From matjaz@mg-soft.si Fri Jul 1 02:35:49 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 C904D11E80E5 for ; Fri, 1 Jul 2011 02:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYzrAu1v+1Kq for ; Fri, 1 Jul 2011 02:35:49 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4311E80E2 for ; Fri, 1 Jul 2011 02:35:47 -0700 (PDT) Received: from [127.0.0.1] (mg-soft.si [10.0.0.15]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id p619ZiIk014112; Fri, 1 Jul 2011 11:35:44 +0200 Message-ID: <4E0D94E4.1040805@mg-soft.si> Date: Fri, 01 Jul 2011 11:35:32 +0200 From: Matjaz Vrecko Organization: MG-SOFT Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf , bertietf@bwijnen.net References: <80A0822C5E9A4440A5117C2F4CD36A6401E11409@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64021B94BF@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64021B94BF@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] NETCONF Protocol Interoperability Event around QuebecMeeting ? - MG-SOFT's NETCONF and YANG tools X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Matjaz Vrecko List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 09:35:49 -0000 Hello Mehmet, Bert et all, It's July 1st, which was the original scheduled date for the interoperability tests, so I would like to use the opportunity and post this brief note to let you know that MG-SOFT has recently published the RC4 release of our first two NETCONF/YANG products: NETCONF Browser and Visual YANG Designer. They are both available from our web site at http://www.mg-soft.com/download.html?os=java Until now, both our products were evaluated and tested mostly by Tail-F team (thank you very much once again to anyone involved at Tail-F's side!) and some other selected customers (thank you to them as well!),... and now we are offering them to anyone interested for evaluation, interoperability testing and review. We would appreciate to receive any kind of feedback. Thank you and best regards, Matjaz On 19-May-2011 2:57 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > it seems there is no sufficient interest on a NETCONF > Protocol Interoperability Event. Thank you to those few > guys who send us their comments. > > We go into a silent mode now, until we here some concrete > interest for such an event with the goal to get NETCONF > documents into draft standard status. > > Mehmet& Bert > > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of ext Bert Wijnen (IETF) >> Sent: Saturday, April 30, 2011 5:17 PM >> To: netconf >> Subject: Re: [Netconf] NETCONF Protocol Interoperability Event around >> QuebecMeeting ? >> >> We (WG chairs) made a little mistake. WE did not >> put a deadline for responsesn. >> >> Sofar, we have only had one response (albeit a positive one) >> to our poll for interest in an interoperability event around the >> next IETF meeting. >> >> If we do not get (at least 2, preferably more) more positive >> responses by May 10, then we won't have such an event. >> >> Your WG chairs. >> Bert and Mehmet >> >> ----- Original Message ----- >> From: "Ersue, Mehmet (NSN - DE/Munich)" >> To: "netconf" >> Cc: "ext Romascanu, Dan (Dan)"; >> >> Sent: Sunday, April 03, 2011 9:35 AM >> Subject: NETCONF Protocol Interoperability Event around Quebec Meeting >> ? >> >> >> Dear NETCONF WG, >> >> in the IETF80 NETCONF session it has been discussed whether a NETCONF >> protocol interoperability event should be organized to take place >> around >> the Quebec meeting. >> The NETCONF interoperability event would be helpful to get our > Proposed >> Standards to the Draft Standard status. >> >> The chairs would like to sense of the WG for the level of interest of >> the implementers on such an interop event. >> >> The focus in the interoperability event would be on following RFCs: >> - draft-ietf-netconf-4741bis (in RFC Ed Queue), >> - draft-ietf-netconf-rfc4742bis (in RFC Ed Queue), >> - RFC 5277 - NETCONF Event Notifications, >> - RFC 6022 - YANG Module for NETCONF Monitoring, >> - RFC 5717 - Partial Lock RPC for NETCONF, >> - draft-ietf-netconf-with-defaults (in RFC Ed Queue). >> >> >> The questions we would like to clarify are in the first step: >> >> - Who has which implementations ready to test by July 1st, 2011? >> - Who would come with implementations and participate if the event >> gets >> organised? >> - Who can provide content for testing (i.e. YANG modules e.g. >> Monitoring)? >> - Who would be willing to prepare test cases? >> >> Please state your interest and opinion on the interop event to the >> chairs directly. >> >> Mehmet& Bert >> >> >> _______________________________________________ >> 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 -- Matjaz Vrecko MG-SOFT Corporation, Strma ulica 8, SI-2000 Maribor, Slovenia Internet: http://www.mg-soft.si/ E-mail: Phone: +386 2 2506565, Fax: +386 2 2506566 From dromasca@avaya.com Sun Jul 3 09:25:29 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 8847521F8628 for ; Sun, 3 Jul 2011 09:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.12 X-Spam-Level: X-Spam-Status: No, score=-103.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHOnG1mGDvwh for ; Sun, 3 Jul 2011 09:25:29 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3421F8626 for ; Sun, 3 Jul 2011 09:25:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABANaWEE6HCzI1/2dsb2JhbABSmEiDVYtgd68iAporhjYEl0uENYZu X-IronPort-AV: E=Sophos;i="4.65,468,1304308800"; d="scan'208";a="254663063" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Jul 2011 12:25:26 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Jul 2011 12:18:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Jul 2011 18:25:24 +0200 Message-ID: In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64024F9B50@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] New RFCs are now available WAS:FW: RFC 6241 on NetworkConfiguration Protocol (NETCONF) Thread-Index: Acw3XrwACV6ZkHIqS9KW+qVkOHP5EQACxIhQAIz7UKA= References: <80A0822C5E9A4440A5117C2F4CD36A64024F9B50@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf" Subject: Re: [Netconf] New RFCs are now available WAS:FW: RFC 6241 on NetworkConfiguration Protocol (NETCONF) 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, 03 Jul 2011 16:25:29 -0000 Hi,=20 Thanks and congratulations to the editors, chairs and the whole WG.=20 Regards, Dan=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Ersue, Mehmet (NSN - DE/Munich) > Sent: Friday, July 01, 2011 12:12 AM > To: netconf > Subject: [Netconf] New RFCs are now available WAS:FW: RFC 6241 on > NetworkConfiguration Protocol (NETCONF) >=20 > Congratulations to all editors, coauthors and the contributors of > the new RFCs 6341, 6242, and 6243 and the substantial work they did. >=20 > Thank you to the whole WG for reviewing and supporting the development. >=20 > Mehmet >=20 > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ext > rfc-editor@rfc-editor.org > Sent: Thursday, June 30, 2011 9:46 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netconf@ietf.org; rfc-editor@rfc-editor.org > Subject: RFC 6241 on Network Configuration Protocol (NETCONF) >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6241 >=20 > Title: Network Configuration Protocol (NETCONF) > Author: R. Enns, Ed., > M. Bjorklund, Ed., > J. Schoenwaelder, Ed., > A. Bierman, Ed. > Status: Standards Track > Stream: IETF > Date: June 2011 > Mailbox: rob.enns@gmail.com, > mbj@tail-f.com, > j.schoenwaelder@jacobs-university.de, > andy.bierman@brocade.com > Pages: 113 > Characters: 209465 > Obsoletes: RFC4741 >=20 > I-D Tag: draft-ietf-netconf-4741bis-10.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6241.txt >=20 > The Network Configuration Protocol (NETCONF) defined in this document > provides mechanisms to install, manipulate, and delete the > configuration of network devices. It uses an Extensible Markup > Language (XML)-based data encoding for the configuration data as well > as the protocol messages. The NETCONF protocol operations are > realized as remote procedure calls (RPCs). This document obsoletes > RFC 4741. [STANDARDS-TRACK] >=20 > This document is a product of the Network Configuration Working Group > of > the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > 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 mehmet.ersue@nsn.com Tue Jul 5 01:38:49 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 1131421F865C for ; Tue, 5 Jul 2011 01:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.2 X-Spam-Level: X-Spam-Status: No, score=-96.2 tagged_above=-999 required=5 tests=[AWL=-10.100, BAYES_99=3.5, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ3rSPBNziKp for ; Tue, 5 Jul 2011 01:38:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CCB4121F878F for ; Tue, 5 Jul 2011 01:38:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p658ceZe028041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 5 Jul 2011 10:38:46 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p658cepg012970 for ; Tue, 5 Jul 2011 10:38:40 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jul 2011 10:38:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC3AEE.F069B2C9" Date: Tue, 5 Jul 2011 10:38:38 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640253DF2C@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2011-2012: Third Call for Volunteers Thread-Index: Acw6YdXEMViNNQVvQP2YfrSj16VxVwAHoKCgABuT9yA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 05 Jul 2011 08:38:39.0923 (UTC) FILETIME=[F08BE830:01CC3AEE] Subject: [Netconf] FW: Nomcom 2011-2012: Third Call for Volunteers 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, 05 Jul 2011 08:38:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3AEE.F069B2C9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIGNhbm5vdCBzYXkgaXQgYmV0dGVyLiBQbGVhc2UgY29uc2lkZXIgdG8gdm9s dW50ZWVyIGZvciBOb21Db20uDQoNCk1laG1ldCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFJvbWFzY2FudSwgRGFuIChEYW4pIFttYWlsdG86ZHJvbWFzY2FAYXZheWEuY29t XSANClNlbnQ6IE1vbmRheSwgSnVseSAwNCwgMjAxMSA5OjI5IFBNDQpUbzogb3BzLWFkc0B0b29s cy5pZXRmLm9yZw0KU3ViamVjdDogRlc6IE5vbWNvbSAyMDExLTIwMTI6IFRoaXJkIENhbGwgZm9y IFZvbHVudGVlcnMgDQoNCkhpLCANCg0KUGxlYXNlIGZvcndhcmQgdGhpcyBtYWlsIGZyb20gdGhl IE5vbWNvbSBjaGFpciB0byB5b3VyIFdHIG1haWwgbGlzdHMuIFBsZWFzZSByZW1pbmQgZXZlcnli b2R5IHRoYXQgcGFydGljaXBhdGlvbiBpbiBOb21jb20gaXMgb2YgZ3JlYXQgaW1wb3J0YW5jZSBm b3IgdGhlIElFVEYgYW5kIGNvbnRyaWJ1dGVzIHRvIHRoZSBzZWxlY3Rpb24gb2YgdGhlIGZ1dHVy ZSBsZWFkZXJzaGlwIGFuZCBpbXByb3ZlbWVudCBvZiB0aGUgSUVURiBwcm9jZXNzZXMuIA0KDQpU aGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlldGYtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5vbUNvbSBDaGFpcg0KU2VudDogTW9u ZGF5LCBKdWx5IDA0LCAyMDExIDY6NDcgUE0NClRvOiBJRVRGIEFubm91bmNlbWVudCBsaXN0DQpD YzogaWV0ZkBpZXRmLm9yZw0KU3ViamVjdDogTm9tY29tIDIwMTEtMjAxMjogVGhpcmQgQ2FsbCBm b3IgVm9sdW50ZWVycyANCg0KVGhpcyBpcyB0aGUgVGhpcmQgY2FsbCBmb3IgVm9sdW50ZWVycyBm b3IgdGhlIDIwMTEtMTIgTm9tY29tLiAgV2UgYXJlIGFsbW9zdCB0aHJvdWdoIHRoZSB2b2x1bnRl ZXIgcGVyaW9kIHNvIGlmIHlvdSBhcmUgY29uc2lkZXJpbmcgdm9sdW50ZWVyaW5nLCBwbGVhc2Ug ZG8gc28gdmVyeSBzb29uLiANCg0KV2UgaGF2ZSBoYWQgYSB2ZXJ5IGdvb2QgcmVzcG9uc2UgdG8g dGhlIGluaXRpYWwgY2FsbCBmb3Igdm9sdW50ZWVycyBhbmQgSSBhbSBwbGVhc2VkIHRvIHJlcG9y dCB0aGF0IHdlIGhhdmUgODQgdm9sdW50ZWVycyB0aHVzIGZhciB3aG9zZSBxdWFsaWZpY2F0aW9u cyBoYXZlIGJlZW4gY29uZmlybWVkIGJ5IHRoZSBzZWNyZXRhcmlhdC4gSSBoYXZlIG5vdGlmaWVk IGVhY2ggb2YgdGhlc2Ugdm9sdW50ZWVycyBieSBlbWFpbC4gIA0KDQpIb3dldmVyLCB3ZSB3b3Vs ZCBsaWtlIHRvIGhhdmUgbWFueSBtb3JlIHZvbHVudGVlcnMuIFRoZSBtb3JlIHZvbHVudGVlcnMs IHRoZSBiZXR0ZXIgY2hhbmNlIHdlIGhhdmUgb2YgY2hvb3NpbmcgYSByYW5kb20geWV0IHJlcHJl c2VudGF0aXZlIGNyb3NzIHNlY3Rpb24gb2YgdGhlIElFVEYgcG9wdWxhdGlvbi4gWW91IGhhdmUg dW50aWwgMTE6NTkgcG0gRURUIEp1bHkgMTAsIDIwMTEgdG8gdm9sdW50ZWVyIGZvciBOb21jb20g YnV0IGl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIGlmIHlvdSBjYW4gdm9sdW50ZWVyIGFzIGVhcmx5 IGFzIHBvc3NpYmxlLiANCg0KSWYgeW91IHZvbHVudGVlcmVkIGJlZm9yZSAwOTowMCBFRFQgb24g SnVuZSAyOSB0byBzZXJ2ZSBhcyBhIHZvdGluZyBtZW1iZXIgYW5kIGhhdmUgbm90IHJlY2VpdmVk IGEgY29uZmlybWF0aW9uIGVtYWlsIGZyb20gbWUsIHBsZWFzZSByZS1zdWJtaXQgYW5kIGJyaW5n IHRvIG15IGF0dGVudGlvbiByaWdodCBhd2F5IQ0KICAgDQpEZXRhaWxzIGFib3V0IHRoZSBwcm9j ZXNzIGZvciB2b2x1bnRlZXJpbmcgZm9yIHRoZSBOb21jb20gYW5kIHRoZSBsaXN0IG9mIG9wZW4g cG9zaXRpb25zIGZvciB3aGljaCB0aGUgbm9taW5hdGluZyBjb21taXR0ZWUgaXMgcmVzcG9uc2li bGUgYXJlIHN1bW1hcml6ZWQgaW4gdGhlIGluaXRpYWwgYW5ub3VuY2VtZW50Og0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2Fubi9ub21jb20vMjkzOC8NCg0KVGhlIDg0IHZvbHVudGVl cnMgd2hvIGhhdmUgdGh1cyBmYXIgYmVlbiBxdWFsaWZpZWQgYnkgdGhlIHNlY3JldGFyaWF0DQph cmU6DQoNCkFsaWEgQXRsYXMsSnVuaXBlciBOZXR3b3Jrcw0KTGl4aWEgWmhhbmcsVUNMQQ0KV2Fz c2ltIEhhZGRhZCAsRXJpY3Nzb24NCkdsZW4gWm9ybixOZXR3b3JrIFplbg0KUmljaGFyZCBCYXJu ZXMsQkJOIFRlY2hub2xvZ2llcw0KU3RlcGhlbiBLZW50LEJCTiBUZWNobm9sb2dpZXMNClNjb3R0 IE1hbnNmaWVsZCxFcmljc3Nvbg0KVGluYSBUU09VIChUaW5nIFpPVSksRnV0dXJlV2VpIFRlY2hu b2xvZ2llcyBGZXJuYW5kbyBHb250LFVUTi9GUkggS2FyZW4gU2VvLEJCTiBUZWNobm9sb2dpZXMg SmllIERvbmcsSHVhd2VpIFRlY2hub2xvZ2llcyBNYWNoIENoZW4sSHVhd2VpIFRlY2hub2xvZ2ll cyBDby4gTHRkLg0KU2hlbmcgSmlhbmcsSHVhd2VpIFRlY2hub2xvZ2llcyBDby4gTHRkLg0KRGlt aXRyaSBQYXBhZGltaXRyaW91LEFsY2F0ZWwtTHVjZW50DQpUaG9tYXMgRC4gTmFkZWF1LENBIFRl Y2hub2xvZ2llcw0KRGF2aWQgTWV5ZXIsQ2lzY28gU3lzdGVtcy9Vbml2ZXJzaXR5IG9mIE9yZWdv biBXZXNsZXkgR2VvcmdlLFRpbWUgV2FybmVyIENhYmxlIEN1bGxlbiBKZW5uaW5ncyxDaXNjbyBT dGVwaGVuIEhhbm5hLEp1bmlwZXIgTmV0d29ya3MgU3RlcGhhbiBXZW5nZXIsQmlkeW8gSW5jLg0K S2V5dXIgUGF0ZWwsQ2lzY28gU3lzdGVtcw0KTWljaGFlbCAoTWlrZSkgSGFtaWx0b24sQnJlYWtp bmdQb2ludCBTeXN0ZW1zIEJlaGNldCBTYXJpa2F5YSxIdWF3ZWkgVVNBIE1hcmsgVG93bnNsZXks Q2lzY28gU3lzdGVtcyBGcmVkIEJha2VyLENpc2NvIFN5c3RlbXMgQnJpYW4gVHJhbW1lbGwsRVRI IFpyaWNoIFNhbSBIYXJ0bWFuLFBhaW5sZXNzIFNlY3VyaXR5IENocmlzIEdyaWZmaXRocyxDb21j YXN0IEdlb3JnZSBNaWNoYWVsc29uLEFQTklDIEppYW5rYW5nIFlhbyxDTk5JQyBTb2hlbCBLaGFu LENvbWNhc3QgRGFjaGVuZyBaaGFuZyxIdWF3ZWkgTGlhbnNodSBaaGVuZyxIdWF3ZWkgVGVjaG5v bG9naWVzIEh1aSBEZW5nLENoaW5hIE1vYmlsZSBHYW5nIENoZW4sQ2hpbmEgTW9iaWxlIE1pcmph IEtobGV3aW5kLFVuaXZlcnNpdHkgb2YgU3R1dHRnYXJ0IElLUiBKb2huIEUgRHJha2UsSnVuaXBl ciBOZXR3b3JrcyBNYXR0IExlcGluc2tpLEJCTiBUZWNobm9sb2dpZXMgU3ViaXIgRGFzLFRlbGNv cmRpYSBUZWNobm9sb2dpZXMgSW5jIFlpIFpoYW8sSHVhd2VpIEpvaG4gU2N1ZGRlcixKdW5pcGVy IE5ldHdvcmtzIENocmlzdGVyIEhvbG1iZXJnLExNIEVyaWNzc29uIFRlZW11IFNhdm9sYWluZW4s Tm9raWEgU2FtaXRhIENoYWtyYWJhcnRpLEVyaWNzc29uIEphYXAgQWtrZXJodWlzLE5MbmV0IGxh YnMgSmFzb24gV2VpbCxUaW1lIFdhcm5lciBDYWJsZSBSYW5keSBCdXNoLEludGVybmV0IEluaXRp YXRpdmUgSmFwYW4gQ2hyaXN0aWFuIFNjaG1pZHQsTm9raWEgU2llbWVucyBOZXR3b3JrcyBTZWFu IFNoZW4sQ05OSUMgTG91IEJlcmdlcixMYWJOIENvbnN1bHRpbmcgTC5MLkMuDQpEb25hbGQgRWFz dGxha2UsSHVhd2VpDQpYaWFvaHUgWHUsSHVhd2VpIFRlY2hub2xvZ2llcyBjby4gTHRkLg0KQnJq ZSBPaGxtYW4sRXJpY3Nzb24NCkRlYm9yYWggQnJ1bmdhcmQsQVQmVA0KTWFnbnVzIFdlc3Rlcmx1 bmQsRXJpY3Nzb24NClpoZW4gQ2FvLENoaW5hIE1vYmlsZQ0KSGFkcmllbCBLYXBsYW4sQWNtZSBQ YWNrZXQNCkxpbGxhIERvdm5lcixFcmljc3Nvbg0KSm9obiBKYXNvbiBCcnpvem93c2tpLENvbWNh c3QNCkpvbm5lIFNvaW5pbmVuLFJlbmVzYXMgTW9iaWxlDQpKYXZpZXIgVWJpbGxvcyxTd2VkaXNo IEluc3RpdHV0ZSBvZiBDb21wdXRlciBTY2llbmNlIEVyaWMgR3JheSxFcmljc3NvbiBUaG9tYXMg SGVyYnN0LFNpbHZlciBTcHJpbmcgTmV0d29ya3MgTmluZyBab25nLEh1YXdlaSBUZWNobm9sb2dp ZXMgSGFpYmluIFNvbmcsSHVhd2VpIFRlY2hub2xvZ2llcyBZaW5namllIEd1LEh1YXdlaSBUZWNo bm9sb2dpZXMgSG9uZ3l1IExpLEh1YXdlaSBUZWNobm9sb2dpZXMgVGVycnkgTWFuZGVyc29uLElD QU5OIEFyaSBLZXJhbmVuLEVyaWNzc29uIEpvdW5pIEtvcmhvbmVuLE5va2lhIFNpZW1lbnMgTmV0 d29ya3MgQmh1bWlwIEtoYXNuYWJpc2gsWlRFIFVTQSBJbmMuDQpEYXBlbmcgTGl1LENoaW5hIE1v YmlsZQ0KRmFuZ3dlaSBIdSxaVEUgQ29ycG9yYXRpb24NCk9sZSBUcm9hbixDaXNjbw0KUGFzY2Fs IFRodWJlcnQsQ2lzY28NCldvamNpZWNoIERlYyxDaXNjbw0KR3VudGVyIFZhbiBkZSBWZWxkZSxD aXNjbw0KTmluZyBTbyxWZXJpem9uIEluYy4vVW5pdmVyc2l0eSBvZiBUZXhhcyBhdCBEYWxsYXMg R3VvbWFuIGxpdSxaVEUgU2ltb24gUGlldHJvIFJvbWFubyxNZWV0ZWNoby9Vbml2ZXJzaXR5IG9m IE5hcG9saSBMdWNhIE1hcnRpbmksQ2lzY28gQmlsbCBWZXJTdGVlZyxDaXNjbyBUb2VybGVzcyBF Y2tlcnQsQ2lzY28gU3lzdGVtcyBKb3NlcGggU2Fsb3dleSxDaXNjbyBTeXN0ZW1zDQoNClRoZSBw cmltYXJ5IGFjdGl2aXR5IGZvciB0aGlzIG5vbWNvbSB3aWxsIGJlZ2luIGR1cmluZyBJRVRGLTgx IGluIFF1ZWJlYyBDaXR5IGFuZCBzaG91bGQgYmUgY29tcGxldGVkIGJ5IEphbnVhcnkgMjAxMi4g VGhlIG5vbWNvbSB3aWxsIGJlIGNvbGxlY3RpbmcgcmVxdWlyZW1lbnRzIGZyb20gdGhlIGNvbW11 bml0eSwgYXMgd2VsbCBhcyB0YWxraW5nIHRvIGNhbmRpZGF0ZXMgYW5kIHRvIGNvbW11bml0eSBt ZW1iZXJzIGFib3V0IGNhbmRpZGF0ZXMuIFRoZXJlIHdpbGwgYmUgcmVndWxhcmx5IHNjaGVkdWxl ZCBjb25mZXJlbmNlIGNhbGxzIHRvIGVuc3VyZSBwcm9ncmVzcy4gVGh1cywgYmVpbmcgYSBub21j b20gbWVtYmVyIGRvZXMgcmVxdWlyZSBzb21lIHRpbWUgY29tbWl0bWVudC4NCiANClBsZWFzZSB2 b2x1bnRlZXIgYnkgc2VuZGluZyBhbiBlbWFpbCB0byBtZSBiZWZvcmUNCjExOjU5IHBtIEVEVCBK dWx5IDEwLCAyMDExIGFzIGZvbGxvd3M6DQoNClRvOiBzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24u Y29tDQpTdWJqZWN0OiBOb21jb20gMjAxMS0xMiBWb2x1bnRlZXINCg0KUGxlYXNlIGluY2x1ZGUg dGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBpbiB0aGUgYm9keSBvZiB0aGUgbWFpbDoNCg0KRnVs bCBOYW1lOiAgLy8gQXMgeW91IGVudGVyIGluIHRoZSBJRVRGIFJlZ2lzdHJhdGlvbiBGb3JtLA0K ICAgICAgICAgICAgLy8gRmlyc3QvR2l2ZW4gbmFtZSBmb2xsb3dlZCBieSBMYXN0L0ZhbWlseSBO YW1lDQoNCkN1cnJlbnQgUHJpbWFyeSBBZmZpbGlhdGlvbjogLy8gdHlwaWNhbGx5IHdoYXQgZ29l cyBpbiB0aGUgQ29tcGFueSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gZmllbGQg aW4gdGhlIElFVEYgUmVnaXN0cmF0aW9uIEZvcm0NCg0KRW1haWwgQWRkcmVzcyhlcyk6IC8vIGFs bCBlbWFpbCBhZGRyZXNzZXMgdXNlZCB0byBSZWdpc3RlciBmb3IgdGhlIA0KICAgICAgICAgICAg ICAgICAgIC8vIHBhc3QgNSBJRVRGIG1lZXRpbmdzDQoJCSAgIC8vIFBsZWFzZSBkZXNpZ25hdGUg YSBQcmVmZXJyZWQgZW1haWwgYWRkcmVzcyBmb3INCiAgICAgICAgICAgICAgICAgICAvLyBjb250 YWN0IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgZW1haWwgYWRkcmVzcw0KDQpUZWxlcGhvbmUg bnVtYmVyOiAgLy8gV2l0aCBjb3VudHJ5IGNvZGUgKGZvciBjb25maXJtYXRpb24gaWYgc2VsZWN0 ZWQpDQoNClBsZWFzZSBleHBlY3QgYW4gZW1haWwgcmVzcG9uc2UgZnJvbSBtZSB3aXRoaW4gMyBi dXNpbmVzcyBkYXlzIHN0YXRpbmcgd2hldGhlciBvciBub3QgeW91IGFyZSBxdWFsaWZpZWQuICBJ ZiB5b3UgZG8gbm90IHJlY2VpdmUgYSByZXNwb25zZSBpbiB0aGlzIHRpbWVmcmFtZSwgcGxlYXNl IHJlLXNlbmQgeW91ciBlbWFpbCB3aXRoIHRoZSB0YWcgIlJFU0VORDoiIGFkZGVkIHRvIHRoZSBz dWJqZWN0IGxpbmUuDQoNCklmIHlvdSBhcmUgbm90IHlldCBzdXJlIHlvdSB3b3VsZCBsaWtlIHRv IHZvbHVudGVlciwgcGxlYXNlIGNvbnNpZGVyIHRoYXQgTm9tY29tIG1lbWJlcnMgcGxheSBhIHZl cnkgaW1wb3J0YW50IHJvbGUgaW4gc2hhcGluZyB0aGUgbGVhZGVyc2hpcCBvZiB0aGUgSUVURi4g IEVuc3VyaW5nIHRoZSBsZWFkZXJzaGlwIG9mIHRoZSBJRVRGIGlzIGZhaXIgYW5kIGJhbGFuY2Vk IGFuZCBjb21wcmlzZWQgb2YgdGhvc2Ugd2hvIGNhbiBsZWFkIHRoZSBJRVRGIGluIHRoZSByaWdo dCBkaXJlY3Rpb24gaXMgYW4gaW1wb3J0YW50IHJlc3BvbnNpYmlsaXR5IHRoYXQgcmVzdHMgb24g dGhlIElFVEYgcGFydGljaXBhbnRzIGF0IGxhcmdlLiBWb2x1bnRlZXJpbmcgZm9yIHRoZSBOb21j b20gaXMgYSBnb29kIHdheSBvZiBjb250cmlidXRpbmcgaW4gdGhhdCBkaXJlY3Rpb24uDQoNCkkg d2lsbCBiZSBwdWJsaXNoaW5nIGEgbW9yZSBkZXRhaWxlZCB0YXJnZXQgdGltZXRhYmxlLCBhcyB3 ZWxsIGFzIGRldGFpbHMgb2YgdGhlIHJhbmRvbW5lc3Mgc2VlZHMgdG8gYmUgdXNlZCBmb3IgdGhl IFJGQyAzNzk3IHNlbGVjdGlvbiBwcm9jZXNzIHZlcnkgc29vbi4NCg0KVGhhbmsgeW91IGluIGFk dmFuY2UgZm9yIHlvdXIgcGFydGljaXBhdGlvbi4NCg0KU3VyZXNoIEtyaXNobmFuDQpOb21jb20g Q2hhaXIgMjAxMS0yMDEyDQpFbWFpbDogbm9tY29tLWNoYWlyQGlldGYub3JnLCBzdXJlc2gua3Jp c2huYW5AZXJpY3Nzb24uY29tDQo= ------_=_NextPart_001_01CC3AEE.F069B2C9 Content-Type: text/plain; name="ATT1874148.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1874148.txt Content-Disposition: attachment; filename="ATT1874148.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYtQW5u b3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg== ------_=_NextPart_001_01CC3AEE.F069B2C9-- From bertietf@bwijnen.net Mon Jul 11 02:27:42 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 8019321F8AD6 for ; Mon, 11 Jul 2011 02:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bhfaope49PXr for ; Mon, 11 Jul 2011 02:27:42 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6E21F8AD4 for ; Mon, 11 Jul 2011 02:27:41 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QgCmA-00042C-U0 for netconf@ietf.org; Mon, 11 Jul 2011 11:27:40 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest59.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QgCmA-0007CA-Qd for netconf@ietf.org; Mon, 11 Jul 2011 11:27:38 +0200 Message-ID: <4E1AC20A.6020506@bwijnen.net> Date: Mon, 11 Jul 2011 11:27:38 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: netconf References: <80A0822C5E9A4440A5117C2F4CD36A64024F9B50@DEMUEXC006.nsn-intra.net> In-Reply-To: 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: 86ab03e524994f79ca2c75a176445dd416e498f9bbcc3d88bf9a05cd6c3f4d7b Subject: [Netconf] Congrats with the new RFCs (6241, 6242 and 6243) - now foxus on Access Control 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: Mon, 11 Jul 2011 09:27:42 -0000 I know I am late on this (I was on a 3 week vacation). Congrats to the WG and a special thanks to the editors/authors of the drafts that now became RFCs. Now... let us complete the Access Control Model. Did you (WG participants) all read the latest revision of the documents? We need to finalize though, and it would be good if you all come well prepared to the meeting in Quebec. Bert From kwatsen@juniper.net Tue Jul 12 16:46: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 A984A11E80AB; Tue, 12 Jul 2011 16:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNiuf0-RE+U9; Tue, 12 Jul 2011 16:46:07 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6050C11E80AA; Tue, 12 Jul 2011 16:46:07 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKThzcv2RknzC1DrGm1LRbJ8maljZkydfq@postini.com; Tue, 12 Jul 2011 16:46:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 12 Jul 2011 16:24:20 -0700 From: Kent Watsen To: "netconf@ietf.org" , "opsawg@ietf.org" Date: Tue, 12 Jul 2011 16:24:18 -0700 Thread-Topic: guidance on draft-kwatsen-reverse-ssh Thread-Index: AcxA6tK7l3FOEsmfR0O95XCnacOjbQ== Message-ID: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] guidance on draft-kwatsen-reverse-ssh 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, 12 Jul 2011 23:46:08 -0000 I'm writing this email for guidance on how to move this draft forward. Per recommendation of NETCONF chairs and both the Ops and Security ADs, I h= ave been reviewing draft-kwatsen-reverse-ssh with the SAAG and IETF-SSH lis= ts, who currently review SSH-related RFCs. After about a month of discussi= on, there seems to be four possible solutions (below), each with pros and c= ons. Unfortunately, the SAAG and IETF-SSH lists seem to prefer solutions t= hat I feel are excessively onerous to implement, which puts us into a virtu= al deadlock. Before diving into the four solutions, let me first preface that the desire= to support Reverse SSH is primarily for devices to be able to "call home" = to an NMS that would then manage the device via the NetConf protocol though= , of course, other network management protocols could be tunneled over the = SSH connection as well. This is "important" in that my company has been do= ing this for a number of years now and also because we've received requests= from other WG members to submit a draft for it. =20 And now, without further ado, here are the four possible solutions: 1. out-of-band role-reversal Device initiates a TCP connection to an IANA-assigned port, sends a special SSH-role-reversal message, and then starts the SSH Server protocol (i.e. fork/exec `sshd -i`). From the NMS perspective, upon accepting a connection on the IANA-assigned port, it receives the special SSH-role-reversal message and uses it to fetch credentials from its DB, and then starts the SSH Client protocol (SSH client=20 libraries available in many programming languages). =20 This solution is fully described by the draft-kwatsen-reverse-ssh-00=20 submission. A variant of this solution has been in use at Juniper for ~5 years. It does not require any modification to SSH=20 client/server implementations. If we choose to promote this=20 solution, I recommend modifying the draft slightly to allow the MAC and host-key algorithms to be negotiated *exactly* like the SSH=20 protocol (essentially, merging in the best part of solution #2) I feel this is the best solution because it's simple to implement and interoperable with all SSH implementation we've tried it with. Also, this solution benefits in that, in all cases, the device is always running the SSH server and the NMS is always running the SSH client. This keeps it simple in that how peers identify and authenticate each other is consistent regardless which peer=20 initiates the underlying TCP connection. However, the SAAG and IETF-SSH lists did not like this solution because they felt that the role-reversal should happen in-band to=20 the SSH protocol and also that there was no reason for another IANA-assigned port. As maintainers of the SSH protocol, I can=20 understand why they feel that way, but taking a step back, what's wrong with the role-reversal happening a step before the=20 SSH-protocol starts? 2. out-of-band reversal, but no special ssh-role-reversal message This solution is a lot like the first, but the special role-reversal message is replaced with heavy restrictions on which host-key algorithms are allowed to just those that relay identity as well as authentication (i.e. the x.509 algs from RFC6187 and a new family of algs based on HMAC I defined for the purpose). This solution is fully described by the draft-kwatsen-reverse-ssh-01=20 submission. It requires modification to SSH client/server implementations - so that the server (the device) only advertizes the allowed algorithms and so that they're both aware of the new "hmac-*" family of algorithms. This solution has some pros and cons to the first solution. On the positive side, leveraging the existing MAC and host-key=20 negotiation logic built into the SSH protocol is pretty slick. On the negative side, needing to modify the SSH client/server code support the x.509 and HMAC based keys would take some time and further, restricting which hosts keys can be advertized=20 to just these is somewhat uncomfortable (i.e. no ssh-rsa or=20 ssh-dsa allowed), unlike with solution #1. 3. in-band solution, by allowing the SSH server to open channels In this solution, the device SSHs to the NMS (i.e. device is SSH client and the NMS is the SSH server). The original thinking was that the device would connect to port 22, where the NMS would be running a generic SSH server (i.e. `sshd`), but further analysis suggests that it would be too difficult for the NMS to bind it's business-logic via a subsystem and instead should be a custom server built by linking to an SSH Server library and listening to some port other than 22. This solution would require non-trivial modification of SSH client and server implementations - to enable a server to open channels on the client. As one SAAG member wrote "Frankly, you will probably have a hard time getting upstream OpenSSH to accept patches to=20 implement this or any other approach. They're _very_ conservative about changes." This solutions has pros and cons as well. On the positive side, it's the simplest solution at the RFC level - we only need to remove the SHOULD in RFC4254 section 6.1. On the negative side, this solution may be difficult to implement, would require updating the SSH code on devices, and introduces new challenges in how the peers identify and authenticate each other. Another big negative is that it's unlikely to be supported by OpenSSH because, let's face it, letting a server open channels to a client doesn't sound very secure ;) 4. in-band solution, based on remote port-forwarding This solution again has the device SSH-ing to the NMS, but this=20 time it sets up a remotely forwarded port that the NMS can then use to SSH back to the device on. This solution requires no modification to existing SSH software. It might be OK to use generic `sshd` listening on port 22, since the device only needs to send a signal to the NMS to connect back it on the forwarded-port it opened. The positives of this solution are its simplicity (not even an RFC is required). The negatives are that how peers identify and authenticate each other would have to be solved for both directions. Another negative is that there could be collisions with the=20 remote-ports opened by the devices. And yet another negative=20 is that there would be double encryption, wasting precious CPU cycles on both sides. How to move forward? - first, it would be interesting to get some feedback on the various proposals from the NETCONF and OPSAWG WG members. I realize that above are very high-level descriptions, but hopefully it's enough to get the gist of what's being proposed... - if it turns out that there is significant support for solution #1 (or even #2), then we might be able to take that back to the SAAG and IETF-SSH lists for their reconsideration. Alternatively, perhaps either the OPSAWG or the NETCONF WG would be interested in picking up this I-D? As a last-ditch effort, would it make sense to submit=20 it as an EXPERIMENTAL RFC? - would others who asked for this draft to be submitted even implement an EXPERIMENTAL RFC? Thanks, Kent From j.schoenwaelder@jacobs-university.de Tue Jul 12 21:47:20 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 B9E8321F85CB; Tue, 12 Jul 2011 21:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z05i--VFSeSl; Tue, 12 Jul 2011 21:47:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 39C1C21F8596; Tue, 12 Jul 2011 21:47:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E4D820BFD; Wed, 13 Jul 2011 06:47:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MqnYEH4GeUob; Wed, 13 Jul 2011 06:47:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8273320BE9; Wed, 13 Jul 2011 06:47:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 39D9619E0E58; Wed, 13 Jul 2011 06:47:11 +0200 (CEST) Date: Wed, 13 Jul 2011 06:47:11 +0200 From: Juergen Schoenwaelder To: Kent Watsen , f@elstar.local Message-ID: <20110713044711.GA80654@elstar.local> Mail-Followup-To: Kent Watsen , f@elstar.local, "netconf@ietf.org" , "opsawg@ietf.org" References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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: Wed, 13 Jul 2011 04:47:20 -0000 On Tue, Jul 12, 2011 at 04:24:18PM -0700, Kent Watsen wrote: > And now, without further ado, here are the four possible solutions: [...] > How to move forward? > > - first, it would be interesting to get some feedback on the various > proposals from the NETCONF and OPSAWG WG members. I realize that > above are very high-level descriptions, but hopefully it's enough > to get the gist of what's being proposed... > > - if it turns out that there is significant support for solution #1 > (or even #2), then we might be able to take that back to the SAAG > and IETF-SSH lists for their reconsideration. Alternatively, perhaps > either the OPSAWG or the NETCONF WG would be interested in picking > up this I-D? As a last-ditch effort, would it make sense to submit > it as an EXPERIMENTAL RFC? - would others who asked for this draft > to be submitted even implement an EXPERIMENTAL RFC? There is some history of this discussion in the ISMS working group. When ISMS did SNMP over SSH, we had a hard time dealing with notifications and the Juniper approach was already put on the table at that time as "running code that seems to work in practice to solve an operational problem". As far as I recall, there was no doubt about the operational problem and the need to solve it _but_ there were security concerns brought forward. I would have to do several hours of reading of ISMS archives in order to phrase them correctly. But simply put (as far as I recall - and I don't really recall any details and so I might be totally off), the concern had to do with something not truely authenticated to tell a box to SSH somewhere which involves the usage of identities with cryptographic keys. In ISMS, we ended up making the notification originator the SSH client - and this caused quite some costs since the amount of config increases and the identity to bind access control to becomes different. So in essence, I believe we have been for years at a deadlock situation where operational people were clear that a solution for devices to "call home" is clearly needed but the security people had security concerns with the solutions presented and the solutions liked more by security people to be operationally a pain. Perhaps one path forward is to have the operational people push a solution that is implementable and solves an operational problem (without creating a new operational problem) through the whole IETF process forcing the security people to clearly document their security concerns and then it can be seen whether that text all goes into the Security Considerations and the protocol passes or the document stops at the IESG. This is potentially a painful exercise. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Wed Jul 13 00:42: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 E029121F87A5; Wed, 13 Jul 2011 00:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbjRo03T-qJ6; Wed, 13 Jul 2011 00:42:19 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52921F87A4; Wed, 13 Jul 2011 00:42:19 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qgu5H-0007Ul-D4; Wed, 13 Jul 2011 09:42:16 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qgu5H-0003W5-79; Wed, 13 Jul 2011 09:42:15 +0200 Message-ID: <4E1D4C56.8090307@bwijnen.net> Date: Wed, 13 Jul 2011 09:42:14 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.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: 86ab03e524994f79ca2c75a176445dd40b09c11924f2885c38fdc1155279150c Cc: "opsawg@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] guidance on draft-kwatsen-reverse-ssh 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, 13 Jul 2011 07:42:20 -0000 On 7/13/11 1:24 AM, Kent Watsen wrote: on solution 2: > This solution has some pros and cons to the first solution. On > the positive side, leveraging the existing MAC and host-key > negotiation logic built into the SSH protocol is pretty slick. > On the negative side, needing to modify the SSH client/server > code support the x.509 and HMAC based keys would take some time > and further, restricting which hosts keys can be advertized > to just these is somewhat uncomfortable (i.e. no ssh-rsa or > ssh-dsa allowed), unlike with solution #1. So Kent, do I understand correctly from your email that the SAAG and SSH people prefer solution 2? If so, are they (I guess specifically the SSH guys) willing to work on the spec and then implement this in SSH implementations/products/distributions? Bert From bertietf@bwijnen.net Wed Jul 13 06:07: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 22A0F21F85C7 for ; Wed, 13 Jul 2011 06:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foUqJBoUPd01 for ; Wed, 13 Jul 2011 06:07:29 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 454F111E807C for ; Wed, 13 Jul 2011 06:04:37 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qgz79-0004NW-My for netconf@ietf.org; Wed, 13 Jul 2011 15:04:35 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qgz79-0007m8-DE for netconf@ietf.org; Wed, 13 Jul 2011 15:04:31 +0200 Message-ID: <4E1D97DF.30305@bwijnen.net> Date: Wed, 13 Jul 2011 15:04:31 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1D97A9.2080201@bwijnen.net> In-Reply-To: <4E1D97A9.2080201@bwijnen.net> X-Forwarded-Message-Id: <4E1D97A9.2080201@bwijnen.net> Content-Type: multipart/mixed; boundary="------------000209030303090004010200" 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: 86ab03e524994f79ca2c75a176445dd4dd85975020007591fa465506cde1eb71 Subject: [Netconf] Fwd: Updated NETCONF WG charter 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, 13 Jul 2011 13:07:30 -0000 This is a multi-part message in MIME format. --------------000209030303090004010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, non real technical content change. -------- Original Message -------- Subject: Updated NETCONF WG charter Date: Wed, 13 Jul 2011 15:03:37 +0200 From: Bert (IETF) Wijnen To: iesg-secretary@ietf.org CC: Dan Romascanu , "Ersue, Mehmet (NSN - DE/Munich)" , Ron Bonica Dear secretariat, attached is an updated WG charter for NETCONF as discussed and agreed with Dan Romascanu our AD. The changes are: - it removes some text of completed work - it updates the milestones - it lists our new Security (Tech) Advisor. Thanks, Bert and Mehmet NETCONF WG chairs --------------000209030303090004010200 Content-Type: text/plain; name="netconf-charter-2011-jul-13.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="netconf-charter-2011-jul-13.txt" Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Security Advisor: Tim Polk Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org or: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group has produced a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. - Provides support for asynchronous notifications. The NETCONF protocol has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 2. The NETCONF server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to define suitable notifications. 3. As implementation and deployment experience gained with the NETCONF monitoring data model, the WG may revise the NETCONF monitoring data model to add additional objects that can be used to check the status of the server and to discover additional information about the server implementation. The WG may choose to revise the NETCONF monitoring data model. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis done - rfc4741bis to IESG for consideration as Proposed Standard done - Send rfc4742bis to IESG for consideration as proposed Standard. done - first WG draft (rev 00) on NACM posted done - first WG draft (rev 00) on NETCONF specific YANG modules posted Jul 2011 - WGLC for NACM document Jul 2011 - WGLC for NETCONF specific notifications document Sep 2011 - (if needed last) WGLC for NACM document Sep 2011 - (if needed last) WGLC for NETCONF specific notifications document Okt 2011 - submit NACM document to IESG for consideration as Proposed Standard Okt 2011 - submit NETCONF specific notifications document to IESG for consideration as Proposed Standard --------------000209030303090004010200-- From bertietf@bwijnen.net Wed Jul 13 06:21: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 58ADA11E80CE for ; Wed, 13 Jul 2011 06:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.574 X-Spam-Level: X-Spam-Status: No, score=-99.574 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEj4PiGslSFL for ; Wed, 13 Jul 2011 06:21:31 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id EB5B911E807D for ; Wed, 13 Jul 2011 06:21:29 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1QgzNY-000574-Bu; Wed, 13 Jul 2011 15:21:28 +0200 Message-ID: <2BF207B2E9DF4CCF943F6D320B59D859@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Matjaz Vrecko" References: <80A0822C5E9A4440A5117C2F4CD36A6401E11409@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64021B94BF@DEMUEXC006.nsn-intra.net> <4E0D94E4.1040805@mg-soft.si> In-Reply-To: <4E0D94E4.1040805@mg-soft.si> Date: Wed, 13 Jul 2011 15:19:04 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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 Cc: Netconf Subject: Re: [Netconf] NETCONF Protocol Interoperability Event around QuebecMeeting ? - MG-SOFT's NETCONF and YANG tools 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, 13 Jul 2011 13:21:35 -0000 Matjaz, Sorry for a bit of delay in answering (vacation and such..). Good to see one more implementation. As you may have seen, the interoperability event in Quebec was canceled, because we did not get enough commitments in time in order to make arrangements. That does not mean that people cannot sit together and do some informal interoperability testing. That would be goodness in fact. Will you be in Canada at our meeting? Meanwhile, we have RFCs 6241, 6242 and 6243 published. They are the cleaned up versions and should make it easier for implementing (and checking) interoperable implemntations. Bert and Mehmet ----- Original Message ----- From: "Matjaz Vrecko" To: "Ersue, Mehmet (NSN - DE/Munich)" ; "netconf" ; Cc: Sent: Friday, July 01, 2011 11:35 AM Subject: Re: [Netconf] NETCONF Protocol Interoperability Event around QuebecMeeting ? - MG-SOFT's NETCONF and YANG tools > Hello Mehmet, Bert et all, > > It's July 1st, which was the original scheduled date for the > interoperability tests, so I would like to use the opportunity > and post this brief note to let you know that MG-SOFT has > recently published the RC4 release of our first two NETCONF/YANG > products: NETCONF Browser and Visual YANG Designer. They are > both available from our web site at > http://www.mg-soft.com/download.html?os=java > > Until now, both our products were evaluated and tested mostly by > Tail-F team (thank you very much once again to anyone involved > at Tail-F's side!) and some other selected customers (thank > you to them as well!),... and now we are offering them to anyone > interested for evaluation, interoperability testing and review. > We would appreciate to receive any kind of feedback. > > Thank you and best regards, > Matjaz > > On 19-May-2011 2:57 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Hi All, >> >> it seems there is no sufficient interest on a NETCONF >> Protocol Interoperability Event. Thank you to those few >> guys who send us their comments. >> >> We go into a silent mode now, until we here some concrete >> interest for such an event with the goal to get NETCONF >> documents into draft standard status. >> >> Mehmet& Bert >> >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >>> Behalf Of ext Bert Wijnen (IETF) >>> Sent: Saturday, April 30, 2011 5:17 PM >>> To: netconf >>> Subject: Re: [Netconf] NETCONF Protocol Interoperability Event around >>> QuebecMeeting ? >>> >>> We (WG chairs) made a little mistake. WE did not >>> put a deadline for responsesn. >>> >>> Sofar, we have only had one response (albeit a positive one) >>> to our poll for interest in an interoperability event around the >>> next IETF meeting. >>> >>> If we do not get (at least 2, preferably more) more positive >>> responses by May 10, then we won't have such an event. >>> >>> Your WG chairs. >>> Bert and Mehmet >>> >>> ----- Original Message ----- >>> From: "Ersue, Mehmet (NSN - DE/Munich)" >>> To: "netconf" >>> Cc: "ext Romascanu, Dan (Dan)"; >>> >>> Sent: Sunday, April 03, 2011 9:35 AM >>> Subject: NETCONF Protocol Interoperability Event around Quebec Meeting >>> ? >>> >>> >>> Dear NETCONF WG, >>> >>> in the IETF80 NETCONF session it has been discussed whether a NETCONF >>> protocol interoperability event should be organized to take place >>> around >>> the Quebec meeting. >>> The NETCONF interoperability event would be helpful to get our >> Proposed >>> Standards to the Draft Standard status. >>> >>> The chairs would like to sense of the WG for the level of interest of >>> the implementers on such an interop event. >>> >>> The focus in the interoperability event would be on following RFCs: >>> - draft-ietf-netconf-4741bis (in RFC Ed Queue), >>> - draft-ietf-netconf-rfc4742bis (in RFC Ed Queue), >>> - RFC 5277 - NETCONF Event Notifications, >>> - RFC 6022 - YANG Module for NETCONF Monitoring, >>> - RFC 5717 - Partial Lock RPC for NETCONF, >>> - draft-ietf-netconf-with-defaults (in RFC Ed Queue). >>> >>> >>> The questions we would like to clarify are in the first step: >>> >>> - Who has which implementations ready to test by July 1st, 2011? >>> - Who would come with implementations and participate if the event >>> gets >>> organised? >>> - Who can provide content for testing (i.e. YANG modules e.g. >>> Monitoring)? >>> - Who would be willing to prepare test cases? >>> >>> Please state your interest and opinion on the interop event to the >>> chairs directly. >>> >>> Mehmet& Bert >>> >>> >>> _______________________________________________ >>> 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 > > -- > Matjaz Vrecko > MG-SOFT Corporation, Strma ulica 8, SI-2000 Maribor, Slovenia > Internet: http://www.mg-soft.si/ E-mail: > Phone: +386 2 2506565, Fax: +386 2 2506566 From mehmet.ersue@nsn.com Wed Jul 13 07:38: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 EFF7F21F89A3 for ; Wed, 13 Jul 2011 07:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.092 X-Spam-Level: X-Spam-Status: No, score=-105.092 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9fe3-ugmD0h for ; Wed, 13 Jul 2011 07:38:43 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 936B321F899D for ; Wed, 13 Jul 2011 07:38:43 -0700 (PDT) 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 p6DEcgbx008200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Jul 2011 16:38:42 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6DEcftZ028320 for ; Wed, 13 Jul 2011 16:38:42 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 16:38:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2011 16:38:27 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64025F262F@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft NETCONF Session Agenda for IETF 81 Thread-Index: AcxBaoaAFCwedXebQ3SVxVxVLYTe7g== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 13 Jul 2011 14:38:33.0131 (UTC) FILETIME=[8A67F7B0:01CC416A] Subject: [Netconf] Draft NETCONF Session Agenda for IETF 81 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, 13 Jul 2011 14:38:48 -0000 Hi All, please find below the draft agenda for the NETCONF session at IETF 81. http://www.ietf.org/proceedings/81/agenda/netconf.txt=20 Please send us your comments by July 18, 2011. Mehmet & Bert From bertietf@bwijnen.net Wed Jul 13 07:53: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 5818B21F8804 for ; Wed, 13 Jul 2011 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf4OJp6BtIy3 for ; Wed, 13 Jul 2011 07:53:23 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 81C3921F857D for ; Wed, 13 Jul 2011 07:53:23 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qh0oT-0007Bh-I2 for netconf@ietf.org; Wed, 13 Jul 2011 16:53:22 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qh0oT-00072J-DF for netconf@ietf.org; Wed, 13 Jul 2011 16:53:21 +0200 Message-ID: <4E1DB161.2060707@bwijnen.net> Date: Wed, 13 Jul 2011 16:53:21 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf 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: 86ab03e524994f79ca2c75a176445dd419e1e301261b645982d691a295fede6e Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.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, 13 Jul 2011 14:53:24 -0000 Dear WG participants, This document was published mid-June, and we have not had much comments sofar. So we conclude it must be ready for WG Last Call. This is a formal WG Last call for draft-ietf-netconf-system-notifications-04.txt Please review and send any comments BEFORE August 1. Best would be if you can send it BEFORE July 24, so that we can discuss any open issues during our Netconf session at IETF81 in Quebec. Bert and Mehmet From bertietf@bwijnen.net Wed Jul 13 07:53:28 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 C479521F8870 for ; Wed, 13 Jul 2011 07:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlTm22YnhnQU for ; Wed, 13 Jul 2011 07:53:28 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 1107121F886C for ; Wed, 13 Jul 2011 07:53:28 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qh0oX-0003mg-83 for netconf@ietf.org; Wed, 13 Jul 2011 16:53:27 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qh0oX-00072X-3s for netconf@ietf.org; Wed, 13 Jul 2011 16:53:25 +0200 Message-ID: <4E1DB164.5090007@bwijnen.net> Date: Wed, 13 Jul 2011 16:53:24 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf 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: 86ab03e524994f79ca2c75a176445dd41bc7012d8c956210f214dd8874f4a2df Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control-04.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, 13 Jul 2011 14:53:28 -0000 Dear WG participants, This document was published mid-June, and we have not had much comments sofar. So we conclude it must be ready for WG Last Call. This is a formal WG Last call for draft-ietf-netconf-access-control-04.txt Please review and send any comments BEFORE August 1. Best would be if you can send it BEFORE July 24, so that we can discuss any open issues during our Netconf session at IETF81 in Quebec. Bert and Mehmet From kwatsen@juniper.net Wed Jul 13 12:10:29 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 6579921F863A; Wed, 13 Jul 2011 12:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws+gaPFQsUkN; Wed, 13 Jul 2011 12:10:25 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id B0C0221F8B45; Wed, 13 Jul 2011 12:10:17 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTh3tkn5jqaC736dHA+6cgw6qCz+z41Vk@postini.com; Wed, 13 Jul 2011 12:10:23 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 13 Jul 2011 12:08:54 -0700 From: Kent Watsen To: "Bert (IETF) Wijnen" Date: Wed, 13 Jul 2011 12:08:53 -0700 Thread-Topic: [Netconf] guidance on draft-kwatsen-reverse-ssh Thread-Index: AcxBMGXEAtBJWpEuRXWBb7JvV/wdEwAVs/Rw Message-ID: <84600D05C20FF943918238042D7670FD3E8429F92B@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> <4E1D4C56.8090307@bwijnen.net> In-Reply-To: <4E1D4C56.8090307@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] guidance on draft-kwatsen-reverse-ssh 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, 13 Jul 2011 19:10:29 -0000 > So Kent, do I understand correctly from your email that the > SAAG and SSH people prefer solution 2? Not as the -01 draft is written, which maps to solution #2, but it might be= more palatable to them if we tweak the SSH handshake so that the device (t= he SSH client) indicates that it wants a role-reversal. as it's written no= w, the server MUST listen on a port other than 22, with this change, it MAY= listen on port 22. =20 I've resisted this solution since it would require non-trivial modification= to the various SSH client/server implementations. The current -01 draft c= ould be implemented with just minor tuning - to advertize support for the x= .509 and HMAC based host-keys... > If so, are they (I guess specifically the SSH guys) willing to work on th= e > spec and then implement this in SSH implementations/products/distribution= s? They are willing to work on the RFC, but they have no influence over implem= entations, specifically OpenSSH. Case in point, they recently standardized= x.509 host-keys (RFC 6187), but OpenSSH just released its own non-x.509 ba= sed solution (http://lwn.net/Articles/377703/)... Thanks, Kent From kwatsen@juniper.net Wed Jul 13 12:47:41 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 D441A11E8115; Wed, 13 Jul 2011 12:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxayTTzAY-Lj; Wed, 13 Jul 2011 12:47:41 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 10E8F11E80BE; Wed, 13 Jul 2011 12:47:41 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTh32WpBPlm5vRujmtINpZN7y6bsp0VL0@postini.com; Wed, 13 Jul 2011 12:47:41 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 13 Jul 2011 12:26:15 -0700 From: Kent Watsen To: Juergen Schoenwaelder , "f@elstar.local" Date: Wed, 13 Jul 2011 12:26:13 -0700 Thread-Topic: [OPSAWG] guidance on draft-kwatsen-reverse-ssh Thread-Index: AcxBF/FkbqvUHA6ISYKp5j4aUVsh9AAeGTeg Message-ID: <84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> <20110713044711.GA80654@elstar.local> In-Reply-To: <20110713044711.GA80654@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 13 Jul 2011 19:47:41 -0000 > There is some history of this discussion in the ISMS working group. > When ISMS did SNMP over SSH, we had a hard time dealing with > notifications and the Juniper approach was already put on the table at > that time as "running code that seems to work in practice to solve an > operational problem". As far as I recall, there was no doubt about the > operational problem and the need to solve it _but_ there were security > concerns brought forward. I would have to do several hours of reading > of ISMS archives in order to phrase them correctly. But simply put (as > far as I recall - and I don't really recall any details and so I might > be totally off), the concern had to do with something not truely > authenticated to tell a box to SSH somewhere which involves the usage > of identities with cryptographic keys. In ISMS, we ended up making the > notification originator the SSH client - and this caused quite some > costs since the amount of config increases and the identity to bind > access control to becomes different. As a security person myself, I'm fairly confident that the "Juniper approac= h" is OK. We've also had numerous security folks look at it as well as the= US government (it's FIPS certified) and Tier-1 SPs... The only security issue raised so far by the SAAG and IETF-SSH lists was re= garding the new HMAC family of host-key algorithms defined in the -01 draft= . By nature, it requires a symmetric key and they didn't see how a symmetr= ic-key could be provided in a first-time "call-home" scenario. Of course, = the symmetric key can be provided to the device, either keyed in or read of= f a USB pen-drive... > So in essence, I believe we have been for years at a deadlock > situation where operational people were clear that a solution for > devices to "call home" is clearly needed but the security people had > security concerns with the solutions presented and the solutions liked > more by security people to be operationally a pain.=20 Exactly. > Perhaps one path forward is to have the operational people push a > solution that is implementable and solves an operational problem > (without creating a new operational problem) through the whole IETF > process forcing the security people to clearly document their security > concerns and then it can be seen whether that text all goes into the > Security Considerations and the protocol passes or the document stops > at the IESG. This is potentially a painful exercise. As painful as it may be, I think this is our best-case scenario. We could = push it forward as an independent submission (EXPERIMENTAL?), but it would = be much better if either the NETCONF and OPSAWG WGs could sponsor it. Pers= onally, I still agree that it's not NETCONF-specific and hence not for the = NETCONF WG, but it makes sense for OPSAWG, if the WG agrees... Thanks, Kent From kwatsen@juniper.net Wed Jul 13 15:32:59 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 5397311E81C4 for ; Wed, 13 Jul 2011 15:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HMweJ3S+vzG for ; Wed, 13 Jul 2011 15:32:58 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id A44B711E8075 for ; Wed, 13 Jul 2011 15:32:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTh4dGLF81kZkuCZqXQb2V++EmQabu0cC@postini.com; Wed, 13 Jul 2011 15:32:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 13 Jul 2011 15:32:21 -0700 From: Kent Watsen To: "Bert (IETF) Wijnen" , netconf Date: Wed, 13 Jul 2011 15:32:18 -0700 Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt Thread-Index: AcxBbKi/eSO0BRL+TkKfStzm3NoUnQAKCEKg Message-ID: <84600D05C20FF943918238042D7670FD3E8429FC1A@EMBX01-HQ.jnpr.net> References: <4E1DB161.2060707@bwijnen.net> In-Reply-To: <4E1DB161.2060707@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.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, 13 Jul 2011 22:32:59 -0000 Comments: Now that we've renamed it to "NetConf Base Notifications", should we s/draf= t-ietf-netconf-system-notifications-04.txt/draft-ietf-netconf-base-notifica= tions-04.txt/? - does it matter once it becomes an RFC? Now that 4741bis is out, we should replace references to it with "RFC 6241" Why does the " changed-by "container have "case by-user" when it's already = in a "choice" statement. Alternatively, do we need to add a "case by-serve= r" statement? Why set the numerical value for the "termination-reason" and "confirm-event= " enumerations? - since the values provided are exactly the default values= ... Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Bert (IETF) Wijnen Sent: Wednesday, July 13, 2011 10:53 AM To: netconf Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications= -04.txt Dear WG participants, This document was published mid-June, and we have not had much comments sofar. So we conclude it must be ready for WG Last Call. This is a formal WG Last call for draft-ietf-netconf-system-notifications-0= 4.txt Please review and send any comments BEFORE August 1. Best would be if you can send it BEFORE July 24, so that we can discuss any open issues during our Netconf session at IETF81 in Quebec. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From biermana@Brocade.com Wed Jul 13 15:47: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 CDEFB11E81C4 for ; Wed, 13 Jul 2011 15:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8esFR6zuXE0G for ; Wed, 13 Jul 2011 15:47:30 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC9E11E8075 for ; Wed, 13 Jul 2011 15:47:30 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p6DMlRvn017372; Wed, 13 Jul 2011 15:47:27 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id xhh888467-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jul 2011 15:47:27 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 15:52:16 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 13 Jul 2011 15:47:26 -0700 From: Andy Bierman To: Kent Watsen , "Bert (IETF) Wijnen" , netconf Date: Wed, 13 Jul 2011 15:47:25 -0700 Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt Thread-Index: AcxBbKi/eSO0BRL+TkKfStzm3NoUnQAKCEKgAAYUDoA= Message-ID: References: <4E1DB161.2060707@bwijnen.net> <84600D05C20FF943918238042D7670FD3E8429FC1A@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E8429FC1A@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-13_08:2011-07-14, 2011-07-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107130182 Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.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, 13 Jul 2011 22:47:30 -0000 see inline -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Wednesday, July 13, 2011 3:32 PM To: Bert (IETF) Wijnen; netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notificat= ions-04.txt Comments: Now that we've renamed it to "NetConf Base Notifications", should we s/draf= t-ietf-netconf-system-notifications-04.txt/draft-ietf-netconf-base-notifica= tions-04.txt/? - does it matter once it becomes an RFC? [ab: no -- the draft stays the same until published as RFC. The draft name is not important.] Now that 4741bis is out, we should replace references to it with "RFC 6241" [ab: sure] Why does the " changed-by "container have "case by-user" when it's already = in a "choice" statement. Alternatively, do we need to add a "case by-serve= r" statement? The uses-stmt is not [ab: leaf server is the by-server case. I suppose 'uses common-session-par= ms' can be the case-stmt and case by-user is redundant. It doesn't hurt anything to h= ave the case label.] Why set the numerical value for the "termination-reason" and "confirm-event= " enumerations? - since the values provided are exactly the default values= ... [ab: the enum values can be removed.] Thanks, Kent Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Bert (IETF) Wijnen Sent: Wednesday, July 13, 2011 10:53 AM To: netconf Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications= -04.txt Dear WG participants, This document was published mid-June, and we have not had much comments sofar. So we conclude it must be ready for WG Last Call. This is a formal WG Last call for draft-ietf-netconf-system-notifications-0= 4.txt Please review and send any comments BEFORE August 1. Best would be if you can send it BEFORE July 24, so that we can discuss any open issues during our Netconf session at IETF81 in Quebec. Bert and Mehmet _______________________________________________ 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 From dromasca@avaya.com Wed Jul 13 22:00:55 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 A129D11E8146 for ; Wed, 13 Jul 2011 22:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-5NClAUqEEH for ; Wed, 13 Jul 2011 22:00:55 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1811E810E for ; Wed, 13 Jul 2011 22:00:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAM92Hk7GmAcF/2dsb2JhbABTmBKPPneubgKbRYVbXwSYAYs1 X-IronPort-AV: E=Sophos;i="4.65,527,1304308800"; d="scan'208";a="256504212" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jul 2011 01:00:53 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jul 2011 00:59:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 07:00:50 +0200 Message-ID: In-Reply-To: <84600D05C20FF943918238042D7670FD3E8429FC1A@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt Thread-Index: AcxBbKi/eSO0BRL+TkKfStzm3NoUnQAKCEKgABN34cA= References: <4E1DB161.2060707@bwijnen.net> <84600D05C20FF943918238042D7670FD3E8429FC1A@EMBX01-HQ.jnpr.net> From: "Romascanu, Dan (Dan)" To: "Kent Watsen" , "Bert (IETF) Wijnen" , "netconf" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.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: Thu, 14 Jul 2011 05:00:55 -0000 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Kent Watsen > Sent: Thursday, July 14, 2011 1:32 AM > To: Bert (IETF) Wijnen; netconf > Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system- > notifications-04.txt >=20 >=20 > Comments: >=20 > Now that we've renamed it to "NetConf Base Notifications", should we > s/draft-ietf-netconf-system-notifications-04.txt/draft-ietf-netconf- > base-notifications-04.txt/? - does it matter once it becomes an RFC? >=20 [[DR]] No, it does not matter, and please do not do it as a change of name of the document implies resetting the numbering also to 00, and makes tracking the history more difficult.=20 Regards, Dan From bertietf@bwijnen.net Fri Jul 15 02:31: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 EBCE021F8658 for ; Fri, 15 Jul 2011 02:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVjraaC0U85v for ; Fri, 15 Jul 2011 02:31:24 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 3B48221F85FF for ; Fri, 15 Jul 2011 02:31:21 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qhejt-0000Cw-RQ for netconf@ietf.org; Fri, 15 Jul 2011 11:31:19 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest59.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qhejt-0003os-O9 for netconf@ietf.org; Fri, 15 Jul 2011 11:31:17 +0200 Message-ID: <4E2008E5.4030609@bwijnen.net> Date: Fri, 15 Jul 2011 11:31:17 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1DB161.2060707@bwijnen.net> In-Reply-To: <4E1DB161.2060707@bwijnen.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: 86ab03e524994f79ca2c75a176445dd486638e70dc58bf5f2f1265014c149297 Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.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, 15 Jul 2011 09:31:25 -0000 I did review this document. Looks pretty good to me. I'd like to have some answers/explanations to y comments and I think we can improve consistency a tid-bit. Here are my comments/questions: - replace references to 4741is with ref to rfc6241 - replace references to RFC4741 and RFC4742 with references to RFC6241 and RFC6242 This is in the "security Considerations" section. Sounds like I need to update the template as well. - RFC6242 then needs to be added to )I think normative) references list - I see in sect 2.1: A server MAY report events for non-NETCONF management sessions, using the 'session-id' value of zero. I tried to find how/where it "session-id" and possible contents in a notification are defined/specified. It seems the only place is in the YANG module, right? Anyways, It seems from sect 2.1 (and the YANG module) that for NETCONF management sessions a session-id MUST(?) be reported in the notification. So I then wonder when reading section 2.1.1: netconf-capability-change: Generated when the NETCONF server detects that the server capabilities have changed. Indicates which capabilities have been added, deleted, and/or modified. How does a capability change occur? Is that though some protocol operation over some session (so we have a session-id), or does that happen in a different way, so that the session-id=0 ?? Or is there nos session-id in that case (but session-id has "mandarory true") ?? MMmm maybe the text in sect 2.1 and 2.1.1 confuses me. Because when I read the YANG module, then I think I see that if it is a server internal event, that we do have the leaf "server" present and if changed by a user/session, then we have the common-session-parms present. Did I get that right? Were other people similarly confused? Is this all clear to the novice reader (we need to focus on YANG module readers, right?) - I am somehwat surprised by: notification netconf-session-end { description "Generated when a NETCONF server detects that a NETCONF session has terminated. A server MAY optionally generate this event for non-NETCONF management sessions. Indicates the identity of the user that owned the session, and why the session was terminated."; Same for netconf-session-start How should I interpret "netconf-session-end" for a non-NETCONF session? Consistency related notes/remarks: - I see: The following terms are defined in [I-D.ietf-netconf-4741bis]: o client o datastore o operation o server Actually, RFC6241 defines "protocol operation" and not "operation". Maybe it is better to be consistent. - I see: 2.1. Overview The YANG module defined within this document specifies a small number of notification event messages for use within the 'NETCONF' stream, in rfc5277 I see the phrases "event notification match" and "Sending Event Notifications"... It seems that maybe we better speak of "event notification messages"? But maybe that is just me? Bert (speaking as technical contributor) From bertietf@bwijnen.net Fri Jul 15 06:14:13 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 1805D21F85C0 for ; Fri, 15 Jul 2011 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g3Om1sXTrD6 for ; Fri, 15 Jul 2011 06:14:12 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id B42E821F84FB for ; Fri, 15 Jul 2011 06:14:10 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QhiDT-0004za-NM for netconf@ietf.org; Fri, 15 Jul 2011 15:14:08 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest59.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QhiDT-0006XT-IT for netconf@ietf.org; Fri, 15 Jul 2011 15:14:03 +0200 Message-ID: <4E203D1B.8020109@bwijnen.net> Date: Fri, 15 Jul 2011 15:14:03 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1DB164.5090007@bwijnen.net> In-Reply-To: <4E1DB164.5090007@bwijnen.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: 86ab03e524994f79ca2c75a176445dd4e91041af1577e2e1ea536606f0389906 Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-access-control-04.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, 15 Jul 2011 13:14:13 -0000 I did review this document Here are my comments/questions: - replace references to rfc4741bis with references to rfc6241. - replace references to rfc4742bis with references to rfc6242. - Sect 2. Remove editors note or make some real text out of it. -Sect 2.4.3, page 9 [Editor's note: ditto for "replace" (and copy-config...) Note that with this rule, a client w/o read access can guess db content by sending merge requests - if access-denied is not returned, it means the db has that value.] So the info about replace and copy-config is text that I would make part of the text here. The latter part (about guessing without having read access) should go in (maybe already is) in the Security Considerations section. But I wonder then, why would we not require read access for these cases? If we do, then the guessing can be controlled, no? - at the end of sect 2,7: Existing mechanisms can be used to identify the subtree(s) for this purpose. May I ask "which existing mechanisms" ?? - section 2.8 I wonder if the title "Identifying Security Holes" and phrases like "..security holes introduced by a new YANG module." are the proper language. I guess we mean something aka "security sensitive objects" or some such ?? no? I suspect "security holes" may trigger the wrong reactions from security folk who will review our document. We want to "protect (by default)" such "security sensitive objects" instead of we want to "close security holes". I think I would state in this sec 2.8, that the "extension secure" is defined in the YANG module to address this. - second bullet on page 17: If the configuration datastore or conceptual state data is accessed by the protocol operation, then the data node access MUST be authorized. If the session is authorized to perform the requested operation on the requested data, then processing continues. "then the data node access MUST be authorized" ?? Do you mean "then the session MUST have authorization to read the data node" ? or maybe "then access to the data node MUST be authorized"? - at the end of sect 3.1.3 (page 17) should thee not be a bullet that the data nodes present in the notification must be checked to make sure that the subscriber has read access? Mmm, not sure. From pge 27 I get the impression that if an event-type is authorized then automagically also all included data is accessible? I guess this change in thinking was made without me noticing? Can you explain why that works? - section 3.2.4 The same access permissions MUST stay in effect for the processing of a particular message. I think you mean "a whole" or "a single" message or "a complete". That is not very clear from the term "particular message". But it may be my non-native Englisg that causes just confusion with me - sect 3.2.4 The server MUST use the access control rules in effect at the time the message is processed. Would it be clearer (assuming that is what you intend) to say: The server MUST use the access control rules in effect at the time it starts processing the message. It may be just me who find that clearer. - sect 3.3.1 Upon the very first start-up of the NETCONF server, the access control configuration will probably not be present. If it isn't, a server MUST NOT allow any write access to any session role except a "recovery session", if supported. So if a "recovery session" is not supported, must a server than allow access or not? And if yes, what kind of access to whom? Would be a big security issue, no? - page 23: 7. For each rule-list entry found, process all rules, in order, What is "in order". I guess I am also somehwat confused by the YANG module stating: list rule-list { key "name"; ordered-by user; Maybe I am not fully getting the structure here. - Same question on "in order" on page 24, point 6. - Same for point 6 on page 27. - Page 27 2. If the session is identified as a "recovery session", then the notification is permitted. I wonder if (in recovery mode or recover session) you need to be able to receive notifications??? I can live with it... but if the purpose is really recovery, then maybe we should provide this functionality in recovery mode? Consistency and clarfying questions/related remarks: - The concept of a "recovery session" is mentioned a few times and it is stated that it is outside the scope of this document. I suppose that also means that it is "implementation dependent" or "an implementation matter". I think it would be good to state so explicitly, otherwise I suspect we may get questions if/how/where/when it is defined/specified. - this document speaks about "NETCONF datastore". I believe that rfc6241 speaks about just "datastore" in a few places and mostly speaks about "configuration datastore". Should we be consistent and use "configuration datastore"? Or is there special meaning for "NETCONF datastore"?? - it seems to me that figure 2 uses different terminology than figure 1. fig 1 speaks about an acc ctl point for "operations" while figure 2 seems to identify that control point with "rpc access control". I suggest to take a close look at both figures and try to use as much as possible consistent terminology. Same for page 16 and subsequent pages. "RPC operation" is a term we did away with a while ago I believe. Also check sect 3.3.4 for consistency in terminology and names of acc ctl points - section 3.2.4 speaks about "server data". Is that the "conceptual configuration data store" or what? I prefer we use terms that we already have. If we must use the term "server data", then pls define it in the terminology section - page 28 leaf would a better name not be: leaf Bert (speaking as a technical contributor) From bertietf@bwijnen.net Sat Jul 16 05:02:28 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 BA1BF21F85E5 for ; Sat, 16 Jul 2011 05:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGfnOSfGnNGR for ; Sat, 16 Jul 2011 05:02:28 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 556E821F85E0 for ; Sat, 16 Jul 2011 05:02:25 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qi3ZZ-0002ja-F5 for netconf@ietf.org; Sat, 16 Jul 2011 14:02:22 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qi3ZZ-0004Fd-3q for netconf@ietf.org; Sat, 16 Jul 2011 14:02:17 +0200 Message-ID: <4E217DCB.70101@bwijnen.net> Date: Sat, 16 Jul 2011 14:02:19 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------060706070103010701090700" 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: 86ab03e524994f79ca2c75a176445dd4be6d26073b7294bcef9b59539ec4c7b9 Subject: [Netconf] Fwd: IETF 81 Audio Streaming 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, 16 Jul 2011 12:02:28 -0000 This is a multi-part message in MIME format. --------------060706070103010701090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI for those who may not be on the ietf list Bert -------- Original Message -------- Subject: IETF 81 Audio Streaming Date: Fri, 15 Jul 2011 14:52:47 -0700 From: Nick Kukich To: ietf@ietf.org Greetings! We're two weeks out from the beginning of meeting streaming. For those interested in monitoring sessions or participating remotely the following information may prove useful. - -Audio Streaming- All 8 parallel tracks at the IETF 81 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 25, 2011 at 0900 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT. Because we have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording or observation is not occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule are best retrieved from the IETF tools agenda, which as per Standard operating procedure will be located here: http://tools.ietf.org/agenda/81/ - -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html or click on the Jabber links in the tools team agenda once you have a properly configured jabber/xmpp messaging client. - -Webex- Webex screen sharing participation is possible for a limited number of sessions. Consult with your working-group chair or the secretariat for more information. - -Ticketing- For prompt access to the meeting trouble desk, the email address is: mtd@ietf.org For streaming related issues please send email to ietf-streaming@verilan.com with info including the current time and affected streaming channel. Regards, Nick Kukich Network Engineer Verilan Event Services, Inc. 503.710.5115 --------------060706070103010701090700 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --------------060706070103010701090700-- From SEANG@amdocs.com Mon Jul 18 06:39: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 E058D21F8B15 for ; Mon, 18 Jul 2011 06:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mm8isYDRbRH for ; Mon, 18 Jul 2011 06:38:56 -0700 (PDT) Received: from isomail2.amdocs.com (isomail2.amdocs.com [193.43.244.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE7921F8AF2 for ; Mon, 18 Jul 2011 06:38:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by isomail1.amdocs.com (Postfix) with SMTP id 87948885F2; Mon, 18 Jul 2011 16:38:55 +0300 (IDT) Received: from ilhodmailfe2.corp.amdocs.com (unknown [10.236.20.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by isomail2.amdocs.com (Postfix) with ESMTPS id B32B688399 for ; Mon, 18 Jul 2011 16:38:49 +0300 (IDT) Received: from ILHODMAIL1.corp.amdocs.com ([10.236.20.104]) by ilhodmailfe2.corp.amdocs.com ([10.236.20.101]) with mapi; Mon, 18 Jul 2011 16:38:31 +0300 From: Sean Gillings To: "netconf@ietf.org" Date: Mon, 18 Jul 2011 16:38:30 +0300 Thread-Topic: Most used transport protocol for NETCONF Thread-Index: AcxFT0InkGHK5sYcS+WyP/WxqDttnw== Message-ID: <95386E877461454481D1E5F9C2A2B6F113C4A4E154@ILHODMAIL1.corp.amdocs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] Most used transport protocol for NETCONF 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: Mon, 18 Jul 2011 13:40:51 -0000 RFC4741=20lists=20BEEP,=20SSH,=20SSL=20&=20Console=20as=20permitted=20tra= nsport=20protocols=20for=20NETCONF=20format=20XML=20messages=20over=20a= =20CLI=20interface.=20=20Has=20anyone=20collected=20statistics=20concerni= ng=20which=20is=20the=20most=20popular=20protocol=20in=20use=20currently?= =20=20If=20so=20can=20you=20please=20post=20results=20in=20this=20thread= =20or=20reply=20with=20thread=20&/or=20URL=20where=20such=20data=20can=20= be=20found? S=E9an=20[Amdocs=20OSS=20Division] Senior=20Software=20Design=20Architect=20(Activation) This=20message=20and=20the=20information=20contained=20herein=20is=20prop= rietary=20and=20confidential=20and=20subject=20to=20the=20Amdocs=20policy= =20statement, you=20may=20review=20at=20http://www.amdocs.com/email_disclaimer.asp From mbj@tail-f.com Mon Jul 18 06:56:03 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 0711A21F8B98 for ; Mon, 18 Jul 2011 06:56:03 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y9+VKGjrPsS for ; Mon, 18 Jul 2011 06:56:02 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7384A21F8BAF for ; Mon, 18 Jul 2011 06:56:02 -0700 (PDT) Received: from localhost (213-65-184-200-no181.tbcn.telia.com [213.65.184.200]) by mail.tail-f.com (Postfix) with ESMTPSA id 6EA511200AC0; Mon, 18 Jul 2011 15:55:12 +0200 (CEST) Date: Mon, 18 Jul 2011 15:55:56 +0200 (CEST) Message-Id: <20110718.155556.320751918.mbj@tail-f.com> To: SEANG@amdocs.com From: Martin Bjorklund In-Reply-To: <95386E877461454481D1E5F9C2A2B6F113C4A4E154@ILHODMAIL1.corp.amdocs.com> References: <95386E877461454481D1E5F9C2A2B6F113C4A4E154@ILHODMAIL1.corp.amdocs.com> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Most used transport protocol for NETCONF 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: Mon, 18 Jul 2011 13:56:03 -0000 Hi, Sean Gillings wrote: > RFC4741 lists BEEP, SSH, SSL & Console as permitted transport protocols for > NETCONF format XML messages over a CLI interface. Has anyone collected > statistics concerning which is the most popular protocol in use currently? If > so can you please post results in this thread or reply with thread &/or URL > where such data can be found? The short answer: SSH. Note the listing you refer to in 4741 is just an example. NETCONF can run on any transport for which there is a mapping. Also note that RFC 6241, which obsoletes 4741, has an updated example where 'console' is removed. SSH is mandatory, and most (all?) open source and commercial stacks supports only SSH out of the box. This said, I think there are some vendors that also support BEEP or SOAP/HTTP/TLS. Also note that current devices uses the SSH mapping defined in RFC 4742, but this RFC was obsoleted by 6242, which defines a new SSH framing protocol. /martin From bertietf@bwijnen.net Mon Jul 18 06:56: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 E557C21F8BD1 for ; Mon, 18 Jul 2011 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgTfpamaqqqX for ; Mon, 18 Jul 2011 06:56:07 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id E8CD121F8B98 for ; Mon, 18 Jul 2011 06:56:06 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QioIl-0005IJ-34; Mon, 18 Jul 2011 15:56:05 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest59.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QioIk-00016H-JN; Mon, 18 Jul 2011 15:56:02 +0200 Message-ID: <4E243B72.9010902@bwijnen.net> Date: Mon, 18 Jul 2011 15:56:02 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Sean Gillings References: <95386E877461454481D1E5F9C2A2B6F113C4A4E154@ILHODMAIL1.corp.amdocs.com> In-Reply-To: <95386E877461454481D1E5F9C2A2B6F113C4A4E154@ILHODMAIL1.corp.amdocs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: 86ab03e524994f79ca2c75a176445dd417305305d88d70505153197c3c3d7dc0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Most used transport protocol for NETCONF 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: Mon, 18 Jul 2011 13:56:08 -0000 First, Pls note that RFC4741 was recently obsoleted by RFC6241. I can only guess. But since SSH is the (only) mandatory transport protocol that MUST be supported my guess would be that it is SSH. Those who actually do use NETCONF, pls feel free to let us know on the NETCONF WG mailing list which of the trasports you actually use.. Bert On 7/18/11 3:38 PM, Sean Gillings wrote: > RFC4741 lists BEEP, SSH, SSL& Console as permitted transport protocols for NETCONF format XML messages over a CLI interface. Has anyone collected statistics concerning which is the most popular protocol in use currently? If so can you please post results in this thread or reply with thread&/or URL where such data can be found? > > Séan [Amdocs OSS Division] > Senior Software Design Architect (Activation) > > This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, > you may review at http://www.amdocs.com/email_disclaimer.asp > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From ramu.n@huawei.com Mon Jul 18 19:21:34 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 3D38721F8550 for ; Mon, 18 Jul 2011 19:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v68v4VNbqcRs for ; Mon, 18 Jul 2011 19:21:33 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 634C621F8520 for ; Mon, 18 Jul 2011 19:21:33 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOK003VQ6GO34@szxga05-in.huawei.com> for netconf@ietf.org; Tue, 19 Jul 2011 10:19:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOK00FK06GNNW@szxga05-in.huawei.com> for netconf@ietf.org; Tue, 19 Jul 2011 10:19:36 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACI68530; Tue, 19 Jul 2011 10:19:35 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Jul 2011 10:19:31 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.158]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Tue, 19 Jul 2011 10:19:34 +0800 Date: Tue, 19 Jul 2011 02:19:33 +0000 From: Ramu n X-Originating-IP: [10.18.1.38] To: "netconf@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zeF9UZGQQpkMat3nqG+6gQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: regarding string data-type restrictions while configuring through Netconf Thread-index: AQHMRbpMU5gNtyZ7uUa0N+u1w+5i3g== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [Netconf] regarding string data-type restrictions while configuring through Netconf 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, 19 Jul 2011 02:21:34 -0000 --Boundary_(ID_zeF9UZGQQpkMat3nqG+6gQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, In operation, for string data-type fields can contain some special characters like tab(\t), ? these type of characters are used for help inforamtion in Command Line, So in Command Line these special characters are not allowed as part of string value. Example: ????????????? Please suggest, Is there any limitaions on string data-type while configuring through Netconf. Regards, Ramu N *************************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_zeF9UZGQQpkMat3nqG+6gQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi,

 

In <edit-config&g= t; operation, for string data-type fields can contain some special characte= rs like tab(\t), ?

these type of characters are used for help inforamtion in Command L= ine, So in Command Line these special characters are not allowed as part of= string value.

 

Example:

<r=
pc message-id=3D"101"
      &nbs=
p;   xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"&=
gt;
       <edit-config>
 &n=
bsp;       <target>
  &nbs=
p;        <running/>
 &nbs=
p;       </target>
   =
;      <config>
    &=
nbsp;      <top xmlns=3D"http://example.com/schema/1.2/config&qu=
ot;>
          &nbs=
p;  <interface>
       &nb=
sp;       <name>?????????????</name&=
gt;
           &n=
bsp;   <mtu></mtu>
     &=
nbsp;       </interface>
  =
;         </top>
 &nb=
sp;       </config>
  &nbs=
p;    </edit-config>
     </=
rpc>

Please suggest, Is there any limitaions on string data-type while config= uring through Netconf.

 

Regards,

Ramu N
***************************************************************************= ************
 
            This e-m= ail and attachments contain confidential information from HUAWEI, which is = intended only for the person or entity whose address is listed above. Any u= se of the information contained herein in any way (including, but not limit= ed to, total or partial disclosure, reproduction, or dissemination) by persons other th= an the intended recipient's) is prohibited. If you receive this e-mail in e= rror, please notify the sender by phone or email immediately and delete it!=

--Boundary_(ID_zeF9UZGQQpkMat3nqG+6gQ)-- From j.schoenwaelder@jacobs-university.de Mon Jul 18 23:07:43 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 9484021F86A5 for ; Mon, 18 Jul 2011 23:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYCSRC27QwBI for ; Mon, 18 Jul 2011 23:07:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4403621F86A6 for ; Mon, 18 Jul 2011 23:07:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C3D420BDE; Tue, 19 Jul 2011 08:07:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id huD8d3f3Z0Rz; Tue, 19 Jul 2011 08:07:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE3FA20BDD; Tue, 19 Jul 2011 08:07:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0C7851A0DE5F; Tue, 19 Jul 2011 08:07:35 +0200 (CEST) Date: Tue, 19 Jul 2011 08:07:35 +0200 From: Juergen Schoenwaelder To: Ramu n Message-ID: <20110719060735.GA66241@elstar.local> Mail-Followup-To: Ramu n , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] regarding string data-type restrictions while configuring through Netconf 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: Tue, 19 Jul 2011 06:07:43 -0000 On Tue, Jul 19, 2011 at 02:19:33AM +0000, Ramu n wrote: > > In operation, for string data-type fields can contain some special characters like tab(\t), ? > RFC 6020 says: 9.4. The string Built-In Type The string built-in type represents human-readable strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]: ;; any Unicode character, excluding the surrogate blocks, ;; FFFE, and FFFF. string = *char char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD / %x10000-10FFFF NETCONF itself (RFC 6241) does not place any restriction on the content of XML elements. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Tue Jul 19 02:25:45 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 B0A2821F880C; Tue, 19 Jul 2011 02:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YioiXARciZXQ; Tue, 19 Jul 2011 02:25:45 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3F721F8890; Tue, 19 Jul 2011 02:25:43 -0700 (PDT) Received: from host217-44-4-189.range217-44.btcentralplus.com (HELO pc6) ([217.44.4.189]) by c2beaomr08.btconnect.com with SMTP id DQA51860; Tue, 19 Jul 2011 10:25:34 +0100 (BST) Message-ID: <01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Kent Watsen" , "Juergen Schoenwaelder" References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net><20110713044711.GA80654@elstar.local> <84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net> Date: Tue, 19 Jul 2011 10:22:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E254D8E.0033, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.7.19.90022:17:9.535, ip=217.44.4.189, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __URI_NO_PATH, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4E254D8F.0012,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: opsawg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 19 Jul 2011 09:25:45 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Juergen Schoenwaelder" ; Cc: ; Sent: Wednesday, July 13, 2011 9:26 PM > > > There is some history of this discussion in the ISMS working group. > > When ISMS did SNMP over SSH, we had a hard time dealing with > > notifications and the Juniper approach was already put on the table at > > that time as "running code that seems to work in practice to solve an > > operational problem". As far as I recall, there was no doubt about the > > operational problem and the need to solve it _but_ there were security > > concerns brought forward. I would have to do several hours of reading > > of ISMS archives in order to phrase them correctly. But simply put (as > > far as I recall - and I don't really recall any details and so I might > > be totally off), the concern had to do with something not truely > > authenticated to tell a box to SSH somewhere which involves the usage > > of identities with cryptographic keys. In ISMS, we ended up making the > > notification originator the SSH client - and this caused quite some > > costs since the amount of config increases and the identity to bind > > access control to becomes different. > > As a security person myself, I'm fairly confident that the "Juniper approach" is OK. We've also had numerous security folks look at it as well as the US government (it's FIPS certified) and Tier-1 SPs... > > The only security issue raised so far by the SAAG and IETF-SSH lists was regarding the new HMAC family of host-key algorithms defined in the -01 draft. By nature, it requires a symmetric key and they didn't see how a symmetric-key could be provided in a first-time "call-home" scenario. Of course, the symmetric key can be provided to the device, either keyed in or read off a USB pen-drive... > > > So in essence, I believe we have been for years at a deadlock > > situation where operational people were clear that a solution for > > devices to "call home" is clearly needed but the security people had > > security concerns with the solutions presented and the solutions liked > > more by security people to be operationally a pain. > > Exactly. Kent My recollection is somewhat different to Juergen's. Call home was requested by Eliot Lear but did not get much support in isms WG. Sam Hartman, as AD, ruled it out of scope since the WG already had a lot to do, the charter was to add security to SNMPv3 and not to introduce functions that SNMPv3 did not have (like call home). You will find this in the archives in August 2005, particularly around August 18th. For myself, I have always thought it obvious that the direction, client-server, of the TCP layer can and should be decoupled from that of the security layer, SSL, SSH, TLS ... but whenever I have proposed that, I have not got much support:-( Tom Petch > > Perhaps one path forward is to have the operational people push a > > solution that is implementable and solves an operational problem > > (without creating a new operational problem) through the whole IETF > > process forcing the security people to clearly document their security > > concerns and then it can be seen whether that text all goes into the > > Security Considerations and the protocol passes or the document stops > > at the IESG. This is potentially a painful exercise. > > As painful as it may be, I think this is our best-case scenario. We could push it forward as an independent submission (EXPERIMENTAL?), but it would be much better if either the NETCONF and OPSAWG WGs could sponsor it. Personally, I still agree that it's not NETCONF-specific and hence not for the NETCONF WG, but it makes sense for OPSAWG, if the WG agrees... > > > Thanks, > Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Tue Jul 19 03:24:59 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 6B3CF21F873F; Tue, 19 Jul 2011 03:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+nw4BAiquQO; Tue, 19 Jul 2011 03:24:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AA4FC21F873A; Tue, 19 Jul 2011 03:24:58 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA4B420BE1; Tue, 19 Jul 2011 12:24:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xrl-MtCEo4ok; Tue, 19 Jul 2011 12:24:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 402BC20AFE; Tue, 19 Jul 2011 12:24:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 254C41A0E3AA; Tue, 19 Jul 2011 12:24:54 +0200 (CEST) Date: Tue, 19 Jul 2011 12:24:54 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20110719102454.GA67454@elstar.local> Mail-Followup-To: "t.petch" , Kent Watsen , opsawg@ietf.org, netconf@ietf.org References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> <20110713044711.GA80654@elstar.local> <84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net> <01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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: Tue, 19 Jul 2011 10:24:59 -0000 On Tue, Jul 19, 2011 at 10:22:38AM +0200, t.petch wrote: > My recollection is somewhat different to Juergen's. > > Call home was requested by Eliot Lear but did not get much support in isms WG. > > Sam Hartman, as AD, ruled it out of scope since the WG already had a lot to do, > the charter was to add security to SNMPv3 and not to introduce functions that > SNMPv3 did not have (like call home). You will find this in the archives in > August 2005, particularly around August 18th. Yes, ISMS was never chartered to work on call home. However, we had to address the question how a notification originator sends notifications to a notification receiver via SSH. And this is very similar and this is the discussion I have been referring to in my previous email. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Tue Jul 19 10:46:23 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 C617A21F850F for ; Tue, 19 Jul 2011 10:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxOEL0Tby5+a for ; Tue, 19 Jul 2011 10:46:23 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 718E721F8504 for ; Tue, 19 Jul 2011 10:46:23 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6JHkKP0026361 for ; Tue, 19 Jul 2011 13:46:22 -0400 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37852] helo=[192.168.0.146]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1E/B7-18127-BE2C52E4; Tue, 19 Jul 2011 13:46:20 -0400 Message-ID: <4E25C2EE.8060004@andybierman.com> Date: Tue, 19 Jul 2011 10:46:22 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "t.petch" , Kent Watsen , opsawg@ietf.org, netconf@ietf.org References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> <20110713044711.GA80654@elstar.local> <84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net> <01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> <20110719102454.GA67454@elstar.local> In-Reply-To: <20110719102454.GA67454@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 19 Jul 2011 17:46:23 -0000 On 07/19/2011 03:24 AM, Juergen Schoenwaelder wrote: > On Tue, Jul 19, 2011 at 10:22:38AM +0200, t.petch wrote: > >> My recollection is somewhat different to Juergen's. >> >> Call home was requested by Eliot Lear but did not get much support in isms WG. >> >> Sam Hartman, as AD, ruled it out of scope since the WG already had a lot to do, >> the charter was to add security to SNMPv3 and not to introduce functions that >> SNMPv3 did not have (like call home). You will find this in the archives in >> August 2005, particularly around August 18th. > > Yes, ISMS was never chartered to work on call home. However, we had to > address the question how a notification originator sends notifications > to a notification receiver via SSH. And this is very similar and this > is the discussion I have been referring to in my previous email. > Here is the original charter text from Eliot Lear: http://www.ietf.org/mail-archive/web/ietf/current/msg38521.html Here are David Harrington's slides on why not ISMS: http://www.ietf.org/proceedings/64/slides/callhome-5.pdf Here are the Callhome BoF minutes: http://www.ietf.org/proceedings/64/callhome.html My recollection of the conclusion was that the problem space was not big enough, and an SSH-specific solution was inappropriate. A more general approach should be investigated. So almost 6 years have passed, and NETCONF vendors still want a call-home solution for SSH. IMO, Ken's proposal should be published (assuming the security experts approve). NETCONF notifications are rarely used. The main reason given is that the client connection maintenance is not worth the resources and coding effort. I think call-home for SSH could make NETCONF more deployable. > /js > Andy From randy_presuhn@mindspring.com Tue Jul 19 10:47:36 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 9FB8221F86D1; Tue, 19 Jul 2011 10:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.927 X-Spam-Level: X-Spam-Status: No, score=-100.927 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQNhJGX61pDf; Tue, 19 Jul 2011 10:47:36 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2221F8532; Tue, 19 Jul 2011 10:47:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nMkLdGky++o2QONMUCwfu1+xAqXMDEWvUZf2JkU0vxrAtSt5jV93uBlDqn18MzhG; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.174.180] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QjEON-0003To-JL; Tue, 19 Jul 2011 13:47:35 -0400 Message-ID: <004b01cc463c$b25b1f00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net><20110713044711.GA80654@elstar.local><84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net><01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> <20110719102454.GA67454@elstar.local> Date: Tue, 19 Jul 2011 10:52:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288f74ca8de626d7efb336e75a1b94f6699350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.180 Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 19 Jul 2011 17:47:36 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "t.petch" > Cc: ; > Sent: Tuesday, July 19, 2011 3:24 AM > Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh ... > Yes, ISMS was never chartered to work on call home. However, we had to > address the question how a notification originator sends notifications > to a notification receiver via SSH. And this is very similar and this > is the discussion I have been referring to in my previous email. ... At the risk of an infinite loop... At the SNMP level, wouldn't defining an appropriate notification type for "call home" be sufficient? It seems to me the necessary document is one little notification type and a lot of applicability statement. Randy From randy_presuhn@mindspring.com Tue Jul 19 11:09:02 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 84EDC21F8506; Tue, 19 Jul 2011 11:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.887 X-Spam-Level: X-Spam-Status: No, score=-101.887 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cRUkjnj5ZIR; Tue, 19 Jul 2011 11:09:02 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id E33CF21F84E3; Tue, 19 Jul 2011 11:09:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=neJErP1+z6L29QsWa5ghvc81460x265wvDer1IkQr/8bb1jkLnQ5PoeLtiTBcu3f; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.174.180] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QjEj7-0006wH-7o; Tue, 19 Jul 2011 14:09:01 -0400 Message-ID: <005201cc463f$b0b90060$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> <20110713044711.GA80654@elstar.local> <84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net> <01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net><20110719102454.GA67454@elstar.local> <4E25C2EE.8060004@andybierman.com> Date: Tue, 19 Jul 2011 11:14:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee28882e21d4e88577cf7a77fc594628cf979350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.180 Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 19 Jul 2011 18:09:02 -0000 Hi - > From: "Andy Bierman" > To: "t.petch" ; "Kent Watsen" ; ; > Sent: Tuesday, July 19, 2011 10:46 AM > Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh ... > Here is the original charter text from Eliot Lear: > > http://www.ietf.org/mail-archive/web/ietf/current/msg38521.html > > Here are David Harrington's slides on why not ISMS: > > http://www.ietf.org/proceedings/64/slides/callhome-5.pdf > > Here are the Callhome BoF minutes: > > http://www.ietf.org/proceedings/64/callhome.html > > My recollection of the conclusion was that the problem space was not big enough, > and an SSH-specific solution was inappropriate. A more general approach should > be investigated. > > So almost 6 years have passed, and NETCONF vendors still want a call-home solution for SSH. > IMO, Ken's proposal should be published (assuming the security experts approve). > NETCONF notifications are rarely used. The main reason given is that the client > connection maintenance is not worth the resources and coding effort. I think > call-home for SSH could make NETCONF more deployable. ... It seems like there were two distinct problem spaces that folks had in mind during the initial discussions. One (I'll call it the "narrow" one) is the question of how a device new to the network lets management know that it exists so that it can be (more fully) configured. The other (I'll call it the "broad" one) includes the issues of overcoming NAT. The original proposed charter text seems consistent with the narrow space. Addressing it shouldn't be much work, but would nonetheless be worthwhile. The broad problem is a different matter. David Harrington's most persuasive arguments were addressed to it, rather than the narrow problem. The NETCONF connection maintenance issue Andy raises is really a third issue, which wasn't germane to the isms discussions. When talking about user / vendor needs, it would probably be helpful to indicate which of these three is "the problem" that needs to be addressed, and the extent to which solving the others is necessary (or not). Randy From j.schoenwaelder@jacobs-university.de Tue Jul 19 11:17:54 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 A6A02228017; Tue, 19 Jul 2011 11:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.802 X-Spam-Level: X-Spam-Status: No, score=-102.802 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9RvhkRPfrkT; Tue, 19 Jul 2011 11:17:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6C811E8070; Tue, 19 Jul 2011 11:17:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5638F20BE8; Tue, 19 Jul 2011 20:17:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mWkRvirel6jt; Tue, 19 Jul 2011 20:17:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D321A20BDA; Tue, 19 Jul 2011 20:17:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C2EC1A0F3AE; Tue, 19 Jul 2011 20:17:46 +0200 (CEST) Date: Tue, 19 Jul 2011 20:17:45 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20110719181745.GA70006@elstar.local> Mail-Followup-To: Randy Presuhn , opsawg@ietf.org, netconf@ietf.org References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> <20110713044711.GA80654@elstar.local> <84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net> <01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> <20110719102454.GA67454@elstar.local> <004b01cc463c$b25b1f00$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004b01cc463c$b25b1f00$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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: Tue, 19 Jul 2011 18:17:54 -0000 On Tue, Jul 19, 2011 at 10:52:57AM -0700, Randy Presuhn wrote: > At the risk of an infinite loop... > At the SNMP level, wouldn't defining an appropriate notification type > for "call home" be sufficient? It seems to me the necessary document > is one little notification type and a lot of applicability statement. ISMS ended up not sending notifications over SSH sessions (or DTLS session) initiated by a management system, this is very different from how NETCONF notifications work. And the way access control is done in SNMP land on outgoing notifications and the identity of what is being authenticated by SNMP (transport) security models all adds its share of complexity. So yes, lets not get into a loop. Even though I understand how ISMS ended up with what we have now, I do not consider the solution that came out of ISMS a particularly practical solution and I can only encourage people to try to solve "call home" in a more generic way. Perhaps this time there is more success. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Tue Jul 19 11:50:10 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 B4D5D11E8084; Tue, 19 Jul 2011 11:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8erCQWAdXKrD; Tue, 19 Jul 2011 11:50:09 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DF34211E8082; Tue, 19 Jul 2011 11:50:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTiXR305lLaBIGZmiUbzSR/WPTe1umD+z@postini.com; Tue, 19 Jul 2011 11:50:08 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Jul 2011 11:49:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p6JInev12633; Tue, 19 Jul 2011 11:49:40 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p6JINNRq002843; Tue, 19 Jul 2011 18:23:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201107191823.p6JINNRq002843@idle.juniper.net> To: Randy Presuhn In-Reply-To: <005201cc463f$b0b90060$6801a8c0@oemcomputer> Date: Tue, 19 Jul 2011 14:23:23 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: opsawg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 19 Jul 2011 18:50:10 -0000 "Randy Presuhn" writes: >One (I'll call it the "narrow" one) is the question of how a device new to the >network lets management know that it exists so that it can be (more fully) >configured. The other (I'll call it the "broad" one) includes the issues of >overcoming NAT. The terms "broad" and "narrow" seem meaningless in this discussion. Can we choose better terms? "new-device" and "reachability" are perhaps more self-explanitory. >The broad problem is a different matter. David >Harrington's most persuasive arguments were addressed to it, rather than >the narrow problem. Under "Alternative Proposals", he lists: Develop call-home as an add-on to existing transports, changing only the initiator which is essentially what Kent's done. So given that this is an existing problem for which there is no current solution, what's the best path forward? Are there issues with Kent's draft? Thanks, Phil From kwatsen@juniper.net Tue Jul 19 13:14:01 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 9C3EE21F8AB9; Tue, 19 Jul 2011 13:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scDYZ1s+PBqK; Tue, 19 Jul 2011 13:14:01 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6D821F8AF2; Tue, 19 Jul 2011 13:13:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTiXlg+3zs3eS4FGa5a4Gnhry4vMrgvRu@postini.com; Tue, 19 Jul 2011 13:14:00 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 19 Jul 2011 13:13:09 -0700 From: Kent Watsen To: Phil Shafer , Randy Presuhn Date: Tue, 19 Jul 2011 13:13:07 -0700 Thread-Topic: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh Thread-Index: AcxGRLYK1V0uv75tQIeMy0W4zj+yVQAB/ZfQ Message-ID: <84600D05C20FF943918238042D7670FD3E849038AE@EMBX01-HQ.jnpr.net> References: <005201cc463f$b0b90060$6801a8c0@oemcomputer> <201107191823.p6JINNRq002843@idle.juniper.net> In-Reply-To: <201107191823.p6JINNRq002843@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 19 Jul 2011 20:14:01 -0000 > The terms "broad" and "narrow" seem meaningless in this discussion. > Can we choose better terms? "new-device" and "reachability" are > perhaps more self-explanitory. Regarding the narrow/broad terminology, I tend to use "initial discovery" a= nd "on-going management". The draft enumerates motivation the for both cas= es. > Are there issues with Kent's draft? When considering this, please reference the -00 draft. The -01 draft was p= ut together to appease some SAAG/IETF-SSH list members, but it is unnecessa= rily more complex than the solution presented in the -00 draft. That said, if there's support for the -00 draft, I recommend updating its b= ootstrap sequence to be more like SSH, by having the MAC and Host-Key algor= ithms negotiated. Thanks, Kent =20 From kwatsen@juniper.net Tue Jul 19 13:34: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 4AFBF21F8B2C; Tue, 19 Jul 2011 13:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+WH7hiqyVN0; Tue, 19 Jul 2011 13:34:38 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5722521F8B2B; Tue, 19 Jul 2011 13:34:38 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTiXqXJ8eSR+vkl1Sr0hUGV/gDTXgfgHP@postini.com; Tue, 19 Jul 2011 13:34:38 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 19 Jul 2011 13:32:57 -0700 From: Kent Watsen To: Andy Bierman , t.petch , "opsawg@ietf.org" , "netconf@ietf.org" Date: Tue, 19 Jul 2011 13:32:55 -0700 Thread-Topic: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh Thread-Index: AcxGO87C1rGjIcD/SuOgTYH/eb0A7AAE3UZA Message-ID: <84600D05C20FF943918238042D7670FD3E849038E3@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net> <20110713044711.GA80654@elstar.local> <84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net> <01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> <20110719102454.GA67454@elstar.local> <4E25C2EE.8060004@andybierman.com> In-Reply-To: <4E25C2EE.8060004@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 19 Jul 2011 20:34:39 -0000 > My recollection of the conclusion was that the problem space was > not big enough, and an SSH-specific solution was inappropriate. =20 > A more general approach should be investigated. If this is still a concern, we might be able to extend the protocol so that= it could reverse *any* TCP-based client/server protocol (HTTP, POP, IMAP, = etc.) Is there a perceived need to reverse other protocols? - perhaps to r= esolve the NAT traversal case? > ...assuming the security experts approve So far their objections have primarily been that the solution proposed wasn= 't integrated into the SSH protocol enough. There were few comments/concer= ns regarding security (see my July 12 email for details) > The main reason given is that the client connection maintenance is > not worth the resources and coding effort. Just to clarify, the coding effort on the devices is really quite small. A= ll that is needed is a daemon to initiate the TCP connection, complete the = bootstrap sequence, and then fork/exec `sshd -i` in exactly the same way th= at `inetd` does. SSH itself can't differentiate how the underlying transpo= rt was established. Juniper has C-based source code for doing this that we= have provided to partners in the past, but we should be able to open sourc= e it in order to validate the draft, presuming it moves forward... Thanks, Kent From ietfc@btconnect.com Wed Jul 20 03:21:33 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 CA36F21F86E1; Wed, 20 Jul 2011 03:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-+P6C+HenNS; Wed, 20 Jul 2011 03:21:33 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id C4D4421F86E5; Wed, 20 Jul 2011 03:21:31 -0700 (PDT) Received: from host86-185-125-164.range86-185.btcentralplus.com (HELO pc6) ([86.185.125.164]) by c2beaomr06.btconnect.com with SMTP id DWY80667; Wed, 20 Jul 2011 11:21:28 +0100 (BST) Message-ID: <00d301cc46be$00397d80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Kent Watsen" References: <005201cc463f$b0b90060$6801a8c0@oemcomputer><201107191823.p6JINNRq002843@idle.juniper.net> <84600D05C20FF943918238042D7670FD3E849038AE@EMBX01-HQ.jnpr.net> Date: Wed, 20 Jul 2011 11:18:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4E26AC27.0105, actions=TAG X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.7.20.94214:17:9.535, ip=86.185.125.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __URI_NO_PATH, BODY_SIZE_1500_1599, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4E26AC29.0034,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: opsawg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 20 Jul 2011 10:21:33 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Phil Shafer" ; "Randy Presuhn" Cc: ; Sent: Tuesday, July 19, 2011 10:13 PM > > The terms "broad" and "narrow" seem meaningless in this discussion. > > Can we choose better terms? "new-device" and "reachability" are > > perhaps more self-explanitory. > > Regarding the narrow/broad terminology, I tend to use "initial discovery" and "on-going management". The draft enumerates motivation the for both cases. > > > > Are there issues with Kent's draft? > > When considering this, please reference the -00 draft. How? With the death of watersprings, I know of no way to get an obsoleted draft; the IETF web site only gives me -01 which is what I would expect. If you really want us to consider the earlier version then I think that you should re-issue it as -02. And a URL would help. Tom Petch > The -01 draft was put together to appease some SAAG/IETF-SSH list members, but it is unnecessarily more complex than the solution presented in the -00 draft. > > That said, if there's support for the -00 draft, I recommend updating its bootstrap sequence to be more like SSH, by having the MAC and Host-Key algorithms negotiated. > > > Thanks, > Kent > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From ietfc@btconnect.com Wed Jul 20 04:45:46 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 C4B5B21F87FA; Wed, 20 Jul 2011 04:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbqpuIozSt0Z; Wed, 20 Jul 2011 04:45:46 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6728021F86EB; Wed, 20 Jul 2011 04:45:44 -0700 (PDT) Received: from host86-185-125-164.range86-185.btcentralplus.com (HELO pc6) ([86.185.125.164]) by c2beaomr08.btconnect.com with SMTP id DQM06614; Wed, 20 Jul 2011 12:45:37 +0100 (BST) Message-ID: <011d01cc46c9$c209e160$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Kent Watsen" , , References: <84600D05C20FF943918238042D7670FD3E8429F313@EMBX01-HQ.jnpr.net><20110713044711.GA80654@elstar.local><84600D05C20FF943918238042D7670FD3E8429F98E@EMBX01-HQ.jnpr.net><01c401cc45ed$07d58060$4001a8c0@gateway.2wire.net> <20110719102454.GA67454@elstar.local> <4E25C2EE.8060004@andybierman.com> <84600D05C20FF943918238042D7670FD3E849038E3@EMBX01-HQ.jnpr.net> Date: Wed, 20 Jul 2011 12:42:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4E26BFE1.0094, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.7.20.104214:17:9.535, ip=86.185.125.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4E26BFE5.00DE,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 20 Jul 2011 11:45:46 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Andy Bierman" ; "t.petch" ; ; Sent: Tuesday, July 19, 2011 10:32 PM > My recollection of the conclusion was that the problem space was > not big enough, and an SSH-specific solution was inappropriate. > A more general approach should be investigated. If this is still a concern, we might be able to extend the protocol so that it could reverse *any* TCP-based client/server protocol (HTTP, POP, IMAP, etc.) Is there a perceived need to reverse other protocols? - perhaps to resolve the NAT traversal case? Kent As far as I can see, that is impossible with the architecture that the IETF currently uses. When a TCP connection is established, then the port (usually) determines the 'application'. What happens next is up to the application. It would have been immensely useful had there been a requirement for all applications (ie the layer above TCP/UDP/SCTP) to start with a negotiation, who is to be client, are we using security, ....? Some applications have precisely this, but it is specific to the application. So a generic call home has to be application specific, in which case it cannot be generic. What we can do, and what you could have done, is define a new port which conveys precisely that semantic, negotiation follows, or else role reversal follows, become the client to me instead of the server (which is part of what you have done). But it remains application specific and I cannot see any other solution. Where the application needs role reversal, allocate a new port; but I do not think that that is sufficiently complicated to warrant an I-D. Tom Petch > ...assuming the security experts approve So far their objections have primarily been that the solution proposed wasn't integrated into the SSH protocol enough. There were few comments/concerns regarding security (see my July 12 email for details) > The main reason given is that the client connection maintenance is > not worth the resources and coding effort. Just to clarify, the coding effort on the devices is really quite small. All that is needed is a daemon to initiate the TCP connection, complete the bootstrap sequence, and then fork/exec `sshd -i` in exactly the same way that `inetd` does. SSH itself can't differentiate how the underlying transport was established. Juniper has C-based source code for doing this that we have provided to partners in the past, but we should be able to open source it in order to validate the draft, presuming it moves forward... Thanks, Kent From kwatsen@juniper.net Wed Jul 20 09:41:10 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 E0D4421F865D; Wed, 20 Jul 2011 09:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDcqBtJvcXR3; Wed, 20 Jul 2011 09:41:10 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0D15621F8610; Wed, 20 Jul 2011 09:41:09 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTicFJAD6tyAENLTXnzIYwP6ZCOJlq4vc@postini.com; Wed, 20 Jul 2011 09:41:10 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 20 Jul 2011 09:39:37 -0700 From: Kent Watsen To: t.petch Date: Wed, 20 Jul 2011 09:39:32 -0700 Thread-Topic: [OPSAWG] [Netconf] guidance on draft-kwatsen-reverse-ssh Thread-Index: AcxGxstNqkEbWw/5RLCp/6Q2h/U15wAM/NWA Message-ID: <84600D05C20FF943918238042D7670FD3E84903F31@EMBX01-HQ.jnpr.net> References: <005201cc463f$b0b90060$6801a8c0@oemcomputer><201107191823.p6JINNRq002843@idle.juniper.net> <84600D05C20FF943918238042D7670FD3E849038AE@EMBX01-HQ.jnpr.net> <00d301cc46be$00397d80$4001a8c0@gateway.2wire.net> In-Reply-To: <00d301cc46be$00397d80$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 20 Jul 2011 16:41:11 -0000 > When considering this, please reference the -00 draft. > > How? With the death of watersprings, I know of no way to get an obsolete= d > draft; the IETF web site only gives me -01 which is what I would expect. = =20 I don't know what "watersprings" is, but whenever I look at drafts via http://tools.ietf.org/html/, I'm always able to access all previous drafts and even get diffs between them... > And a URL would help. Here's a directly link to the "-00" draft: http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-00 Thanks, Kent From wwwrun@ietfa.amsl.com Thu Jul 21 09:59:18 2011 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 1D10921F8743; Thu, 21 Jul 2011 09:59:15 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110721165918.1D10921F8743@ietfa.amsl.com> Date: Thu, 21 Jul 2011 09:59:15 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] WG Action: RECHARTER: Network Configuration (netconf) 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, 21 Jul 2011 16:59:18 -0000 The Network Configuration (netconf) working group in the Operations and Management Area Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Network Configuration (netconf) -------------------------------------- Current Status: Active Working Group Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Security Advisor: Tim Polk Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org or: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group has produced a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. - Provides support for asynchronous notifications. The NETCONF protocol has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 2. The NETCONF server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to define suitable notifications. 3. As implementation and deployment experience gained with the NETCONF monitoring data model, the WG may revise the NETCONF monitoring data model to add additional objects that can be used to check the status of the server and to discover additional information about the server implementation. The WG may choose to revise the NETCONF monitoring data model. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis done - rfc4741bis to IESG for consideration as Proposed Standard done - Send rfc4742bis to IESG for consideration as proposed Standard. done - first WG draft (rev 00) on NACM posted done - first WG draft (rev 00) on NETCONF specific YANG modules posted Jul 2011 - WGLC for NACM document Jul 2011 - WGLC for NETCONF specific notifications document Sep 2011 - (if needed last) WGLC for NACM document Sep 2011 - (if needed last) WGLC for NETCONF specific notifications document Oct 2011 - submit NACM document to IESG for consideration as Proposed Standard Oct 2011 - submit NETCONF specific notifications document to IESG for consideration as Proposed Standard From ietfc@btconnect.com Thu Jul 21 10:30:11 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 C54F221F870F; Thu, 21 Jul 2011 10:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbj2ofaPUNJj; Thu, 21 Jul 2011 10:30:11 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id C744D21F858A; Thu, 21 Jul 2011 10:30:10 -0700 (PDT) Received: from host86-185-125-164.range86-185.btcentralplus.com (HELO pc6) ([86.185.125.164]) by c2beaomr10.btconnect.com with SMTP id DRC44395; Thu, 21 Jul 2011 18:30:07 +0100 (BST) Message-ID: <013f01cc47c3$0b40e960$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Kent Watsen" References: <005201cc463f$b0b90060$6801a8c0@oemcomputer><201107191823.p6JINNRq002843@idle.juniper.net> <84600D05C20FF943918238042D7670FD3E849038AE@EMBX01-HQ.jnpr.net> <00d301cc46be$00397d80$4001a8c0@gateway.2wire.net> <84600D05C20FF943918238042D7670FD3E84903F31@EMBX01-HQ.jnpr.net> Date: Thu, 21 Jul 2011 18:27:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E28621E.0099, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.7.21.165114:17:9.535, ip=86.185.125.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __URI_NO_WWW, __CP_URI_IN_BODY, BODY_SIZE_1100_1199, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4E28621F.003D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: opsawg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh 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, 21 Jul 2011 17:30:11 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" Cc: ; Sent: Wednesday, July 20, 2011 6:39 PM > When considering this, please reference the -00 draft. > > How? With the death of watersprings, I know of no way to get an obsoleted > draft; the IETF web site only gives me -01 which is what I would expect. I don't know what "watersprings" is, but whenever I look at drafts via http://tools.ietf.org/html/, I'm always able to access all previous drafts and even get diffs between them... > And a URL would help. Here's a directly link to the "-00" draft: http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-00 Kent Thanks for that. I was using the I-D search facility on the IETF web site - silly me - and it only lists -00 even when I select current and expired I-Ds. watersprings was a website that gave access to all IETF I-Ds going back further than I even had need to go, via a very easy to use, so simple anyone could navigate it interface. Like all the best technology, it has been withdrawn:-( Tom Petch Thanks, Kent From ietf@andybierman.com Fri Jul 22 15:20:15 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 66BFB21F8B7B for ; Fri, 22 Jul 2011 15:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38DRaELI6Suv for ; Fri, 22 Jul 2011 15:20:14 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6854021F8B79 for ; Fri, 22 Jul 2011 15:20:14 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6MMKDEv008779 for ; Fri, 22 Jul 2011 18:20:13 -0400 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:47097] helo=[192.168.0.146]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B3/C4-15811-C97F92E4; Fri, 22 Jul 2011 18:20:13 -0400 Message-ID: <4E29F797.5060107@andybierman.com> Date: Fri, 22 Jul 2011 15:20:07 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] open-source support for new NETCONF RFCs 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, 22 Jul 2011 22:20:15 -0000 FYI, The first version of Yuma 2 has been released. Yuma Project: http://sourceforge.net/projects/yuma/ Yuma Downloads: http://www.netconfcentral.org/download It includes full support for the following IETF standards: * NETCONF ver. 1.1 (RFC 6241) * NETCONF over SSH ver. 1.1 (RFC 6242) * NETCONF Capability (RFC 6243) * NETCONF ver. 1.0 (RFC 4741) * NETCONF over SSH ver. 1.1 (RFC 4742) * NETCONF Notifications (RFC 5277) * NETCONF Partial Locking (RFC 5717) * NETCONF Monitoring (RFC 6022) * YANG data modeling language (RFC 6020) * YANG Data Types (RFC 6021) Andy From j.schoenwaelder@jacobs-university.de Sun Jul 24 08:12:59 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 6B99B21F88A6 for ; Sun, 24 Jul 2011 08:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZymqsa-WGhd for ; Sun, 24 Jul 2011 08:12:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2921F88A1 for ; Sun, 24 Jul 2011 08:12:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6313720A6D for ; Sun, 24 Jul 2011 17:12:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DTkjStIW9X0d; Sun, 24 Jul 2011 17:12:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F027720BD5; Sun, 24 Jul 2011 17:12:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 654301A15CCA; Sun, 24 Jul 2011 17:12:53 +0200 (CEST) Date: Sun, 24 Jul 2011 17:12:53 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20110724151253.GA99659@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] js review of draft-ietf-netconf-system-notifications-04 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: Sun, 24 Jul 2011 15:12:59 -0000 I have reviewed draft-ietf-netconf-system-notifications-04. I am fine with the document in general and support this going forward towards the IESG. I have a number of little issues and nits, most of them are purly editorial. 1) I suggested to put the acronym NETCONF into the title so that RFCs related to NETCONF are easy to search and find in the RFC list: Network Configuration Protocol (NETCONF) Base Notifications 2) For my taste, there is a bit too much structure. I suggest to simply remove the subsection title 2.1.1. The 3rd paragraph in 2.1 could also simply become a reference to [RFC6020] in the first sentence where YANG is mentioned. 3) s/defines some events/defines some notifications/ 4) I suggest to call the module ietf-netconf-notifications (dropping the base) and I suggest to change the prefix to 'ncn'. To me, ncbase is a bit confusing (and ietf-netconf-monitoring uses ncm). 5) s/common NETCONF base notification events/common NETCONF notifications/ 6) s/to identity/to identify 7) The case 'by-user' could probably be called 'by-session'. 8) s/Summarizes each edit being reported./ The notification summarizes the edits that have been detected./ 9) I suggest to call 'target-datastore' simply 'datastore'. A) References to 4741 / 4742 (security considerations) and 4741bis (elsewhere) need to updated. B) s/, and may be now be vulnerable to unspecified attacks//g /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Jul 24 11:55:31 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 70EA121F8892 for ; Sun, 24 Jul 2011 11:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e7-6S-dLnsh for ; Sun, 24 Jul 2011 11:55:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E05CB21F8760 for ; Sun, 24 Jul 2011 11:55:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47CB620AFA for ; Sun, 24 Jul 2011 20:55:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XEzNq5l5gQQO; Sun, 24 Jul 2011 20:55:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D89920A01; Sun, 24 Jul 2011 20:55:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F3B5A1A1603F; Sun, 24 Jul 2011 20:55:23 +0200 (CEST) Date: Sun, 24 Jul 2011 20:55:23 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20110724185523.GB624@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] js review of draft-ietf-netconf-access-control-04 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: Sun, 24 Jul 2011 18:55:31 -0000 I have reviewed draft-ietf-netconf-access-control-04. I am fine with the document in general, although I have a number of issues and suggestions but nothing I do consider a show stopped on the technical side. The comments are in document order. 1) I suggested to put the acronym NETCONF into the title so that RFCs related to NETCONF are easy to search in the RFC list: Network Configuration Protocol (NETCONF) Access Control Model 2) I suggest to get rid of the section titles for section 1.1.1, 1.1.2, 1.1.3, and 1.1.4. 3) s/conceptual criteria used/criteria used/ 4) I do not understand figure 1. Perhaps the idea is that the top-right box is accessing state data but that conflicts with the text on the arrow pointing to data node access allowed. The text did not help me to understand this either. Should the arrow pointing from the lower-right box point to "notification" instead of client session? Should there be an arrow "client reply"? Or even better, should this be "RPC request" and "RPC reply"? 5) In 2.2, what is "NETCONF session output"? Did you mean "state data"? 6) In 2.3, s/procedural interface model/remote procedure call model/ since this is the way 6241 describes this. 7) In 2.3, s/candidate configuration/candidate configuration datastore/ and s/running configuration/running configuration datastore/ 8) My understanding of 2.4.4 is that copy-config fails as soon as there is a non-readable object. If so, can you spell out which error is being generated? 9) Should 2.6 have been: It SHOULD be possible to disable part or all of the access control model without deleting any access control rules. 10) Should 2.7 start with "Suitable configuration and monitoring..." instead of control? 11) Figure 2 adds details to figure 1 but I am still confused what the " acc. ctl" box does. If it is protecting state data sitting in server instrumentation, why is it not called from the " processor" much like the "data node acc. ctl"? Perhaps "data node acc. ctl" really is "configuration datastore access control" and the other box was meant to be "state data access control"? The text again did not help me to figure this out. (How does the second item on page 17 map to the figure?) 12) s/be configured in multiple groups/be a member of multiple groups/ 13) Section 3.2.3 states that access is granted to sessions. I am not sure this is true - at least the examples seem to convince me that access is granted to users. Do we need 3.2.3 at all? 14) The first sentence in 3.2.4 does not really tell me much and seems to be a bit recursive. 15) In 3.2.5.1, s/access requested/requests/ ? 16) Should there be a notification-default switch as well? 17) If I set exec-default to "deny", then nothing seems to be possible anymore except the exchange. Even notifications require an RPC to subscribe to a stream. So how useful is the exec-default switch? 18) I assume with "module" you mean "YANG module" or perhaps more generic "data model module". (In the NETCONF monitoring data model, this is called a schema identifier - boah.) 19) My reading of the rules of procedure is that a user that does not map into a group simply bypasses all access control rule checks and ends up with access denied if the corresponding default switch is set to "permit". Is this desirable behaviour? You mistype a name in a group configuration and the result is open access? 20) Can we replace the text in 3.4.1 with pyang -f tree output? I happen to find that format more useful to understand the structure than lots of text (and it is remarkably simply in this case since the data model is remarkably short). 21) I would have used the prefix and toplevel node ncacm instead of nacm. For the prefix, this would give us consistency with other NETCONF prefixes we already have (nc, ncm, ncwd, [ncn], ...). 21) s/NETCONF Server Access Control Model/NETCONF Access Control Model/ 22) There is of course a question what is secure and very-secure and why two levels are needed or enough. But only time will tell.. (no action expected). 23) improved description bit create (access-operation-type): Any operation that creates a new data node. 24) improved description bit read (access-operation-type): Any operation or notification that returns the value of a data node is a read operation. 25) improved description bit delete (access-operation-type): Any operation that removes a data node is a delete operation. 26) improved description group-name-type: Name of an administrative group to which users can be assigned. 27) Is denied-data-writes and bumped once per RPC execution or multiple times if multiple data nodes are affected? I expect the former but it should be clarified (perhaps even spell this out in the elements of procedure?). 28) Why is the rule-list name and the rule name restricted to 1..256? Seems arbitrary and we do not have restrictions on user names or group names. 29) Several comments about the examples: I find the examples very helpful. I like to propose some name changes to make them easier to read and to better memorize the purpose of rules. A.2: OLD NEW guest guest-acl mod-1 deny-ncm monitor example monitor-acl mod-2 permit-ncm mod-3 permit-exec admin example admin-acl mod-4 permit-all A.3: OLD NEW guest guest-monitor-acl rpc-1 deny-kill-session rpc-2 deny-delete-config monitor monitor-acl rpc-3 permit-edit-config A.4: OLD NEW guest rules guest-acl data-1 deny-n:ncacm monitor rules monitor-acl data-acme-config permit-acme-config dummy-itf permit-dummy-interface admin rules admin-acl admin-itf permit-interfaces I believe it is important to use "speaking" names in the examples since people will copy from the examples when they write their own access control rules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Mon Jul 25 13:40:06 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 8AE8D21F8880 for ; Mon, 25 Jul 2011 13:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.28 X-Spam-Level: X-Spam-Status: No, score=-105.28 tagged_above=-999 required=5 tests=[AWL=1.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPV8kgZa2kRs for ; Mon, 25 Jul 2011 13:40:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 442FF21F886E for ; Mon, 25 Jul 2011 13:40:00 -0700 (PDT) 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 p6PKdsnU015583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jul 2011 22:39:55 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6PKdsvw005059; Mon, 25 Jul 2011 22:39:54 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 22:39:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 22:39:51 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640269C416@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Session Summary Thread-Index: AcxLCv6lZe/4sNp0Tp+BjT0rjScuYw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 25 Jul 2011 20:39:54.0378 (UTC) FILETIME=[0264B6A0:01CC4B0B] Cc: netconf Subject: [Netconf] WG Session Summary 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: Mon, 25 Jul 2011 20:40:06 -0000 Hi Dan,=20 below is a summary and action items from the NETCONF WG session on July 25, 2011 in=20 Quebec City, Canada:=20 - We had approx. 37 participants in the 2 hour NETCONF session.=20 - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and review of the=20 documents. Status of the documents: (http://www.ietf.org/proceedings/81/slides/netconf-0.ppt) - The documents With-defaults capability, 4741bis and 4742bis have been published as RFC 6243, RFC 6241 and RFC 6242. - Following documents are in WG LC till August 1st and they have been discussed in the session=20 with their issues: - Network Configuration Protocol Access Control Model (draft-ietf-netconf-access-control-04) - NETCONF System Notifications (draft-ietf-netconf-system-notifications-04) Discussion on chartered items: NETCONF NACM: (http://www.ietf.org/proceedings/81/slides/netconf-3.pdf) - Andy brought up the open issues for NACM. - Andy will send the proposed text for the issues to the maillist and prepare a revision for=20 the draft within 2 weeks. - WG co-chairs will start a new WG LC once the revision is available. NETCONF System Notifications: (http://www.ietf.org/proceedings/81/slides/netconf-1.pdf) - Andy brought up the open issues for System notifications draft. - Andy will send the proposed text for the issues to the maillist and prepare a revision for=20 the draft within 2 weeks. - WG co-chairs will start a new WG LC once the revision is available. Discussion on not chartered items: NETCONF Light: (http://www.ietf.org/proceedings/81/slides/netconf-2.pdf) - Juergen Schoenwaelder presented on the implementation of the NETCONF Light=20 (NETCONF on Constrained Devices). - Different participants showed an interest on the draft. Beside constrained devices it can=20 also be used for devices which don't want to implement the whole NETCONF standard.=20 Dan suggested to follow up the work and others proposed to keep the document alive with=20 the goal to make e.g. Informational. Reverse SSH: (http://www.ietf.org/proceedings/81/slides/netconf-6.pdf) - Kent Watsen presented on the Reverse SSH draft and the discussion took place in SSH=20 and SAAG maillists. - There are 4 options for implementation with different pro & contra. - It has been discussed whether it could be an experimental based on the options easy to=20 implement.=20 - 9-10 persons think that the work is interesting to do. - Which way to go and whether it can be done in NETCONF WG needs further discussion. Bert & Mehmet From mbj@tail-f.com Mon Jul 25 14:13:53 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 E74C021F85DA for ; Mon, 25 Jul 2011 14:13:53 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0Z90qUWDjn2 for ; Mon, 25 Jul 2011 14:13:53 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AC70E21F84E8 for ; Mon, 25 Jul 2011 14:13:52 -0700 (PDT) Received: from localhost (unknown [130.129.18.172]) by mail.tail-f.com (Postfix) with ESMTPSA id EEFCC1200CB1 for ; Mon, 25 Jul 2011 23:12:26 +0200 (CEST) Date: Mon, 25 Jul 2011 17:13:41 -0400 (EDT) Message-Id: <20110725.171341.488213779.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <4E1DB161.2060707@bwijnen.net> References: <4E1DB161.2060707@bwijnen.net> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.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: Mon, 25 Jul 2011 21:13:54 -0000 Hi, I have reviewed this document, and I think it is ready for publication, with some minor edits: As I said in the meeting, the text needs to be clearer about how session id '0' is used. ---------- OLD: enum "killed" { value 1; description "The session was terminated by the client in abnormal fashion, e.g., by the NETCONF operation."; } NEW: enum "killed" { value 1; description "The session was terminated in an abnormal fashion, e.g., by the NETCONF operation."; } ---------- OLD: leaf killed-by { when "../termination-reason = 'killed'"; type nc:session-id-type; description "The session ID that issued the , if the session was terminated by this operation. If the session was abnormally terminated by a non-NETCONF client operation, the value '0' will be used instead."; } NEW: leaf killed-by { when "../termination-reason = 'killed'"; type nc:session-id-type-or-zero; description "The ID of the session that terminated this session, or the value '0' if it was terminated in some other way."; /martin From bertietf@bwijnen.net Tue Jul 26 14:05:41 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 EF04321F8784 for ; Tue, 26 Jul 2011 14:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNr8uTO5Wcyf for ; Tue, 26 Jul 2011 14:05:41 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id C665221F877F for ; Tue, 26 Jul 2011 14:05:40 -0700 (PDT) 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 1Qloor-0002FA-RF; Tue, 26 Jul 2011 23:05:39 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-1477.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qlooq-0007Az-Qf; Tue, 26 Jul 2011 23:05:37 +0200 Message-ID: <4E2F2C20.6080802@bwijnen.net> Date: Tue, 26 Jul 2011 17:05:36 -0400 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Yoshifumi Atarashi References: <20110726200206.GA8321@elstar.local> <4E2F1F8D.7050207@alaxala.net> In-Reply-To: <4E2F1F8D.7050207@alaxala.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: 86ab03e524994f79ca2c75a176445dd42976a7e83e2a19eba71630c8fe7853bf Cc: Netconf Subject: Re: [Netconf] [netmod] system data model rpcs 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, 26 Jul 2011 21:05:42 -0000 On 7/26/11 4:11 PM, Yoshifumi Atarashi wrote: > Many venders and ISPs operators think that Power/Reboot control > mechanism are caution of securty hole . > Be carefully consider the risks. > Yoshifumi Atarashi OK, I remember that way back when, there were safety laws that would forbid to do a remote reboot (actually that was a remote power on.). But in any event, these dyas, someone can ssh into a device, got to root mode and then do a reboot also. SO in that sense, I do not see why it would be so different if Netcofn could do it (with proper access control of course). Bert > (11/07/26 16:02), Juergen Schoenwaelder wrote: >> Hi, >> >> I am wondering whether we should add some additional RPCs to the >> system data model. I am thinking about very basic things such as a >> reboot RPC and/or a powerdown RPC. >> >> /js >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From atarashi@alaxala.net Tue Jul 26 14:31:41 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 A696011E80B8; Tue, 26 Jul 2011 14:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRuAprHfcsh1; Tue, 26 Jul 2011 14:31:41 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D00CF11E80AF; Tue, 26 Jul 2011 14:31:40 -0700 (PDT) Received: by gwb20 with SMTP id 20so739418gwb.31 for ; Tue, 26 Jul 2011 14:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alaxala.net; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xlezTTQz/6wa89FsHgUHyCM50puGkkPyjZRz0r9d0Fg=; b=dV/oG6K0/nC2q8CyPUxogXopSMp3CnqU0LXITbMGqZDmY55Fr8rx27d5+8YRGywYoq ryWOiLrDRzNhxYB27ZWe6qxvbQbTpKd7jT6BPrtmxqqKBz2f83gGz+7tCt3NxX1jvez7 /Klh4DExckQJZ0HNihbhOedyEg/iDepbo9sYA= Received: by 10.142.144.15 with SMTP id r15mr4115796wfd.439.1311715899837; Tue, 26 Jul 2011 14:31:39 -0700 (PDT) Received: from dhcp-5725.meeting.ietf.org (dhcp-5725.meeting.ietf.org [130.129.87.37]) by mx.google.com with ESMTPS id 9sm946760pbx.34.2011.07.26.14.31.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 14:31:39 -0700 (PDT) Message-ID: <4E2F3239.4020405@alaxala.net> Date: Tue, 26 Jul 2011 17:31:37 -0400 From: Yoshifumi Atarashi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja-JP-mac; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Bert (IETF) Wijnen" References: <20110726200206.GA8321@elstar.local> <4E2F1F8D.7050207@alaxala.net> <4E2F2C20.6080802@bwijnen.net> In-Reply-To: <4E2F2C20.6080802@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] system data model rpcs 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, 26 Jul 2011 21:31:41 -0000 Thank you, Bert. We(Venders) sometimes are bullied by operators about security issue...... I don't mind these control. For netconf/netmod deployment, I'm thinking something is better instead of power control, more useful for ISPs systems. Yoshifumi Atarashi (11/07/26 17:05), Bert (IETF) Wijnen wrote: > On 7/26/11 4:11 PM, Yoshifumi Atarashi wrote: >> Many venders and ISPs operators think that Power/Reboot control >> mechanism are caution of securty hole . >> Be carefully consider the risks. >> Yoshifumi Atarashi > OK, I remember that way back when, there were safety laws that would > forbid to > do a remote reboot (actually that was a remote power on.). > > But in any event, these dyas, someone can ssh into a device, got to > root mode > and then do a reboot also. SO in that sense, I do not see why it would be > so different if Netcofn could do it (with proper access control of > course). > > Bert > >> (11/07/26 16:02), Juergen Schoenwaelder wrote: >>> Hi, >>> >>> I am wondering whether we should add some additional RPCs to the >>> system data model. I am thinking about very basic things such as a >>> reboot RPC and/or a powerdown RPC. >>> >>> /js >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From lhotka@cesnet.cz Wed Jul 27 08:04:34 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 97BDE21F8B6A for ; Wed, 27 Jul 2011 08:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYwVKB0Zf1yv for ; Wed, 27 Jul 2011 08:04:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id A2D3E21F8922 for ; Wed, 27 Jul 2011 08:04:33 -0700 (PDT) Received: from [IPv6:2001:df8::8:5ab0:35ff:fe73:8f1d] (unknown [IPv6:2001:df8:0:8:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2B9612CDE2CE for ; Wed, 27 Jul 2011 17:04:32 +0200 (CEST) From: Ladislav Lhotka Content-Type: multipart/signed; boundary=Apple-Mail-6-611905695; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 27 Jul 2011 11:04:30 -0400 Message-Id: <39E71257-6243-4DD3-857F-376DBBA4F164@cesnet.cz> To: netconf@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Netconf] concurrent access to candidate 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, 27 Jul 2011 15:04:34 -0000 --Apple-Mail-6-611905695 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'd like to clarify the options for concurrent access to candidate. = Consider the following scenario: 1. An administrator works in candidate on implementing a major = reconfiguration. This may take several hours, so the admin may not be to = finish it in one session. So he applies a part of the changes and ends = the session (releasing the lock on candidate). 2. A low-profile user opens a session and wants to make minor change, = e.g. change his password. His attempt to lock the candidate is refused = because of uncommited changes. So he executes "discard-changes", obtains = the lock, applies his edit and performs a commit. The only chance for the admini to avoid losing his work seems to be to = keep the first session open with a lock on candidate, but this is = against the requirement that the locks be short-lived. Or am I missing = something? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-6-611905695 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNzI3MTUwNDMxWjAjBgkqhkiG9w0BCQQxFgQUZD+ALzaOMwXy3lXVvod0fi5RCQYwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQCceHfLFs6zPfnQQkh/WOfminL2 7x7RcPniiHWanG2fR6RklI75u6wh2OyyXWc2Pn8hrNPqvh3IsZ8xK1Nukjn/cwk7q0ybj5KivMaK ZYLYYAsIcYjapDOGKhzda8uTSuF1PQgPh8gGCtaBus8FbYqpZvDbKu9DPWwBDouia1NPF7MfGd/6 7EbjjjI3VqS7BxOb2/BomIhVCwvsEk0A75hGGqYaH2wMJ3cUbZpAUQ5JTaYtyvn3a6kT7OagBt7s iKa3kG/gqgCSKYvTG4UbmYplyjX281THrz3C1Ap9A84wJDb9udNAh61KmHuJGE1yChYYtuDsFbco mx8AwrGpxTFWAAAAAAAA --Apple-Mail-6-611905695-- From ietf@andybierman.com Wed Jul 27 08:25:38 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 567B821F8753 for ; Wed, 27 Jul 2011 08:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPlgv0U88HtN for ; Wed, 27 Jul 2011 08:25:37 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8621F86D8 for ; Wed, 27 Jul 2011 08:25:37 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6RFPa9s012079 for ; Wed, 27 Jul 2011 11:25:36 -0400 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.23.149] ([130.129.23.149:47119] helo=[130.129.23.149]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E3/3E-21697-0FD203E4; Wed, 27 Jul 2011 11:25:36 -0400 Message-ID: <4E302DED.7020607@andybierman.com> Date: Wed, 27 Jul 2011 08:25:33 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ladislav Lhotka References: <39E71257-6243-4DD3-857F-376DBBA4F164@cesnet.cz> In-Reply-To: <39E71257-6243-4DD3-857F-376DBBA4F164@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] concurrent access to candidate 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, 27 Jul 2011 15:25:38 -0000 On 07/27/2011 08:04 AM, Ladislav Lhotka wrote: > Hi, > > I'd like to clarify the options for concurrent access to candidate. Consider the following scenario: > > 1. An administrator works in candidate on implementing a major reconfiguration. This may take several hours, so the admin may not be to finish it in one session. So he applies a part of the changes and ends the session (releasing the lock on candidate). > > 2. A low-profile user opens a session and wants to make minor change, e.g. change his password. His attempt to lock the candidate is refused because of uncommited changes. So he executes "discard-changes", obtains the lock, applies his edit and performs a commit. > > The only chance for the admini to avoid losing his work seems to be to keep the first session open with a lock on candidate, but this is against the requirement that the locks be short-lived. Or am I missing something Why would the 2nd session even bother with discard-changes? Most users tend to ignore locking because CLI ignores locking. SNMP never had any locking. (But just because 2 technologies are horribly broken doesn't mean NETCONF should be just as broken. ;-) The global candidate in NETCONF is seriously flawed. Explicit global locking is not the best way to solve the multiple-writers problem. This is certainly not the way source code control systems work. Private candidates, which utilize mandatory-to-use implicit partial locking is a much more robust solution. It would also solve the commit-deadlock problem which Wes has described many times. There would no way a private candidate could contain edits which could not be committed due to access control. (I'm thinking of writing a draft, but private candidates require that the global candidate is removed, which would make a server non-compliant. An optional capability is not so straight-forward.) > Lada > Andy > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@cesnet.cz Wed Jul 27 10:27:43 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 81F5021F855F for ; Wed, 27 Jul 2011 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C90KDAnDoHzl for ; Wed, 27 Jul 2011 10:27:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE6721F850B for ; Wed, 27 Jul 2011 10:27:42 -0700 (PDT) Received: from [IPv6:2001:df8::8:5ab0:35ff:fe73:8f1d] (unknown [IPv6:2001:df8:0:8:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4CF932CDE229; Wed, 27 Jul 2011 19:27:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1-620492772; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <4E302DED.7020607@andybierman.com> Date: Wed, 27 Jul 2011 13:27:38 -0400 Message-Id: <7069F743-1947-473D-95A9-5D7F1D23C75F@cesnet.cz> References: <39E71257-6243-4DD3-857F-376DBBA4F164@cesnet.cz> <4E302DED.7020607@andybierman.com> To: Andy Bierman X-Mailer: Apple Mail (2.1084) Cc: netconf@ietf.org Subject: Re: [Netconf] concurrent access to candidate 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, 27 Jul 2011 17:27:43 -0000 --Apple-Mail-1-620492772 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 27, 2011, at 11:25 AM, Andy Bierman wrote: > On 07/27/2011 08:04 AM, Ladislav Lhotka wrote: >> Hi, >>=20 >> I'd like to clarify the options for concurrent access to candidate. = Consider the following scenario: >>=20 >> 1. An administrator works in candidate on implementing a major = reconfiguration. This may take several hours, so the admin may not be to = finish it in one session. So he applies a part of the changes and ends = the session (releasing the lock on candidate). >>=20 >> 2. A low-profile user opens a session and wants to make minor change, = e.g. change his password. His attempt to lock the candidate is refused = because of uncommited changes. So he executes "discard-changes", obtains = the lock, applies his edit and performs a commit. >>=20 >> The only chance for the admini to avoid losing his work seems to be = to keep the first session open with a lock on candidate, but this is = against the requirement that the locks be short-lived. Or am I missing = something >=20 > Why would the 2nd session even bother with discard-changes? > Most users tend to ignore locking because CLI ignores locking. OK, but then we can end up with a candidate that nobody (except = superuser) can commit, if our admin doesn't have write access to the = low-profile user's password. =20 > SNMP never had any locking. (But just because 2 technologies are = horribly > broken doesn't mean NETCONF should be just as broken. ;-) >=20 > The global candidate in NETCONF is seriously flawed. > Explicit global locking is not the best way to solve the = multiple-writers problem. > This is certainly not the way source code control systems work. >=20 > Private candidates, which utilize mandatory-to-use implicit partial = locking > is a much more robust solution. It would also solve the = commit-deadlock > problem which Wes has described many times. There would no way a = private > candidate could contain edits which could not be committed due to = access control. I have been also thinking about representing pending changes to = candidate as a list of patches. Then each patch can keep specific access = rights depending on the user that performed it. Commit would then mean = applying all these patches to running (atomically). A reply to asking for candidate could also be constructed = at any time. Lada >=20 > (I'm thinking of writing a draft, but private candidates require that > the global candidate is removed, which would make a server = non-compliant. > An optional capability is not so straight-forward.) >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >> -- >> Ladislav Lhotka, CESNET >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-1-620492772 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNzI3MTcyNzM4WjAjBgkqhkiG9w0BCQQxFgQUMRXRjBI5gz16iOCGDuNgYj2OsFUwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBbQZ791M8k0H8cxrGX/CcDVwjb XZx3sCbNIoHxSYKupaN+SYEZkIDp8mbLrsnH35tPO19yColYhcBSprc2mRaXWyn5yzw21HosKttA GV/1MWaOGF0ZTgzST+kbOwuCIHsRibQLD2HJs9TGXDPXg8O5/R/cMUh++IG50U3n2SsSrfuYPYeE B9OEqQFphNveASxagERkOJkv2GPTC3rChv2686Lk0FssqYgDrOUjhsRkKvV+86Wmt5WpUc3PvJ2s 7Ov1Er8qoJyVZ2hzpXORodEyZL+bBrZKucMU0/JJ5G1EWd8eh/2jA2xJbU1LUzDGIrQMIWU3lpFA UmJVwVgJJjbNAAAAAAAA --Apple-Mail-1-620492772-- From mbj@tail-f.com Wed Jul 27 10:43:25 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 7CCB111E80DF for ; Wed, 27 Jul 2011 10:43:25 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvNSJdEHcUp7 for ; Wed, 27 Jul 2011 10:43:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 02B6611E8075 for ; Wed, 27 Jul 2011 10:43:24 -0700 (PDT) Received: from localhost (dhcp-12ac.meeting.ietf.org [130.129.18.172]) by mail.tail-f.com (Postfix) with ESMTPSA id 87DC81200AA7; Wed, 27 Jul 2011 19:41:50 +0200 (CEST) Date: Wed, 27 Jul 2011 13:43:20 -0400 (EDT) Message-Id: <20110727.134320.128828201.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4E302DED.7020607@andybierman.com> References: <39E71257-6243-4DD3-857F-376DBBA4F164@cesnet.cz> <4E302DED.7020607@andybierman.com> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] concurrent access to candidate 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, 27 Jul 2011 17:43:25 -0000 Andy Bierman wrote: > On 07/27/2011 08:04 AM, Ladislav Lhotka wrote: > > Hi, > > > > I'd like to clarify the options for concurrent access to candidate. Consider > > the following scenario: > > > > 1. An administrator works in candidate on implementing a major > > reconfiguration. This may take several hours, so the admin may not be to > > finish it in one session. So he applies a part of the changes and ends the > > session (releasing the lock on candidate). > > > > 2. A low-profile user opens a session and wants to make minor change, > > e.g. change his password. His attempt to lock the candidate is refused > > because of uncommited changes. So he executes "discard-changes", obtains the > > lock, applies his edit and performs a commit. > > > > The only chance for the admini to avoid losing his work seems to be to keep > > the first session open with a lock on candidate, but this is against the > > requirement that the locks be short-lived. Or am I missing something > > Why would the 2nd session even bother with discard-changes? This is not the point. The solution we come up with must work also for the corner cases. This said, I agree with your statement that the global / shared candidate has its problems... IMO, this is one of them. If you work with the shared candidate you have to be prepared for things like this. The alternative - that requires access to the things that will be modified - is worse. /martin From mbj@tail-f.com Thu Jul 28 12:56:11 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 C8BE111E8153 for ; Thu, 28 Jul 2011 12:56:11 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RYi0li3nV1N for ; Thu, 28 Jul 2011 12:56:11 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 498D211E8151 for ; Thu, 28 Jul 2011 12:56:11 -0700 (PDT) Received: from localhost (dhcp-12ac.meeting.ietf.org [130.129.18.172]) by mail.tail-f.com (Postfix) with ESMTPSA id ECAFD1200AFE; Thu, 28 Jul 2011 21:54:31 +0200 (CEST) Date: Thu, 28 Jul 2011 15:56:06 -0400 (EDT) Message-Id: <20110728.155606.507589786.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110724185523.GB624@elstar.local> References: <20110724185523.GB624@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-access-control-04 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, 28 Jul 2011 19:56:11 -0000 Hi, We have updated the document taking your comments into account. See inline. Juergen Schoenwaelder wrote: > 16) Should there be a notification-default switch as well? This is covered by read-default. > 17) If I set exec-default to "deny", then nothing seems to be possible > anymore except the exchange. Even notifications require an > RPC to subscribe to a stream. So how useful is the exec-default > switch? This switch allows a deployment where all acccess rules are explicit. Some operators might want to configure their boxes in such very secure mode. > 19) My reading of the rules of procedure is that a user that does not > map into a group simply bypasses all access control rule checks > and ends up with access denied if the corresponding default switch > is set to "permit". Is this desirable behaviour? You mistype a > name in a group configuration and the result is open access? This is exactly what the default switches are used for. This is also why write-default is deny by default. This is the other end of the spectrum - once you're authenticated you get full read/write/exec access. /martin & andy From phil@juniper.net Fri Jul 29 07:47:06 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 27A8621F8C36 for ; Fri, 29 Jul 2011 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KhWqCdBAzhT for ; Fri, 29 Jul 2011 07:47:04 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E102221F8C3A for ; Fri, 29 Jul 2011 07:47:01 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTjLH5e5yS2ViFugO7vnT1Oew3lFgXyZ0@postini.com; Fri, 29 Jul 2011 07:47:04 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 29 Jul 2011 07:03:17 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p6TE3Ev62681; Fri, 29 Jul 2011 07:03:14 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p6TDalN0092145; Fri, 29 Jul 2011 13:36:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201107291336.p6TDalN0092145@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20110725.171341.488213779.mbj@tail-f.com> Date: Fri, 29 Jul 2011 09:36:47 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.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, 29 Jul 2011 14:47:06 -0000 Martin Bjorklund writes: >NEW: > leaf killed-by { > when "../termination-reason = 'killed'"; > type nc:session-id-type-or-zero; > description > "The ID of the session that terminated this session, or the > value '0' if it was terminated in some other way."; Why emit the leaf at all if it doesn't have a valuable value? Thanks, Phil From bertietf@bwijnen.net Fri Jul 29 09:30:37 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 80C6521F8565 for ; Fri, 29 Jul 2011 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFLWfP9kLYer for ; Fri, 29 Jul 2011 09:30:37 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id B589121F8562 for ; Fri, 29 Jul 2011 09:30:36 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QmpxI-0007XY-Ef for netconf@ietf.org; Fri, 29 Jul 2011 18:30:34 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-47b5.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QmpxH-0001Mc-3o for netconf@ietf.org; Fri, 29 Jul 2011 18:30:32 +0200 Message-ID: <4E32E026.5000305@bwijnen.net> Date: Fri, 29 Jul 2011 12:30:30 -0400 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1DB161.2060707@bwijnen.net> In-Reply-To: <4E1DB161.2060707@bwijnen.net> X-Forwarded-Message-Id: <4E1DB161.2060707@bwijnen.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: 86ab03e524994f79ca2c75a176445dd46c3e95d1a39d95b78775559445304c37 Subject: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-system-notifications-04.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, 29 Jul 2011 16:30:37 -0000 WG participants, Pls review BEFORE or BY August 1 if you have not already done so. A "I read it and see no issues or have no concerns" is also very welcome! I case you need a couple of days extra time (and commit a date for your review), we're willing to consider a short extension. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt Date: Wed, 13 Jul 2011 16:53:21 +0200 From: Bert (IETF) Wijnen To: netconf Dear WG participants, This document was published mid-June, and we have not had much comments sofar. So we conclude it must be ready for WG Last Call. This is a formal WG Last call for draft-ietf-netconf-system-notifications-04.txt Please review and send any comments BEFORE August 1. Best would be if you can send it BEFORE July 24, so that we can discuss any open issues during our Netconf session at IETF81 in Quebec. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Fri Jul 29 09:31:23 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 E1BFD21F8565 for ; Fri, 29 Jul 2011 09:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t76nnSmdq7S for ; Fri, 29 Jul 2011 09:31:23 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 5157F21F8489 for ; Fri, 29 Jul 2011 09:31:23 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qmpy4-0007ZC-JD for netconf@ietf.org; Fri, 29 Jul 2011 18:31:22 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-47b5.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qmpy4-0001Pa-Bk for netconf@ietf.org; Fri, 29 Jul 2011 18:31:20 +0200 Message-ID: <4E32E057.7030707@bwijnen.net> Date: Fri, 29 Jul 2011 12:31:19 -0400 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1DB164.5090007@bwijnen.net> In-Reply-To: <4E1DB164.5090007@bwijnen.net> X-Forwarded-Message-Id: <4E1DB164.5090007@bwijnen.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: 86ab03e524994f79ca2c75a176445dd403cd8d4d8e776006370fb6b8c8329ad6 Subject: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.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, 29 Jul 2011 16:31:24 -0000 WG participants, Pls review BEFORE or BY August 1 if you have not already done so. A "I read it and see no issues or have no concerns" is also very welcome! I case you need a couple of days extra time (and commit a date for your review), we're willing to consider a short extension. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control-04.txt Date: Wed, 13 Jul 2011 16:53:24 +0200 From: Bert (IETF) Wijnen To: netconf Dear WG participants, This document was published mid-June, and we have not had much comments sofar. So we conclude it must be ready for WG Last Call. This is a formal WG Last call for draft-ietf-netconf-access-control-04.txt Please review and send any comments BEFORE August 1. Best would be if you can send it BEFORE July 24, so that we can discuss any open issues during our Netconf session at IETF81 in Quebec. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf