From dromasca@avaya.com Thu Dec 1 02:31:05 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA8D21F8C45 for ; Thu, 1 Dec 2011 02:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.276 X-Spam-Level: X-Spam-Status: No, score=-103.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwbUkTRbsXcK for ; Thu, 1 Dec 2011 02:31:04 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 599ED21F8B05 for ; Thu, 1 Dec 2011 02:31:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAANRW107GmAcF/2dsb2JhbABEhQOVUo8UgQmBBYFyAQEBAQMSEQ0EQw4GAQgNBAQBAQMCBgYMCwECAgMBRAcBAQUEAQQTCAEZh22YM4QUiW6RcoEwhluBfzNjBJo6jDA X-IronPort-AV: E=Sophos;i="4.71,277,1320642000"; d="scan'208";a="279946561" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Dec 2011 05:31:02 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Dec 2011 05:28:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 1 Dec 2011 11:30:58 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: David Harrington's Yes on draft-ietf-netconf-system-notifications-06:(with COMMENT) Thread-Index: AcyvoSmVem8OwhVKTEu0AVRjQNODGwAcwjKQ From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: David Harrington's Yes on draft-ietf-netconf-system-notifications-06:(with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 10:31:05 -0000 UGxlYXNlIGFkZHJlc3MgdGhlIGlzc3VlIHJhaXNlZCBieSBEYXZpZCBpbiBoaXMgQ09NTUVOVC4g DQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaWVzZy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWVzZy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgSGFycmluZ3Rvbg0KU2VudDogV2VkbmVzZGF5 LCBOb3ZlbWJlciAzMCwgMjAxMSAxMDo0NyBQTQ0KVG86IFRoZSBJRVNHDQpDYzogZHJhZnQtaWV0 Zi1uZXRjb25mLXN5c3RlbS1ub3RpZmljYXRpb25zQHRvb2xzLmlldGYub3JnOyBuZXRjb25mLWNo YWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogRGF2aWQgSGFycmluZ3RvbidzIFllcyBvbiBk cmFmdC1pZXRmLW5ldGNvbmYtc3lzdGVtLW5vdGlmaWNhdGlvbnMtMDY6KHdpdGggQ09NTUVOVCkN Cg0KRGF2aWQgSGFycmluZ3RvbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCmRyYWZ0LWlldGYtbmV0Y29uZi1zeXN0ZW0tbm90aWZpY2F0aW9ucy0wNjogWWVz DQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3Qg YW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0 YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlpb25z IGNvdWxkIGJlIGltcHJvdmVkIGJ5IGRpc2N1c3Npbmcgd2hhdCB0aHJlYXQgaXMgcG9zZWQgYnkg dGhlIHNwZWNpZmljIGRhdGEgcG9pbnRzLiANCg0KRm9yIGV4YW1wbGUsIG5ldGNvbmYtY29uZmln LWNoYW5nZSAiaW5kaWNhdGVzIHRoYXQgdGhlIHN5c3RlbSBjb25maWd1cmFzdGlvbiBoYXMgY2hh bmdlZC4iIEkgZG9uJ3QgdW5kZXJzdGFuZCBqdXN0IHdoYXQgdnVsbmVyYWJpbGl0eSB0aGlzIGRl c2NyaWJlczsgaXMgdGhlIGNvbmNlcm4gYWJvdXQgZGlzY2xvc2luZyBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgc3lzdGVtPyBvciBhbGVydGluZyBhIGxpc3RlbmluZyBhdHRhY2tlciB0aGF0IHRoZSBz eXN0ZW0gbWlnaHQgbm93IGJlIG1vcmUgdnVsbmVyYWJsZT8gVGhlIHNlbnNpdGl2aXR5L3Z1bG5l cmFiaWxpdHkgaXMgbm90IGRlc2NyaWJlZC4gRGl0dG8gZm9yIG1hbnkgb2YgdGhlc2UgYnVsbGV0 cy4NCg0KDQo= From andy@netconfcentral.org Thu Dec 1 04:43:19 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A4821F8AE1 for ; Thu, 1 Dec 2011 04:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWy3z4yEEAIN for ; Thu, 1 Dec 2011 04:43:18 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7A39121F89BA for ; Thu, 1 Dec 2011 04:43:18 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pB1ChE1Y002083 for ; Thu, 1 Dec 2011 07:43:16 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:34372] helo=[192.168.0.126]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D1/E0-24418-26677DE4; Thu, 01 Dec 2011 07:43:14 -0500 Message-ID: <4ED77661.40007@netconfcentral.org> Date: Thu, 01 Dec 2011 04:43:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] FW: David Harrington's Yes on draft-ietf-netconf-system-notifications-06:(with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 12:43:19 -0000 On 12/01/2011 02:30 AM, Romascanu, Dan (Dan) wrote: > Please address the issue raised by David in his COMMENT. I can add text that says the administrator must be aware of the specific capabilities and features supported by a server. A change in system capabilities may alter the specific vulnerabilities related to particular data models. The capabilities themselves will not be enough information to determine any particular security threat. For example, if the acme implementation of version X of module foo is known (a-priori) to have a buffer overflow exploit that is fixed in version Y, then a capability change event that indicates module foo, version X has been loaded into the system would notify the administrator of new vulnerable device. The same event for version Y would indicate the vulnerability has been removed from the device. There could be direct relationships between a data model capability event and a security threat, such as loading a port-mirroring/packet capture module like RMON, which might be exploited for unauthorized eavesdropping somehow. Andy > Thanks and Regards, > > Dan > > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of David Harrington > Sent: Wednesday, November 30, 2011 10:47 PM > To: The IESG > Cc: draft-ietf-netconf-system-notifications@tools.ietf.org; netconf-chairs@tools.ietf.org > Subject: David Harrington's Yes on draft-ietf-netconf-system-notifications-06:(with COMMENT) > > David Harrington has entered the following ballot position for > draft-ietf-netconf-system-notifications-06: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The security consideratiions could be improved by discussing what threat is posed by the specific data points. > > For example, netconf-config-change "indicates that the system configurastion has changed." I don't understand just what vulnerability this describes; is the concern about disclosing information about the system? or alerting a listening attacker that the system might now be more vulnerable? The sensitivity/vulnerability is not described. Ditto for many of these bullets. > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From dromasca@avaya.com Thu Dec 1 08:08:16 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D4C21F93C2 for ; Thu, 1 Dec 2011 08:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.344 X-Spam-Level: X-Spam-Status: No, score=-103.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRblZzxk-Iwj for ; Thu, 1 Dec 2011 08:08:15 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7021F93BD for ; Thu, 1 Dec 2011 08:08:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAD+m107GmAcF/2dsb2JhbABEhQOVU48agQmBBYFyAQEBAQMSEQ0ERQwGAQgNBAQBAQMCBgYMCwECAgMBRAcBAQUEAQQTCAEZh22cDIlukXSBMIZbgX8zYwSaOoww X-IronPort-AV: E=Sophos;i="4.71,279,1320642000"; d="scan'208";a="317401814" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Dec 2011 11:08:02 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Dec 2011 11:05:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 1 Dec 2011 17:08:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: David Harrington's Discuss on draft-ietf-netconf-access-control-06:(with DISCUSS and COMMENT) Thread-Index: AcywQxLEHic2iVF7S+G7XV4huGocfwAADqbQ From: "Romascanu, Dan (Dan)" To: Cc: ext David B Harrington Subject: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-access-control-06:(with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 16:08:16 -0000 DQpQbGVhc2UgYWRkcmVzcyB0aGUgaXNzdWVzIHJhaXNlZCBieSBEYXZpZCBpbiBoaXMgRElTQ1VT Uy4gDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaWVzZy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWVzZy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgSGFycmluZ3Rvbg0KU2VudDogVGh1cnNk YXksIERlY2VtYmVyIDAxLCAyMDExIDY6MDYgUE0NClRvOiBUaGUgSUVTRw0KQ2M6IGRyYWZ0LWll dGYtbmV0Y29uZi1hY2Nlc3MtY29udHJvbEB0b29scy5pZXRmLm9yZzsgbmV0Y29uZi1jaGFpcnNA dG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IERhdmlkIEhhcnJpbmd0b24ncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtbmV0Y29uZi1hY2Nlc3MtY29udHJvbC0wNjood2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKQ0KDQpEYXZpZCBIYXJyaW5ndG9uIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1uZXRjb25mLWFjY2Vzcy1jb250cm9sLTA2OiBEaXNj dXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRh Y3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJIHBsYW4gdG8gYmFsbG90IFlFUyBvbmNl IGEgZmV3IGNvbmNlcm5zIGFyZSBhZGRyZXNzZWQuDQoNCjEpIGluIDMuNC4zLCBhIHNlcnZlciBt dXN0IG5vdCBpbmNsdWRlIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gSG93IGRvZXMgb25lIGRldGVy bWluZSB3aGF0IGlzIHNlbnNpdGl2ZT8gU2hvdWxkIHRoZSBzZXJ2ZXIgY2hlY2sgdGhlIHNlbnNp dGl2aXR5IG1hcmtlciBpbiB0aGUgbWliIG1vZHVsZT8gd2l0aG91dCBjbGVhciBkZWZpbml0aW9u IG9mIHNlbnNpdGl2ZSwgdGhlICJNVVNUIE5PVCIgZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2UsIHNp bmNlIHRoZSBpbXBsZW1lbnRhdGlvbiBjYW5ub3QgaW1wbGVtZW50IHN1Y2ggYSBydWxlIGluIGFu IGludGVyb3BlcmFibGUgbWFubmVyDQoNCjIpIGluIDMuNC41LCB0aGUgc2VjdXJpdHV5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24gc2hvdWxkIGRpc2N1c3MgdGhlIHBvdGVudGlhbCBmb3IgbWlzdXNl IG9mIGFkZGluZyBncm91cHMgZnJvbSB0aGUgdHJhbnNwb3J0LiBUaGlzIGVmZmVjdGl2ZWx5IG92 ZXJyaWRlcyB0aGUgY29uc3RyYWludHMgcHJlLWNvbmZpZ3VyZWQgYnkgYW4gYWRtaW4gaW4gdGhl IG5hY20uIFNob3VsZCB0aGVyZSBiZSBhbiBlbmFibGUvZGlzYWJsZSBvYmplY3QgdGhhdCBhbGxv d3MgYW4gYWRtaW4gdG8gc2F5ICJkbyBOT1QgY29uc2lkZXIgdGhlIGdyb3VwcyBzcGVjaWZpZWQg YnkgdHJhbnNwb3J0Ij8gKElTTVMgaGFkIGEgbG9uZyBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIg UkFESVVTIG9yIHRoZSBwcmUtY29uZmlndXJlZCBWQUNNIHJ1bGVzIHNob3VsZCBiZSBkb21pbmFu dC4pDQoNCjMpIHNlY3Rpb24gMy40LjYgc2F5cyBuYWNtIGNvbmZpZ3VyYXRpb24gZm9yIG5vdGlm aWNhdGlvbnMgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIElzIHRoZXJlIGEgZG9j dW1lbnQgdGhhdCBkb2VzIGFkZHJlc3MgdGhpcz8gDQoNCjQpIFNOTVB2MydzIFZBQ00gZGVzY3Jp YmVzIGhvdyB0byBhcHBseSBydWxlcyB0byBub3RpZmljYXRpb25zLiBJZiBuYWNtIGZvciBub3Rp ZmljYXRpb25zIGlzIGNvbnRlbnQtaWdub3JhbnQsIHRoZW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNob3VsZCBhZHZpc2UgYWRtaW5zIHRvIGJlIGF3YXJlIHRoYXQgYW55IHVzZXIgYXV0 aG9yaXplZCB0byByZWNlaXZlIG5vdGlmaWNhdGlvbnMgaGFzIGFjY2VzcyB0byBhbnkgZGF0YSB0 aGF0IG1pZ2h0IGJlIGluY2x1ZGVkIGluIHRoZSBub3RpZmljYXRpb24uIFRoaXMgY291bGQgY2F1 c2UgaW5hZHZlcnRlbnRseSBkaXNjbG9zZSB0byBhIHVzZXIgaW5mb3JtYXRpb24gdGhhdCBzaG91 bGQgYmUgc3ViamVjdCB0byBwcml2YWN5IHJ1bGVzIChhbmQgcG90ZW50aWFsbHkgcHJpdmFjeSBs YXdzKSwgb3Igb3RoZXIgc2Vuc2l0aXZlIGRhdGEgdGhhdCBzaG91bGQgbm90IGJlIHNoYXJhYmxl IGFjcm9zcyB1c2Vycy4gDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQoxKSBpbiBzZWN0aW9uIDMuNSwgdGhlIG9uZSBzZW50ZW5jZSByZWZlcnMg dG8gc2VjdGlvbiAzLjUuIEkgZG9uJ3QgdGhpbmsgdGhlIHNlbnRlbmNlIGFkZHMgYW55dGhpbmcs IGV2ZW4gaWYgeW91IG1lYW50IHRvIHBvaW50IHRvIHRoZSBZQU5HIG1vZHVsZSBpbiAzLjUuMi4N Cg0KDQo= From dromasca@avaya.com Sun Dec 4 01:10:30 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C925A21F8492 for ; Sun, 4 Dec 2011 01:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3By0USG+3s-6 for ; Sun, 4 Dec 2011 01:10:30 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 452B621F84A6 for ; Sun, 4 Dec 2011 01:10:30 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEc4207GmAcF/2dsb2JhbABEqjCBBYF0AQEDEh4KMQwUARUVBgwMB1AHAQQbGp4mhBSaaYgMgjJjBJpDjDI X-IronPort-AV: E=Sophos;i="4.71,293,1320642000"; d="scan'208";a="317801381" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Dec 2011 04:10:27 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Dec 2011 04:08:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Dec 2011 10:10:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: status of the notifications and access control documents Thread-Index: AcyyZIZI1BgrkqVvTjOKC2d/gZrGQQ== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] status of the notifications and access control documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 09:10:30 -0000 Hi, The IESG discussed in the telechat on 12/1 two netconf documents: draft-ietf-netconf-system-notifications-06 was approved with the status ' write-up needed '. This means that before I send the final approval request I would like the editors and the chairs to address the various comments made during the IETF Last Call, by the ADs as COMMENTs and by the expert teams reviews. Please suggest editing to solve these, if there are a few we can solve them with RFC Editor note, else with a revised version.=20 draft-ietf-netconf-access-control-06 has one pending DISCUSS from DBH. Please work to solve the issues raised by David, and the other comments. The status of the document is 'Revised ID Needed'.=20 Thanks and Regards, Dan From tomoyuki.iijima.fg@hitachi.com Thu Dec 8 00:10:39 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8921F8AF3 for ; Thu, 8 Dec 2011 00:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ9E1UjAdKNl for ; Thu, 8 Dec 2011 00:10:38 -0800 (PST) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 92FBA21F8AD8 for ; Thu, 8 Dec 2011 00:10:38 -0800 (PST) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id AEC1F33CC6 for ; Thu, 8 Dec 2011 17:10:34 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id pB88AYs1029493; Thu, 8 Dec 2011 17:10:34 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id pB88AXcP022920 for ; Thu, 8 Dec 2011 17:10:34 +0900 X-AuditID: b753bd60-a2688ba000000655-02-4ee070f95392 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id A41A277426A for ; Thu, 8 Dec 2011 17:10:33 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id pB88APK7876652; Thu, 8 Dec 2011 17:10:25 +0900 Message-ID: <4EE070EF.4090502@hitachi.com> Date: Thu, 08 Dec 2011 17:10:23 +0900 From: Tomoyuki Iijima User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: netconf@ietf.org References: <201111211559.pALFxthw007924@idle.juniper.net> <4ECD91EE.2070602@alaxala.net> <80A0822C5E9A4440A5117C2F4CD36A6403096118@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403096118@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:10:39 -0000 Hi, There seems to be some requests in the mailing list to keep NETCONF over SOAP/BEEP. As far as there are expressions to implement NETCONF 1.1 over SOAP from implementers, and if no one volunteers to write a draft, I can volunteer to propose a draft for NETCONF 1.1 over SOAP. I think the biggest issue of NETCONF 1.1 for underlying transport protocol is the introduction of NETCONF username. Now I'm implementing that mechanism for NETCONF 1.1 over WebSocket by using "cookie." I think same mechanism is used in the case of NETCONF 1.1 over SOAP. If this idea is okay, I can prepare a draft for discussion hopefully by the next meeting. Another idea is to incorporate this mechanism into SOAP header, but it will be more difficult. Kind regards, (2011/11/24 16:42), Ersue, Mehmet (NSN - DE/Munich) wrote: >> 3 - There are multiple people in the WG who want to work >> on such a revision. >> 4 - The existing implementations (if any) are also willing >> to implement such a revision > > This is fine. However, still the questions 3 and 4 need to be > answered to update RFC 4743 fitting the NETCONF RFC 6241. > > Cheers, > Mehmet > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext >> Yoshifumi Atarashi >> Sent: Thursday, November 24, 2011 1:38 AM >> To: netconf@ietf.org >> Subject: Re: [Netconf] Obsoleting Netconf over > SOAP(RFC4743)/BEEP(RFC4744) >> >> Hello, >> >> Alaxala have an implementation of NETCONF over SOAP. >> It's supported on our products. >> And I know HITACHI, NEC, Allied products use NETCONF over SOAP. >> >> Yoshifumi Atarashi >> >> >> (11/11/22 0:59), Phil Shafer wrote: >>> "Bert Wijnen (IETF)" writes: >>>> 1 - There are multiple implementations >>>> 2 - There is real production deployment >>>> 3 - There are multiple people in the WG who want to work >>>> on such a revision. >>>> 4 - The existing implementations (if any) are also willing >>>> to implement such a revision >>> We have an implementation of NETCONF over BEEP in JUNOS that is >>> used in real deployments. I'm mostly on hiatus from IETF work due >>> to "day job" commitments and travel restrictions, so that's two out >>> of four for me. >>> >>> Thanks, >>> Phil >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > -- Tomoyuki Iijima From internet-drafts@ietf.org Fri Dec 9 12:20:56 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FBB21F8A7A; Fri, 9 Dec 2011 12:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYTTv87agBki; Fri, 9 Dec 2011 12:20:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA12721F8922; Fri, 9 Dec 2011 12:20:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111209202055.8008.75657.idtracker@ietfa.amsl.com> Date: Fri, 09 Dec 2011 12:20:55 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-system-notifications-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:20:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group o= f the IETF. Title : Network Configuration Protocol (NETCONF) Base Notificati= ons Author(s) : Andy Bierman Filename : draft-ietf-netconf-system-notifications-07.txt Pages : 17 Date : 2011-12-09 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-= 07.txt From iesg-secretary@ietf.org Wed Dec 14 08:23:56 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABBE21F8B7E; Wed, 14 Dec 2011 08:23:55 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryw9rT8RFvhj; Wed, 14 Dec 2011 08:23:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E9121F8B63; Wed, 14 Dec 2011 08:23:54 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111214162354.20548.77033.idtracker@ietfa.amsl.com> Date: Wed, 14 Dec 2011 08:23:54 -0800 Cc: netconf mailing list , netconf chair , RFC Editor Subject: [Netconf] Protocol Action: 'Network Configuration Protocol (NETCONF) Base Notifications' to Proposed Standard (draft-ietf-netconf-system-notifications-07.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 16:23:56 -0000 The IESG has approved the following document: - 'Network Configuration Protocol (NETCONF) Base Notifications' (draft-ietf-netconf-system-notifications-07.txt) as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-system-notifications/ Technical Summary The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. Working Group Summary The document has been longly discussed in the Working Group, including several WG Last Calls. The comments and reviews helped to improve the document a lot and the current version reflects the consensus of the Working Group. There was some debate on the scope of the draft. Kent Watsen was the only person who proposed the document to cover a much bigger scope. The system-startup notification has been removed after some discussion. The last WGLC did raise only minor issues. The changes have been accepted by the WG with some additional discussion and bug fixing. Document Quality It is expected that NETCONF implementations will be extended once this document gets published as proposed standard to support system notifications. Personnel Mehmet Ersue is the Document Shepherd for this document Dan Romascanu is the Responsible Area Director. From dromasca@avaya.com Wed Dec 14 08:53:27 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A803921F85B1 for ; Wed, 14 Dec 2011 08:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9iN5HuI0umu for ; Wed, 14 Dec 2011 08:53:27 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 19D9621F8551 for ; Wed, 14 Dec 2011 08:53:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4AAB7T6E7GmAcF/2dsb2JhbABDmmGQRoEFgXIBAQEBAwEBAQ8eCjQJDgQCAQgNBAQBAQsGDAcEAQYBJh8JCAEBBBMIGodgm0mbZYhvgjdjBJphjD4 X-IronPort-AV: E=Sophos;i="4.71,353,1320642000"; d="scan'208";a="319554738" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Dec 2011 11:53:26 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Dec 2011 11:50:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Dec 2011 17:53:23 +0100 Message-ID: In-Reply-To: <20111214162354.20548.77033.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Network Configuration Protocol (NETCONF) BaseNotifications' to Proposed Standard(draft-ietf-netconf-system-notifications-07.txt) Thread-Index: Acy6fNwzeWBw68X1SDaMEY3VmWsjwgAA+zCA References: <20111214162354.20548.77033.idtracker@ietfa.amsl.com> From: "Romascanu, Dan (Dan)" To: Subject: Re: [Netconf] Protocol Action: 'Network Configuration Protocol (NETCONF) BaseNotifications' to Proposed Standard(draft-ietf-netconf-system-notifications-07.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 16:53:27 -0000 Congratulations to the editors, chairs and WG for meting this milestone. Regards, Dan > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, December 14, 2011 6:24 PM > To: IETF-Announce > Cc: netconf mailing list; netconf chair; RFC Editor > Subject: Protocol Action: 'Network Configuration Protocol (NETCONF) > BaseNotifications' to Proposed Standard(draft-ietf-netconf-system- > notifications-07.txt) >=20 > The IESG has approved the following document: > - 'Network Configuration Protocol (NETCONF) Base Notifications' > (draft-ietf-netconf-system-notifications-07.txt) as a Proposed > Standard >=20 > This document is the product of the Network Configuration Working > Group. >=20 > The IESG contact persons are Dan Romascanu and Ron Bonica. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-netconf-system- > notifications/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > The NETCONF protocol provides mechanisms to manipulate configuration > datastores. However, client applications often need to be aware of > common events such as a change in NETCONF server capabilities, that > may impact management applications. Standard mechanisms are needed > to support the monitoring of the base system events within the > NETCONF server. This document defines a YANG module that allows a > NETCONF client to receive notifications for some common system > events. >=20 > Working Group Summary >=20 > The document has been longly discussed in the Working Group, > including several WG Last Calls. The comments and reviews helped > to improve the document a lot and the current version reflects the > consensus of the Working Group. > There was some debate on the scope of the draft. Kent Watsen was > the only person who proposed the document to cover a much bigger > scope. The system-startup notification has been removed after some > discussion. > The last WGLC did raise only minor issues. The changes have been > accepted by the WG with some additional discussion and bug fixing. >=20 > Document Quality >=20 > It is expected that NETCONF implementations will be extended once > this document gets published as proposed standard to support system > notifications. >=20 > Personnel >=20 > Mehmet Ersue is the Document Shepherd for this document > Dan Romascanu is the Responsible Area Director. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From mehmet.ersue@nsn.com Wed Dec 14 09:32:35 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF5321F8B81 for ; Wed, 14 Dec 2011 09:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOs8cZheGvaT for ; Wed, 14 Dec 2011 09:32:34 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6625221F8B65 for ; Wed, 14 Dec 2011 09:32:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBEHWVXn030357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2011 18:32:31 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBEHWUD1002512; Wed, 14 Dec 2011 18:32:31 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Dec 2011 18:32:30 +0100 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, 14 Dec 2011 18:32:30 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64032978E1@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Protocol Action: 'Network Configuration Protocol(NETCONF) BaseNotifications' to ProposedStandard(draft-ietf-netconf-system-notifications-07.txt) Thread-Index: Acy6fNwzeWBw68X1SDaMEY3VmWsjwgAA+zCAAAFbGwA= References: <20111214162354.20548.77033.idtracker@ietfa.amsl.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 14 Dec 2011 17:32:30.0909 (UTC) FILETIME=[5B6BFED0:01CCBA86] Subject: Re: [Netconf] Protocol Action: 'Network Configuration Protocol(NETCONF) BaseNotifications' to ProposedStandard(draft-ietf-netconf-system-notifications-07.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 17:32:35 -0000 Same here. Thanks to Andy for pushing the draft and everybody who supported it. Cheers,=20 Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Romascanu, Dan (Dan) > Sent: Wednesday, December 14, 2011 5:53 PM > To: netconf@ietf.org > Subject: Re: [Netconf] Protocol Action: 'Network Configuration Protocol(NETCONF) > BaseNotifications' to ProposedStandard(draft-ietf-netconf-system-notifications-07.txt) >=20 > Congratulations to the editors, chairs and WG for meting this milestone. >=20 >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > > bounces@ietf.org] On Behalf Of The IESG > > Sent: Wednesday, December 14, 2011 6:24 PM > > To: IETF-Announce > > Cc: netconf mailing list; netconf chair; RFC Editor > > Subject: Protocol Action: 'Network Configuration Protocol (NETCONF) > > BaseNotifications' to Proposed Standard(draft-ietf-netconf-system- > > notifications-07.txt) > > > > The IESG has approved the following document: > > - 'Network Configuration Protocol (NETCONF) Base Notifications' > > (draft-ietf-netconf-system-notifications-07.txt) as a Proposed > > Standard > > > > This document is the product of the Network Configuration Working > > Group. > > > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > > > A URL of this Internet Draft is: > > http://datatracker.ietf.org/doc/draft-ietf-netconf-system- > > notifications/ > > > > > > > > > > Technical Summary > > > > The NETCONF protocol provides mechanisms to manipulate > configuration > > datastores. However, client applications often need to be aware of > > common events such as a change in NETCONF server capabilities, that > > may impact management applications. Standard mechanisms are needed > > to support the monitoring of the base system events within the > > NETCONF server. This document defines a YANG module that allows a > > NETCONF client to receive notifications for some common system > > events. > > > > Working Group Summary > > > > The document has been longly discussed in the Working Group, > > including several WG Last Calls. The comments and reviews helped > > to improve the document a lot and the current version reflects the > > consensus of the Working Group. > > There was some debate on the scope of the draft. Kent Watsen was > > the only person who proposed the document to cover a much bigger > > scope. The system-startup notification has been removed after some > > discussion. > > The last WGLC did raise only minor issues. The changes have been > > accepted by the WG with some additional discussion and bug fixing. > > > > Document Quality > > > > It is expected that NETCONF implementations will be extended once > > this document gets published as proposed standard to support system > > notifications. > > > > Personnel > > > > Mehmet Ersue is the Document Shepherd for this document > > Dan Romascanu is the Responsible Area Director. > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Wed Dec 14 14:25:47 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E3311E80CC for ; Wed, 14 Dec 2011 14:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoohlPpdKE5m for ; Wed, 14 Dec 2011 14:25:46 -0800 (PST) Received: from relay54.tele2.vuurwerk.nl (relay54.tele2.vuurwerk.nl [62.250.3.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2A99211E80AA for ; Wed, 14 Dec 2011 14:25:46 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1RaxGj-0007gT-CG for netconf@ietf.org; Wed, 14 Dec 2011 23:25:45 +0100 Message-ID: <9C7FD475C469428CA2474B402533B4A3@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 14 Dec 2011 23:25:39 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [Netconf] Fw: Last Call: (The RPKI/RouterProtocol) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 22:25:47 -0000 Randy Bush response to that comment that I firwarded just a minute ago. Bert ----- Original Message ----- From: "Randy Bush" To: "Shane Amante" Cc: "IETF Disgust" Sent: Wednesday, December 14, 2011 10:42 PM Subject: Re: Last Call: (The RPKI/RouterProtocol) to Proposed Standard >I am not sure if this is an architectural misunderstanding V a red > herring. > > As you say, NetConf is for *configuring* routers. RPKI-rtr is not used > for router configuration, but rather dynamic data, a la IS-IS or BGP. > In fact, the RPKI-rtr payload data go into the same data structure as > the BGP data. > > Of course, the configuration of the RPKI-rtr relationship to cache(s) is > router configuration, similar to configuring BGP peers, and presumably > can be done by NetConf on those platforms which support NetConf. > > Bottom line: NetConf 'replaces' the CLI, not BGP. > > FWIW, two or three years ago, not wanting to reinvent the wheel, we > looked at NetConf-style payload packaging. After all, Bert and I > chartered NetConf back in the day. I still owe a dinner to the two > NetConf folk who helped try. Unfortunately the mismatch was > non-trivial, though nowhere near the mismatch of DNSsec, at which we > also looked (as the Tonys and I had published in 1998, Lutz in 2006, > etc., of which I presume you are unaware). > > When we evaluated the data bloat for NetConf-style packaging we were not > cheered. While probably not important for a CLI replacement, for a > continuous dynamic protocol the overhead of unpacking XML and decoding > the contained ASCII payload drew unhappy whining from the router > hackers. > > NetConf is not ideal for a long-session back-and-forth protocol, with > RPKI-rtr's serial number exchange which leaves the router in control of > the exchanges and enables incremental update of the data. You *really* > do not want the cache to send the full data set to the router every > time. And you definitely do not want a cache trying to keep track of > the state of O(100) router clients which may or may not still think they > are its friend. > > And, sadly, NetConf is not available on significant platforms where > RPKI-rtr is already running today. > > So, all in all, being lazy, of course we tried. But it was not a good > fit. Of course, if you want to have a go at it, I am sure we would be > willing to at least kibitz. But first you might want to talk to the > vendors who have already implemented RPKI-rtr to see if they would be > willing to re-code. > > randy > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From bertietf@bwijnen.net Wed Dec 14 14:25:47 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EAF11E80CD for ; Wed, 14 Dec 2011 14:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Feza8FEwlZqM for ; Wed, 14 Dec 2011 14:25:46 -0800 (PST) Received: from relay54.tele2.vuurwerk.nl (relay54.tele2.vuurwerk.nl [62.250.3.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8CB11E809F for ; Wed, 14 Dec 2011 14:25:46 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1RaxGj-0007gT-0Z for netconf@ietf.org; Wed, 14 Dec 2011 23:25:45 +0100 Message-ID: <7797C89608B94A0C8C8060AD887E0E38@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 14 Dec 2011 23:24:31 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [Netconf] Fw: Last Call: (The RPKI/RouterProtocol) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 22:25:47 -0000 I don't think that our Netconf protocol was intended for this. But I am forwarding this to the WG, so that people are aware. Bert ----- Original Message ----- From: "Shane Amante" To: Sent: Wednesday, December 14, 2011 4:27 AM Subject: Re: Last Call: (The RPKI/RouterProtocol) to Proposed Standard > [Resending to ietf@ietf.org] > > I am curious why an IETF WG (SIDR) has endorsed a wholly new protocol through > which to configure policy information on routers (as proposed in > draft-ietf-sidr-rpki-rtr), particularly when the IETF already has existing > standards to do so, namely: NETCONF [RFC4741] & YANG [RFC6020]? In addition, > given that NETCONF + YANG were designed for extensibility, they would allow > operators to take it upon themselves, if they wish, to easily enrich and/or > extend RPKI-validated data before it is sent from an RPKI cache to routers, > (compared to a binary protocol like RPKI-RTR). I don't see any discussion in > draft-ietf-sidr-rpki-rtr as to whether: a) consideration was given to develop > a YANG model, for validated RPKI data, which then would use NETCONF to > securely transport that from an RPKI cache to the router; and, b) if it was > considered, what were the reasons that approach was not pursued. > > In the short-term, I am concerned that, from an architectural point-of-view, > the IETF has not chosen to re-use the existing set of very successful > configuration protocols, namely NETCONF & YANG, for the task of configuring > validated policy information from the RPKI to/within routers. This could not > only cause confusion in the industry, but also lead to additional operational > costs to operators who would have to maintain two protocols for configuring > policy on their network: RPKI-RTR and, separately, NETCONF/YANG, particularly > when those same operators already have to use NETCONF/YANG for other router > configuration tasks anyway. Furthermore, NETCONF is in shipping & deployed > implementations today vs. RPKI-RTR which is likely still several years in the > future before it starts shipping in GA SW releases, not including the time it > will take to qualify it before it sees actual network deployment. > > Longer term, development of a new configuration protocol, (namely RPKI-RTR), > likely has architectural implications given the discussion that occurred at > IETF 82 in the SDN "informational-gathering session", held on Thursday > afternoon. Although it is a too early to tell where the discussions at that > SDN meeting will ultimately lead to, there did seem to be a significant amount > of interest in the architectural concept of looking at the problem of > attempting to configure networks using a top-down methodology and, in > particular, re-using those existing IETF protocols, e.g.: NETCONF/YANG, SNMP, > etc., southbound from an SDN Orchestrator toward various network elements. As > such, it may be useful for the IESG and IAB to collaborate on the long-term > architectural implications and additional complexity that another "southbound > protocol", specifically: RPKI-RTR, could have on future efforts such as those > discussed in the SDN meeting. > > -shane > > > On Nov 29, 2011, at 3:51 PM, The IESG wrote: >> The IESG has received a request from the Secure Inter-Domain Routing WG >> (sidr) to consider the following document: >> - 'The RPKI/Router Protocol' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2011-12-13. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> In order to formally validate the origin ASs of BGP announcements, >> routers need a simple but reliable mechanism to receive RPKI >> [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This >> document describes a protocol to deliver validated prefix origin data >> to routers. >> >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From bertietf@bwijnen.net Thu Dec 15 06:28:14 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0221F899F for ; Thu, 15 Dec 2011 06:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK6MoGayqFcu for ; Thu, 15 Dec 2011 06:28:13 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 6725B21F8888 for ; Thu, 15 Dec 2011 06:28:11 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RbCI1-0005IL-4I for netconf@ietf.org; Thu, 15 Dec 2011 15:28:10 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RbCI0-00034r-PQ for netconf@ietf.org; Thu, 15 Dec 2011 15:28:05 +0100 Message-ID: <4EEA03F4.6000607@bwijnen.net> Date: Thu, 15 Dec 2011 15:28:04 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Netconf References: <4EE93050.3070309@raszuk.net> In-Reply-To: <4EE93050.3070309@raszuk.net> X-Forwarded-Message-Id: <4EE93050.3070309@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4be62a5406ddc3a6ce0268ffcfa49ed56 Subject: [Netconf] Fwd: Re: Last Call: (The RPKI/Router Protocol) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 14:28:15 -0000 FYI -------- Original Message -------- Subject: Re: Last Call: (The RPKI/Router Protocol) to Proposed Standard Date: Thu, 15 Dec 2011 00:25:04 +0100 From: Robert Raszuk Reply-To: robert@raszuk.net To: Randy Bush , Shane Amante CC: IETF Disgust Let me observe that there could be middle ground to both sides here. While I am very well aware that few of the commercial routers support inline origin validation and rpki-rtr protocol to retrieve the abstract of RPKI data needed for validation it seems also very clear that this is just one possible deployment model. Let's observe that there are going to be orders of magnitude more BGP implementations which will never get the BGP origin validation code into their branches yet which will still happily run in many production networks for years to come which may be a significant obstacle to the deployment of this functionality. Therefor I would consider an alternative deployment model where the validation happens (even if a bit delayed) at few distributed BGP prefix validators around given AS then the outcome of such validation is distributed in the form of BGP policy configuration (via Netconf) to all legacy BGP speakers. While perhaps risking to say unpopular comment my personal preference would be for the latter deployment model. With this in mind I do agree with Shane that in general IETF should try to reuse existing protocols to accomplish the goals by recommending such deployment models which allow one to do so rather then keep inventing more and more protocols to address point solutions. Best, R. > I am not sure if this is an architectural misunderstanding V a red > herring. > > As you say, NetConf is for *configuring* routers. RPKI-rtr is not used > for router configuration, but rather dynamic data, a la IS-IS or BGP. > In fact, the RPKI-rtr payload data go into the same data structure as > the BGP data. > > Of course, the configuration of the RPKI-rtr relationship to cache(s) is > router configuration, similar to configuring BGP peers, and presumably > can be done by NetConf on those platforms which support NetConf. > > Bottom line: NetConf 'replaces' the CLI, not BGP. > > FWIW, two or three years ago, not wanting to reinvent the wheel, we > looked at NetConf-style payload packaging. After all, Bert and I > chartered NetConf back in the day. I still owe a dinner to the two > NetConf folk who helped try. Unfortunately the mismatch was > non-trivial, though nowhere near the mismatch of DNSsec, at which we > also looked (as the Tonys and I had published in 1998, Lutz in 2006, > etc., of which I presume you are unaware). > > When we evaluated the data bloat for NetConf-style packaging we were not > cheered. While probably not important for a CLI replacement, for a > continuous dynamic protocol the overhead of unpacking XML and decoding > the contained ASCII payload drew unhappy whining from the router > hackers. > > NetConf is not ideal for a long-session back-and-forth protocol, with > RPKI-rtr's serial number exchange which leaves the router in control of > the exchanges and enables incremental update of the data. You *really* > do not want the cache to send the full data set to the router every > time. And you definitely do not want a cache trying to keep track of > the state of O(100) router clients which may or may not still think they > are its friend. > > And, sadly, NetConf is not available on significant platforms where > RPKI-rtr is already running today. > > So, all in all, being lazy, of course we tried. But it was not a good > fit. Of course, if you want to have a go at it, I am sure we would be > willing to at least kibitz. But first you might want to talk to the > vendors who have already implemented RPKI-rtr to see if they would be > willing to re-code. > > randy > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From dbharrington@comcast.net Fri Dec 16 15:28:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4208B21F8487 for ; Fri, 16 Dec 2011 15:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7Q0yPmjhrFo for ; Fri, 16 Dec 2011 15:28:23 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1521F844D for ; Fri, 16 Dec 2011 15:28:23 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id 9zKn1i0041YDfWL5CzUPuu; Fri, 16 Dec 2011 23:28:23 +0000 Received: from davidPC ([71.233.85.150]) by omta20.westchester.pa.mail.comcast.net with comcast id 9zUN1i0023Ecudz3gzUNzx; Fri, 16 Dec 2011 23:28:22 +0000 From: "David B Harrington" To: , Date: Fri, 16 Dec 2011 18:28:07 -0500 Message-ID: <417E7DB0279844BFA56B8BD3DC0853D3@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acy2eeqXnSj5ZWrSTem087bXtnI0cAABnwuwAXJzbCA= X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-Mailman-Approved-At: Fri, 16 Dec 2011 15:36:39 -0800 Subject: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 23:28:24 -0000 This didn't get to the list. dbh -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Friday, December 09, 2011 10:44 AM To: 'Bert Wijnen (IETF)' Cc: 'Martin Bjorklund'; andy@netconfcentral.com; mehmet.ersue@nsn.com; dromasca@avaya.com; iesg@ietf.org Subject: RE: David Harrington's Discuss on draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) Hi, I don't think that's adequate. The way NACM is written, additional groups can be specified by any transport [model]. So it is not just RADIUS that is a concern; it is ANY transport (model) that might provide groups. Somebody could rewrite netconf/SSH and somehow add a group thing to it (I have no idea how). Security is a process. The ability to control addon groups must work across all transport models. An admin might want to disable the addon-groups feature globally. An admin might want to control specific transport models and not others. If a transport model is developed that supports the addon-group feature but doesn't offer an enable/disable capability, and NACM doesn't have a global switch, then we have a problem. The admin cannot configure either approach. I think the right way to handle this is to 1) provide a global switch, and 2) make it a requirement of NACM that *if** a transport model supports the passing of addon-groups for NACM, in whatever way, then it MUST offer an administratively configurable knob to enable/disable the functionality for that transport model. In 2.5, you have this text: The ACM needs to support the concept of administrative groups, to support the well-established distinction between a root account and other types of less-privileged conceptual user accounts. These groups needs to be configurable by the administrator. It is necessary that the user-to-group mapping can be delegated to a central server, such as a RADIUS server [RFC2865] [RFC5607]. Since authentication is performed by the NETCONF transport layer, and RADIUS performs authentication and service authorization at the same time, the underlying NETCONF transport needs to be able to report a set of group names associated with the user to the server. I suggest you add text that saya "Since an administrator may define the user-to-group mappings to constrain a user' rights, an administator MUST be able to configure NACM to not consider the dynamically-reported extra user-to-group mappings reported by the underlying NETCONF transport in the detrmination of user permissions." (i.e., a switch that says NACM can consider the INTERSECTION of the pre-configured and dynamic mappings, but not the UNION of the two. The default is to consider the union.) Remember COPS-PR, and its global lock that prevented an admin from overriding the policy server, inclduing with other NM protocols? In ISMS, the RADIUS folks argued that RADIUS should override the administrator; the SNMP folks argued that a configuration done by the human administrator should take precedence over what RADIUS says, because the human might know something that RADIUS doesn't. same debate: Policy-server versus human; who gets precedence? In ISMS we settled on a way to determine user-to-group mappings that RADIUS could not override (those that were not explicitly marked volatile in the MIB). In ISMS, we have a 1:1 user-to-group constraint; as a result, if there was a non-volatile entry for a user, RADIUS could not modify or add on additional user-to-group mappings. Netconf, however, doesn't have a 1:1 constraint, and doesn't have a MIB for NACM user-to-group bindings that gets modified when a transport layer reports user-to-group bindings; apparently the expectation is that the addon-groups will only be implemented as a temporary binding associated with the session rather than a change to the NACM pre-configuration. So the admin has no way to control these addon bindings; they cannot set the pre-configured user-to-group bindings as non-volatile to prevent dynamically changing the set of groups a user belongs to; they cannot disable the dynamic addon-group feature of NACM when they are in the process of debugging misconfigurations or tracking down a security problem. The only way, currently, for an operator to shut off the policy-driven group-addons is to go to the (RADIUS) policy server to remove the addon groups [which is equivalent to having to modify a COPS-PR policy at the policy server as the only way to override COPS-PR; even COPS-PR had a global switch for disabling policy that netconf does not). So I think, based on the long discussions we've already had in IETF about policy-driven versus human-configured, there needs to be a global switch to disable this dynamic user-to-group policy feature in NACM, and (if the WG wants this extra complexity) each transport that offers dynamic user-to-group mappings MUST have a knob at the policy-enforcement-point, that allows an operator to do a dynamic-policy-override, either manually or by pre-configuration of NACM user-to-group bindings that cannot be modified (including adding on extra user-to-group bindings) by THAT transport. dbh > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: Friday, December 09, 2011 8:53 AM > To: David Harrington > Cc: Martin Bjorklund; andy@netconfcentral.com; > mehmet.ersue@nsn.com; dromasca@avaya.com; iesg@ietf.org > Subject: Re: David Harrington's Discuss on > draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) > > David, W.r.t. to this discuss item, I check (as per below) with > the editor/author Martin, and I think that doing a YANG module > for aka radius-for-netconf migth make sense, and if we do so > then we can include such a leaf to disable the usage of the > Management-Policy-ID attribute. > > But I doubt we should do radius specific stuff in the NACM > module itself. > > So the proposal is to just add the suggested text to the > security considerations. Will that work for you and clear > your discuss? > > Thanks, > Bert > Document Shepherd > > > On 12/9/11 9:35 AM, Martin Bjorklund wrote: > > "Bert Wijnen (IETF)" wrote: > >> > >> > >> On 12/9/11 9:05 AM, Martin Bjorklund wrote: > >>> For bullet 1 below, I suggested: > >>> > >>> An administrator needs to be aware of the security > properties of > >>> any AAA protocol used by the NETCONF transport protocol to > >>> determine group names. For example, if the AAA > protocol does not > >>> protect against man-in-the-middle attacks, an > attacker might be > >>> able to inject group names that are configured in > NACM, so that a > >>> user gets more permissions than it should. In such > cases, the > >>> administrator may wish to disable the usage of such > group names in > >>> the AAA protocol. > >>> > >> > >> Does that not just mean to disable the "AAA protoco;" for use by > >> NETCONF server? > >> Is that then not a AAA issue? > > > > Right; at least an AAA-specific issue, when the AAA protocol is used > > with NETCONF. But disabling it completely doesn't solve > the problem. > > The issue is this: > > > > Suppose an administrator descides to use RADIUS for authentication > > only. He sets up his RADIUS server to just do > authentication. On the > > NETCONF device, he configures a "guest" group, to which all remote > > users are mapped. Now, an attacker manages to do a > man-in-the-middle > > attack, where he modifies the reply from the RADIUS server to also > > inclue a Management-Policy-ID attribute with the value "admin". The > > NETCONF server picks it up, and assigns this remote user to the > > "admin" group which has full access to the entire box. > > > > So, IMO, the "radius-for-netconf" YANG module should > contain a leaf to > > disable the usage of the Management-Policy-ID attribute. > > > > Making a global leaf is to coarse, since if one AAA protocol is > > secure, and another one is not, then disabling this for both is not > > useful. > > > > > > /martin > > > > > > > >> Sure we could add something to NETCONF too, but do we have > to do so at this > >> stage in the process? > >> > >> Bert > >> > >>> To which dbh replied: > >>> > >>> Good, but you need to make the object for > enabling/disabling the > >>> functionality a must-implement, or it won't be there when an > >>> operator needs it. > >>> > >>> > >>> Can we tweak the text I suggested somehow so that it > makes him happy > >>> without us adding this global leaf? It is a bit hard to add > >>> must-implement objects in the Security Consideration... > >> > > > From andy@netconfcentral.org Fri Dec 16 16:17:27 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4115D1F0C3F for ; Fri, 16 Dec 2011 16:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qaZ3dezzXru for ; Fri, 16 Dec 2011 16:17:26 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id C1FA21F0C3B for ; Fri, 16 Dec 2011 16:17:18 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pBH0HG00017679 for ; Fri, 16 Dec 2011 19:17:18 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43787] helo=[192.168.0.126]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 17/F5-30758-B8FDBEE4; Fri, 16 Dec 2011 19:17:16 -0500 Message-ID: <4EEBDF8B.8020300@netconfcentral.org> Date: Fri, 16 Dec 2011 16:17:15 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David B Harrington References: <417E7DB0279844BFA56B8BD3DC0853D3@davidPC> In-Reply-To: <417E7DB0279844BFA56B8BD3DC0853D3@davidPC> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 00:17:27 -0000 On 12/16/2011 03:28 PM, David B Harrington wrote: > This didn't get to the list. I'm trying to catch up with these details -- see inline... > > dbh Andy > > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, December 09, 2011 10:44 AM > To: 'Bert Wijnen (IETF)' > Cc: 'Martin Bjorklund'; andy@netconfcentral.com; mehmet.ersue@nsn.com; > dromasca@avaya.com; iesg@ietf.org > Subject: RE: David Harrington's Discuss on > draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) > > Hi, > > I don't think that's adequate. > > The way NACM is written, additional groups can be specified by any > transport [model]. > So it is not just RADIUS that is a concern; it is ANY transport > (model) that might provide groups. > Somebody could rewrite netconf/SSH and somehow add a group thing to it > (I have no idea how). > > Security is a process. The ability to control addon groups must work > across all transport models. > An admin might want to disable the addon-groups feature globally. We have this knob. I hope that is not the issue. > An admin might want to control specific transport models and not > others. I don't know if we need this knob, but I'll take your word for it. > If a transport model is developed that supports the addon-group > feature but doesn't offer an enable/disable capability, and NACM > doesn't have a global switch, then we have a problem. > The admin cannot configure either approach. > > I think the right way to handle this is to 1) provide a global switch, > and 2) make it a requirement of NACM that *if** a transport model > supports the passing of addon-groups for NACM, in whatever way, then > it MUST offer an administratively configurable knob to enable/disable > the functionality > for that transport model. This seems OK to me. I think we could actually construct a YANG module (using an identityref ID) so individual switches could be added for new transport protocols without rewriting the NACM module. > > In 2.5, you have this text: > The ACM needs to support the concept of administrative groups, to > support the well-established distinction between a root account and > other types of less-privileged conceptual user accounts. These > groups needs to be configurable by the administrator. > > It is necessary that the user-to-group mapping can be delegated to > a > central server, such as a RADIUS server [RFC2865] [RFC5607]. Since > authentication is performed by the NETCONF transport layer, and > RADIUS performs authentication and service authorization at the > same > time, the underlying NETCONF transport needs to be able to report a > set of group names associated with the user to the server. > > I suggest you add text that saya "Since an administrator may define > the user-to-group mappings to constrain a user' rights, an > administator MUST be able to configure NACM to not consider > the dynamically-reported extra user-to-group mappings reported by the > underlying NETCONF transport in the detrmination of user permissions." > (i.e., a switch that says NACM can consider the INTERSECTION of the > pre-configured and dynamic mappings, but not the UNION of the two. The > default is to consider the union.) > > Remember COPS-PR, and its global lock that prevented an admin from > overriding the policy server, inclduing with other NM protocols? Yes I remember it well. NETCONF nor NACM is anything like the all-or-nothing limitations of COPS-PR. An admin could hard-wire the user to group mappings in the local tables and set the global switch to off. But I agree your individual switches are better, so I'm OK with that. > In ISMS, the RADIUS folks argued that RADIUS should override the > administrator; the SNMP folks argued that a configuration done by the > human administrator should take precedence over what RADIUS says, > because the human might know something that RADIUS doesn't. same > debate: Policy-server versus human; who gets precedence? In ISMS we > settled on a way to determine user-to-group mappings that RADIUS could > not override (those that were not explicitly marked volatile in the > MIB). In ISMS, we have a 1:1 user-to-group constraint; as a result, if > there was a non-volatile entry for a user, RADIUS could not modify or > add on additional user-to-group mappings. > > Netconf, however, doesn't have a 1:1 constraint, and doesn't have a > MIB for NACM user-to-group bindings that gets modified when a > transport layer reports user-to-group bindings; apparently the > expectation is that the addon-groups will only be implemented as a > temporary binding associated with the session rather than a change to > the NACM pre-configuration. So the admin has no way to control these > addon bindings; they cannot set the pre-configured user-to-group > bindings as non-volatile to prevent dynamically changing the set of > groups a user belongs to; they cannot disable the dynamic addon-group > feature of NACM when they are in the process of debugging > misconfigurations or tracking down a security problem. > > The only way, currently, for an operator to shut off the policy-driven > group-addons is to go to the (RADIUS) policy server to remove the > addon groups [which is equivalent to having to modify a COPS-PR policy > at the policy server as the only way to override COPS-PR; even COPS-PR > had a global switch for disabling policy that netconf does not). > > So I think, based on the long discussions we've already had in IETF > about policy-driven versus human-configured, there needs to be a > global switch to disable this dynamic user-to-group policy feature in > NACM, and (if the WG wants this extra complexity) each transport that > offers dynamic user-to-group mappings MUST have a knob at the > policy-enforcement-point, that allows an operator to do a > dynamic-policy-override, either manually or by pre-configuration of > NACM user-to-group bindings that cannot be modified (including adding > on extra user-to-group bindings) by THAT transport. > > dbh Andy >> -----Original Message----- >> From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] >> Sent: Friday, December 09, 2011 8:53 AM >> To: David Harrington >> Cc: Martin Bjorklund; andy@netconfcentral.com; >> mehmet.ersue@nsn.com; dromasca@avaya.com; iesg@ietf.org >> Subject: Re: David Harrington's Discuss on >> draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) >> >> David, W.r.t. to this discuss item, I check (as per below) with >> the editor/author Martin, and I think that doing a YANG module >> for aka radius-for-netconf migth make sense, and if we do so >> then we can include such a leaf to disable the usage of the >> Management-Policy-ID attribute. >> >> But I doubt we should do radius specific stuff in the NACM >> module itself. >> >> So the proposal is to just add the suggested text to the >> security considerations. Will that work for you and clear >> your discuss? >> >> Thanks, >> Bert >> Document Shepherd >> >> >> On 12/9/11 9:35 AM, Martin Bjorklund wrote: >>> "Bert Wijnen (IETF)" wrote: >>>> >>>> On 12/9/11 9:05 AM, Martin Bjorklund wrote: >>>>> For bullet 1 below, I suggested: >>>>> >>>>> An administrator needs to be aware of the security >> properties of >>>>> any AAA protocol used by the NETCONF transport protocol to >>>>> determine group names. For example, if the AAA >> protocol does not >>>>> protect against man-in-the-middle attacks, an >> attacker might be >>>>> able to inject group names that are configured in >> NACM, so that a >>>>> user gets more permissions than it should. In such >> cases, the >>>>> administrator may wish to disable the usage of such >> group names in >>>>> the AAA protocol. >>>>> >>>> Does that not just mean to disable the "AAA protoco;" for use by >>>> NETCONF server? >>>> Is that then not a AAA issue? >>> Right; at least an AAA-specific issue, when the AAA protocol is > used >>> with NETCONF. But disabling it completely doesn't solve >> the problem. >>> The issue is this: >>> >>> Suppose an administrator descides to use RADIUS for authentication >>> only. He sets up his RADIUS server to just do >> authentication. On the >>> NETCONF device, he configures a "guest" group, to which all remote >>> users are mapped. Now, an attacker manages to do a >> man-in-the-middle >>> attack, where he modifies the reply from the RADIUS server to also >>> inclue a Management-Policy-ID attribute with the value "admin". > The >>> NETCONF server picks it up, and assigns this remote user to the >>> "admin" group which has full access to the entire box. >>> >>> So, IMO, the "radius-for-netconf" YANG module should >> contain a leaf to >>> disable the usage of the Management-Policy-ID attribute. >>> >>> Making a global leaf is to coarse, since if one AAA protocol is >>> secure, and another one is not, then disabling this for both is > not >>> useful. >>> >>> >>> /martin >>> >>> >>> >>>> Sure we could add something to NETCONF too, but do we have >> to do so at this >>>> stage in the process? >> >> >>>> Bert >>>> >>>>> To which dbh replied: >>>>> >>>>> Good, but you need to make the object for >> enabling/disabling the >>>>> functionality a must-implement, or it won't be there when an >>>>> operator needs it. >>>>> >>>>> >>>>> Can we tweak the text I suggested somehow so that it >> makes him happy >>>>> without us adding this global leaf? It is a bit hard to add >>>>> must-implement objects in the Security Consideration... > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From j.schoenwaelder@jacobs-university.de Sat Dec 17 02:31:27 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC4621F8BE9 for ; Sat, 17 Dec 2011 02:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.14 X-Spam-Level: X-Spam-Status: No, score=-103.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWChf+Hf+Jom for ; Sat, 17 Dec 2011 02:31:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA6F21F8BE8 for ; Sat, 17 Dec 2011 02:31:25 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72F8020D82; Sat, 17 Dec 2011 11:31:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M7OwqX4bPzUp; Sat, 17 Dec 2011 11:31:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E912C20D7F; Sat, 17 Dec 2011 11:31:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AD82C1C1C963; Sat, 17 Dec 2011 11:31:01 +0100 (CET) Date: Sat, 17 Dec 2011 11:31:01 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20111217103101.GA49087@elstar.local> Mail-Followup-To: Andy Bierman , David B Harrington , netconf@ietf.org, netconf-chairs@tools.ietf.org References: <417E7DB0279844BFA56B8BD3DC0853D3@davidPC> <4EEBDF8B.8020300@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EEBDF8B.8020300@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: David B Harrington , netconf@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 10:31:27 -0000 On Fri, Dec 16, 2011 at 04:17:15PM -0800, Andy Bierman wrote: > >I suggest you add text that saya "Since an administrator may define > >the user-to-group mappings to constrain a user' rights, an > >administator MUST be able to configure NACM to not consider > >the dynamically-reported extra user-to-group mappings reported by the > >underlying NETCONF transport in the detrmination of user permissions." > >(i.e., a switch that says NACM can consider the INTERSECTION of the > >pre-configured and dynamic mappings, but not the UNION of the two. The > >default is to consider the union.) > > > >Remember COPS-PR, and its global lock that prevented an admin from > >overriding the policy server, inclduing with other NM protocols? > > Yes I remember it well. > NETCONF nor NACM is anything like the all-or-nothing limitations of COPS-PR. > An admin could hard-wire the user to group mappings in the local tables > and set the global switch to off. > > But I agree your individual switches are better, so I'm OK with that. My understanding is that with ISMS, local configured mappings overwrite mappings obtained from other sources. If that is the behaviour we want, we should make it so. Switches that turn on/off _all_ dynamic mappings associated with a given transport are rather course grained and operationally likely not very helpful to resolve conflicts. In VACM, a (security name, security model) pair maps to exactly one group. This is rather different in NACM where a user name can be in multiple groups and dynamic group mappings provided by the transport are currently simply added to the set of groups a user belongs to. As a consequence, the solution likely needs to be different in that we might need to be able to configure in NACM (a) at a course grained level whether dynamically learned groups are used at all (global on/off switch) (b) at the level of a given transport whether we trust all of the transport's provided dynamic group mappings (this is what DBH suggested I think) (c) at the fine grained level of specific user entries whether we accept dynamically learned group entries It might be operationally relevant to allow a configuration that generally rejects dynamic group mappings (for a given transport) except for a white list of users where we trust the transport to do the right thing. /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 Sat Dec 17 03:49:07 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F1821F85C7 for ; Sat, 17 Dec 2011 03:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N6g5GjOo2fg for ; Sat, 17 Dec 2011 03:49:07 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CF62421F8586 for ; Sat, 17 Dec 2011 03:49:06 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D2B4F1200045; Sat, 17 Dec 2011 12:49:04 +0100 (CET) Date: Sat, 17 Dec 2011 12:49:04 +0100 (CET) Message-Id: <20111217.124904.64889221.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111217103101.GA49087@elstar.local> References: <417E7DB0279844BFA56B8BD3DC0853D3@davidPC> <4EEBDF8B.8020300@netconfcentral.org> <20111217103101.GA49087@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netconf-chairs@tools.ietf.org, dbharrington@comcast.net Subject: Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 11:49:07 -0000 Hi, Juergen Schoenwaelder wrote: > (a) at a course grained level whether dynamically learned groups are > used at all (global on/off switch) This was what dbh suggested, and we believe this is a good idea. So we propose we add this. Furthermore, Andy suggested that the entire concept of "allow dynamically learned groups" should be a YANG feature. I.e., optional to implement. > (b) at the level of a given transport whether we trust all of the > transport's provided dynamic group mappings (this is what DBH > suggested I think) This is what I personally think makes most sense; since it depends on the transport if you trust it to do the right thing or not. In any case, this is outside the scope of NACM. > (c) at the fine grained level of specific user entries whether we > accept dynamically learned group entries Hmm. I was thinking it might be useful to do this on a group basis. I.e. maybe you don't want the "superuser" group to be added dynamically. /martin > It might be operationally relevant to allow a configuration that > generally rejects dynamic group mappings (for a given transport) > except for a white list of users where we trust the transport to do > the right thing. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From internet-drafts@ietf.org Fri Dec 23 04:57:08 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE02721F84FC; Fri, 23 Dec 2011 04:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UEeeyRbSzCM; Fri, 23 Dec 2011 04:57:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5021F84A5; Fri, 23 Dec 2011 04:57:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111223125708.29140.9186.idtracker@ietfa.amsl.com> Date: Fri, 23 Dec 2011 04:57:08 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 12:57:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group o= f the IETF. Title : Network Configuration Protocol (NETCONF) Access Control = Model Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-access-control-07.txt Pages : 54 Date : 2011-12-23 The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-07.txt From bertietf@bwijnen.net Tue Dec 27 08:49:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA00F21F84F8 for ; Tue, 27 Dec 2011 08:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.014 X-Spam-Level: X-Spam-Status: No, score=-99.014 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcdKUdN6kGak for ; Tue, 27 Dec 2011 08:48:59 -0800 (PST) Received: from relay54.tele2.vuurwerk.nl (relay54.tele2.vuurwerk.nl [62.250.3.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABD921F850E for ; Tue, 27 Dec 2011 08:48:59 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1RfaCr-0008OQ-K1 for netconf@ietf.org; Tue, 27 Dec 2011 17:48:53 +0100 Message-ID: <03E146553DC644748AA096E6839D172B@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Tue, 27 Dec 2011 17:48:52 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [Netconf] Pls check before COB Jan 6th, 2012: draft-ietf-netconf-access-control-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 16:49:00 -0000 Dear WG participants, Just on Xmas eve, we cleared the IESG comments and DISCUSS on this document. To clear the discuss, we had to add a knob in the ietf-netconf-acm YANG module that allows an administartor to enable/disable dynamic addtion of external groups: leaf enable-external-groups { type boolean; default true; description "Controls whether the server uses the groups reported by the NETCONF transport layer when it assigns the user to a set of NACM groups. If this leaf has the value 'false', any group names reported by the transport layer are ignored by the server."; } That is the only substantial change, and we want to be sure the WG agrees with that. Other than that we believe that the changes are only editorial and/or clarifications. Pls let us know if you agree or disagree. Bert Wijnen, document shepherd ----- Original Message ----- From: To: Cc: Sent: Friday, December 23, 2011 1:57 PM Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Network Configuration Working > Group of the IETF. > > Title : Network Configuration Protocol (NETCONF) Access Control > Model > Author(s) : Andy Bierman > Martin Bjorklund > Filename : draft-ietf-netconf-access-control-07.txt > Pages : 54 > Date : 2011-12-23 > > The standardization of network configuration interfaces for use with > the NETCONF protocol requires a structured and secure operating > environment that promotes human usability and multi-vendor > interoperability. There is a need for standard mechanisms to > restrict NETCONF protocol access for particular users to a pre- > configured subset of all available NETCONF protocol operations and > content. This document defines such an access control model. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-07.txt > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf