From root@core3.amsl.com Sat Oct 2 11:30:08 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F92C3A6BAF; Sat, 2 Oct 2010 11:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101002183004.8F92C3A6BAF@core3.amsl.com> Date: Sat, 2 Oct 2010 11:30:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 18:30:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-11.txt Pages : 36 Date : 2010-10-02 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-usage-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-02111802.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Tue Oct 5 02:21:49 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4885C3A6EFF for ; Tue, 5 Oct 2010 02:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp3RydaBPLuv for ; Tue, 5 Oct 2010 02:21:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D53D13A6F07 for ; Tue, 5 Oct 2010 02:21:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,283,1283745600"; d="scan'208";a="241212966" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Oct 2010 05:22:44 -0400 X-IronPort-AV: E=Sophos;i="4.57,283,1283745600"; d="scan'208";a="519236391" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Oct 2010 05:22:43 -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: Tue, 5 Oct 2010 11:22:29 +0200 Message-ID: In-Reply-To: <4FB2A2E7-04E3-4604-B709-36A0E2F809B2@jdscons.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) Thread-Index: ActkH+fxSOthdfUwSUKp/lhaq7lhwAATbkdQ References: <20100917082039.GA47046@elstar.local> <20100917101102.GA47610@elstar.local><4C9371A6.6040106@cisco.com><000b01cb5895$868c3ca0$4001a8c0@gateway.2wire.net><0b4b01cb58aa$4cd4f320$4001a8c0@gateway.2wire.net><003c01cb58e5$e95359e0$6801a8c0@oemcomputer> <4FB2A2E7-04E3-4604-B709-36A0E2F809B2@jdscons.com> From: "Romascanu, Dan (Dan)" To: "Jon Saperia" , "Randy Presuhn" Cc: netmod@ietf.org Subject: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 09:21:49 -0000 I cannot agree more as well to: =20 > What we need=20 > are widely implemented objects (however you want to call the=20 > structures) that give real visibility into what is going on=20 > in the devices and networks. And I am copying the netmod list on purpose because I hold the opinion that this statement made in the SNMP / ISMS context is true for the current state of the NETCONF and YANG evolution as well.=20 I hope that the rechartering of the NETMOD WG will be soon approved as a step in this direction.=20 Dan > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of Jon Saperia > Sent: Monday, September 20, 2010 7:44 PM > To: Randy Presuhn > Cc: isms@ietf.org; ops-area@ietf.org > Subject: Re: [Isms] [OPS-AREA] status and future of the isms=20 > working group >=20 > I could not agree more.=20 >=20 > I would add that additional protocol/architecture/framework=20 > on any of the management infrastructures we have does not=20 > address the key point I took from Randy's post. What we need=20 > are widely implemented objects (however you want to call the=20 > structures) that give real visibility into what is going on=20 > in the devices and networks. That has always been the=20 > problem and until we address that who cares how we transport=20 > the data. I would settle for RFC2549, if it contained the=20 > right information. >=20 > /jon > On Sep 20, 2010, at 1:04 PM, Randy Presuhn wrote: >=20 > > Hi - > >=20 > >> From: "t.petch" > > ... > >> I think that our resources are limited, and tend to decay with the=20 > >> age of a working group, so I would rather see them applied=20 > elsewhere. =20 > >> I look back at the effort that went into RFC3411, over many years,=20 > >> and yet it fell at the first hurdle, not accommodating the move of=20 > >> security from deep inside the engine to off the bottom of=20 > the radar; why should we do any better this time? > > ... > >=20 > > The problem as I see it was that RFC3411 was intended to be=20 > the glue=20 > > describing how a particular set of specifications fit=20 > together, *not*=20 > > as > > *the* architecture for all future SNMP work. *Requiring*=20 > extensions,=20 > > additions, and embellishments to adhere to that=20 > architecture is in my=20 > > opinion a huge mistake. From my perspective, the real problem=20 > > addressed by RFC 3411 was that some of the preceding proposals for=20 > > securing SNMP had so many convolutions and interactions=20 > that a lot of=20 > > folks had trouble wrapping their heads around them. The modularity=20 > > brought by RFC 3411 was modularity of *specification*, not=20 > necessarily=20 > > implementation. The ASIs were rather controversial because=20 > folks were=20 > > (rightly, in retrospect) concerned that they would be=20 > understood in a=20 > > prescriptive sense, rather than descriptive sense in which=20 > they were=20 > > intended. > >=20 > > More importantly, I think focusing energy on this "problem"=20 > (which is=20 > > tempting because it's something we think we understand) would be a=20 > > huge distraction from the *real* problem: the kinds of information=20 > > models this infrastructure should provide access to. If the=20 > > information models can't support the high-value functions=20 > > administrators / operators need, then embellishing the=20 > protocol engine architecture is a waste of time. > >=20 > > Randy > >=20 > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms >=20 From ietf@andybierman.com Tue Oct 5 08:21:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50453A6F9C for ; Tue, 5 Oct 2010 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLWEEdjcczZI for ; Tue, 5 Oct 2010 08:21:11 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by core3.amsl.com (Postfix) with ESMTP id 552083A6F87 for ; Tue, 5 Oct 2010 08:21:11 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.149.5] (may be forged)) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o95FM8t0011273 for ; Tue, 5 Oct 2010 11:22:08 -0400 Authentication-Results: cm-omr4 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.126.165.113] ([173.126.165.113:52915] helo=[173.126.165.113]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D6/CC-05246-E924BAC4; Tue, 05 Oct 2010 11:22:08 -0400 To: "=?utf-8?B?Um9tYXNjYW51LCBEYW4gKERhbik=?=" , "=?utf-8?B?Sm9uIFNhcGVyaWE=?=" , "=?utf-8?B?UmFuZHkgUHJlc3Vobg==?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 05 Oct 2010 08:22:21 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1286292141457" Cc: netmod@ietf.org Subject: Re: [netmod] =?utf-8?q?True_for_NETCONF/YANG_as_well_=28was=3A_RE=3A_?= =?utf-8?q?=5BIsms=5D_=5BOPS-AREA=5D=09status_and_future_of_the_ism?= =?utf-8?q?s_working_group=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:21:13 -0000 ------=_Part_0_1286292141457 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SXQgaXMgZ29pbmcgdG8gcmVxdWlyZSBkb21haW4tc3BlY2lmaWMgV0cgZWZmb3J0cywgbm90IG1v cmUgbmV0bW9kIHdvcmsuCgpBbmR5CgotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZyb206ICJS b21hc2NhbnUsIERhbiAoRGFuKSIgPGRyb21hc2NhQGF2YXlhLmNvbT4KRGF0ZTogVHVlLCBPY3Qg NSwgMjAxMCAwMjoyMgpTdWJqZWN0OiBbbmV0bW9kXSBUcnVlIGZvciBORVRDT05GL1lBTkcgYXMg d2VsbCAod2FzOiBSRTogW0lzbXNdIFtPUFMtQVJFQV0Jc3RhdHVzIGFuZCBmdXR1cmUgb2YgdGhl IGlzbXMgd29ya2luZyBncm91cCkKVG86ICJKb24gU2FwZXJpYSIgPHNhcGVyaWFAamRzY29ucy5j b20+LCAiUmFuZHkgUHJlc3VobiIgPHJhbmR5X3ByZXN1aG5AbWluZHNwcmluZy5jb20+CkNjOiA8 bmV0bW9kQGlldGYub3JnPgoKCkkgY2Fubm90IGFncmVlIG1vcmUgYXMgd2VsbCB0bzogIAoKPiAg V2hhdCB3ZSBuZWVkIAo+IGFyZSB3aWRlbHkgaW1wbGVtZW50ZWQgb2JqZWN0cyAoaG93ZXZlciB5 b3Ugd2FudCB0byBjYWxsIHRoZSAKPiBzdHJ1Y3R1cmVzKSB0aGF0IGdpdmUgcmVhbCB2aXNpYmls aXR5IGludG8gd2hhdCBpcyBnb2luZyBvbiAKPiBpbiB0aGUgZGV2aWNlcyBhbmQgbmV0d29ya3Mu CgpBbmQgSSBhbSBjb3B5aW5nIHRoZSBuZXRtb2QgbGlzdCBvbiBwdXJwb3NlIGJlY2F1c2UgSSBo b2xkIHRoZSBvcGluaW9uCnRoYXQgdGhpcyBzdGF0ZW1lbnQgbWFkZSBpbiB0aGUgU05NUCAvIElT TVMgY29udGV4dCBpcyB0cnVlIGZvciB0aGUKY3VycmVudCBzdGF0ZSBvZiB0aGUgTkVUQ09ORiBh bmQgWUFORyBldm9sdXRpb24gYXMgd2VsbC4gCgpJIGhvcGUgdGhhdCB0aGUgcmVjaGFydGVyaW5n IG9mIHRoZSBORVRNT0QgV0cgd2lsbCBiZSBzb29uIGFwcHJvdmVkIGFzIGEKc3RlcCBpbiB0aGlz IGRpcmVjdGlvbi4gCgpEYW4KCgoKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206 IGlzbXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlzbXMtYm91bmNlc0BpZXRmLm9yZ10gT24g Cj4gQmVoYWxmIE9mIEpvbiBTYXBlcmlhCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjAsIDIw MTAgNzo0NCBQTQo+IFRvOiBSYW5keSBQcmVzdWhuCj4gQ2M6IGlzbXNAaWV0Zi5vcmc7IG9wcy1h cmVhQGlldGYub3JnCj4gU3ViamVjdDogUmU6IFtJc21zXSBbT1BTLUFSRUFdIHN0YXR1cyBhbmQg ZnV0dXJlIG9mIHRoZSBpc21zIAo+IHdvcmtpbmcgZ3JvdXAKPiAKPiBJIGNvdWxkIG5vdCBhZ3Jl ZSBtb3JlLiAKPiAKPiBJIHdvdWxkIGFkZCAgdGhhdCBhZGRpdGlvbmFsIHByb3RvY29sL2FyY2hp dGVjdHVyZS9mcmFtZXdvcmsgCj4gb24gYW55IG9mIHRoZSBtYW5hZ2VtZW50IGluZnJhc3RydWN0 dXJlcyB3ZSBoYXZlIGRvZXMgbm90IAo+IGFkZHJlc3MgdGhlIGtleSBwb2ludCBJIHRvb2sgZnJv bSBSYW5keSdzIHBvc3QuICBXaGF0IHdlIG5lZWQgCj4gYXJlIHdpZGVseSBpbXBsZW1lbnRlZCBv YmplY3RzIChob3dldmVyIHlvdSB3YW50IHRvIGNhbGwgdGhlIAo+IHN0cnVjdHVyZXMpIHRoYXQg Z2l2ZSByZWFsIHZpc2liaWxpdHkgaW50byB3aGF0IGlzIGdvaW5nIG9uIAo+IGluIHRoZSBkZXZp Y2VzIGFuZCBuZXR3b3Jrcy4gIFRoYXQgaGFzIGFsd2F5cyBiZWVuIHRoZSAKPiBwcm9ibGVtIGFu ZCB1bnRpbCB3ZSBhZGRyZXNzIHRoYXQgd2hvIGNhcmVzIGhvdyB3ZSB0cmFuc3BvcnQgCj4gdGhl IGRhdGEuIEkgd291bGQgc2V0dGxlIGZvciBSRkMyNTQ5LCBpZiBpdCBjb250YWluZWQgdGhlIAo+ IHJpZ2h0IGluZm9ybWF0aW9uLgo+IAo+IC9qb24KPiBPbiBTZXAgMjAsIDIwMTAsIGF0IDE6MDQg UE0sIFJhbmR5IFByZXN1aG4gd3JvdGU6Cj4gCj4gPiBIaSAtCj4gPiAKPiA+PiBGcm9tOiAidC5w ZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+Cj4gPiAuLi4KPiA+PiBJIHRoaW5rIHRoYXQgb3Vy IHJlc291cmNlcyBhcmUgbGltaXRlZCwgYW5kIHRlbmQgdG8gZGVjYXkgd2l0aCB0aGUgCj4gPj4g YWdlIG9mIGEgd29ya2luZyBncm91cCwgc28gSSB3b3VsZCByYXRoZXIgc2VlIHRoZW0gYXBwbGll ZCAKPiBlbHNld2hlcmUuICAKPiA+PiBJIGxvb2sgYmFjayBhdCB0aGUgZWZmb3J0IHRoYXQgd2Vu dCBpbnRvIFJGQzM0MTEsIG92ZXIgbWFueSB5ZWFycywgCj4gPj4gYW5kIHlldCBpdCBmZWxsIGF0 IHRoZSBmaXJzdCBodXJkbGUsIG5vdCBhY2NvbW1vZGF0aW5nIHRoZSBtb3ZlIG9mIAo+ID4+IHNl Y3VyaXR5IGZyb20gZGVlcCBpbnNpZGUgdGhlIGVuZ2luZSB0byBvZmYgdGhlIGJvdHRvbSBvZiAK PiB0aGUgcmFkYXI7IHdoeSBzaG91bGQgd2UgZG8gYW55IGJldHRlciB0aGlzIHRpbWU/Cj4gPiAu Li4KPiA+IAo+ID4gVGhlIHByb2JsZW0gYXMgSSBzZWUgaXQgd2FzIHRoYXQgUkZDMzQxMSB3YXMg aW50ZW5kZWQgdG8gYmUgCj4gdGhlIGdsdWUgCj4gPiBkZXNjcmliaW5nIGhvdyBhIHBhcnRpY3Vs YXIgc2V0IG9mIHNwZWNpZmljYXRpb25zIGZpdCAKPiB0b2dldGhlciwgKm5vdCogCj4gPiBhcwo+ ID4gKnRoZSogYXJjaGl0ZWN0dXJlIGZvciBhbGwgZnV0dXJlIFNOTVAgd29yay4gICpSZXF1aXJp bmcqIAo+IGV4dGVuc2lvbnMsIAo+ID4gYWRkaXRpb25zLCBhbmQgZW1iZWxsaXNobWVudHMgdG8g YWRoZXJlIHRvIHRoYXQgCj4gYXJjaGl0ZWN0dXJlIGlzIGluIG15IAo+ID4gb3BpbmlvbiBhIGh1 Z2UgbWlzdGFrZS4gIEZyb20gbXkgcGVyc3BlY3RpdmUsIHRoZSByZWFsIHByb2JsZW0gCj4gPiBh ZGRyZXNzZWQgYnkgUkZDIDM0MTEgd2FzIHRoYXQgc29tZSBvZiB0aGUgcHJlY2VkaW5nIHByb3Bv c2FscyBmb3IgCj4gPiBzZWN1cmluZyBTTk1QIGhhZCBzbyBtYW55IGNvbnZvbHV0aW9ucyBhbmQg aW50ZXJhY3Rpb25zIAo+IHRoYXQgYSBsb3Qgb2YgCj4gPiBmb2xrcyBoYWQgdHJvdWJsZSB3cmFw cGluZyB0aGVpciBoZWFkcyBhcm91bmQgdGhlbS4gIFRoZSBtb2R1bGFyaXR5IAo+ID4gYnJvdWdo dCBieSBSRkMgMzQxMSB3YXMgbW9kdWxhcml0eSBvZiAqc3BlY2lmaWNhdGlvbiosIG5vdCAKPiBu ZWNlc3NhcmlseSAKPiA+IGltcGxlbWVudGF0aW9uLiAgVGhlIEFTSXMgd2VyZSByYXRoZXIgY29u dHJvdmVyc2lhbCBiZWNhdXNlIAo+IGZvbGtzIHdlcmUgCj4gPiAocmlnaHRseSwgaW4gcmV0cm9z cGVjdCkgY29uY2VybmVkIHRoYXQgdGhleSB3b3VsZCBiZSAKPiB1bmRlcnN0b29kIGluIGEgCj4g PiBwcmVzY3JpcHRpdmUgc2Vuc2UsIHJhdGhlciB0aGFuIGRlc2NyaXB0aXZlIHNlbnNlIGluIHdo aWNoIAo+IHRoZXkgd2VyZSAKPiA+IGludGVuZGVkLgo+ID4gCj4gPiBNb3JlIGltcG9ydGFudGx5 LCBJIHRoaW5rIGZvY3VzaW5nIGVuZXJneSBvbiB0aGlzICJwcm9ibGVtIiAKPiAod2hpY2ggaXMg Cj4gPiB0ZW1wdGluZyBiZWNhdXNlIGl0J3Mgc29tZXRoaW5nIHdlIHRoaW5rIHdlIHVuZGVyc3Rh bmQpIHdvdWxkIGJlIGEgCj4gPiBodWdlIGRpc3RyYWN0aW9uIGZyb20gdGhlICpyZWFsKiBwcm9i bGVtOiB0aGUga2luZHMgb2YgaW5mb3JtYXRpb24gCj4gPiBtb2RlbHMgdGhpcyBpbmZyYXN0cnVj dHVyZSBzaG91bGQgcHJvdmlkZSBhY2Nlc3MgdG8uICBJZiB0aGUgCj4gPiBpbmZvcm1hdGlvbiBt b2RlbHMgY2FuJ3Qgc3VwcG9ydCB0aGUgaGlnaC12YWx1ZSBmdW5jdGlvbnMgCj4gPiBhZG1pbmlz dHJhdG9ycyAvIG9wZXJhdG9ycyBuZWVkLCB0aGVuIGVtYmVsbGlzaGluZyB0aGUgCj4gcHJvdG9j b2wgZW5naW5lIGFyY2hpdGVjdHVyZSBpcyBhIHdhc3RlIG9mIHRpbWUuCj4gPiAKPiA+IFJhbmR5 Cj4gPiAKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gPiBPUFMtQVJFQSBtYWlsaW5nIGxpc3QKPiA+IE9QUy1BUkVBQGlldGYub3JnCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1hcmVhCj4gPiAKPiAKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IElzbXMgbWFpbGlu ZyBsaXN0Cj4gSXNtc0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXNtcwo+IApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAoK ------=_Part_0_1286292141457 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SXQgaXMgZ29pbmcgdG8gcmVxdWlyZSBkb21haW4tc3BlY2lmaWMgV0cgZWZmb3J0cywgbm90IG1v cmUgbmV0bW9kIHdvcmsuPGJyPjxicj5BbmR5PGJyPjxicj4tLS0tLSBSZXBseSBtZXNzYWdlIC0t LS0tPGJyPkZyb206ICZxdW90O1JvbWFzY2FudSwgRGFuIChEYW4pJnF1b3Q7ICZsdDtkcm9tYXNj YUBhdmF5YS5jb20mZ3Q7PGJyPkRhdGU6IFR1ZSwgT2N0IDUsIDIwMTAgMDI6MjI8YnI+U3ViamVj dDogW25ldG1vZF0gVHJ1ZSBmb3IgTkVUQ09ORi9ZQU5HIGFzIHdlbGwgKHdhczogUkU6IFtJc21z XSBbT1BTLUFSRUFdCXN0YXR1cyBhbmQgZnV0dXJlIG9mIHRoZSBpc21zIHdvcmtpbmcgZ3JvdXAp PGJyPlRvOiAmcXVvdDtKb24gU2FwZXJpYSZxdW90OyAmbHQ7c2FwZXJpYUBqZHNjb25zLmNvbSZn dDssICZxdW90O1JhbmR5IFByZXN1aG4mcXVvdDsgJmx0O3JhbmR5X3ByZXN1aG5AbWluZHNwcmlu Zy5jb20mZ3Q7PGJyPkNjOiAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj48YnI+PGJyPkkgY2Fu bm90IGFncmVlIG1vcmUgYXMgd2VsbCB0bzogJm5ic3A7PGJyPjxicj4mZ3Q7ICZuYnNwO1doYXQg d2UgbmVlZCA8YnI+Jmd0OyBhcmUgd2lkZWx5IGltcGxlbWVudGVkIG9iamVjdHMgKGhvd2V2ZXIg eW91IHdhbnQgdG8gY2FsbCB0aGUgPGJyPiZndDsgc3RydWN0dXJlcykgdGhhdCBnaXZlIHJlYWwg dmlzaWJpbGl0eSBpbnRvIHdoYXQgaXMgZ29pbmcgb24gPGJyPiZndDsgaW4gdGhlIGRldmljZXMg YW5kIG5ldHdvcmtzLjxicj48YnI+QW5kIEkgYW0gY29weWluZyB0aGUgbmV0bW9kIGxpc3Qgb24g cHVycG9zZSBiZWNhdXNlIEkgaG9sZCB0aGUgb3Bpbmlvbjxicj50aGF0IHRoaXMgc3RhdGVtZW50 IG1hZGUgaW4gdGhlIFNOTVAgLyBJU01TIGNvbnRleHQgaXMgdHJ1ZSBmb3IgdGhlPGJyPmN1cnJl bnQgc3RhdGUgb2YgdGhlIE5FVENPTkYgYW5kIFlBTkcgZXZvbHV0aW9uIGFzIHdlbGwuIDxicj48 YnI+SSBob3BlIHRoYXQgdGhlIHJlY2hhcnRlcmluZyBvZiB0aGUgTkVUTU9EIFdHIHdpbGwgYmUg c29vbiBhcHByb3ZlZCBhcyBhPGJyPnN0ZXAgaW4gdGhpcyBkaXJlY3Rpb24uIDxicj48YnI+RGFu PGJyPjxicj48YnI+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyBG cm9tOiBpc21zLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppc21zLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIDxicj4mZ3Q7IEJlaGFsZiBPZiBKb24gU2FwZXJpYTxicj4mZ3Q7IFNlbnQ6IE1vbmRheSwg U2VwdGVtYmVyIDIwLCAyMDEwIDc6NDQgUE08YnI+Jmd0OyBUbzogUmFuZHkgUHJlc3Vobjxicj4m Z3Q7IENjOiBpc21zQGlldGYub3JnOyBvcHMtYXJlYUBpZXRmLm9yZzxicj4mZ3Q7IFN1YmplY3Q6 IFJlOiBbSXNtc10gW09QUy1BUkVBXSBzdGF0dXMgYW5kIGZ1dHVyZSBvZiB0aGUgaXNtcyA8YnI+ Jmd0OyB3b3JraW5nIGdyb3VwPGJyPiZndDsgPGJyPiZndDsgSSBjb3VsZCBub3QgYWdyZWUgbW9y ZS4gPGJyPiZndDsgPGJyPiZndDsgSSB3b3VsZCBhZGQgJm5ic3A7dGhhdCBhZGRpdGlvbmFsIHBy b3RvY29sL2FyY2hpdGVjdHVyZS9mcmFtZXdvcmsgPGJyPiZndDsgb24gYW55IG9mIHRoZSBtYW5h Z2VtZW50IGluZnJhc3RydWN0dXJlcyB3ZSBoYXZlIGRvZXMgbm90IDxicj4mZ3Q7IGFkZHJlc3Mg dGhlIGtleSBwb2ludCBJIHRvb2sgZnJvbSBSYW5keSYjMzk7cyBwb3N0LiAmbmJzcDtXaGF0IHdl IG5lZWQgPGJyPiZndDsgYXJlIHdpZGVseSBpbXBsZW1lbnRlZCBvYmplY3RzIChob3dldmVyIHlv dSB3YW50IHRvIGNhbGwgdGhlIDxicj4mZ3Q7IHN0cnVjdHVyZXMpIHRoYXQgZ2l2ZSByZWFsIHZp c2liaWxpdHkgaW50byB3aGF0IGlzIGdvaW5nIG9uIDxicj4mZ3Q7IGluIHRoZSBkZXZpY2VzIGFu ZCBuZXR3b3Jrcy4gJm5ic3A7VGhhdCBoYXMgYWx3YXlzIGJlZW4gdGhlIDxicj4mZ3Q7IHByb2Js ZW0gYW5kIHVudGlsIHdlIGFkZHJlc3MgdGhhdCB3aG8gY2FyZXMgaG93IHdlIHRyYW5zcG9ydCA8 YnI+Jmd0OyB0aGUgZGF0YS4gSSB3b3VsZCBzZXR0bGUgZm9yIFJGQzI1NDksIGlmIGl0IGNvbnRh aW5lZCB0aGUgPGJyPiZndDsgcmlnaHQgaW5mb3JtYXRpb24uPGJyPiZndDsgPGJyPiZndDsgL2pv bjxicj4mZ3Q7IE9uIFNlcCAyMCwgMjAxMCwgYXQgMTowNCBQTSwgUmFuZHkgUHJlc3VobiB3cm90 ZTo8YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7IEhpIC08YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsm Z3Q7IEZyb206ICZxdW90O3QucGV0Y2gmcXVvdDsgJmx0O2lldGZjQGJ0Y29ubmVjdC5jb20mZ3Q7 PGJyPiZndDsgJmd0OyAuLi48YnI+Jmd0OyAmZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgb3VyIHJlc291 cmNlcyBhcmUgbGltaXRlZCwgYW5kIHRlbmQgdG8gZGVjYXkgd2l0aCB0aGUgPGJyPiZndDsgJmd0 OyZndDsgYWdlIG9mIGEgd29ya2luZyBncm91cCwgc28gSSB3b3VsZCByYXRoZXIgc2VlIHRoZW0g YXBwbGllZCA8YnI+Jmd0OyBlbHNld2hlcmUuICZuYnNwOzxicj4mZ3Q7ICZndDsmZ3Q7IEkgbG9v ayBiYWNrIGF0IHRoZSBlZmZvcnQgdGhhdCB3ZW50IGludG8gUkZDMzQxMSwgb3ZlciBtYW55IHll YXJzLCA8YnI+Jmd0OyAmZ3Q7Jmd0OyBhbmQgeWV0IGl0IGZlbGwgYXQgdGhlIGZpcnN0IGh1cmRs ZSwgbm90IGFjY29tbW9kYXRpbmcgdGhlIG1vdmUgb2YgPGJyPiZndDsgJmd0OyZndDsgc2VjdXJp dHkgZnJvbSBkZWVwIGluc2lkZSB0aGUgZW5naW5lIHRvIG9mZiB0aGUgYm90dG9tIG9mIDxicj4m Z3Q7IHRoZSByYWRhcjsgd2h5IHNob3VsZCB3ZSBkbyBhbnkgYmV0dGVyIHRoaXMgdGltZT88YnI+ Jmd0OyAmZ3Q7IC4uLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBUaGUgcHJvYmxlbSBhcyBJ IHNlZSBpdCB3YXMgdGhhdCBSRkMzNDExIHdhcyBpbnRlbmRlZCB0byBiZSA8YnI+Jmd0OyB0aGUg Z2x1ZSA8YnI+Jmd0OyAmZ3Q7IGRlc2NyaWJpbmcgaG93IGEgcGFydGljdWxhciBzZXQgb2Ygc3Bl Y2lmaWNhdGlvbnMgZml0IDxicj4mZ3Q7IHRvZ2V0aGVyLCAqbm90KiA8YnI+Jmd0OyAmZ3Q7IGFz PGJyPiZndDsgJmd0OyAqdGhlKiBhcmNoaXRlY3R1cmUgZm9yIGFsbCBmdXR1cmUgU05NUCB3b3Jr LiAmbmJzcDsqUmVxdWlyaW5nKiA8YnI+Jmd0OyBleHRlbnNpb25zLCA8YnI+Jmd0OyAmZ3Q7IGFk ZGl0aW9ucywgYW5kIGVtYmVsbGlzaG1lbnRzIHRvIGFkaGVyZSB0byB0aGF0IDxicj4mZ3Q7IGFy Y2hpdGVjdHVyZSBpcyBpbiBteSA8YnI+Jmd0OyAmZ3Q7IG9waW5pb24gYSBodWdlIG1pc3Rha2Uu ICZuYnNwO0Zyb20gbXkgcGVyc3BlY3RpdmUsIHRoZSByZWFsIHByb2JsZW0gPGJyPiZndDsgJmd0 OyBhZGRyZXNzZWQgYnkgUkZDIDM0MTEgd2FzIHRoYXQgc29tZSBvZiB0aGUgcHJlY2VkaW5nIHBy b3Bvc2FscyBmb3IgPGJyPiZndDsgJmd0OyBzZWN1cmluZyBTTk1QIGhhZCBzbyBtYW55IGNvbnZv bHV0aW9ucyBhbmQgaW50ZXJhY3Rpb25zIDxicj4mZ3Q7IHRoYXQgYSBsb3Qgb2YgPGJyPiZndDsg Jmd0OyBmb2xrcyBoYWQgdHJvdWJsZSB3cmFwcGluZyB0aGVpciBoZWFkcyBhcm91bmQgdGhlbS4g Jm5ic3A7VGhlIG1vZHVsYXJpdHkgPGJyPiZndDsgJmd0OyBicm91Z2h0IGJ5IFJGQyAzNDExIHdh cyBtb2R1bGFyaXR5IG9mICpzcGVjaWZpY2F0aW9uKiwgbm90IDxicj4mZ3Q7IG5lY2Vzc2FyaWx5 IDxicj4mZ3Q7ICZndDsgaW1wbGVtZW50YXRpb24uICZuYnNwO1RoZSBBU0lzIHdlcmUgcmF0aGVy IGNvbnRyb3ZlcnNpYWwgYmVjYXVzZSA8YnI+Jmd0OyBmb2xrcyB3ZXJlIDxicj4mZ3Q7ICZndDsg KHJpZ2h0bHksIGluIHJldHJvc3BlY3QpIGNvbmNlcm5lZCB0aGF0IHRoZXkgd291bGQgYmUgPGJy PiZndDsgdW5kZXJzdG9vZCBpbiBhIDxicj4mZ3Q7ICZndDsgcHJlc2NyaXB0aXZlIHNlbnNlLCBy YXRoZXIgdGhhbiBkZXNjcmlwdGl2ZSBzZW5zZSBpbiB3aGljaCA8YnI+Jmd0OyB0aGV5IHdlcmUg PGJyPiZndDsgJmd0OyBpbnRlbmRlZC48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgTW9yZSBp bXBvcnRhbnRseSwgSSB0aGluayBmb2N1c2luZyBlbmVyZ3kgb24gdGhpcyAmcXVvdDtwcm9ibGVt JnF1b3Q7IDxicj4mZ3Q7ICh3aGljaCBpcyA8YnI+Jmd0OyAmZ3Q7IHRlbXB0aW5nIGJlY2F1c2Ug aXQmIzM5O3Mgc29tZXRoaW5nIHdlIHRoaW5rIHdlIHVuZGVyc3RhbmQpIHdvdWxkIGJlIGEgPGJy PiZndDsgJmd0OyBodWdlIGRpc3RyYWN0aW9uIGZyb20gdGhlICpyZWFsKiBwcm9ibGVtOiB0aGUg a2luZHMgb2YgaW5mb3JtYXRpb24gPGJyPiZndDsgJmd0OyBtb2RlbHMgdGhpcyBpbmZyYXN0cnVj dHVyZSBzaG91bGQgcHJvdmlkZSBhY2Nlc3MgdG8uICZuYnNwO0lmIHRoZSA8YnI+Jmd0OyAmZ3Q7 IGluZm9ybWF0aW9uIG1vZGVscyBjYW4mIzM5O3Qgc3VwcG9ydCB0aGUgaGlnaC12YWx1ZSBmdW5j dGlvbnMgPGJyPiZndDsgJmd0OyBhZG1pbmlzdHJhdG9ycyAvIG9wZXJhdG9ycyBuZWVkLCB0aGVu IGVtYmVsbGlzaGluZyB0aGUgPGJyPiZndDsgcHJvdG9jb2wgZW5naW5lIGFyY2hpdGVjdHVyZSBp cyBhIHdhc3RlIG9mIHRpbWUuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFJhbmR5PGJyPiZn dDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPiZndDsgJmd0OyBPUFMtQVJFQSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAm Z3Q7IE9QUy1BUkVBQGlldGYub3JnPGJyPiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1hcmVhIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29wcy1hcmVhPC9hPjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgPGJyPiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0 OyBJc21zIG1haWxpbmcgbGlzdDxicj4mZ3Q7IElzbXNAaWV0Zi5vcmc8YnI+Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lzbXMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXNtczwvYT48YnI+Jmd0OyA8YnI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bmV0bW9kIG1haWxpbmcg bGlzdDxicj5uZXRtb2RAaWV0Zi5vcmc8YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kPC9hPjxicj48YnI+PGJyPjxicj4= ------=_Part_0_1286292141457-- From saperia@jdscons.com Tue Oct 5 08:29:42 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C71C3A6C96 for ; Tue, 5 Oct 2010 08:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3N-YeSNl2ta for ; Tue, 5 Oct 2010 08:29:40 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 2F8FD3A6AD2 for ; Tue, 5 Oct 2010 08:29:40 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o95FUWke022977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Oct 2010 10:30:33 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-168-895271102 From: Jon Saperia In-Reply-To: Date: Tue, 5 Oct 2010 11:30:32 -0400 Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1081) Cc: netmod@ietf.org Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:29:42 -0000 --Apple-Mail-168-895271102 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes. Many objects that are used in SNMP today were developed outside of the = SNMP WG. The larger community now has to look at the body of work = completed in NETCONF/YANG and see how they might want to define standard = configuration objects for their respective areas. /jon On Oct 5, 2010, at 11:22 AM, Andy Bierman wrote: > It is going to require domain-specific WG efforts, not more netmod = work. >=20 > Andy >=20 > ----- Reply message ----- > From: "Romascanu, Dan (Dan)" > Date: Tue, Oct 5, 2010 02:22 > Subject: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] = [OPS-AREA] status and future of the isms working group) > To: "Jon Saperia" , "Randy Presuhn" = > Cc: >=20 >=20 > I cannot agree more as well to: =20 >=20 > > What we need=20 > > are widely implemented objects (however you want to call the=20 > > structures) that give real visibility into what is going on=20 > > in the devices and networks. >=20 > And I am copying the netmod list on purpose because I hold the opinion > that this statement made in the SNMP / ISMS context is true for the > current state of the NETCONF and YANG evolution as well.=20 >=20 > I hope that the rechartering of the NETMOD WG will be soon approved as = a > step in this direction.=20 >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > > Behalf Of Jon Saperia > > Sent: Monday, September 20, 2010 7:44 PM > > To: Randy Presuhn > > Cc: isms@ietf.org; ops-area@ietf.org > > Subject: Re: [Isms] [OPS-AREA] status and future of the isms=20 > > working group > >=20 > > I could not agree more.=20 > >=20 > > I would add that additional protocol/architecture/framework=20 > > on any of the management infrastructures we have does not=20 > > address the key point I took from Randy's post. What we need=20 > > are widely implemented objects (however you want to call the=20 > > structures) that give real visibility into what is going on=20 > > in the devices and networks. That has always been the=20 > > problem and until we address that who cares how we transport=20 > > the data. I would settle for RFC2549, if it contained the=20 > > right information. > >=20 > > /jon > > On Sep 20, 2010, at 1:04 PM, Randy Presuhn wrote: > >=20 > > > Hi - > > >=20 > > >> From: "t.petch" > > > ... > > >> I think that our resources are limited, and tend to decay with = the=20 > > >> age of a working group, so I would rather see them applied=20 > > elsewhere. =20 > > >> I look back at the effort that went into RFC3411, over many = years,=20 > > >> and yet it fell at the first hurdle, not accommodating the move = of=20 > > >> security from deep inside the engine to off the bottom of=20 > > the radar; why should we do any better this time? > > > ... > > >=20 > > > The problem as I see it was that RFC3411 was intended to be=20 > > the glue=20 > > > describing how a particular set of specifications fit=20 > > together, *not*=20 > > > as > > > *the* architecture for all future SNMP work. *Requiring*=20 > > extensions,=20 > > > additions, and embellishments to adhere to that=20 > > architecture is in my=20 > > > opinion a huge mistake. =46rom my perspective, the real problem=20= > > > addressed by RFC 3411 was that some of the preceding proposals for=20= > > > securing SNMP had so many convolutions and interactions=20 > > that a lot of=20 > > > folks had trouble wrapping their heads around them. The = modularity=20 > > > brought by RFC 3411 was modularity of *specification*, not=20 > > necessarily=20 > > > implementation. The ASIs were rather controversial because=20 > > folks were=20 > > > (rightly, in retrospect) concerned that they would be=20 > > understood in a=20 > > > prescriptive sense, rather than descriptive sense in which=20 > > they were=20 > > > intended. > > >=20 > > > More importantly, I think focusing energy on this "problem"=20 > > (which is=20 > > > tempting because it's something we think we understand) would be a=20= > > > huge distraction from the *real* problem: the kinds of information=20= > > > models this infrastructure should provide access to. If the=20 > > > information models can't support the high-value functions=20 > > > administrators / operators need, then embellishing the=20 > > protocol engine architecture is a waste of time. > > >=20 > > > Randy > > >=20 > > > _______________________________________________ > > > OPS-AREA mailing list > > > OPS-AREA@ietf.org > > > https://www.ietf.org/mailman/listinfo/ops-area > > >=20 > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 >=20 --Apple-Mail-168-895271102 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 5, 2010, at 11:22 AM, Andy Bierman wrote:

It is = going to require domain-specific WG efforts, not more netmod = work.

Andy

----- Reply message -----
From: "Romascanu, = Dan (Dan)" <dromasca@avaya.com>
Date: = Tue, Oct 5, 2010 02:22
Subject: [netmod] True for NETCONF/YANG as = well (was: RE: [Isms] [OPS-AREA] status and future of the isms = working group)
To: "Jon Saperia" <saperia@jdscons.com>, "Randy = Presuhn" <randy_presuhn@mindspring.com<= /a>>
Cc: <netmod@ietf.org>


I = cannot agree more as well to:  

>  What we need =
> are widely implemented objects (however you want to call the =
> structures) that give real visibility into what is going on =
> in the devices and networks.

And I am copying the netmod = list on purpose because I hold the opinion
that this statement made = in the SNMP / ISMS context is true for the
current state of the = NETCONF and YANG evolution as well.

I hope that the rechartering = of the NETMOD WG will be soon approved as a
step in this direction. =

Dan



> -----Original Message-----
> From: = isms-bounces@ietf.org = [mailto:isms-bounces@ietf.org] On
> Behalf Of Jon Saperia
> = Sent: Monday, September 20, 2010 7:44 PM
> To: Randy = Presuhn
> Cc: isms@ietf.org; = ops-area@ietf.org
> = Subject: Re: [Isms] [OPS-AREA] status and future of the isms
> = working group
>
> I could not agree more.
>
> = I would add  that additional protocol/architecture/framework =
> on any of the management infrastructures we have does not =
> address the key point I took from Randy's post.  What we = need
> are widely implemented objects (however you want to call = the
> structures) that give real visibility into what is going on =
> in the devices and networks.  That has always been the =
> problem and until we address that who cares how we transport =
> the data. I would settle for RFC2549, if it contained the =
> right information.
>
> /jon
> On Sep 20, = 2010, at 1:04 PM, Randy Presuhn wrote:
>
> > Hi = -
> >
> >> From: "t.petch" <ietfc@btconnect.com>
> = > ...
> >> I think that our resources are limited, and = tend to decay with the
> >> age of a working group, so I = would rather see them applied
> elsewhere.  
> = >> I look back at the effort that went into RFC3411, over many = years,
> >> and yet it fell at the first hurdle, not = accommodating the move of
> >> security from deep inside = the engine to off the bottom of
> the radar; why should we do any = better this time?
> > ...
> >
> > The = problem as I see it was that RFC3411 was intended to be
> the = glue
> > describing how a particular set of specifications fit =
> together, *not*
> > as
> > *the* = architecture for all future SNMP work.  *Requiring*
> = extensions,
> > additions, and embellishments to adhere to = that
> architecture is in my
> > opinion a huge = mistake.  =46rom my perspective, the real problem
> > = addressed by RFC 3411 was that some of the preceding proposals for =
> > securing SNMP had so many convolutions and interactions =
> that a lot of
> > folks had trouble wrapping their = heads around them.  The modularity
> > brought by RFC = 3411 was modularity of *specification*, not
> necessarily =
> > implementation.  The ASIs were rather controversial = because
> folks were
> > (rightly, in retrospect) = concerned that they would be
> understood in a
> > = prescriptive sense, rather than descriptive sense in which
> they = were
> > intended.
> >
> > More = importantly, I think focusing energy on this "problem"
> (which = is
> > tempting because it's something we think we understand) = would be a
> > huge distraction from the *real* problem: the = kinds of information
> > models this infrastructure should = provide access to.  If the
> > information models can't = support the high-value functions
> > administrators / = operators need, then embellishing the
> protocol engine = architecture is a waste of time.
> >
> > = Randy
> >
> > = _______________________________________________
> > OPS-AREA = mailing list
> > OPS-AREA@ietf.org
> > https://www.ietf.o= rg/mailman/listinfo/ops-area
> >
>
> = _______________________________________________
> Isms mailing = list
> Isms@ietf.org
> = https://www.ietf.org/m= ailman/listinfo/isms
> =
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org= /mailman/listinfo/netmod




<= /body>= --Apple-Mail-168-895271102-- From wwwrun@core3.amsl.com Tue Oct 5 09:51:38 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A34533A6FC6; Tue, 5 Oct 2010 09:51:38 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101005165138.A34533A6FC6@core3.amsl.com> Date: Tue, 5 Oct 2010 09:51:38 -0700 (PDT) Cc: Internet Architecture Board , netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Document Action: 'Guidelines for Authors and Reviewers of YANG Data Model Documents' to Informational RFC X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:51:38 -0000 The IESG has approved the following document: - 'Guidelines for Authors and Reviewers of YANG Data Model Documents' as an Informational RFC This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-usage/ Technical Summary This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations which utilize YANG data model modules. Working Group Summary Consensus was reached among all interested parties before requesting the publication of this document. Document Quality Multiple implementers of YANG and those who write models using YANG have reviewed the document. Personnel David Partain is the Document Shepherd for this document? Dan Romascanu is the Responsible Area Director. RFC Editor Note 1. In Section 3.4: OLD: This section MUST be patterned after the latest approved template (available at http://www.ops.ietf.org/netconf/yang-security-considerations.txt). NEW: This section MUST be patterned after the latest approved template (available at http://www.ops.ietf.org/netconf/yang-security-considerations.txt). Section 6.1 contains the security considerations template dated 2010-06-16. Authors MUST check the WEB page at the URL listed above in case there is a more recent version available. 2. In Section 3.5: OLD: In order to comply with IESG policy as set forth in http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is submitted to the IESG for publication which has action items for IANA MUST contain an IANA Considerations section. The requirements for this section vary depending what actions are required of the IANA. If there are no IANA considerations applicable to the document, then the IANA Considerations section is not required. Refer to the guidelines in [RFC5226] for more details. NEW: In order to comply with IESG policy as set forth in http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is submitted to the IESG for publication which has action items for IANA MUST contain an IANA Considerations section. The requirements for this section vary depending what actions are required of the IANA. If there are no IANA considerations applicable to the document, then the IANA Considerations section is not required and is removed by the RFC Editor before publication. Refer to then guidelines in [RFC5226] for more details. 3. In section 'Appendix A. Module Review Checklist', add to bullet item 4: The Ops & Mgmt Area Director is investigating whether a better location on the main IETF website for the following url: http://www.ops.ietf.org/netconf/yang-security-considerations.txt can be found. Please check prior to publication whether a replacement location has been found. From j.schoenwaelder@jacobs-university.de Tue Oct 5 10:06:41 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBD73A6FA7 for ; Tue, 5 Oct 2010 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.975 X-Spam-Level: X-Spam-Status: No, score=-101.975 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6JuYFsOqq6W for ; Tue, 5 Oct 2010 10:06:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 136DA3A6F8B for ; Tue, 5 Oct 2010 10:06:40 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7865C001E; Tue, 5 Oct 2010 19:07:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nxhDx9Z10vUs; Tue, 5 Oct 2010 19:07:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03BDAC0023; Tue, 5 Oct 2010 19:07:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B75BA1510244; Tue, 5 Oct 2010 19:07:06 +0200 (CEST) Date: Tue, 5 Oct 2010 19:07:06 +0200 From: Juergen Schoenwaelder To: Jon Saperia Message-ID: <20101005170705.GB48717@elstar.local> Mail-Followup-To: Jon Saperia , Andy Bierman , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:06:41 -0000 On Tue, Oct 05, 2010 at 05:30:32PM +0200, Jon Saperia wrote: > Many objects that are used in SNMP today were developed outside of > the SNMP WG. The larger community now has to look at the body of > work completed in NETCONF/YANG and see how they might want to define > standard configuration objects for their respective areas. Nope, the NETCONF/NETMOD framework still lack a common understanding how to structure data models (missing basic infrastructure) and we do not really know how to deal with the distinction and modeling of the relationship between operational state and configuration state. This is why NETMOD was supposed to recharter to put the core data models in place. At least that was my understanding at the last IETF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Oct 5 10:21:09 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955593A6D7B for ; Tue, 5 Oct 2010 10:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84273avhBAlP for ; Tue, 5 Oct 2010 10:21:08 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 6C2353A6CE1 for ; Tue, 5 Oct 2010 10:21:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,285,1283745600"; d="scan'208";a="241292675" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Oct 2010 13:22:06 -0400 X-IronPort-AV: E=Sophos;i="4.57,285,1283745600"; d="scan'208";a="523462396" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Oct 2010 13:22:05 -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: Tue, 5 Oct 2010 19:21:44 +0200 Message-ID: In-Reply-To: <20101005170705.GB48717@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) Thread-Index: Actkr9JqNL8gio2CR9O0nk/3FT8LSwAAUK5Q References: <20101005170705.GB48717@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Jon Saperia" Cc: netmod@ietf.org Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:21:09 -0000 The re-chartering is on the table of the IESG. I agree with Juergen here, I think that the NETMOD team should do one more step in creating a small base of core YANG modules that would both provide basic infrastructure objects and a small set of examples about how to structure data models. Other WGs in the IETF areas or other SDOs will continue to build on this work and extend the data models according to their needs. Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, October 05, 2010 7:07 PM > To: Jon Saperia > Cc: netmod@ietf.org > Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE:=20 > [Isms] [OPS-AREA] status and future of the isms working group) >=20 > On Tue, Oct 05, 2010 at 05:30:32PM +0200, Jon Saperia wrote: > =20 > > Many objects that are used in SNMP today were developed=20 > outside of the=20 > > SNMP WG. The larger community now has to look at the body of work=20 > > completed in NETCONF/YANG and see how they might want to define=20 > > standard configuration objects for their respective areas. >=20 > Nope, the NETCONF/NETMOD framework still lack a common=20 > understanding how to structure data models (missing basic=20 > infrastructure) and we do not really know how to deal with=20 > the distinction and modeling of the relationship between=20 > operational state and configuration state. This is why NETMOD=20 > was supposed to recharter to put the core data models in=20 > place. At least that was my understanding at the last IETF. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From randy_presuhn@mindspring.com Tue Oct 5 10:27:23 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998693A6F5A for ; Tue, 5 Oct 2010 10:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkeYm9FHX6cZ for ; Tue, 5 Oct 2010 10:27:22 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id B9D393A6CE1 for ; Tue, 5 Oct 2010 10:27:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Vz3fCbqLfl4zsSxm7od2K/Lu2eeEbuzeOnrRvA+SMSg3hNYCErJceNPTR2Z1tYZd; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.214] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P3BJM-0007E1-LR for netmod@ietf.org; Tue, 05 Oct 2010 13:28:20 -0400 Message-ID: <002d01cb64b2$e4bdee80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20101005170705.GB48717@elstar.local> Date: Tue, 5 Oct 2010 10:29:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe7425ed75f566b89f4176926c36e3fe58350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.214 Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:27:23 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Jon Saperia" > Cc: > Sent: Tuesday, October 05, 2010 10:07 AM > Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) ... > Nope, the NETCONF/NETMOD framework still lack a common understanding > how to structure data models (missing basic infrastructure) and we do > not really know how to deal with the distinction and modeling of the > relationship between operational state and configuration state. ... Total agreement. This need for a "meta-model" (for lack of a better term) was a recurring concern when we were putting together the data modeling requirements i-d way back when. However, I fear that such a thing is unlikely to come to be unless there has been a major cultural shift in the IETF. The netconf pendulum has swung in the direction of encouraging maximum vendor differentiation, to the point of not even nailing down such fundamentals. Any effort to nail things down now will probably meet with fierce resistance from those whose deployed models don't map well to whatever the meta- model ends up being. And, for better or worse, running code trumps theory. Randy Randy From biermana@Brocade.com Tue Oct 5 10:33:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D6B3A6C9D for ; Tue, 5 Oct 2010 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWBDIUxH0MjW for ; Tue, 5 Oct 2010 10:33:19 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 47FA33A6F91 for ; Tue, 5 Oct 2010 10:33:19 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o95HKCHU015164; Tue, 5 Oct 2010 10:34:14 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id rr3jkr61y-9 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 05 Oct 2010 10:34:13 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 5 Oct 2010 10:38:08 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 5 Oct 2010 10:34:11 -0700 From: Andy Bierman To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder , Jon Saperia Date: Tue, 5 Oct 2010 10:34:09 -0700 Thread-Topic: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) Thread-Index: Actkr9JqNL8gio2CR9O0nk/3FT8LSwAAUK5QAABZsTA= Message-ID: References: <20101005170705.GB48717@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-05_06:2010-10-05, 2010-10-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010050118 Cc: "netmod@ietf.org" Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-AREA] status and future of the isms working group) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:33:21 -0000 I do not agree at all that the lack of standard data models for configurati= on has anything at all to do with the clarification of corner-case operational= data, such as the duplex-mode =3D 'auto' example that has been used many times. Plain old config vs. plain old state data is just not a problem. The lack of 3 things that are so obvious they should not need mentioning, but here they are again (since repetition is the key to learning ;-) * system group * interface table * ENTITY-MIB replacement Some vendors will insist that their own proprietary versions are good enoug= h. I think that is the real problem -- there are no vendors motivated to work on a standard solution for these infrastructure data models (my employer in= cluded). Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Romascanu, Dan (Dan) Sent: Tuesday, October 05, 2010 10:22 AM To: Juergen Schoenwaelder; Jon Saperia Cc: netmod@ietf.org Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms] [OPS-A= REA] status and future of the isms working group) The re-chartering is on the table of the IESG. I agree with Juergen here, I think that the NETMOD team should do one more step in creating a small base of core YANG modules that would both provide basic infrastructure objects and a small set of examples about how to structure data models. Other WGs in the IETF areas or other SDOs will continue to build on this work and extend the data models according to their needs. Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, October 05, 2010 7:07 PM > To: Jon Saperia > Cc: netmod@ietf.org > Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE:=20 > [Isms] [OPS-AREA] status and future of the isms working group) >=20 > On Tue, Oct 05, 2010 at 05:30:32PM +0200, Jon Saperia wrote: > =20 > > Many objects that are used in SNMP today were developed=20 > outside of the=20 > > SNMP WG. The larger community now has to look at the body of work=20 > > completed in NETCONF/YANG and see how they might want to define=20 > > standard configuration objects for their respective areas. >=20 > Nope, the NETCONF/NETMOD framework still lack a common=20 > understanding how to structure data models (missing basic=20 > infrastructure) and we do not really know how to deal with=20 > the distinction and modeling of the relationship between=20 > operational state and configuration state. This is why NETMOD=20 > was supposed to recharter to put the core data models in=20 > place. At least that was my understanding at the last IETF. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From dromasca@avaya.com Tue Oct 5 10:39:17 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8853A6FC5 for ; Tue, 5 Oct 2010 10:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKfNqHWQwtSd for ; Tue, 5 Oct 2010 10:39:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B0D6F3A6FBD for ; Tue, 5 Oct 2010 10:39:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,285,1283745600"; d="scan'208";a="210611774" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Oct 2010 13:39:59 -0400 X-IronPort-AV: E=Sophos;i="4.57,285,1283745600"; d="scan'208";a="519467664" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Oct 2010 13:39:58 -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: Tue, 5 Oct 2010 19:39:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] True for NETCONF/YANG as well (was: RE: [Isms][OPS-AREA] status and future of the isms working group) Thread-Index: Actkr9JqNL8gio2CR9O0nk/3FT8LSwAAUK5QAABZsTAAAFQ/8A== References: <20101005170705.GB48717@elstar.local> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Juergen Schoenwaelder" , "Jon Saperia" Cc: netmod@ietf.org Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE: [Isms][OPS-AREA] status and future of the isms working group) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:39:17 -0000 Those three modules (plus minus one) are the core of the rechartering scope.=20 But can you write an interface table without clarifying how admin/oper status is modeled? This is not a corner issue imho.=20 Dan =20 > -----Original Message----- > From: Andy Bierman [mailto:biermana@Brocade.com]=20 > Sent: Tuesday, October 05, 2010 7:34 PM > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; Jon Saperia > Cc: netmod@ietf.org > Subject: RE: [netmod] True for NETCONF/YANG as well (was: RE:=20 > [Isms][OPS-AREA] status and future of the isms working group) >=20 > I do not agree at all that the lack of standard data models=20 > for configuration has anything at all to do with the=20 > clarification of corner-case operational data, such as the=20 > duplex-mode =3D 'auto' example that has been used many times. > Plain old config vs. plain old state data is just not a problem. >=20 > The lack of 3 things that are so obvious they should not need=20 > mentioning, but here they are again (since repetition is the=20 > key to learning ;-) > * system group > * interface table > * ENTITY-MIB replacement >=20 > Some vendors will insist that their own proprietary versions=20 > are good enough. > I think that is the real problem -- there are no vendors=20 > motivated to work on a standard solution for these=20 > infrastructure data models (my employer included). >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, October 05, 2010 10:22 AM > To: Juergen Schoenwaelder; Jon Saperia > Cc: netmod@ietf.org > Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE:=20 > [Isms] [OPS-AREA] status and future of the isms working group) >=20 > The re-chartering is on the table of the IESG. I agree with=20 > Juergen here, I think that the NETMOD team should do one more=20 > step in creating a small base of core YANG modules that would=20 > both provide basic infrastructure objects and a small set of=20 > examples about how to structure data models. Other WGs in the=20 > IETF areas or other SDOs will continue to build on this work=20 > and extend the data models according to their needs. >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: netmod-bounces@ietf.org > > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, October 05, 2010 7:07 PM > > To: Jon Saperia > > Cc: netmod@ietf.org > > Subject: Re: [netmod] True for NETCONF/YANG as well (was: RE:=20 > > [Isms] [OPS-AREA] status and future of the isms working group) > >=20 > > On Tue, Oct 05, 2010 at 05:30:32PM +0200, Jon Saperia wrote: > > =20 > > > Many objects that are used in SNMP today were developed > > outside of the > > > SNMP WG. The larger community now has to look at the=20 > body of work=20 > > > completed in NETCONF/YANG and see how they might want to define=20 > > > standard configuration objects for their respective areas. > >=20 > > Nope, the NETCONF/NETMOD framework still lack a common=20 > understanding=20 > > how to structure data models (missing basic > > infrastructure) and we do not really know how to deal with the=20 > > distinction and modeling of the relationship between=20 > operational state=20 > > and configuration state. This is why NETMOD was supposed to=20 > recharter=20 > > to put the core data models in place. At least that was my=20 > > understanding at the last IETF. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From ietf@andybierman.com Tue Oct 5 10:50:22 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0163A6FC1 for ; Tue, 5 Oct 2010 10:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXApRdLeEFdz for ; Tue, 5 Oct 2010 10:50:19 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by core3.amsl.com (Postfix) with ESMTP id 6E9573A7006 for ; Tue, 5 Oct 2010 10:50:08 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.149.5] (may be forged)) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o95Hp176031083 for ; Tue, 5 Oct 2010 13:51:02 -0400 Authentication-Results: cm-omr7 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.126.165.113] ([173.126.165.113:52598] helo=[173.126.165.113]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 29/37-14526-2856BAC4; Tue, 05 Oct 2010 13:51:01 -0400 To: "=?utf-8?B?Um9tYXNjYW51LCBEYW4gKERhbik=?=" , "=?utf-8?B?QW5keSBCaWVybWFu?=" , "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" , "=?utf-8?B?Sm9uIFNhcGVyaWE=?=" Message-ID: <29.37.14526.2856BAC4@cm-omr7> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 05 Oct 2010 10:51:14 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1286301074711" Cc: netmod@ietf.org Subject: Re: [netmod] =?utf-8?q?True_for_NETCONF/YANG_as_well_=28was=3A_RE=3A?= =?utf-8?q?=09=5BIsms=5D=5BOPS-AREA=5D=09status_and_future_of_the_i?= =?utf-8?q?sms_working_group=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:50:22 -0000 ------=_Part_1_1286301074711 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2UgaGF2ZSB0aGUgZGVzY3JpcHRpb24gc3RtdCBmb3IgY2xhcmlmeWluZyB0aGF0IG9wZXJzdGF0 dXMgaXMgcmVsYXRlZCB0byBhZG1pbnN0YXR1cy4gIEFkZGluZyBhIG1hY2hpbmUgcmVhZGFibGUg c3RtdCBmb3IgdGhhdCB3aWxsIGhhdmUgbm8gaW1wYWN0IG9uIHRoZSBkZXBsb3ltZW50IG9mIHN0 YW5kYXJkIGNvbnRlbnQuICBSRkMgcHVibGljYXRpb24gb2Ygc3RhbmRhcmQgY29udGVudCB3aWxs IGhhdmUgYW4gaW1wYWN0LgoKQWRkaW5nIG1vcmUgcHJvdG9jb2wgYmVsbHMgYW5kIHdoaXN0bGVz IGlzIGp1c3QgYW4gZXhjdXNlIGZvciBkZWxheWluZyB0aGUgcmVhbCBkYXRhIG1vZGVsIGRlZmlu aXRpb24gd29yay4KCkFuZHkKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogIlJvbWFz Y2FudSwgRGFuIChEYW4pIiA8ZHJvbWFzY2FAYXZheWEuY29tPgpEYXRlOiBUdWUsIE9jdCA1LCAy MDEwIDEwOjM5ClN1YmplY3Q6IFtuZXRtb2RdIFRydWUgZm9yIE5FVENPTkYvWUFORyBhcyB3ZWxs ICh3YXM6IFJFOglbSXNtc11bT1BTLUFSRUFdCXN0YXR1cyBhbmQgZnV0dXJlIG9mIHRoZSBpc21z IHdvcmtpbmcgZ3JvdXApClRvOiAiQW5keSBCaWVybWFuIiA8Ymllcm1hbmFAQnJvY2FkZS5jb20+ LCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz aXR5LmRlPiwgIkpvbiBTYXBlcmlhIiA8c2FwZXJpYUBqZHNjb25zLmNvbT4KQ2M6IDxuZXRtb2RA aWV0Zi5vcmc+CgoKVGhvc2UgdGhyZWUgbW9kdWxlcyAocGx1cyBtaW51cyBvbmUpIGFyZSB0aGUg Y29yZSBvZiB0aGUgcmVjaGFydGVyaW5nCnNjb3BlLiAKCkJ1dCBjYW4geW91IHdyaXRlIGFuIGlu dGVyZmFjZSB0YWJsZSB3aXRob3V0IGNsYXJpZnlpbmcgaG93IGFkbWluL29wZXIKc3RhdHVzIGlz IG1vZGVsZWQ/IFRoaXMgaXMgbm90IGEgY29ybmVyIGlzc3VlIGltaG8uIAoKRGFuCiAKCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzpiaWVy bWFuYUBCcm9jYWRlLmNvbV0gCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAwNSwgMjAxMCA3OjM0 IFBNCj4gVG86IFJvbWFzY2FudSwgRGFuIChEYW4pOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpv biBTYXBlcmlhCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZwo+IFN1YmplY3Q6IFJFOiBbbmV0bW9kXSBU cnVlIGZvciBORVRDT05GL1lBTkcgYXMgd2VsbCAod2FzOiBSRTogCj4gW0lzbXNdW09QUy1BUkVB XSBzdGF0dXMgYW5kIGZ1dHVyZSBvZiB0aGUgaXNtcyB3b3JraW5nIGdyb3VwKQo+IAo+IEkgZG8g bm90IGFncmVlIGF0IGFsbCB0aGF0IHRoZSBsYWNrIG9mIHN0YW5kYXJkIGRhdGEgbW9kZWxzIAo+ IGZvciBjb25maWd1cmF0aW9uIGhhcyBhbnl0aGluZyBhdCBhbGwgdG8gZG8gd2l0aCB0aGUgCj4g Y2xhcmlmaWNhdGlvbiBvZiBjb3JuZXItY2FzZSBvcGVyYXRpb25hbCBkYXRhLCBzdWNoIGFzIHRo ZSAKPiBkdXBsZXgtbW9kZSA9ICdhdXRvJyBleGFtcGxlIHRoYXQgaGFzIGJlZW4gdXNlZCBtYW55 IHRpbWVzLgo+IFBsYWluIG9sZCBjb25maWcgdnMuIHBsYWluIG9sZCBzdGF0ZSBkYXRhIGlzIGp1 c3Qgbm90IGEgcHJvYmxlbS4KPiAKPiBUaGUgbGFjayBvZiAzIHRoaW5ncyB0aGF0IGFyZSBzbyBv YnZpb3VzIHRoZXkgc2hvdWxkIG5vdCBuZWVkIAo+IG1lbnRpb25pbmcsIGJ1dCBoZXJlIHRoZXkg YXJlIGFnYWluIChzaW5jZSByZXBldGl0aW9uIGlzIHRoZSAKPiBrZXkgdG8gbGVhcm5pbmcgOy0p Cj4gICAgKiBzeXN0ZW0gZ3JvdXAKPiAgICAqIGludGVyZmFjZSB0YWJsZQo+ICAgICogRU5USVRZ LU1JQiByZXBsYWNlbWVudAo+IAo+IFNvbWUgdmVuZG9ycyB3aWxsIGluc2lzdCB0aGF0IHRoZWly IG93biBwcm9wcmlldGFyeSB2ZXJzaW9ucyAKPiBhcmUgZ29vZCBlbm91Z2guCj4gSSB0aGluayB0 aGF0IGlzIHRoZSByZWFsIHByb2JsZW0gLS0gdGhlcmUgYXJlIG5vIHZlbmRvcnMgCj4gbW90aXZh dGVkIHRvIHdvcmsgb24gYSBzdGFuZGFyZCBzb2x1dGlvbiBmb3IgdGhlc2UgCj4gaW5mcmFzdHJ1 Y3R1cmUgZGF0YSBtb2RlbHMgKG15IGVtcGxveWVyIGluY2x1ZGVkKS4KPiAKPiAKPiBBbmR5Cj4g Cj4gCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZyAKPiBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg Um9tYXNjYW51LCBEYW4gKERhbikKPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA1LCAyMDEwIDEw OjIyIEFNCj4gVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgSm9uIFNhcGVyaWEKPiBDYzogbmV0 bW9kQGlldGYub3JnCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFRydWUgZm9yIE5FVENPTkYvWUFO RyBhcyB3ZWxsICh3YXM6IFJFOiAKPiBbSXNtc10gW09QUy1BUkVBXSBzdGF0dXMgYW5kIGZ1dHVy ZSBvZiB0aGUgaXNtcyB3b3JraW5nIGdyb3VwKQo+IAo+IFRoZSByZS1jaGFydGVyaW5nIGlzIG9u IHRoZSB0YWJsZSBvZiB0aGUgSUVTRy4gSSBhZ3JlZSB3aXRoIAo+IEp1ZXJnZW4gaGVyZSwgSSB0 aGluayB0aGF0IHRoZSBORVRNT0QgdGVhbSBzaG91bGQgZG8gb25lIG1vcmUgCj4gc3RlcCBpbiBj cmVhdGluZyBhIHNtYWxsIGJhc2Ugb2YgY29yZSBZQU5HIG1vZHVsZXMgdGhhdCB3b3VsZCAKPiBi b3RoIHByb3ZpZGUgYmFzaWMgaW5mcmFzdHJ1Y3R1cmUgb2JqZWN0cyBhbmQgYSBzbWFsbCBzZXQg b2YgCj4gZXhhbXBsZXMgYWJvdXQgaG93IHRvIHN0cnVjdHVyZSBkYXRhIG1vZGVscy4gT3RoZXIg V0dzIGluIHRoZSAKPiBJRVRGIGFyZWFzIG9yIG90aGVyIFNET3Mgd2lsbCBjb250aW51ZSB0byBi dWlsZCBvbiB0aGlzIHdvcmsgCj4gYW5kIGV4dGVuZCB0aGUgZGF0YSBtb2RlbHMgYWNjb3JkaW5n IHRvIHRoZWlyIG5lZWRzLgo+IAo+IERhbgo+ICAgCj4gCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQo+ID4gRnJvbTogbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcKPiA+IFttYWlsdG86bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIK PiA+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDUsIDIwMTAgNzowNyBQTQo+ID4gVG86IEpvbiBT YXBlcmlhCj4gPiBDYzogbmV0bW9kQGlldGYub3JnCj4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0g VHJ1ZSBmb3IgTkVUQ09ORi9ZQU5HIGFzIHdlbGwgKHdhczogUkU6IAo+ID4gW0lzbXNdIFtPUFMt QVJFQV0gc3RhdHVzIGFuZCBmdXR1cmUgb2YgdGhlIGlzbXMgd29ya2luZyBncm91cCkKPiA+IAo+ ID4gT24gVHVlLCBPY3QgMDUsIDIwMTAgYXQgMDU6MzA6MzJQTSArMDIwMCwgSm9uIFNhcGVyaWEg d3JvdGU6Cj4gPiAgCj4gPiA+IE1hbnkgb2JqZWN0cyB0aGF0IGFyZSB1c2VkIGluIFNOTVAgdG9k YXkgd2VyZSBkZXZlbG9wZWQKPiA+IG91dHNpZGUgb2YgdGhlCj4gPiA+IFNOTVAgV0cuICBUaGUg bGFyZ2VyIGNvbW11bml0eSBub3cgaGFzIHRvIGxvb2sgYXQgdGhlIAo+IGJvZHkgb2Ygd29yayAK PiA+ID4gY29tcGxldGVkIGluIE5FVENPTkYvWUFORyBhbmQgc2VlIGhvdyB0aGV5IG1pZ2h0IHdh bnQgdG8gZGVmaW5lIAo+ID4gPiBzdGFuZGFyZCBjb25maWd1cmF0aW9uIG9iamVjdHMgZm9yIHRo ZWlyIHJlc3BlY3RpdmUgYXJlYXMuCj4gPiAKPiA+IE5vcGUsIHRoZSBORVRDT05GL05FVE1PRCBm cmFtZXdvcmsgc3RpbGwgbGFjayBhIGNvbW1vbiAKPiB1bmRlcnN0YW5kaW5nIAo+ID4gaG93IHRv IHN0cnVjdHVyZSBkYXRhIG1vZGVscyAobWlzc2luZyBiYXNpYwo+ID4gaW5mcmFzdHJ1Y3R1cmUp IGFuZCB3ZSBkbyBub3QgcmVhbGx5IGtub3cgaG93IHRvIGRlYWwgd2l0aCB0aGUgCj4gPiBkaXN0 aW5jdGlvbiBhbmQgbW9kZWxpbmcgb2YgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIAo+IG9wZXJh dGlvbmFsIHN0YXRlIAo+ID4gYW5kIGNvbmZpZ3VyYXRpb24gc3RhdGUuIFRoaXMgaXMgd2h5IE5F VE1PRCB3YXMgc3VwcG9zZWQgdG8gCj4gcmVjaGFydGVyIAo+ID4gdG8gcHV0IHRoZSBjb3JlIGRh dGEgbW9kZWxzIGluIHBsYWNlLiBBdCBsZWFzdCB0aGF0IHdhcyBteSAKPiA+IHVuZGVyc3RhbmRp bmcgYXQgdGhlIGxhc3QgSUVURi4KPiA+IAo+ID4gL2pzCj4gPiAKPiA+IC0tIAo+ID4gSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgK PiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkg QnJlbWVuLCBHZXJtYW55Cj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gPiBuZXRt b2RAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kCj4gPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+IApfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAoK ------=_Part_1_1286301074711 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2UgaGF2ZSB0aGUgZGVzY3JpcHRpb24gc3RtdCBmb3IgY2xhcmlmeWluZyB0aGF0IG9wZXJzdGF0 dXMgaXMgcmVsYXRlZCB0byBhZG1pbnN0YXR1cy4gJm5ic3A7QWRkaW5nIGEgbWFjaGluZSByZWFk YWJsZSBzdG10IGZvciB0aGF0IHdpbGwgaGF2ZSBubyBpbXBhY3Qgb24gdGhlIGRlcGxveW1lbnQg b2Ygc3RhbmRhcmQgY29udGVudC4gJm5ic3A7UkZDIHB1YmxpY2F0aW9uIG9mIHN0YW5kYXJkIGNv bnRlbnQgd2lsbCBoYXZlIGFuIGltcGFjdC48YnI+PGJyPkFkZGluZyBtb3JlIHByb3RvY29sIGJl bGxzIGFuZCB3aGlzdGxlcyBpcyBqdXN0IGFuIGV4Y3VzZSBmb3IgZGVsYXlpbmcgdGhlIHJlYWwg ZGF0YSBtb2RlbCBkZWZpbml0aW9uIHdvcmsuPGJyPjxicj5BbmR5PGJyPjxicj4tLS0tLSBSZXBs eSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZxdW90O1JvbWFzY2FudSwgRGFuIChEYW4pJnF1b3Q7 ICZsdDtkcm9tYXNjYUBhdmF5YS5jb20mZ3Q7PGJyPkRhdGU6IFR1ZSwgT2N0IDUsIDIwMTAgMTA6 Mzk8YnI+U3ViamVjdDogW25ldG1vZF0gVHJ1ZSBmb3IgTkVUQ09ORi9ZQU5HIGFzIHdlbGwgKHdh czogUkU6CVtJc21zXVtPUFMtQVJFQV0Jc3RhdHVzIGFuZCBmdXR1cmUgb2YgdGhlIGlzbXMgd29y a2luZyBncm91cCk8YnI+VG86ICZxdW90O0FuZHkgQmllcm1hbiZxdW90OyAmbHQ7Ymllcm1hbmFA QnJvY2FkZS5jb20mZ3Q7LCAmcXVvdDtKdWVyZ2VuIFNjaG9lbndhZWxkZXImcXVvdDsgJmx0O2ou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDssICZxdW90O0pvbiBTYXBlcmlh JnF1b3Q7ICZsdDtzYXBlcmlhQGpkc2NvbnMuY29tJmd0Ozxicj5DYzogJmx0O25ldG1vZEBpZXRm Lm9yZyZndDs8YnI+PGJyPjxicj5UaG9zZSB0aHJlZSBtb2R1bGVzIChwbHVzIG1pbnVzIG9uZSkg YXJlIHRoZSBjb3JlIG9mIHRoZSByZWNoYXJ0ZXJpbmc8YnI+c2NvcGUuIDxicj48YnI+QnV0IGNh biB5b3Ugd3JpdGUgYW4gaW50ZXJmYWNlIHRhYmxlIHdpdGhvdXQgY2xhcmlmeWluZyBob3cgYWRt aW4vb3Blcjxicj5zdGF0dXMgaXMgbW9kZWxlZD8gVGhpcyBpcyBub3QgYSBjb3JuZXIgaXNzdWUg aW1oby4gPGJyPjxicj5EYW48YnI+IDxicj48YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4mZ3Q7IEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmJpZXJtYW5hQEJyb2NhZGUu Y29tXSA8YnI+Jmd0OyBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA1LCAyMDEwIDc6MzQgUE08YnI+ Jmd0OyBUbzogUm9tYXNjYW51LCBEYW4gKERhbik7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgSm9u IFNhcGVyaWE8YnI+Jmd0OyBDYzogbmV0bW9kQGlldGYub3JnPGJyPiZndDsgU3ViamVjdDogUkU6 IFtuZXRtb2RdIFRydWUgZm9yIE5FVENPTkYvWUFORyBhcyB3ZWxsICh3YXM6IFJFOiA8YnI+Jmd0 OyBbSXNtc11bT1BTLUFSRUFdIHN0YXR1cyBhbmQgZnV0dXJlIG9mIHRoZSBpc21zIHdvcmtpbmcg Z3JvdXApPGJyPiZndDsgPGJyPiZndDsgSSBkbyBub3QgYWdyZWUgYXQgYWxsIHRoYXQgdGhlIGxh Y2sgb2Ygc3RhbmRhcmQgZGF0YSBtb2RlbHMgPGJyPiZndDsgZm9yIGNvbmZpZ3VyYXRpb24gaGFz IGFueXRoaW5nIGF0IGFsbCB0byBkbyB3aXRoIHRoZSA8YnI+Jmd0OyBjbGFyaWZpY2F0aW9uIG9m IGNvcm5lci1jYXNlIG9wZXJhdGlvbmFsIGRhdGEsIHN1Y2ggYXMgdGhlIDxicj4mZ3Q7IGR1cGxl eC1tb2RlID0gJiMzOTthdXRvJiMzOTsgZXhhbXBsZSB0aGF0IGhhcyBiZWVuIHVzZWQgbWFueSB0 aW1lcy48YnI+Jmd0OyBQbGFpbiBvbGQgY29uZmlnIHZzLiBwbGFpbiBvbGQgc3RhdGUgZGF0YSBp cyBqdXN0IG5vdCBhIHByb2JsZW0uPGJyPiZndDsgPGJyPiZndDsgVGhlIGxhY2sgb2YgMyB0aGlu Z3MgdGhhdCBhcmUgc28gb2J2aW91cyB0aGV5IHNob3VsZCBub3QgbmVlZCA8YnI+Jmd0OyBtZW50 aW9uaW5nLCBidXQgaGVyZSB0aGV5IGFyZSBhZ2FpbiAoc2luY2UgcmVwZXRpdGlvbiBpcyB0aGUg PGJyPiZndDsga2V5IHRvIGxlYXJuaW5nIDstKTxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsqIHN5c3Rl bSBncm91cDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsqIGludGVyZmFjZSB0YWJsZTxicj4mZ3Q7ICZu YnNwOyAmbmJzcDsqIEVOVElUWS1NSUIgcmVwbGFjZW1lbnQ8YnI+Jmd0OyA8YnI+Jmd0OyBTb21l IHZlbmRvcnMgd2lsbCBpbnNpc3QgdGhhdCB0aGVpciBvd24gcHJvcHJpZXRhcnkgdmVyc2lvbnMg PGJyPiZndDsgYXJlIGdvb2QgZW5vdWdoLjxicj4mZ3Q7IEkgdGhpbmsgdGhhdCBpcyB0aGUgcmVh bCBwcm9ibGVtIC0tIHRoZXJlIGFyZSBubyB2ZW5kb3JzIDxicj4mZ3Q7IG1vdGl2YXRlZCB0byB3 b3JrIG9uIGEgc3RhbmRhcmQgc29sdXRpb24gZm9yIHRoZXNlIDxicj4mZ3Q7IGluZnJhc3RydWN0 dXJlIGRhdGEgbW9kZWxzIChteSBlbXBsb3llciBpbmNsdWRlZCkuPGJyPiZndDsgPGJyPiZndDsg PGJyPiZndDsgQW5keTxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPiZndDsgRnJvbTogbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgPGJyPiZndDsg W21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFzY2FudSwg RGFuIChEYW4pPGJyPiZndDsgU2VudDogVHVlc2RheSwgT2N0b2JlciAwNSwgMjAxMCAxMDoyMiBB TTxicj4mZ3Q7IFRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpvbiBTYXBlcmlhPGJyPiZndDsg Q2M6IG5ldG1vZEBpZXRmLm9yZzxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBUcnVlIGZv ciBORVRDT05GL1lBTkcgYXMgd2VsbCAod2FzOiBSRTogPGJyPiZndDsgW0lzbXNdIFtPUFMtQVJF QV0gc3RhdHVzIGFuZCBmdXR1cmUgb2YgdGhlIGlzbXMgd29ya2luZyBncm91cCk8YnI+Jmd0OyA8 YnI+Jmd0OyBUaGUgcmUtY2hhcnRlcmluZyBpcyBvbiB0aGUgdGFibGUgb2YgdGhlIElFU0cuIEkg YWdyZWUgd2l0aCA8YnI+Jmd0OyBKdWVyZ2VuIGhlcmUsIEkgdGhpbmsgdGhhdCB0aGUgTkVUTU9E IHRlYW0gc2hvdWxkIGRvIG9uZSBtb3JlIDxicj4mZ3Q7IHN0ZXAgaW4gY3JlYXRpbmcgYSBzbWFs bCBiYXNlIG9mIGNvcmUgWUFORyBtb2R1bGVzIHRoYXQgd291bGQgPGJyPiZndDsgYm90aCBwcm92 aWRlIGJhc2ljIGluZnJhc3RydWN0dXJlIG9iamVjdHMgYW5kIGEgc21hbGwgc2V0IG9mIDxicj4m Z3Q7IGV4YW1wbGVzIGFib3V0IGhvdyB0byBzdHJ1Y3R1cmUgZGF0YSBtb2RlbHMuIE90aGVyIFdH cyBpbiB0aGUgPGJyPiZndDsgSUVURiBhcmVhcyBvciBvdGhlciBTRE9zIHdpbGwgY29udGludWUg dG8gYnVpbGQgb24gdGhpcyB3b3JrIDxicj4mZ3Q7IGFuZCBleHRlbmQgdGhlIGRhdGEgbW9kZWxz IGFjY29yZGluZyB0byB0aGVpciBuZWVkcy48YnI+Jmd0OyA8YnI+Jmd0OyBEYW48YnI+Jmd0OyAm bmJzcDsgPGJyPiZndDsgPGJyPiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4mZ3Q7ICZndDsgRnJvbTogbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8YnI+Jmd0OyAmZ3Q7IFtt YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWVyZ2VuIFNjaG9l bndhZWxkZXI8YnI+Jmd0OyAmZ3Q7IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDUsIDIwMTAgNzow NyBQTTxicj4mZ3Q7ICZndDsgVG86IEpvbiBTYXBlcmlhPGJyPiZndDsgJmd0OyBDYzogbmV0bW9k QGlldGYub3JnPGJyPiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW25ldG1vZF0gVHJ1ZSBmb3IgTkVU Q09ORi9ZQU5HIGFzIHdlbGwgKHdhczogUkU6IDxicj4mZ3Q7ICZndDsgW0lzbXNdIFtPUFMtQVJF QV0gc3RhdHVzIGFuZCBmdXR1cmUgb2YgdGhlIGlzbXMgd29ya2luZyBncm91cCk8YnI+Jmd0OyAm Z3Q7IDxicj4mZ3Q7ICZndDsgT24gVHVlLCBPY3QgMDUsIDIwMTAgYXQgMDU6MzA6MzJQTSArMDIw MCwgSm9uIFNhcGVyaWEgd3JvdGU6PGJyPiZndDsgJmd0OyAmbmJzcDs8YnI+Jmd0OyAmZ3Q7ICZn dDsgTWFueSBvYmplY3RzIHRoYXQgYXJlIHVzZWQgaW4gU05NUCB0b2RheSB3ZXJlIGRldmVsb3Bl ZDxicj4mZ3Q7ICZndDsgb3V0c2lkZSBvZiB0aGU8YnI+Jmd0OyAmZ3Q7ICZndDsgU05NUCBXRy4g Jm5ic3A7VGhlIGxhcmdlciBjb21tdW5pdHkgbm93IGhhcyB0byBsb29rIGF0IHRoZSA8YnI+Jmd0 OyBib2R5IG9mIHdvcmsgPGJyPiZndDsgJmd0OyAmZ3Q7IGNvbXBsZXRlZCBpbiBORVRDT05GL1lB TkcgYW5kIHNlZSBob3cgdGhleSBtaWdodCB3YW50IHRvIGRlZmluZSA8YnI+Jmd0OyAmZ3Q7ICZn dDsgc3RhbmRhcmQgY29uZmlndXJhdGlvbiBvYmplY3RzIGZvciB0aGVpciByZXNwZWN0aXZlIGFy ZWFzLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBOb3BlLCB0aGUgTkVUQ09ORi9ORVRNT0Qg ZnJhbWV3b3JrIHN0aWxsIGxhY2sgYSBjb21tb24gPGJyPiZndDsgdW5kZXJzdGFuZGluZyA8YnI+ Jmd0OyAmZ3Q7IGhvdyB0byBzdHJ1Y3R1cmUgZGF0YSBtb2RlbHMgKG1pc3NpbmcgYmFzaWM8YnI+ Jmd0OyAmZ3Q7IGluZnJhc3RydWN0dXJlKSBhbmQgd2UgZG8gbm90IHJlYWxseSBrbm93IGhvdyB0 byBkZWFsIHdpdGggdGhlIDxicj4mZ3Q7ICZndDsgZGlzdGluY3Rpb24gYW5kIG1vZGVsaW5nIG9m IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiA8YnI+Jmd0OyBvcGVyYXRpb25hbCBzdGF0ZSA8YnI+ Jmd0OyAmZ3Q7IGFuZCBjb25maWd1cmF0aW9uIHN0YXRlLiBUaGlzIGlzIHdoeSBORVRNT0Qgd2Fz IHN1cHBvc2VkIHRvIDxicj4mZ3Q7IHJlY2hhcnRlciA8YnI+Jmd0OyAmZ3Q7IHRvIHB1dCB0aGUg Y29yZSBkYXRhIG1vZGVscyBpbiBwbGFjZS4gQXQgbGVhc3QgdGhhdCB3YXMgbXkgPGJyPiZndDsg Jmd0OyB1bmRlcnN0YW5kaW5nIGF0IHRoZSBsYXN0IElFVEYuPGJyPiZndDsgJmd0OyA8YnI+Jmd0 OyAmZ3Q7IC9qczxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAtLSA8YnI+Jmd0OyAmZ3Q7IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4mZ3Q7ICZndDsgUGhvbmU6ICs0OSA0MjEg MjAwIDM1ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBSaW5nIDEsIDI4NzU5 IEJyZW1lbiwgR2VybWFueTxicj4mZ3Q7ICZndDsgRmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEw MyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuamFj b2JzLXVuaXZlcnNpdHkuZGUvIj5odHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4m Z3Q7PGJyPiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4mZ3Q7ICZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgbmV0 bW9kQGlldGYub3JnPGJyPiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2Q8L2E+PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8 YnI+Jmd0OyBuZXRtb2RAaWV0Zi5vcmc8YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPiZndDsgPGJyPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+bmV0bW9k QGlldGYub3JnPGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwv YT48YnI+PGJyPjxicj48YnI+ ------=_Part_1_1286301074711-- From david.kessens@nsn.com Wed Oct 6 07:34:20 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1863A6F10 for ; Wed, 6 Oct 2010 07:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SawrrzHlpfDz for ; Wed, 6 Oct 2010 07:34:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id BB9743A6FE1 for ; Wed, 6 Oct 2010 07:34:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o96EZ8TZ002975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2010 16:35:08 +0200 Received: from localhost.localdomain ([10.138.51.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o96EZ5Ze006612; Wed, 6 Oct 2010 16:35:07 +0200 Received: from localhost.localdomain (david [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id o96EYxLF009857; Wed, 6 Oct 2010 07:35:06 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id o95Mcv0u007698; Tue, 5 Oct 2010 15:38:57 -0700 Date: Tue, 5 Oct 2010 15:38:57 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20101005223856.GB6755@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf-chairs@tools.ietf.org Subject: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 14:34:20 -0000 Working Group, As agreed during our last working group session in Maastricht, a new proposed charter for the netmod working group would be formulated to be discussed on the mailing list. Please see below for the current version of the proposed charter. This is not a formal Last Call yet, we would first like to see a bit more discussion on the list whether the current proposal is at least somewhat in line with the current thinking of most participants. We would especially welcome some more input on making the individual work items a bit more specific on what should be included/excluded in the various proposed core models. At the same time, we do want to converge quickly to a new charter as our Area Director has made it clear that he would like to have a new charter in place before the next IETF meeting. Please let us know what you think about the proposal and whether there are any specific issues that need to be addressed before we move to a formal Last Call. In addition, we would very much like to hear commitments from volunteers who are willing to do actual work on the proposed charter items. Obviously, the best way to show us such a commitment is by submitting a first draft! Thanks! David & David --- NETCONF Data Modeling Language (netmod) ----------------------------- Last Modified: 2010-10-05 Current Status: Active Working Group Chairs: David Partain David Kessens Area Director: Dan Romascanu Mailing List Address: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will initially work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts. 4. SMIv2 translation to YANG The NETMOD Working Group will not work on another version of YANG. It will also not serve as a review team for YANG modules developed by other working groups. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Oct 2010 Submission of individual draft(s) of System data model draft Oct 2010 Submission of individual draft(s) of Interface data model Oct 2010 Submission of individual draft(s) of Routing data model Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG Dec 2010 Submit first working group draft of System data model draft Dec 2010 Submit first working group draft of Interface data model Dec 2010 Submit first working group draft of Routing data model Dec 2010 Submit first working group draft of SMIv2 translation to YANG Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2011 Submit System data model to the IESG (proposed standard) Aug 2011 Submit Interface data model to the IESG (proposed standard) Aug 2011 Submit Routing data model to the IESG (proposed standard) ---- From j.schoenwaelder@jacobs-university.de Wed Oct 6 08:21:17 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634F93A7090 for ; Wed, 6 Oct 2010 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtbNxjRiWU87 for ; Wed, 6 Oct 2010 08:21:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9F1573A6F93 for ; Wed, 6 Oct 2010 08:21:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DE2CC0095; Wed, 6 Oct 2010 17:22:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Lqvaw5C3TmMF; Wed, 6 Oct 2010 17:22:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7A42C0048; Wed, 6 Oct 2010 17:22:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2DE251515A17; Wed, 6 Oct 2010 17:21:37 +0200 (CEST) Date: Wed, 6 Oct 2010 17:21:37 +0200 From: Juergen Schoenwaelder To: David Kessens Message-ID: <20101006152137.GB54890@elstar.local> Mail-Followup-To: David Kessens , "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" References: <20101005223856.GB6755@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101005223856.GB6755@nsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:21:17 -0000 On Wed, Oct 06, 2010 at 12:38:57AM +0200, David Kessens wrote: > In addition, we would very much like to hear commitments from volunteers who > are willing to do actual work on the proposed charter items. Obviously, the > best way to show us such a commitment is by submitting a first draft! Concerning the SMIv2 to YANG translation, I have not updated the meanwhile expired ID, but instead I have rewritten the implementation that is part of libsmi. I am not sure whether I manage to update the ID before the cutoff, but I do have issues to discuss, most importantly whether we should make to 'config true' at all. Doing so has a number of problems because of the unclear delineation of config from operational state in the SNMP world and the lack of a generic NETCONF operations for modifying operational state. Bottom line: there is some progress on this workitem but currently more running code than written words. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From biermana@Brocade.com Wed Oct 6 09:28:34 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194373A6F95 for ; Wed, 6 Oct 2010 09:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25gX4q9oMwnf for ; Wed, 6 Oct 2010 09:28:33 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id E0CA33A6F7A for ; Wed, 6 Oct 2010 09:28:32 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o96GRRFf026876; Wed, 6 Oct 2010 09:29:32 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id rrrabg5qc-7 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Oct 2010 09:29:32 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 09:33:22 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 6 Oct 2010 09:29:26 -0700 From: Andy Bierman To: Juergen Schoenwaelder , "David Kessens" Date: Wed, 6 Oct 2010 09:29:25 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActlakXSwG1aJf8dTdCVM7hLhQyLsQACEEEA Message-ID: References: <20101005223856.GB6755@nsn.com> <20101006152137.GB54890@elstar.local> In-Reply-To: <20101006152137.GB54890@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-06_09:2010-10-06, 2010-10-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060085 Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:28:34 -0000 Hi, The issue of config property as boolean vs. multi-value enum was discussed = and dismissed many times. The NETMOD WG was sure the config property is a bool= ean. This is fundamental to YANG and NETCONF operation. Saying that we don't kn= ow what config is, or what state is, sends the completely wrong message to the= IETF community about the stability of NETCONF/YANG. There are some very minor (but visible) corner cases such as duplex-mode=3D= 'auto', but that does not mean config=3Dtrue/false makes NETCONF/YANG unusable or e= ven slightly broken. Not every possible data modeling behavior has a machine-readable s= tatement. Sometimes we will have to use description-stmt. In the future (2+ years) w= e should revisit YANG to see if there are more machine-readable stmts that are neede= d. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Wednesday, October 06, 2010 8:22 AM To: David Kessens Cc: netconf-chairs@tools.ietf.org; netmod@ietf.org Subject: Re: [netmod] Charter proposal for netmod wg On Wed, Oct 06, 2010 at 12:38:57AM +0200, David Kessens wrote: =20 > In addition, we would very much like to hear commitments from volunteers = who > are willing to do actual work on the proposed charter items. Obviously, t= he > best way to show us such a commitment is by submitting a first draft! Concerning the SMIv2 to YANG translation, I have not updated the meanwhile expired ID, but instead I have rewritten the implementation that is part of libsmi. I am not sure whether I manage to update the ID before the cutoff, but I do have issues to discuss, most importantly whether we should make to 'config true' at all. Doing so has a number of problems because of the unclear delineation of config from operational state in the SNMP world and the lack of a generic NETCONF operations for modifying operational state. Bottom line: there is some progress on this workitem but currently more running code than written words. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Wed Oct 6 10:34:02 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDC23A70FB for ; Wed, 6 Oct 2010 10:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKFHPerVdorE for ; Wed, 6 Oct 2010 10:34:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EF2123A7174 for ; Wed, 6 Oct 2010 10:34:00 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8C870616012; Wed, 6 Oct 2010 19:34:59 +0200 (CEST) Date: Wed, 06 Oct 2010 19:34:58 +0200 (CEST) Message-Id: <20101006.193458.169823536.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101006152137.GB54890@elstar.local> References: <20101005223856.GB6755@nsn.com> <20101006152137.GB54890@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:34:02 -0000 Juergen Schoenwaelder wrote: > On Wed, Oct 06, 2010 at 12:38:57AM +0200, David Kessens wrote: > > > In addition, we would very much like to hear commitments from volunteers who > > are willing to do actual work on the proposed charter items. Obviously, the > > best way to show us such a commitment is by submitting a first draft! > > Concerning the SMIv2 to YANG translation, I have not updated the > meanwhile expired ID, but instead I have rewritten the implementation > that is part of libsmi. I am not sure whether I manage to update the > ID before the cutoff, but I do have issues to discuss, most > importantly whether we should make to 'config true' at all. Doing so > has a number of problems because of the unclear delineation of config > from operational state in the SNMP world and the lack of a generic > NETCONF operations for modifying operational state. This is a real issue when you try to map from SMIv2 to YANG. In order to do this properly, some kind of annotation to the MIB objects is needed, so that the translation process can decide if a certain read-write or read-create object should be translated to config true or false. Because of this, I think we should stick to config false, i.e. make the resulting YANG module pure config false. > Bottom line: there is some progress on this workitem but currently > more running code than written words. Assuming this is in the libsmi svn, I'll check it out. /martin From wwwrun@rfc-editor.org Wed Oct 6 12:16:49 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2043A71E7; Wed, 6 Oct 2010 12:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwxXvHsdVE4j; Wed, 6 Oct 2010 12:16:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id DA2613A7201; Wed, 6 Oct 2010 12:16:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CB94BE0733; Wed, 6 Oct 2010 12:17:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101006191743.CB94BE0733@rfc-editor.org> Date: Wed, 6 Oct 2010 12:17:43 -0700 (PDT) X-Mailman-Approved-At: Wed, 06 Oct 2010 12:17:40 -0700 Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] RFC 6020 on YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:16:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6020 Title: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author: M. Bjorklund, Ed. Status: Standards Track Stream: IETF Date: October 2010 Mailbox: mbj@tail-f.com Pages: 173 Characters: 324178 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-yang-13.txt URL: http://www.rfc-editor.org/rfc/rfc6020.txt YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS TRACK] This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Oct 6 12:16:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EDA3A71C0; Wed, 6 Oct 2010 12:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.841 X-Spam-Level: X-Spam-Status: No, score=-101.841 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUKoKOu75XsP; Wed, 6 Oct 2010 12:16:57 -0700 (PDT) Received: from rfc-editor.org (rfcpa [64.170.98.47]) by core3.amsl.com (Postfix) with ESMTP id A0FE63A7217; Wed, 6 Oct 2010 12:16:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 83FC6E0738; Wed, 6 Oct 2010 12:17:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101006191753.83FC6E0738@rfc-editor.org> Date: Wed, 6 Oct 2010 12:17:53 -0700 (PDT) X-Mailman-Approved-At: Wed, 06 Oct 2010 12:17:40 -0700 Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] RFC 6021 on Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:16:58 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6021 Title: Common YANG Data Types Author: J. Schoenwaelder, Ed. Status: Standards Track Stream: IETF Date: October 2010 Mailbox: j.schoenwaelder@jacobs-university.de Pages: 26 Characters: 52826 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-yang-types-09.txt URL: http://www.rfc-editor.org/rfc/rfc6021.txt This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS TRACK] This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From biermana@Brocade.com Wed Oct 6 12:32:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210733A70C3 for ; Wed, 6 Oct 2010 12:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr9TSbFmom3F for ; Wed, 6 Oct 2010 12:32:34 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id DE8FF3A71B4 for ; Wed, 6 Oct 2010 12:32:33 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o96JUPtG022615; Wed, 6 Oct 2010 12:33:34 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id rrvuv03fg-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Oct 2010 12:33:33 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 12:37:26 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 6 Oct 2010 12:33:31 -0700 From: Andy Bierman To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Date: Wed, 6 Oct 2010 12:33:29 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActlfNEFI8//u+40TIapCKPb/czhSQAD4Q5w Message-ID: References: <20101005223856.GB6755@nsn.com> <20101006152137.GB54890@elstar.local> <20101006.193458.169823536.mbj@tail-f.com> In-Reply-To: <20101006.193458.169823536.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-06_10:2010-10-06, 2010-10-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060123 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:32:35 -0000 Hi, NETCONF has no support at all for read-write (as opposed to read-create). The protocol designers were well aware of this fact during development. Anything marked config=3Dfalse is not writable. NETCONF cannot support read-write, or accessible-for-notify, or not-accessi= ble. It only supports read-create (config=3Dtrue) and read-only (config=3Dfalse)= . NETCONF servers ignore not-accessible (typically used for keys) because it is meaningless in NETCONF. This shows some of the flaws in the chartering logic for this document. There seems to be some assumption that SNMP behavior is somehow going to be= mapped into NETCONF and complete SMIv2 semantics preserved. IMO, this is a low pr= iority, and any NETCONF protocol changes to support SMIv2 are probably unacceptable= . Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Martin Bjorklund Sent: Wednesday, October 06, 2010 10:35 AM To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org; netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg Juergen Schoenwaelder wrote: > On Wed, Oct 06, 2010 at 12:38:57AM +0200, David Kessens wrote: > =20 > > In addition, we would very much like to hear commitments from volunteer= s who > > are willing to do actual work on the proposed charter items. Obviously,= the > > best way to show us such a commitment is by submitting a first draft! >=20 > Concerning the SMIv2 to YANG translation, I have not updated the > meanwhile expired ID, but instead I have rewritten the implementation > that is part of libsmi. I am not sure whether I manage to update the > ID before the cutoff, but I do have issues to discuss, most > importantly whether we should make to 'config true' at all. Doing so > has a number of problems because of the unclear delineation of config > from operational state in the SNMP world and the lack of a generic > NETCONF operations for modifying operational state. This is a real issue when you try to map from SMIv2 to YANG. In order to do this properly, some kind of annotation to the MIB objects is needed, so that the translation process can decide if a certain read-write or read-create object should be translated to config true or false. Because of this, I think we should stick to config false, i.e. make the resulting YANG module pure config false. > Bottom line: there is some progress on this workitem but currently > more running code than written words. Assuming this is in the libsmi svn, I'll check it out. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From phil@juniper.net Wed Oct 6 12:45:43 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9373A700E for ; Wed, 6 Oct 2010 12:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wezdNwJWPfw for ; Wed, 6 Oct 2010 12:45:42 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 2BB753A719F for ; Wed, 6 Oct 2010 12:45:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTKzSG6GV7wS+97DTaUwd6JlC2sq/V9It@postini.com; Wed, 06 Oct 2010 12:46:43 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 12:45:58 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o96JjuU77720; Wed, 6 Oct 2010 12:45:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o96JPG51018487; Wed, 6 Oct 2010 19:25:16 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010061925.o96JPG51018487@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Wed, 6 Oct 2010 15:25:16 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:45:44 -0000 Andy Bierman writes: >NETCONF has no support at all for read-write (as opposed to read-create). >The protocol designers were well aware of this fact during development. >Anything marked config=false is not writable. Just to be clea: NETCONF can do anything it pleases, since there's no limit on data models. "config=false" is a YANG mechanism, not NETCONF. Thanks, Phil From david.partain@ericsson.com Wed Oct 6 12:53:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9953A71C8 for ; Wed, 6 Oct 2010 12:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.358 X-Spam-Level: X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THaiQOXg8gfr for ; Wed, 6 Oct 2010 12:53:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 90F073A7191 for ; Wed, 6 Oct 2010 12:53:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-2c-4cacd3e3bea6 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.8F.09806.3E3DCAC4; Wed, 6 Oct 2010 21:54:11 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Oct 2010 21:54:11 +0200 Received: from [153.88.53.172] ([153.88.53.172]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Oct 2010 21:54:10 +0200 From: David Partain Organization: Ericsson To: netmod@ietf.org Date: Wed, 6 Oct 2010 21:54:10 +0200 User-Agent: KMail/1.9.10 References: <20101006191743.CB94BE0733@rfc-editor.org> In-Reply-To: <20101006191743.CB94BE0733@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201010062154.10138.david.partain@ericsson.com> X-OriginalArrivalTime: 06 Oct 2010 19:54:11.0132 (UTC) FILETIME=[3EAB97C0:01CB6590] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] The new RFCs! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:53:12 -0000 Hello all, The day has finally arrived! On Wednesday 06 October 2010 21.17.43 rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 6020 > > Title: YANG - A Data Modeling > Language for the Network Configuration Protocol > (NETCONF) > Author: M. Bjorklund, Ed. and... On Wednesday 06 October 2010 21.17.53 rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 6021 > > Title: Common YANG Data Types > Author: J. Schoenwaelder, Ed. I'd like to thank the working group and, in particular, the editors for their tireless work. When this little adventure began, there were many who said we'd never get to this point. I'm very happy that we proved them wrong, even if it is a wee bit later than I wanted :-) We're not finished yet, but this is a very big step forward. Thanks, everyone! David From biermana@Brocade.com Wed Oct 6 13:09:17 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30643A71BC for ; Wed, 6 Oct 2010 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90LrVCEJcd0f for ; Wed, 6 Oct 2010 13:09:16 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id E3FA63A6FF3 for ; Wed, 6 Oct 2010 13:09:16 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o96K6ju2032442; Wed, 6 Oct 2010 13:10:17 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id rrwkh833q-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Oct 2010 13:10:17 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 13:14:49 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 6 Oct 2010 13:10:16 -0700 From: Andy Bierman To: Phil Shafer Date: Wed, 6 Oct 2010 13:10:15 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: Actljzg5dJoe79ZmS+y6praqc00jfQAAMLFg Message-ID: References: <201010061925.o96JPG51018487@idle.juniper.net> In-Reply-To: <201010061925.o96JPG51018487@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-06_11:2010-10-06, 2010-10-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060131 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:09:18 -0000 OK - point taken. But we are chartering the mapping of SMIv2 to YANG, not SNMP to NETCONF. YANG is very specific about how it applies to NETCONF operations. A server which advertises a YANG module (by adding ?module=3Dfoo&revisi= on=3Dbar to the namespace URI in the ) has to follow the rules specified= by YANG. We have already blurred the line between protocol and data modeling languag= e, exposing the myth that the 2 layers were ever independent, because we defin= e YANG extensions that change NETCONF protocol behavior (e.g., the extension = in 4741bis that patches in the 'select' and 'type' attributes for the = element.) YANG extensions for SMIv2 mapping to YANG which change NETCONF operation be= havior are possible, but (IMO) a bad idea. The YANG marketing blurb claimed that YANG extensions only provided 'extra' information, and did not harm basic protocol interoperability at all. An application that ignored an ext= ension could still use the 'basic' YANG definitions to utilize NETCONF. This is not the case at all for most YANG extensions, including any that wo= uld change the meaning of config-stmt. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Phil Shafer Sent: Wednesday, October 06, 2010 12:25 PM To: Andy Bierman Cc: netmod@ietf.org; netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg Andy Bierman writes: >NETCONF has no support at all for read-write (as opposed to read-create). >The protocol designers were well aware of this fact during development. >Anything marked config=3Dfalse is not writable. Just to be clea: NETCONF can do anything it pleases, since there's no limit on data models. "config=3Dfalse" is a YANG mechanism, not NETCONF. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Wed Oct 6 13:14:57 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CEA3A6FF3 for ; Wed, 6 Oct 2010 13:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuAW3ar+M3R1 for ; Wed, 6 Oct 2010 13:14:56 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DBA643A720A for ; Wed, 6 Oct 2010 13:14:55 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 11DF3616012; Wed, 6 Oct 2010 22:15:55 +0200 (CEST) Date: Wed, 06 Oct 2010 22:15:53 +0200 (CEST) Message-Id: <20101006.221553.50606857.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: <201010061925.o96JPG51018487@idle.juniper.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:14:57 -0000 Andy Bierman wrote: > The YANG marketing blurb claimed that > YANG extensions only provided 'extra' information, and did not harm > basic protocol interoperability at all. An application that ignored an > extension > could still use the 'basic' YANG definitions to utilize NETCONF. > This is not the case at all for most YANG extensions, including any that would > change the meaning of config-stmt. I disagree that its not true for "most YANG extensions", and also I do not think anyone has proposed an extension that would change the meaning of the config stmt, _for this particular reason_! *if* we wanted to map also read-write operational data into YANG, it could be done with something like: config false; xxx:writable-operational true; which would not change the meaning of config false. /martin From biermana@Brocade.com Wed Oct 6 13:23:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333DF3A7004 for ; Wed, 6 Oct 2010 13:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aeJ4y9Zucpy for ; Wed, 6 Oct 2010 13:23:34 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 72A913A71C8 for ; Wed, 6 Oct 2010 13:23:29 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o96KM8UT019481; Wed, 6 Oct 2010 13:24:30 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id rrwkh83cs-15 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Oct 2010 13:24:29 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 13:28:18 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 6 Oct 2010 13:24:22 -0700 From: Andy Bierman To: Martin Bjorklund Date: Wed, 6 Oct 2010 13:24:21 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: Actlk0w49G8oJIgVRyKIhx8BbwCaEwAAEU2w Message-ID: References: <201010061925.o96JPG51018487@idle.juniper.net> <20101006.221553.50606857.mbj@tail-f.com> In-Reply-To: <20101006.221553.50606857.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-06_11:2010-10-06, 2010-10-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060135 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:23:35 -0000 Hi, The server is not going to allow any config=3Dfalse node to be written. Adding an extension to allow exceptions certainly changes the meaning of config false; The server MUST understand the extension in order to allow to operate on config=3Dfalse nodes. However, if the operation is used instead of , I think this is probably OK. =20 Not a useful standard, but technically not violating the 4741bis or YANG sp= ecs. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Martin Bjorklund Sent: Wednesday, October 06, 2010 1:16 PM To: Andy Bierman Cc: netmod@ietf.org; netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg Andy Bierman wrote: > The YANG marketing blurb claimed that > YANG extensions only provided 'extra' information, and did not harm > basic protocol interoperability at all. An application that ignored an > extension > could still use the 'basic' YANG definitions to utilize NETCONF. > This is not the case at all for most YANG extensions, including any that = would > change the meaning of config-stmt. I disagree that its not true for "most YANG extensions", and also I do not think anyone has proposed an extension that would change the meaning of the config stmt, _for this particular reason_! *if* we wanted to map also read-write operational data into YANG, it could be done with something like: config false; xxx:writable-operational true; which would not change the meaning of config false. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From david.kessens@nsn.com Wed Oct 6 13:56:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D173A71D3 for ; Wed, 6 Oct 2010 13:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnncfRU6RevN for ; Wed, 6 Oct 2010 13:56:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1ED123A6C1C for ; Wed, 6 Oct 2010 13:56:19 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o96KvKud000911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Oct 2010 22:57:20 +0200 Received: from localhost.localdomain ([10.138.50.96]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o96KvIOI027029 for ; Wed, 6 Oct 2010 22:57:19 +0200 Received: from localhost.localdomain (david [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id o96KvHLP013938 for ; Wed, 6 Oct 2010 13:57:18 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id o96KvGFM013937 for netmod@ietf.org; Wed, 6 Oct 2010 13:57:16 -0700 Date: Wed, 6 Oct 2010 13:57:16 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20101006205716.GB13773@nsn.com> References: <201010061925.o96JPG51018487@idle.juniper.net> <20101006.221553.50606857.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101006.221553.50606857.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:56:21 -0000 I would like to remind everybody that we would like to issue a formal Last Call on the proposed charter as soon as possible. In order to this, we really need concrete statements on whether you believe it is headed in the right direction and what changes are still needed. Thanks! David Kessens speaking as one of the cochairs --- From biermana@Brocade.com Wed Oct 6 17:22:42 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4513A6ECC for ; Wed, 6 Oct 2010 17:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+276DaGpz7w for ; Wed, 6 Oct 2010 17:22:41 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id EB22E3A6D97 for ; Wed, 6 Oct 2010 17:22:40 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o970LgHi001308; Wed, 6 Oct 2010 17:23:41 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id rs04fg4h3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Oct 2010 17:23:41 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 17:27:35 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 6 Oct 2010 17:23:39 -0700 From: Andy Bierman To: David Kessens , "netmod@ietf.org" Date: Wed, 6 Oct 2010 17:23:39 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActlY7t3pA/1W78pSfm7TMwkSCqV1wAUaw+g Message-ID: References: <20101005223856.GB6755@nsn.com> In-Reply-To: <20101005223856.GB6755@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-06_13:2010-10-06, 2010-10-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060173 Cc: "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 00:22:42 -0000 Hi, I think there needs to be text added that none of the new NETMOD work can enhance/modify/alter 4741bis or RFC 6020 (YANG). All new charter items MUST be fully interoperable with implementations of 4741bis and/or YANG. No YANG extensions will be introduced which require a 4741bis server to be aware of the extension to achieve the correct behavior.=20 Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= David Kessens Sent: Tuesday, October 05, 2010 3:39 PM To: netmod@ietf.org Cc: netconf-chairs@tools.ietf.org Subject: [netmod] Charter proposal for netmod wg Working Group, As agreed during our last working group session in Maastricht, a new proposed charter for the netmod working group would be formulated to be discussed on the mailing list. Please see below for the current version of the proposed charter. This is not a formal Last Call yet, we would first like to see a bit more discussion on the list whether the current proposal is at least somewhat in line with the current thinking of most participants. We would especially welcome some more input on making the individual work items a bit more specific on what should be included/excluded in the various proposed core models. At the same time, we do want to converge quickly to a new charter as our Area Director has made it clear that he would like to have a new charter in place before the next IETF meeting. Please let us know what you think about the proposal and whether there are any specific issues that need to be addressed before we move to a formal La= st Call. In addition, we would very much like to hear commitments from volunteers wh= o are willing to do actual work on the proposed charter items. Obviously, the best way to show us such a commitment is by submitting a first draft! Thanks! David & David --- NETCONF Data Modeling Language (netmod) ----------------------------- Last Modified: 2010-10-05 Current Status: Active Working Group Chairs:=20 David Partain David Kessens Area Director:=20 Dan Romascanu Mailing List Address: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will initially work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts. 4. SMIv2 translation to YANG The NETMOD Working Group will not work on another version of YANG. It will also not serve as a review team for YANG modules developed by other working groups. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Oct 2010 Submission of individual draft(s) of System data model draft Oct 2010 Submission of individual draft(s) of Interface data model Oct 2010 Submission of individual draft(s) of Routing data model Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG Dec 2010 Submit first working group draft of System data model draft Dec 2010 Submit first working group draft of Interface data model Dec 2010 Submit first working group draft of Routing data model Dec 2010 Submit first working group draft of SMIv2 translation to YANG Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2011 Submit System data model to the IESG (proposed standard) Aug 2011 Submit Interface data model to the IESG (proposed standard) Aug 2011 Submit Routing data model to the IESG (proposed standard)=20 ---- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From dromasca@avaya.com Thu Oct 7 02:37:33 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066293A6FA6; Thu, 7 Oct 2010 02:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+Q1YTLUGTGQ; Thu, 7 Oct 2010 02:37:30 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 421253A6D98; Thu, 7 Oct 2010 02:37:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="38008426" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 07 Oct 2010 05:38:31 -0400 X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="524147325" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Oct 2010 05:38:30 -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, 7 Oct 2010 11:38:29 +0200 Message-ID: In-Reply-To: <20101006191743.CB94BE0733@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] RFC 6020 on YANG - A Data Modeling Language for theNetwork Configuration Protocol (NETCONF) Thread-Index: Actli3c2vCJ6paniQLGAgz7j+RtP+QAd+rLw References: <20101006191743.CB94BE0733@rfc-editor.org> From: "Romascanu, Dan (Dan)" To: , , Cc: netmod@ietf.org Subject: Re: [netmod] RFC 6020 on YANG - A Data Modeling Language for theNetwork Configuration Protocol (NETCONF) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 09:37:33 -0000 Congratulations to the authors, chairs and the whole WG for this achievement.=20 Regards, Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of=20 > rfc-editor@rfc-editor.org > Sent: Wednesday, October 06, 2010 9:18 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netmod@ietf.org; rfc-editor@rfc-editor.org > Subject: [netmod] RFC 6020 on YANG - A Data Modeling Language=20 > for theNetwork Configuration Protocol (NETCONF) >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 > =20 > RFC 6020 >=20 > Title: YANG - A Data Modeling=20 > Language for the Network Configuration Protocol=20 > (NETCONF)=20 > Author: M. Bjorklund, Ed. > Status: Standards Track > Stream: IETF > Date: October 2010 > Mailbox: mbj@tail-f.com > Pages: 173 > Characters: 324178 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-netmod-yang-13.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6020.txt >=20 > YANG is a data modeling language used to model configuration=20 > and state data manipulated by the Network Configuration=20 > Protocol (NETCONF), NETCONF remote procedure calls, and=20 > NETCONF notifications. > [STANDARDS TRACK] >=20 > This document is a product of the NETCONF Data Modeling=20 > Language Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet=20 > standards track protocol for the Internet community,and=20 > requests discussion and suggestions for improvements. Please=20 > refer to the current edition of the Internet Official=20 > Protocol Standards (STD 1) for the standardization state and=20 > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see=20 > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to=20 > either the author of the RFC in question, or to=20 > rfc-editor@rfc-editor.org. Unless specifically noted=20 > otherwise on the RFC itself, all RFCs are for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Thu Oct 7 02:38:38 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5D13A6F00; Thu, 7 Oct 2010 02:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjZWKDyfNgC1; Thu, 7 Oct 2010 02:38:36 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 2543F3A6EF5; Thu, 7 Oct 2010 02:38:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="38008611" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 07 Oct 2010 05:39:36 -0400 X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="520214275" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Oct 2010 05:39:01 -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, 7 Oct 2010 11:38:40 +0200 Message-ID: In-Reply-To: <20101006191753.83FC6E0738@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] RFC 6021 on Common YANG Data Types Thread-Index: Actli5Q5TFCwi4vHSdqanJkaADAmzgAd9VLQ References: <20101006191753.83FC6E0738@rfc-editor.org> From: "Romascanu, Dan (Dan)" To: , , Cc: netmod@ietf.org Subject: Re: [netmod] RFC 6021 on Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 09:38:38 -0000 Congratulations to the authors, chairs and the whole WG for this achievement.=20 Regards, Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of=20 > rfc-editor@rfc-editor.org > Sent: Wednesday, October 06, 2010 9:18 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netmod@ietf.org; rfc-editor@rfc-editor.org > Subject: [netmod] RFC 6021 on Common YANG Data Types >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 > =20 > RFC 6021 >=20 > Title: Common YANG Data Types=20 > Author: J. Schoenwaelder, Ed. > Status: Standards Track > Stream: IETF > Date: October 2010 > Mailbox: j.schoenwaelder@jacobs-university.de > Pages: 26 > Characters: 52826 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-netmod-yang-types-09.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6021.txt >=20 > This document introduces a collection of common data types to=20 > be used with the YANG data modeling language. [STANDARDS TRACK] >=20 > This document is a product of the NETCONF Data Modeling=20 > Language Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet=20 > standards track protocol for the Internet community,and=20 > requests discussion and suggestions for improvements. Please=20 > refer to the current edition of the Internet Official=20 > Protocol Standards (STD 1) for the standardization state and=20 > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see=20 > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to=20 > either the author of the RFC in question, or to=20 > rfc-editor@rfc-editor.org. Unless specifically noted=20 > otherwise on the RFC itself, all RFCs are for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Thu Oct 7 02:39:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC8F3A6F00 for ; Thu, 7 Oct 2010 02:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6p344Y05ET8 for ; Thu, 7 Oct 2010 02:39:31 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 396B43A6FA6 for ; Thu, 7 Oct 2010 02:39:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="241579600" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Oct 2010 05:40:28 -0400 X-IronPort-AV: E=Sophos;i="4.57,296,1283745600"; d="scan'208";a="524147832" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Oct 2010 05:40:27 -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, 7 Oct 2010 11:40:10 +0200 Message-ID: In-Reply-To: <201010062154.10138.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] The new RFCs! Thread-Index: ActlkFegBJgDaSH0TlqflDzHc1tTYwAcy9YQ References: <20101006191743.CB94BE0733@rfc-editor.org> <201010062154.10138.david.partain@ericsson.com> From: "Romascanu, Dan (Dan)" To: "David Partain" , Subject: Re: [netmod] The new RFCs! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 09:39:36 -0000 Great - we do have a data modeling language. Let us write some models! Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of David Partain > Sent: Wednesday, October 06, 2010 9:54 PM > To: netmod@ietf.org > Subject: [netmod] The new RFCs! >=20 > Hello all, >=20 > The day has finally arrived! >=20 > On Wednesday 06 October 2010 21.17.43 rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 6020 > > > > Title: YANG - A Data Modeling > > Language for the Network Configuration Protocol > > (NETCONF) > > Author: M. Bjorklund, Ed. >=20 > and... >=20 > On Wednesday 06 October 2010 21.17.53 rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 6021 > > > > Title: Common YANG Data Types > > Author: J. Schoenwaelder, Ed. >=20 > I'd like to thank the working group and, in particular, the=20 > editors for their tireless work. When this little adventure=20 > began, there were many who said we'd never get to this point.=20 > I'm very happy that we proved them wrong, even if it is a=20 > wee bit later than I wanted :-) >=20 > We're not finished yet, but this is a very big step forward. >=20 > Thanks, everyone! >=20 > David > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From phil@juniper.net Thu Oct 7 09:04:15 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469003A6F2A for ; Thu, 7 Oct 2010 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ65KBewDNFl for ; Thu, 7 Oct 2010 09:04:14 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 523523A6FA9 for ; Thu, 7 Oct 2010 09:04:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTK3vsYBoa3X7AUMhtDDJgQr4SzwuGosR@postini.com; Thu, 07 Oct 2010 09:05:17 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 09:01:28 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o97G1PU49727; Thu, 7 Oct 2010 09:01:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o97FeiGg024762; Thu, 7 Oct 2010 15:40:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010071540.o97FeiGg024762@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 7 Oct 2010 11:40:44 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:04:15 -0000 Andy Bierman writes: >Adding an extension to allow exceptions certainly changes the meaning >of config false; The server MUST understand the extension in order to >allow to operate on config=false nodes. Given that the server must have advertised the module containing the extension (or a module that uses it) in the hello message, the client will know that the server does understand the extension. Thanks, Phil From ietf@andybierman.com Thu Oct 7 09:42:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA563A7150 for ; Thu, 7 Oct 2010 09:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBoPcuUzdENu for ; Thu, 7 Oct 2010 09:42:16 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 0AA853A6FD0 for ; Thu, 7 Oct 2010 09:42:15 -0700 (PDT) Received: (qmail 42482 invoked from network); 7 Oct 2010 16:43:15 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 07 Oct 2010 09:43:15 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: fN1qMtUVM1mcDlajWAZt9tVJEX3QRuw9wU5G9GqEB9YdDEI xhmQtORWYPoyj3chrX4B11JzC7TwIYfiP73BEse2WP2X.hPOZAVa7n3dhVbU EsYsvoUtBUJXWB6YBhuANf0gTTo3Uc3UaOP.V5kGnfnxN0t6JHIcaFM2IwEB E55T5GIvug_wHl9AKXVtVj8P58qG77UMwEsD_fwvDrtiAm3S7LoZPidJuGiv XE7GezIaWVKxBXmmaEXh80oKUlbOt69yXSCsVUg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CADF8A2.1070706@andybierman.com> Date: Thu, 07 Oct 2010 09:43:14 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Phil Shafer References: <201010071540.o97FeiGg024762@idle.juniper.net> In-Reply-To: <201010071540.o97FeiGg024762@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andy Bierman , "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:42:32 -0000 On 10/07/2010 08:40 AM, Phil Shafer wrote: > Andy Bierman writes: >> Adding an extension to allow exceptions certainly changes the meaning >> of config false; The server MUST understand the extension in order to >> allow to operate on config=false nodes. > > Given that the server must have advertised the module containing > the extension (or a module that uses it) in the hello message, the > client will know that the server does understand the extension. > You are right. But I really don't like defining protocol behavior in the YANG language, whether it's an extension or not. Changes to NETCONF behavior should only be done in the protocol document or in a 'capability' extension document. Looking at the bigger picture, do we really want to inherit the SNMP access enumerations from SMIv2? What about RowStatus? That is part of the SNMP database model as well. Does this charter item include adding the SNMP database model to the NETCONF model in some bolt-on manner? What is the plan to deal with the SNMP-only aspects of SMIv2? Does it include NETCONF protocol behavior changes or not? If so, then the NETCONF charter needs to be updated to reflect this work-in-progress, assuming there is consensus. > Thanks, > Phil Andy From dromasca@avaya.com Thu Oct 7 09:52:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1D73A707A for ; Thu, 7 Oct 2010 09:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW8ZogjrSEta for ; Thu, 7 Oct 2010 09:52:10 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 424103A6F3C for ; Thu, 7 Oct 2010 09:52:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,298,1283745600"; d="scan'208";a="241656293" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Oct 2010 12:52:22 -0400 X-IronPort-AV: E=Sophos;i="4.57,298,1283745600"; d="scan'208";a="520430949" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Oct 2010 12:52:22 -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, 7 Oct 2010 18:52:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETMOD re-chartering approved for external review Thread-Index: ActmP/YO/bGyZFOjQ0aLmjITV+YKQw== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] NETMOD re-chartering approved for external review X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:52:12 -0000 The IESG approved today sending the new NETMOD charter for external (all IETF) review pending edits.=20 The edit that the IETF required was related to item: 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate support from routing experts. Adrian Farrel - Routing AD asked for clarification of the required support. If the WG believes that a routing expert should be a co-editor of the document the charter should say it. Early review and WGLC reviews from the routing area could also be mentioned explicitly.=20 I know other charter aspects are being discussed on the list. I would urge the WG to finalize discussions and agree on a text that can be sent for wider discussion to all the IETF as soon as possible. The latest a revised text should be sent for external review (which lasts a week) is next Thursday 7/14. Earlier is better. Not all details need to be caught in the charter text.=20 Thanks and Regards, Dan From j.schoenwaelder@jacobs-university.de Thu Oct 7 10:45:44 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D485D3A717D for ; Thu, 7 Oct 2010 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58JHy1Vkpz+T for ; Thu, 7 Oct 2010 10:45:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 13FAA3A7151 for ; Thu, 7 Oct 2010 10:45:41 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D48AC0015; Thu, 7 Oct 2010 19:46:43 +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 VhgJmgR0r5xa; Thu, 7 Oct 2010 19:46:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8448C0008; Thu, 7 Oct 2010 19:46:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 168A81518361; Thu, 7 Oct 2010 19:46:11 +0200 (CEST) Date: Thu, 7 Oct 2010 19:46:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101007174611.GA58495@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , Andy Bierman , "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CADF8A2.1070706@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" , Andy Bierman , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:45:44 -0000 On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote: > Looking at the bigger picture, do we really want to inherit the SNMP access > enumerations from SMIv2? What about RowStatus? That is part of the SNMP > database model as well. > > Does this charter item include adding the SNMP database model to the > NETCONF model in some bolt-on manner? What is the plan to deal with > the SNMP-only aspects of SMIv2? Does it include NETCONF protocol > behavior changes or not? If so, then the NETCONF charter needs to > be updated to reflect this work-in-progress, assuming there is > consensus. A likely starting point for this work is: http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 Perhaps it gets easier for me to understand your concerns if you can tell me whether you see specific problems with this. As indicated earlier, the config true translation still in this ID likely needs to be dropped, so things would be kind of read-only. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Thu Oct 7 11:21:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFB13A6F9B for ; Thu, 7 Oct 2010 11:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NFunzjwyanH for ; Thu, 7 Oct 2010 11:21:29 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id C53903A6F3E for ; Thu, 7 Oct 2010 11:21:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTK4P3qTxPeVOOXR06d8BXK+0QNRoXHr2@postini.com; Thu, 07 Oct 2010 11:22:32 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 11:20:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o97IKqU11041; Thu, 7 Oct 2010 11:20:52 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o97I0AQU026019; Thu, 7 Oct 2010 18:00:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010071800.o97I0AQU026019@idle.juniper.net> To: Andy Bierman In-Reply-To: <4CADF8A2.1070706@andybierman.com> Date: Thu, 7 Oct 2010 14:00:10 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Andy Bierman , "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:21:30 -0000 Andy Bierman writes: >Looking at the bigger picture, do we really want to inherit the SNMP access >enumerations from SMIv2? What about RowStatus? That is part of the SNMP >database model as well. No, I agree. We don't want magic data. Everytime I've made magic data, I've lived to regret it. Data is innert. RPCs should be used to instruct the server to perform an action. For example, if a device supports a value that says "the next time you boot, use this device", that value might look like data, but it's not config data (since it's discarded on reboot). But instead of making it writable non-config data, the modeler should instead make an RPC that sets that data value. usb Thanks, Phil From biermana@Brocade.com Thu Oct 7 11:36:38 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD0E3A70B7 for ; Thu, 7 Oct 2010 11:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAgCL8mfzRNn for ; Thu, 7 Oct 2010 11:36:35 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 2B8983A6F71 for ; Thu, 7 Oct 2010 11:36:23 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o97IaLC2027083; Thu, 7 Oct 2010 11:36:21 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id rshyrg2er-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Oct 2010 11:36:21 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 11:40:51 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 7 Oct 2010 11:36:19 -0700 From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman Date: Thu, 7 Oct 2010 11:36:17 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActmR6Zl9HivMnniS8CS/DoRpDqwKQABex5Q Message-ID: References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> In-Reply-To: <20101007174611.GA58495@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-07_09:2010-10-07, 2010-10-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010070108 Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:36:38 -0000 Hi, I would like the charter to say that the SMIv2 translation will focus on operational data and notifications, since this is the easiest to complete and has the most MIB objects defined. Support for writable objects may be attempted in a separate document in a future work item, but not now. Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, October 07, 2010 10:46 AM To: Andy Bierman Cc: Phil Shafer; Andy Bierman; netconf-chairs@tools.ietf.org; netmod@ietf.o= rg Subject: Re: [netmod] Charter proposal for netmod wg On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote: =20 > Looking at the bigger picture, do we really want to inherit the SNMP acce= ss > enumerations from SMIv2? What about RowStatus? That is part of the SNMP > database model as well. >=20 > Does this charter item include adding the SNMP database model to the > NETCONF model in some bolt-on manner? What is the plan to deal with > the SNMP-only aspects of SMIv2? Does it include NETCONF protocol > behavior changes or not? If so, then the NETCONF charter needs to > be updated to reflect this work-in-progress, assuming there is > consensus. A likely starting point for this work is: http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 Perhaps it gets easier for me to understand your concerns if you can tell me whether you see specific problems with this. As indicated earlier, the config true translation still in this ID likely needs to be dropped, so things would be kind of read-only. /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 saperia@jdscons.com Thu Oct 7 11:41:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336003A6F3E for ; Thu, 7 Oct 2010 11:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbdGkHzmELf2 for ; Thu, 7 Oct 2010 11:41:50 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 8A45F3A6F35 for ; Thu, 7 Oct 2010 11:41:50 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o97Igm76013299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Oct 2010 13:42:50 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: Date: Thu, 7 Oct 2010 14:42:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1081) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:41:52 -0000 Seems to me the focus should be on getting NETCONF/YANG to the point = where useful modules for configuration work. If that can be = successfully achieved and adopted by a larger community then other = extensions dealing with 'operational' data might be in order. I would = not try too hard to bold NETCONF with SNMP. The management applications = that deal with configuration and other data have been dealing with = associations between the two for some time. =20 /jon On Oct 7, 2010, at 2:36 PM, Andy Bierman wrote: > Hi, >=20 > I would like the charter to say that the SMIv2 translation will > focus on operational data and notifications, since this is the > easiest to complete and has the most MIB objects defined. > Support for writable objects may be attempted in a separate document > in a future work item, but not now. >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, October 07, 2010 10:46 AM > To: Andy Bierman > Cc: Phil Shafer; Andy Bierman; netconf-chairs@tools.ietf.org; = netmod@ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg >=20 > On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote: >=20 >> Looking at the bigger picture, do we really want to inherit the SNMP = access >> enumerations from SMIv2? What about RowStatus? That is part of the = SNMP >> database model as well. >>=20 >> Does this charter item include adding the SNMP database model to the >> NETCONF model in some bolt-on manner? What is the plan to deal with >> the SNMP-only aspects of SMIv2? Does it include NETCONF protocol >> behavior changes or not? If so, then the NETCONF charter needs to >> be updated to reflect this work-in-progress, assuming there is >> consensus. >=20 > A likely starting point for this work is: >=20 > http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 >=20 > Perhaps it gets easier for me to understand your concerns if you can > tell me whether you see specific problems with this. As indicated > earlier, the config true translation still in this ID likely needs to > be dropped, so things would be kind of read-only. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From biermana@Brocade.com Thu Oct 7 11:54:57 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532903A701B for ; Thu, 7 Oct 2010 11:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYRodLloNl9c for ; Thu, 7 Oct 2010 11:54:54 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 1F66D3A6FE3 for ; Thu, 7 Oct 2010 11:54:53 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o97Isb4J017240; Thu, 7 Oct 2010 11:55:46 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id rskc280tg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Oct 2010 11:55:46 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 12:00:17 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 7 Oct 2010 11:55:45 -0700 From: Andy Bierman To: Jon Saperia Date: Thu, 7 Oct 2010 11:55:44 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActmT3RO3vWJ1XP9SxOsxN7U5QMlMwAAX3bw Message-ID: References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> In-Reply-To: <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-07_09:2010-10-07, 2010-10-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010070110 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:54:57 -0000 Hi Jon, Looks like we all agree on writable objects if not readable ones. NETCONF of SNMP data is something some NMS developers have asked for, and I prefer to have 1 standard solution than every vendor do it differentl= y (what we have now). Andy -----Original Message----- From: Jon Saperia [mailto:saperia@jdscons.com]=20 Sent: Thursday, October 07, 2010 11:43 AM To: Andy Bierman Cc: Juergen Schoenwaelder; Andy Bierman; netmod@ietf.org; netconf-chairs@to= ols.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg Seems to me the focus should be on getting NETCONF/YANG to the point where = useful modules for configuration work. If that can be successfully achieve= d and adopted by a larger community then other extensions dealing with 'ope= rational' data might be in order. I would not try too hard to bold NETCONF= with SNMP. The management applications that deal with configuration and o= ther data have been dealing with associations between the two for some time= . =20 /jon On Oct 7, 2010, at 2:36 PM, Andy Bierman wrote: > Hi, >=20 > I would like the charter to say that the SMIv2 translation will > focus on operational data and notifications, since this is the > easiest to complete and has the most MIB objects defined. > Support for writable objects may be attempted in a separate document > in a future work item, but not now. >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]= =20 > Sent: Thursday, October 07, 2010 10:46 AM > To: Andy Bierman > Cc: Phil Shafer; Andy Bierman; netconf-chairs@tools.ietf.org; netmod@ietf= .org > Subject: Re: [netmod] Charter proposal for netmod wg >=20 > On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote: >=20 >> Looking at the bigger picture, do we really want to inherit the SNMP acc= ess >> enumerations from SMIv2? What about RowStatus? That is part of the SNMP >> database model as well. >>=20 >> Does this charter item include adding the SNMP database model to the >> NETCONF model in some bolt-on manner? What is the plan to deal with >> the SNMP-only aspects of SMIv2? Does it include NETCONF protocol >> behavior changes or not? If so, then the NETCONF charter needs to >> be updated to reflect this work-in-progress, assuming there is >> consensus. >=20 > A likely starting point for this work is: >=20 > http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 >=20 > Perhaps it gets easier for me to understand your concerns if you can > tell me whether you see specific problems with this. As indicated > earlier, the config true translation still in this ID likely needs to > be dropped, so things would be kind of read-only. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From saperia@jdscons.com Thu Oct 7 12:05:42 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DCB3A701E for ; Thu, 7 Oct 2010 12:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWYy49G+UyN9 for ; Thu, 7 Oct 2010 12:05:40 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 977333A6DED for ; Thu, 7 Oct 2010 12:05:16 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o97J68FK015380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Oct 2010 14:06:08 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: Date: Thu, 7 Oct 2010 15:06:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> To: Andy Bierman X-Mailer: Apple Mail (2.1081) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:05:42 -0000 Hi, Which NMS developers have asked for this? The SNMP stuff is standard - = if not the objects themselves - NETCONF will have the same issue with = regard to 'standard objects' even more so for configuration data. It is = not the conveyance of the information that is or has been at issue. = This would just be a convenience without the bang for the buck. I still think focus should be on a standard way we can get the = configuration problem solved. =20 /jon On Oct 7, 2010, at 2:55 PM, Andy Bierman wrote: > Hi Jon, >=20 > Looks like we all agree on writable objects if not readable ones. > NETCONF of SNMP data is something some NMS developers have asked = for, > and I prefer to have 1 standard solution than every vendor do it = differently > (what we have now). >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: Jon Saperia [mailto:saperia@jdscons.com]=20 > Sent: Thursday, October 07, 2010 11:43 AM > To: Andy Bierman > Cc: Juergen Schoenwaelder; Andy Bierman; netmod@ietf.org; = netconf-chairs@tools.ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg >=20 > Seems to me the focus should be on getting NETCONF/YANG to the point = where useful modules for configuration work. If that can be = successfully achieved and adopted by a larger community then other = extensions dealing with 'operational' data might be in order. I would = not try too hard to bold NETCONF with SNMP. The management applications = that deal with configuration and other data have been dealing with = associations between the two for some time. =20 > /jon > On Oct 7, 2010, at 2:36 PM, Andy Bierman wrote: >=20 >> Hi, >>=20 >> I would like the charter to say that the SMIv2 translation will >> focus on operational data and notifications, since this is the >> easiest to complete and has the most MIB objects defined. >> Support for writable objects may be attempted in a separate document >> in a future work item, but not now. >>=20 >>=20 >> Andy >>=20 >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 >> Sent: Thursday, October 07, 2010 10:46 AM >> To: Andy Bierman >> Cc: Phil Shafer; Andy Bierman; netconf-chairs@tools.ietf.org; = netmod@ietf.org >> Subject: Re: [netmod] Charter proposal for netmod wg >>=20 >> On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote: >>=20 >>> Looking at the bigger picture, do we really want to inherit the SNMP = access >>> enumerations from SMIv2? What about RowStatus? That is part of the = SNMP >>> database model as well. >>>=20 >>> Does this charter item include adding the SNMP database model to the >>> NETCONF model in some bolt-on manner? What is the plan to deal with >>> the SNMP-only aspects of SMIv2? Does it include NETCONF protocol >>> behavior changes or not? If so, then the NETCONF charter needs to >>> be updated to reflect this work-in-progress, assuming there is >>> consensus. >>=20 >> A likely starting point for this work is: >>=20 >> http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 >>=20 >> Perhaps it gets easier for me to understand your concerns if you can >> tell me whether you see specific problems with this. As indicated >> earlier, the config true translation still in this ID likely needs to >> be dropped, so things would be kind of read-only. >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 From biermana@Brocade.com Thu Oct 7 12:14:15 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA6E3A702E for ; Thu, 7 Oct 2010 12:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxBUS6XR8AQA for ; Thu, 7 Oct 2010 12:14:12 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 36E903A701E for ; Thu, 7 Oct 2010 12:14:11 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o97JFD6h015206; Thu, 7 Oct 2010 12:15:13 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id rshyrg394-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Oct 2010 12:15:13 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 12:18:49 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 7 Oct 2010 12:14:54 -0700 From: Andy Bierman To: Jon Saperia Date: Thu, 7 Oct 2010 12:14:52 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActmUrg1aLuSEagiR9CascKuIbf9RwAACNsA Message-ID: References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-07_09:2010-10-07, 2010-10-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010070114 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:14:15 -0000 Hi Jon, Well, developers at my company have asked recently (for example). I want to see Juergen's draft standardized, and then use smidump -fyang to bring almost any MIB object into the XML subtree with read-only access, in a consistent and useful way. XPath and subtree filtering provides the N= MS with powerful server-side filtering that is easy to use. Lower complexity. Less code. There are reasons to do this if you are already writing NETCONF applications anyway. It is not the highest priority by a mile, but it is on the list. Andy -----Original Message----- From: Jon Saperia [mailto:saperia@jdscons.com]=20 Sent: Thursday, October 07, 2010 12:06 PM To: Andy Bierman Cc: Juergen Schoenwaelder; Andy Bierman; netmod@ietf.org; netconf-chairs@to= ols.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg Hi, Which NMS developers have asked for this? The SNMP stuff is standard - if n= ot the objects themselves - NETCONF will have the same issue with regard to= 'standard objects' even more so for configuration data. It is not the con= veyance of the information that is or has been at issue. This would just b= e a convenience without the bang for the buck. I still think focus should be on a standard way we can get the configuratio= n problem solved. =20 /jon On Oct 7, 2010, at 2:55 PM, Andy Bierman wrote: > Hi Jon, >=20 > Looks like we all agree on writable objects if not readable ones. > NETCONF of SNMP data is something some NMS developers have asked fo= r, > and I prefer to have 1 standard solution than every vendor do it differen= tly > (what we have now). >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: Jon Saperia [mailto:saperia@jdscons.com]=20 > Sent: Thursday, October 07, 2010 11:43 AM > To: Andy Bierman > Cc: Juergen Schoenwaelder; Andy Bierman; netmod@ietf.org; netconf-chairs@= tools.ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg >=20 > Seems to me the focus should be on getting NETCONF/YANG to the point wher= e useful modules for configuration work. If that can be successfully achie= ved and adopted by a larger community then other extensions dealing with 'o= perational' data might be in order. I would not try too hard to bold NETCO= NF with SNMP. The management applications that deal with configuration and= other data have been dealing with associations between the two for some ti= me. =20 > /jon > On Oct 7, 2010, at 2:36 PM, Andy Bierman wrote: >=20 >> Hi, >>=20 >> I would like the charter to say that the SMIv2 translation will >> focus on operational data and notifications, since this is the >> easiest to complete and has the most MIB objects defined. >> Support for writable objects may be attempted in a separate document >> in a future work item, but not now. >>=20 >>=20 >> Andy >>=20 >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ]=20 >> Sent: Thursday, October 07, 2010 10:46 AM >> To: Andy Bierman >> Cc: Phil Shafer; Andy Bierman; netconf-chairs@tools.ietf.org; netmod@iet= f.org >> Subject: Re: [netmod] Charter proposal for netmod wg >>=20 >> On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote: >>=20 >>> Looking at the bigger picture, do we really want to inherit the SNMP ac= cess >>> enumerations from SMIv2? What about RowStatus? That is part of the SNMP >>> database model as well. >>>=20 >>> Does this charter item include adding the SNMP database model to the >>> NETCONF model in some bolt-on manner? What is the plan to deal with >>> the SNMP-only aspects of SMIv2? Does it include NETCONF protocol >>> behavior changes or not? If so, then the NETCONF charter needs to >>> be updated to reflect this work-in-progress, assuming there is >>> consensus. >>=20 >> A likely starting point for this work is: >>=20 >> http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 >>=20 >> Perhaps it gets easier for me to understand your concerns if you can >> tell me whether you see specific problems with this. As indicated >> earlier, the config true translation still in this ID likely needs to >> be dropped, so things would be kind of read-only. >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 From j.schoenwaelder@jacobs-university.de Thu Oct 7 12:18:07 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4393A708A for ; Thu, 7 Oct 2010 12:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V6NRnTfX6gJ for ; Thu, 7 Oct 2010 12:17:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 17A583A6FF0 for ; Thu, 7 Oct 2010 12:17:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE3E4C0019; Thu, 7 Oct 2010 21:18:55 +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 kgzs1aIHw-Ux; Thu, 7 Oct 2010 21:18:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CECA4C0015; Thu, 7 Oct 2010 21:18:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7E68A1518628; Thu, 7 Oct 2010 21:18:26 +0200 (CEST) Date: Thu, 7 Oct 2010 21:18:26 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101007191826.GB58686@elstar.local> Mail-Followup-To: Andy Bierman , Andy Bierman , Phil Shafer , "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:18:07 -0000 On Thu, Oct 07, 2010 at 08:36:17PM +0200, Andy Bierman wrote: > I would like the charter to say that the SMIv2 translation will > focus on operational data and notifications, since this is the > easiest to complete and has the most MIB objects defined. > Support for writable objects may be attempted in a separate document > in a future work item, but not now. Can you please clarify your statement? Are you suggesting (i) that read-write or read-create data is not translated at all or are you suggesting (ii) that read-write or read-create data is translated to 'config false' data, leaving it for further study whether/how such data can be modified via NETCONF? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Oct 7 12:19:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68F23A702E for ; Thu, 7 Oct 2010 12:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dy+hwSVHc+m for ; Thu, 7 Oct 2010 12:19:37 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4DD523A6C4C for ; Thu, 7 Oct 2010 12:19:37 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E1219616001 for ; Thu, 7 Oct 2010 21:20:38 +0200 (CEST) Date: Thu, 07 Oct 2010 21:20:38 +0200 (CEST) Message-Id: <20101007.212038.190910601.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] RFC 6020 and pyang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:19:40 -0000 Hi, To celebrate the publication of RFC 6020 we have released pyang 1.0, see http://code.google.com/p/pyang. It has some useful new features, e.g. the '--ietf' parameter which checks a module for compliance with the YANG usage guidelines. /martin From j.schoenwaelder@jacobs-university.de Thu Oct 7 12:34:27 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5180F3A6DE5 for ; Thu, 7 Oct 2010 12:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvvIabDOj8MC for ; Thu, 7 Oct 2010 12:34:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 863683A6C4C for ; Thu, 7 Oct 2010 12:34:23 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30236C0022; Thu, 7 Oct 2010 21:35:26 +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 GspTPZFU5wA2; Thu, 7 Oct 2010 21:35:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77480C0019; Thu, 7 Oct 2010 21:35:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 276B115186F1; Thu, 7 Oct 2010 21:34:54 +0200 (CEST) Date: Thu, 7 Oct 2010 21:34:54 +0200 From: Juergen Schoenwaelder To: Jon Saperia Message-ID: <20101007193454.GC58686@elstar.local> Mail-Followup-To: Jon Saperia , Andy Bierman , Andy Bierman , "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:34:27 -0000 On Thu, Oct 07, 2010 at 09:06:07PM +0200, Jon Saperia wrote: > Which NMS developers have asked for this? The SNMP stuff is standard > - if not the objects themselves - NETCONF will have the same issue > with regard to 'standard objects' even more so for configuration > data. It is not the conveyance of the information that is or has > been at issue. This would just be a convenience without the bang > for the buck. During the IAB Network Management Workshop [RFC3535], it was noted that SNMP shows relatively poor performance for bulk data transfers and filtering capabilities are limited to what has been built into the MIB design. At the workshop, operators reported that they sometimes script CLIs to get scalable access to data instead of using SNMP. Allowing operators to move from scripted proprietary CLIs to standardized NETCONF access to operational data may not just be a matter of convenience. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From saperia@jdscons.com Thu Oct 7 12:43:02 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8DD3A6CBE for ; Thu, 7 Oct 2010 12:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxwPjuo3SiSe for ; Thu, 7 Oct 2010 12:43:01 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 8BC5A3A6C4C for ; Thu, 7 Oct 2010 12:43:01 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o97Ji11M009197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Oct 2010 14:44:01 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: <20101007193454.GC58686@elstar.local> Date: Thu, 7 Oct 2010 15:44:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> <20101007193454.GC58686@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1081) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:43:02 -0000 That is a pretty old data point and not the one I asked about that Andy = has already responded to. I asked which application developers were requesting the access to = SNMP-based data via NETCONF mechanisms. I still do not see any = compelling reason to spend cycles on this topic when the original = problem, configuration that was to have been addressed by this = technology is still open. That is, we still do not have standard = configuration modules much less a range of cross vendor management = systems that use it. /jon On Oct 7, 2010, at 3:34 PM, Juergen Schoenwaelder wrote: > On Thu, Oct 07, 2010 at 09:06:07PM +0200, Jon Saperia wrote: >=20 >> Which NMS developers have asked for this? The SNMP stuff is standard >> - if not the objects themselves - NETCONF will have the same issue >> with regard to 'standard objects' even more so for configuration >> data. It is not the conveyance of the information that is or has >> been at issue. This would just be a convenience without the bang >> for the buck. >=20 > During the IAB Network Management Workshop [RFC3535], it was noted > that SNMP shows relatively poor performance for bulk data transfers > and filtering capabilities are limited to what has been built into the > MIB design. >=20 > At the workshop, operators reported that they sometimes script CLIs to > get scalable access to data instead of using SNMP. Allowing operators > to move from scripted proprietary CLIs to standardized NETCONF access > to operational data may not just be a matter of convenience. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From j.schoenwaelder@jacobs-university.de Thu Oct 7 12:49:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B5C3A6F7E for ; Thu, 7 Oct 2010 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.532 X-Spam-Level: X-Spam-Status: No, score=-101.532 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_UNSUB22=0.948, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw8NehosN8NP for ; Thu, 7 Oct 2010 12:49:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1E2193A6FED for ; Thu, 7 Oct 2010 12:49:30 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFB4EC0019; Thu, 7 Oct 2010 21:50:32 +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 KNLOE20aTKRK; Thu, 7 Oct 2010 21:50:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE7EDC0015; Thu, 7 Oct 2010 21:50:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43ADF151880E; Thu, 7 Oct 2010 21:50:03 +0200 (CEST) Date: Thu, 7 Oct 2010 21:50:03 +0200 From: Juergen Schoenwaelder To: Jon Saperia Message-ID: <20101007195003.GA58833@elstar.local> Mail-Followup-To: Jon Saperia , Andy Bierman , Andy Bierman , "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> <20101007193454.GC58686@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:49:32 -0000 On Thu, Oct 07, 2010 at 09:44:00PM +0200, Jon Saperia wrote: > That is a pretty old data point and not the one I asked about that > Andy has already responded to. Perhaps old, but still relevant, perhaps not for you. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From saperia@jdscons.com Thu Oct 7 13:20:54 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7773A7111 for ; Thu, 7 Oct 2010 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 664kwbz8hFMd for ; Thu, 7 Oct 2010 13:20:53 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id EBFAE3A6FE1 for ; Thu, 7 Oct 2010 13:20:52 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o97KLqA5031840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Oct 2010 15:21:53 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: <20101007195003.GA58833@elstar.local> Date: Thu, 7 Oct 2010 16:21:51 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3B0DD567-BB05-486C-9C81-0F8D36C5117A@jdscons.com> References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <075FC9AF-0539-4695-9AB5-5B160F6CE409@jdscons.com> <20101007193454.GC58686@elstar.local> <20101007195003.GA58833@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1081) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 20:20:54 -0000 I did not say it was irrelevant. It was however not what I asked about. /jon On Oct 7, 2010, at 3:50 PM, Juergen Schoenwaelder wrote: > On Thu, Oct 07, 2010 at 09:44:00PM +0200, Jon Saperia wrote: > >> That is a pretty old data point and not the one I asked about that >> Andy has already responded to. > > Perhaps old, but still relevant, perhaps not for you. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From phil@juniper.net Thu Oct 7 14:16:03 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37AC3A7159 for ; Thu, 7 Oct 2010 14:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDnk7M3IKMk7 for ; Thu, 7 Oct 2010 14:16:01 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 324B93A717F for ; Thu, 7 Oct 2010 14:15:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTK44vHutNOhVRLqN06lf5YywxxSS8QCS@postini.com; Thu, 07 Oct 2010 14:17:05 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 14:15:09 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o97LF8U89558; Thu, 7 Oct 2010 14:15:08 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o97KsQU1030824; Thu, 7 Oct 2010 20:54:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010072054.o97KsQU1030824@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20101007193454.GC58686@elstar.local> Date: Thu, 7 Oct 2010 16:54:26 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:16:04 -0000 Juergen Schoenwaelder writes: >At the workshop, operators reported that they sometimes script CLIs to >get scalable access to data instead of using SNMP. Allowing operators >to move from scripted proprietary CLIs to standardized NETCONF access >to operational data may not just be a matter of convenience. Moving from screen scraping to an API is definitely a Good Thing, but even this would be behind the times. When statistics gathering is externally driven, the times you most need to data (when your network is thrashing) is the time that you are least likely to get it (because your network is thrashing). In JUNOS we record statistics data (as instructed by config) on local storage (hard drive) in CSV/XML format and transfer it (compressed) at time or size thresholds. You also access this data (via NETCONF RPC) with filters (time range or content) to get XML data that you can transform (via XSLT) into something you can show in your browser (lika SVG). So no one's going to oh and ah over simpler access, but giving them richer, more accurate data is something that will. Thanks, Phil From saperia@jdscons.com Thu Oct 7 14:26:04 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1F03A718D for ; Thu, 7 Oct 2010 14:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQrUnRtq7SeQ for ; Thu, 7 Oct 2010 14:26:03 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 793723A719C for ; Thu, 7 Oct 2010 14:25:28 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o97LQU3l030198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Oct 2010 16:26:30 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: <201010072054.o97KsQU1030824@idle.juniper.net> Date: Thu, 7 Oct 2010 17:26:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <062CA02F-D53D-4296-8B08-AC1C8A66B810@jdscons.com> References: <201010072054.o97KsQU1030824@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1081) Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:26:04 -0000 To carry your point one step further, there are some cases where it = would be very helpful to the management application not to have to = initiate a 'poll' or get-conf like action. The ability for the managed = device to send information at 'scheduled' times or under certain = conditions would be helpful - and others have done this. But this is = not something that is accomplished just by changing how the data are = described. As you point out there are configuration elements in the = managed device and management applications would need work to deal with = this. My point is, finish the initial work first (getting a standard = configuration mechanism with standard configuration objects) which will = take the least amount of time. Let the market absorb that, then add = other elements based on what does or does not happen. /jon =20 On Oct 7, 2010, at 4:54 PM, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> At the workshop, operators reported that they sometimes script CLIs = to >> get scalable access to data instead of using SNMP. Allowing operators >> to move from scripted proprietary CLIs to standardized NETCONF access >> to operational data may not just be a matter of convenience. >=20 > Moving from screen scraping to an API is definitely a Good Thing, > but even this would be behind the times. When statistics gathering > is externally driven, the times you most need to data (when your > network is thrashing) is the time that you are least likely to get > it (because your network is thrashing). >=20 > In JUNOS we record statistics data (as instructed by config) on > local storage (hard drive) in CSV/XML format and transfer it > (compressed) at time or size thresholds. You also access this data > (via NETCONF RPC) with filters (time range or content) to get XML > data that you can transform (via XSLT) into something you can show > in your browser (lika SVG). >=20 > So no one's going to oh and ah over simpler access, but giving > them richer, more accurate data is something that will. >=20 > Thanks, > Phil >=20 From biermana@Brocade.com Thu Oct 7 14:26:33 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDFE3A7004 for ; Thu, 7 Oct 2010 14:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS+234JTD7rA for ; Thu, 7 Oct 2010 14:26:31 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 508013A715C for ; Thu, 7 Oct 2010 14:26:26 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o97LQC6Q028191; Thu, 7 Oct 2010 14:27:29 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id rskc2844h-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Oct 2010 14:27:29 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 14:31:23 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 7 Oct 2010 14:27:28 -0700 From: Andy Bierman To: Phil Shafer , Juergen Schoenwaelder Date: Thu, 7 Oct 2010 14:27:27 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActmZQGt/XwCgElTRmalny2PPEbg7AAAQbZg Message-ID: References: <20101007193454.GC58686@elstar.local> <201010072054.o97KsQU1030824@idle.juniper.net> In-Reply-To: <201010072054.o97KsQU1030824@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-07_09:2010-10-07, 2010-10-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010070139 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:26:33 -0000 Hi Phil, There are many use-cases, not just 1. (Your solution sounds less complicated than IPFIX by a mile.) XPath is pretty good at needle-in-a-haystack data searches. It doesn't matter how good your bulk transfer is if N is large enough. You have to leave the haystack where it is at a certain point. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Phil Shafer Sent: Thursday, October 07, 2010 1:54 PM To: Juergen Schoenwaelder Cc: netmod@ietf.org; netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg Juergen Schoenwaelder writes: >At the workshop, operators reported that they sometimes script CLIs to >get scalable access to data instead of using SNMP. Allowing operators >to move from scripted proprietary CLIs to standardized NETCONF access >to operational data may not just be a matter of convenience. Moving from screen scraping to an API is definitely a Good Thing, but even this would be behind the times. When statistics gathering is externally driven, the times you most need to data (when your network is thrashing) is the time that you are least likely to get it (because your network is thrashing). In JUNOS we record statistics data (as instructed by config) on local storage (hard drive) in CSV/XML format and transfer it (compressed) at time or size thresholds. You also access this data (via NETCONF RPC) with filters (time range or content) to get XML data that you can transform (via XSLT) into something you can show in your browser (lika SVG). So no one's going to oh and ah over simpler access, but giving them richer, more accurate data is something that will. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From saperia@jdscons.com Thu Oct 7 14:50:56 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6953A6F94 for ; Thu, 7 Oct 2010 14:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8bkpE3O+A8C for ; Thu, 7 Oct 2010 14:50:55 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 37CE03A6E7D for ; Thu, 7 Oct 2010 14:50:54 -0700 (PDT) Received: from [10.0.1.4] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o97LpsqS001641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Oct 2010 16:51:55 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: Date: Thu, 7 Oct 2010 17:51:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26340549-CDAF-48BD-907D-FEF143B37C96@jdscons.com> References: <20101007193454.GC58686@elstar.local> <201010072054.o97KsQU1030824@idle.juniper.net> To: Andy Bierman X-Mailer: Apple Mail (2.1081) Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:50:56 -0000 Fair point, another reason though why in some conditions, some local = intelligence (to the managed element) is helpful so that the managed = element sends what it has been configured to 'know' is needed. There is = nothing that picks up performance like minimizing the movement of data. =20= The protocols/data definitions, even in large networks have seldom been = the bottleneck in a large distributed management suite in my experience = (tuning is needed for sure). The performance problem is having so much = data that serialization to/from the database becomes an issue no matter = how well constructed. =20 I hope that any new work related to data collection of non-configuration = information would do some deep thinking about these issues and see what = can been helped by data definitions and protocol operations. =20 /jon On Oct 7, 2010, at 5:27 PM, Andy Bierman wrote: > Hi Phil, >=20 > There are many use-cases, not just 1. > (Your solution sounds less complicated than IPFIX by a mile.) >=20 > XPath is pretty good at needle-in-a-haystack data searches. > It doesn't matter how good your bulk transfer is if N is large enough. > You have to leave the haystack where it is at a certain point. >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf Of Phil Shafer > Sent: Thursday, October 07, 2010 1:54 PM > To: Juergen Schoenwaelder > Cc: netmod@ietf.org; netconf-chairs@tools.ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg >=20 > Juergen Schoenwaelder writes: >> At the workshop, operators reported that they sometimes script CLIs = to >> get scalable access to data instead of using SNMP. Allowing operators >> to move from scripted proprietary CLIs to standardized NETCONF access >> to operational data may not just be a matter of convenience. >=20 > Moving from screen scraping to an API is definitely a Good Thing, > but even this would be behind the times. When statistics gathering > is externally driven, the times you most need to data (when your > network is thrashing) is the time that you are least likely to get > it (because your network is thrashing). >=20 > In JUNOS we record statistics data (as instructed by config) on > local storage (hard drive) in CSV/XML format and transfer it > (compressed) at time or size thresholds. You also access this data > (via NETCONF RPC) with filters (time range or content) to get XML > data that you can transform (via XSLT) into something you can show > in your browser (lika SVG). >=20 > So no one's going to oh and ah over simpler access, but giving > them richer, more accurate data is something that will. >=20 > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mbj@tail-f.com Thu Oct 7 14:58:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CF13A6E2C for ; Thu, 7 Oct 2010 14:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N87ynFmJ0GAx for ; Thu, 7 Oct 2010 14:58:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 83A4E3A6D53 for ; Thu, 7 Oct 2010 14:58:54 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 05FCE616001; Thu, 7 Oct 2010 23:59:56 +0200 (CEST) Date: Thu, 07 Oct 2010 23:59:55 +0200 (CEST) Message-Id: <20101007.235955.167534178.mbj@tail-f.com> To: david.kessens@nsn.com From: Martin Bjorklund In-Reply-To: <20101005223856.GB6755@nsn.com> References: <20101005223856.GB6755@nsn.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:58:55 -0000 Hi, David Kessens wrote: > Please see below for the current version of the proposed charter. [...] > The NETMOD Working Group will initially work on the following items: > > 1. Core system data model > 2. Core interface data model > 3. Core routing data model that can be augmented with routing > protocol specifics. This requires appropriate active editorial > participation from routing experts. > 4. SMIv2 translation to YANG I think the most interesting work ahead of us is starting to write models both for the device and for the network, as we discussed in Maastricht. Since network-wide config is not part of this charter, does that mean that we must finish this before we start to work on network-wide config? I think the design of device data models (2 and 3 above) may be impacted by the larger picture with network data models. /martin From mbj@tail-f.com Thu Oct 7 15:02:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E66A3A6F46 for ; Thu, 7 Oct 2010 15:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyS-GWODQgA8 for ; Thu, 7 Oct 2010 15:02:04 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 73A923A6F7F for ; Thu, 7 Oct 2010 15:02:03 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 998FB616001; Fri, 8 Oct 2010 00:03:06 +0200 (CEST) Date: Fri, 08 Oct 2010 00:03:05 +0200 (CEST) Message-Id: <20101008.000305.148115658.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: <20101005223856.GB6755@nsn.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:02:05 -0000 Hi, Andy Bierman wrote: > I think there needs to be text added that none of the new NETMOD work > can enhance/modify/alter 4741bis or RFC 6020 (YANG). > All new charter items MUST be fully interoperable with implementations > of 4741bis and/or YANG. No YANG extensions will be introduced which > require a 4741bis server to be aware of the extension to achieve the > correct behavior. I don't think we should add this to the charter. That does not mean that I think that we should end up with YANG extensions, but if we do need them we should not be limited by this charter. Also the term "correct behavior" can be interpreted in many ways... /martin From mbj@tail-f.com Thu Oct 7 15:09:06 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A003A6F06 for ; Thu, 7 Oct 2010 15:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeMrUpl1uEUH for ; Thu, 7 Oct 2010 15:09:05 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2298B3A6E40 for ; Thu, 7 Oct 2010 15:09:05 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id CA394616001; Fri, 8 Oct 2010 00:10:07 +0200 (CEST) Date: Fri, 08 Oct 2010 00:10:06 +0200 (CEST) Message-Id: <20101008.001006.207941401.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101007174611.GA58495@elstar.local> References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netconf-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:09:06 -0000 Juergen Schoenwaelder wrote: > On Thu, Oct 07, 2010 at 06:43:14PM +0200, Andy Bierman wrote: > > > Looking at the bigger picture, do we really want to inherit the SNMP access > > enumerations from SMIv2? What about RowStatus? That is part of the SNMP > > database model as well. > > > > Does this charter item include adding the SNMP database model to the > > NETCONF model in some bolt-on manner? What is the plan to deal with > > the SNMP-only aspects of SMIv2? Does it include NETCONF protocol > > behavior changes or not? If so, then the NETCONF charter needs to > > be updated to reflect this work-in-progress, assuming there is > > consensus. > > A likely starting point for this work is: > > http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 If we do this mapping, does that mean that all current SMIv2 modules are magically available for normal YANG modules to use, or do we require the translated modules to be published as RFCs? If they are available w/o publication, can people start to import them so they get typedefs from them? Is this something we want to recommend? /martin From ietf@andybierman.com Thu Oct 7 19:38:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C723A657C for ; Thu, 7 Oct 2010 19:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaOOtnQJTBZR for ; Thu, 7 Oct 2010 19:38:34 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 9D7EF3A6782 for ; Thu, 7 Oct 2010 19:38:32 -0700 (PDT) Received: (qmail 66004 invoked from network); 8 Oct 2010 02:39:33 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 07 Oct 2010 19:39:33 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 07.dSOwVM1k5FZkZ8Yi4Dr4Q6kCfLl4JjW58ASKAc5gilzJ K8qBWvGDucxy.GBPN0AwVHKr6wXIjzXmLvXEFMcteX17T2ET8FjnEWTqpxtp 5yux0o_raiQx6IuR.XZVFlp2m8HEFawHGpaumfHxq1O2HlbWEFaMF6QGvGTz EqP5ZJ3qbI43HvD7ojX80JKtZsBwpUkAkOQiv8qaaHkrQsaRGi.H3GaHGFwn Obj.ZQRLhWUj_sBR5.eluSysvszq3ewTkRRI_NurF36Gtw5Kw.SIUqP0AtuO rmrEUo3zwRYGAfZBek0HxyEybK_tDKM91lMA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CAE8465.2030509@andybierman.com> Date: Thu, 07 Oct 2010 19:39:33 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Martin Bjorklund References: <20101005223856.GB6755@nsn.com> <20101007.235955.167534178.mbj@tail-f.com> In-Reply-To: <20101007.235955.167534178.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 02:38:35 -0000 On 10/07/2010 02:59 PM, Martin Bjorklund wrote: > Hi, > > David Kessens wrote: >> Please see below for the current version of the proposed charter. > > [...] >> The NETMOD Working Group will initially work on the following items: >> >> 1. Core system data model >> 2. Core interface data model >> 3. Core routing data model that can be augmented with routing >> protocol specifics. This requires appropriate active editorial >> participation from routing experts. >> 4. SMIv2 translation to YANG > > I think the most interesting work ahead of us is starting to write > models both for the device and for the network, as we discussed in > Maastricht. Since network-wide config is not part of this charter, > does that mean that we must finish this before we start to work on > network-wide config? I think the design of device data models (2 and > 3 above) may be impacted by the larger picture with network data > models. > I agree. (1) and (2) above would be the best to have first, even if just a minimal set of mandatory-to-implement objects were defined. It would be good to have a standard solution for interface naming, like you showed me at the last IETF, something like: leaf name { description "interface name (key)"; type string; } leaf name-format { description "expression describing ../name string syntax and providing leafref pointers to the associated leaf objects represented in the name string."; type "if-name-format-type"; // value example: // "%1/%2/%3:/chassis/my-switch-id:/chassis/my-slot-id:/chassis/my-port-id" // (The actual syntax is different, but you get the idea.) config false; } (Hoping somebody will write an interface module.) > > /martin Andy From ietf@andybierman.com Thu Oct 7 19:50:48 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF2E3A67D0 for ; Thu, 7 Oct 2010 19:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me6qmFEfoo2N for ; Thu, 7 Oct 2010 19:50:39 -0700 (PDT) Received: from smtp106.sbc.mail.gq1.yahoo.com (smtp106.sbc.mail.gq1.yahoo.com [67.195.14.109]) by core3.amsl.com (Postfix) with SMTP id 860993A67B3 for ; Thu, 7 Oct 2010 19:50:31 -0700 (PDT) Received: (qmail 96523 invoked from network); 8 Oct 2010 02:51:15 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 07 Oct 2010 19:51:15 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: uZQzW9gVM1mJRg.5quadcYwC5ZvRW9ZQS92wXbW.f34dTTd dzwjDGF025iZgQk1tFXn6MuBm_c4igK2.Q.LmKO0g3yQPpFz7zjBrnzEORnA GpqDc83ksm93.KU._A4DRqB4isNFs0DCwgUkvbe6X2aIy1EzPzspUoXSXDZF 9uz4wioSAxtM87eloRYtrl4EP03hm.6Z6jD4JGfzqgga1qjnsD8XeoOnKzVr VjnoufJtNPqaRbbIK2WvJ9ZI5iuDX X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CAE8722.9020603@andybierman.com> Date: Thu, 07 Oct 2010 19:51:14 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <20101007191826.GB58686@elstar.local> In-Reply-To: <20101007191826.GB58686@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 02:50:48 -0000 On 10/07/2010 12:18 PM, Juergen Schoenwaelder wrote: > On Thu, Oct 07, 2010 at 08:36:17PM +0200, Andy Bierman wrote: > >> I would like the charter to say that the SMIv2 translation will >> focus on operational data and notifications, since this is the >> easiest to complete and has the most MIB objects defined. >> Support for writable objects may be attempted in a separate document >> in a future work item, but not now. > > Can you please clarify your statement? > > Are you suggesting (i) that read-write or read-create data is not > translated at all or are you suggesting (ii) that read-write or > read-create data is translated to 'config false' data, leaving it for > further study whether/how such data can be modified via NETCONF? > (ii). Sort of a forced MIN-ACCESS read-only. My biggest concern will all of this new work is that it needs to be done much faster than the usual IETF pace. Rather than spend an extra 12 - 18 months defining the last 20% of features, we need to just stop and publish the low-hanging 80% ASAP. > /js > Andy From ietf@andybierman.com Thu Oct 7 20:01:06 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3EAC3A67D7 for ; Thu, 7 Oct 2010 20:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjEEGt1vuysE for ; Thu, 7 Oct 2010 20:01:04 -0700 (PDT) Received: from nm27.bullet.mail.ne1.yahoo.com (nm27.bullet.mail.ne1.yahoo.com [98.138.90.90]) by core3.amsl.com (Postfix) with SMTP id 324923A67B1 for ; Thu, 7 Oct 2010 20:01:04 -0700 (PDT) Received: from [98.138.90.54] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 08 Oct 2010 03:02:04 -0000 Received: from [98.138.89.249] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 08 Oct 2010 03:02:04 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 08 Oct 2010 03:02:04 -0000 X-Yahoo-Newman-Id: 27562.34930.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 99067 invoked from network); 8 Oct 2010 03:02:03 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 07 Oct 2010 20:02:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: K7y.yhUVM1lH7l8YGTwpK2x2hnINS0vb1wQG9TJeWrJlnIV SPXk5IoatVKYzuNiyscx4EkgzTkMBYo4Lu_MIvT_iSpA09p.hhumTzK5njy5 FVCfqnHvsl_oNWKC03AtRQ8DIduupwdcB6HLoJLsr7FLiYGO3SjSGaNGvaCu 1j55JdwFlTzith7d3qjvG7qtMmPVE3tn1uDAsBcbQPA2scyaG2djYDtYYhwh oEi.fBbyzAUmukAv0oCdMptvALATsCsTnfdgY.1SQOH1JUObrGLku._QCbBP dQ4s34Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CAE89AA.6060303@andybierman.com> Date: Thu, 07 Oct 2010 20:02:02 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Martin Bjorklund References: <20101005223856.GB6755@nsn.com> <20101008.000305.148115658.mbj@tail-f.com> In-Reply-To: <20101008.000305.148115658.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netmod@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 03:01:06 -0000 On 10/07/2010 03:03 PM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> I think there needs to be text added that none of the new NETMOD work >> can enhance/modify/alter 4741bis or RFC 6020 (YANG). >> All new charter items MUST be fully interoperable with implementations >> of 4741bis and/or YANG. No YANG extensions will be introduced which >> require a 4741bis server to be aware of the extension to achieve the >> correct behavior. > > I don't think we should add this to the charter. That does not mean > that I think that we should end up with YANG extensions, but if we do > need them we should not be limited by this charter. Also the term > "correct behavior" can be interpreted in many ways... > OK -- if the SMIv2 translation is limited to read-only then I am not worried about changing the NETCONF protocol at all. > > /martin Andy From phil@juniper.net Thu Oct 7 20:45:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AD93A67E1 for ; Thu, 7 Oct 2010 20:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5tthzYl6hYO for ; Thu, 7 Oct 2010 20:45:54 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id A26BA3A67A7 for ; Thu, 7 Oct 2010 20:45:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTK6ULZwRgbz1uJJ1SZJUaTXiSap7+bxH@postini.com; Thu, 07 Oct 2010 20:46:58 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 20:46:11 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o983kAU38126; Thu, 7 Oct 2010 20:46:10 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o983PRGU032881; Fri, 8 Oct 2010 03:25:27 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010080325.o983PRGU032881@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 7 Oct 2010 23:25:27 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 03:45:55 -0000 Andy Bierman writes: >There are many use-cases, not just 1. Absolutely. >(Your solution sounds less complicated than IPFIX by a mile.) Yup, and that's a good thing. >XPath is pretty good at needle-in-a-haystack data searches. >It doesn't matter how good your bulk transfer is if N is large enough. >You have to leave the haystack where it is at a certain point. You lost me in the haystack metaphor, but I guess my underlaying message is this: If we're suddenly turning our efforts to replicating 20 years of SNMP cruft in YANG, then I'm going to be extremely disappointed. This isn't about just having a better way to describe data, it's about what can be done when we can stop thinking about minor data encoding issues and start thinking about the data we are encoding, what it contains, and how to make that data more accurate, more timely, and more important. If NETCONF/YANG is just a new wineskin for the old wine, we've wasted an awful lot of time. Thanks, Phil From biermana@Brocade.com Thu Oct 7 22:42:15 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAAEC3A682C for ; Thu, 7 Oct 2010 22:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR3mMnkQRM8L for ; Thu, 7 Oct 2010 22:42:12 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 92D703A67E9 for ; Thu, 7 Oct 2010 22:42:12 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o985fAcZ024284; Thu, 7 Oct 2010 22:43:16 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id rsvuwr0mt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Oct 2010 22:43:15 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 22:47:08 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 7 Oct 2010 22:43:14 -0700 From: Andy Bierman To: Phil Shafer Date: Thu, 7 Oct 2010 22:43:13 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: Actmm3U9otrJsafUT+GFnpoYXuEciQADmivQ Message-ID: References: <201010080325.o983PRGU032881@idle.juniper.net> In-Reply-To: <201010080325.o983PRGU032881@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-08_02:2010-10-08, 2010-10-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010070225 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 05:42:15 -0000 Hi, I think Juergen will do a good job on the translation draft, and the starting point draft is good enough to get done quickly. I think a system.yang module would get done quickly, if that draft existed. The problem is interfaces.yang. How to support ifStackTable sort of layering? How to name interfaces? What standard knobs to interfaces have? What standard operational data do interfaces have? What new features to support? IMO, ignoring all the standards work that has been done for SNMP would be a big mistake. I don't know who has the energy or desire to rewrite lots of MIB modules for operational data. I would be happy with just an interfaces framework that didn't define any knobs, just naming and a 'home' for augmenting the generic interface with TBD standard and vendor objects. I am not talking about replicating SNMP interfaces data structures verbatim= . I agree with you that a new interfaces model is needed, but many details are already defined in MIBs from all kinds of organizations. Andy -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net]=20 Sent: Thursday, October 07, 2010 8:25 PM To: Andy Bierman Cc: Juergen Schoenwaelder; netmod@ietf.org; netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg=20 Andy Bierman writes: >There are many use-cases, not just 1. Absolutely. >(Your solution sounds less complicated than IPFIX by a mile.) Yup, and that's a good thing. >XPath is pretty good at needle-in-a-haystack data searches. >It doesn't matter how good your bulk transfer is if N is large enough. >You have to leave the haystack where it is at a certain point. You lost me in the haystack metaphor, but I guess my underlaying message is this: If we're suddenly turning our efforts to replicating 20 years of SNMP cruft in YANG, then I'm going to be extremely disappointed. This isn't about just having a better way to describe data, it's about what can be done when we can stop thinking about minor data encoding issues and start thinking about the data we are encoding, what it contains, and how to make that data more accurate, more timely, and more important. If NETCONF/YANG is just a new wineskin for the old wine, we've wasted an awful lot of time. Thanks, Phil From j.schoenwaelder@jacobs-university.de Thu Oct 7 23:36:01 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FF93A6835 for ; Thu, 7 Oct 2010 23:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv2MreACHzfp for ; Thu, 7 Oct 2010 23:36:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 322543A682E for ; Thu, 7 Oct 2010 23:36:00 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96455C0039; Fri, 8 Oct 2010 08:37:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4Iv2-wHatNe9; Fri, 8 Oct 2010 08:37:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32499C0015; Fri, 8 Oct 2010 08:37:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CC5761518F85; Fri, 8 Oct 2010 08:36:33 +0200 (CEST) Date: Fri, 8 Oct 2010 08:36:33 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101008063633.GB59583@elstar.local> Mail-Followup-To: Martin Bjorklund , "ietf@andybierman.com" , "netmod@ietf.org" , "biermana@Brocade.com" , "netconf-chairs@tools.ietf.org" References: <201010071540.o97FeiGg024762@idle.juniper.net> <4CADF8A2.1070706@andybierman.com> <20101007174611.GA58495@elstar.local> <20101008.001006.207941401.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101008.001006.207941401.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "biermana@Brocade.com" , "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 06:36:01 -0000 On Fri, Oct 08, 2010 at 12:10:06AM +0200, Martin Bjorklund wrote: > If we do this mapping, does that mean that all current SMIv2 modules > are magically available for normal YANG modules to use, or do we > require the translated modules to be published as RFCs? Once there is an agreed algorithm, I think it would be pointless to republish the translations. YANG can be translated to YIN and RNG and we stopped publishing the translations. So we should be able to do the same here. Having a repository where people can pick up already translated modules may be convenient, but that should not require complicated IETF actions. > If they are available w/o publication, can people start to import them > so they get typedefs from them? Is this something we want to recommend? I assume the number of typedefs you can use in a straight-forward manner for configuration modules is somewhat limited since some SMIv2 TCs do carry SNMP semantics or SNMP restrictions or they lack a canonical textual representation etc. I believe what we did with the core YANG data types in RFC 6021, namely creating YANG versions of common data types and being explicit about equivalent SMIv2 data types (where they exist) is likely a good workable approach of reuse for configuration modules. That said, the policy question you are raising, namely whether it is _allowed_ to import from a translated SMIv2 module which never got published in YANG format as an RFC, can be debated. I would argue this should be allowed if the translation is allocating namespaces that are properly registered etc. so that there can't be any bad side effects caused by name clashes or usage of not properly registered namespace identifiers. (But that is a solvable problem.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri Oct 8 01:33:43 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF883A684A for ; Fri, 8 Oct 2010 01:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy5-FfN3T+LR for ; Fri, 8 Oct 2010 01:33:43 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CB17D3A67A6 for ; Fri, 8 Oct 2010 01:33:42 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 962BD616013; Fri, 8 Oct 2010 10:34:45 +0200 (CEST) Date: Fri, 08 Oct 2010 10:34:45 +0200 (CEST) Message-Id: <20101008.103445.183095648.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20101008063633.GB59583@elstar.local> References: <20101007174611.GA58495@elstar.local> <20101008.001006.207941401.mbj@tail-f.com> <20101008063633.GB59583@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netconf-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 08:33:44 -0000 Hi, I would like to understand the use case for the result of this work item a bit better. Assuming we do this mapping, what signals does it send and what is the intended use case for the resulting YANG modules? Who is the NETCONF client in this case, and what is required from him? As an example, if we do a straight-forward translation of the data models, an OBJECT IDENTIFIER will probably be translated into yang:object-identifier-128, and OCTET STRING into binary. This means that the data will have to be processed by the client before it is presented to the user, just like a SNMP manager does. With RowPointers etc it also needs to be aware of if INDEXes are IMPLIED or not in order to correctly present the data. So is the use case really that we get a better transport than SNMP between an SNMP manager and a device? /martin From j.schoenwaelder@jacobs-university.de Fri Oct 8 02:06:10 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00ED43A6844 for ; Fri, 8 Oct 2010 02:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.006 X-Spam-Level: X-Spam-Status: No, score=-102.006 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cp7pVnEeOOK for ; Fri, 8 Oct 2010 02:06:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6E1F23A67A3 for ; Fri, 8 Oct 2010 02:06:08 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7279EC0015; Fri, 8 Oct 2010 11:07:12 +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 62Dy-8Bjuycn; Fri, 8 Oct 2010 11:07:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9587AC0039; Fri, 8 Oct 2010 11:07:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C89AE15193BF; Fri, 8 Oct 2010 11:06:42 +0200 (CEST) Date: Fri, 8 Oct 2010 11:06:42 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101008090641.GA60011@elstar.local> Mail-Followup-To: Martin Bjorklund , "ietf@andybierman.com" , "netmod@ietf.org" , "biermana@Brocade.com" , "netconf-chairs@tools.ietf.org" References: <20101007174611.GA58495@elstar.local> <20101008.001006.207941401.mbj@tail-f.com> <20101008063633.GB59583@elstar.local> <20101008.103445.183095648.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101008.103445.183095648.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "biermana@Brocade.com" , "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:06:10 -0000 On Fri, Oct 08, 2010 at 10:34:45AM +0200, Martin Bjorklund wrote: > Who is the NETCONF client in this case, and what is required from him? > As an example, if we do a straight-forward translation of the data > models, an OBJECT IDENTIFIER will probably be translated into > yang:object-identifier-128, and OCTET STRING into binary. This means > that the data will have to be processed by the client before it is > presented to the user, just like a SNMP manager does. You get the raw data in an XML document. The elements in the XML document are not OIDs but descriptors. There are several products out there today that do provide XML access to SNMP instrumentation because apparently there is a market for getting more efficient access to large amounts of data sitting in existing SNMP instrumentations. The representation of SNMP data in XML, however, is not defined and as such there is no interoperability. Making a NETCONF server access SNMP instrumentation is not a big development effort and I am sure this will be done. The question is whether we want to have one way of doing this (and then this is the right time to define it) or we are fine with having several different ways of doing it. To get back to your question: OID _values_ are relatively rare in MIB modules and a textual representation of OIDs in dotted format is not uncommon, (unfortunately) even in many SNMP applications. The translation of OCTET STRINGs might depend on DISPLAY-HINTs - they might not all be binary. > With RowPointers etc it also needs to be aware of if INDEXes are > IMPLIED or not in order to correctly present the data. Correct. It is still SNMP instrumentation and there is in my view no good way to beautify things without causing trouble. Thats why a config false translation makes sense, you do not want to carry SNMP limitations into configuration models. The config true thing generally does not work since SNMP has no notion of configuration data stores and no robust distinction between state and configuration objects. > So is the use case really that we get a better transport than SNMP > between an SNMP manager and a device? A better transport is a use case. Access to SNMP instrumentation in a _common_ XML format is another value on its own. Reuse of existing instrumentation isn't a bad idea either. There likely is also a long-term value in being able to access all information using one protocol with a single security / access control framework. If we do not define the translation now, I am sure we will end up with a collection of different translations soon and then agreeing on a common way will be much harder, if feasible at all. So we either work out a common translation now or we pretend that we rewrite all data models from scratch incorporating translations manually as needed, or we decide that a common way to access our legacy SNMP instrumentation is not a problem to warrants a common solution. Pick your choice. I have already taken mine. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri Oct 8 04:14:56 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EC63A6880 for ; Fri, 8 Oct 2010 04:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH4qjWrZrBMO for ; Fri, 8 Oct 2010 04:14:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 5FFB03A6841 for ; Fri, 8 Oct 2010 04:14:54 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0B9A12CDE05E for ; Fri, 8 Oct 2010 13:15:57 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20101007.235955.167534178.mbj@tail-f.com> References: <20101005223856.GB6755@nsn.com> <20101007.235955.167534178.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 08 Oct 2010 13:15:54 +0200 Message-ID: <1286536554.13533.2.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:14:56 -0000 On Čt, 2010-10-07 at 23:59 +0200, Martin Bjorklund wrote: > Hi, > > David Kessens wrote: > > Please see below for the current version of the proposed charter. > > [...] > > The NETMOD Working Group will initially work on the following items: > > > > 1. Core system data model > > 2. Core interface data model > > 3. Core routing data model that can be augmented with routing > > protocol specifics. This requires appropriate active editorial > > participation from routing experts. > > 4. SMIv2 translation to YANG > > I think the most interesting work ahead of us is starting to write > models both for the device and for the network, as we discussed in > Maastricht. Since network-wide config is not part of this charter, > does that mean that we must finish this before we start to work on > network-wide config? I think the design of device data models (2 and > 3 above) may be impacted by the larger picture with network data > models. +1 I am now looking at RPSL, which in fact is close to my understanding of network-wide configuration. It might be a useful exercise to try to express it in YANG. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Fri Oct 8 09:54:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985223A6887 for ; Fri, 8 Oct 2010 09:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG0M3Y2qb3XX for ; Fri, 8 Oct 2010 09:54:15 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 385A23A691F for ; Fri, 8 Oct 2010 09:54:15 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o98GtHmP008504; Fri, 8 Oct 2010 09:55:18 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id rt4u5039u-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 08 Oct 2010 09:55:18 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Oct 2010 09:59:48 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 8 Oct 2010 09:55:17 -0700 From: Andy Bierman To: Juergen Schoenwaelder , "Martin Bjorklund" Date: Fri, 8 Oct 2010 09:55:16 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActmyDM8Kh2kSfGTRKu64cw2QBVPWQAPIVpA Message-ID: References: <20101007174611.GA58495@elstar.local> <20101008.001006.207941401.mbj@tail-f.com> <20101008063633.GB59583@elstar.local> <20101008.103445.183095648.mbj@tail-f.com> <20101008090641.GA60011@elstar.local> In-Reply-To: <20101008090641.GA60011@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-08_12:2010-10-08, 2010-10-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080097 Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:54:16 -0000 Hi, We need to have a data modeling framework and an intuitive understanding of the data organization and meta-structure. We need to understand how IETF WGs are going to define data structures within this framework. The ipfix-psamp.yang module clearly shows the need to reference existing data structures in SMIv2. I do not think we can ignore ifIndex, entLogicalIndex, entPhysicalIndex, etc. in NETCONF data models. There is a need to easily correlate the operational data associated with specific configuration settings. If you set the port-profile to have loss-less service for COS '3', then which operational data nodes indicate the dropped frame counters for that port? How is the existing instrumentation going to be reused? When we agree on what we want to do with existing SNMP data, then we might also agree on the solution-space. But we have not defined the problem-spac= e. Why are we focusing on translating SMIv2 to YANG, when the bigger problem is the complete absence of an SNMP co-existence strategy? We should understand the coexistence framework first, and then the mechanics of the t= ranslation will seem less arbitrary. Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 08, 2010 2:07 AM To: Martin Bjorklund Cc: ietf@andybierman.com; netmod@ietf.org; Andy Bierman; netconf-chairs@too= ls.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg On Fri, Oct 08, 2010 at 10:34:45AM +0200, Martin Bjorklund wrote: =20 > Who is the NETCONF client in this case, and what is required from him? > As an example, if we do a straight-forward translation of the data > models, an OBJECT IDENTIFIER will probably be translated into > yang:object-identifier-128, and OCTET STRING into binary. This means > that the data will have to be processed by the client before it is > presented to the user, just like a SNMP manager does. =20 You get the raw data in an XML document. The elements in the XML document are not OIDs but descriptors. There are several products out there today that do provide XML access to SNMP instrumentation because apparently there is a market for getting more efficient access to large amounts of data sitting in existing SNMP instrumentations. The representation of SNMP data in XML, however, is not defined and as such there is no interoperability. Making a NETCONF server access SNMP instrumentation is not a big development effort and I am sure this will be done. The question is whether we want to have one way of doing this (and then this is the right time to define it) or we are fine with having several different ways of doing it. To get back to your question: OID _values_ are relatively rare in MIB modules and a textual representation of OIDs in dotted format is not uncommon, (unfortunately) even in many SNMP applications. The translation of OCTET STRINGs might depend on DISPLAY-HINTs - they might not all be binary. > With RowPointers etc it also needs to be aware of if INDEXes are > IMPLIED or not in order to correctly present the data. Correct. It is still SNMP instrumentation and there is in my view no good way to beautify things without causing trouble. Thats why a config false translation makes sense, you do not want to carry SNMP limitations into configuration models. The config true thing generally does not work since SNMP has no notion of configuration data stores and no robust distinction between state and configuration objects. > So is the use case really that we get a better transport than SNMP > between an SNMP manager and a device? A better transport is a use case. Access to SNMP instrumentation in a _common_ XML format is another value on its own. Reuse of existing instrumentation isn't a bad idea either. There likely is also a long-term value in being able to access all information using one protocol with a single security / access control framework. If we do not define the translation now, I am sure we will end up with a collection of different translations soon and then agreeing on a common way will be much harder, if feasible at all. So we either work out a common translation now or we pretend that we rewrite all data models from scratch incorporating translations manually as needed, or we decide that a common way to access our legacy SNMP instrumentation is not a problem to warrants a common solution. Pick your choice. I have already taken mine. ;-) /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 ietfdbh@comcast.net Fri Oct 8 12:22:27 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297FC3A692A for ; Fri, 8 Oct 2010 12:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv5UAszYoUoF for ; Fri, 8 Oct 2010 12:22:25 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 3A3383A6924 for ; Fri, 8 Oct 2010 12:22:25 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id GFnd1f0060bG4ec5DKPXju; Fri, 08 Oct 2010 19:23:31 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id GKPW1f0042JQnJT3PKPWi8; Fri, 08 Oct 2010 19:23:31 +0000 From: "David Harrington" To: "'Andy Bierman'" , "'Juergen Schoenwaelder'" , "'MartinBjorklund'" References: <20101007174611.GA58495@elstar.local><20101008.001006.207941401.mbj@tail-f.com><20101008063633.GB59583@elstar.local><20101008.103445.183095648.mbj@tail-f.com><20101008090641.GA60011@elstar.local> Date: Fri, 8 Oct 2010 15:22:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActmyDM8Kh2kSfGTRKu64cw2QBVPWQAPIVpAAAPyDHA= In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: netmod@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:22:27 -0000 Hi, I don't have time to personally get involved in long debates about an snmp/netconf coexistence architecture. My thoughts on the most effective netconf/netmod direction: 1) there is already lots of SNMP infrastructure, and I think operators are fine with SNMP/MIBs for monitoring the network devices. 2) SNMP configuration falls down on three major points a) SETs are not supported widely, because SNMPv1 was not secure and SNMPv3/USM/VACM is complex b) SETs do not align well with CLI-style configuration c) writing proprietary CLI-scripts is way way faster than standardizing MIB modules (MIBs are OBE) 3) Netconf configuration holds promise because: a) Netconf is secure using existing security infrstructure, hence less additional work than SNMPv3/USM b) Netconf is designed to align well with CLI-scripting configuration 4) Netconf will still face these issues: a) writing proprietary CLI-scripts is way way faster than standardizing YANG modules b) vendors have been clear they have no desire to standardize the CLI c) vendors need the ability to extend any configuration interface to support new proprietary features d) operators will need to monitor changes to operational state they have caused using Netconf. So I think YANG modules have a large barrier to adoption, just as SNMP SETs have. My suggestion going forward is to not reinvent the SNMP/MIB wheel. The MIB data models and SNMP already exist, and are widely deployed. For now, consider that problem solved; being able to read MIB data, whether read-only or read-write or read-create, using Netconf is simply not the highest priority. Focus on what has NOT been solved - getting some acceptable standardized data modeling for configuration. Focus on developing data models in YANG that align well with CLI-scripting configuration, and utilize the full feature set of YANG. You do not want to constrain yourselves to doing YANG models that align with SNMP models. The alignment with CLI-style configuration is far more important to get right. In the YANG model documentation, you can have a "Manageability Considerations" section that points out the need to be able to monitor the changes to operational state, and this can be done using appropriate management interfaces for monitoring, ***such as*** SNMP and existing MIB modules associated with the content of the YANG module. My recommendation is to name the associated MIB modules and possibly how specific MIB tables/objects relate to the specific YANG model structures. Many technologies, especially those from other SDOs like IEEE 802, have standard configurable properties, and it is expected that the vendor will write a CLI interface or configuration files or whatever to configure those properties. and then they define MIB modules to examine/monitor operational state. For years we have dealt with the fact that configuration tools and monitoring tools are separate. Many MIB modules monitor the operational state that results from configuration done using CLI interfaces. If the underlying technology has changed significantly from when it was modeled using MIB, then a YANG module to configure it might model it in quite a different manner than an existing MIB model of the technology, and you could write new MIB modules, or YANG monitoring modules, to monitor the updated technology. YANG modules should help define standard configurable properties of the underlying technologies, which would certainly include some things already modeled in MIBs, such as ifIndex. But think of ifIndex as being an abstract configurable property of the interfaces being managed, not just as a MIB object. my $.02 dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, October 08, 2010 12:55 PM > To: Juergen Schoenwaelder; MartinBjorklund > Cc: netconf-chairs@tools.ietf.org; netmod@ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg > > Hi, > > We need to have a data modeling framework and an intuitive > understanding of the data organization and meta-structure. > We need to understand how IETF WGs are going to define data > structures within this framework. > > The ipfix-psamp.yang module clearly shows the need to > reference existing data structures in SMIv2. I do not think > we can ignore ifIndex, entLogicalIndex, entPhysicalIndex, > etc. in NETCONF data models. > > There is a need to easily correlate the operational data > associated with specific configuration settings. If you set > the port-profile to have loss-less service for COS '3', then > which operational data nodes indicate the dropped frame > counters for that port? > > How is the existing instrumentation going to be reused? > > When we agree on what we want to do with existing SNMP data, > then we might also agree on the solution-space. But we have > not defined the problem-space. > > Why are we focusing on translating SMIv2 to YANG, when the > bigger problem is the complete absence of an SNMP > co-existence strategy? We should understand the coexistence > framework first, and then the mechanics of the translation > will seem less arbitrary. > > > > Andy > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 08, 2010 2:07 AM > To: Martin Bjorklund > Cc: ietf@andybierman.com; netmod@ietf.org; Andy Bierman; > netconf-chairs@tools.ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg > > On Fri, Oct 08, 2010 at 10:34:45AM +0200, Martin Bjorklund wrote: > > > Who is the NETCONF client in this case, and what is > required from him? > > As an example, if we do a straight-forward translation of the data > > models, an OBJECT IDENTIFIER will probably be translated into > > yang:object-identifier-128, and OCTET STRING into binary. > This means > > that the data will have to be processed by the client before it is > > presented to the user, just like a SNMP manager does. > > You get the raw data in an XML document. The elements in the > XML document are not OIDs but descriptors. There are several > products out there today that do provide XML access to SNMP > instrumentation because apparently there is a market for > getting more efficient access to large amounts of data > sitting in existing SNMP instrumentations. The representation > of SNMP data in XML, however, is not defined and as such > there is no interoperability. Making a NETCONF server access > SNMP instrumentation is not a big development effort and I am > sure this will be done. The question is whether we want to > have one way of doing this (and then this is the right time > to define it) or we are fine with having several different > ways of doing it. > > To get back to your question: OID _values_ are relatively > rare in MIB modules and a textual representation of OIDs in > dotted format is not uncommon, (unfortunately) even in many > SNMP applications. The translation of OCTET STRINGs might > depend on DISPLAY-HINTs - they might not all be binary. > > > With RowPointers etc it also needs to be aware of if INDEXes are > > IMPLIED or not in order to correctly present the data. > > Correct. It is still SNMP instrumentation and there is in my > view no good way to beautify things without causing trouble. > Thats why a config false translation makes sense, you do not > want to carry SNMP limitations into configuration models. The > config true thing generally does not work since SNMP has no > notion of configuration data stores and no robust distinction > between state and configuration objects. > > > So is the use case really that we get a better transport than SNMP > > between an SNMP manager and a device? > > A better transport is a use case. Access to SNMP > instrumentation in a _common_ XML format is another value on > its own. Reuse of existing instrumentation isn't a bad idea > either. There likely is also a long-term value in being able > to access all information using one protocol with a single > security / access control framework. > > If we do not define the translation now, I am sure we will > end up with a collection of different translations soon and > then agreeing on a common way will be much harder, if > feasible at all. So we either work out a common translation > now or we pretend that we rewrite all data models from > scratch incorporating translations manually as needed, or we > decide that a common way to access our legacy SNMP > instrumentation is not a problem to warrants a common solution. > > Pick your choice. I have already taken mine. ;-) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From biermana@Brocade.com Fri Oct 8 12:57:42 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D063A694A for ; Fri, 8 Oct 2010 12:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUaPyXZ8KN+G for ; Fri, 8 Oct 2010 12:57:40 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id C9E343A695B for ; Fri, 8 Oct 2010 12:57:39 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o98Jpl32002055; Fri, 8 Oct 2010 12:58:44 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id rt8ddg27r-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 08 Oct 2010 12:58:43 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Oct 2010 13:02:34 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Fri, 8 Oct 2010 12:58:40 -0700 From: Andy Bierman To: David Harrington , "'Juergen Schoenwaelder'" , "'MartinBjorklund'" Date: Fri, 8 Oct 2010 12:58:39 -0700 Thread-Topic: [netmod] Charter proposal for netmod wg Thread-Index: ActmyDM8Kh2kSfGTRKu64cw2QBVPWQAPIVpAAAPyDHAAAr8XEA== Message-ID: References: <20101007174611.GA58495@elstar.local><20101008.001006.207941401.mbj@tail-f.com><20101008063633.GB59583@elstar.local><20101008.103445.183095648.mbj@tail-f.com><20101008090641.GA60011@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-08_14:2010-10-08, 2010-10-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080129 Cc: "netmod@ietf.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:57:42 -0000 Hi, OK to avoiding long debates on coexistence frameworks, and the question "why are we doing this?" should be clear. You make many good points though. Looking at a concrete example like the ipfix-psamp YANG module, there is a YANG object that contains an ifIndex value. Nothing more. =20 1) Is this the level of SNMP data structure coupling we want? 2) Does inclusion of such an object mandate or just imply that SNMP can be used to retrieve the ifEntry, etc. for that ifIndex? 3) What if NETCONF application programmers do not want/need SNMP, but want small amounts of SNMP data during provisioning, etc.? (Another reason -- simplified security: NETCONF uses the same AAA as CLI). IMO, the best approach would be: A) Make new framework objects=20 Do not use exact 'ifEntry', 'entPhysicalEntry', etc.;=20 Create new scaffolding and naming B) Combine any 'old' leafs with any 'new' leafs that may be needed. =20 If a translated SMIv2 leaf is suitable for both configuration and=20 state (dual-mode), then complete reuse makes sense. C) Separate SMIv2 -> YANG naming translation from model translation D) Support 'object relation' meta-data with YANG extensions, such as the smi:oid extension defined in Juergen's draft. E) Support 'object relocation' functionality as an optional server capabil= ity; YANG data structures that represent the 'same' semantics and leaf-level= syntax as the SMIv2 definition. (Not clear if 100% fidelity is possible or nee= ded) - should be configurable - should be algorithmic (e.g., Juergen's smidump -fyang) At a minimum, we need a standard way to know where to find ifInOctets.1 in = NETCONF operational data, and a standard way to know if /interface[name=3D'eth0']/in-octets is = really the same as ifInOctets.1. Andy -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Friday, October 08, 2010 12:22 PM To: Andy Bierman; 'Juergen Schoenwaelder'; 'MartinBjorklund' Cc: netconf-chairs@tools.ietf.org; netmod@ietf.org Subject: RE: [netmod] Charter proposal for netmod wg Hi, I don't have time to personally get involved in long debates about an snmp/netconf coexistence architecture. My thoughts on the most effective netconf/netmod direction: 1) there is already lots of SNMP infrastructure, and I think operators are fine with SNMP/MIBs for monitoring the network devices. 2) SNMP configuration falls down on three major points=20 a) SETs are not supported widely, because SNMPv1 was not secure and SNMPv3/USM/VACM is complex=20 b) SETs do not align well with CLI-style configuration c) writing proprietary CLI-scripts is way way faster than standardizing MIB modules (MIBs are OBE) 3) Netconf configuration holds promise because: a) Netconf is secure using existing security infrstructure, hence less additional work than SNMPv3/USM b) Netconf is designed to align well with CLI-scripting configuration 4) Netconf will still face these issues: a) writing proprietary CLI-scripts is way way faster than standardizing YANG modules b) vendors have been clear they have no desire to standardize the CLI c) vendors need the ability to extend any configuration interface to support new proprietary features d) operators will need to monitor changes to operational state they have caused using Netconf. So I think YANG modules have a large barrier to adoption, just as SNMP SETs have. My suggestion going forward is to not reinvent the SNMP/MIB wheel. The MIB data models and SNMP already exist, and are widely deployed. For now, consider that problem solved; being able to read MIB data, whether read-only or read-write or read-create, using Netconf is simply not the highest priority. Focus on what has NOT been solved - getting some acceptable standardized data modeling for configuration.=20 Focus on developing data models in YANG that align well with CLI-scripting configuration, and utilize the full feature set of YANG. You do not want to constrain yourselves to doing YANG models that align with SNMP models. The alignment with CLI-style configuration is far more important to get right. In the YANG model documentation, you can have a "Manageability Considerations" section that points out the need to be able to monitor the changes to operational state, and this can be done using appropriate management interfaces for monitoring, ***such as*** SNMP and existing MIB modules associated with the content of the YANG module. My recommendation is to name the associated MIB modules and possibly how specific MIB tables/objects relate to the specific YANG model structures.=20 Many technologies, especially those from other SDOs like IEEE 802, have standard configurable properties, and it is expected that the vendor will write a CLI interface or configuration files or whatever to configure those properties. and then they define MIB modules to examine/monitor operational state. For years we have dealt with the fact that configuration tools and monitoring tools are separate. Many MIB modules monitor the operational state that results from configuration done using CLI interfaces.=20 If the underlying technology has changed significantly from when it was modeled using MIB, then a YANG module to configure it might model it in quite a different manner than an existing MIB model of the technology, and you could write new MIB modules, or YANG monitoring modules, to monitor the updated technology.=20 YANG modules should help define standard configurable properties of the underlying technologies, which would certainly include some things already modeled in MIBs, such as ifIndex. But think of ifIndex as being an abstract configurable property of the interfaces being managed, not just as a MIB object. my $.02 dbh > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, October 08, 2010 12:55 PM > To: Juergen Schoenwaelder; MartinBjorklund > Cc: netconf-chairs@tools.ietf.org; netmod@ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg >=20 > Hi, >=20 > We need to have a data modeling framework and an intuitive=20 > understanding of the data organization and meta-structure. =20 > We need to understand how IETF WGs are going to define data=20 > structures within this framework. >=20 > The ipfix-psamp.yang module clearly shows the need to=20 > reference existing data structures in SMIv2. I do not think=20 > we can ignore ifIndex, entLogicalIndex, entPhysicalIndex,=20 > etc. in NETCONF data models. >=20 > There is a need to easily correlate the operational data=20 > associated with specific configuration settings. If you set=20 > the port-profile to have loss-less service for COS '3', then=20 > which operational data nodes indicate the dropped frame=20 > counters for that port? >=20 > How is the existing instrumentation going to be reused? >=20 > When we agree on what we want to do with existing SNMP data,=20 > then we might also agree on the solution-space. But we have=20 > not defined the problem-space. >=20 > Why are we focusing on translating SMIv2 to YANG, when the=20 > bigger problem is the complete absence of an SNMP=20 > co-existence strategy? We should understand the coexistence=20 > framework first, and then the mechanics of the translation=20 > will seem less arbitrary. >=20 >=20 >=20 > Andy >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 08, 2010 2:07 AM > To: Martin Bjorklund > Cc: ietf@andybierman.com; netmod@ietf.org; Andy Bierman;=20 > netconf-chairs@tools.ietf.org > Subject: Re: [netmod] Charter proposal for netmod wg >=20 > On Fri, Oct 08, 2010 at 10:34:45AM +0200, Martin Bjorklund wrote: > =20 > > Who is the NETCONF client in this case, and what is=20 > required from him? > > As an example, if we do a straight-forward translation of the data > > models, an OBJECT IDENTIFIER will probably be translated into=20 > > yang:object-identifier-128, and OCTET STRING into binary. =20 > This means=20 > > that the data will have to be processed by the client before it is > > presented to the user, just like a SNMP manager does. >=20 > You get the raw data in an XML document. The elements in the=20 > XML document are not OIDs but descriptors. There are several=20 > products out there today that do provide XML access to SNMP=20 > instrumentation because apparently there is a market for=20 > getting more efficient access to large amounts of data=20 > sitting in existing SNMP instrumentations. The representation=20 > of SNMP data in XML, however, is not defined and as such=20 > there is no interoperability. Making a NETCONF server access=20 > SNMP instrumentation is not a big development effort and I am=20 > sure this will be done. The question is whether we want to=20 > have one way of doing this (and then this is the right time=20 > to define it) or we are fine with having several different=20 > ways of doing it. >=20 > To get back to your question: OID _values_ are relatively=20 > rare in MIB modules and a textual representation of OIDs in=20 > dotted format is not uncommon, (unfortunately) even in many=20 > SNMP applications. The translation of OCTET STRINGs might=20 > depend on DISPLAY-HINTs - they might not all be binary. >=20 > > With RowPointers etc it also needs to be aware of if INDEXes are=20 > > IMPLIED or not in order to correctly present the data. >=20 > Correct. It is still SNMP instrumentation and there is in my=20 > view no good way to beautify things without causing trouble.=20 > Thats why a config false translation makes sense, you do not=20 > want to carry SNMP limitations into configuration models. The=20 > config true thing generally does not work since SNMP has no=20 > notion of configuration data stores and no robust distinction=20 > between state and configuration objects. >=20 > > So is the use case really that we get a better transport than SNMP > > between an SNMP manager and a device? >=20 > A better transport is a use case. Access to SNMP=20 > instrumentation in a _common_ XML format is another value on=20 > its own. Reuse of existing instrumentation isn't a bad idea=20 > either. There likely is also a long-term value in being able=20 > to access all information using one protocol with a single=20 > security / access control framework. >=20 > If we do not define the translation now, I am sure we will=20 > end up with a collection of different translations soon and=20 > then agreeing on a common way will be much harder, if=20 > feasible at all. So we either work out a common translation=20 > now or we pretend that we rewrite all data models from=20 > scratch incorporating translations manually as needed, or we=20 > decide that a common way to access our legacy SNMP=20 > instrumentation is not a problem to warrants a common solution. >=20 > Pick your choice. I have already taken mine. ;-) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From saperia@jdscons.com Fri Oct 8 14:28:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DCE3A695D for ; Fri, 8 Oct 2010 14:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQpYqhhJs4yv for ; Fri, 8 Oct 2010 14:28:23 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 9B6C83A6953 for ; Fri, 8 Oct 2010 14:28:23 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o98LTPAR011538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 8 Oct 2010 16:29:26 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: Date: Fri, 8 Oct 2010 17:29:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101007174611.GA58495@elstar.local><20101008.001006.207941401.mbj@tail-f.com><20101008063633.GB59583@elstar.local><20101008.103445.183095648.mbj@tail-f.com><20101008090641.GA60011@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1081) Cc: "netconf-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Charter proposal for netmod wg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 21:28:25 -0000 I think with Dave's note and Andy's reply two approaches are defined. = One from my read uses the SNMP infrastructure for monitoring while the = other moves away by supporting it with new mechanisms and/or mapping. My view is that focus should be on solving the original problem first, = configuration. Management applications that are concerned with both = [configuration and monitoring] have dealt with the issue of = configuration and monitoring data in different formats and name spaces = for a long time. NETCONF could help move the field forward by making configuration = data/formats and name spaces more standard. Management applications = will still have to have device specific knowledge from vendor, model, = hardware/firmware, software revision before they can manage = configuration effectively. Some of the NETCONF/YANG mechanisms already = defined help. This is not a function of how the data are defined for the individual = device or even how it is carried to/from managed elements. The hard = problem will remain in the NMS. /jon On Oct 8, 2010, at 3:58 PM, Andy Bierman wrote: > Hi, >=20 > OK to avoiding long debates on coexistence frameworks, and the = question > "why are we doing this?" should be clear. You make many good points > though. >=20 > Looking at a concrete example like the ipfix-psamp YANG module, > there is a YANG object that contains an ifIndex value. Nothing more. >=20 > 1) Is this the level of SNMP data structure coupling we want? >=20 > 2) Does inclusion of such an object mandate or just imply that > SNMP can be used to retrieve the ifEntry, etc. for that ifIndex? >=20 > 3) What if NETCONF application programmers do not want/need SNMP, = but > want small amounts of SNMP data during provisioning, etc.? > (Another reason -- simplified security: NETCONF uses the same > AAA as CLI). >=20 > IMO, the best approach would be: >=20 > A) Make new framework objects=20 > Do not use exact 'ifEntry', 'entPhysicalEntry', etc.;=20 > Create new scaffolding and naming >=20 > B) Combine any 'old' leafs with any 'new' leafs that may be needed. =20= > If a translated SMIv2 leaf is suitable for both configuration and=20= > state (dual-mode), then complete reuse makes sense. >=20 > C) Separate SMIv2 -> YANG naming translation from model translation >=20 > D) Support 'object relation' meta-data with YANG extensions, such as > the smi:oid extension defined in Juergen's draft. >=20 > E) Support 'object relocation' functionality as an optional server = capability; > YANG data structures that represent the 'same' semantics and = leaf-level syntax > as the SMIv2 definition. (Not clear if 100% fidelity is possible or = needed) >=20 > - should be configurable > - should be algorithmic (e.g., Juergen's smidump -fyang) >=20 > At a minimum, we need a standard way to know where to find = ifInOctets.1 in NETCONF operational > data, and a standard way to know if /interface[name=3D'eth0']/in-octets = is really > the same as ifInOctets.1. >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, October 08, 2010 12:22 PM > To: Andy Bierman; 'Juergen Schoenwaelder'; 'MartinBjorklund' > Cc: netconf-chairs@tools.ietf.org; netmod@ietf.org > Subject: RE: [netmod] Charter proposal for netmod wg >=20 > Hi, >=20 > I don't have time to personally get involved in long debates about an > snmp/netconf coexistence architecture. > My thoughts on the most effective netconf/netmod direction: >=20 > 1) there is already lots of SNMP infrastructure, and I think operators > are fine with SNMP/MIBs for monitoring the network devices. >=20 > 2) SNMP configuration falls down on three major points=20 > a) SETs are not supported widely, because SNMPv1 was not > secure and SNMPv3/USM/VACM is complex=20 > b) SETs do not align well with CLI-style configuration > c) writing proprietary CLI-scripts is way way faster than > standardizing MIB modules (MIBs are OBE) >=20 > 3) Netconf configuration holds promise because: > a) Netconf is secure using existing security infrstructure, > hence less additional work than SNMPv3/USM > b) Netconf is designed to align well with CLI-scripting > configuration >=20 > 4) Netconf will still face these issues: > a) writing proprietary CLI-scripts is way way faster than > standardizing YANG modules > b) vendors have been clear they have no desire to standardize > the CLI > c) vendors need the ability to extend any configuration > interface to support new proprietary features > d) operators will need to monitor changes to operational state > they have caused using Netconf. >=20 > So I think YANG modules have a large barrier to adoption, just as SNMP > SETs have. >=20 > My suggestion going forward is to not reinvent the SNMP/MIB wheel. The > MIB data models and SNMP already exist, and are widely deployed. For > now, consider that problem solved; being able to read MIB data, > whether read-only or read-write or read-create, using Netconf is > simply not the highest priority. >=20 > Focus on what has NOT been solved - getting some acceptable > standardized data modeling for configuration.=20 > Focus on developing data models in YANG that align well with > CLI-scripting configuration, and utilize the full feature set of YANG. > You do not want to constrain yourselves to doing YANG models that > align with SNMP models. The alignment with CLI-style configuration is > far more important to get right. >=20 > In the YANG model documentation, you can have a "Manageability > Considerations" section that points out the need to be able to monitor > the changes to operational state, and this can be done using > appropriate management interfaces for monitoring, ***such as*** SNMP > and existing MIB modules associated with the content of the YANG > module. My recommendation is to name the associated MIB modules and > possibly how specific MIB tables/objects relate to the specific YANG > model structures.=20 >=20 > Many technologies, especially those from other SDOs like IEEE 802, > have standard configurable properties, and it is expected that the > vendor will write a CLI interface or configuration files or whatever > to configure those properties. and then they define MIB modules to > examine/monitor operational state. For years we have dealt with the > fact that configuration tools and monitoring tools are separate. Many > MIB modules monitor the operational state that results from > configuration done using CLI interfaces.=20 >=20 > If the underlying technology has changed significantly from when it > was modeled using MIB, then a YANG module to configure it might model > it in quite a different manner than an existing MIB model of the > technology, and you could write new MIB modules, or YANG monitoring > modules, to monitor the updated technology.=20 >=20 > YANG modules should help define standard configurable properties of > the underlying technologies, which would certainly include some things > already modeled in MIBs, such as ifIndex. But think of ifIndex as > being an abstract configurable property of the interfaces being > managed, not just as a MIB object. >=20 > my $.02 > dbh >=20 >=20 >> -----Original Message----- >> From: netmod-bounces@ietf.org=20 >> [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Friday, October 08, 2010 12:55 PM >> To: Juergen Schoenwaelder; MartinBjorklund >> Cc: netconf-chairs@tools.ietf.org; netmod@ietf.org >> Subject: Re: [netmod] Charter proposal for netmod wg >>=20 >> Hi, >>=20 >> We need to have a data modeling framework and an intuitive=20 >> understanding of the data organization and meta-structure. =20 >> We need to understand how IETF WGs are going to define data=20 >> structures within this framework. >>=20 >> The ipfix-psamp.yang module clearly shows the need to=20 >> reference existing data structures in SMIv2. I do not think=20 >> we can ignore ifIndex, entLogicalIndex, entPhysicalIndex,=20 >> etc. in NETCONF data models. >>=20 >> There is a need to easily correlate the operational data=20 >> associated with specific configuration settings. If you set=20 >> the port-profile to have loss-less service for COS '3', then=20 >> which operational data nodes indicate the dropped frame=20 >> counters for that port? >>=20 >> How is the existing instrumentation going to be reused? >>=20 >> When we agree on what we want to do with existing SNMP data,=20 >> then we might also agree on the solution-space. But we have=20 >> not defined the problem-space. >>=20 >> Why are we focusing on translating SMIv2 to YANG, when the=20 >> bigger problem is the complete absence of an SNMP=20 >> co-existence strategy? We should understand the coexistence=20 >> framework first, and then the mechanics of the translation=20 >> will seem less arbitrary. >>=20 >>=20 >>=20 >> Andy >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder=20 >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, October 08, 2010 2:07 AM >> To: Martin Bjorklund >> Cc: ietf@andybierman.com; netmod@ietf.org; Andy Bierman;=20 >> netconf-chairs@tools.ietf.org >> Subject: Re: [netmod] Charter proposal for netmod wg >>=20 >> On Fri, Oct 08, 2010 at 10:34:45AM +0200, Martin Bjorklund wrote: >>=20 >>> Who is the NETCONF client in this case, and what is=20 >> required from him? >>> As an example, if we do a straight-forward translation of the data >=20 >>> models, an OBJECT IDENTIFIER will probably be translated into=20 >>> yang:object-identifier-128, and OCTET STRING into binary. =20 >> This means=20 >>> that the data will have to be processed by the client before it is >=20 >>> presented to the user, just like a SNMP manager does. >>=20 >> You get the raw data in an XML document. The elements in the=20 >> XML document are not OIDs but descriptors. There are several=20 >> products out there today that do provide XML access to SNMP=20 >> instrumentation because apparently there is a market for=20 >> getting more efficient access to large amounts of data=20 >> sitting in existing SNMP instrumentations. The representation=20 >> of SNMP data in XML, however, is not defined and as such=20 >> there is no interoperability. Making a NETCONF server access=20 >> SNMP instrumentation is not a big development effort and I am=20 >> sure this will be done. The question is whether we want to=20 >> have one way of doing this (and then this is the right time=20 >> to define it) or we are fine with having several different=20 >> ways of doing it. >>=20 >> To get back to your question: OID _values_ are relatively=20 >> rare in MIB modules and a textual representation of OIDs in=20 >> dotted format is not uncommon, (unfortunately) even in many=20 >> SNMP applications. The translation of OCTET STRINGs might=20 >> depend on DISPLAY-HINTs - they might not all be binary. >>=20 >>> With RowPointers etc it also needs to be aware of if INDEXes are=20 >>> IMPLIED or not in order to correctly present the data. >>=20 >> Correct. It is still SNMP instrumentation and there is in my=20 >> view no good way to beautify things without causing trouble.=20 >> Thats why a config false translation makes sense, you do not=20 >> want to carry SNMP limitations into configuration models. The=20 >> config true thing generally does not work since SNMP has no=20 >> notion of configuration data stores and no robust distinction=20 >> between state and configuration objects. >>=20 >>> So is the use case really that we get a better transport than SNMP >=20 >>> between an SNMP manager and a device? >>=20 >> A better transport is a use case. Access to SNMP=20 >> instrumentation in a _common_ XML format is another value on=20 >> its own. Reuse of existing instrumentation isn't a bad idea=20 >> either. There likely is also a long-term value in being able=20 >> to access all information using one protocol with a single=20 >> security / access control framework. >>=20 >> If we do not define the translation now, I am sure we will=20 >> end up with a collection of different translations soon and=20 >> then agreeing on a common way will be much harder, if=20 >> feasible at all. So we either work out a common translation=20 >> now or we pretend that we rewrite all data models from=20 >> scratch incorporating translations manually as needed, or we=20 >> decide that a common way to access our legacy SNMP=20 >> instrumentation is not a problem to warrants a common solution. >>=20 >> Pick your choice. I have already taken mine. ;-) >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Mon Oct 11 05:32:45 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C423A6A0F for ; Mon, 11 Oct 2010 05:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arUkwTtUX662 for ; Mon, 11 Oct 2010 05:32:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 93EC73A6A05 for ; Mon, 11 Oct 2010 05:32:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,313,1283745600"; d="scan'208";a="211389393" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Oct 2010 08:32:40 -0400 X-IronPort-AV: E=Sophos;i="4.57,313,1283745600"; d="scan'208";a="521519799" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Oct 2010 08:32:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2010 14:32:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: YANG-Doctors Team - we need more volunteers Thread-Index: ActpQF/wjjo+TFl1TLurQDQkzVlWZA== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] YANG-Doctors Team - we need more volunteers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 12:32:46 -0000 A couple of month ago I sent to the list a call for volunteers for the YANG Doctors directorate (review team). As I was saying in that message ' it will be a closed group which will review documents and discuss YANG-related queries and issues. All YANG documents in the IETF will be directed to this team for expert review.' Up to now I received answers from Juergen, Bert, Andy, Martin and Jan Lindblad. Thanks to all! We need more volunteers, so please step ahead to become part of the team. I would expect at least all the documents authors and contributors to NETCONF and YANG to continue to support the evolution of YANG by becoming part of the YANG Doctors directorate.=20 I will go ahead in the meantime and establish the YANG Doctors mail list.=20 Thanks and Regards, Dan =20 From lhotka@cesnet.cz Mon Oct 11 11:09:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF31F3A6B52 for ; Mon, 11 Oct 2010 11:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJQEaKjt6NcK for ; Mon, 11 Oct 2010 11:09:57 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 8A9C33A6B51 for ; Mon, 11 Oct 2010 11:09:56 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id A27612CDE060; Mon, 11 Oct 2010 20:11:04 +0200 (CEST) From: Ladislav Lhotka To: "Romascanu, Dan (Dan)" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 11 Oct 2010 20:11:02 +0200 Message-ID: <1286820662.6284.2.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG-Doctors Team - we need more volunteers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 18:09:58 -0000 Hi Dan, I'd like to join the review team. Lada On Po, 2010-10-11 at 14:32 +0200, Romascanu, Dan (Dan) wrote: > A couple of month ago I sent to the list a call for volunteers for the > YANG Doctors directorate (review team). As I was saying in that message > ' it will be a closed group which will review documents and discuss > YANG-related queries and issues. All YANG documents in the IETF will be > directed to this team for expert review.' > > Up to now I received answers from Juergen, Bert, Andy, Martin and Jan > Lindblad. Thanks to all! We need more volunteers, so please step ahead > to become part of the team. I would expect at least all the documents > authors and contributors to NETCONF and YANG to continue to support the > evolution of YANG by becoming part of the YANG Doctors directorate. > > I will go ahead in the meantime and establish the YANG Doctors mail > list. > > Thanks and Regards, > > Dan > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dromasca@avaya.com Tue Oct 12 02:11:34 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FA73A6BBB for ; Tue, 12 Oct 2010 02:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsQvEsgaiu0H for ; Tue, 12 Oct 2010 02:11:32 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 92C053A6BC2 for ; Tue, 12 Oct 2010 02:11:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,319,1283745600"; d="scan'208";a="38640374" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 12 Oct 2010 05:11:56 -0400 X-IronPort-AV: E=Sophos;i="4.57,319,1283745600"; d="scan'208";a="525618438" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Oct 2010 05:11:55 -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: Tue, 12 Oct 2010 11:11:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Charter of NETMOD for external review - REQUIRED Thread-Index: Actp7YMVsNwys8E1QWC0iQA43wxJtg== From: "Romascanu, Dan (Dan)" To: Cc: netmod@ietf.org Subject: [netmod] New Charter of NETMOD for external review - REQUIRED X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 09:11:34 -0000 NETMOD WG Chairs, This is a gentle reminder that I need the revised text of the new charter of NETMOD in order to submit it for external review before Thursday, so that it can be discussed by the IESG in the telechat on 10/21. I know that some discussions continue, but I suggest that you can agree on a text by now and continue to debate details in the coming week, while the charter is in external review.=20 Do not forget to include the clarifications required by the IESG concerning the participation of the routing area experts.=20 Thanks and Regards, Dan From dromasca@avaya.com Tue Oct 12 02:20:51 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD5E3A6784 for ; Tue, 12 Oct 2010 02:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezpstg3LqGuy for ; Tue, 12 Oct 2010 02:20:50 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 0E0693A6765 for ; Tue, 12 Oct 2010 02:20:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,319,1283745600"; d="scan'208";a="211519357" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Oct 2010 05:22:01 -0400 X-IronPort-AV: E=Sophos;i="4.57,319,1283745600"; d="scan'208";a="525621521" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Oct 2010 05:22:00 -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: Tue, 12 Oct 2010 11:21:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time for a new NETMOD co-chair - Call for Nominations Thread-Index: Actp7uPkHCmpycXrQriNfm+opK1ozg== From: "Romascanu, Dan (Dan)" To: Cc: Ron Bonica Subject: [netmod] Time for a new NETMOD co-chair - Call for Nominations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 09:20:51 -0000 David Partain let me know that he decided to step down from his position of co-chair of the NETMOD WG because of changes in his day job priorities. Without David's contribution Netmod and YANG would simply not have happened. The whole community owes him a big THANK YOU for gathering support and pushing ahead with the idea of a DML for NETCONF, and leading the work from the start of the WG until today. I hope that David will continue to support the work with valuable guidance and contributions, not only during the transition process but also in the years to come.=20 I am opening for nominations the position of co-chair of NETMOD. Nominations and self-nominations are welcome. If you believe that you are up to the job and willing to serve, or you know somebody who is up to the job please let me know before Friday 10/22. I plan to run the interviews and decide on a new co-chair to work with David Kessens who is continuing on the job as soon as the nomination period ends, and I hope that we can complete the nomination and transition process before IETF-79.=20 Regards, Dan From david.kessens@nsn.com Tue Oct 12 22:33:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC6D3A6B90 for ; Tue, 12 Oct 2010 22:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxJ4bngpUjxM for ; Tue, 12 Oct 2010 22:33:56 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id B690C3A68B3 for ; Tue, 12 Oct 2010 22:33:55 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9D5Z4W2030565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Oct 2010 07:35:04 +0200 Received: from localhost6.localdomain6 ([10.138.48.208]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9D5YoUH004168 for ; Wed, 13 Oct 2010 07:34:53 +0200 Received: from localhost6.localdomain6 (localhost.localdomain [127.0.0.1]) by localhost6.localdomain6 (8.14.4/8.14.3) with ESMTP id o9D5YfCA032392 for ; Tue, 12 Oct 2010 22:34:41 -0700 Received: (from david@localhost) by localhost6.localdomain6 (8.14.4/8.14.4/Submit) id o9D5Y6a4032294 for netmod@ietf.org; Tue, 12 Oct 2010 22:34:06 -0700 X-Authentication-Warning: localhost6.localdomain6: david set sender to david.kessens@nsn.com using -f Date: Tue, 12 Oct 2010 22:34:06 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20101013053405.GE25284@nsn.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) Subject: [netmod] Brief Last Call: Charter proposal for netmod wg (10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 05:33:59 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Working Group, Please see below for a revised version of the proposed new netmod charter. I have tried to incorporate comments from the IESG and comments that seem to have wide spread support. I have also attached a diff file to make comparison with the previous version easy. As our Area Director explained in a previous mail, I don't have the luxury to do a lengthy Last Call as it is important to get a new charter in place before next IETF meeting. Therefore, I will need your comments on the mailing list that either (dis)approve of the current text or suggest text for improvements by the end of business on Thursday. As our timeline is quite short, it is extra important that I see a lot of comments from as many participants as possible. However, as also mentioned by Dan, if necessary, we will still have a little bit of extra time to do some more fine tuning after the Last Call has passed and before the charter is up for approval on the next IESG telechat on 10/21. This also means that we can theoretically still pull the proposed charter from consideration by the IESG after the Last Call has passed until 10/20. My intention is obviously not to do this but I want to mention this to make sure that people who might potentially have missed our very short deadline know that they can still speak up to allow me as chairperson to reassess whether we indeed reached our goal of rough consensus. Finally, I would like to thank David Partain for all the work he has done for the netmod working group. I don't think we would have been able to achieve our milestones as quick as we did without his dedication. Thanks! David Kessens --- NETCONF Data Modeling Language (netmod) ----------------------------- Last Modified: 2010-10-12 Current Status: Active Working Group Chairs: David Partain David Kessens Area Director: Dan Romascanu Mailing List Address: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will initially work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts. 4. SMIv2 translation to YANG for read-only operational data and notifications. Guidance will be provided on how to reference existing data structures in SMIv2 from YANG. The NETMOD Working Group will not work on another version of YANG. All new charter items must be fully interoperable with implementations of rfc 4741bis and/or rfc 6020. It will also not serve as a review team for YANG modules developed by other working groups. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Oct 2010 Submission of individual draft(s) of System data model draft Oct 2010 Submission of individual draft(s) of Interface data model Oct 2010 Submission of individual draft(s) of Routing data model Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG Dec 2010 Submit first working group draft of System data model draft Dec 2010 Submit first working group draft of Interface data model Dec 2010 Submit first working group draft of Routing data model Dec 2010 Submit first working group draft of SMIv2 translation to YANG Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2011 Submit System data model to the IESG (proposed standard) Aug 2011 Submit Interface data model to the IESG (proposed standard) Aug 2011 Submit Routing data model to the IESG (proposed standard) ---- --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff 3c3 < Last Modified: 2010-10-05 --- > Last Modified: 2010-10-12 38,42c38,45 < 4. SMIv2 translation to YANG < < The NETMOD Working Group will not work on another version of YANG. It < will also not serve as a review team for YANG modules developed by other < working groups. --- > 4. SMIv2 translation to YANG for read-only operational data and > notifications. Guidance will be provided on how to reference existing > data structures in SMIv2 from YANG. > > The NETMOD Working Group will not work on another version of YANG. All new > charter items must be fully interoperable with implementations of rfc > 4741bis and/or rfc 6020. It will also not serve as a review team for YANG > modules developed by other working groups. --cWoXeonUoKmBZSoM-- From dromasca@avaya.com Wed Oct 13 02:52:56 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302F33A692B for ; Wed, 13 Oct 2010 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9qM8xnUtnBF for ; Wed, 13 Oct 2010 02:52:48 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id EF8353A659C for ; Wed, 13 Oct 2010 02:52:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,324,1283745600"; d="scan'208";a="38823881" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 13 Oct 2010 05:53:59 -0400 X-IronPort-AV: E=Sophos;i="4.57,324,1283745600"; d="scan'208";a="522335271" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Oct 2010 05:53:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2010 11:53:07 +0200 Message-ID: In-Reply-To: <20101013053405.GE25284@nsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) Thread-Index: ActqmG0XNSAvFk0cQsSZUjdDqbe/zAAIs0CQ References: <20101013053405.GE25284@nsn.com> From: "Romascanu, Dan (Dan)" To: "David Kessens" , Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:52:57 -0000 Thanks, David.=20 Two comments.=20 1. I suggest to add to item #3 'and review at WGLC by the Routing Area WG'. =20 2. I need to send the new charter text to external review tomorrow by mid-day the latest - so please raise TODAY any critical issues that would require text changes before the IETF external review.=20 Thanks and Regards, Dan > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of David Kessens > Sent: Wednesday, October 13, 2010 7:34 AM > To: netmod@ietf.org > Subject: [netmod] Brief Last Call: Charter proposal for=20 > netmod wg(10/14/2010) >=20 >=20 > Working Group, >=20 > Please see below for a revised version of the proposed new=20 > netmod charter. >=20 > I have tried to incorporate comments from the IESG and=20 > comments that seem to have wide spread support. I have also=20 > attached a diff file to make comparison with the previous=20 > version easy. >=20 > As our Area Director explained in a previous mail, I don't=20 > have the luxury to do a lengthy Last Call as it is important=20 > to get a new charter in place before next IETF meeting.=20 > Therefore, I will need your comments on the mailing list that=20 > either (dis)approve of the current text or suggest text for=20 > improvements by the end of business on Thursday. As our=20 > timeline is quite short, it is extra important that I see a=20 > lot of comments from as many participants as possible. >=20 > However, as also mentioned by Dan, if necessary, we will=20 > still have a little bit of extra time to do some more fine=20 > tuning after the Last Call has passed and before the charter=20 > is up for approval on the next IESG telechat on 10/21. This=20 > also means that we can theoretically still pull the proposed=20 > charter from consideration by the IESG after the Last Call=20 > has passed until 10/20. My intention is obviously not to do=20 > this but I want to mention this to make sure that people who=20 > might potentially have missed our very short deadline know=20 > that they can still speak up to allow me as chairperson to=20 > reassess whether we indeed reached our goal of rough consensus. >=20 > Finally, I would like to thank David Partain for all the work=20 > he has done for the netmod working group. I don't think we=20 > would have been able to achieve our milestones as quick as we=20 > did without his dedication. >=20 > Thanks! >=20 > David Kessens > --- >=20 > NETCONF Data Modeling Language (netmod) > ----------------------------- > Last Modified: 2010-10-12 >=20 > Current Status: Active Working Group >=20 > Chairs:=20 > David Partain David Kessens=20 > >=20 > Area Director:=20 > Dan Romascanu >=20 > Mailing List > Address: netmod@ietf.org > To Subscribe: netmod-request@ietf.org > Archive: http://www.ietf.org/mail-archive/web/netmod/ >=20 > Description: >=20 > The NETCONF Working Group has completed a base protocol to be=20 > used for configuration management. However, the NETCONF=20 > protocol does not include a modeling language or accompanying=20 > rules that can be used to model the management information=20 > that is to be configured using NETCONF. The NETMOD working=20 > group has defined the data modeling language YANG but no IETF=20 > models exist yet. The purpose of the NETMOD working group is=20 > to support the ongoing deployment of YANG by developing a set=20 > of core YANG data models and other activities that will allow=20 > network operators to use YANG for configuration and=20 > management of network elements. >=20 > The NETMOD Working Group will initially work on the following items: >=20 > 1. Core system data model > 2. Core interface data model > 3. Core routing data model that can be augmented with routing > protocol specifics. This requires appropriate active editorial > participation from routing experts. > 4. SMIv2 translation to YANG for read-only operational data and > notifications. Guidance will be provided on how to=20 > reference existing > data structures in SMIv2 from YANG. >=20 > The NETMOD Working Group will not work on another version of=20 > YANG. All new charter items must be fully interoperable with=20 > implementations of rfc 4741bis and/or rfc 6020. It will also=20 > not serve as a review team for YANG modules developed by=20 > other working groups. >=20 > The WG will consult with the NETCONF working group to ensure=20 > that NETMOD's decision do not conflict with planned work in NETCONF. >=20 >=20 > Goals and Milestones: >=20 > Oct 2010 Submission of individual draft(s) of System data=20 > model draft > Oct 2010 Submission of individual draft(s) of Interface data model > Oct 2010 Submission of individual draft(s) of Routing data model > Oct 2010 Submission of individual draft(s) of SMIv2=20 > translation to YANG > Dec 2010 Submit first working group draft of System data model draft > Dec 2010 Submit first working group draft of Interface data model > Dec 2010 Submit first working group draft of Routing data model > Dec 2010 Submit first working group draft of SMIv2=20 > translation to YANG > Apr 2011 Submit SMIv2 to YANG translation to the IESG=20 > (proposed standard) > Apr 2011 Submit System data model to the IESG (proposed standard) > Aug 2011 Submit Interface data model to the IESG (proposed standard) > Aug 2011 Submit Routing data model to the IESG (proposed standard)=20 >=20 > ---- >=20 >=20 From mbj@tail-f.com Wed Oct 13 03:47:09 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A053A693D for ; Wed, 13 Oct 2010 03:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6twY7Q509ORQ for ; Wed, 13 Oct 2010 03:47:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E40B83A68FC for ; Wed, 13 Oct 2010 03:47:07 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 52FDF616001; Wed, 13 Oct 2010 12:48:22 +0200 (CEST) Date: Wed, 13 Oct 2010 12:48:21 +0200 (CEST) Message-Id: <20101013.124821.250999240.mbj@tail-f.com> To: dromasca@avaya.com From: Martin Bjorklund In-Reply-To: References: <20101013053405.GE25284@nsn.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 10:47:09 -0000 Hi, "Romascanu, Dan (Dan)" wrote: > 2. I need to send the new charter text to external review tomorrow by > mid-day the latest - so please raise TODAY any critical issues that > would require text changes before the IETF external review. I asked before if this charter excludes work on network-wide config. It seems it does. Does that mean that we must finish this proposed charter before we start to work on network-wide config in the WG? /martin > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: netmod-bounces@ietf.org > > [mailto:netmod-bounces@ietf.org] On Behalf Of David Kessens > > Sent: Wednesday, October 13, 2010 7:34 AM > > To: netmod@ietf.org > > Subject: [netmod] Brief Last Call: Charter proposal for > > netmod wg(10/14/2010) > > > > > > Working Group, > > > > Please see below for a revised version of the proposed new > > netmod charter. > > > > I have tried to incorporate comments from the IESG and > > comments that seem to have wide spread support. I have also > > attached a diff file to make comparison with the previous > > version easy. > > > > As our Area Director explained in a previous mail, I don't > > have the luxury to do a lengthy Last Call as it is important > > to get a new charter in place before next IETF meeting. > > Therefore, I will need your comments on the mailing list that > > either (dis)approve of the current text or suggest text for > > improvements by the end of business on Thursday. As our > > timeline is quite short, it is extra important that I see a > > lot of comments from as many participants as possible. > > > > However, as also mentioned by Dan, if necessary, we will > > still have a little bit of extra time to do some more fine > > tuning after the Last Call has passed and before the charter > > is up for approval on the next IESG telechat on 10/21. This > > also means that we can theoretically still pull the proposed > > charter from consideration by the IESG after the Last Call > > has passed until 10/20. My intention is obviously not to do > > this but I want to mention this to make sure that people who > > might potentially have missed our very short deadline know > > that they can still speak up to allow me as chairperson to > > reassess whether we indeed reached our goal of rough consensus. > > > > Finally, I would like to thank David Partain for all the work > > he has done for the netmod working group. I don't think we > > would have been able to achieve our milestones as quick as we > > did without his dedication. > > > > Thanks! > > > > David Kessens > > --- > > > > NETCONF Data Modeling Language (netmod) > > ----------------------------- > > Last Modified: 2010-10-12 > > > > Current Status: Active Working Group > > > > Chairs: > > David Partain David Kessens > > > > > > Area Director: > > Dan Romascanu > > > > Mailing List > > Address: netmod@ietf.org > > To Subscribe: netmod-request@ietf.org > > Archive: http://www.ietf.org/mail-archive/web/netmod/ > > > > Description: > > > > The NETCONF Working Group has completed a base protocol to be > > used for configuration management. However, the NETCONF > > protocol does not include a modeling language or accompanying > > rules that can be used to model the management information > > that is to be configured using NETCONF. The NETMOD working > > group has defined the data modeling language YANG but no IETF > > models exist yet. The purpose of the NETMOD working group is > > to support the ongoing deployment of YANG by developing a set > > of core YANG data models and other activities that will allow > > network operators to use YANG for configuration and > > management of network elements. > > > > The NETMOD Working Group will initially work on the following items: > > > > 1. Core system data model > > 2. Core interface data model > > 3. Core routing data model that can be augmented with routing > > protocol specifics. This requires appropriate active editorial > > participation from routing experts. > > 4. SMIv2 translation to YANG for read-only operational data and > > notifications. Guidance will be provided on how to > > reference existing > > data structures in SMIv2 from YANG. > > > > The NETMOD Working Group will not work on another version of > > YANG. All new charter items must be fully interoperable with > > implementations of rfc 4741bis and/or rfc 6020. It will also > > not serve as a review team for YANG modules developed by > > other working groups. > > > > The WG will consult with the NETCONF working group to ensure > > that NETMOD's decision do not conflict with planned work in NETCONF. > > > > > > Goals and Milestones: > > > > Oct 2010 Submission of individual draft(s) of System data > > model draft > > Oct 2010 Submission of individual draft(s) of Interface data model > > Oct 2010 Submission of individual draft(s) of Routing data model > > Oct 2010 Submission of individual draft(s) of SMIv2 > > translation to YANG > > Dec 2010 Submit first working group draft of System data model draft > > Dec 2010 Submit first working group draft of Interface data model > > Dec 2010 Submit first working group draft of Routing data model > > Dec 2010 Submit first working group draft of SMIv2 > > translation to YANG > > Apr 2011 Submit SMIv2 to YANG translation to the IESG > > (proposed standard) > > Apr 2011 Submit System data model to the IESG (proposed standard) > > Aug 2011 Submit Interface data model to the IESG (proposed standard) > > Aug 2011 Submit Routing data model to the IESG (proposed standard) > > > > ---- > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Wed Oct 13 04:02:59 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450103A6954 for ; Wed, 13 Oct 2010 04:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.073 X-Spam-Level: X-Spam-Status: No, score=-101.073 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_20=-0.74, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NIq5hmGdUpT for ; Wed, 13 Oct 2010 04:02:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 804703A68FC for ; Wed, 13 Oct 2010 04:02:57 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6904FC002F; Wed, 13 Oct 2010 13:04:13 +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 uGlclSRT7JTj; Wed, 13 Oct 2010 13:04:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9901AC0021; Wed, 13 Oct 2010 13:04:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1DB14152511C; Wed, 13 Oct 2010 13:03:42 +0200 (CEST) Date: Wed, 13 Oct 2010 13:03:42 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20101013110341.GC69745@elstar.local> Mail-Followup-To: Martin Bjorklund , dromasca@avaya.com, netmod@ietf.org References: <20101013053405.GE25284@nsn.com> <20101013.124821.250999240.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101013.124821.250999240.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 11:02:59 -0000 On Wed, Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund wrote: > I asked before if this charter excludes work on network-wide config. > It seems it does. Does that mean that we must finish this proposed > charter before we start to work on network-wide config in the WG? I think the unanswered question was whether it is this WG or another WG. For the rechartering text crafted at the last IETF meeting, I also recall that network-wide config was not too well understood and there were no concrete solution proposals to look at. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Oct 13 04:44:26 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98EC53A6A28 for ; Wed, 13 Oct 2010 04:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaYcXJ976K1Q for ; Wed, 13 Oct 2010 04:44:22 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B369E3A69EB for ; Wed, 13 Oct 2010 04:44:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,325,1283745600"; d="scan'208";a="242480142" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Oct 2010 07:45:19 -0400 X-IronPort-AV: E=Sophos;i="4.57,325,1283745600"; d="scan'208";a="526067095" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Oct 2010 07:44:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2010 13:44:24 +0200 Message-ID: In-Reply-To: <20101013110341.GC69745@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) Thread-Index: ActqxnXXWxKoFyN+SLOqWDuygl1A0QABP8fQ References: <20101013053405.GE25284@nsn.com> <20101013.124821.250999240.mbj@tail-f.com> <20101013110341.GC69745@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 11:44:27 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Wednesday, October 13, 2010 1:04 PM > To: Martin Bjorklund > Cc: Romascanu, Dan (Dan); netmod@ietf.org > Subject: Re: [netmod] Brief Last Call: Charter proposal for=20 > netmod wg(10/14/2010) >=20 > On Wed, Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund wrote: > =20 > > I asked before if this charter excludes work on network-wide config. > > It seems it does. Does that mean that we must finish this proposed=20 > > charter before we start to work on network-wide config in the WG? >=20 > I think the unanswered question was whether it is this WG or=20 > another WG. For the rechartering text crafted at the last=20 > IETF meeting, I also recall that network-wide config was not=20 > too well understood and there were no concrete solution=20 > proposals to look at. >=20 > /js >=20 I remember that somebody (was this Phil? ) too an action item to write a document that would include a problem statement as well as point to a possible scope of work, which was identified during out Maastricht bar-BOF discussions.=20 For the purpose of this WG rechartering, I think it's too early for inclusion in the charter, but nothing prevents individuals to work on network-wide config, and the mail list and some time at the end of the WG meetings could be used for this work.=20 Dan From ietf@andybierman.com Wed Oct 13 06:25:26 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C291C3A6930 for ; Wed, 13 Oct 2010 06:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGzE51O9wfkt for ; Wed, 13 Oct 2010 06:25:22 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 03BA73A6899 for ; Wed, 13 Oct 2010 06:25:21 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o9DDQbY3011670 for ; Wed, 13 Oct 2010 09:26:37 -0400 Authentication-Results: cm-omr7 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [70.0.209.50] ([70.0.209.50:60690] helo=[70.0.209.50]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E4/D9-09923-B83B5BC4; Wed, 13 Oct 2010 09:26:37 -0400 To: "=?utf-8?B?Um9tYXNjYW51LCBEYW4gKERhbik=?=" , "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" , "=?utf-8?B?TWFydGluIEJqb3JrbHVuZA==?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 13 Oct 2010 06:26:50 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6_1286976410529" Cc: netmod@ietf.org Subject: Re: [netmod] =?utf-8?q?Brief_Last_Call=3A_Charter_proposal_for_netmod?= =?utf-8?b?CXdnKDEwLzE0LzIwMTAp?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:25:26 -0000 ------=_Part_6_1286976410529 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IG5ldHdvcmsgd2lkZSBjb25maWcgaXMgbm90IHJlYWR5IGZv ciBhIFdHLgpJdCBpcyBub3QgY2xlYXIgdGhhdCBzeXN0ZW0gb3IgaW50ZXJmYWNlcyBtb2R1bGVz IGFyZSByZWFkeSBlaXRoZXIuClRoZXJlIGFyZSBubyBzdGFydGluZyBkb2N1bWVudHMuIFRoZXJl IGFyZSBubyBleHBlcnQgYXV0aG9ycyBzaWduZWQgdXAuIEV2ZW4gd2l0aCBTTUkgdHJhbnNsYXRp b24gdGhlcmUgaXMgbm8gY2xlYXIgY29uc2Vuc3VzIG9uIHRoZSBwcm9ibGVtIHRoYXQgbmVlZHMg dG8gYmUgc29sdmVkLgpJTU8sIG5vdGhpbmcgaW4gdGhpcyBjaGFydGVyIGlzIHJlYWxseSByZWFk eSBmb3Igc3RhbmRhcmRpemF0aW9uLgoKQW5keQoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpG cm9tOiAiUm9tYXNjYW51LCBEYW4gKERhbikiIDxkcm9tYXNjYUBhdmF5YS5jb20+CkRhdGU6IFdl ZCwgT2N0IDEzLCAyMDEwIDA0OjQ0ClN1YmplY3Q6IFtuZXRtb2RdIEJyaWVmIExhc3QgQ2FsbDog Q2hhcnRlciBwcm9wb3NhbCBmb3IgbmV0bW9kCXdnKDEwLzE0LzIwMTApClRvOiAiSnVlcmdlbiBT Y2hvZW53YWVsZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiwgIk1h cnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1mLmNvbT4KQ2M6IDxuZXRtb2RAaWV0Zi5vcmc+CgoK IAoKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2Fl bGRlciAKPiBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gCj4g U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEzLCAyMDEwIDE6MDQgUE0KPiBUbzogTWFydGluIEJq b3JrbHVuZAo+IENjOiBSb21hc2NhbnUsIERhbiAoRGFuKTsgbmV0bW9kQGlldGYub3JnCj4gU3Vi amVjdDogUmU6IFtuZXRtb2RdIEJyaWVmIExhc3QgQ2FsbDogQ2hhcnRlciBwcm9wb3NhbCBmb3Ig Cj4gbmV0bW9kIHdnKDEwLzE0LzIwMTApCj4gCj4gT24gV2VkLCBPY3QgMTMsIDIwMTAgYXQgMTI6 NDg6MjFQTSArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToKPiAgCj4gPiBJIGFza2VkIGJl Zm9yZSBpZiB0aGlzIGNoYXJ0ZXIgZXhjbHVkZXMgd29yayBvbiBuZXR3b3JrLXdpZGUgY29uZmln Lgo+ID4gSXQgc2VlbXMgaXQgZG9lcy4gIERvZXMgdGhhdCBtZWFuIHRoYXQgd2UgbXVzdCBmaW5p c2ggdGhpcyBwcm9wb3NlZCAKPiA+IGNoYXJ0ZXIgYmVmb3JlIHdlIHN0YXJ0IHRvIHdvcmsgb24g bmV0d29yay13aWRlIGNvbmZpZyBpbiB0aGUgV0c/Cj4gCj4gSSB0aGluayB0aGUgdW5hbnN3ZXJl ZCBxdWVzdGlvbiB3YXMgd2hldGhlciBpdCBpcyB0aGlzIFdHIG9yIAo+IGFub3RoZXIgV0cuIEZv ciB0aGUgcmVjaGFydGVyaW5nIHRleHQgY3JhZnRlZCBhdCB0aGUgbGFzdCAKPiBJRVRGIG1lZXRp bmcsIEkgYWxzbyByZWNhbGwgdGhhdCBuZXR3b3JrLXdpZGUgY29uZmlnIHdhcyBub3QgCj4gdG9v IHdlbGwgdW5kZXJzdG9vZCBhbmQgdGhlcmUgd2VyZSBubyBjb25jcmV0ZSBzb2x1dGlvbiAKPiBw cm9wb3NhbHMgdG8gbG9vayBhdC4KPiAKPiAvanMKPiAKCkkgcmVtZW1iZXIgdGhhdCBzb21lYm9k eSAod2FzIHRoaXMgUGhpbD8gKSB0b28gYW4gYWN0aW9uIGl0ZW0gdG8gd3JpdGUgYQpkb2N1bWVu dCB0aGF0IHdvdWxkIGluY2x1ZGUgYSBwcm9ibGVtIHN0YXRlbWVudCBhcyB3ZWxsIGFzIHBvaW50 IHRvIGEKcG9zc2libGUgc2NvcGUgb2Ygd29yaywgd2hpY2ggd2FzIGlkZW50aWZpZWQgZHVyaW5n IG91dCBNYWFzdHJpY2h0CmJhci1CT0YgZGlzY3Vzc2lvbnMuIAoKRm9yIHRoZSBwdXJwb3NlIG9m IHRoaXMgV0cgcmVjaGFydGVyaW5nLCBJIHRoaW5rIGl0J3MgdG9vIGVhcmx5IGZvcgppbmNsdXNp b24gaW4gdGhlIGNoYXJ0ZXIsIGJ1dCBub3RoaW5nIHByZXZlbnRzIGluZGl2aWR1YWxzIHRvIHdv cmsgb24KbmV0d29yay13aWRlIGNvbmZpZywgYW5kIHRoZSBtYWlsIGxpc3QgYW5kIHNvbWUgdGlt ZSBhdCB0aGUgZW5kIG9mIHRoZQpXRyBtZWV0aW5ncyBjb3VsZCBiZSB1c2VkIGZvciB0aGlzIHdv cmsuIAoKRGFuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCgo= ------=_Part_6_1286976410529 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IG5ldHdvcmsgd2lkZSBjb25maWcgaXMgbm90IHJlYWR5IGZv ciBhIFdHLjxicj5JdCBpcyBub3QgY2xlYXIgdGhhdCBzeXN0ZW0gb3IgaW50ZXJmYWNlcyBtb2R1 bGVzIGFyZSByZWFkeSBlaXRoZXIuPGJyPlRoZXJlIGFyZSBubyBzdGFydGluZyBkb2N1bWVudHMu IFRoZXJlIGFyZSBubyBleHBlcnQgYXV0aG9ycyBzaWduZWQgdXAuIEV2ZW4gd2l0aCBTTUkgdHJh bnNsYXRpb24gdGhlcmUgaXMgbm8gY2xlYXIgY29uc2Vuc3VzIG9uIHRoZSBwcm9ibGVtIHRoYXQg bmVlZHMgdG8gYmUgc29sdmVkLjxicj5JTU8sIG5vdGhpbmcgaW4gdGhpcyBjaGFydGVyIGlzIHJl YWxseSByZWFkeSBmb3Igc3RhbmRhcmRpemF0aW9uLjxicj48YnI+QW5keTxicj48YnI+LS0tLS0g UmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtSb21hc2NhbnUsIERhbiAoRGFuKSZx dW90OyAmbHQ7ZHJvbWFzY2FAYXZheWEuY29tJmd0Ozxicj5EYXRlOiBXZWQsIE9jdCAxMywgMjAx MCAwNDo0NDxicj5TdWJqZWN0OiBbbmV0bW9kXSBCcmllZiBMYXN0IENhbGw6IENoYXJ0ZXIgcHJv cG9zYWwgZm9yIG5ldG1vZAl3ZygxMC8xNC8yMDEwKTxicj5UbzogJnF1b3Q7SnVlcmdlbiBTY2hv ZW53YWVsZGVyJnF1b3Q7ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUm Z3Q7LCAmcXVvdDtNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7ICZsdDttYmpAdGFpbC1mLmNvbSZndDs8 YnI+Q2M6ICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPjxicj48YnI+IDxicj48YnI+Jmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IEp1ZXJnZW4gU2Nob2Vud2Fl bGRlciA8YnI+Jmd0OyBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k ZV0gPGJyPiZndDsgU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEzLCAyMDEwIDE6MDQgUE08YnI+ Jmd0OyBUbzogTWFydGluIEJqb3JrbHVuZDxicj4mZ3Q7IENjOiBSb21hc2NhbnUsIERhbiAoRGFu KTsgbmV0bW9kQGlldGYub3JnPGJyPiZndDsgU3ViamVjdDogUmU6IFtuZXRtb2RdIEJyaWVmIExh c3QgQ2FsbDogQ2hhcnRlciBwcm9wb3NhbCBmb3IgPGJyPiZndDsgbmV0bW9kIHdnKDEwLzE0LzIw MTApPGJyPiZndDsgPGJyPiZndDsgT24gV2VkLCBPY3QgMTMsIDIwMTAgYXQgMTI6NDg6MjFQTSAr MDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZTo8YnI+Jmd0OyAmbmJzcDs8YnI+Jmd0OyAmZ3Q7 IEkgYXNrZWQgYmVmb3JlIGlmIHRoaXMgY2hhcnRlciBleGNsdWRlcyB3b3JrIG9uIG5ldHdvcmst d2lkZSBjb25maWcuPGJyPiZndDsgJmd0OyBJdCBzZWVtcyBpdCBkb2VzLiAmbmJzcDtEb2VzIHRo YXQgbWVhbiB0aGF0IHdlIG11c3QgZmluaXNoIHRoaXMgcHJvcG9zZWQgPGJyPiZndDsgJmd0OyBj aGFydGVyIGJlZm9yZSB3ZSBzdGFydCB0byB3b3JrIG9uIG5ldHdvcmstd2lkZSBjb25maWcgaW4g dGhlIFdHPzxicj4mZ3Q7IDxicj4mZ3Q7IEkgdGhpbmsgdGhlIHVuYW5zd2VyZWQgcXVlc3Rpb24g d2FzIHdoZXRoZXIgaXQgaXMgdGhpcyBXRyBvciA8YnI+Jmd0OyBhbm90aGVyIFdHLiBGb3IgdGhl IHJlY2hhcnRlcmluZyB0ZXh0IGNyYWZ0ZWQgYXQgdGhlIGxhc3QgPGJyPiZndDsgSUVURiBtZWV0 aW5nLCBJIGFsc28gcmVjYWxsIHRoYXQgbmV0d29yay13aWRlIGNvbmZpZyB3YXMgbm90IDxicj4m Z3Q7IHRvbyB3ZWxsIHVuZGVyc3Rvb2QgYW5kIHRoZXJlIHdlcmUgbm8gY29uY3JldGUgc29sdXRp b24gPGJyPiZndDsgcHJvcG9zYWxzIHRvIGxvb2sgYXQuPGJyPiZndDsgPGJyPiZndDsgL2pzPGJy PiZndDsgPGJyPjxicj5JIHJlbWVtYmVyIHRoYXQgc29tZWJvZHkgKHdhcyB0aGlzIFBoaWw/ICkg dG9vIGFuIGFjdGlvbiBpdGVtIHRvIHdyaXRlIGE8YnI+ZG9jdW1lbnQgdGhhdCB3b3VsZCBpbmNs dWRlIGEgcHJvYmxlbSBzdGF0ZW1lbnQgYXMgd2VsbCBhcyBwb2ludCB0byBhPGJyPnBvc3NpYmxl IHNjb3BlIG9mIHdvcmssIHdoaWNoIHdhcyBpZGVudGlmaWVkIGR1cmluZyBvdXQgTWFhc3RyaWNo dDxicj5iYXItQk9GIGRpc2N1c3Npb25zLiA8YnI+PGJyPkZvciB0aGUgcHVycG9zZSBvZiB0aGlz IFdHIHJlY2hhcnRlcmluZywgSSB0aGluayBpdCYjMzk7cyB0b28gZWFybHkgZm9yPGJyPmluY2x1 c2lvbiBpbiB0aGUgY2hhcnRlciwgYnV0IG5vdGhpbmcgcHJldmVudHMgaW5kaXZpZHVhbHMgdG8g d29yayBvbjxicj5uZXR3b3JrLXdpZGUgY29uZmlnLCBhbmQgdGhlIG1haWwgbGlzdCBhbmQgc29t ZSB0aW1lIGF0IHRoZSBlbmQgb2YgdGhlPGJyPldHIG1lZXRpbmdzIGNvdWxkIGJlIHVzZWQgZm9y IHRoaXMgd29yay4gPGJyPjxicj5EYW48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+bmV0bW9kIG1haWxpbmcgbGlzdDxicj5uZXRtb2RAaWV0Zi5v cmc8YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj48 YnI+PGJyPjxicj4= ------=_Part_6_1286976410529-- From dromasca@avaya.com Wed Oct 13 06:31:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC973A6A9F for ; Wed, 13 Oct 2010 06:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXyj402gQg-E for ; Wed, 13 Oct 2010 06:31:53 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id CC31F3A6AC3 for ; Wed, 13 Oct 2010 06:31:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,325,1283745600"; d="scan'208,217";a="38852671" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 13 Oct 2010 09:33:08 -0400 X-IronPort-AV: E=Sophos;i="4.57,325,1283745600"; d="scan'208,217";a="522413884" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Oct 2010 09:32:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6ADB.0B783FFF" Date: Wed, 13 Oct 2010 15:32:12 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) Thread-Index: Actq2mNohAZTvexHRWqHaus6sLF5OgAAEFaQ References: From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Juergen Schoenwaelder" , "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:31:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6ADB.0B783FFF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would suggest that the WG makes an effort to overcome this situation, identify contributors, issue the starting documents. It would be a great mistake to stop or pause at this point. =20 Dan =20 ________________________________ From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Wednesday, October 13, 2010 3:27 PM To: Romascanu, Dan (Dan); Juergen Schoenwaelder; Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) =09 =09 I agree with you that network wide config is not ready for a WG. It is not clear that system or interfaces modules are ready either. There are no starting documents. There are no expert authors signed up. Even with SMI translation there is no clear consensus on the problem that needs to be solved. IMO, nothing in this charter is really ready for standardization. =09 Andy =09 ----- Reply message ----- From: "Romascanu, Dan (Dan)" Date: Wed, Oct 13, 2010 04:44 Subject: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) To: "Juergen Schoenwaelder" , "Martin Bjorklund" Cc: =09 =09 =09 =09 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Wednesday, October 13, 2010 1:04 PM > To: Martin Bjorklund > Cc: Romascanu, Dan (Dan); netmod@ietf.org > Subject: Re: [netmod] Brief Last Call: Charter proposal for=20 > netmod wg(10/14/2010) >=20 > On Wed, Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund wrote: > =20 > > I asked before if this charter excludes work on network-wide config. > > It seems it does. Does that mean that we must finish this proposed=20 > > charter before we start to work on network-wide config in the WG? >=20 > I think the unanswered question was whether it is this WG or=20 > another WG. For the rechartering text crafted at the last=20 > IETF meeting, I also recall that network-wide config was not=20 > too well understood and there were no concrete solution=20 > proposals to look at. >=20 > /js >=20 =09 I remember that somebody (was this Phil? ) too an action item to write a document that would include a problem statement as well as point to a possible scope of work, which was identified during out Maastricht bar-BOF discussions.=20 =09 For the purpose of this WG rechartering, I think it's too early for inclusion in the charter, but nothing prevents individuals to work on network-wide config, and the mail list and some time at the end of the WG meetings could be used for this work.=20 =09 Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod =09 =09 =09 =09 ------_=_NextPart_001_01CB6ADB.0B783FFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 would suggest that the WG makes an effort to overcome this situation, = identify=20 contributors, issue the starting documents. It would be a great mistake = to stop=20 or pause at this point.
 
Dan
 

From: Andy Bierman=20 [mailto:ietf@andybierman.com]
Sent: Wednesday, October 13, = 2010=20 3:27 PM
To: Romascanu, Dan (Dan); Juergen Schoenwaelder; = Martin=20 Bjorklund
Cc: netmod@ietf.org
Subject: Re: = [netmod] Brief=20 Last Call: Charter proposal for netmod = wg(10/14/2010)

I agree with you that network wide config is not ready for = a=20 WG.
It is not clear that system or interfaces modules are ready=20 either.
There are no starting documents. There are no expert = authors signed=20 up. Even with SMI translation there is no clear consensus on the = problem that=20 needs to be solved.
IMO, nothing in this charter is really ready = for=20 standardization.

Andy

----- Reply message -----
From: = "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Date: Wed, Oct = 13, 2010=20 04:44
Subject: [netmod] Brief Last Call: Charter proposal for = netmod=20 wg(10/14/2010)
To: "Juergen Schoenwaelder"=20 <j.schoenwaelder@jacobs-university.de>, "Martin Bjorklund"=20 <mbj@tail-f.com>
Cc: = <netmod@ietf.org>




>=20 -----Original Message-----
> From: Juergen Schoenwaelder =
>=20 [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: = Wednesday,=20 October 13, 2010 1:04 PM
> To: Martin Bjorklund
> Cc: = Romascanu,=20 Dan (Dan); netmod@ietf.org
> Subject: Re: [netmod] Brief Last = Call:=20 Charter proposal for
> netmod wg(10/14/2010)
>
> = On Wed,=20 Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund wrote:
>=20  
> > I asked before if this charter excludes work on=20 network-wide config.
> > It seems it does.  Does that = mean that=20 we must finish this proposed
> > charter before we start to = work on=20 network-wide config in the WG?
>
> I think the unanswered = question was whether it is this WG or
> another WG. For the=20 rechartering text crafted at the last
> IETF meeting, I also = recall=20 that network-wide config was not
> too well understood and = there were=20 no concrete solution
> proposals to look at.
>
>=20 /js
>

I remember that somebody (was this Phil? ) too an = action=20 item to write a
document that would include a problem statement as = well as=20 point to a
possible scope of work, which was identified during out=20 Maastricht
bar-BOF discussions.

For the purpose of this WG=20 rechartering, I think it's too early for
inclusion in the charter, = but=20 nothing prevents individuals to work on
network-wide config, and = the mail=20 list and some time at the end of the
WG meetings could be used for = this=20 work. =

Dan
_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod



------_=_NextPart_001_01CB6ADB.0B783FFF-- From lhotka@cesnet.cz Wed Oct 13 07:40:28 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C9F3A6956 for ; Wed, 13 Oct 2010 07:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh4zjn2UC5sL for ; Wed, 13 Oct 2010 07:37:41 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 832F23A6954 for ; Wed, 13 Oct 2010 07:37:40 -0700 (PDT) Received: from [192.168.2.8] (unknown [78.156.128.19]) by office2.cesnet.cz (Postfix) with ESMTPSA id 8E2A92CDE058 for ; Wed, 13 Oct 2010 16:38:55 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20101013053405.GE25284@nsn.com> References: <20101013053405.GE25284@nsn.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 13 Oct 2010 16:38:54 +0200 Message-ID: <1286980734.7051.39.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg (10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 14:40:29 -0000 Hi, I am fine with this charter. Lada On Út, 2010-10-12 at 22:34 -0700, David Kessens wrote: > Working Group, > > Please see below for a revised version of the proposed new netmod charter. > > I have tried to incorporate comments from the IESG and comments that seem to > have wide spread support. I have also attached a diff file to make > comparison with the previous version easy. > > As our Area Director explained in a previous mail, I don't have the luxury > to do a lengthy Last Call as it is important to get a new charter in place > before next IETF meeting. Therefore, I will need your comments on the > mailing list that either (dis)approve of the current text or suggest text > for improvements by the end of business on Thursday. As our timeline is > quite short, it is extra important that I see a lot of comments from as many > participants as possible. > > However, as also mentioned by Dan, if necessary, we will still have a little > bit of extra time to do some more fine tuning after the Last Call has passed > and before the charter is up for approval on the next IESG telechat on > 10/21. This also means that we can theoretically still pull the proposed > charter from consideration by the IESG after the Last Call has passed until > 10/20. My intention is obviously not to do this but I want to mention this > to make sure that people who might potentially have missed our very short > deadline know that they can still speak up to allow me as chairperson to > reassess whether we indeed reached our goal of rough consensus. > > Finally, I would like to thank David Partain for all the work he has done > for the netmod working group. I don't think we would have been able to > achieve our milestones as quick as we did without his dedication. > > Thanks! > > David Kessens > --- > > NETCONF Data Modeling Language (netmod) > ----------------------------- > Last Modified: 2010-10-12 > > Current Status: Active Working Group > > Chairs: > David Partain > David Kessens > > Area Director: > Dan Romascanu > > Mailing List > Address: netmod@ietf.org > To Subscribe: netmod-request@ietf.org > Archive: http://www.ietf.org/mail-archive/web/netmod/ > > Description: > > The NETCONF Working Group has completed a base protocol to be used for > configuration management. However, the NETCONF protocol does not include > a modeling language or accompanying rules that can be used to model the > management information that is to be configured using NETCONF. The > NETMOD working group has defined the data modeling language YANG but no > IETF models exist yet. The purpose of the NETMOD working group is to > support the ongoing deployment of YANG by developing a set of core YANG > data models and other activities that will allow network operators to > use YANG for configuration and management of network elements. > > The NETMOD Working Group will initially work on the following items: > > 1. Core system data model > 2. Core interface data model > 3. Core routing data model that can be augmented with routing > protocol specifics. This requires appropriate active editorial > participation from routing experts. > 4. SMIv2 translation to YANG for read-only operational data and > notifications. Guidance will be provided on how to reference existing > data structures in SMIv2 from YANG. > > The NETMOD Working Group will not work on another version of YANG. All new > charter items must be fully interoperable with implementations of rfc > 4741bis and/or rfc 6020. It will also not serve as a review team for YANG > modules developed by other working groups. > > The WG will consult with the NETCONF working group to ensure that > NETMOD's decision do not conflict with planned work in NETCONF. > > > Goals and Milestones: > > Oct 2010 Submission of individual draft(s) of System data model draft > Oct 2010 Submission of individual draft(s) of Interface data model > Oct 2010 Submission of individual draft(s) of Routing data model > Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG > Dec 2010 Submit first working group draft of System data model draft > Dec 2010 Submit first working group draft of Interface data model > Dec 2010 Submit first working group draft of Routing data model > Dec 2010 Submit first working group draft of SMIv2 translation to YANG > Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard) > Apr 2011 Submit System data model to the IESG (proposed standard) > Aug 2011 Submit Interface data model to the IESG (proposed standard) > Aug 2011 Submit Routing data model to the IESG (proposed standard) > > ---- > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Oct 13 07:43:23 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E994C3A67D3 for ; Wed, 13 Oct 2010 07:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXg0tX0VWXMO for ; Wed, 13 Oct 2010 07:43:21 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 3E23E3A67EA for ; Wed, 13 Oct 2010 07:43:20 -0700 (PDT) Received: from [192.168.2.8] (unknown [78.156.128.19]) by office2.cesnet.cz (Postfix) with ESMTPSA id 29D5B2CDE058; Wed, 13 Oct 2010 16:44:36 +0200 (CEST) From: Ladislav Lhotka To: "Romascanu, Dan (Dan)" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 13 Oct 2010 16:44:35 +0200 Message-ID: <1286981075.7051.42.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 14:43:23 -0000 On St, 2010-10-13 at 15:32 +0200, Romascanu, Dan (Dan) wrote: > I would suggest that the WG makes an effort to overcome this > situation, identify contributors, issue the starting documents. It > would be a great mistake to stop or pause at this point. I am interested in contributing to the routing data model(s). BTW, packet filtering is supposed to be a part of interface configuration? Lada > > Dan > > > > ______________________________________________________________ > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Wednesday, October 13, 2010 3:27 PM > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; Martin > Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] Brief Last Call: Charter proposal for > netmod wg(10/14/2010) > > > > I agree with you that network wide config is not ready for a > WG. > It is not clear that system or interfaces modules are ready > either. > There are no starting documents. There are no expert authors > signed up. Even with SMI translation there is no clear > consensus on the problem that needs to be solved. > IMO, nothing in this charter is really ready for > standardization. > > Andy > > ----- Reply message ----- > From: "Romascanu, Dan (Dan)" > Date: Wed, Oct 13, 2010 04:44 > Subject: [netmod] Brief Last Call: Charter proposal for netmod > wg(10/14/2010) > To: "Juergen Schoenwaelder" > , "Martin Bjorklund" > > Cc: > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, October 13, 2010 1:04 PM > > To: Martin Bjorklund > > Cc: Romascanu, Dan (Dan); netmod@ietf.org > > Subject: Re: [netmod] Brief Last Call: Charter proposal for > > netmod wg(10/14/2010) > > > > On Wed, Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund > wrote: > > > > > I asked before if this charter excludes work on > network-wide config. > > > It seems it does. Does that mean that we must finish this > proposed > > > charter before we start to work on network-wide config in > the WG? > > > > I think the unanswered question was whether it is this WG > or > > another WG. For the rechartering text crafted at the last > > IETF meeting, I also recall that network-wide config was > not > > too well understood and there were no concrete solution > > proposals to look at. > > > > /js > > > > I remember that somebody (was this Phil? ) too an action item > to write a > document that would include a problem statement as well as > point to a > possible scope of work, which was identified during out > Maastricht > bar-BOF discussions. > > For the purpose of this WG rechartering, I think it's too > early for > inclusion in the charter, but nothing prevents individuals to > work on > network-wide config, and the mail list and some time at the > end of the > WG meetings could be used for this work. > > Dan > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Wed Oct 13 08:03:45 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B8A3A692F for ; Wed, 13 Oct 2010 08:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J094m1op2SVD for ; Wed, 13 Oct 2010 08:03:44 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by core3.amsl.com (Postfix) with ESMTP id E811E3A6AB2 for ; Wed, 13 Oct 2010 08:03:39 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o9DF4mXb030642 for ; Wed, 13 Oct 2010 11:04:56 -0400 Authentication-Results: cm-omr3 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [70.0.209.50] ([70.0.209.50:54670] helo=[70.0.209.50]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 77/82-00997-B8AC5BC4; Wed, 13 Oct 2010 11:04:48 -0400 To: "=?utf-8?B?TGFkaXNsYXYgTGhvdGth?=" , "=?utf-8?B?Um9tYXNjYW51LCBEYW4gKERhbik=?=" Message-ID: <77.82.00997.B8AC5BC4@cm-omr3> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 13 Oct 2010 08:05:00 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7_1286982300541" Cc: netmod@ietf.org Subject: Re: [netmod] =?utf-8?q?Brief_Last_Call=3A_Charter_proposal_for_netmod?= =?utf-8?q?_wg=2810/14/2010=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 15:03:45 -0000 ------=_Part_7_1286982300541 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SnVzdCBhYm91dCBhbnl0aGluZyBjb3VsZCBiZSBjYWxsZWQgaW50ZXJmYWNlIGNvbmZpZ3VyYXRp b24uCk1vc3Qgc2VydmljZXMgaGF2ZSBzb21lIHBlci1pbnRlcmZhY2UgY29uZmlnIGFuZCBzb21l IGdsb2JhbCBjb25maWcuIFdoYXQgaXMgdGhlIHNjb3BlIG9mIHRoaXMgY2hhcnRlciBpdGVtPwoK V2l0aG91dCBhIHN0YXJ0aW5nIGRvY3VtZW50IG9yIGF1dGhvcnMsIHRoaXMgaXMgbGlrZSBzaWdu aW5nIGEgYmxhbmsgY2hlY2suCgpBbmR5CgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9t OiAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQGNlc25ldC5jej4KRGF0ZTogV2VkLCBPY3QgMTMs IDIwMTAgMDc6NDQKU3ViamVjdDogW25ldG1vZF0gQnJpZWYgTGFzdCBDYWxsOiBDaGFydGVyIHBy b3Bvc2FsIGZvciBuZXRtb2Qgd2coMTAvMTQvMjAxMCkKVG86ICJSb21hc2NhbnUsIERhbiAoRGFu KSIgPGRyb21hc2NhQGF2YXlhLmNvbT4KQ2M6ICJBbmR5IEJpZXJtYW4iIDxpZXRmQGFuZHliaWVy bWFuLmNvbT4sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU+LCAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPiwgPG5l dG1vZEBpZXRmLm9yZz4KCgpPbiBTdCwgMjAxMC0xMC0xMyBhdCAxNTozMiArMDIwMCwgUm9tYXNj YW51LCBEYW4gKERhbikgd3JvdGU6Cj4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIFdHIG1ha2Vz IGFuIGVmZm9ydCB0byBvdmVyY29tZSB0aGlzCj4gc2l0dWF0aW9uLCBpZGVudGlmeSBjb250cmli dXRvcnMsIGlzc3VlIHRoZSBzdGFydGluZyBkb2N1bWVudHMuIEl0Cj4gd291bGQgYmUgYSBncmVh dCBtaXN0YWtlIHRvIHN0b3Agb3IgcGF1c2UgYXQgdGhpcyBwb2ludC4KCkkgYW0gaW50ZXJlc3Rl ZCBpbiBjb250cmlidXRpbmcgdG8gdGhlIHJvdXRpbmcgZGF0YSBtb2RlbChzKS4KQlRXLCBwYWNr ZXQgZmlsdGVyaW5nIGlzIHN1cHBvc2VkIHRvIGJlIGEgcGFydCBvZiBpbnRlcmZhY2UKY29uZmln dXJhdGlvbj8KCkxhZGEKCj4gIAo+IERhbgo+ICAKPiAKPiAgICAgICAgIAo+ICAgICAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiAgICAgICAgIEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmlldGZAYW5keWJpZXJtYW4u Y29tXSAKPiAgICAgICAgIFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMywgMjAxMCAzOjI3IFBN Cj4gICAgICAgICBUbzogUm9tYXNjYW51LCBEYW4gKERhbik7IEp1ZXJnZW4gU2Nob2Vud2FlbGRl cjsgTWFydGluCj4gICAgICAgICBCam9ya2x1bmQKPiAgICAgICAgIENjOiBuZXRtb2RAaWV0Zi5v cmcKPiAgICAgICAgIFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBCcmllZiBMYXN0IENhbGw6IENoYXJ0 ZXIgcHJvcG9zYWwgZm9yCj4gICAgICAgICBuZXRtb2Qgd2coMTAvMTQvMjAxMCkKPiAgICAgICAg IAo+ICAgICAgICAgCj4gICAgICAgICAKPiAgICAgICAgIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBu ZXR3b3JrIHdpZGUgY29uZmlnIGlzIG5vdCByZWFkeSBmb3IgYQo+ICAgICAgICAgV0cuCj4gICAg ICAgICBJdCBpcyBub3QgY2xlYXIgdGhhdCBzeXN0ZW0gb3IgaW50ZXJmYWNlcyBtb2R1bGVzIGFy ZSByZWFkeQo+ICAgICAgICAgZWl0aGVyLgo+ICAgICAgICAgVGhlcmUgYXJlIG5vIHN0YXJ0aW5n IGRvY3VtZW50cy4gVGhlcmUgYXJlIG5vIGV4cGVydCBhdXRob3JzCj4gICAgICAgICBzaWduZWQg dXAuIEV2ZW4gd2l0aCBTTUkgdHJhbnNsYXRpb24gdGhlcmUgaXMgbm8gY2xlYXIKPiAgICAgICAg IGNvbnNlbnN1cyBvbiB0aGUgcHJvYmxlbSB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZC4KPiAgICAg ICAgIElNTywgbm90aGluZyBpbiB0aGlzIGNoYXJ0ZXIgaXMgcmVhbGx5IHJlYWR5IGZvcgo+ICAg ICAgICAgc3RhbmRhcmRpemF0aW9uLgo+ICAgICAgICAgCj4gICAgICAgICBBbmR5Cj4gICAgICAg ICAKPiAgICAgICAgIC0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KPiAgICAgICAgIEZyb206ICJS b21hc2NhbnUsIERhbiAoRGFuKSIgPGRyb21hc2NhQGF2YXlhLmNvbT4KPiAgICAgICAgIERhdGU6 IFdlZCwgT2N0IDEzLCAyMDEwIDA0OjQ0Cj4gICAgICAgICBTdWJqZWN0OiBbbmV0bW9kXSBCcmll ZiBMYXN0IENhbGw6IENoYXJ0ZXIgcHJvcG9zYWwgZm9yIG5ldG1vZAo+ICAgICAgICAgd2coMTAv MTQvMjAxMCkKPiAgICAgICAgIFRvOiAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIgo+ICAgICAgICAg PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4sICJNYXJ0aW4gQmpvcmtsdW5k Igo+ICAgICAgICAgPG1iakB0YWlsLWYuY29tPgo+ICAgICAgICAgQ2M6IDxuZXRtb2RAaWV0Zi5v cmc+Cj4gICAgICAgICAKPiAgICAgICAgIAo+ICAgICAgICAgCj4gICAgICAgICAKPiAgICAgICAg ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiAgICAgICAgID4gRnJvbTogSnVlcmdlbiBT Y2hvZW53YWVsZGVyIAo+ICAgICAgICAgPiBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZV0gCj4gICAgICAgICA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMywg MjAxMCAxOjA0IFBNCj4gICAgICAgICA+IFRvOiBNYXJ0aW4gQmpvcmtsdW5kCj4gICAgICAgICA+ IENjOiBSb21hc2NhbnUsIERhbiAoRGFuKTsgbmV0bW9kQGlldGYub3JnCj4gICAgICAgICA+IFN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBCcmllZiBMYXN0IENhbGw6IENoYXJ0ZXIgcHJvcG9zYWwgZm9y IAo+ICAgICAgICAgPiBuZXRtb2Qgd2coMTAvMTQvMjAxMCkKPiAgICAgICAgID4gCj4gICAgICAg ICA+IE9uIFdlZCwgT2N0IDEzLCAyMDEwIGF0IDEyOjQ4OjIxUE0gKzAyMDAsIE1hcnRpbiBCam9y a2x1bmQKPiAgICAgICAgIHdyb3RlOgo+ICAgICAgICAgPiAgCj4gICAgICAgICA+ID4gSSBhc2tl ZCBiZWZvcmUgaWYgdGhpcyBjaGFydGVyIGV4Y2x1ZGVzIHdvcmsgb24KPiAgICAgICAgIG5ldHdv cmstd2lkZSBjb25maWcuCj4gICAgICAgICA+ID4gSXQgc2VlbXMgaXQgZG9lcy4gIERvZXMgdGhh dCBtZWFuIHRoYXQgd2UgbXVzdCBmaW5pc2ggdGhpcwo+ICAgICAgICAgcHJvcG9zZWQgCj4gICAg ICAgICA+ID4gY2hhcnRlciBiZWZvcmUgd2Ugc3RhcnQgdG8gd29yayBvbiBuZXR3b3JrLXdpZGUg Y29uZmlnIGluCj4gICAgICAgICB0aGUgV0c/Cj4gICAgICAgICA+IAo+ICAgICAgICAgPiBJIHRo aW5rIHRoZSB1bmFuc3dlcmVkIHF1ZXN0aW9uIHdhcyB3aGV0aGVyIGl0IGlzIHRoaXMgV0cKPiAg ICAgICAgIG9yIAo+ICAgICAgICAgPiBhbm90aGVyIFdHLiBGb3IgdGhlIHJlY2hhcnRlcmluZyB0 ZXh0IGNyYWZ0ZWQgYXQgdGhlIGxhc3QgCj4gICAgICAgICA+IElFVEYgbWVldGluZywgSSBhbHNv IHJlY2FsbCB0aGF0IG5ldHdvcmstd2lkZSBjb25maWcgd2FzCj4gICAgICAgICBub3QgCj4gICAg ICAgICA+IHRvbyB3ZWxsIHVuZGVyc3Rvb2QgYW5kIHRoZXJlIHdlcmUgbm8gY29uY3JldGUgc29s dXRpb24gCj4gICAgICAgICA+IHByb3Bvc2FscyB0byBsb29rIGF0Lgo+ICAgICAgICAgPiAKPiAg ICAgICAgID4gL2pzCj4gICAgICAgICA+IAo+ICAgICAgICAgCj4gICAgICAgICBJIHJlbWVtYmVy IHRoYXQgc29tZWJvZHkgKHdhcyB0aGlzIFBoaWw/ICkgdG9vIGFuIGFjdGlvbiBpdGVtCj4gICAg ICAgICB0byB3cml0ZSBhCj4gICAgICAgICBkb2N1bWVudCB0aGF0IHdvdWxkIGluY2x1ZGUgYSBw cm9ibGVtIHN0YXRlbWVudCBhcyB3ZWxsIGFzCj4gICAgICAgICBwb2ludCB0byBhCj4gICAgICAg ICBwb3NzaWJsZSBzY29wZSBvZiB3b3JrLCB3aGljaCB3YXMgaWRlbnRpZmllZCBkdXJpbmcgb3V0 Cj4gICAgICAgICBNYWFzdHJpY2h0Cj4gICAgICAgICBiYXItQk9GIGRpc2N1c3Npb25zLiAKPiAg ICAgICAgIAo+ICAgICAgICAgRm9yIHRoZSBwdXJwb3NlIG9mIHRoaXMgV0cgcmVjaGFydGVyaW5n LCBJIHRoaW5rIGl0J3MgdG9vCj4gICAgICAgICBlYXJseSBmb3IKPiAgICAgICAgIGluY2x1c2lv biBpbiB0aGUgY2hhcnRlciwgYnV0IG5vdGhpbmcgcHJldmVudHMgaW5kaXZpZHVhbHMgdG8KPiAg ICAgICAgIHdvcmsgb24KPiAgICAgICAgIG5ldHdvcmstd2lkZSBjb25maWcsIGFuZCB0aGUgbWFp bCBsaXN0IGFuZCBzb21lIHRpbWUgYXQgdGhlCj4gICAgICAgICBlbmQgb2YgdGhlCj4gICAgICAg ICBXRyBtZWV0aW5ncyBjb3VsZCBiZSB1c2VkIGZvciB0aGlzIHdvcmsuIAo+ICAgICAgICAgCj4g ICAgICAgICBEYW4KPiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gICAgICAgICBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gICAgICAgICBuZXRt b2RAaWV0Zi5vcmcKPiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCj4gICAgICAgICAKPiAgICAgICAgIAo+ICAgICAgICAgCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0 Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMw QwoKCg== ------=_Part_7_1286982300541 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SnVzdCBhYm91dCBhbnl0aGluZyBjb3VsZCBiZSBjYWxsZWQgaW50ZXJmYWNlIGNvbmZpZ3VyYXRp b24uPGJyPk1vc3Qgc2VydmljZXMgaGF2ZSBzb21lIHBlci1pbnRlcmZhY2UgY29uZmlnIGFuZCBz b21lIGdsb2JhbCBjb25maWcuIFdoYXQgaXMgdGhlIHNjb3BlIG9mIHRoaXMgY2hhcnRlciBpdGVt Pzxicj48YnI+V2l0aG91dCBhIHN0YXJ0aW5nIGRvY3VtZW50IG9yIGF1dGhvcnMsIHRoaXMgaXMg bGlrZSBzaWduaW5nIGEgYmxhbmsgY2hlY2suPGJyPjxicj5BbmR5PGJyPjxicj48YnI+LS0tLS0g UmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtMYWRpc2xhdiBMaG90a2EmcXVvdDsg Jmx0O2xob3RrYUBjZXNuZXQuY3omZ3Q7PGJyPkRhdGU6IFdlZCwgT2N0IDEzLCAyMDEwIDA3OjQ0 PGJyPlN1YmplY3Q6IFtuZXRtb2RdIEJyaWVmIExhc3QgQ2FsbDogQ2hhcnRlciBwcm9wb3NhbCBm b3IgbmV0bW9kIHdnKDEwLzE0LzIwMTApPGJyPlRvOiAmcXVvdDtSb21hc2NhbnUsIERhbiAoRGFu KSZxdW90OyAmbHQ7ZHJvbWFzY2FAYXZheWEuY29tJmd0Ozxicj5DYzogJnF1b3Q7QW5keSBCaWVy bWFuJnF1b3Q7ICZsdDtpZXRmQGFuZHliaWVybWFuLmNvbSZndDssICZxdW90O0p1ZXJnZW4gU2No b2Vud2FlbGRlciZxdW90OyAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl Jmd0OywgJnF1b3Q7TWFydGluIEJqb3JrbHVuZCZxdW90OyAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7 LCAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj48YnI+PGJyPk9uIFN0LCAyMDEwLTEwLTEzIGF0 IDE1OjMyICswMjAwLCBSb21hc2NhbnUsIERhbiAoRGFuKSB3cm90ZTo8YnI+Jmd0OyBJIHdvdWxk IHN1Z2dlc3QgdGhhdCB0aGUgV0cgbWFrZXMgYW4gZWZmb3J0IHRvIG92ZXJjb21lIHRoaXM8YnI+ Jmd0OyBzaXR1YXRpb24sIGlkZW50aWZ5IGNvbnRyaWJ1dG9ycywgaXNzdWUgdGhlIHN0YXJ0aW5n IGRvY3VtZW50cy4gSXQ8YnI+Jmd0OyB3b3VsZCBiZSBhIGdyZWF0IG1pc3Rha2UgdG8gc3RvcCBv ciBwYXVzZSBhdCB0aGlzIHBvaW50Ljxicj48YnI+SSBhbSBpbnRlcmVzdGVkIGluIGNvbnRyaWJ1 dGluZyB0byB0aGUgcm91dGluZyBkYXRhIG1vZGVsKHMpLjxicj5CVFcsIHBhY2tldCBmaWx0ZXJp bmcgaXMgc3VwcG9zZWQgdG8gYmUgYSBwYXJ0IG9mIGludGVyZmFjZTxicj5jb25maWd1cmF0aW9u Pzxicj48YnI+TGFkYTxicj48YnI+Jmd0OyAmbmJzcDs8YnI+Jmd0OyBEYW48YnI+Jmd0OyAmbmJz cDs8YnI+Jmd0OyA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmlldGZAYW5keWJpZXJtYW4u Y29tXSA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VudDogV2VkbmVzZGF5 LCBPY3RvYmVyIDEzLCAyMDEwIDM6MjcgUE08YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgVG86IFJvbWFzY2FudSwgRGFuIChEYW4pOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IE1h cnRpbjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCam9ya2x1bmQ8YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2M6IG5ldG1vZEBpZXRmLm9yZzxicj4mZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJqZWN0OiBSZTogW25ldG1vZF0gQnJpZWYg TGFzdCBDYWxsOiBDaGFydGVyIHByb3Bvc2FsIGZvcjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBuZXRtb2Qgd2coMTAvMTQvMjAxMCk8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4mZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IG5ldHdvcmsgd2lkZSBjb25maWcgaXMgbm90 IHJlYWR5IGZvciBhPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdHLjxicj4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJdCBpcyBub3QgY2xlYXIgdGhhdCBzeXN0 ZW0gb3IgaW50ZXJmYWNlcyBtb2R1bGVzIGFyZSByZWFkeTxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBlaXRoZXIuPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFRoZXJlIGFyZSBubyBzdGFydGluZyBkb2N1bWVudHMuIFRoZXJlIGFyZSBubyBleHBlcnQgYXV0 aG9yczxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaWduZWQgdXAuIEV2ZW4g d2l0aCBTTUkgdHJhbnNsYXRpb24gdGhlcmUgaXMgbm8gY2xlYXI8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgY29uc2Vuc3VzIG9uIHRoZSBwcm9ibGVtIHRoYXQgbmVlZHMgdG8g YmUgc29sdmVkLjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJTU8sIG5vdGhp bmcgaW4gdGhpcyBjaGFydGVyIGlzIHJlYWxseSByZWFkeSBmb3I8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgc3RhbmRhcmRpemF0aW9uLjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQW5keTxi cj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj4mZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBGcm9tOiAmcXVvdDtSb21hc2NhbnUsIERhbiAoRGFuKSZxdW90 OyAmbHQ7ZHJvbWFzY2FAYXZheWEuY29tJmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBEYXRlOiBXZWQsIE9jdCAxMywgMjAxMCAwNDo0NDxicj4mZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBTdWJqZWN0OiBbbmV0bW9kXSBCcmllZiBMYXN0IENhbGw6IENoYXJ0 ZXIgcHJvcG9zYWwgZm9yIG5ldG1vZDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB3ZygxMC8xNC8yMDEwKTxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUbzog JnF1b3Q7SnVlcmdlbiBTY2hvZW53YWVsZGVyJnF1b3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7 LCAmcXVvdDtNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDttYmpAdGFpbC1mLmNvbSZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQ2M6ICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsgRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxicj4mZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlXSA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBT ZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTMsIDIwMTAgMTowNCBQTTxicj4mZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRvOiBNYXJ0aW4gQmpvcmtsdW5kPGJyPiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgQ2M6IFJvbWFzY2FudSwgRGFuIChEYW4pOyBu ZXRtb2RAaWV0Zi5vcmc8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBT dWJqZWN0OiBSZTogW25ldG1vZF0gQnJpZWYgTGFzdCBDYWxsOiBDaGFydGVyIHByb3Bvc2FsIGZv ciA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBuZXRtb2Qgd2coMTAv MTQvMjAxMCk8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBPbiBXZWQsIE9jdCAxMywgMjAxMCBh dCAxMjo0ODoyMVBNICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kPGJyPiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHdyb3RlOjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7ICZuYnNwOzxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZn dDsgSSBhc2tlZCBiZWZvcmUgaWYgdGhpcyBjaGFydGVyIGV4Y2x1ZGVzIHdvcmsgb248YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmV0d29yay13aWRlIGNvbmZpZy48YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IEl0IHNlZW1zIGl0IGRvZXMu ICZuYnNwO0RvZXMgdGhhdCBtZWFuIHRoYXQgd2UgbXVzdCBmaW5pc2ggdGhpczxicj4mZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcm9wb3NlZCA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IGNoYXJ0ZXIgYmVmb3JlIHdlIHN0YXJ0IHRvIHdvcmsg b24gbmV0d29yay13aWRlIGNvbmZpZyBpbjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB0aGUgV0c/PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgPGJy PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgSSB0aGluayB0aGUgdW5hbnN3 ZXJlZCBxdWVzdGlvbiB3YXMgd2hldGhlciBpdCBpcyB0aGlzIFdHPGJyPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IG9yIDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7IGFub3RoZXIgV0cuIEZvciB0aGUgcmVjaGFydGVyaW5nIHRleHQgY3JhZnRlZCBhdCB0 aGUgbGFzdCA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBJRVRGIG1l ZXRpbmcsIEkgYWxzbyByZWNhbGwgdGhhdCBuZXR3b3JrLXdpZGUgY29uZmlnIHdhczxicj4mZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBub3QgPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDsgdG9vIHdlbGwgdW5kZXJzdG9vZCBhbmQgdGhlcmUgd2VyZSBubyBj b25jcmV0ZSBzb2x1dGlvbiA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyBwcm9wb3NhbHMgdG8gbG9vayBhdC48YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAvanM8YnI+ Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEkg cmVtZW1iZXIgdGhhdCBzb21lYm9keSAod2FzIHRoaXMgUGhpbD8gKSB0b28gYW4gYWN0aW9uIGl0 ZW08YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8gd3JpdGUgYTxicj4mZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkb2N1bWVudCB0aGF0IHdvdWxkIGluY2x1ZGUg YSBwcm9ibGVtIHN0YXRlbWVudCBhcyB3ZWxsIGFzPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHBvaW50IHRvIGE8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg cG9zc2libGUgc2NvcGUgb2Ygd29yaywgd2hpY2ggd2FzIGlkZW50aWZpZWQgZHVyaW5nIG91dDxi cj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNYWFzdHJpY2h0PGJyPiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJhci1CT0YgZGlzY3Vzc2lvbnMuIDxicj4mZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgRm9yIHRoZSBwdXJwb3NlIG9mIHRoaXMgV0cgcmVjaGFydGVyaW5nLCBJIHRoaW5rIGl0 JiMzOTtzIHRvbzxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlYXJseSBmb3I8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5jbHVzaW9uIGluIHRoZSBjaGFy dGVyLCBidXQgbm90aGluZyBwcmV2ZW50cyBpbmRpdmlkdWFscyB0bzxicj4mZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB3b3JrIG9uPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IG5ldHdvcmstd2lkZSBjb25maWcsIGFuZCB0aGUgbWFpbCBsaXN0IGFuZCBzb21lIHRp bWUgYXQgdGhlPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuZCBvZiB0aGU8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV0cgbWVldGluZ3MgY291bGQgYmUg dXNlZCBmb3IgdGhpcyB3b3JrLiA8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhbjxicj4mZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuZXRtb2QgbWFp bGluZyBsaXN0PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5ldG1vZEBpZXRm Lm9yZzxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJy PiZndDsgbmV0bW9kQGlldGYub3JnPGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kPC9hPjxicj48YnI+LS0gPGJyPkxhZGlzbGF2IExob3RrYSwgQ0VTTkVU PGJyPlBHUCBLZXkgSUQ6IEU3NEU4QzBDPGJyPjxicj48YnI+PGJyPjxicj4= ------=_Part_7_1286982300541-- From david.kessens@nsn.com Wed Oct 13 21:38:48 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7410A3A68B5 for ; Wed, 13 Oct 2010 21:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHKjaNmA5hEP for ; Wed, 13 Oct 2010 21:38:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9EE7E3A685B for ; Wed, 13 Oct 2010 21:38:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9E4dtEw008934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2010 06:39:55 +0200 Received: from localhost6.localdomain6 ([10.138.48.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9E4dnrH013264; Thu, 14 Oct 2010 06:39:51 +0200 Received: from localhost6.localdomain6 (localhost.localdomain [127.0.0.1]) by localhost6.localdomain6 (8.14.4/8.14.3) with ESMTP id o9E4csNE013081; Wed, 13 Oct 2010 21:38:54 -0700 Received: (from david@localhost) by localhost6.localdomain6 (8.14.4/8.14.4/Submit) id o9E4cosk013070; Wed, 13 Oct 2010 21:38:50 -0700 X-Authentication-Warning: localhost6.localdomain6: david set sender to david.kessens@nsn.com using -f Date: Wed, 13 Oct 2010 21:38:50 -0700 From: David Kessens To: Andy Bierman Message-ID: <20101014043850.GC2416@nsn.com> References: <77.82.00997.B8AC5BC4@cm-omr3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77.82.00997.B8AC5BC4@cm-omr3> User-Agent: Mutt/1.5.20 (2009-08-17) Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 04:38:49 -0000 Andy, Lada, Personally, I would not put packet filtering under interface configuration. I rather keep things simple in order to get our first core models out the door as quickly as possible. I do think however that we might be able to convince our Area Directors to add items like this to our charter without too many difficulties if somebody were to contribute a rather complete personal draft that pretty much covers this area very well. David Kessens speaking as an individual contributor --- On Wed, Oct 13, 2010 at 08:05:00AM -0700, Andy Bierman wrote: > Just about anything could be called interface configuration. > Most services have some per-interface config and some global config. What is the scope of this charter item? > > Without a starting document or authors, this is like signing a blank check. > > Andy > > > ----- Reply message ----- > From: "Ladislav Lhotka" > Date: Wed, Oct 13, 2010 07:44 > Subject: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) > To: "Romascanu, Dan (Dan)" > Cc: "Andy Bierman" , "Juergen Schoenwaelder" , "Martin Bjorklund" , > > > On St, 2010-10-13 at 15:32 +0200, Romascanu, Dan (Dan) wrote: > > I would suggest that the WG makes an effort to overcome this > > situation, identify contributors, issue the starting documents. It > > would be a great mistake to stop or pause at this point. > > I am interested in contributing to the routing data model(s). > BTW, packet filtering is supposed to be a part of interface > configuration? > > Lada > > > > > Dan > > > > > > > > ______________________________________________________________ > > From: Andy Bierman [mailto:ietf@andybierman.com] > > Sent: Wednesday, October 13, 2010 3:27 PM > > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; Martin > > Bjorklund > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Brief Last Call: Charter proposal for > > netmod wg(10/14/2010) > > > > > > > > I agree with you that network wide config is not ready for a > > WG. > > It is not clear that system or interfaces modules are ready > > either. > > There are no starting documents. There are no expert authors > > signed up. Even with SMI translation there is no clear > > consensus on the problem that needs to be solved. > > IMO, nothing in this charter is really ready for > > standardization. > > > > Andy > > > > ----- Reply message ----- > > From: "Romascanu, Dan (Dan)" > > Date: Wed, Oct 13, 2010 04:44 > > Subject: [netmod] Brief Last Call: Charter proposal for netmod > > wg(10/14/2010) > > To: "Juergen Schoenwaelder" > > , "Martin Bjorklund" > > > > Cc: > > > > > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Wednesday, October 13, 2010 1:04 PM > > > To: Martin Bjorklund > > > Cc: Romascanu, Dan (Dan); netmod@ietf.org > > > Subject: Re: [netmod] Brief Last Call: Charter proposal for > > > netmod wg(10/14/2010) > > > > > > On Wed, Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund > > wrote: > > > > > > > I asked before if this charter excludes work on > > network-wide config. > > > > It seems it does. Does that mean that we must finish this > > proposed > > > > charter before we start to work on network-wide config in > > the WG? > > > > > > I think the unanswered question was whether it is this WG > > or > > > another WG. For the rechartering text crafted at the last > > > IETF meeting, I also recall that network-wide config was > > not > > > too well understood and there were no concrete solution > > > proposals to look at. > > > > > > /js > > > > > > > I remember that somebody (was this Phil? ) too an action item > > to write a > > document that would include a problem statement as well as > > point to a > > possible scope of work, which was identified during out > > Maastricht > > bar-BOF discussions. > > > > For the purpose of this WG rechartering, I think it's too > > early for > > inclusion in the charter, but nothing prevents individuals to > > work on > > network-wide config, and the mail list and some time at the > > end of the > > WG meetings could be used for this work. > > > > Dan > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod David Kessens --- From david.kessens@nsn.com Wed Oct 13 21:40:08 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6113A68BB for ; Wed, 13 Oct 2010 21:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMWCRutAO9Tn for ; Wed, 13 Oct 2010 21:40:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 973333A685B for ; Wed, 13 Oct 2010 21:40:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9E4fJea010742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2010 06:41:19 +0200 Received: from localhost6.localdomain6 ([10.138.48.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9E4fAdV019872; Thu, 14 Oct 2010 06:41:18 +0200 Received: from localhost6.localdomain6 (localhost.localdomain [127.0.0.1]) by localhost6.localdomain6 (8.14.4/8.14.3) with ESMTP id o9E4eFns013115; Wed, 13 Oct 2010 21:40:15 -0700 Received: (from david@localhost) by localhost6.localdomain6 (8.14.4/8.14.4/Submit) id o9E4eFMw013114; Wed, 13 Oct 2010 21:40:15 -0700 X-Authentication-Warning: localhost6.localdomain6: david set sender to david.kessens@nsn.com using -f Date: Wed, 13 Oct 2010 21:40:15 -0700 From: David Kessens To: "Romascanu, Dan (Dan)" Message-ID: <20101014044015.GD2416@nsn.com> References: <20101013053405.GE25284@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 04:40:08 -0000 Dan, On Wed, Oct 13, 2010 at 11:53:07AM +0200, Romascanu, Dan (Dan) wrote: > > 1. I suggest to add to item #3 'and review at WGLC by the Routing Area > WG'. I have no problem with this. David Kessens --- From lhotka@cesnet.cz Thu Oct 14 01:06:54 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2F03A68A8 for ; Thu, 14 Oct 2010 01:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7z-0vtjYucw for ; Thu, 14 Oct 2010 01:06:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 5621B3A677C for ; Thu, 14 Oct 2010 01:06:50 -0700 (PDT) Received: from [192.168.2.8] (unknown [78.156.128.19]) by office2.cesnet.cz (Postfix) with ESMTPSA id 317102CDE059; Thu, 14 Oct 2010 10:08:07 +0200 (CEST) From: Ladislav Lhotka To: David Kessens In-Reply-To: <20101014043850.GC2416@nsn.com> References: <77.82.00997.B8AC5BC4@cm-omr3> <20101014043850.GC2416@nsn.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 14 Oct 2010 10:08:06 +0200 Message-ID: <1287043686.1714.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 08:06:54 -0000 On St, 2010-10-13 at 21:38 -0700, David Kessens wrote: > Andy, Lada, > > Personally, I would not put packet filtering under interface configuration. > I rather keep things simple in order to get our first core models out the > door as quickly as possible. I agree, things like this should be developed elsewhere and augment the interface model where necessary. After all, that's where YANG really shines. > > > I do think however that we might be able to convince our Area Directors to > add items like this to our charter without too many difficulties if somebody > were to contribute a rather complete personal draft that pretty much covers > this area very well. Fair enough. Lada > > David Kessens > speaking as an individual contributor > --- > > On Wed, Oct 13, 2010 at 08:05:00AM -0700, Andy Bierman wrote: > > Just about anything could be called interface configuration. > > Most services have some per-interface config and some global config. What is the scope of this charter item? > > > > Without a starting document or authors, this is like signing a blank check. > > > > Andy > > > > > > ----- Reply message ----- > > From: "Ladislav Lhotka" > > Date: Wed, Oct 13, 2010 07:44 > > Subject: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) > > To: "Romascanu, Dan (Dan)" > > Cc: "Andy Bierman" , "Juergen Schoenwaelder" , "Martin Bjorklund" , > > > > > > On St, 2010-10-13 at 15:32 +0200, Romascanu, Dan (Dan) wrote: > > > I would suggest that the WG makes an effort to overcome this > > > situation, identify contributors, issue the starting documents. It > > > would be a great mistake to stop or pause at this point. > > > > I am interested in contributing to the routing data model(s). > > BTW, packet filtering is supposed to be a part of interface > > configuration? > > > > Lada > > > > > > > > Dan > > > > > > > > > > > > ______________________________________________________________ > > > From: Andy Bierman [mailto:ietf@andybierman.com] > > > Sent: Wednesday, October 13, 2010 3:27 PM > > > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; Martin > > > Bjorklund > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] Brief Last Call: Charter proposal for > > > netmod wg(10/14/2010) > > > > > > > > > > > > I agree with you that network wide config is not ready for a > > > WG. > > > It is not clear that system or interfaces modules are ready > > > either. > > > There are no starting documents. There are no expert authors > > > signed up. Even with SMI translation there is no clear > > > consensus on the problem that needs to be solved. > > > IMO, nothing in this charter is really ready for > > > standardization. > > > > > > Andy > > > > > > ----- Reply message ----- > > > From: "Romascanu, Dan (Dan)" > > > Date: Wed, Oct 13, 2010 04:44 > > > Subject: [netmod] Brief Last Call: Charter proposal for netmod > > > wg(10/14/2010) > > > To: "Juergen Schoenwaelder" > > > , "Martin Bjorklund" > > > > > > Cc: > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > Sent: Wednesday, October 13, 2010 1:04 PM > > > > To: Martin Bjorklund > > > > Cc: Romascanu, Dan (Dan); netmod@ietf.org > > > > Subject: Re: [netmod] Brief Last Call: Charter proposal for > > > > netmod wg(10/14/2010) > > > > > > > > On Wed, Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund > > > wrote: > > > > > > > > > I asked before if this charter excludes work on > > > network-wide config. > > > > > It seems it does. Does that mean that we must finish this > > > proposed > > > > > charter before we start to work on network-wide config in > > > the WG? > > > > > > > > I think the unanswered question was whether it is this WG > > > or > > > > another WG. For the rechartering text crafted at the last > > > > IETF meeting, I also recall that network-wide config was > > > not > > > > too well understood and there were no concrete solution > > > > proposals to look at. > > > > > > > > /js > > > > > > > > > > I remember that somebody (was this Phil? ) too an action item > > > to write a > > > document that would include a problem statement as well as > > > point to a > > > possible scope of work, which was identified during out > > > Maastricht > > > bar-BOF discussions. > > > > > > For the purpose of this WG rechartering, I think it's too > > > early for > > > inclusion in the charter, but nothing prevents individuals to > > > work on > > > network-wide config, and the mail list and some time at the > > > end of the > > > WG meetings could be used for this work. > > > > > > Dan > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > David Kessens > --- -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From wwwrun@core3.amsl.com Thu Oct 14 10:03:06 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2BFB53A6B8E; Thu, 14 Oct 2010 10:03:05 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101014170306.2BFB53A6B8E@core3.amsl.com> Date: Thu, 14 Oct 2010 10:03:06 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] WG Review: Recharter of NETCONF Data Modeling Language (netmod) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 17:03:06 -0000 A modified charter has been submitted for the NETCONF Data Modeling Language (netmod) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, October 21, 2010. NETCONF Data Modeling Language (netmod) ----------------------------- Last Modified: 2010-10-12 Current Status: Active Working Group Chairs: David Partain David Kessens Area Director: Dan Romascanu Mailing List Address: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will initially work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts and review at WGLC by the Routing Area working group. 4. SMIv2 translation to YANG for read-only operational data and notifications. Guidance will be provided on how to reference existing data structures in SMIv2 from YANG. The NETMOD Working Group will not work on another version of YANG. All new charter items must be fully interoperable with implementations of RFC 4741bis and/or RFC 6020. It will also not serve as a review team for YANG modules developed by other working groups. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Oct 2010 Submission of individual draft(s) of System data model draft Oct 2010 Submission of individual draft(s) of Interface data model Oct 2010 Submission of individual draft(s) of Routing data model Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG Dec 2010 Submit first working group draft of System data model draft Dec 2010 Submit first working group draft of Interface data model Dec 2010 Submit first working group draft of Routing data model Dec 2010 Submit first working group draft of SMIv2 translation to YANG Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2011 Submit System data model to the IESG (proposed standard) Aug 2011 Submit Interface data model to the IESG (proposed standard) Aug 2011 Submit Routing data model to the IESG (proposed standard) From ietf@andybierman.com Thu Oct 14 10:24:48 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5793A6B87 for ; Thu, 14 Oct 2010 10:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUnDdk-i0Ejh for ; Thu, 14 Oct 2010 10:24:47 -0700 (PDT) Received: from nm2-vm0.bullet.mail.ne1.yahoo.com (nm2-vm0.bullet.mail.ne1.yahoo.com [98.138.91.39]) by core3.amsl.com (Postfix) with SMTP id 6305D3A6B4B for ; Thu, 14 Oct 2010 10:24:47 -0700 (PDT) Received: from [98.138.90.50] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2010 17:26:06 -0000 Received: from [98.138.87.12] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2010 17:26:06 -0000 Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP; 14 Oct 2010 17:26:06 -0000 X-Yahoo-Newman-Id: 275752.44802.bm@omp1012.mail.ne1.yahoo.com Received: (qmail 92350 invoked from network); 14 Oct 2010 17:26:06 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 14 Oct 2010 10:26:05 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: qdc413sVM1mzV2yByXSSfzgSQXsrvNgVPdBCFRSOnQ0gg5d T9i68.nYbNyKPfiPOIdircpw.qCcGQNSKd_RAIZ0O0.MKIMAh1PqPlEtvCDE cHfYGxevrWd7XJv6Em5CQXB.NKFZ9gPsDN9vbKc4zmbis1fLmxKcNblWGH5J l6J7hbUyn8..TNmJDWLJEF9W5YjncNeCNQYAmSqjDi5EwU6MWn6yTUmoLpyb ky5AcuJ9nx58LcJoZVVBVoEW1nz.cqBQe2ZF9Mzp51isKAjtYT9FAG.n3Ycw 4sw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CB73D27.8010609@andybierman.com> Date: Thu, 14 Oct 2010 10:25:59 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: netmod@ietf.org References: <77.82.00997.B8AC5BC4@cm-omr3> In-Reply-To: <77.82.00997.B8AC5BC4@cm-omr3> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Brief Last Call: Charter proposal for netmod wg(10/14/2010) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 17:24:48 -0000 On 10/13/2010 08:05 AM, Andy Bierman wrote: > Just about anything could be called interface configuration. > Most services have some per-interface config and some global config. > What is the scope of this charter item? > > Without a starting document or authors, this is like signing a blank check. I think the NETMOD WG needs to think about big picture before starting on modules from scratch. The process will go a lot smoother and get done faster in the end, if we agree first on the basic scope and structure of the data. We need to agree on some requirements, without writing an entire RFC on the subject. > > Andy > Andy > > ----- Reply message ----- > From: "Ladislav Lhotka" > Date: Wed, Oct 13, 2010 07:44 > Subject: [netmod] Brief Last Call: Charter proposal for netmod > wg(10/14/2010) > To: "Romascanu, Dan (Dan)" > Cc: "Andy Bierman" , "Juergen Schoenwaelder" > , "Martin Bjorklund" > , > > > On St, 2010-10-13 at 15:32 +0200, Romascanu, Dan (Dan) wrote: > > I would suggest that the WG makes an effort to overcome this > > situation, identify contributors, issue the starting documents. It > > would be a great mistake to stop or pause at this point. > > I am interested in contributing to the routing data model(s). > BTW, packet filtering is supposed to be a part of interface > configuration? > > Lada > > > > > Dan > > > > > > > > ______________________________________________________________ > > From: Andy Bierman [mailto:ietf@andybierman.com] > > Sent: Wednesday, October 13, 2010 3:27 PM > > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; Martin > > Bjorklund > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Brief Last Call: Charter proposal for > > netmod wg(10/14/2010) > > > > > > > > I agree with you that network wide config is not ready for a > > WG. > > It is not clear that system or interfaces modules are ready > > either. > > There are no starting documents. There are no expert authors > > signed up. Even with SMI translation there is no clear > > consensus on the problem that needs to be solved. > > IMO, nothing in this charter is really ready for > > standardization. > > > > Andy > > > > ----- Reply message ----- > > From: "Romascanu, Dan (Dan)" > > Date: Wed, Oct 13, 2010 04:44 > > Subject: [netmod] Brief Last Call: Charter proposal for netmod > > wg(10/14/2010) > > To: "Juergen Schoenwaelder" > > , "Martin Bjorklund" > > > > Cc: > > > > > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Wednesday, October 13, 2010 1:04 PM > > > To: Martin Bjorklund > > > Cc: Romascanu, Dan (Dan); netmod@ietf.org > > > Subject: Re: [netmod] Brief Last Call: Charter proposal for > > > netmod wg(10/14/2010) > > > > > > On Wed, Oct 13, 2010 at 12:48:21PM +0200, Martin Bjorklund > > wrote: > > > > > > > I asked before if this charter excludes work on > > network-wide config. > > > > It seems it does. Does that mean that we must finish this > > proposed > > > > charter before we start to work on network-wide config in > > the WG? > > > > > > I think the unanswered question was whether it is this WG > > or > > > another WG. For the rechartering text crafted at the last > > > IETF meeting, I also recall that network-wide config was > > not > > > too well understood and there were no concrete solution > > > proposals to look at. > > > > > > /js > > > > > > > I remember that somebody (was this Phil? ) too an action item > > to write a > > document that would include a problem statement as well as > > point to a > > possible scope of work, which was identified during out > > Maastricht > > bar-BOF discussions. > > > > For the purpose of this WG rechartering, I think it's too > > early for > > inclusion in the charter, but nothing prevents individuals to > > work on > > network-wide config, and the mail list and some time at the > > end of the > > WG meetings could be used for this work. > > > > Dan > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From dromasca@avaya.com Mon Oct 18 02:30:47 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B008E3A6A79 for ; Mon, 18 Oct 2010 02:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRuZ5pikG-fq for ; Mon, 18 Oct 2010 02:30:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D0E433A6D10 for ; Mon, 18 Oct 2010 02:30:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="212377680" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Oct 2010 05:32:12 -0400 X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="527429801" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Oct 2010 05:32:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Oct 2010 11:31:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Time for a new NETMOD co-chair - Call for Nominations Thread-Index: Actp7uPkHCmpycXrQriNfm+opK1ozgEuBRsQ References: From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Cc: Ron Bonica Subject: Re: [netmod] Time for a new NETMOD co-chair - Call for Nominations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 09:30:47 -0000 This is a reminder that a call for nominations for the open position of co-chair of Netmod is runing until this coming Friday 8/22. If you want to serve the community by taking this responsibility, and/or if you know somebody who is capable to do the job please let me know.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, October 12, 2010 11:22 AM > To: netmod@ietf.org > Cc: Ron Bonica > Subject: [netmod] Time for a new NETMOD co-chair - Call for=20 > Nominations >=20 > David Partain let me know that he decided to step down from=20 > his position of co-chair of the NETMOD WG because of changes=20 > in his day job priorities. Without David's contribution=20 > Netmod and YANG would simply not have happened. The whole=20 > community owes him a big THANK YOU for gathering support and=20 > pushing ahead with the idea of a DML for NETCONF, and leading=20 > the work from the start of the WG until today. I hope that=20 > David will continue to support the work with valuable=20 > guidance and contributions, not only during the transition=20 > process but also in the years to come.=20 >=20 > I am opening for nominations the position of co-chair of NETMOD. > Nominations and self-nominations are welcome. If you believe=20 > that you are up to the job and willing to serve, or you know=20 > somebody who is up to the job please let me know before=20 > Friday 10/22. I plan to run the interviews and decide on a=20 > new co-chair to work with David Kessens who is continuing on=20 > the job as soon as the nomination period ends, and I hope=20 > that we can complete the nomination and transition process=20 > before IETF-79.=20 >=20 > Regards, >=20 > Dan > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Tue Oct 19 03:11:44 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1269F3A67A7 for ; Tue, 19 Oct 2010 03:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiBuEsggKzvS for ; Tue, 19 Oct 2010 03:11:39 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id CAFFF3A657C for ; Tue, 19 Oct 2010 03:11:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,349,1283745600"; d="scan'208";a="243359008" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Oct 2010 06:13:07 -0400 X-IronPort-AV: E=Sophos;i="4.57,349,1283745600"; d="scan'208";a="524308447" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Oct 2010 06:13:07 -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: Tue, 19 Oct 2010 12:12:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART Telechat Review of draft-ietf-netmod-dsdl-map-08 Thread-Index: ActvCk/qYW4aA4VKTQe7Aq8KbpkBzQAa+C7g From: "Romascanu, Dan (Dan)" To: Subject: [netmod] FW: Gen-ART Telechat Review of draft-ietf-netmod-dsdl-map-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 10:11:44 -0000 =20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Monday, October 18, 2010 11:20 PM To: draft-ietf-netmod-dsdl-map.all@tools.ietf.org; General Area Review Team Cc: The IETF Subject: Gen-ART Telechat Review of draft-ietf-netmod-dsdl-map-08 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netmod-dsdl-map-08 Reviewer: Ben Campbell Review Date: 18 Oct 2010 IESG Telechat date: 21 Oct 2010 Summary: This draft is ready for publication as a proposed standard. This version addresses all of the comments from my review of version 07 at IETF LC.=20 Major Issues: None Minor Issues: None Nits and Editorial Comments: -- The resolution to my comment about invalid author email addresses was to remove the co-authors, as they are no longer active in the working group. I have no opinion as to whether that is a good idea or not, and I assume all involved are okay with it. I merely bring it up to make sure people have thought about it. From mehmet.ersue@nsn.com Tue Oct 19 07:59:19 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6BB3A6895 for ; Tue, 19 Oct 2010 07:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f05h5tHRz72N for ; Tue, 19 Oct 2010 07:59:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 6928D3A6882 for ; Tue, 19 Oct 2010 07:59:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9JF0g1Y020872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Oct 2010 17:00:42 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9JF0gU6013537 for ; Tue, 19 Oct 2010 17:00:42 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Oct 2010 17:00:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB6F9E.662C966E" Date: Tue, 19 Oct 2010 17:00:40 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011B63A6@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-linowski-netmod-yang-abstract-04.txt Thread-Index: Actvfz/BOPaXdabTQUWlLIRzfn5rcAAHtgFQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 19 Oct 2010 15:00:42.0015 (UTC) FILETIME=[663052F0:01CB6F9E] Subject: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:59:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6F9E.662C966E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org Sent: Tuesday, October 19, 2010 1:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-linowski-netmod-yang-abstract-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extending YANG with Language Abstractions Author(s) : B. Linowski, et al. Filename : draft-linowski-netmod-yang-abstract-04.txt Pages : 78 Date : 2010-10-19 YANG - the NETCONF Data Modeling Language - supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests to enhance YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- 04.txt=20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/=20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CB6F9E.662C966E Content-Type: application/octet-stream; name="draft-linowski-netmod-yang-abstract-04.URL" Content-Transfer-Encoding: base64 Content-Description: draft-linowski-netmod-yang-abstract-04.URL Content-Disposition: attachment; filename="draft-linowski-netmod-yang-abstract-04.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saW5vd3NraS1uZXRtb2QteWFuZy1hYnN0cmFjdC0wNC50eHQNCg== ------_=_NextPart_001_01CB6F9E.662C966E-- From mehmet.ersue@nsn.com Tue Oct 19 08:01:14 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6488F3A6835 for ; Tue, 19 Oct 2010 08:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.126 X-Spam-Level: X-Spam-Status: No, score=-102.126 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl1V-RZgcH+v for ; Tue, 19 Oct 2010 08:01:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 030B63A6895 for ; Tue, 19 Oct 2010 08:01:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9JF2fko025083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Oct 2010 17:02:41 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9JF2cQj018324; Tue, 19 Oct 2010 17:02:41 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Oct 2010 16:58:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Oct 2010 16:58:19 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011B63A0@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Review of draft-linowski-netmod-yang-abstract-03.txt Thread-Index: ActVjyEZhFfA4km/S+ylKAijjprTxAJiDG2QACe0FmAD83W/MA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" X-OriginalArrivalTime: 19 Oct 2010 14:58:21.0011 (UTC) FILETIME=[1224D230:01CB6F9E] Cc: netmod@ietf.org Subject: [netmod] FW: Review of draft-linowski-netmod-yang-abstract-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 15:01:14 -0000 Hi Martin, sorry for late response. See below. > Hi Mehmet, >=20 > "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > > ------------------------------------------------------------ > > > > > > s 2.9. > > > > > > Why do you define the "complex-type" feature? Why is this feature > > > important to a client? How will the client adapt depending on if > this > > > feature is present or not? > > > > > > IMO, it is not needed at all. If the server advertises support for > a > > > module that uses complex-types, it obvioulsy implements complex- > types. > > > > This might look a bit redundant. However, having the feature allows > > to use the if-feature mechanism with a commonly defined tag. >=20 > Can you give an example of a use case where this would be useful? E.g. it allows to expose NE configuration/state data with CTs as an alternate representation. The CT feature enables then to wrap this alternate representation into a if-feature statement. [...]=20 > > > If complex-types are used, some of the flexibility of YANG is lost. > > > For example, in your equipment example, suppose vendor X wants to > add > > > its own proprietary attributes to all "ManagedHardware". This will > > > not be possible unless all classes derived from ManagedHardware at > > > some point are tracked down, and all ct:instance statements for > these > > > classes are augmented with the new attributes. > > > > Actually it depends on the pov. and the way you are modeling. In > > our opinion complex-types introduce a powerful language feature for > > top-down modeling and enables additional flexibility for the aimed > > purpose, e.g. with inheritance. The new feature makes YANG models > > easier mapable to other models like SID. > > > > You can always extend a base class to affect inheriting classes >=20 > Can you show how this would be done in the example I gave above? In such a case vendor X would probably derive one or more vendor=20 specific extensions from ancestors of ManagedHardware (something=20 like "XChassis" and "XBackplane"). But again, as stated in section 2.13.2., we want to keep the=20 modeling with complex types simple and propose the augmentation=20 of complex type instances without recursion. > > or > > inherit from a class and add new attributes on the new class level. >=20 > But this doesn't solve the problem in the example above. Vendor X > cannot change all classes in the inheritance chain, if these classes > are defined in published standard modules. It is true that you cannot augment complex types with recursion and=20 in that respect they behave like groupings. =20 The approach we propose for the example above is to create sub-classes=20 of the classes defined in the standard module and to enhance them with=20 vendor specific data elements. This is the classical and straightforward approach for modeling with inheritance. >=20 > /martin Cheers, Mehmet From mbj@tail-f.com Wed Oct 20 06:33:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB623A67D3 for ; Wed, 20 Oct 2010 06:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0pcpbZfJwuH for ; Wed, 20 Oct 2010 06:33:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 898E03A67FE for ; Wed, 20 Oct 2010 06:33:30 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 65332616004 for ; Wed, 20 Oct 2010 15:35:02 +0200 (CEST) Date: Wed, 20 Oct 2010 15:35:01 +0200 (CEST) Message-Id: <20101020.153501.236075803.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Oct_20_15_35_01_2010_933)--" Content-Transfer-Encoding: 7bit Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 13:33:32 -0000 ----Next_Part(Wed_Oct_20_15_35_01_2010_933)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This draft might be of interest for the WG, even though it is not covered by our charter. Chair(s?) - if there is time when we meet in Beijing, we would like to present this draft. /martin ----Next_Part(Wed_Oct_20_15_35_01_2010_933)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on thermopyle.tail-f.com X-Spam-Level: X-Spam-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.4 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mail.tail-f.com (Postfix) with ESMTP id C194161A1EB for ; Mon, 18 Oct 2010 16:15:40 +0200 (CEST) Received: by core3.amsl.com (Postfix, from userid 30) id 1AEF73A6C7C; Mon, 18 Oct 2010 07:14:11 -0700 (PDT) From: IETF I-D Submission Tool To: mbj@tail-f.com Cc: j.schoenwaelder@jacobs-university.de Subject: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101018141411.1AEF73A6C7C@core3.amsl.com> Date: Mon, 18 Oct 2010 07:14:11 -0700 (PDT) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5 int cnt prob spamicity histogram 0.00 36 0.011509 0.010451 #################################### 0.10 4 0.111085 0.021680 #### 0.20 0 0.000000 0.021680 0.30 0 0.000000 0.021680 0.40 0 0.000000 0.021680 0.50 0 0.000000 0.021680 0.60 0 0.000000 0.021680 0.70 0 0.000000 0.021680 0.80 0 0.000000 0.021680 0.90 0 0.000000 0.021680 A new version of I-D, draft-bjorklund-netmod-snmp-cfg-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Filename: draft-bjorklund-netmod-snmp-cfg Revision: 00 Title: snmp cfg Creation_date: 2010-10-18 WG ID: Independent Submission Number_of_pages: 36 Abstract: This document defines a collection of YANG definitions for configuring SNMP engines. The IETF Secretariat. ----Next_Part(Wed_Oct_20_15_35_01_2010_933)---- From biermana@Brocade.com Wed Oct 20 08:46:08 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26B73A68D5 for ; Wed, 20 Oct 2010 08:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-qriR98ACAC for ; Wed, 20 Oct 2010 08:46:07 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id A47973A681F for ; Wed, 20 Oct 2010 08:46:07 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9KFiD7G017254; Wed, 20 Oct 2010 08:47:40 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s21dug233-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Oct 2010 08:47:40 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Oct 2010 08:51:59 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 20 Oct 2010 08:47:38 -0700 From: Andy Bierman To: Martin Bjorklund , "netmod@ietf.org" Date: Wed, 20 Oct 2010 08:47:37 -0700 Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: ActwW6FEr0HfR4y2ShK503ZqpTm1NAAD/+qQ Message-ID: References: <20101020.153501.236075803.mbj@tail-f.com> In-Reply-To: <20101020.153501.236075803.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-20_08:2010-10-20, 2010-10-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010200085 X-Proofpoint-SSN: Sensitivity2 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:46:08 -0000 Hi, This draft is rather terse wrt/ purpose and fit within the NETCONF standard= . There is 1 sentence: Abstract This document defines a collection of YANG definitions for configuring SNMP engines. Since YANG is a data modeling language for NETCONF (it's even in the title)= , how is this supposed to be used? Since SNMP is not widely used for configu= ration, why is this work important to NETCONF standardization? If we have an SMIv2= to YANG mapping algorithm, why do we need to publish YANG versions of SMIv2 modules= ? Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Martin Bjorklund Sent: Wednesday, October 20, 2010 6:35 AM To: netmod@ietf.org Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-s= nmp-cfg-00 Hi, This draft might be of interest for the WG, even though it is not covered b= y our charter. Chair(s?) - if there is time when we meet in Beijing, we would like to pres= ent this draft. /martin From ietfdbh@comcast.net Wed Oct 20 10:13:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8F53A68F7 for ; Wed, 20 Oct 2010 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmFV96nsU4yB for ; Wed, 20 Oct 2010 10:13:23 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 8B65C3A67FD for ; Wed, 20 Oct 2010 10:13:22 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Lzt81f0050bG4ec5B5EwjQ; Wed, 20 Oct 2010 17:14:56 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id M5Ew1f0082JQnJT3P5EwhF; Wed, 20 Oct 2010 17:14:56 +0000 From: "David Harrington" To: "'Andy Bierman'" , "'Martin Bjorklund'" , References: <20101020.153501.236075803.mbj@tail-f.com> Date: Wed, 20 Oct 2010 13:14:50 -0400 Message-ID: <86F02899CB3D40E8BB57AD97C522A178@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: ActwW6FEr0HfR4y2ShK503ZqpTm1NAAD/+qQAAGsEJA= Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:13:25 -0000 Hi, Andy, You apparently didn't read the draft. Since SNMP is not widely used for configuration, we need something else to do that configuration. Netconf is the IETF-preferred standard for doing configuration. This is a yang data model for doing configuration of SNMP engines using netconf. The draft seems quite light on text. I'll do a more thorough review when the document is fleshed out more. A point I will make is that the feature definitions do not align with snmpv3 (IETF) compliance requirements. These feature sets might make perfect sense from an ooperational point of view. But you should probably point out that not supporting the feature might make your configuration non-compliant to the IETF standard. For example, I think proxy and multiple context support are required as part of the snmpv3 standard. Regarding type definitions. If the WG documents will define normative translations of SMIv2 datatypes for admin-string, identifier, context-name, etc., it would be better to reference the other document. Is there a reason you are using abbreviations in your names? When an operator reads sec-name, they will not necessarily recognize it as being snmp-security-name; I think you could imporve the meaningfulness of your typedefs. In Spectrum we avoided the use of "OID" and "ObjectIdentifier" in our GUI and called it something else ("variable name" or something), and operators complained because they would need to go to the User's Guide to see whether the definiiton/semantics of our naming matched the naming in the SNMP standard. Customers found it so confusing we had to change our screens to use the naming from the standard. Modifying the accepted naming should only be done with good reason. Obviously the change form securityName to security-name has a good reason; chaging from securityName to sec-name seems much less justified. I don't know what the identifier typedef refers to. What type of identifier is this in SNMP terms? is this an OID? see above. if so, keep in mind that OID is a term from the underlying (managed) functionality. You want to reflect what you are actually modeling, because the operator is going to think in the terminology appropriate to the thing being managed. Do you have a reference clause in YANG typedefs? that would help a lot here. Assuming this is true in yang as well, you might want to echo the fact that adminstring is measured in octets, not characters (due to internationalization). I think that might be important enough to mention in your typdef, rather than relying on the reference to 3411 to make that point. I'm a bit concerned with defining snmp-agent. SNMPv3 is designed so that "agent" just refers to a particualr configuration of snmp-applications within an engine. This is important because it caused massive problems in SNMPv2 when we tried to add informs, and had a security mib inside a manager. There is no clear definition of the difference between an SNMP agent and an SNMP manager and an SNMP proxy. An "agent" represents the aggregation of certain feature sets (command-responder, notification-originator, etc.). I recommend you focus on configuring the engine, independent of role, and then confugure specific feature sets. In SNMPv3, we wrote separate MIB modules to correspond to different functionality/features, such as USM, VACM, security models, messaging models, transport models, and applications; these are specific aspects of the underlying managed technology, much as spanning tree and vlans are aspects of bridging technology. I recommend against ignoring the underlying design. You might want to change udp-port to a union of transport protocol and port. If SNMP might use DNS to discover a manager-service, you might also want to include a service name in the union. This is becoming a fairly popular thing to do. Since I've been transport AD, I've seen a lot of things being defined as a service, and then DNS identifies the address, port, and transport protoocl to use to access the service. And I notice a new draft to do that. Is version extensible? (not that I think a new snmp version will be seen anytime soon, but with things like DNS lookup of an SNMP service and multiple interfaces and separation of identifier and address in HIP and LISP, I wouldn't rule it out totally. enterprise-number - you might want to reference the IANA enterprise-number registry. you have a typedef engine-id and a container engine-id. I assume it's legal in yang, but is that wise? more later ... dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, October 20, 2010 11:48 AM > To: Martin Bjorklund; netmod@ietf.org > Subject: Re: [netmod] Fw: New Version Notification for > draft-bjorklund-netmod-snmp-cfg-00 > > Hi, > > This draft is rather terse wrt/ purpose and fit within the > NETCONF standard. > There is 1 sentence: > > Abstract > > This document defines a collection of YANG definitions for > configuring SNMP engines. > > Since YANG is a data modeling language for NETCONF (it's even > in the title), > how is this supposed to be used? Since SNMP is not widely > used for configuration, > why is this work important to NETCONF standardization? If we > have an SMIv2 to YANG > mapping algorithm, why do we need to publish YANG versions of > SMIv2 modules? > > > Andy > > > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Wednesday, October 20, 2010 6:35 AM > To: netmod@ietf.org > Subject: [netmod] Fw: New Version Notification for > draft-bjorklund-netmod-snmp-cfg-00 > > Hi, > > This draft might be of interest for the WG, even though it is > not covered by our charter. > > Chair(s?) - if there is time when we meet in Beijing, we > would like to present this draft. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From biermana@Brocade.com Wed Oct 20 10:36:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC413A69F4 for ; Wed, 20 Oct 2010 10:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuJpr5xBC6pH for ; Wed, 20 Oct 2010 10:36:31 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id B5A3E3A6961 for ; Wed, 20 Oct 2010 10:36:30 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9KHaT6k001172; Wed, 20 Oct 2010 10:38:02 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s24pqr097-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Oct 2010 10:38:02 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Oct 2010 10:42:21 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 20 Oct 2010 10:38:00 -0700 From: Andy Bierman To: David Harrington , "'Martin Bjorklund'" , "netmod@ietf.org" Date: Wed, 20 Oct 2010 10:37:59 -0700 Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: ActwW6FEr0HfR4y2ShK503ZqpTm1NAAD/+qQAAGsEJAAAlotIA== Message-ID: References: <20101020.153501.236075803.mbj@tail-f.com> <86F02899CB3D40E8BB57AD97C522A178@23FX1C1> In-Reply-To: <86F02899CB3D40E8BB57AD97C522A178@23FX1C1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-20_08:2010-10-20, 2010-10-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010200097 X-Proofpoint-SSN: Sensitivity2 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:36:32 -0000 David, I did read the draft. I don't agree that the IETF needs to provide NETCONF write access to any SN= MP data. These objects have been available in SNMP. If they were that important, they would be implemented by now. I suppose if people want to implement this as a standard they should work on this draft. =20 Andy -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Wednesday, October 20, 2010 10:15 AM To: Andy Bierman; 'Martin Bjorklund'; netmod@ietf.org Subject: RE: [netmod] Fw: New Version Notification for draft-bjorklund-netm= od-snmp-cfg-00 Hi, Andy, You apparently didn't read the draft. Since SNMP is not widely used for configuration, we need something else to do that configuration. Netconf is the IETF-preferred standard for doing configuration.=20 This is a yang data model for doing configuration of SNMP engines using netconf. The draft seems quite light on text. I'll do a more thorough review when the document is fleshed out more. A point I will make is that the feature definitions do not align with snmpv3 (IETF) compliance requirements. These feature sets might make perfect sense from an ooperational point of view. But you should probably point out that not supporting the feature might make your configuration non-compliant to the IETF standard. For example, I think proxy and multiple context support are required as part of the snmpv3 standard. Regarding type definitions. If the WG documents will define normative translations of SMIv2 datatypes for admin-string, identifier, context-name, etc., it would be better to reference the other document. Is there a reason you are using abbreviations in your names? When an operator reads sec-name, they will not necessarily recognize it as being snmp-security-name; I think you could imporve the meaningfulness of your typedefs.=20 In Spectrum we avoided the use of "OID" and "ObjectIdentifier" in our GUI and called it something else ("variable name" or something), and operators complained because they would need to go to the User's Guide to see whether the definiiton/semantics of our naming matched the naming in the SNMP standard. Customers found it so confusing we had to change our screens to use the naming from the standard. Modifying the accepted naming should only be done with good reason. Obviously the change form securityName to security-name has a good reason; chaging from securityName to sec-name seems much less justified. I don't know what the identifier typedef refers to. What type of identifier is this in SNMP terms? is this an OID? see above. if so, keep in mind that OID is a term from the underlying (managed) functionality. You want to reflect what you are actually modeling, because the operator is going to think in the terminology appropriate to the thing being managed. Do you have a reference clause in YANG typedefs? that would help a lot here. Assuming this is true in yang as well, you might want to echo the fact that adminstring is measured in octets, not characters (due to internationalization). I think that might be important enough to mention in your typdef, rather than relying on the reference to 3411 to make that point. I'm a bit concerned with defining snmp-agent. SNMPv3 is designed so that "agent" just refers to a particualr configuration of snmp-applications within an engine. This is important because it caused massive problems in SNMPv2 when we tried to add informs, and had a security mib inside a manager. There is no clear definition of the difference between an SNMP agent and an SNMP manager and an SNMP proxy. An "agent" represents the aggregation of certain feature sets (command-responder, notification-originator, etc.).=20 I recommend you focus on configuring the engine, independent of role, and then confugure specific feature sets. In SNMPv3, we wrote separate MIB modules to correspond to different functionality/features, such as USM, VACM, security models, messaging models, transport models, and applications; these are specific aspects of the underlying managed technology, much as spanning tree and vlans are aspects of bridging technology. I recommend against ignoring the underlying design. You might want to change udp-port to a union of transport protocol and port.=20 If SNMP might use DNS to discover a manager-service, you might also want to include a service name in the union. This is becoming a fairly popular thing to do. Since I've been transport AD, I've seen a lot of things being defined as a service, and then DNS identifies the address, port, and transport protoocl to use to access the service. And I notice a new draft to do that. Is version extensible? (not that I think a new snmp version will be seen anytime soon, but with things like DNS lookup of an SNMP service and multiple interfaces and separation of identifier and address in HIP and LISP, I wouldn't rule it out totally. enterprise-number - you might want to reference the IANA enterprise-number registry. you have a typedef engine-id and a container engine-id. I assume it's legal in yang, but is that wise? more later ... dbh > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, October 20, 2010 11:48 AM > To: Martin Bjorklund; netmod@ietf.org > Subject: Re: [netmod] Fw: New Version Notification for=20 > draft-bjorklund-netmod-snmp-cfg-00 >=20 > Hi, >=20 > This draft is rather terse wrt/ purpose and fit within the=20 > NETCONF standard. > There is 1 sentence: >=20 > Abstract >=20 > This document defines a collection of YANG definitions for > configuring SNMP engines. >=20 > Since YANG is a data modeling language for NETCONF (it's even=20 > in the title), > how is this supposed to be used? Since SNMP is not widely=20 > used for configuration, > why is this work important to NETCONF standardization? If we=20 > have an SMIv2 to YANG > mapping algorithm, why do we need to publish YANG versions of=20 > SMIv2 modules? >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Wednesday, October 20, 2010 6:35 AM > To: netmod@ietf.org > Subject: [netmod] Fw: New Version Notification for=20 > draft-bjorklund-netmod-snmp-cfg-00 >=20 > Hi, >=20 > This draft might be of interest for the WG, even though it is=20 > not covered by our charter. >=20 > Chair(s?) - if there is time when we meet in Beijing, we=20 > would like to present this draft. >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Wed Oct 20 13:05:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3993A68EC for ; Wed, 20 Oct 2010 13:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDABzihZK2gV for ; Wed, 20 Oct 2010 13:05:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 73CF13A67AB for ; Wed, 20 Oct 2010 13:05:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3211C0004; Wed, 20 Oct 2010 22:06:44 +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 FXcG0AB8j+Fv; Wed, 20 Oct 2010 22:06:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B0A3C0002; Wed, 20 Oct 2010 22:06:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 691E61569293; Wed, 20 Oct 2010 22:06:04 +0200 (CEST) Date: Wed, 20 Oct 2010 22:06:04 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101020200604.GG24243@elstar.local> Mail-Followup-To: Andy Bierman , David Harrington , 'Martin Bjorklund' , "netmod@ietf.org" References: <20101020.153501.236075803.mbj@tail-f.com> <86F02899CB3D40E8BB57AD97C522A178@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:05:12 -0000 On Wed, Oct 20, 2010 at 10:37:59AM -0700, Andy Bierman wrote: > I don't agree that the IETF needs to provide NETCONF write access to any SNMP data. > These objects have been available in SNMP. If they were that important, > they would be implemented by now. > > I suppose if people want to implement this as a standard they should > work on this draft. Give me a honest answer: How do you configure your SNMP agent? Via SNMPv3 sets or via a CLI or config file? Shall we ask operators? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Wed Oct 20 13:17:46 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70503A68E8 for ; Wed, 20 Oct 2010 13:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VepT81W68eZ0 for ; Wed, 20 Oct 2010 13:17:45 -0700 (PDT) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by core3.amsl.com (Postfix) with ESMTP id 0374B3A68F6 for ; Wed, 20 Oct 2010 13:17:44 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o9KKJGA7029856 for ; Wed, 20 Oct 2010 16:19:18 -0400 Authentication-Results: cm-omr7 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.127.11.239] ([173.127.11.239:58478] helo=[173.127.11.239]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id DC/BB-11475-2CE4FBC4; Wed, 20 Oct 2010 16:19:16 -0400 To: "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" , "=?utf-8?B?QW5keSBCaWVybWFu?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 20 Oct 2010 13:19:30 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1287605970800" Cc: =?utf-8?B?bmV0bW9kQGlldGYub3Jn?= Subject: Re: [netmod] =?utf-8?q?Fw=3A_New_Version_Notification_for_draft-bjork?= =?utf-8?q?lund-netmod-snmp-cfg-00?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:17:47 -0000 ------=_Part_0_1287605970800 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U05NUCBpcyBjb25maWd1cmVkIHZpYSBDTEksCmFuZCB0aGUgY29uZmlnIGlzIHNpbXBsZSBhbmQg cmF0aGVyIGxpbWl0ZWQgaW4gc2NvcGUuICBBIHN0YW5kYXJkIHRoYXQgZm9yY2VkIHVzIHRvIGlt cGxlbWVudCBsb3RzIG1vcmUgU05NUCBjb25maWcga25vYnMgaXMgbm90IGEgcHJpb3JpdHkuCgoK Ci0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIg PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4KRGF0ZTogV2VkLCBPY3QgMjAs IDIwMTAgMTM6MDYKU3ViamVjdDogW25ldG1vZF0gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1zbm1wLWNmZy0wMApUbzogIkFuZHkgQmllcm1h biIgPGJpZXJtYW5hQEJyb2NhZGUuY29tPgpDYzogIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBp ZXRmLm9yZz4KCgpPbiBXZWQsIE9jdCAyMCwgMjAxMCBhdCAxMDozNzo1OUFNIC0wNzAwLCBBbmR5 IEJpZXJtYW4gd3JvdGU6Cgo+IEkgZG9uJ3QgYWdyZWUgdGhhdCB0aGUgSUVURiBuZWVkcyB0byBw cm92aWRlIE5FVENPTkYgd3JpdGUgYWNjZXNzIHRvIGFueSBTTk1QIGRhdGEuCj4gVGhlc2Ugb2Jq ZWN0cyBoYXZlIGJlZW4gYXZhaWxhYmxlIGluIFNOTVAuICBJZiB0aGV5IHdlcmUgdGhhdCBpbXBv cnRhbnQsCj4gdGhleSB3b3VsZCBiZSBpbXBsZW1lbnRlZCBieSBub3cuCj4gCj4gSSBzdXBwb3Nl IGlmIHBlb3BsZSB3YW50IHRvIGltcGxlbWVudCB0aGlzIGFzIGEgc3RhbmRhcmQgdGhleSBzaG91 bGQKPiB3b3JrIG9uIHRoaXMgZHJhZnQuICAKCkdpdmUgbWUgYSBob25lc3QgYW5zd2VyOiBIb3cg ZG8geW91IGNvbmZpZ3VyZSB5b3VyIFNOTVAgYWdlbnQ/IFZpYQpTTk1QdjMgc2V0cyBvciB2aWEg YSBDTEkgb3IgY29uZmlnIGZpbGU/IFNoYWxsIHdlIGFzayBvcGVyYXRvcnM/CgovanMKCi0tIApK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSApQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5 IEJyZW1lbiwgR2VybWFueQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKCg== ------=_Part_0_1287605970800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U05NUCBpcyBjb25maWd1cmVkIHZpYSBDTEksPGJyPmFuZCB0aGUgY29uZmlnIGlzIHNpbXBsZSBh bmQgcmF0aGVyIGxpbWl0ZWQgaW4gc2NvcGUuICZuYnNwO0Egc3RhbmRhcmQgdGhhdCBmb3JjZWQg dXMgdG8gaW1wbGVtZW50IGxvdHMgbW9yZSBTTk1QIGNvbmZpZyBrbm9icyBpcyBub3QgYSBwcmlv cml0eS48YnI+PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAm cXVvdDtKdWVyZ2VuIFNjaG9lbndhZWxkZXImcXVvdDsgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZSZndDs8YnI+RGF0ZTogV2VkLCBPY3QgMjAsIDIwMTAgMTM6MDY8YnI+ U3ViamVjdDogW25ldG1vZF0gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt YmpvcmtsdW5kLW5ldG1vZC1zbm1wLWNmZy0wMDxicj5UbzogJnF1b3Q7QW5keSBCaWVybWFuJnF1 b3Q7ICZsdDtiaWVybWFuYUBCcm9jYWRlLmNvbSZndDs8YnI+Q2M6ICZxdW90O25ldG1vZEBpZXRm Lm9yZyZxdW90OyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj48YnI+PGJyPk9uIFdlZCwgT2N0 IDIwLCAyMDEwIGF0IDEwOjM3OjU5QU0gLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+PGJy PiZndDsgSSBkb24mIzM5O3QgYWdyZWUgdGhhdCB0aGUgSUVURiBuZWVkcyB0byBwcm92aWRlIE5F VENPTkYgd3JpdGUgYWNjZXNzIHRvIGFueSBTTk1QIGRhdGEuPGJyPiZndDsgVGhlc2Ugb2JqZWN0 cyBoYXZlIGJlZW4gYXZhaWxhYmxlIGluIFNOTVAuICZuYnNwO0lmIHRoZXkgd2VyZSB0aGF0IGlt cG9ydGFudCw8YnI+Jmd0OyB0aGV5IHdvdWxkIGJlIGltcGxlbWVudGVkIGJ5IG5vdy48YnI+Jmd0 OyA8YnI+Jmd0OyBJIHN1cHBvc2UgaWYgcGVvcGxlIHdhbnQgdG8gaW1wbGVtZW50IHRoaXMgYXMg YSBzdGFuZGFyZCB0aGV5IHNob3VsZDxicj4mZ3Q7IHdvcmsgb24gdGhpcyBkcmFmdC4gJm5ic3A7 PGJyPjxicj5HaXZlIG1lIGEgaG9uZXN0IGFuc3dlcjogSG93IGRvIHlvdSBjb25maWd1cmUgeW91 ciBTTk1QIGFnZW50PyBWaWE8YnI+U05NUHYzIHNldHMgb3IgdmlhIGEgQ0xJIG9yIGNvbmZpZyBm aWxlPyBTaGFsbCB3ZSBhc2sgb3BlcmF0b3JzPzxicj48YnI+L2pzPGJyPjxicj4tLSA8YnI+SnVl cmdlbiBTY2hvZW53YWVsZGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdl cm1hbnk8YnI+RmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEwMyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj5o dHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PGJyPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm5ldG1vZCBtYWlsaW5nIGxpc3Q8 YnI+bmV0bW9kQGlldGYub3JnPGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZDwvYT48YnI+PGJyPjxicj48YnI+ ------=_Part_0_1287605970800-- From mbj@tail-f.com Wed Oct 20 13:30:36 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF86E3A6947 for ; Wed, 20 Oct 2010 13:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmmW8xGCrjly for ; Wed, 20 Oct 2010 13:30:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B959C3A6911 for ; Wed, 20 Oct 2010 13:30:32 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id F086E616012; Wed, 20 Oct 2010 22:32:04 +0200 (CEST) Date: Wed, 20 Oct 2010 22:32:01 +0200 (CEST) Message-Id: <20101020.223201.93340544.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <86F02899CB3D40E8BB57AD97C522A178@23FX1C1> References: <20101020.153501.236075803.mbj@tail-f.com> <86F02899CB3D40E8BB57AD97C522A178@23FX1C1> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:30:36 -0000 Hi David, "David Harrington" wrote: > The draft seems quite light on text. To put it mildly... :) We decided to publish what we had, and since we got these comments from you, I think that was the right thing to do! It started out (in the early days of YANG) as an exercise to see what a configuration model for VACM could look like in YANG, then it grew to be a complete model for an agent, and now it has actually been implemented and is used in some products. > I'll do a more thorough review when the document is fleshed out more. > > A point I will make is that the feature definitions do not align with > snmpv3 (IETF) compliance requirements. > These feature sets might make perfect sense from an ooperational point > of view. > But you should probably point out that not supporting the feature > might make your configuration non-compliant to the IETF standard. For > example, I think proxy and multiple context support are required as > part of the snmpv3 standard. I agree that the features should match the compliance requirements. But I think they do. 3413 says: A proxy forwarder application forwards SNMP messages. Note that implementation of a proxy forwarder application is optional. Our feature should use this terminology though, and have a reference to 3413. 3411 says: An SNMP entity potentially has access to many contexts. and I don't think there is anything that says that a particular engine MUST have more than one context. There is also no way to configure contexts over SNMP. Maybe we should add more features for vacm, usm, (tsm). > Regarding type definitions. If the WG documents will define normative > translations of SMIv2 datatypes for admin-string, identifier, > context-name, etc., it would be better to reference the other > document. Ok. > Is there a reason you are using abbreviations in your names? When an > operator reads sec-name, they will not necessarily recognize it as > being snmp-security-name; I think you could imporve the meaningfulness > of your typedefs. Ok. > In Spectrum we avoided the use of "OID" and "ObjectIdentifier" in our > GUI and called it something else ("variable name" or something), and > operators complained because they would need to go to the User's Guide > to see whether the definiiton/semantics of our naming matched the > naming in the SNMP standard. Customers found it so confusing we had to > change our screens to use the naming from the standard. Modifying the > accepted naming should only be done with good reason. Obviously the > change form securityName to security-name has a good reason; chaging > from securityName to sec-name seems much less justified. Ok. > I don't know what the identifier typedef refers to. What type of > identifier is this in SNMP terms? Note that the 'identifier' type is a restricted admin-string: typedef identifier { type admin-string { length "1..32"; } It is just a convenient type for a common restriction in these MIBS, e.g.: snmpTargetAddrName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) snmpTargetParamsName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) vacmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) etc. We should at least describe it better, probably rename it. An option is to remove it and use the same kind of restriction as in the MIBs. > is this an OID? see above. if so, > keep in mind that OID is a term from the underlying (managed) > functionality. You want to reflect what you are actually modeling, > because the operator is going to think in the terminology appropriate > to the thing being managed. > > Do you have a reference clause in YANG typedefs? that would help a lot > here. Yes, we can use reference in typedefs; I will add that. > Assuming this is true in yang as well, you might want to echo the fact > that adminstring is measured in octets, not characters (due to > internationalization). I think that might be important enough to > mention in your typdef, rather than relying on the reference to 3411 > to make that point. No, it is not true in YANG; the string's length restriction is number of characters. So the current restriction is not quite correct. We have to do something, probably describe the real (number of octets) restriction in the description clause. > I'm a bit concerned with defining snmp-agent. SNMPv3 is designed so > that "agent" just refers to a particualr configuration of > snmp-applications within an engine. This is important because it > caused massive problems in SNMPv2 when we tried to add informs, and > had a security mib inside a manager. There is no clear definition of > the difference between an SNMP agent and an SNMP manager and an SNMP > proxy. An "agent" represents the aggregation of certain feature sets > (command-responder, notification-originator, etc.). > > I recommend you focus on configuring the engine, independent of role, > and then confugure specific feature sets. Ok. The focus for us has really been the "agent" part (obviously...). I'll think about what we can do. > In SNMPv3, we wrote separate > MIB modules to correspond to different functionality/features, such as > USM, VACM, security models, messaging models, transport models, and > applications; these are specific aspects of the underlying managed > technology, much as spanning tree and vlans are aspects of bridging > technology. I recommend against ignoring the underlying design. > > You might want to change udp-port to a union of transport protocol and > port. > If SNMP might use DNS to discover a manager-service, you might also > want to include a service name in the union. This is becoming a fairly > popular thing to do. Since I've been transport AD, I've seen a lot of > things being defined as a service, and then DNS identifies the > address, port, and transport protoocl to use to access the service. > And I notice a new draft to do that. I saw that too. Yes, I agree we need to make this more flexible. > Is version extensible? No it isn't. It could be made extensible, but this enum is simpler, and even if we'll see a new version someday, it's not likely new versions will be added often. So if it happens, this enum must be revised. > (not that I think a new snmp version will be > seen anytime soon, but with things like DNS lookup of an SNMP service > and multiple interfaces and separation of identifier and address in > HIP and LISP, I wouldn't rule it out totally. > > enterprise-number - you might want to reference the IANA > enterprise-number registry. Ok. > you have a typedef engine-id and a container engine-id. I assume it's > legal in yang, but is that wise? Yes, it is legal, but you're probably right. Thanks again for your comments! /martin P.S. I extended the very handy tool 'smistrip' so that it can extract YANG modules, and actually any code component marked with the convention we use in the NETMOD/NETCONF specs. If anyone is interested, it is available at: http://www.yang-central.org/twiki/pub/Main/YangTools/rfcstrip D.S. From saperia@jdscons.com Wed Oct 20 13:44:00 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C623A68C2 for ; Wed, 20 Oct 2010 13:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZRzAhcqHa1f for ; Wed, 20 Oct 2010 13:43:59 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id B13AA3A67A7 for ; Wed, 20 Oct 2010 13:43:59 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o9KKjTqr014910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Oct 2010 15:45:30 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: <20101020200604.GG24243@elstar.local> Date: Wed, 20 Oct 2010 16:45:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101020.153501.236075803.mbj@tail-f.com> <86F02899CB3D40E8BB57AD97C522A178@23FX1C1> <20101020200604.GG24243@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1081) Cc: Andy Bierman , "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:44:01 -0000 On Oct 20, 2010, at 4:06 PM, Juergen Schoenwaelder wrote: > On Wed, Oct 20, 2010 at 10:37:59AM -0700, Andy Bierman wrote: >=20 >> I don't agree that the IETF needs to provide NETCONF write access to = any SNMP data. >> These objects have been available in SNMP. If they were that = important, >> they would be implemented by now. >>=20 >> I suppose if people want to implement this as a standard they should >> work on this draft. =20 >=20 > Give me a honest answer: How do you configure your SNMP agent? Via > SNMPv3 sets or via a CLI or config file? Shall we ask operators? =46rom what I have seen: .. it depends on the type of system in my experience. Some basic = systems use things like snmpd.cnf or a variant of that for configuration = even though there is full access to the standard MIB Objects for = configuration of the SNMP Framework. That does not mean that there is = no CLI access either. Many systems I have seen support SNMP, CLI and = File. The access method is dependent on how complex the overall system = is. YMMV. In those cases where there are multiple access methods (the case for = most of the systems I know), how the rest of the management environment = and NOC is organized are the determining factors..=20 /jon >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From j.schoenwaelder@jacobs-university.de Wed Oct 20 13:44:18 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281C93A6905 for ; Wed, 20 Oct 2010 13:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21rIJ82VxfAK for ; Wed, 20 Oct 2010 13:44:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 432FD3A68C2 for ; Wed, 20 Oct 2010 13:44:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0399C0002; Wed, 20 Oct 2010 22:45:50 +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 TfZ7F9Yqc36j; Wed, 20 Oct 2010 22:45:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26D47C0004; Wed, 20 Oct 2010 22:45:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 32090156950B; Wed, 20 Oct 2010 22:45:11 +0200 (CEST) Date: Wed, 20 Oct 2010 22:45:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101020204511.GA24577@elstar.local> Mail-Followup-To: Andy Bierman , Andy Bierman , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andy Bierman , "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:44:18 -0000 On Wed, Oct 20, 2010 at 01:19:30PM -0700, Andy Bierman wrote: > SNMP is configured via CLI, and the config is simple and rather > limited in scope. So you are saying there is no need for NETCONF since there is always a proprietary CLI that does the job. Interesting late insights? > A standard that forced us to implement lots more SNMP config knobs > is not a priority. We do not claim this is a priority work item. I personally would appreciate to see more YANG data models popping up in individual IDs. But perhaps this is not welcome by everyone. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Oct 20 13:46:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93A03A68C2 for ; Wed, 20 Oct 2010 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY3LRAeL+B83 for ; Wed, 20 Oct 2010 13:46:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B82C53A6946 for ; Wed, 20 Oct 2010 13:46:20 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 24E04616004; Wed, 20 Oct 2010 22:47:54 +0200 (CEST) Date: Wed, 20 Oct 2010 22:47:51 +0200 (CEST) Message-Id: <20101020.224751.41501184.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: biermana@Brocade.com, netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:46:21 -0000 "Andy Bierman" wrote: > SNMP is configured via CLI, > and the config is simple and rather limited in scope. A standard that forced > us to implement lots more SNMP config knobs is not a priority. FWIW, some rather big router vendors do support more or less full SNMP config (like the one presented in this draft) via their CLIs. And you are not forced to implement this ;-) /martin From biermana@Brocade.com Wed Oct 20 14:23:26 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7583A682F for ; Wed, 20 Oct 2010 14:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhTDRCyKO+OU for ; Wed, 20 Oct 2010 14:23:25 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 7E17F3A67FB for ; Wed, 20 Oct 2010 14:23:25 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9KLL6lg002728; Wed, 20 Oct 2010 14:24:58 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id s27s680h0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Oct 2010 14:24:58 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Oct 2010 14:29:17 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 20 Oct 2010 14:24:56 -0700 From: Andy Bierman To: Juergen Schoenwaelder Date: Wed, 20 Oct 2010 14:24:54 -0700 Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: Actwl8yQf20eWd0hTgegszICiAFxUwAAI9pQ Message-ID: References: <20101020204511.GA24577@elstar.local> In-Reply-To: <20101020204511.GA24577@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-20_10:2010-10-20, 2010-10-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010200130 X-Proofpoint-SSN: Sensitivity2 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:23:26 -0000 Hi, I think NETCONF configuration of the SNMP agent is a low priority for my co= mpany. Besides configuring community strings, there is not much we need to support= . This represents a few CLI commands out of 1000s. The small number of knobs we currently need to support SNMP Get operations = are already done, and this limited configurability is not holding back any of o= ur NMS developers. =20 The tradition in the IETF is to let people have their sandbox, so if others want to work on this, then that's great. We don't have to agree on the relative priority. The IESG needs to worry about enough resources, proper = review, etc., but that's not usually a problem. Looking forward, the operational data that SNMP provides is going to become NETCONF data (via your SMIv2 mapping or N proprietary mappings), so the SNMP agent is going to be less and less important over time. I agree that configuring the SNMP agent is a self-contained problem, and knowing how well NETCONF/YANG addresses self-contained modeling problem= s is useful to know. To that end, I would prefer configuring NTP or OSPF as an exercise, rather than baggage-laden SNMP. Andy =20 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Wednesday, October 20, 2010 1:45 PM To: Andy Bierman Cc: Andy Bierman; netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netm= od-snmp-cfg-00 On Wed, Oct 20, 2010 at 01:19:30PM -0700, Andy Bierman wrote: > SNMP is configured via CLI, and the config is simple and rather > limited in scope. So you are saying there is no need for NETCONF since there is always a proprietary CLI that does the job. Interesting late insights? > A standard that forced us to implement lots more SNMP config knobs > is not a priority. We do not claim this is a priority work item. I personally would appreciate to see more YANG data models popping up in individual IDs. But perhaps this is not welcome by everyone. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From phil@juniper.net Wed Oct 20 14:37:04 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE68C3A6914 for ; Wed, 20 Oct 2010 14:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz1sIVeEuYep for ; Wed, 20 Oct 2010 14:37:03 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id BF80F3A695A for ; Wed, 20 Oct 2010 14:35:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTL9g8Y2483LZDEkEGCe/q7e9xt4bz430@postini.com; Wed, 20 Oct 2010 14:37:34 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Oct 2010 14:35:33 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o9KLZWU73053; Wed, 20 Oct 2010 14:35:32 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o9KLEbwh036374; Wed, 20 Oct 2010 21:14:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010202114.o9KLEbwh036374@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20101020200604.GG24243@elstar.local> Date: Wed, 20 Oct 2010 17:14:37 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Andy Bierman , "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:37:05 -0000 Juergen Schoenwaelder writes: >Give me a honest answer: How do you configure your SNMP agent? Via >SNMPv3 sets or via a CLI or config file? Shall we ask operators? Heck, give an honest prediction: How will you configure your NETCONF user and permissions? CLI, NETCONF, or RADIUS? Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Oct 20 14:42:51 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C163A6979 for ; Wed, 20 Oct 2010 14:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzsCEraWu6Ng for ; Wed, 20 Oct 2010 14:42:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D21C23A6914 for ; Wed, 20 Oct 2010 14:41:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63335C0004; Wed, 20 Oct 2010 23:41:35 +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 tMhr1qzWPh9z; Wed, 20 Oct 2010 23:41:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D6F5C0002; Wed, 20 Oct 2010 23:41:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6EA5315697CD; Wed, 20 Oct 2010 23:40:53 +0200 (CEST) Date: Wed, 20 Oct 2010 23:40:53 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20101020214053.GD24670@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , "netmod@ietf.org" References: <20101020200604.GG24243@elstar.local> <201010202114.o9KLEbwh036374@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010202114.o9KLEbwh036374@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andy Bierman , "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:42:51 -0000 On Wed, Oct 20, 2010 at 05:14:37PM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Give me a honest answer: How do you configure your SNMP agent? Via > >SNMPv3 sets or via a CLI or config file? Shall we ask operators? > > Heck, give an honest prediction: How will you configure your NETCONF > user and permissions? CLI, NETCONF, or RADIUS? Perhaps a CLI running over NETCONF to configure how a RADIUS server validates user credentials. Can I not do this with SNMP? Please. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 21 01:40:38 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5252B3A69F4 for ; Thu, 21 Oct 2010 01:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQfG28sz7HAk for ; Thu, 21 Oct 2010 01:40:36 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 98ACA3A69DD for ; Thu, 21 Oct 2010 01:40:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,216,1286164800"; d="scan'208";a="212926729" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Oct 2010 04:42:10 -0400 X-IronPort-AV: E=Sophos;i="4.58,216,1286164800"; d="scan'208";a="528541079" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 04:42:09 -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, 21 Oct 2010 10:41:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: Thread-Index: Actw7F4g30WG9y/fTVmCAGA6FK49tAAD0z3Q From: "Romascanu, Dan (Dan)" To: "Ladislav Lhotka" Cc: netmod@ietf.org Subject: [netmod] FW: DISCUSS: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 08:40:38 -0000 Hi Lada, Please address the issue raised by Alexey in his DISCUSS.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Thursday, October 21, 2010 8:50 AM To: iesg@ietf.org Cc: draft-ietf-netmod-dsdl-map@tools.ietf.org; netmod-chairs@tools.ietf.org Subject: DISCUSS: Discuss: This is a well written document, a pleasure to read. I have one minor issue that I would like to quickly discuss before recommending approval of this document: In Section 11.3 (on page 74): /nc:rpc-reply/nc:data ex6:outer 1 2 This looks like a cut and paste error (extra text), can you please confirm? /nc:rpc-reply/nc:data ex6:outer 1 2 [...] From root@core3.amsl.com Thu Oct 21 03:00:22 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3E9503A69A1; Thu, 21 Oct 2010 03:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101021100011.3E9503A69A1@core3.amsl.com> Date: Thu, 21 Oct 2010 03:00:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 10:00:22 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka Filename : draft-ietf-netmod-dsdl-map-09.txt Pages : 112 Date : 2010-10-21 This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF message etc. Procedures for schema-based validation of such documents are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-dsdl-map-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-21025357.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Thu Oct 21 07:11:39 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAB03A69FB for ; Thu, 21 Oct 2010 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynFfzGq2Yv-W for ; Thu, 21 Oct 2010 07:11:36 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 196E53A6A1C for ; Thu, 21 Oct 2010 07:11:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,217,1286164800"; d="scan'208";a="213012362" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Oct 2010 10:12:54 -0400 X-IronPort-AV: E=Sophos;i="4.58,217,1286164800"; d="scan'208";a="528723522" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 10:12:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 16:12:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: Thread-Index: ActxKBzLkGbGbIzlRZWhQwIePScQ1gAAcCyQ From: "Romascanu, Dan (Dan)" To: "Ladislav Lhotka" Cc: netmod@ietf.org Subject: [netmod] FW: DISCUSS: X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 14:11:40 -0000 Hi Lada, Please address the issues raised by Sean in his DISCUSS.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of = Sean Turner Sent: Thursday, October 21, 2010 3:57 PM To: iesg@ietf.org Cc: draft-ietf-netmod-dsdl-map@tools.ietf.org; = netmod-chairs@tools.ietf.org Subject: DISCUSS: Discuss: This is a discuss-discuss (I'm not asking for any changes - just trying = to figure this out) DSRL can change the validated schema. The validated schema is the bit = that normally would have been sent down the wire from say a client to a = server. From what I've yahoooo!-ed, DSRL can be used to modify the = names of elements and fields. Say a client changes the name of a field = called "stop" to "arr=EAt" - who is the server going to know to undo = that change to get back to a validated schema? Are the all the mappings = performed sent along from the client to the server to facilitate this? The document includes the following text: While the mapping from YANG to DSDL described in this document may in = principle be invertible, the inverse mapping from DSDL to YANG is beyond = the scope of this document. Are we setting ourselves for clients who send stuff to servers and the = server can't validate that the response is a validate schema? From ietfdbh@comcast.net Thu Oct 21 08:29:56 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4903A6A45 for ; Thu, 21 Oct 2010 08:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2Dypgmvk7y3 for ; Thu, 21 Oct 2010 08:29:47 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 1446A3A684C for ; Thu, 21 Oct 2010 08:29:41 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta10.westchester.pa.mail.comcast.net with comcast id MPK71f0050EZKEL5ATX7DW; Thu, 21 Oct 2010 15:31:07 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta01.westchester.pa.mail.comcast.net with comcast id MTX41f00S2JQnJT3MTX5vZ; Thu, 21 Oct 2010 15:31:07 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Andy Bierman'" References: <20101020204511.GA24577@elstar.local> Date: Thu, 21 Oct 2010 11:30:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20101020204511.GA24577@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: Actwl8qASxlCijNvSdO/VjdG9t+C5gAmfRKg Cc: 'Andy Bierman' , netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:29:56 -0000 Hi, So the operators explained that one of the major problems with the MIB approach is that the MIB data models did not allow configuring **everything** on a target device, whereas CLI gave them access to everything. If YANG modeling is going to be more useful than MIB modeling, it has a long way to go to make everything on the box configurable using Netconf. Certainly some things might be more important than others, but I am with Juergen that individual YANG models are better than none. If you want to prioritize IETF efforts at standardizing YANG models, then it would be wise to focus on widely-deployed IETF standard technologies that operators find fairly complex to configure. SNMP is one of the IETF standards that fit that description. Of course, many deployments of widely-deployed IETF technolgies are based on toolkits or licensed stacks, so convincing the toolkit producers to support configuration using Netconif and YANG will be fairly important to encouraging Netconf/YANG deployment. Some of the major SNMP toolkit vendors are actively participating in, or actively monitoring the progress of, YANG so the SNMP toolkit environment might be a pretty good priority. If you attend NANOG, a tremendous amount of discussion is about routing protocols like BGP, so that would also be a reasonable priority. Are the leading vendors of routing stacks active in netmod? dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, October 20, 2010 4:45 PM > To: Andy Bierman > Cc: Andy Bierman; netmod@ietf.org > Subject: Re: [netmod] Fw: New Version Notification for > draft-bjorklund-netmod-snmp-cfg-00 > > On Wed, Oct 20, 2010 at 01:19:30PM -0700, Andy Bierman wrote: > > > SNMP is configured via CLI, and the config is simple and rather > > limited in scope. > > So you are saying there is no need for NETCONF since there is always a > proprietary CLI that does the job. Interesting late insights? > > > A standard that forced us to implement lots more SNMP config knobs > > is not a priority. > > We do not claim this is a priority work item. I personally would > appreciate to see more YANG data models popping up in individual IDs. > But perhaps this is not welcome by everyone. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From wjhns1@hardakers.net Thu Oct 21 09:27:50 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15233A693B for ; Thu, 21 Oct 2010 09:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjxqdvrfXPPA for ; Thu, 21 Oct 2010 09:27:49 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 941563A6910 for ; Thu, 21 Oct 2010 09:27:49 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 682AA98098; Thu, 21 Oct 2010 09:29:04 -0700 (PDT) From: Wes Hardaker To: Martin Bjorklund Organization: Sparta References: <20101020.153501.236075803.mbj@tail-f.com> Date: Thu, 21 Oct 2010 09:29:04 -0700 In-Reply-To: <20101020.153501.236075803.mbj@tail-f.com> (Martin Bjorklund's message of "Wed, 20 Oct 2010 15:35:01 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:27:50 -0000 Though interesting and I have no objection to actually following it up and making it happen, I don't think it's the best use of our resources at this time. (That being said, if there is people that want to do the work my opinion is that the IETF should let the work happen rather than say "no, not at this time). For myself, though, it would make more sense to concentrate on models that operators really need the most, like routing, user tables, firewalls, etc. Spending time configuring SNMP will likely only delay working on the real problems people care the most about unless we can do them all at once. [on a side note: I sure get a lot of questions from people about configuring SNMP using SNMP; if no one is doing it, why am I getting questions?] -- Wes Hardaker Cobham Analytic Solutions From biermana@Brocade.com Thu Oct 21 10:33:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFBE63A6A81 for ; Thu, 21 Oct 2010 10:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YN0pMtCKI4r for ; Thu, 21 Oct 2010 10:33:29 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 2B8D43A6A7C for ; Thu, 21 Oct 2010 10:33:29 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9LHVY6E001117; Thu, 21 Oct 2010 10:35:04 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s2sd6r0jd-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Oct 2010 10:35:03 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Oct 2010 10:39:21 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 21 Oct 2010 10:35:02 -0700 From: Andy Bierman To: David Harrington , "'Juergen Schoenwaelder'" Date: Thu, 21 Oct 2010 10:34:57 -0700 Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: Actwl8qASxlCijNvSdO/VjdG9t+C5gAmfRKgAAPl0vA= Message-ID: References: <20101020204511.GA24577@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-21_08:2010-10-21, 2010-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010210129 X-Proofpoint-SSN: Sensitivity2 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:33:31 -0000 Hi, I recall that the operators present at that meeting almost 10 years ago did= not even agree all the time, or about all the details. Getting 'CLI access to everything' vs. 'NETCONF access to everything' is an implementation detail. In the end, this is becomes a business decision by each vendor. There will never be a data model that has both sufficient scope and WG consensus as a complete solution -- ever. The problem is that product differentiation will always get in the way. The success of standard data models depends mostly on the ability of individual vendors to integrate the standard with their own proprietary models. Unlike multiple readers, supporting multiple writers (i.e., more than 1 config=3Dtrue object for the same knob) requires real work and planning. But we keep insisting (for 20 years now) that the only thing that matters is the quality of the content written by the IETF. Complete solutions only= , even if that makes implementation for vendors difficult or impractical. Even if it takes many years to complete the standard. XML makes it easy to combine content from multiple namespaces into a single retrieval or edit operation. Unlike SMIv2 OIDs, the identifier for a NETCO= NF database node has semantics (the node's ancestors). It is easy to get everything related to a particular protocol or service in 1 operation, without knowing a priori every 'place' to look for related data. The line between vendor data and standard data gets blurred. The biggest problem facing a meaningful standards effort is time. A vendor can knock out a data model in a few months. The same effort takes 2 - 3 years in the IETF. This is just a non-starter from a business POV. Waiting for the RFC to come out is not an option. Adding the standard later is the most likely option, and it is much harder to do that for writable objects than read-only objects. The NETMOD WG already agreed on 3 areas for new work: - system - interfaces - routing That is why I think we need to get a simple framework done in 4 - 6 months. 1) The SNMP system group as starting point 2) interface table has only 'name' and 'ifIndex' (maybe a few more details ala IF-STACK-MIB) 3) A routing framework data model (and maybe protocol-specific modules if writers and reviewers are available) Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= David Harrington Sent: Thursday, October 21, 2010 8:31 AM To: 'Juergen Schoenwaelder'; 'Andy Bierman' Cc: Andy Bierman; netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netm= od-snmp-cfg-00 Hi, So the operators explained that one of the major problems with the MIB approach is that the MIB data models did not allow configuring **everything** on a target device, whereas CLI gave them access to everything. If YANG modeling is going to be more useful than MIB modeling, it has a long way to go to make everything on the box configurable using Netconf. Certainly some things might be more important than others, but I am with Juergen that individual YANG models are better than none.=20 If you want to prioritize IETF efforts at standardizing YANG models, then it would be wise to focus on widely-deployed IETF standard technologies that operators find fairly complex to configure. SNMP is one of the IETF standards that fit that description. Of course, many deployments of widely-deployed IETF technolgies are based on toolkits or licensed stacks, so convincing the toolkit producers to support configuration using Netconif and YANG will be fairly important to encouraging Netconf/YANG deployment. Some of the major SNMP toolkit vendors are actively participating in, or actively monitoring the progress of, YANG so the SNMP toolkit environment might be a pretty good priority.=20 If you attend NANOG, a tremendous amount of discussion is about routing protocols like BGP, so that would also be a reasonable priority. Are the leading vendors of routing stacks active in netmod?=20 dbh > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, October 20, 2010 4:45 PM > To: Andy Bierman > Cc: Andy Bierman; netmod@ietf.org > Subject: Re: [netmod] Fw: New Version Notification for=20 > draft-bjorklund-netmod-snmp-cfg-00 >=20 > On Wed, Oct 20, 2010 at 01:19:30PM -0700, Andy Bierman wrote: >=20 > > SNMP is configured via CLI, and the config is simple and rather > > limited in scope. >=20 > So you are saying there is no need for NETCONF since there is always a > proprietary CLI that does the job. Interesting late insights? >=20 > > A standard that forced us to implement lots more SNMP config knobs > > is not a priority. >=20 > We do not claim this is a priority work item. I personally would > appreciate to see more YANG data models popping up in individual IDs. > But perhaps this is not welcome by everyone. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From dromasca@avaya.com Thu Oct 21 10:42:54 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3493A6A22 for ; Thu, 21 Oct 2010 10:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpXwfzdw1f+E for ; Thu, 21 Oct 2010 10:42:54 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 0F46F3A6866 for ; Thu, 21 Oct 2010 10:42:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="40138384" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 21 Oct 2010 13:44:29 -0400 X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="528799917" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 13:44:28 -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, 21 Oct 2010 19:44:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-netmod-dsdl-map-09 approved by the IESG Thread-Index: ActxR5aJrYfCu6JMRYaOFwsL/cedzg== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] draft-ietf-netmod-dsdl-map-09 approved by the IESG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:42:55 -0000 The IESG approved in the telechat today draft-ietf-netmod-dsdl-map-09 as PS. Thanks to everybody who contributed and especially to Lada.=20 Lada, are there any edits that are still to be made following the discussions with the ADs, or is draft-09 ready to go?=20 Dan From dromasca@avaya.com Thu Oct 21 10:50:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728F53A6A1B for ; Thu, 21 Oct 2010 10:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnExWd5QuXtv for ; Thu, 21 Oct 2010 10:50:51 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 54FF13A68F3 for ; Thu, 21 Oct 2010 10:50:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="243915824" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2010 13:52:26 -0400 X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="525406382" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Oct 2010 13:52:26 -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, 21 Oct 2010 19:52:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering of NETMOD approved by the IESG Thread-Index: ActxSKvhe2XfcOLPSbyST9C2zSkCAg== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] Rechartering of NETMOD approved by the IESG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:50:52 -0000 The rechartering of NETMOD was approved by the IESG in the telechat today.=20 The only question was asked by David Harrington and was related to the fact that the last item in the charter (#4) seems to be a departure from the original focus of NETCONF and YANG on configuration. My reading is that this item should be allowed, so that operators will have at hand the option of using new developped YANG modules or existing standard MIB modules (in SMI or mapped into YANG) and chose what they want to use. That's why I supported this point in the charter.=20 Good luck an please start making the new charter happen.=20 Dan From lhotka@cesnet.cz Thu Oct 21 10:51:56 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C513A6A85 for ; Thu, 21 Oct 2010 10:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAVTKPBxgh6H for ; Thu, 21 Oct 2010 10:51:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 619083A68F3 for ; Thu, 21 Oct 2010 10:51:55 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 45E412CDE072; Thu, 21 Oct 2010 19:53:29 +0200 (CEST) From: Ladislav Lhotka To: "Romascanu, Dan (Dan)" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 19:53:28 +0200 Message-ID: <1287683608.1606.111.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-dsdl-map-09 approved by the IESG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:51:56 -0000 Hi Dan, On Čt, 2010-10-21 at 19:44 +0200, Romascanu, Dan (Dan) wrote: > The IESG approved in the telechat today draft-ietf-netmod-dsdl-map-09 as > PS. Thanks to everybody who contributed and especially to Lada. Good news, thanks! > > Lada, are there any edits that are still to be made following the > discussions with the ADs, or is draft-09 ready to go? There are two edits based on the comments by Peter Saint-Andre. I hope the IANA templates are correct and need no other changes. So should I submit -10 with those two changes now? Lada > > > Dan > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dromasca@avaya.com Thu Oct 21 10:54:14 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7993A6A43 for ; Thu, 21 Oct 2010 10:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWuHuJbDVA9U for ; Thu, 21 Oct 2010 10:54:12 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id D6A823A6A83 for ; Thu, 21 Oct 2010 10:54:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="40140352" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 21 Oct 2010 13:55:43 -0400 X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="525407208" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Oct 2010 13:55:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 19:54:50 +0200 Message-ID: In-Reply-To: <1287683608.1606.111.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] draft-ietf-netmod-dsdl-map-09 approved by the IESG Thread-Index: ActxSOE8hvX8A6nMRrGirC0OhLDpjAAABTgA References: <1287683608.1606.111.camel@missotis> From: "Romascanu, Dan (Dan)" To: "Ladislav Lhotka" Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-dsdl-map-09 approved by the IESG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:54:14 -0000 Yes, please submit draft-10 and thanks for all the good work.=20 Regards, Dan > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz]=20 > Sent: Thursday, October 21, 2010 7:53 PM > To: Romascanu, Dan (Dan) > Cc: netmod@ietf.org > Subject: Re: [netmod] draft-ietf-netmod-dsdl-map-09 approved=20 > by the IESG >=20 > Hi Dan, >=20 > On =C8t, 2010-10-21 at 19:44 +0200, Romascanu, Dan (Dan) wrote: > > The IESG approved in the telechat today=20 > draft-ietf-netmod-dsdl-map-09=20 > > as PS. Thanks to everybody who contributed and especially to Lada. >=20 > Good news, thanks! >=20 > >=20 > > Lada, are there any edits that are still to be made following the=20 > > discussions with the ADs, or is draft-09 ready to go? >=20 > There are two edits based on the comments by Peter=20 > Saint-Andre. I hope the IANA templates are correct and need=20 > no other changes. >=20 > So should I submit -10 with those two changes now? >=20 > Lada >=20 > > =20 > >=20 > > Dan > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 >=20 From phil@juniper.net Thu Oct 21 11:08:22 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298143A6923 for ; Thu, 21 Oct 2010 11:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQPv11RIg4IN for ; Thu, 21 Oct 2010 11:08:21 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id AB2FC3A6452 for ; Thu, 21 Oct 2010 11:07:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTMCBx70WwnfjQt48SQyH/KjtTv9wLED1@postini.com; Thu, 21 Oct 2010 11:09:57 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Oct 2010 11:07:32 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o9LI7VU18690; Thu, 21 Oct 2010 11:07:31 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o9LHkamK042826; Thu, 21 Oct 2010 17:46:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201010211746.o9LHkamK042826@idle.juniper.net> To: David Harrington In-Reply-To: Date: Thu, 21 Oct 2010 13:46:36 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: 'Andy Bierman' , netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:08:22 -0000 "David Harrington" writes: >So the operators explained that one of the major problems with the MIB >approach is that the MIB data models did not allow configuring >**everything** on a target device, whereas CLI gave them access to >everything. With NETCONF/YANG, the argument is a little different. So let's say I want to make an application to configure PWE tunnels thru my network, and the standard defines 80% of what I need. If I can use NETCONF to access non-YANG-modeled data or proprietary YANG-modeled data to get the other 20%, then I'm happy. If I need to resort to screen scraping to get to data, then I might as well use the screen scraping method to get the whole kit-n-kaboodle. >If YANG modeling is going to be more useful than MIB modeling, it has >a long way to go to make everything on the box configurable using >Netconf. Certainly some things might be more important than others, >but I am with Juergen that individual YANG models are better than >none. With NETCONF/YANG we have built a smaller hill, since the only requirement is that the device expose all configuration via NETCONF, which is required to have a functional NETCONF implementation. Once that burden has been met, it works as an "escape hatch" for data that is not YANG'd yet. SNMP had no such mechanism, so the fall back was screen scraping. >If you want to prioritize IETF efforts at standardizing YANG models, >then it would be wise to focus on widely-deployed IETF standard >technologies that operators find fairly complex to configure. SNMP is >one of the IETF standards that fit that description. I've written some words recently about when automation is a win. Here's a snippet: ------- * Conditions for Automation We've looked at a number of on-box features that make automation more robust and reliable. Let's look briefly at when automation can pay maximum dividends. When is automation and flow-through provisioning an appropriate solution? There are four qualities that a problem must have to be a good candidate: - complexity -- Is is a hard problem? - frequency -- Do changes happen often? - importance -- Will failures matter? - scale -- Is the rate of change relatively high? If the answer to these four is "yes", then the problem is a good candidate and the cost of using automation will be paid for by the increase in the robustness, ease of use, certainty, assurance, and scaling that automation can provide. A change that's needed once a year on ten boxes is likely not a candidate, but one made once a month on a thousand boxes would be. If changes are complex, where a minor mistake is hard to diagnose, and it has an impact on customer SLAs or has been a significant source of network outages, the problem would be important enough to target for automation. The details of the formula may vary by provider, but the basic idea is that went the cost of getting it wrong exceeds the cost of doing it right, the right way should win. Automation can provide concrete benefits to network stability, customer satisfaction, and employee productivity. ------- So to my mind, SNMP does not hit any of these thresholds. PWs or BGPVPNs hit them all, so I think those are the problem domains that will let YANG models shine. If we could become the standard configuration mechanism for "hot" technologies like this, then we'll be livin' the dream. >If you attend NANOG, a tremendous amount of discussion is about >routing protocols like BGP, so that would also be a reasonable >priority. Are the leading vendors of routing stacks active in netmod? BGP doesn't have the change rate that would make automation give a reasonable yield. On the other hand, BGP is well understood and widely deployed, so perhaps as a "technology demonstration" it would make sense. Thanks, Phil From biermana@Brocade.com Thu Oct 21 11:29:45 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130D83A6A47 for ; Thu, 21 Oct 2010 11:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuHi8GONQreL for ; Thu, 21 Oct 2010 11:29:43 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id E51AE3A67C2 for ; Thu, 21 Oct 2010 11:29:43 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9LIVEeC015010; Thu, 21 Oct 2010 11:31:19 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s2sd6r19w-46 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Oct 2010 11:31:19 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Oct 2010 11:35:31 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 21 Oct 2010 11:31:11 -0700 From: Andy Bierman To: Phil Shafer , David Harrington Date: Thu, 21 Oct 2010 11:31:10 -0700 Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: ActxSyuzCkDJhWM6Rr6nJVXwaybuVQAAL6cw Message-ID: References: <201010211746.o9LHkamK042826@idle.juniper.net> In-Reply-To: <201010211746.o9LHkamK042826@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-21_09:2010-10-21, 2010-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010210145 X-Proofpoint-SSN: Sensitivity2 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:29:45 -0000 Hi Phil, Your Conditions for Automation is excellent. Can we get it on the NETCONF Wiki? It would really help to remind people of the use cases. Only the 'interfaces' work item meets your criteria. The 'commonality' factor is independent of the automation factors. Every protocol/service that has per-interface config is going to need to identify the interface. We cannot have more than 1 way to do this in the standard. We cannot leave it as a vendor detail. IMO, NACM is a critical component related to your 'is it important' point. Is it important to prevent malicious and/or unintended alteration of the configuration? Depends on the network, but generally this is important. In order for NACM to be deployed, the standardization of 'users' must also be done. I think Juergen is right about putting that in its own document, instead of NACM. This is important config, even if NACM is not supported. IMO, the 2 most valuable config modules would be bare-interfaces and user login authentication. Andy -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net]=20 Sent: Thursday, October 21, 2010 10:47 AM To: David Harrington Cc: 'Juergen Schoenwaelder'; 'Andy Bierman'; Andy Bierman; netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netm= od-snmp-cfg-00=20 "David Harrington" writes: >So the operators explained that one of the major problems with the MIB >approach is that the MIB data models did not allow configuring >**everything** on a target device, whereas CLI gave them access to >everything. With NETCONF/YANG, the argument is a little different. So let's say I want to make an application to configure PWE tunnels thru my network, and the standard defines 80% of what I need. If I can use NETCONF to access non-YANG-modeled data or proprietary YANG-modeled data to get the other 20%, then I'm happy. If I need to resort to screen scraping to get to data, then I might as well use the screen scraping method to get the whole kit-n-kaboodle. >If YANG modeling is going to be more useful than MIB modeling, it has >a long way to go to make everything on the box configurable using >Netconf. Certainly some things might be more important than others, >but I am with Juergen that individual YANG models are better than >none.=20 With NETCONF/YANG we have built a smaller hill, since the only requirement is that the device expose all configuration via NETCONF, which is required to have a functional NETCONF implementation. Once that burden has been met, it works as an "escape hatch" for data that is not YANG'd yet. SNMP had no such mechanism, so the fall back was screen scraping. >If you want to prioritize IETF efforts at standardizing YANG models, >then it would be wise to focus on widely-deployed IETF standard >technologies that operators find fairly complex to configure. SNMP is >one of the IETF standards that fit that description. I've written some words recently about when automation is a win. Here's a snippet: ------- * Conditions for Automation We've looked at a number of on-box features that make automation more robust and reliable. Let's look briefly at when automation can pay maximum dividends. When is automation and flow-through provisioning an appropriate solution? There are four qualities that a problem must have to be a good candidate: - complexity -- Is is a hard problem? - frequency -- Do changes happen often? - importance -- Will failures matter? - scale -- Is the rate of change relatively high? If the answer to these four is "yes", then the problem is a good candidate and the cost of using automation will be paid for by the increase in the robustness, ease of use, certainty, assurance, and scaling that automation can provide. A change that's needed once a year on ten boxes is likely not a candidate, but one made once a month on a thousand boxes would be. If changes are complex, where a minor mistake is hard to diagnose, and it has an impact on customer SLAs or has been a significant source of network outages, the problem would be important enough to target for automation. The details of the formula may vary by provider, but the basic idea is that went the cost of getting it wrong exceeds the cost of doing it right, the right way should win. Automation can provide concrete benefits to network stability, customer satisfaction, and employee productivity. ------- So to my mind, SNMP does not hit any of these thresholds. PWs or BGPVPNs hit them all, so I think those are the problem domains that will let YANG models shine. If we could become the standard configuration mechanism for "hot" technologies like this, then we'll be livin' the dream. >If you attend NANOG, a tremendous amount of discussion is about >routing protocols like BGP, so that would also be a reasonable >priority. Are the leading vendors of routing stacks active in netmod?=20 BGP doesn't have the change rate that would make automation give a reasonable yield. On the other hand, BGP is well understood and widely deployed, so perhaps as a "technology demonstration" it would make sense. Thanks, Phil From lhotka@cesnet.cz Thu Oct 21 11:33:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2F23A689B for ; Thu, 21 Oct 2010 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxfCyD3qibEF for ; Thu, 21 Oct 2010 11:33:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 0CB073A6452 for ; Thu, 21 Oct 2010 11:33:29 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id EF2A82CDE058; Thu, 21 Oct 2010 20:35:03 +0200 (CEST) From: Ladislav Lhotka To: "Romascanu, Dan (Dan)" In-Reply-To: References: <1287683608.1606.111.camel@missotis> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Oct 2010 20:35:02 +0200 Message-ID: <1287686102.1606.112.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-dsdl-map-09 approved by the IESG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:33:30 -0000 On Čt, 2010-10-21 at 19:54 +0200, Romascanu, Dan (Dan) wrote: > Yes, please submit draft-10 and thanks for all the good work. Done. Thanks, Lada > > Regards, > > Dan > > > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz] > > Sent: Thursday, October 21, 2010 7:53 PM > > To: Romascanu, Dan (Dan) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] draft-ietf-netmod-dsdl-map-09 approved > > by the IESG > > > > Hi Dan, > > > > On Čt, 2010-10-21 at 19:44 +0200, Romascanu, Dan (Dan) wrote: > > > The IESG approved in the telechat today > > draft-ietf-netmod-dsdl-map-09 > > > as PS. Thanks to everybody who contributed and especially to Lada. > > > > Good news, thanks! > > > > > > > > Lada, are there any edits that are still to be made following the > > > discussions with the ADs, or is draft-09 ready to go? > > > > There are two edits based on the comments by Peter > > Saint-Andre. I hope the IANA templates are correct and need > > no other changes. > > > > So should I submit -10 with those two changes now? > > > > Lada > > > > > > > > > > > Dan > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Oct 21 11:43:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54EF3A67C2 for ; Thu, 21 Oct 2010 11:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFLHU8I6yH7A for ; Thu, 21 Oct 2010 11:43:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 62D643A6452 for ; Thu, 21 Oct 2010 11:43:13 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE9A8C0004; Thu, 21 Oct 2010 20:44:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PRrC8V63iL4O; Thu, 21 Oct 2010 20:44:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9059C0002; Thu, 21 Oct 2010 20:44:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DBBFB156C3AD; Thu, 21 Oct 2010 20:44:08 +0200 (CEST) Date: Thu, 21 Oct 2010 20:44:08 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20101021184408.GC27772@elstar.local> Mail-Followup-To: Phil Shafer , David Harrington , 'Andy Bierman' , 'Andy Bierman' , netmod@ietf.org References: <201010211746.o9LHkamK042826@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010211746.o9LHkamK042826@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Andy Bierman' , netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:43:16 -0000 On Thu, Oct 21, 2010 at 01:46:36PM -0400, Phil Shafer wrote: > BGP doesn't have the change rate that would make automation give a > reasonable yield. On the other hand, BGP is well understood and > widely deployed, so perhaps as a "technology demonstration" it > would make sense. Martin and I never claimed SNMP config is important. Initially, we started looking at it because this is the only technology I am aware of where the IETF has a standard configuration model. This made this excercise easier for us than dealing with say BGP VPNs. (And we also happen to understand SNMP config better than BGP VPN config. ;-) I believe we need technology demonstrations. The more the better. In my view, we should _encourage_ people to post YANG technology demonstrations as individual IDs for whatever configuration model they are familiar with. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Thu Oct 21 11:45:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 96BB83A689B; Thu, 21 Oct 2010 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101021184501.96BB83A689B@core3.amsl.com> Date: Thu, 21 Oct 2010 11:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka Filename : draft-ietf-netmod-dsdl-map-10.txt Pages : 112 Date : 2010-10-21 This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF message etc. Procedures for schema-based validation of such documents are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-dsdl-map-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-21113219.I-D@ietf.org> --NextPart-- From ietf@andybierman.com Thu Oct 21 13:33:47 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939AF3A67F6 for ; Thu, 21 Oct 2010 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWkdPeW1YuPK for ; Thu, 21 Oct 2010 13:33:46 -0700 (PDT) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by core3.amsl.com (Postfix) with SMTP id 6F9C23A690C for ; Thu, 21 Oct 2010 13:33:46 -0700 (PDT) Received: from [98.139.91.66] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 21 Oct 2010 20:35:20 -0000 Received: from [98.139.91.34] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 21 Oct 2010 20:35:19 -0000 Received: from [127.0.0.1] by omp1034.mail.sp2.yahoo.com with NNFMP; 21 Oct 2010 19:54:33 -0000 X-Yahoo-Newman-Id: 828456.12351.bm@omp1034.mail.sp2.yahoo.com Received: (qmail 33362 invoked from network); 21 Oct 2010 19:54:33 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 21 Oct 2010 12:54:33 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: pI5mL40VM1kFNMKsPUzm_KMGO7V7t9aokRHjZPUIJkpb0Pq UPcVOqN6MHU10jylcUPTNOA8CoONH.07ff7NMkW8JmDu5bsbHZBEcAzOsHcr pMeaOiLd3LIy8yAE5VgCpU0h8YcJ09.Sb_tuRRqBPqvRPBY6TBbN_98tJqUE EwmFQps7cwhpRry34hTlXXvEmFKWJ.85B1Mpw5Vek5_jlpDvnTfK1Pl1Y0Dw Y X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC09A7C.6020506@andybierman.com> Date: Thu, 21 Oct 2010 12:54:36 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Wes Hardaker References: <20101020.153501.236075803.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 20:33:47 -0000 On 10/21/2010 09:29 AM, Wes Hardaker wrote: > ... > > [on a side note: I sure get a lot of questions from people about > configuring SNMP using SNMP; if no one is doing it, why am I getting > questions?] > Ummm, because SNMP is so hard to use for configuration? Because these particular MIB modules are complicated and non-intuitive? I can't commit to working on the details on this module, but I don't mind if it is published. I agree with Juergen that having specific modules published in RFCs is forward progress. This also shows how much more powerful YANG is than SMIv2, which is important. My concern is that we pull in lots of SNMP baggage by requiring that new YANG modules be compatible with all existing modules, which will include this one. Establishing precedent is extremely important, and requires attention and resources. Wasting it on unimportant content amounts to mis-management. It turns out that what modules to standardize and in what order is rather important. IMO, interface naming has to be first. Almost every YANG module, including 1 in progress in the IPFIX WG, needs to refer to interface instances. Andy From j.schoenwaelder@jacobs-university.de Thu Oct 21 13:43:06 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC233A6A7A for ; Thu, 21 Oct 2010 13:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbekjHB4ZorY for ; Thu, 21 Oct 2010 13:43:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7415C3A6A83 for ; Thu, 21 Oct 2010 13:43:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 298B1C0004; Thu, 21 Oct 2010 22:44:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cGxG8gdLpOvp; Thu, 21 Oct 2010 22:44:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94242C0002; Thu, 21 Oct 2010 22:44:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B838B156CAB1; Thu, 21 Oct 2010 22:43:59 +0200 (CEST) Date: Thu, 21 Oct 2010 22:43:59 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101021204359.GD28148@elstar.local> Mail-Followup-To: Andy Bierman , Wes Hardaker , netmod@ietf.org References: <20101020.153501.236075803.mbj@tail-f.com> <4CC09A7C.6020506@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC09A7C.6020506@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 20:43:06 -0000 On Thu, Oct 21, 2010 at 12:54:36PM -0700, Andy Bierman wrote: > My concern is that we pull in lots of SNMP baggage by requiring > that new YANG modules be compatible with all existing modules, > which will include this one. My brain got a segfault on this one. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From spakes@snmp.com Thu Oct 21 14:41:34 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D5A3A6A20 for ; Thu, 21 Oct 2010 14:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjApoX4LKVJ9 for ; Thu, 21 Oct 2010 14:41:29 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7733A3A6848 for ; Thu, 21 Oct 2010 14:41:28 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA26136; Thu, 21 Oct 2010 17:42:47 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA09581; Thu, 21 Oct 2010 17:42:42 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 21 Oct 2010 17:42:40 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4CC09A7C.6020506@andybierman.com> Message-ID: References: <20101020.153501.236075803.mbj@tail-f.com> <4CC09A7C.6020506@andybierman.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: netmod@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 21:41:34 -0000 On Thu, 21 Oct 2010, Andy Bierman wrote: > I can't commit to working on the details on this module, > but I don't mind if it is published. I agree with Juergen > that having specific modules published in RFCs is forward progress. > This also shows how much more powerful YANG is than SMIv2, which is > important. In time, the capabilities of YANG that are beyond SMIv2 to model application data will be commonly exercised in new documents that are created. However, IMHO, the wise course of action for the short term would be to take small steps. Instead of redesigning "MIB-II" objects in the first go around, I would suggest writing YANG documents that mirror the existing RFCs as closely as possible. Think about vendors who would want to add a NETCONF server in their product, and then consider how many might delay that decision because they would have to overhaul their code that interacts with the stack and kernel to exchange data. > It turns out that what modules to standardize and in what order > is rather important. IMO, interface naming has to be first. > Almost every YANG module, including 1 in progress in the IPFIX WG, > needs to refer to interface instances. I agree with Andy here. At the very least, the working group should produce a document that is the YANG equivalent to RFC 2863. IMHO, it should exactly mirror the existing objects, at least the ones that are not deprecated. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From ietf@andybierman.com Thu Oct 21 14:50:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1E53A67FB for ; Thu, 21 Oct 2010 14:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dZ+wReeARjZ for ; Thu, 21 Oct 2010 14:50:30 -0700 (PDT) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by core3.amsl.com (Postfix) with SMTP id 87D843A67EF for ; Thu, 21 Oct 2010 14:50:30 -0700 (PDT) Received: from [98.139.91.64] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 21 Oct 2010 21:52:04 -0000 Received: from [98.139.91.20] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 21 Oct 2010 21:51:56 -0000 Received: from [127.0.0.1] by omp1020.mail.sp2.yahoo.com with NNFMP; 21 Oct 2010 21:31:47 -0000 X-Yahoo-Newman-Id: 700961.54963.bm@omp1020.mail.sp2.yahoo.com Received: (qmail 41247 invoked from network); 21 Oct 2010 21:31:47 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 21 Oct 2010 14:31:47 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ndr38l8VM1mG2paLBpD_5uiOJSN.nb5Oqjnco7ia3FyjN6A 5gsrrIqAE18tb30qSsPJ9iqmsJ19DUdRGS2hvGJu9hmIddDH3r4LMuyj30v_ qGZ8F_R3e85qpRGy9f2DkK_Y871MeysvCLya.sRnSDqegAFym09goKEj.A8P Fio9DOyFRNa4iozvp8JRb1P4ZFiNONOc4CNMxybeXRmPd6pnquuNVIvqS5FG C4pYKo0QsZE9UfbKhxyxMufNMttVFipHwCY6e X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC0B142.4060402@andybierman.com> Date: Thu, 21 Oct 2010 14:31:46 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 MIME-Version: 1.0 To: Wes Hardaker , netmod@ietf.org References: <20101020.153501.236075803.mbj@tail-f.com> <4CC09A7C.6020506@andybierman.com> <20101021204359.GD28148@elstar.local> In-Reply-To: <20101021204359.GD28148@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 21:50:35 -0000 On 10/21/2010 01:43 PM, Juergen Schoenwaelder wrote: > On Thu, Oct 21, 2010 at 12:54:36PM -0700, Andy Bierman wrote: > >> My concern is that we pull in lots of SNMP baggage by requiring >> that new YANG modules be compatible with all existing modules, >> which will include this one. > > My brain got a segfault on this one. Try parsing this... I don't want to waste any effort working on SNMP in the NETMOD WG right now. It is not a high priority, and working on it concurrently with framework components such as interfaces may be counter-productive. > > /js > Andy From mbj@tail-f.com Fri Oct 22 02:09:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E8F3A68AB for ; Fri, 22 Oct 2010 02:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly+DUJVhENcU for ; Fri, 22 Oct 2010 02:09:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E76C63A68C4 for ; Fri, 22 Oct 2010 02:09:28 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id ACA4E616012; Fri, 22 Oct 2010 11:11:04 +0200 (CEST) Date: Fri, 22 Oct 2010 11:11:04 +0200 (CEST) Message-Id: <20101022.111104.235838872.mbj@tail-f.com> To: netmod@ietf.org, spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <4CC09A7C.6020506@andybierman.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 09:09:30 -0000 Hi, David Spakes wrote: > At the very least, the working group should > produce a document that is the YANG equivalent to RFC 2863. IMHO, > it should exactly mirror the existing objects, at least the ones > that are not deprecated. I disagree. If all we do is put YANG syntax around existing MIB objects, we haven't achieved anything. We should concentrate on interface configuration. It is not important to duplicate all interface counters etc. One thing that *is* important though is how a YANG interface configuration model relates to the MIB. (For example, how the interface name maps to ifIndex.) /martin From biermana@Brocade.com Fri Oct 22 08:53:47 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C463A68A8 for ; Fri, 22 Oct 2010 08:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1al5cVO+9A3e for ; Fri, 22 Oct 2010 08:53:46 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 98D583A6897 for ; Fri, 22 Oct 2010 08:53:46 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id o9MFljp7024117; Fri, 22 Oct 2010 08:55:20 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id s3cp300xk-22 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Oct 2010 08:55:20 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Oct 2010 08:59:20 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Fri, 22 Oct 2010 08:55:01 -0700 From: Andy Bierman To: Martin Bjorklund , "netmod@ietf.org" , "spakes@snmp.com" Date: Fri, 22 Oct 2010 08:55:00 -0700 Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: ActxyRIjfFjW6EPOQCii7zPfyMMrAQANDfoQ Message-ID: References: <4CC09A7C.6020506@andybierman.com> <20101022.111104.235838872.mbj@tail-f.com> In-Reply-To: <20101022.111104.235838872.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-22_09:2010-10-22, 2010-10-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1004200000 definitions=main-1010220103 X-Proofpoint-SSN: Sensitivity2 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 15:53:47 -0000 Hi, I agree with Martin. There should be a new interfaces table that contains a mapping to ifIndex so monitoring MIBs like RMON-MIB can be used with SNMP, even though the config may be done through NETCONF. RMON is an example that supports compl= ete self-configuration through SNMP, but vendors has decided to configure it th= rough CLI anyway. To understand the framework, we have to understand (at least) how an indivi= dual feature would be realized within that framework. Some requirements (IMO): 1) Ability to support easy to use YANG module for any service or feature. Global and per-interface inter-related components are the norm. This must be clear in the data model. 2) Ability to continue retrieving interface-related operational data with= SNMP 3) Ability to also retrieve operational data with NETCONF - mapping algorithm automatically translates any SMIv2 read-only OBJECT-TYPE macro into functionally equivalent YANG module, such tha= t predictable top-level YANG data nodes, suitable for retrieval, are defined. 4) Ability to let vendors continue using their own interface identificati= on strings - Provide optional YANG extension to let vendors describe identifier s= tring components 5) Ability to identify/configure parent and child interface relationships= ,=20 if there is some hierarchy within the interfaces.=20 - other interface relationships such as hot-standby, load-balancing, t= runking=20 should also be supported 6) Ability to pre-provision interfaces which are not currently present. 7) Ability to enable or disable an interface 8) Ability to move child nodes from one interface to another (e.g., move a service, replicate a service, line-card changes slot) Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Martin Bjorklund Sent: Friday, October 22, 2010 2:11 AM To: netmod@ietf.org; spakes@snmp.com Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netm= od-snmp-cfg-00 Hi, David Spakes wrote: > At the very least, the working group should > produce a document that is the YANG equivalent to RFC 2863. IMHO, > it should exactly mirror the existing objects, at least the ones > that are not deprecated. I disagree. If all we do is put YANG syntax around existing MIB objects, we haven't achieved anything. We should concentrate on interface configuration. It is not important to duplicate all interface counters etc. One thing that *is* important though is how a YANG interface configuration model relates to the MIB. (For example,=20 how the interface name maps to ifIndex.) /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From saperia@jdscons.com Fri Oct 22 10:34:27 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DDD3A68E7 for ; Fri, 22 Oct 2010 10:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YwutPm1TWaN for ; Fri, 22 Oct 2010 10:34:26 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 0E7E23A691B for ; Fri, 22 Oct 2010 10:34:26 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o9MHa1xB014601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Oct 2010 12:36:01 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: Date: Fri, 22 Oct 2010 13:36:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0CCDC32D-54A8-4443-9E93-6A8229E15C0A@jdscons.com> References: <4CC09A7C.6020506@andybierman.com> <20101022.111104.235838872.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1081) Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 17:34:27 -0000 The point Martin made about relating the SNMP Model with the YANG based = one is important. The issue is, at least in the SNMP universe, = interface naming is not static/stable and not always predictable. This = has always been an issue for management applications even when not = attempting to map to an alternate name space such as YANG so mapping = counters for an interface with it's YANG based configuration information = could be problematic. Beyond this, most management systems will not = keep the core data in either model (SNMP or YANG) they will have an = internal data base that is based on their own internal model. It is not = clear to me based on applications I know that this extra mapping is all = that helpful since it will have to be redone in the management software = application. /jon On Oct 22, 2010, at 11:55 AM, Andy Bierman wrote: > Hi, >=20 > I agree with Martin. > There should be a new interfaces table that contains a mapping to = ifIndex > so monitoring MIBs like RMON-MIB can be used with SNMP, even though = the > config may be done through NETCONF. RMON is an example that supports = complete > self-configuration through SNMP, but vendors has decided to configure = it through > CLI anyway. >=20 > To understand the framework, we have to understand (at least) how an = individual > feature would be realized within that framework. >=20 > Some requirements (IMO): > 1) Ability to support easy to use YANG module for any service or = feature. > Global and per-interface inter-related components are the norm. > This must be clear in the data model. > 2) Ability to continue retrieving interface-related operational data = with SNMP > 3) Ability to also retrieve operational data with NETCONF > - mapping algorithm automatically translates any SMIv2 read-only > OBJECT-TYPE macro into functionally equivalent YANG module, such = that > predictable top-level YANG data nodes, suitable for = retrieval, > are defined. > 4) Ability to let vendors continue using their own interface = identification strings > - Provide optional YANG extension to let vendors describe = identifier string components > 5) Ability to identify/configure parent and child interface = relationships,=20 > if there is some hierarchy within the interfaces.=20 > - other interface relationships such as hot-standby, = load-balancing, trunking=20 > should also be supported > 6) Ability to pre-provision interfaces which are not currently = present. > 7) Ability to enable or disable an interface > 8) Ability to move child nodes from one interface to another > (e.g., move a service, replicate a service, line-card changes = slot) >=20 >=20 > Andy >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf Of Martin Bjorklund > Sent: Friday, October 22, 2010 2:11 AM > To: netmod@ietf.org; spakes@snmp.com > Subject: Re: [netmod] Fw: New Version Notification for = draft-bjorklund-netmod-snmp-cfg-00 >=20 > Hi, >=20 > David Spakes wrote: >> At the very least, the working group should >> produce a document that is the YANG equivalent to RFC 2863. IMHO, >> it should exactly mirror the existing objects, at least the ones >> that are not deprecated. >=20 > I disagree. If all we do is put YANG syntax around existing MIB > objects, we haven't achieved anything. We should concentrate on > interface configuration. It is not important to duplicate all > interface counters etc. One thing that *is* important though is how a > YANG interface configuration model relates to the MIB. (For example,=20= > how the interface name maps to ifIndex.) >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Sun Oct 24 07:00:43 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9D63A689E for ; Sun, 24 Oct 2010 07:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXsgiHpocLol for ; Sun, 24 Oct 2010 07:00:42 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 8578B3A6857 for ; Sun, 24 Oct 2010 07:00:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,231,1286164800"; d="scan'208";a="40991043" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 24 Oct 2010 10:02:24 -0400 X-IronPort-AV: E=Sophos;i="4.58,231,1286164800"; d="scan'208";a="530584167" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Oct 2010 10:02:23 -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: Sun, 24 Oct 2010 16:02:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: ActxyRIjfFjW6EPOQCii7zPfyMMrAQANDfoQAGGmEBA= References: <4CC09A7C.6020506@andybierman.com><20101022.111104.235838872.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Martin Bjorklund" , , Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 14:00:43 -0000 I agree with Andy and Martin on the approach. This looks like a good set of requirements to start from.=20 Dan (speaking as a contributor)=20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, October 22, 2010 5:55 PM > To: Martin Bjorklund; netmod@ietf.org; spakes@snmp.com > Subject: Re: [netmod] Fw: New Version Notification for=20 > draft-bjorklund-netmod-snmp-cfg-00 >=20 > Hi, >=20 > I agree with Martin. > There should be a new interfaces table that contains a=20 > mapping to ifIndex so monitoring MIBs like RMON-MIB can be=20 > used with SNMP, even though the config may be done through=20 > NETCONF. RMON is an example that supports complete=20 > self-configuration through SNMP, but vendors has decided to=20 > configure it through CLI anyway. >=20 > To understand the framework, we have to understand (at least)=20 > how an individual feature would be realized within that framework. >=20 > Some requirements (IMO): > 1) Ability to support easy to use YANG module for any=20 > service or feature. > Global and per-interface inter-related components are the norm. > This must be clear in the data model. > 2) Ability to continue retrieving interface-related=20 > operational data with SNMP > 3) Ability to also retrieve operational data with NETCONF > - mapping algorithm automatically translates any SMIv2 read-only > OBJECT-TYPE macro into functionally equivalent YANG=20 > module, such that > predictable top-level YANG data nodes, suitable for=20 > retrieval, > are defined. > 4) Ability to let vendors continue using their own=20 > interface identification strings > - Provide optional YANG extension to let vendors=20 > describe identifier string components > 5) Ability to identify/configure parent and child interface=20 > relationships,=20 > if there is some hierarchy within the interfaces.=20 > - other interface relationships such as hot-standby,=20 > load-balancing, trunking=20 > should also be supported > 6) Ability to pre-provision interfaces which are not=20 > currently present. > 7) Ability to enable or disable an interface > 8) Ability to move child nodes from one interface to another > (e.g., move a service, replicate a service, line-card=20 > changes slot) >=20 >=20 > Andy >=20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Friday, October 22, 2010 2:11 AM > To: netmod@ietf.org; spakes@snmp.com > Subject: Re: [netmod] Fw: New Version Notification for=20 > draft-bjorklund-netmod-snmp-cfg-00 >=20 > Hi, >=20 > David Spakes wrote: > > At the very least, the working group should produce a=20 > document that is=20 > > the YANG equivalent to RFC 2863. IMHO, it should exactly=20 > mirror the=20 > > existing objects, at least the ones that are not deprecated. >=20 > I disagree. If all we do is put YANG syntax around existing=20 > MIB objects, we haven't achieved anything. We should=20 > concentrate on interface configuration. It is not important=20 > to duplicate all interface counters etc. One thing that *is*=20 > important though is how a YANG interface configuration model=20 > relates to the MIB. (For example, how the interface name=20 > maps to ifIndex.) >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Mon Oct 25 07:45:13 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F35C3A6A41; Mon, 25 Oct 2010 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QBQ8Bup4O1T; Mon, 25 Oct 2010 07:45:12 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 74DD23A6A45; Mon, 25 Oct 2010 07:45:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,236,1286164800"; d="scan'208";a="214015790" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Oct 2010 10:46:55 -0400 X-IronPort-AV: E=Sophos;i="4.58,236,1286164800"; d="scan'208";a="531205947" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Oct 2010 10:46:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2010 16:46:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: YANG-Doctors up and runing Thread-Index: Act0U2q2SazZNDb9QDCsdwCCe/vr5Q== From: "Romascanu, Dan (Dan)" To: , Subject: [netmod] YANG-Doctors up and runing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 14:45:13 -0000 The YANG-Doctors directorate is formed and the mail list is up and runing.=20 The current list of members is composed of:=20 bertietf@bwijnen.net biermana@Brocade.com david.kessens@nsn.com dromasca@avaya.com j.schoenwaelder@jacobs-university.de janl@tail-f.com lhotka@cesnet.cz mark.scott@ericsson.com mbj@tail-f.com mehmet.ersue@nsn.com wjhns1@hardakers.net If your name is not on the list and you would like to be a YANG Doctor please contact me.=20 Dan =20 From wwwrun@core3.amsl.com Mon Oct 25 09:33:20 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0947B3A6ACA; Mon, 25 Oct 2010 09:33:19 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101025163320.0947B3A6ACA@core3.amsl.com> Date: Mon, 25 Oct 2010 09:33:19 -0700 (PDT) Cc: Internet Architecture Board , netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content' to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:33:20 -0000 The IESG has approved the following document: - 'Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content ' as a Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-10.txt Technical Summary This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF message etc. Procedures for schema-based validation of such documents are also discussed. Working Group Summary Consensus was reached among all interested parties before requesting the publication of this document. Document Quality There is a publicly-available implementation of the mapping rules available. The development of this tool has been done in parallel with writing the document, so the document reflects the running code. Personnel David Partain is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. From dromasca@avaya.com Tue Oct 26 08:49:22 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3D63A681B for ; Tue, 26 Oct 2010 08:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTLnFw+ZNtAP for ; Tue, 26 Oct 2010 08:49:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 698263A67F2 for ; Tue, 26 Oct 2010 08:49:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,241,1286164800"; d="scan'208";a="214360142" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Oct 2010 11:51:07 -0400 X-IronPort-AV: E=Sophos;i="4.58,241,1286164800"; d="scan'208";a="528782908" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Oct 2010 11:51:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2010 17:50:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New WG co-chair for NETMOD Thread-Index: Act1JY2JdiFuqqJxQHyhaCnUuhEitQ== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] New WG co-chair for NETMOD X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 15:49:22 -0000 As you know David Partain is stepping down from the position of co-chair of the NETMOD. Thanks again to David for the tremendous contribution to the inception and progress of YANG.=20 Juergen Schoenwaelder accepted the position of co-chair of the NETMOD WG, together with David Kessens who is continuing. Thanks to Juergen for taking over and good luck to the WG and to the chairs in the continuation of the activity.=20 Regards, Dan From wwwrun@core3.amsl.com Tue Oct 26 11:42:55 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E21B23A6827; Tue, 26 Oct 2010 11:42:54 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101026184254.E21B23A6827@core3.amsl.com> Date: Tue, 26 Oct 2010 11:42:54 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] WG Action: RECHARTER: NETCONF Data Modeling Language (netmod) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 18:42:55 -0000 The NETCONF Data Modeling Language (netmod) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. NETCONF Data Modeling Language (netmod) --------------------------------------------------- Current Status: Active Working Group Chairs: David Kessens Juergen Schoenwaelder Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Description of Working Group: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will initially work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts and review at WGLC by the Routing Area working group. 4. SMIv2 translation to YANG for read-only operational data and notifications. Guidance will be provided on how to reference existing data structures in SMIv2 from YANG. The NETMOD Working Group will not work on another version of YANG. All new charter items must be fully interoperable with implementations of RFC 4741bis and/or RFC 6020. It will also not serve as a review team for YANG modules developed by other working groups. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Oct 2010 Submission of individual draft(s) of System data model draft Oct 2010 Submission of individual draft(s) of Interface data model Oct 2010 Submission of individual draft(s) of Routing data model Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG Dec 2010 Submit first working group draft of System data model draft Dec 2010 Submit first working group draft of Interface data model Dec 2010 Submit first working group draft of Routing data model Dec 2010 Submit first working group draft of SMIv2 translation to YANG Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2011 Submit System data model to the IESG (proposed standard) Aug 2011 Submit Interface data model to the IESG (proposed standard) Aug 2011 Submit Routing data model to the IESG (proposed standard) From B.Hedstrom@CableLabs.com Tue Oct 26 23:59:14 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE333A677E for ; Tue, 26 Oct 2010 23:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.412 X-Spam-Level: ** X-Spam-Status: No, score=2.412 tagged_above=-999 required=5 tests=[AWL=2.874, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU0eBS79WqPZ for ; Tue, 26 Oct 2010 23:59:13 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 85D9A3A68CE for ; Tue, 26 Oct 2010 23:59:13 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o9R712RJ006252 for ; Wed, 27 Oct 2010 01:01:02 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 27 Oct 2010 01:01:02 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 27 Oct 2010 01:01:02 -0600 From: Brian Hedstrom To: "netmod@ietf.org" Date: Wed, 27 Oct 2010 01:00:55 -0600 Thread-Topic: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 Thread-Index: Act1pLM3I1n5bynXQIGbbvtBKqmg5Q== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20315903@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7D20315903srvxchg_" MIME-Version: 1.0 X-Approved: ondar X-Mailman-Approved-At: Wed, 27 Oct 2010 00:01:14 -0700 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 06:59:14 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D20315903srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I would like to add my comments to the value in this IETF draft and on stan= dardizing YANG modules for configuring SNMP access parameters within a netw= ork element. If NETCONF/YANG is used for configuration management of a network element, = but SNMP is used for Fault Management and Performance Monitoring, an SNMP A= gent still must be configured when a network element is deployed into the f= ield. Therefore, there needs to be a way to configure the SNMP Agent param= eters, using NETCONF/YANG, so the OSS tools can perform FM and PM managemen= t functions using SNMP on the network element once that NE is brought into = service and operational. Since the SNMP access objects are standardized by= IETF within MIBs, it only makes sense that IETF standardize these as YANG = modules as well, so that the industry has one set of YANG modules, instead = of every vendor developing their own proprietary YANG module to provision t= heir SNMP agent for operation. Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 AIM: brzahedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com --_000_76AC5FEF83F1E64491446437EA81A61F7D20315903srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I would like to add my comments to the value in this I= ETF draft and on standardizing YANG modules for configuring SNMP access paramet= ers within a network element.

 

If NETCONF/YANG is used for configuration management o= f a network element, but SNMP is used for Fault Management and Performance Monitoring, an SNMP Agent still must be configured when a network element i= s deployed into the field.  Therefore, there needs to be a way to config= ure the SNMP Agent parameters, using NETCONF/YANG, so the OSS tools can perform= FM and PM management functions using SNMP on the network element once that NE = is brought into service and operational.  Since the SNMP access objects a= re standardized by IETF within MIBs, it only makes sense that IETF standardize these as YANG modules as well, so that the industry has one set of YANG mod= ules, instead of every vendor developing their own proprietary YANG module to provision their SNMP agent for operation.

 

Thanks,

 

Brian Hedstrom
Senior Architect, Business & Operational Support Systems
CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
AIM: brzahedstrom
Skype IM: brian.hedstrom
b.heds= trom@cablelabs.com

 

--_000_76AC5FEF83F1E64491446437EA81A61F7D20315903srvxchg_-- From david.kessens@nsn.com Wed Oct 27 19:49:02 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B1F3A67FE for ; Wed, 27 Oct 2010 19:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsODlRvKateB for ; Wed, 27 Oct 2010 19:49:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id B11E33A67AF for ; Wed, 27 Oct 2010 19:49:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9S2opuH011955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Oct 2010 04:50:52 +0200 Received: from localhost6.localdomain6 ([10.138.49.24]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9S2ooLx017811 for ; Thu, 28 Oct 2010 04:50:51 +0200 Received: from localhost6.localdomain6 (localhost.localdomain [127.0.0.1]) by localhost6.localdomain6 (8.14.4/8.14.3) with ESMTP id o9S2pFDT012113 for ; Wed, 27 Oct 2010 19:51:15 -0700 Received: (from david@localhost) by localhost6.localdomain6 (8.14.4/8.14.4/Submit) id o9S2pFsN012111 for netmod@ietf.org; Wed, 27 Oct 2010 19:51:15 -0700 X-Authentication-Warning: localhost6.localdomain6: david set sender to david.kessens@nsn.com using -f Date: Wed, 27 Oct 2010 19:51:15 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20101028025114.GE3162@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) Subject: [netmod] Call for agenda items X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 02:49:03 -0000 The netmod working group is scheduled to meet during next IETF: TUESDAY, November 9, 2010 1300-1500 Valley Ballroom A We would like to request any and all topics that you would like to bring up during our session. We would like to especially draw your attention to our new charter items. We will need to sign up volunteers who are willing to take up the editor role. We are very interested in presentations on "first takes" and "outlines" on how such documents could/should look like. At the same time, we believe that we should use our face-to-face time well to help us get a better understanding on how we should focus our new work items. We believe that some of the recent discussions on the mailing list have already started to touch such issues and we should definitely continue them. David & Juergen ---