From bertietf@bwijnen.net Mon Apr 2 01:55:12 2012 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 F056921F8871 for ; Mon, 2 Apr 2012 01:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Pv-yVKaT6t for ; Mon, 2 Apr 2012 01:55:11 -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 3B5DF21F8862 for ; Mon, 2 Apr 2012 01:55:11 -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 1SEd2b-0004ao-4r for netconf@ietf.org; Mon, 02 Apr 2012 10:55:10 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest44.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SEd2a-0007Ok-Qu for netconf@ietf.org; Mon, 02 Apr 2012 10:55:08 +0200 Message-ID: <4F79696B.7090109@bwijnen.net> Date: Mon, 02 Apr 2012 10:55:07 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 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: 86ab03e524994f79ca2c75a176445dd48112b2787c5d0bb8c7a146a3da28e42b Subject: [Netconf] accept Netconf over TLS (rfc5539bis) as a WG work item 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, 02 Apr 2012 08:55:12 -0000 From the WG summary: Update of NETCONF over TLS (5539bis): Badra presented remaining issues which he is going to address with a new I-D. The sense in the room was in favor of the draft and it will become WG item after the approval on the maillist. So anyone who is against accepting this work as a WG work item, pls speak up within the next 2 weeks. Otherwise we will include this in a new charter text. Bert and Mehmet From Jonathan.Hansford@generaldynamics.uk.com Tue Apr 3 02:29:34 2012 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 10C1C21F8616 for ; Tue, 3 Apr 2012 02:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQNsdXWqMCPa for ; Tue, 3 Apr 2012 02:29:33 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 67AE221F8514 for ; Tue, 3 Apr 2012 02:29:29 -0700 (PDT) Received: from [85.158.136.35:56021] by server-12.bemta-5.messagelabs.com id AB/9E-05587-8F2CA7F4; Tue, 03 Apr 2012 09:29:28 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-12.tower-125.messagelabs.com!1333445368!23473325!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7266 invoked from network); 3 Apr 2012 09:29:28 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-12.tower-125.messagelabs.com with SMTP; 3 Apr 2012 09:29:28 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 03 Apr 2012 10:29:26 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:29:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 10:29:26 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206952E1E@GDUKADH850.uk1.r-org.net> In-Reply-To: <4F776898.9060904@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Light or Netconf for constrained devices Thread-Index: Ac0RfEM6noYub3+yQvyjV+yIIqOHxg== References: <4F765A4F.3040805@netconfcentral.org><20120331051538.GB70150@elstar.local><4F76AA02.4030401@netconfcentral.org><20120331093809.GB70620@elstar.local><4F7701F9.7020802@netconfcentral.org><20120331142936.GA71199@elstar.local> <4F776898.9060904@netconfcentral.org> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 03 Apr 2012 09:29:27.0291 (UTC) FILETIME=[43B11CB0:01CD117C] Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 03 Apr 2012 09:29:34 -0000 For someone recently coming to NETCONF, I would have thought constrained devices would include some or all of the following characteristics: * During development, prior to release, it would be good to incrementally add NETCONF functionality without the need to add deviation statements * Device with limited CPU * Device with limited memory * Device with limited bandwidth available * Device with limited power available An example of a device that could include most of these constraints might be found on a sensor net.=20 Are there other constraints that need to be considered? Should any of these constraints preclude the use of NETCONF? If all of these can be successfully supported using vanilla NETCONF then guidance on how that could be achieved would be helpful. Thanks, Jonathan Hansford This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From andy@netconfcentral.org Tue Apr 3 03:32:26 2012 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 E234921F86A6 for ; Tue, 3 Apr 2012 03:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toZmBKJ8R3CD for ; Tue, 3 Apr 2012 03:32:26 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by ietfa.amsl.com (Postfix) with SMTP id 5F14621F861A for ; Tue, 3 Apr 2012 03:32:26 -0700 (PDT) Received: (qmail 27882 invoked from network); 3 Apr 2012 10:32:25 -0000 Received: from unknown (75.84.164.152) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 03 Apr 2012 10:32:25 -0000 Message-ID: <4F7AD1B9.3050009@netconfcentral.org> Date: Tue, 03 Apr 2012 03:32:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: netconf@ietf.org References: <4F765A4F.3040805@netconfcentral.org><20120331051538.GB70150@elstar.local><4F76AA02.4030401@netconfcentral.org><20120331093809.GB70620@elstar.local><4F7701F9.7020802@netconfcentral.org><20120331142936.GA71199@elstar.local> <4F776898.9060904@netconfcentral.org> <83C941F7F59F3F42AC017AD1E650546206952E1E@GDUKADH850.uk1.r-org.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206952E1E@GDUKADH850.uk1.r-org.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 03 Apr 2012 10:32:27 -0000 On 04/03/2012 02:29 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: > For someone recently coming to NETCONF, I would have thought constrained > devices would include some or all of the following characteristics: > > * During development, prior to release, it would be good to > incrementally add NETCONF functionality without the need to add > deviation statements > This is the only use case I find puzzling. In my experience, internal server releases to the NMS developers never use deviations. Partial functionality is often delivered, but its scope and limitations are communicated out of band. (e.g., email). > * Device with limited CPU > > * Device with limited memory > > * Device with limited bandwidth available > > * Device with limited power available > > An example of a device that could include most of these constraints > might be found on a sensor net. > > Are there other constraints that need to be considered? Should any of > these constraints preclude the use of NETCONF? > > If all of these can be successfully supported using vanilla NETCONF then > guidance on how that could be achieved would be helpful. > > Thanks, > > Jonathan Hansford > > Andy From kwatsen@juniper.net Tue Apr 3 13:22:32 2012 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 9755211E81D7 for ; Tue, 3 Apr 2012 13:22:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH0HSQaYuOxb for ; Tue, 3 Apr 2012 13:22:26 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id E27EF11E81DD for ; Tue, 3 Apr 2012 13:22:25 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT3tcAOQD36WbN3HDwf/zcqkKLJ1DKoAm@postini.com; Tue, 03 Apr 2012 13:22:25 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, 3 Apr 2012 13:22:21 -0700 From: Kent Watsen To: Andy Bierman , "netconf@ietf.org" Date: Tue, 3 Apr 2012 13:22:13 -0700 Thread-Topic: [Netconf] Netconf Light or Netconf for constrained devices Thread-Index: Ac0RhRMTz41ncoBMTM+65WxLLJxIGQAKMYqg Message-ID: <84600D05C20FF943918238042D7670FD48C0724606@EMBX01-HQ.jnpr.net> References: <4F765A4F.3040805@netconfcentral.org><20120331051538.GB70150@elstar.local><4F76AA02.4030401@netconfcentral.org><20120331093809.GB70620@elstar.local><4F7701F9.7020802@netconfcentral.org><20120331142936.GA71199@elstar.local> <4F776898.9060904@netconfcentral.org> <83C941F7F59F3F42AC017AD1E650546206952E1E@GDUKADH850.uk1.r-org.net> <4F7AD1B9.3050009@netconfcentral.org> In-Reply-To: <4F7AD1B9.3050009@netconfcentral.org> 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] Netconf Light or Netconf for constrained devices 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, 03 Apr 2012 20:22:32 -0000 [back from vacation, which is why I've been MIA for the last week] Andy writes: > >On 04/03/2012 02:29 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: >> For someone recently coming to NETCONF, I would have thought constrained >> devices would include some or all of the following characteristics: >> >> * During development, prior to release, it would be good to >> incrementally add NETCONF functionality without the need to add >> deviation statements > > This is the only use case I find puzzling. > In my experience, internal server releases to the NMS developers > never use deviations. Partial functionality is often delivered, > but its scope and limitations are communicated out of band. (e.g., email)= . We have learned the hard way that communicating limitations "out of band" d= oesn't work. It's too easy for stuff to fall through cracks, and the cruft= that builds up over time becomes unbearable to maintain, but the worst for= us is that the hacks cannot be supported without a corresponding release o= f the NMS software, which is unacceptable in some customer environments [th= is is the same reason "deviations" are a non-starter for us]. Pushing forwards, there appear that there are two distinct concerns: 1) a definition of "constrained" 2) if "netconf-zero" plus features is viable Looking at these in turn: 1) what is "constrained"? - Juergen's impetus for the draft was to support physically constrained devices. Realizing that the=20 solution to Juergen's concern overlapped with the solution=20 needed to support my "non-technical" issues, I raised it at IETF'79. Mehmet and Juergen agreed and we added it. My feelings are that the draft is still too focused on "physical constraints", when maybe the focus should be turned around to=20 look at the limitations of the NETCONF protocol itself. I wouldn't say NETCONF is "constrained", it's "constraining". IMO, looking for a definition of a "constrained device" is barking up the wrong tree. 2. is "netconf-zero + features" a viable strategy? You know, my original thought was to just allow " without subtree filtering". Jeurgen's idea was to have , , and . Then, on Jan 21, you wrote (in a PM) that ", w/o filters, and " plus correct message would suffice, but now I see you've added , , and . A lot of variance, perhaps illustrating a zero-based makes sense afterall...?=20 As mentioned above, I originally thought to just have , since it seemed all other NETCONF operations depended on it, but I now believe it's better this way, per -01, section 2.2, BP #1; which I contend *is* "relevant to IETF", since NETCONF defined the extensibility mechanism in the first place. Think of it as a sign of success, as we wouldn't have picked NETCONF otherwise ;) But the question to ask might be, what difference does it make if "light" starts with netconf-zero? Surely it's better for the devices, and it's not like the NMSs are going to implement any less NETCONF, as they're going to need it all to interoperate with other devices. So, again, what difference does it really make? FWIW, as mentioned before, my company has been developing a *data-driven* N= MS app for almost 7 years now. The app is designed to manage our entire pr= oduct line while never closing the door towards going "multi-vendor" someda= y - while my company is a "vendor", our NMS is developed in the same way th= at you'd expect from a 3rd-party developer. Our NMS implements device-adap= ters so that it can communicate NETCONF to devices that don't support it na= tively. We've worked with a number of OEM partners who already had "NETCON= F" implemented, only to discover that it didn't implement half the operatio= ns or some incorrectly, and yet our NMS still has to manage the OEM-ed devi= ce. Trust me, this isn't just the "device team is lazy" - there is much mo= re in the way. This draft has the potential to resolve many real-world iss= ues for us. PS: And I thought we'd reached the end of this discussion when you wrote: "I don't think there is enough standards value in this draft to be worth implementing, but I'll shut up now since others appear to want to implement it." http://www.ietf.org/mail-archive/web/netconf/current/msg07356.html Thanks, Kent From kwatsen@juniper.net Tue Apr 3 13:57:17 2012 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 89EF211E809D for ; Tue, 3 Apr 2012 13:57:17 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFmQZaw6ZaEQ for ; Tue, 3 Apr 2012 13:57:16 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 06AC511E80B6 for ; Tue, 3 Apr 2012 13:57:15 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT3tkJkKJGydvCfN0kKE4yIjntd9s7/Q7@postini.com; Tue, 03 Apr 2012 13:57:16 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, 3 Apr 2012 13:57:07 -0700 From: Kent Watsen To: Mohamad Badra , Alan Luchuk , Juergen Schoenwaelder Date: Tue, 3 Apr 2012 13:57:06 -0700 Thread-Topic: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis Thread-Index: Acz92IHtWBTTQbw8QOKKOHUaXPGgzAUA0qDg Message-ID: <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_84600D05C20FF943918238042D7670FD48C072467AEMBX01HQjnprn_" MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 03 Apr 2012 20:57:17 -0000 --_000_84600D05C20FF943918238042D7670FD48C072467AEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > RFC5246 doesn't support reverse proxy as well, and all RFCs' Applications= over TLS have the same above language. > > However, what about rewriting it as follow: > > The peer actively opens the TLS connection, and the server passively > listens for the incoming TLS connection. Yes, this leaves the door open better Section 2.2: what about ? - why define another mechanism? = If important, then why doesn't RFC6242 require the client to send SSH_MSG_C= HANNEL_CLOSE and/or SSH_MSG_DISCONNECT. Regardless, I disagree with the i= ntent of forcing graceful closures - in reality, devices MUST be coded to s= upport ungraceful closures and, once the code is written, there isn't much = value to a graceful close anymore. Also the second paragraph seems out of = place - shouldn't it be in the TLS RFC? [Note: this language was also in RF= C5539] I didn't see a response to this comment... > I would prefer not moving it to the "Security Considerations" and I will = replace the 1st paragraph with > > If the server's presented certificate has passed > certification path validation [RFC5280] to a configured > trust anchor, the client MUST carefully examine the > certificate presented by the server to determine if it meets the > client's expectations. Particularly, the client MUST check its > understanding of the server hostname against the server's identity as > presented in the server Certificate message, in order to prevent man- > in-the-middle attacks. Better, thanks Kent --_000_84600D05C20FF943918238042D7670FD48C072467AEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> RFC5246 doesn't support reverse proxy as well,= and all RFCs' Applications over TLS have the same above language. 

&= gt; 

> However, what about rewriting it a= s follow:

> 

= > The peer actively opens the TLS c= onnection, and the server passively

> listens for the incoming T= LS connection.

 

Yes= , this leaves the door open better

 

&= nbsp;

Section 2.2: what about <close-session>?  - w= hy define another mechanism?  If important, then why doesn't RFC6242 r= equire the client to send SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT. =   Regardless, I disagree with the intent of forcing graceful closures = - in reality, devices MUST be coded to support ungraceful closures and, onc= e the code is written, there isn't much value to a graceful close anymore. =  Also the second paragraph seems out of place - shouldn't it be in the= TLS RFC? [Note: this language was also in RFC5539]

 

I didn’t see a response to this comment…

 

 

> I would prefer not moving it to the &quo= t;Security Considerations" and I will replace the 1st paragraph with

= >

> If the server's presented certificate has passed<= o:p>

> certification path validation [RFC5280] to a configured

> = trust anchor, the client MUST carefully examine the

> cer= tificate presented by the server to determine if it meets the

> = client's expectations. Particularly, the client MUST check its

> understanding of the server hostname against the server's identity as=

>= ; presented in the server Certificate message, in order to prevent m= an-

> in-the-middle attacks.<= /o:p>

 

Better, thanks

 

 

 

Kent

 

<= /div>
= --_000_84600D05C20FF943918238042D7670FD48C072467AEMBX01HQjnprn_-- From andy@netconfcentral.org Tue Apr 3 13:59:16 2012 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 9398711E810F for ; Tue, 3 Apr 2012 13:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id papL4YjqS0ms for ; Tue, 3 Apr 2012 13:59:15 -0700 (PDT) Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) by ietfa.amsl.com (Postfix) with SMTP id D413411E809D for ; Tue, 3 Apr 2012 13:59:15 -0700 (PDT) Received: (qmail 9837 invoked from network); 3 Apr 2012 20:59:10 -0000 Received: from unknown (75.84.164.152) by p3plsmtpa08-07.prod.phx3.secureserver.net (173.201.193.108) with ESMTP; 03 Apr 2012 20:59:10 -0000 Message-ID: <4F7B649E.6090806@netconfcentral.org> Date: Tue, 03 Apr 2012 13:59:10 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Kent Watsen References: <4F765A4F.3040805@netconfcentral.org><20120331051538.GB70150@elstar.local><4F76AA02.4030401@netconfcentral.org><20120331093809.GB70620@elstar.local><4F7701F9.7020802@netconfcentral.org><20120331142936.GA71199@elstar.local> <4F776898.9060904@netconfcentral.org> <83C941F7F59F3F42AC017AD1E650546206952E1E@GDUKADH850.uk1.r-org.net> <4F7AD1B9.3050009@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C0724606@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48C0724606@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 03 Apr 2012 20:59:16 -0000 On 04/03/2012 01:22 PM, Kent Watsen wrote: > [back from vacation, which is why I've been MIA for the last week] > Nobody but the co-authors have said they want to work on the problems in sec 2.2. I think it's up to the co-chairs to decide how to proceed. Andy > > > Andy writes: >> >> On 04/03/2012 02:29 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: >>> For someone recently coming to NETCONF, I would have thought constrained >>> devices would include some or all of the following characteristics: >>> >>> * During development, prior to release, it would be good to >>> incrementally add NETCONF functionality without the need to add >>> deviation statements >> >> This is the only use case I find puzzling. >> In my experience, internal server releases to the NMS developers >> never use deviations. Partial functionality is often delivered, >> but its scope and limitations are communicated out of band. (e.g., email). > > > We have learned the hard way that communicating limitations "out of band" doesn't work. It's too easy for stuff to fall through cracks, and the cruft that builds up over time becomes unbearable to maintain, but the worst for us is that the hacks cannot be supported without a corresponding release of the NMS software, which is unacceptable in some customer environments [this is the same reason "deviations" are a non-starter for us]. > > > Pushing forwards, there appear that there are two distinct concerns: > > 1) a definition of "constrained" > 2) if "netconf-zero" plus features is viable > > > Looking at these in turn: > > 1) what is "constrained"? - Juergen's impetus for the draft was > to support physically constrained devices. Realizing that the > solution to Juergen's concern overlapped with the solution > needed to support my "non-technical" issues, I raised > it at IETF'79. Mehmet and Juergen agreed and we added it. > > My feelings are that the draft is still too focused on "physical > constraints", when maybe the focus should be turned around to > look at the limitations of the NETCONF protocol itself. I > wouldn't say NETCONF is "constrained", it's "constraining". IMO, > looking for a definition of a "constrained device" is barking > up the wrong tree. > > > 2. is "netconf-zero + features" a viable strategy? You know, my > original thought was to just allow " without subtree > filtering". Jeurgen's idea was to have,, > and. Then, on Jan 21, you wrote (in a PM) that > ", w/o filters, and" > plus correct message would suffice, but now I see you've > added,, and. A lot of variance, > perhaps illustrating a zero-based makes sense afterall...? > > As mentioned above, I originally thought to just have, > since it seemed all other NETCONF operations depended on it, but I > now believe it's better this way, per -01, section 2.2, BP #1; > which I contend *is* "relevant to IETF", since NETCONF defined > the extensibility mechanism in the first place. Think of it as > a sign of success, as we wouldn't have picked NETCONF otherwise ;) > > But the question to ask might be, what difference does it make if > "light" starts with netconf-zero? Surely it's better for the devices, > and it's not like the NMSs are going to implement any less NETCONF, > as they're going to need it all to interoperate with other devices. > So, again, what difference does it really make? > > > FWIW, as mentioned before, my company has been developing a *data-driven* NMS app for almost 7 years now. The app is designed to manage our entire product line while never closing the door towards going "multi-vendor" someday - while my company is a "vendor", our NMS is developed in the same way that you'd expect from a 3rd-party developer. Our NMS implements device-adapters so that it can communicate NETCONF to devices that don't support it natively. We've worked with a number of OEM partners who already had "NETCONF" implemented, only to discover that it didn't implement half the operations or some incorrectly, and yet our NMS still has to manage the OEM-ed device. Trust me, this isn't just the "device team is lazy" - there is much more in the way. This draft has the potential to resolve many real-world issues for us. > > > PS: And I thought we'd reached the end of this discussion when you wrote: > > "I don't think there is enough standards value in this draft > to be worth implementing, but I'll shut up now since others > appear to want to implement it." > > http://www.ietf.org/mail-archive/web/netconf/current/msg07356.html > > > > > > Thanks, > Kent > > > > > > From kwatsen@juniper.net Tue Apr 3 15:34:28 2012 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 E14CC11E80F6 for ; Tue, 3 Apr 2012 15:34:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-iYm78KBQze for ; Tue, 3 Apr 2012 15:34:28 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id A8C6C11E8086 for ; Tue, 3 Apr 2012 15:34:27 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT3t673DnM5HVqW4hufQH2avi4+n1VB+Q@postini.com; Tue, 03 Apr 2012 15:34:27 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 3 Apr 2012 15:34:22 -0700 From: Kent Watsen To: Alan Luchuk Date: Tue, 3 Apr 2012 15:34:18 -0700 Thread-Topic: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis Thread-Index: Ac0AhY20300CHOwTTfWAwyWs7DCrdQRUgy2Q Message-ID: <84600D05C20FF943918238042D7670FD48C0A290BA@EMBX01-HQ.jnpr.net> References: <201203121922.PAA06844@adminfs.snmp.com> In-Reply-To: <201203121922.PAA06844@adminfs.snmp.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 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 03 Apr 2012 22:34:29 -0000 Hi Alan, Delayed response, but hopefully still helpful >>Section 3.2.1 - What happens if subjectAltName contains more than one=20 >>ipAddress, dnsName, or rfc822Name - as allowed by RFC 5280 section 4.2.1.= 6? > >Only the first ipAddress, dnsName, or rfc822Name is used; subsequent ones >are ignored. How about the following text (note the new paragraph)? > > > o Extract the subjectAltName's rfc822Name from the certificate, then > use the extracted rfc822Name as the NETCONF username; > > o Extract the subjectAltName's dnsName from the certificate, then > use the extracted dnsName as the NETCONF username; > > o Extract the subjectAltName's iPAddress from the certificate, then > use the extracted iPAddress as the NETCONF username; > > o Examine the subjectAltName's rfc822Name, dnsName, and iPAddress > fields in a pre-defined order. Return the value from the first > subjectAltName field that is examined, defined, and populated with > a non-empty value. If no subjectAltName field of a specific type > is defined, then the examination skips that field and proceeds to > examine the next field type. If a subjectAltName field is > defined, but the value is not populated, or is populated by an > empty value, then the examination skips that field and proceeds to > examine the next field type. > > If the subjectAltName contains more than one rfc822Name, dnsName, or=20 > iPAddress, then only the first rfc822Name, dnsName, or iPAddress is > extracted and used. Subsequent rfc822Names, dnsNames, or iPAddresses > are ignored. > > The NETCONF server MUST implement all of these algorithms, and allow > the deployer to choose the algorithm used. The certificate-to- > username-transforms container in the ietf-netconf-tls YANG module > specifies how a NETCONF server transforms a certificate into a > NETCONF username. That addresses the ambiguity issue, but is it OK? I mean, what happens if = by bad luck the device is multi-homed and the ipAddress or dnsName facing t= he NETCONF server happens to not be the first listed? - it is possible, ri= ght? Maybe not very likely though... It think it's OK, assuming the proba= bility is near zero. To Wes's point, it certainly good to have cross-proto= col equality when possible... >>Section 3.2.1.1 - This whole section should be rewritten - it's hard to=20 >>follow as is. I think there is an implicit assumption that the client's= =20 >>certificate is trusted; that is, that the TLS layer would not have allowe= d=20 >>the connection if couldn't validate the certificate. Does this assumption= =20 >>need to be stated explicitly? Third paragraph is about being able to=20 >>apply transformation based on the identification of the issuing CA, a=20 >good idea, but shouldn't this be after exhausting all direct-match options= .=20 >Lastly, what is a "transformation container"? > > >How about completely replacing the existing text in section 3.2.1.1 with=20 >the following text: > > >3.2.1.1. Identifying a Certificate > > The ietf-netconf-tls YANG module identifies the TLS certificate by > the "fingerprint" of the certificate presented by the peer. The=20 > certificate fingerprint is a string of octets composed of a 1-octet=20 > hashing algorithm identifier followed by the results of the hashing=20 > algorithm. The 1-octet hashing algorithm identifier is encoded with=20 > values taken from the IANA TLS HashAlgorithm Registry (RFC 5246). > Implementations are not required to implement all of the hash > algorithms listed in the IANA TLS HashAlgorithm Registry (RFC 5246). > > If a locally held copy of a trusted CA certificate is configured in > the certificate-to-username-transforms container of the ietf-netconf-tl= s=20 > YANG module, and that CA certificate was used to validate the path to=20 > the presented certificate, then the NETCONF server SHOULD derive the > NETCONF username from that entry in the certificate-to-username-transfo= rms=20 > container of the ietf-netconf-tls YANG module. In this case, the same > NETCONF username will be derived from all presented certificates=20 > that have been validated by the CA certificate configured in the =09 > certificate-to-username-transforms container of the ietf-netconf-tls=20 > YANG module. The first paragraph reads much better - thanks! But I feel there are a number of unanswered questions from my paragraph abo= ve. Stated another way, I still don't understand how to implement it. > Yes, the second sentence is redundent and should be deleted. The text=20 > should read: > > description > "This module applies to NETCONF over TLS. It specifies how > NETCONF servers transform X.509 certificates presented by > clients into NETCONF usernames. Looks good, thanks >The suggestions sound reasonable. How about changing the typedef and >YANG object to: > > typedef tls-fingerprint-type { > type binary { > length "1..255"; > } Better now that min-length has been bumped from '0' to '1' >>Regarding "certificate-to-username-transform-count"...=20 >>Regarding "certificate-to-username-transform-last-changed"... > > These are patterned after informational objects in the SNMP-TLS-TM-MIB. = =20 > I have no strong preference whether or not these are retained in the=20 > YANG module. Resetting the value to 0 is intended to allow implementatio= n=20 > on devices that cannot keep time across reboots. =20 If they're not referenced, then I don't believe they have any value and thu= s imagine they should be removed. >>Regarding "certificate-to-username-transforms" >> 1) the statement "the client's presented certificate MUST either be=20 >> validated based on an established trust anchor, or it MUST directly= =20 >> match a fingerprint in this container." is ... > >I think you understand correctly -- this is an OR choice. This text is=20 >strongly patterned after the description clause of the snmpTlstmCertTo- >TSNTable on Page 41 of RFC 6353. I have no preference about how this=20 >should work, but people with more security experience than I thought it=20 >was a useful idea for mapping certificates to usernames, so it was copied >in the ietf-netconf-tls YANG module. Matching RFC 6353 is good - thanks for pointing that out >> 2) the statement "If the list entry's certificate-fingerprint value=20 >> matches that of a locally held copy of a trusted CA certificate, and= =20 >> that CA certificate was used to validate the path to the presented=20 >> certificate, then consider the list entry as a successful match." -= =20 >> what is the "path"? - do you mean the certificate chain? - how does= =20 >> the server know this? I need to see an example. =20 > >I think the words "path" and "certificate chain" are used interchangably >in RFC 6353. Would changing "path" to "certificate chain" be sufficient >here? =20 To resolve the ambiguity question, yes, thanks >The basic idea is that multiple certificates can easily be mapped to a=20 >single NETCONF username. In some situations, this is conceptually easier= =20 >and reduces the configuration of the certificate-to-username-transforms=20 >container. =20 > >For example, let's say a network operations group has 10 network operators= ,=20 >each of which has a personal certificate that identifies a single operator= . >Let's also say that the network operations group has a CA that signs these >personal certificates. Rather than having to configure 10 individual=20 >certificate-to-username-transforms in a NETCONF server, one for each netwo= rk >operator, a single certificate-to-username-transform could be configured >for the network operations CA certificate. This single entry might be >mapped to the NETCONF username "NetworkOperator", and access rights grante= d >to this single NETCONF username. I understood that part. When I said "see an example", I meant regarding ho= w the cert chain is passed. Let's say we have an Issuer called myTrustedCA= , that signs a cert for someUnknownCA, that signs someUserCert. The device= is configured to trust myTrustedCA and the client logging in presents some= UserCert - how can the device allow this connection is the cert chain isn't= passed? Thanks, Kent From j.schoenwaelder@jacobs-university.de Wed Apr 4 00:52:47 2012 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 A57FD21F8621 for ; Wed, 4 Apr 2012 00:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.839 X-Spam-Level: X-Spam-Status: No, score=-101.839 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIhY+62vi5np for ; Wed, 4 Apr 2012 00:52:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ED48921F865C for ; Wed, 4 Apr 2012 00:52:46 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23F9420C2E; Wed, 4 Apr 2012 09:52:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8Tf4a9-dOzQX; Wed, 4 Apr 2012 09:52:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1ECEC20C24; Wed, 4 Apr 2012 09:52:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8DA071E2DF54; Wed, 4 Apr 2012 09:52:45 +0200 (CEST) Date: Wed, 4 Apr 2012 09:52:45 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120404075245.GA13871@elstar.local> Mail-Followup-To: Kent Watsen , Alan Luchuk , "mbadra@gmail.com" , "netconf@ietf.org" References: <201203121922.PAA06844@adminfs.snmp.com> <84600D05C20FF943918238042D7670FD48C0A290BA@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48C0A290BA@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 04 Apr 2012 07:52:47 -0000 On Tue, Apr 03, 2012 at 03:34:18PM -0700, Kent Watsen wrote: > >The suggestions sound reasonable. How about changing the typedef and > >YANG object to: > > > > typedef tls-fingerprint-type { > > type binary { > > length "1..255"; > > } > > Better now that min-length has been bumped from '0' to '1' I had a discussion about this with Martin. While SNMP adds the byte identifying the has algorithm to the hash value so that updates are atomic, I think in a YANG world this looks kind of awkward. I would rather see something like this in a config representation: de:ad:...:be:ef Most tools that compute fingerprints do not seem to produce the format with the embedded code for the hash algorithm. To achieve the above, we would need an IANA controlled grouping such that we achieve crypto agility. > >>Regarding "certificate-to-username-transform-count"... > >>Regarding "certificate-to-username-transform-last-changed"... > > > > These are patterned after informational objects in the SNMP-TLS-TM-MIB. > > I have no strong preference whether or not these are retained in the > > YANG module. Resetting the value to 0 is intended to allow implementation > > on devices that cannot keep time across reboots. > > If they're not referenced, then I don't believe they have any value and thus imagine they should be removed. The last one we do not really need since we have config change notifications (in case someone is interested to be notified). The counter - well not really essential either; I guess I prefer to keep this data model config true only. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Jonathan.Hansford@generaldynamics.uk.com Wed Apr 4 01:36:16 2012 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 1958421F8688 for ; Wed, 4 Apr 2012 01:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGzhVy5OvZle for ; Wed, 4 Apr 2012 01:36:15 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id A8D5B21F867F for ; Wed, 4 Apr 2012 01:36:14 -0700 (PDT) Received: from [85.158.137.83:34613] by server-9.bemta-3.messagelabs.com id 8B/68-10923-DF70C7F4; Wed, 04 Apr 2012 08:36:13 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-5.tower-140.messagelabs.com!1333528572!23898006!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27022 invoked from network); 4 Apr 2012 08:36:12 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-5.tower-140.messagelabs.com with SMTP; 4 Apr 2012 08:36:12 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 04 Apr 2012 09:36:11 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 09:36:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 09:36:10 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E6505462069530E5@GDUKADH850.uk1.r-org.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48C0724606@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Light or Netconf for constrained devices Thread-Index: Ac0SPfzmnfz8DqdMSHyQAtkOkJxiGA== References: <4F765A4F.3040805@netconfcentral.org><20120331051538.GB70150@elstar.local><4F76AA02.4030401@netconfcentral.org><20120331093809.GB70620@elstar.local><4F7701F9.7020802@netconfcentral.org><20120331142936.GA71199@elstar.local><4F776898.9060904@netconfcentral.org><83C941F7F59F3F42AC017AD1E650546206952E1E@GDUKADH850.uk1.r-org.net><4F7AD1B9.3050009@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C0724606@EMBX01-HQ.jnpr.net> From: To: , , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 04 Apr 2012 08:36:12.0432 (UTC) FILETIME=[FDD21100:01CD123D] Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 04 Apr 2012 08:36:16 -0000 > Kent writes: >=20 > [back from vacation, which is why I've been MIA for the last week] >=20 >=20 >=20 > Andy writes: > > > >On 04/03/2012 02:29 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: > >> For someone recently coming to NETCONF, I would have thought > constrained > >> devices would include some or all of the following characteristics: > >> > >> * During development, prior to release, it would be good to > >> incrementally add NETCONF functionality without the need to add > >> deviation statements > > > > This is the only use case I find puzzling. > > In my experience, internal server releases to the NMS developers > > never use deviations. Partial functionality is often delivered, > > but its scope and limitations are communicated out of band. (e.g., > email). >=20 >=20 > We have learned the hard way that communicating limitations "out of band" > doesn't work. It's too easy for stuff to fall through cracks, and the > cruft that builds up over time becomes unbearable to maintain, but the > worst for us is that the hacks cannot be supported without a corresponding > release of the NMS software, which is unacceptable in some customer > environments [this is the same reason "deviations" are a non-starter for > us]. >=20 Particularly if the NMS is a 3rd-party development (as Kent indicated below). One of the operator requirements brought out in RFC3535 states: 4. It is necessary to enable operators to concentrate on the configuration of the network as a whole rather than individual devices. That is most easily achieved if either all network products are from a single supplier and managed through their NMS or network products are from multiple suppliers managed through a generic "3rd-party" NMS. >=20 > Pushing forwards, there appear that there are two distinct concerns: >=20 > 1) a definition of "constrained" > 2) if "netconf-zero" plus features is viable >=20 >=20 > Looking at these in turn: >=20 > 1) what is "constrained"? - Juergen's impetus for the draft was > to support physically constrained devices. Realizing that the > solution to Juergen's concern overlapped with the solution > needed to support my "non-technical" issues, I raised > it at IETF'79. Mehmet and Juergen agreed and we added it. >=20 > My feelings are that the draft is still too focused on "physical > constraints", when maybe the focus should be turned around to > look at the limitations of the NETCONF protocol itself. I > wouldn't say NETCONF is "constrained", it's "constraining". IMO, > looking for a definition of a "constrained device" is barking > up the wrong tree. >=20 >=20 > 2. is "netconf-zero + features" a viable strategy? You know, my > original thought was to just allow " without subtree > filtering". Jeurgen's idea was to have , , > and . Then, on Jan 21, you wrote (in a PM) that > ", w/o filters, and " > plus correct message would suffice, but now I see you've > added , , and . A lot of variance, > perhaps illustrating a zero-based makes sense afterall...? >=20 > As mentioned above, I originally thought to just have , > since it seemed all other NETCONF operations depended on it, but I > now believe it's better this way, per -01, section 2.2, BP #1; > which I contend *is* "relevant to IETF", since NETCONF defined > the extensibility mechanism in the first place. Think of it as > a sign of success, as we wouldn't have picked NETCONF otherwise ;) >=20 > But the question to ask might be, what difference does it make if > "light" starts with netconf-zero? Surely it's better for the > devices, > and it's not like the NMSs are going to implement any less NETCONF, > as they're going to need it all to interoperate with other devices. > So, again, what difference does it really make? >=20 >=20 > FWIW, as mentioned before, my company has been developing a *data-driven* > NMS app for almost 7 years now. The app is designed to manage our entire > product line while never closing the door towards going "multi-vendor" > someday - while my company is a "vendor", our NMS is developed in the same > way that you'd expect from a 3rd-party developer. Our NMS implements > device-adapters so that it can communicate NETCONF to devices that don't > support it natively. We've worked with a number of OEM partners who > already had "NETCONF" implemented, only to discover that it didn't > implement half the operations or some incorrectly, and yet our NMS still > has to manage the OEM-ed device. Trust me, this isn't just the "device > team is lazy" - there is much more in the way. This draft has the > potential to resolve many real-world issues for us. >=20 >=20 > PS: And I thought we'd reached the end of this discussion when you wrote: >=20 > "I don't think there is enough standards value in this draft > to be worth implementing, but I'll shut up now since others > appear to want to implement it." >=20 > http://www.ietf.org/mail-archive/web/netconf/current/msg07356.html >=20 >=20 >=20 >=20 >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From phil@juniper.net Wed Apr 4 05:06:57 2012 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 537CD21F8736 for ; Wed, 4 Apr 2012 05:06:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL8pc5olo4G2 for ; Wed, 4 Apr 2012 05:06:56 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id F278A21F8735 for ; Wed, 4 Apr 2012 05:06:53 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT3w5XW/+4gme1YO1c842twrCsX6PVOmy@postini.com; Wed, 04 Apr 2012 05:06:56 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.3.213.0; Wed, 4 Apr 2012 05:06:39 -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 q34C6Y121875; Wed, 4 Apr 2012 05:06:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q34C75u7013612; Wed, 4 Apr 2012 08:07:06 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201204041207.q34C75u7013612@idle.juniper.net> To: In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462069530E5@GDUKADH850.uk1.r-org.net> Date: Wed, 4 Apr 2012 08:07:05 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 04 Apr 2012 12:06:57 -0000 Jonathan.Hansford@generaldynamics.uk.com writes: >One of the operator requirements brought out in RFC3535 states: > >4. It is necessary to enable operators to concentrate on the > configuration of the network as a whole rather than individual > devices. > >That is most easily achieved if either all network products are from a >single supplier and managed through their NMS or network products are >from multiple suppliers managed through a generic "3rd-party" NMS. I think the key need here is to stop seeing device models as the target, but to instead model networks at a higher level. We could model LAN segments and point-to-point links and assign protocol features to them (ip prefix, OSPF area) instead of repeating the same config values for each device in the network. With appropriate models, error checking become automatic and simple. Opportunities for errors disappear, as the config values are entered in a single place (can't set the an inconsistent OSPF area number if you set it for the LAN segment). Difficult errors become trivial (easy to check that every interface connected to a LAN segment fits into the segment's IP prefix). Whole classes of impossible-to-find errors (like misconfiguring the encoding on an unnumbered point-to-point link) simply vanish. The NMS would generate generic device-centric configuration that would be translated into specific device config based on the make, model, and role of that device. Thanks, Phil From andy@netconfcentral.org Wed Apr 4 05:23:09 2012 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 1F3A121F86D6 for ; Wed, 4 Apr 2012 05:23:09 -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_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7fFODknz9mV for ; Wed, 4 Apr 2012 05:23:08 -0700 (PDT) Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) by ietfa.amsl.com (Postfix) with SMTP id 940B921F86D0 for ; Wed, 4 Apr 2012 05:23:08 -0700 (PDT) Received: (qmail 22190 invoked from network); 4 Apr 2012 12:23:07 -0000 Received: from unknown (75.84.164.152) by p3plsmtpa06-08.prod.phx3.secureserver.net (173.201.192.109) with ESMTP; 04 Apr 2012 12:23:07 -0000 Message-ID: <4F7C3D2B.2030805@netconfcentral.org> Date: Wed, 04 Apr 2012 05:23:07 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Phil Shafer References: <201204041207.q34C75u7013612@idle.juniper.net> In-Reply-To: <201204041207.q34C75u7013612@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 04 Apr 2012 12:23:09 -0000 On 04/04/2012 05:07 AM, Phil Shafer wrote: > Jonathan.Hansford@generaldynamics.uk.com writes: >> One of the operator requirements brought out in RFC3535 states: >> >> 4. It is necessary to enable operators to concentrate on the >> configuration of the network as a whole rather than individual >> devices. >> >> That is most easily achieved if either all network products are from a >> single supplier and managed through their NMS or network products are >>from multiple suppliers managed through a generic "3rd-party" NMS. > > I think the key need here is to stop seeing device models as the > target, but to instead model networks at a higher level. We could > model LAN segments and point-to-point links and assign protocol > features to them (ip prefix, OSPF area) instead of repeating the > same config values for each device in the network. > > With appropriate models, error checking become automatic and simple. > Opportunities for errors disappear, as the config values are entered > in a single place (can't set the an inconsistent OSPF area number > if you set it for the LAN segment). Difficult errors become trivial > (easy to check that every interface connected to a LAN segment fits > into the segment's IP prefix). Whole classes of impossible-to-find > errors (like misconfiguring the encoding on an unnumbered point-to-point > link) simply vanish. > > The NMS would generate generic device-centric configuration that > would be translated into specific device config based on the > make, model, and role of that device. > While very interesting, this thread has nothing to do with NETCONF for Constrained Devices. But I can use this opportunity to remind Phil that we are still waiting for his draft on network-wide configuration since the Maastricht IETF in July 2010. ;-) I think a network-wide data model that could run on an EMS would be a good standard. Back to this thread -- in order for a 3rd party NMS to do useful work, the developers need to code to a core API. Purely optional APIs are avoided at all cost, because alternate coding efforts to accomplish the same task will be needed for the devices that do not implement the optional features. NMS developers like NETCONF precisely because the mandatory-to-implement subset provides enough utility to avoid additional coding efforts. Unless NC4CD provides full CM CRUD operations in some form, I don't see how it helps. > Thanks, > Phil > > Andy From j.schoenwaelder@jacobs-university.de Wed Apr 4 09:30:58 2012 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 0862621F8762 for ; Wed, 4 Apr 2012 09:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE6r6OIHC80n for ; Wed, 4 Apr 2012 09:30:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0354521F875A for ; Wed, 4 Apr 2012 09:30:57 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B3C520C45; Wed, 4 Apr 2012 18:30:56 +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 fxscmRQji8Ml; Wed, 4 Apr 2012 18:30: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 BF78E20C37; Wed, 4 Apr 2012 18:30:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 454081E2EA62; Wed, 4 Apr 2012 18:30:57 +0200 (CEST) Date: Wed, 4 Apr 2012 18:30:57 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120404163057.GA14879@elstar.local> Mail-Followup-To: Andy Bierman , "'netconf@ietf.org'" References: <4F765A4F.3040805@netconfcentral.org> <20120331051538.GB70150@elstar.local> <4F76AA02.4030401@netconfcentral.org> <20120331093809.GB70620@elstar.local> <4F7701F9.7020802@netconfcentral.org> <20120331142936.GA71199@elstar.local> <4F776898.9060904@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F776898.9060904@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'netconf@ietf.org'" Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 04 Apr 2012 16:30:58 -0000 On Sat, Mar 31, 2012 at 01:27:04PM -0700, Andy Bierman wrote: > ... > >You correctly figured out that section 2 provides two motivations > >(sections 2.1 and 2.2) but you incorrectly lump them together thereby > >creating noise but not a sound argument. > > So you admit that sec. 2.2 has nothing to do with constrained devices. I think you are aware of the history of this document and the discussions around it. Its all openly documented, there is nothing I have to admit. > Because the WG chairs asked if people wanted to work on > NETCONF for constrained devices. They did not ask if the > WG wants to work on NETCONF Light. Please remember that -00 was already called NETCONF Light. > If the WG comes to some consensus on the problem space, then > we can talk about your 'feature-based' solution that doesn't > actually work because there are no corresponding if-feature > statements in the ietf-netconf module that would make the > new features relevant in YANG. We can augment if-feature statements into ietf-netconf.yang if you think this is the proper way of doing things. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Wed Apr 4 11:31:09 2012 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 142E221F8775 for ; Wed, 4 Apr 2012 11:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJQj4BWX6ooL for ; Wed, 4 Apr 2012 11:31:08 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAE021F8773 for ; Wed, 4 Apr 2012 11:31:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jBVvh8AcxvbmSNH4C/W6Ba42eS5Gcda1uByMPHtxPo4P2YMq0vfjnggzX7R+0w0x; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.76] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SFUz0-0000xh-SL for netconf@ietf.org; Wed, 04 Apr 2012 14:31:03 -0400 Message-ID: <003c01cd1291$2bc374c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201204041207.q34C75u7013612@idle.juniper.net> Date: Wed, 4 Apr 2012 11:31:35 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f8882df3079af01976a01f47cb87aec3879350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.76 Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices 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, 04 Apr 2012 18:31:09 -0000 Hi - > From: "Phil Shafer" > To: > Cc: > Sent: Wednesday, April 04, 2012 5:07 AM > Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices ... > I think the key need here is to stop seeing device models as the > target, but to instead model networks at a higher level. We could > model LAN segments and point-to-point links and assign protocol > features to them (ip prefix, OSPF area) instead of repeating the > same config values for each device in the network. Yes! This was one of the approaches discussed at the IAB workshop oh-so-many years ago. One of the concepts there was that network operational parameters (configuration in terms of how the *network* was supposed to work) could be systematically tranformed (via XSLT, for example) into vendor- and device-specific stuff. But I don't see this as being the path that netconf and netmod have taken, so I think this is just idle woulda shoulda coulda speculation, too far beyond the scope of what the IETF would be willing to imagine. > With appropriate models, error checking become automatic and simple. > Opportunities for errors disappear, as the config values are entered > in a single place (can't set the an inconsistent OSPF area number > if you set it for the LAN segment). Difficult errors become trivial > (easy to check that every interface connected to a LAN segment fits > into the segment's IP prefix). Whole classes of impossible-to-find > errors (like misconfiguring the encoding on an unnumbered point-to-point > link) simply vanish. But because there are necessarily transformations (including, unfortunately, possible additions of information, ex nihilo from the network's perspective) to get the device- and vendor-specific stuff, you need *real* configuration management, perhaps along the lines of long-expired draft-presuhn-nmwebdav. > The NMS would generate generic device-centric configuration that > would be translated into specific device config based on the > make, model, and role of that device. This is where "proper" CM rears its ugly head. If you want to be able to be able to revert to the configuration in effect at a particular point in time, even if the NMS has changed, it is necessary to have what the NMS generated under configuration management as well, in case, for example, someone messed with the XSLTs. Randy From mbadra@gmail.com Wed Apr 4 14:54:47 2012 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 2A6DB21F864B for ; Wed, 4 Apr 2012 14:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e51vs4DoJNiQ for ; Wed, 4 Apr 2012 14:54:46 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA421F8642 for ; Wed, 4 Apr 2012 14:54:46 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so739464vbb.31 for ; Wed, 04 Apr 2012 14:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gfTvks1qEAAtJsPsQXeNGsOTqO5xyvepdvo+zhxNPf8=; b=DFV6qEzI8hPlAf0/tHi8pXPGt1ra05d0LMr3yXsX4IDhq/5KVWxiZQ4XHydvMDNYU3 ggUyjVkVllKYWVZZQHQHpmX2z5a5PkipKRbZfr1AaLwrjYtGBXx9h66V3B9+nQ9Rly6+ tSp1K285+wqVcEHSKB15iVNEgMfL4GqHyvNas2AIX3Pvffb739IUxeaxuf/HVm03ecmp ++homgfT+e3AvZT1QCGfvXdY/snLD3HHdfxQ+LgxM7M2j8lco9Puq60ExbS6lbgfasBb 8JZzfbeGRQ36rYbI9oCwS1aCkH0F10v5fORVAFKPa6IF+D0BpyaL9duxocwg8K4ET4Qd 8QHA== MIME-Version: 1.0 Received: by 10.52.27.1 with SMTP id p1mr117400vdg.17.1333576485590; Wed, 04 Apr 2012 14:54:45 -0700 (PDT) Received: by 10.220.0.201 with HTTP; Wed, 4 Apr 2012 14:54:45 -0700 (PDT) In-Reply-To: <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> Date: Wed, 4 Apr 2012 23:54:45 +0200 Message-ID: From: Mohamad Badra To: Kent Watsen Content-Type: multipart/alternative; boundary=20cf307d00f8b4555304bce17831 Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 04 Apr 2012 21:54:47 -0000 --20cf307d00f8b4555304bce17831 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen wrote: > Section 2.2: what about ? - why define another mechanism? > If important, then why doesn't RFC6242 require the client to send > SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT. Regardless, I disagree > with the intent of forcing graceful closures - in reality, devices MUST b= e > coded to support ungraceful closures and, once the code is written, there > isn't much value to a graceful close anymore. Also the second paragraph > seems out of place - shouldn't it be in the TLS RFC? [Note: this language > was also in RFC5539]**** > > ** ** > > I didn=92t see a response to this comment=85**** > > > Juergen already commented on this point: "Proper closure of the TLS session is important to be able to distinguish a proper closing of the session from a potentially malicious closing of the session. I guess the same applies for SSH. Sure, you can't prevent arbitrary TCP failures but a proper shutdown procedure tells the other end that the closure was done by intention. In other words, from a security point of view, I think RFC6242 should have also encouraged proper SSH shutdown." Moreover, in RFC5246, Section 7.2.1: The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack Also: Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice. Some TLS1.0 implementations which receive a connection close without first receiving a valid closure alert MUST NOT reuse the TLS session. Best regards, Badra --20cf307d00f8b4555304bce17831 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2012 at 10:57 PM= , Kent Watsen <= kwatsen@juniper.net> wrote:

Sectio= n 2.2: what about <close-session>? =A0- why define another mechanism?= =A0If important, then why doesn't RFC6242 require the client to send S= SH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT. =A0 Regardless, I disagree = with the intent of forcing graceful closures - in reality, devices MUST be = coded to support ungraceful closures and, once the code is written, there i= sn't much value to a graceful close anymore. =A0Also the second paragra= ph seems out of place - shouldn't it be in the TLS RFC? [Note: this lan= guage was also in RFC5539]

=A0

I didn=92t see a response to this comment=85

=A0


=
Juergen already commented on this point:
"Proper closure of the TLS session is important to be able to
distinguish a proper closing of the session from a potentially<= /span>
malicious closing of the session. I guess the s= ame applies for
SSH. Sure, you can't preven= t arbitrary TCP failures but a proper
shutdown procedure tells the other end that the closure was don= e by
intention. In other words, from a security= point of view, I think
RFC6242 should have als= o encouraged proper SSH shutdown."

Moreover, in=A0RFC5246, Sectio= n 7.2.1:

  The client and the server must share knowledge that the connection is=A0<=
/pre>
=A0 =A0ending in order to avoid a t=
runcation attack
=A0
Also:

<=
div>
      Note that as of TLS 1.1,
      failure to properly close a connection no longer requires that a
      session not be resumed.  This is a change from TLS 1.0 to conform
      with widespread implementation practice.


Some TLS1.0=A0imp=
lementations which receive a co=
nnection close without first receiving a valid closure alert MUST NOT reuse the TLS session.

Best regard= s,
Badra
--20cf307d00f8b4555304bce17831-- From j.schoenwaelder@jacobs-university.de Thu Apr 5 03:19:58 2012 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 447A521F86E8 for ; Thu, 5 Apr 2012 03:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80C+Vr4yJVp8 for ; Thu, 5 Apr 2012 03:19:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 43EDA21F864F for ; Thu, 5 Apr 2012 03:19:56 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D15720C24; Thu, 5 Apr 2012 12:19:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 669gi8MgbCyP; Thu, 5 Apr 2012 12:19:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EE7920C22; Thu, 5 Apr 2012 12:19:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E27A81E5641F; Thu, 5 Apr 2012 12:19:54 +0200 (CEST) Date: Thu, 5 Apr 2012 12:19:54 +0200 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20120405101954.GC10272@elstar.local> Mail-Followup-To: Mohamad Badra , Kent Watsen , Alan Luchuk , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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: Thu, 05 Apr 2012 10:19:58 -0000 On Wed, Apr 04, 2012 at 11:54:45PM +0200, Mohamad Badra wrote: > On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen wrote: > > > Section 2.2: what about ? - why define another mechanism? > > If important, then why doesn't RFC6242 require the client to send > > SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT. Regardless, I disagree > > with the intent of forcing graceful closures - in reality, devices MUST be > > coded to support ungraceful closures and, once the code is written, there > > isn't much value to a graceful close anymore. Also the second paragraph > > seems out of place - shouldn't it be in the TLS RFC? [Note: this language > > was also in RFC5539]**** > > > > ** ** > > > > I didn’t see a response to this comment…**** > > > > > > > > > Juergen already commented on this point: > "Proper closure of the TLS session is important to be able to > distinguish a proper closing of the session from a potentially > malicious closing of the session. I guess the same applies for > SSH. Sure, you can't prevent arbitrary TCP failures but a proper > shutdown procedure tells the other end that the closure was done by > intention. In other words, from a security point of view, I think > RFC6242 should have also encouraged proper SSH shutdown." > Perhaps we need to add an explanation (e.g. to the security considerations) so that implementors realize that proper closing of a session has merits and that improper session aborts can be a sign of an attack. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Thu Apr 5 14:25:54 2012 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 E9E0F21F8686 for ; Thu, 5 Apr 2012 14:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 527A1wWld-sY for ; Thu, 5 Apr 2012 14:25:54 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6728421F860E for ; Thu, 5 Apr 2012 14:25:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1155470ghb.31 for ; Thu, 05 Apr 2012 14:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lLt5xY8TTJ+IvWBAQliUzPvDOwNwC34U9FEbghjNYHM=; b=dsFrhYX1ZxGAOnZh2Z5E+S+CXCRKt0/NAhZl14eqmgFor9TULbA/RL4eTx6a/IptF/ XIMF0OMdhhvmOHeu5YDCLLjcRMl/RumG4XpRDiCPY/vl+LxR7/Ti5YcNP6+xX0Rzyh/C O9vapBBlFttzmS2XPnZgeuwVxsGfdf6ouoZiYGhZqEuXzBPmXrzzn25mtJ3p4aiehPm4 MJSoR06QeQt8dRVbt7DbRXC7PDuobyMNfT9U2llivkpGzdrqkAEJxQKeNnnjS/Qr+gai 2m3A5cIVesMICg4vCL5knV4m0K/k42R9GLzoYt1O/WEW/1Y+kyvzpwl1KZSypQQ9j6gd /utg== MIME-Version: 1.0 Received: by 10.236.77.106 with SMTP id c70mr4198634yhe.85.1333661154018; Thu, 05 Apr 2012 14:25:54 -0700 (PDT) Received: by 10.220.0.201 with HTTP; Thu, 5 Apr 2012 14:25:53 -0700 (PDT) In-Reply-To: <20120405101954.GC10272@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <20120405101954.GC10272@elstar.local> Date: Thu, 5 Apr 2012 23:25:53 +0200 Message-ID: From: Mohamad Badra To: Juergen Schoenwaelder , Mohamad Badra , Kent Watsen , Alan Luchuk , Netconf Content-Type: multipart/alternative; boundary=20cf3005120656051b04bcf52f22 Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 05 Apr 2012 21:25:55 -0000 --20cf3005120656051b04bcf52f22 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 5, 2012 at 12:19 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Apr 04, 2012 at 11:54:45PM +0200, Mohamad Badra wrote: > > On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen > wrote: > Perhaps we need to add an explanation (e.g. to the security > considerations) so that implementors realize that proper closing of a > session has merits and that improper session aborts can be a sign of > an attack. > > What about adding the following to the Security Considerations: To help prevent a truncation attack, the peer that is closing the NETCONF session MUST send a TLS close_notify alert and MUST receive a responding close_notify alert from the other peer before terminating the underlying TCP connection. Best regards Badra --20cf3005120656051b04bcf52f22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 5, 2012 at = 12:19 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Wed, Apr 04, 2012 at 11= :54:45PM +0200, Mohamad Badra wrote:
> On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen <kwatsen@juniper.net> wrote:
Perhaps we ne= ed to add an explanation (e.g. to the security
considerations) so that implementors realize that proper closing of a
session has merits and that improper session aborts can be a sign of
an attack.

<= br>

What about adding the following to the Securit= y Considerations:

To help prevent a truncatio= n attack, the peer that is closing the NETCONF
session MUST send a TLS close_notify alert and MUST receive a respondi= ng
close_notify alert from the other peer before terminating the = underlying
TCP connection.

Best re= gards
Badra
--20cf3005120656051b04bcf52f22-- From j.schoenwaelder@jacobs-university.de Thu Apr 5 15:26:26 2012 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 5F82321F85D0 for ; Thu, 5 Apr 2012 15:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.045 X-Spam-Level: X-Spam-Status: No, score=-103.045 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsJMOWYYalWL for ; Thu, 5 Apr 2012 15:26:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A0A1D21F858F for ; Thu, 5 Apr 2012 15:26:25 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C0B920BE9; Fri, 6 Apr 2012 00:26:24 +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 OwU5KgDT0fnf; Fri, 6 Apr 2012 00:26: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 0DB4220BE6; Fri, 6 Apr 2012 00:26:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E1F611E58447; Fri, 6 Apr 2012 00:26:23 +0200 (CEST) Date: Fri, 6 Apr 2012 00:26:23 +0200 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20120405222623.GA15695@elstar.local> Mail-Followup-To: Mohamad Badra , Kent Watsen , Alan Luchuk , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <20120405101954.GC10272@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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: Thu, 05 Apr 2012 22:26:26 -0000 On Thu, Apr 05, 2012 at 11:25:53PM +0200, Mohamad Badra wrote: > On Thu, Apr 5, 2012 at 12:19 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Apr 04, 2012 at 11:54:45PM +0200, Mohamad Badra wrote: > > > On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen > > wrote: > > Perhaps we need to add an explanation (e.g. to the security > > considerations) so that implementors realize that proper closing of a > > session has merits and that improper session aborts can be a sign of > > an attack. > > > > > > What about adding the following to the Security Considerations: > > To help prevent a truncation attack, the peer that is closing the NETCONF > session MUST send a TLS close_notify alert and MUST receive a responding > close_notify alert from the other peer before terminating the underlying > TCP connection. Well, this does not really _prevent_ a truncation attack. Using a close_notify allows the peer only to recognize that it was not facing a potential truncation attack. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Fri Apr 6 00:51:32 2012 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 4ED3A21F848C for ; Fri, 6 Apr 2012 00:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uak4T+HUE8-p for ; Fri, 6 Apr 2012 00:51:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECA721F848A for ; Fri, 6 Apr 2012 00:51:27 -0700 (PDT) Received: by yenm5 with SMTP id m5so1336970yen.31 for ; Fri, 06 Apr 2012 00:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=anotxLrAxpUHQ/dOKPhAIiWC/jTvhlf5AGaJ6A0lnZI=; b=gJGsqtERa4cpQxRdl0m7+CveqwkVJwSZbf0M6BxCygJcrnU7eDH2r9wsG1d5nyzZjJ 4rsXVsGWXJJDJ4Gn7c4hseMkje63BSsZ4HMJOU4yJJep2c8jo8ePB6vcOiZRtIMiR71K MZqwOZbs4s79IW0qNBMPUG3AfylbIGM5r6kA/7udRwNEIuyuSiLKcHKtCIfm11UKpvMV QlmxB5zBANb4EwjnWuy7IquA1EeCWsj4FoD3f3RJQRTQCtLACx4h4i5kVQUbseVjWUdR jSWSpFk9CEHJgFbNwfuHLh7ROBNt/6X+jg/I9HtxGqjQvusokjSrfRd7XYsSv4zcQmBY JldA== MIME-Version: 1.0 Received: by 10.100.246.24 with SMTP id t24mr1909146anh.0.1333698686937; Fri, 06 Apr 2012 00:51:26 -0700 (PDT) Received: by 10.220.0.201 with HTTP; Fri, 6 Apr 2012 00:51:26 -0700 (PDT) In-Reply-To: <20120405222623.GA15695@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <20120405101954.GC10272@elstar.local> <20120405222623.GA15695@elstar.local> Date: Fri, 6 Apr 2012 09:51:26 +0200 Message-ID: From: Mohamad Badra To: Juergen Schoenwaelder , Mohamad Badra , Kent Watsen , Alan Luchuk , Netconf Content-Type: multipart/alternative; boundary=0016e68ea05b78ed5804bcfdec2b Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 06 Apr 2012 07:51:32 -0000 --0016e68ea05b78ed5804bcfdec2b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 6, 2012 at 12:26 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 05, 2012 at 11:25:53PM +0200, Mohamad Badra wrote: > > On Thu, Apr 5, 2012 at 12:19 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Wed, Apr 04, 2012 at 11:54:45PM +0200, Mohamad Badra wrote: > > > > On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen > > > wrote: > > > Perhaps we need to add an explanation (e.g. to the security > > > considerations) so that implementors realize that proper closing of a > > > session has merits and that improper session aborts can be a sign of > > > an attack. > > > > > > > > > > What about adding the following to the Security Considerations: > > > > To help prevent a truncation attack, the peer that is closing the NETCONF > > session MUST send a TLS close_notify alert and MUST receive a responding > > close_notify alert from the other peer before terminating the underlying > > TCP connection. > > Well, this does not really _prevent_ a truncation attack. Using a > close_notify allows the peer only to recognize that it was not facing > a potential truncation attack. > > in RFC5246, The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. What about: To help avoid a truncation attack, the peer that is closing the NETCONF session MUST send a TLS close_notify alert and MUST receive a responding close_notify alert from the other peer before terminating the underlying TCP connection. Kindly don't hesitate to send text that matches better the situation Best regards Badra --0016e68ea05b78ed5804bcfdec2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 6, 2012 at = 12:26 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On T= hu, Apr 05, 2012 at 11:25:53PM +0200, Mohamad Badra wrote:
> On Thu, Apr 5, 2012 at 12:19 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Wed, Apr 04, 2012 at 11:54:45PM +0200, Mohamad Badra wrote: > > > On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen <kwatsen@juniper.net>
> > wrote:
> > Perhaps we need to add an explanation (e.g. to the security
> > considerations) so that implementors realize that proper closing = of a
> > session has merits and that improper session aborts can be a sign= of
> > an attack.
> >
> >
>
> What about adding the following to the Security Considerations:
>
> To help prevent a truncation attack, the peer that is closing the NETC= ONF
> session MUST send a TLS close_notify alert and MUST receive a respondi= ng
> close_notify alert from the other peer before terminating the underlyi= ng
> TCP connection.

Well, this does not really _prevent_ a truncation attack. Using= a
close_notify allows the peer only to recognize that it was not facing
a potential truncation attack.

<= br>
in RFC5246,=A0The client and th= e server must share knowledge that the connection is=A0ending in order to avoid a truncation attack. 

What about:
To help avoid a truncation attack, the= peer that is closing the NETCONF
session MUST send a TLS close_notify alert and MUST receive a respondingclose_notify alert from the other peer before terminating the underlying
TCP connection.

Kindly don't hesitate t= o send text that matches better the situation
Best regards
Badra
--0016e68ea05b78ed5804bcfdec2b-- From j.schoenwaelder@jacobs-university.de Fri Apr 6 03:01:58 2012 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 8C65121F858E for ; Fri, 6 Apr 2012 03:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.061 X-Spam-Level: X-Spam-Status: No, score=-103.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXlFWAmvt-jn for ; Fri, 6 Apr 2012 03:01:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 039AE21F8533 for ; Fri, 6 Apr 2012 03:01:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 144CD20C74; Fri, 6 Apr 2012 12:01:56 +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 8NQCRe-oKN0K; Fri, 6 Apr 2012 12:01:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55B1B20C73; Fri, 6 Apr 2012 12:01:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 77F351E58A5B; Fri, 6 Apr 2012 12:01:55 +0200 (CEST) Date: Fri, 6 Apr 2012 12:01:55 +0200 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20120406100155.GA16574@elstar.local> Mail-Followup-To: Mohamad Badra , Kent Watsen , Alan Luchuk , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <20120405101954.GC10272@elstar.local> <20120405222623.GA15695@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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: Fri, 06 Apr 2012 10:01:58 -0000 On Fri, Apr 06, 2012 at 09:51:26AM +0200, Mohamad Badra wrote: > in RFC5246, The client and the server must share knowledge that the > connection is ending in order to avoid a truncation attack. > > > What about: > > To help avoid a truncation attack, the peer that is closing the NETCONF > session MUST send a TLS close_notify alert and MUST receive a responding > close_notify alert from the other peer before terminating the underlying > TCP connection. > I would prefer to minimize the text we have in this document and instead we should simply refer to Section 7.2.1 in RFC 5246. The wording in RFC 5246 is indeed irritating as welll since close_notify does not "avoid" truncation attacks. The real questions is: What should an implementation running over TLS do if there is no close_notify. I do not think we have an answer to this question and if at the end the implementations do proceed pretty much in the same way regardless whether there has been a close_notify or not, then Phil is at the end effectively right. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Sat Apr 7 08:40:53 2012 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 C134B21F853D for ; Sat, 7 Apr 2012 08:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztQu0EEFtE8W for ; Sat, 7 Apr 2012 08:40:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBA921F8541 for ; Sat, 7 Apr 2012 08:40:51 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1913646vbb.31 for ; Sat, 07 Apr 2012 08:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cBGvjU4uzssW7ruwhe+Va3sS/bb0ObK/mAr1kU6a3QY=; b=0lTQxxzDsZ5TUEwoAsu1ECXC391kGvpTK5sLX+sqMWoIknIfhYfDY2HecZ5gIUDns7 ShFsf3aaWvmtwdaEwQs17+kzPKjIXb4NiyyL7G3FGCFsXYU79XezxIxu15HyWSR09fUu SJlmuWxFIw6TiiaTVqbxuwrHHdfhVRxa9rHL8zcoXXe4QySOh+TFqiwZ7aqKQMJCWwOA 5I//uS2rziPLQ+a3V4DNmtoAuOp706cZbcSswh+56OHtt7Lw+FNIULivLeGncr711boD oaoWrQego99FLWEslS3IxE8NPu4ybzLMkFx9h4yeE6ss/18oePti+jNNMpkJJkrl+cVN D8Yw== MIME-Version: 1.0 Received: by 10.220.116.73 with SMTP id l9mr881293vcq.36.1333813251063; Sat, 07 Apr 2012 08:40:51 -0700 (PDT) Received: by 10.220.0.201 with HTTP; Sat, 7 Apr 2012 08:40:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Apr 2012 17:40:50 +0200 Message-ID: From: Mohamad Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=f46d042fdd0206c01904bd189963 Subject: [Netconf] Updating RFC 5539: Server Identity 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, 07 Apr 2012 15:40:53 -0000 --f46d042fdd0206c01904bd189963 Content-Type: text/plain; charset=ISO-8859-1 Dear All, One point I forgot to include to my presentation during last IETF is the server identity. In fact, RFC6125 specifies recommended procedures for representing and verifying application service identity in certificates intended for use in application protocols employing TLS. I would propose updating parts of Section 3.1. of draft-badra-netconf-rfc5539bis as follows: REPLACE: Matching is performed according to the rules below (following the example of [RFC4642 ]): o The client MUST use the server hostname it used to open the connection (or the hostname specified in the TLS "server_name" extension [RFC5246 ]) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. o If a subjectAltName extension of type dNSName is present in the certificate, it MUST be used as the source of the server's identity. o Matching is case-insensitive. o A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. o If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable. WITH: Matching is performed according to the rules and guidelines defined in RFC6125. Comments? Best regards, Badra --f46d042fdd0206c01904bd189963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,

On= e point I forgot to include to my presentation during last IETF is the serv= er identity. In fact,=A0RFC6125 specifies recommended procedures for repres= enting and verifying application service identity in certificates intended = for use in application protocols employing TLS.

I would propose updating parts of Section 3.1. of = draft-badra-netconf-rfc5539bis as follows:

REPLACE= :

   Matching is performed according to the rules below (following the
   example of [RFC4642]):

   o  The client MUST use the server hostname it used to open the
      connection (or the hostname specified in the TLS "server_name&qu=
ot;
      extension [RFC5246<=
/a>]) as the value to compare against the server
      name as expressed in the server certificate.  The client MUST NOT
      use any form of the server hostname derived from an insecure
      remote source (e.g., insecure DNS lookup).  CNAME canonicalization
      is not done.

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it MUST be used as the source of the server's
      identity.

   o  Matching is case-insensitive.

   o  A "*" wildcard character MAY be used as the leftmost name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

   o  If the certificate contains multiple names (e.g., more than one
      dNSName field), then a match with any one of the fields is
      considered acceptable.

WITH:

=A0 =A0Matching is performed according to the rules and gui= delines defined
=A0 =A0in RFC6125.

Comments?
Best regards,
Badra
--f46d042fdd0206c01904bd189963-- From mbadra@gmail.com Sat Apr 7 10:22:23 2012 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 4567321F84D0 for ; Sat, 7 Apr 2012 10:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTLaBMnb5MBG for ; Sat, 7 Apr 2012 10:22:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D14D21F84C5 for ; Sat, 7 Apr 2012 10:22:22 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1421761vcb.31 for ; Sat, 07 Apr 2012 10:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lotGBFqMgvnYDqPxsCRNG2m5AlNgEoiOqtZrYHaNhQ8=; b=JMoiNWErQPIrm2nuP0IPEAoAGql0ezUkX1zh3cG2wMOZOsBRlsZXT36GXhy4hYRg41 s4YPy4RDqjtq4zJ6ptAPuzC/tBdwrqfSwN1CSay7CL44qcX48rJfF+RjYeXz69TzWjEQ w5NyUFcuuZBFMm18xJ0FiqQHp/p2FjYDPaTgEGNv+tL+1filXMY6oaIsRjzkAkSttCFy vPxdbuHr+OAgdetUe7vXN/oYzJsX+jeGeafUaZJ2S/MJkN/1LUts0ovwXwdYd9iafeyr O6sfI9oZL0nOxSbCHffkSi5MH+tJI76aLbk+MpIqTHukuv9oiRe7RQbpALhjn4HzFDRG svag== MIME-Version: 1.0 Received: by 10.220.116.73 with SMTP id l9mr1000241vcq.36.1333819341932; Sat, 07 Apr 2012 10:22:21 -0700 (PDT) Received: by 10.220.0.201 with HTTP; Sat, 7 Apr 2012 10:22:21 -0700 (PDT) In-Reply-To: <20120406100155.GA16574@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <20120405101954.GC10272@elstar.local> <20120405222623.GA15695@elstar.local> <20120406100155.GA16574@elstar.local> Date: Sat, 7 Apr 2012 19:22:21 +0200 Message-ID: From: Mohamad Badra To: Juergen Schoenwaelder , Mohamad Badra , Kent Watsen , Alan Luchuk , Netconf Content-Type: multipart/alternative; boundary=f46d042fdd02120a6b04bd1a047e Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 07 Apr 2012 17:22:23 -0000 --f46d042fdd02120a6b04bd1a047e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 6, 2012 at 12:01 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 06, 2012 at 09:51:26AM +0200, Mohamad Badra wrote: > > in RFC5246, The client and the server must share knowledge that the > > connection is ending in order to avoid a truncation attack. > > > > > > What about: > > > > To help avoid a truncation attack, the peer that is closing the NETCONF > > session MUST send a TLS close_notify alert and MUST receive a responding > > close_notify alert from the other peer before terminating the underlying > > TCP connection. > > > > I would prefer to minimize the text we have in this document and > instead we should simply refer to Section 7.2.1 in RFC 5246. The > wording in RFC 5246 is indeed irritating as welll since close_notify > does not "avoid" truncation attacks. > > TLS close_notify is integrity protected and has a final result. In this optic, close_notify helps to avoid truncation attack. In RFC4422: A protocol can defend against these attacks by ensuring that each information exchange has a clear final result and that each protocol session has a graceful closure mechanism, and that these are integrity protected. The real questions is: What should an implementation running over TLS > do if there is no close_notify. I do not think we have an answer to > this question and if at the end the implementations do proceed pretty > much in the same way regardless whether there has been a close_notify > or not, then Phil is at the end effectively right If thenwhat about replacing Section 2.2 of the document with (extracted from rfc6242) Exiting NETCONF is accomplished using the operation. A NETCONF server will process NETCONF messages from the NETCONF client in the order in which they are received. When the NETCONF server processes a operation, the NETCONF server SHALL respond and close the TLS session channel. The NETCONF server MUST NOT process any NETCONF messages received after the operation. The TLS session is closed as described in RFC5246 Section 7.2.1 Comments? Best regards, Badra --f46d042fdd02120a6b04bd1a047e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 6, 2012 at 12:01 PM, Juergen Schoenw= aelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Apr 06, 2012 at 09:51:26AM +020= 0, Mohamad Badra wrote:
> in RFC5246, The client and the server must share knowledge that the > connection is ending in order to avoid a truncation attack.
>
>
> What about:
>
> To help avoid a truncation attack, the peer that is closing the NETCON= F
> session MUST send a TLS close_notify alert and MUST receive a respondi= ng
> close_notify alert from the other peer before terminating the underlyi= ng
> TCP connection.
>

I would prefer to minimize the text we have in this document and
instead we should simply refer to Section 7.2.1 in RFC 5246. The
wording in RFC 5246 is indeed irritating as welll since close_notify
does not "avoid" truncation attacks.


TLS close_notify is=A0integrity protec= ted and=A0has a final result. In this optic,=A0close_notify=A0helps to avoi= d truncation attack.

<= div>In RFC4422:=A0
A protocol can defend against these attacks by ensuring that each
= information exchange has a clear final result and that each protocol
= session has a graceful closure mechanism, and that these are=A0
integrity protected.=A0


The real questions is: What should an implementation running over TLS
do if there is no close_notify. I do not think we have an answer to
this question and if at the end the implementations do proceed pretty
much in the same way regardless whether there has been a close_notify
or not, then Phil is at the end effectively right

If thenwhat about replacing Section 2.2 of the document with (extrac= ted from rfc6242)

   Exiting NETCONF is accomplished using the <close-session> oper=
ation. A=20
   NETCONF server will process NETCONF messages from the NETCONF client=20
   in the order in which they are received.  When the NETCONF server=20
   processes a <close-session> operation, the NETCONF server SHALL=20
   respond and close the TLS session channel.  The NETCONF server MUST=20
   NOT process any NETCONF messages received after the <close-session>=
;=20
   operation. The TLS session is closed as described in RFC5246 Section=20
   7.2.1
Comments?
Best regards,
Badra=A0
--f46d042fdd02120a6b04bd1a047e-- From j.schoenwaelder@jacobs-university.de Sat Apr 7 13:46:46 2012 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 3AA6521F84A7 for ; Sat, 7 Apr 2012 13:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.074 X-Spam-Level: X-Spam-Status: No, score=-103.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni5ZSAH+swkI for ; Sat, 7 Apr 2012 13:46:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5321F849C for ; Sat, 7 Apr 2012 13:46:44 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4600B20968; Sat, 7 Apr 2012 22:46:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Rdc_I0CBjH6N; Sat, 7 Apr 2012 22:46:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 710DB20BE4; Sat, 7 Apr 2012 22:46:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A80F1E5998E; Sat, 7 Apr 2012 22:46:42 +0200 (CEST) Date: Sat, 7 Apr 2012 22:46:42 +0200 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20120407204641.GA19378@elstar.local> Mail-Followup-To: Mohamad Badra , Kent Watsen , Alan Luchuk , Netconf References: <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <20120405101954.GC10272@elstar.local> <20120405222623.GA15695@elstar.local> <20120406100155.GA16574@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 20:46:46 -0000 On Sat, Apr 07, 2012 at 07:22:21PM +0200, Mohamad Badra wrote: > > If thenwhat about replacing Section 2.2 of the document with (extracted > from rfc6242) > > Exiting NETCONF is accomplished using the operation. A > NETCONF server will process NETCONF messages from the NETCONF client > in the order in which they are received. When the NETCONF server > processes a operation, the NETCONF server SHALL > respond and close the TLS session channel. The NETCONF server MUST > NOT process any NETCONF messages received after the > operation. The TLS session is closed as described in RFC5246 Section > 7.2.1 > > Comments? This looks good and sufficient to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Mon Apr 9 12:04:50 2012 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 39A5E21F87FA for ; Mon, 9 Apr 2012 12:04:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+tG-F0fWi6E for ; Mon, 9 Apr 2012 12:04:49 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1921F87C4 for ; Mon, 9 Apr 2012 12:04:48 -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 DSNKT4Myxo8HckeOKyIDOBG3rbYJcXcHb7d4@postini.com; Mon, 09 Apr 2012 12:04:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 9 Apr 2012 12:04:28 -0700 From: Kent Watsen To: Mohamad Badra Date: Mon, 9 Apr 2012 12:04:26 -0700 Thread-Topic: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis Thread-Index: Ac0SrY6mm13xKxpTSviChmoc181pHwDxPnJA Message-ID: <84600D05C20FF943918238042D7670FD48C0C1E5C4@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 09 Apr 2012 19:04:50 -0000 > Moreover, in=A0RFC5246, Section 7.2.1: >=20 > > The client and the server must share knowledge that the connection is=A0 >=A0=A0ending in order to avoid a truncation attack =A0 I don't think it's possible for a TCP-based protocol to avoid a truncation = attack (unless using IPSEC) - a protocol can only detect that a truncation = occurred, by having an explicit close message (e.g. close_notify). I check= ed RFC5246's Errata page and didn't see a clarification, do you think it sh= ould be reported? > Also: > > Note that as of TLS 1.1, > failure to properly close a connection no longer requires that a > session not be resumed. This is a change from TLS 1.0 to conform > with widespread implementation practice. > > Some TLS1.0=A0implementations which receive a connection close without fi= rst receiving a > valid closure alert MUST NOT reuse the TLS session. Unwinding the double-negative and what not, it says "a TLS session MAY be r= esumed if it was closed improperly" (i.e. via SSL_set_session()). Session= resumption is an optimization primarily for HTTPS servers as it enables th= e RSA/DH steps to be skipped as the browser connects/disconnects the server= throughout a user's session. Bringing this to NETCONF, it means that NETC= ONF clients MAY try to resume a TLS session and that NETCONF servers MUST s= upport session resumption (ideally via rfc5077). I wonder how much app-lev= el coding is required - looking at OpenSSL source, it seems that the resump= tion logic must be coded into the app-layer... From kwatsen@juniper.net Mon Apr 9 12:09:46 2012 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 21F6121F87D3 for ; Mon, 9 Apr 2012 12:09:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB+XENi3UKuZ for ; Mon, 9 Apr 2012 12:09:45 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7996121F87C7 for ; Mon, 9 Apr 2012 12:09:45 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT4Mz9UcYr5u7hpt6JtSIPuYr5MWiGNUR@postini.com; Mon, 09 Apr 2012 12:09:45 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; Mon, 9 Apr 2012 12:09:23 -0700 From: Kent Watsen To: Juergen Schoenwaelder , Mohamad Badra Date: Mon, 9 Apr 2012 12:09:22 -0700 Thread-Topic: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis Thread-Index: Ac0U/4zvK2A5pVfUQUS9EW6si1GDiQBfJtmQ Message-ID: <84600D05C20FF943918238042D7670FD48C0C1E5DA@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <20120405101954.GC10272@elstar.local> <20120405222623.GA15695@elstar.local> <20120406100155.GA16574@elstar.local> <20120407204641.GA19378@elstar.local> In-Reply-To: <20120407204641.GA19378@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: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 09 Apr 2012 19:09:46 -0000 >> If then what about replacing Section 2.2 of the document with (extracted >> from rfc6242) >>=20 >> Exiting NETCONF is accomplished using the operation. = A >> NETCONF server will process NETCONF messages from the NETCONF client >> in the order in which they are received. When the NETCONF server >> processes a operation, the NETCONF server SHALL >> respond and close the TLS session channel. The NETCONF server MUST >> NOT process any NETCONF messages received after the >> operation. The TLS session is closed as described in RFC5246 Section >> 7.2.1 >>=20 >> Comments? > > This looks good and sufficient to me. Agreed From mbadra@gmail.com Mon Apr 9 12:41:00 2012 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 323FC21F87C7 for ; Mon, 9 Apr 2012 12:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzoBXMhRXddE for ; Mon, 9 Apr 2012 12:40:59 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 840C421F87C3 for ; Mon, 9 Apr 2012 12:40:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2954676vbb.31 for ; Mon, 09 Apr 2012 12:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5o10Rmknuki9fEmeLYF+eQy1mKwxIRXnUgjcLse56HM=; b=kIhSZ1/HxxcsNuI0lAW7nQCriTq7J+3iXrh+Ipk8P3LpITP2PM0QfxfmVC7iuXmG+Y +sDq1VXBk8qKgPXrtqEQvm9Yd4BMpNbBvr95IJVsiqTnWWRwqH6KBdrFsVLX5zDAbvmP /M9pFexgJVKFZzr823CLsA7MlMwoc414L9Uds3W8jxA/i9U1RG3DoIfJIP1KbiNYTpl4 Sl7/JRfrl612jaBrWNXic+zwJUHhF61xB3pgYRHqvwGIEveqhm/KvoL4A7ERRlQhsePN 8nsrIP2oOK1QCAOppwJr2fGfbwl4Oqe23MXyhjRJN6aUkPDeKRLoGy7zmc200tuBX09y NG+w== MIME-Version: 1.0 Received: by 10.52.22.148 with SMTP id d20mr3433961vdf.102.1334000458957; Mon, 09 Apr 2012 12:40:58 -0700 (PDT) Received: by 10.220.0.201 with HTTP; Mon, 9 Apr 2012 12:40:58 -0700 (PDT) In-Reply-To: <84600D05C20FF943918238042D7670FD48C0C1E5C4@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C072467A@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD48C0C1E5C4@EMBX01-HQ.jnpr.net> Date: Mon, 9 Apr 2012 21:40:58 +0200 Message-ID: From: Mohamad Badra To: Kent Watsen Content-Type: multipart/alternative; boundary=20cf307d00f07c81db04bd442f81 Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis 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, 09 Apr 2012 19:41:00 -0000 --20cf307d00f07c81db04bd442f81 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 9, 2012 at 9:04 PM, Kent Watsen wrote: > > > > > Moreover, in RFC5246, Section 7.2.1: > > > > > > The client and the server must share knowledge that the connection is > > ending in order to avoid a truncation attack > > I don't think it's possible for a TCP-based protocol to avoid a truncation > attack (unless using IPSEC) - a protocol can only detect that a truncation > occurred, by having an explicit close message (e.g. close_notify). I > checked RFC5246's Errata page and didn't see a clarification, do you think > it should be reported? I totally agree with you, and I believe it should be reported. Best regards, Badra --20cf307d00f07c81db04bd442f81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 9, 2012 at = 9:04 PM, Kent Watsen <kwatsen@juniper.net> wrote:



> Moreover, in=A0RFC5246, Section 7.2.1:
>
>
> =A0The client and the server must share knowledge that the connection = is=A0
>=A0=A0ending in order to avoid a truncation attack
=A0
I don't think it's possible for a TCP-based protocol to avoid= a truncation attack (unless using IPSEC) - a protocol can only detect that= a truncation occurred, by having an explicit close message (e.g. close_not= ify). =A0I checked RFC5246's Errata page and didn't see a clarifica= tion, do you think it should be reported?

I totally agree with you, and I believe it should be re= ported.
Best regards,
Badra
--20cf307d00f07c81db04bd442f81-- From luchuk@snmp.com Wed Apr 11 08:37:08 2012 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 8DC5421F84F2 for ; Wed, 11 Apr 2012 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msV6kTvYTPdk for ; Wed, 11 Apr 2012 08:37:07 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id B9BF821F84CE for ; Wed, 11 Apr 2012 08:37:05 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA19414; Wed, 11 Apr 2012 11:37:04 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id LAA15744; Wed, 11 Apr 2012 11:36:59 -0400 (EDT) Date: Wed, 11 Apr 2012 11:36:59 -0400 (EDT) From: Alan Luchuk Message-Id: <201204111536.LAA15744@adminfs.snmp.com> To: netconf@ietf.org Subject: [Netconf] Updates to the ietf-netconf-tls.yang module 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, 11 Apr 2012 15:37:08 -0000 Hello, Related to updates to draft-badra-netconf-rfc5539bis-01.txt, after reviewing the NETCONF WG E-mail comments about the ietf-netconf-tls YANG module, I've updated it and included it with this E-mail. Almost all of the suggested changes have been incorporated, including: - a number of editorial/textual changes; - features for certficiates or psk; - shorter names in the certificate container; - removed a couple of scalars; - added an import for ietf-netconf-acm; - removed a number of enums from the map-type object - the ISMS WG omitted the additional enumerations from the SNMP-TLS-TM-MIB because the additional enumerations added complexity without much benefit; - changed description references to "path" to "certificate chain"; - changed certificate-fingerprint so it's representation on the wire would be more YANG-like; Regards, --Alan file "ietf-netconf-tls@2012-04-11.yang" module ietf-netconf-tls { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-tls"; prefix "nctls"; import ietf-yang-types { prefix yang; } import ietf-netconf-acm { prefix nacm; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Mehmet Ersue WG Chair: Bert Wijnen Editor: Mohamad Badra "; description "This module applies to NETCONF over TLS. It specifies how NETCONF servers transform X.509 certificates presented by clients into NETCONF usernames. It also specifies how NETCONF servers transform pre-shared TLS keys into NETCONF usernames. This YANG module is patterned after parts of the SNMP-TLS-TM-MIB defined in RFC 6353. Much of the description text has been copied directly from the SNMP-TLS-TM-MIB, and modified as necessary. Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and // remove this note // RFC Ed.: please update the date to the date of publication revision "2012-04-11" { description "Incorporates comments on draft-badra-netconf-rfc5539bis-01.txt."; reference "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; } revision "2012-02-13" { description "Initial version"; reference "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; } feature map-certificates { description "The :map-certificates capability implements mapping X.509 certificates to NETCONF user names."; } feature map-pre-shared-keys { description "The :map-pre-shared-keys capability implements mapping TLS pre-shared keys to NETCONF user names."; } typedef tls-fingerprint-type { type binary { length "1..max"; } description "A cryptographic signature (fingerprint) value that can be used to uniquely reference other data of potentially arbitrary length."; } // // Objects related to deriving NETCONF usernames from X.509 // certificates. // container cert-mappings { if-feature map-certificates; config true; description "This container is used by a NETCONF server to map the NETCONF client's presented X.509 certificate to a NETCONF username. On an incoming TLS connection, the client's presented certificate MUST either be validated based on an established trust anchor, or it MUST directly match a fingerprint in this container. This container does not provide any mechanisms for configuring the trust anchors; the transfer of any needed trusted certificates for certificate chain validation is expected to occur through an out-of-band transfer. Once the certificate has been found acceptable (either by certificate chain validation or directly matching a fingerprint in this container), this container is consulted to determine the appropriate NETCONF username to associate with the remote connection. This is done by considering each list entry from this container in prioritized order according to its index value. Each list entry's fingerprint value determines whether the list entry is a match for the incoming connection: 1) If the list entry's fingerprint value matches that of the presented certificate, then consider the list entry as a successful match. 2) If the list entry's fingerprint value matches that of a locally held copy of a trusted CA certificate, and that CA certificate was part of the CA certificate chain to the presented certificate, then consider the list entry as a successful match. This feature lets the NETCONF server derive NETCONF usernames from all certificates signed by the trusted CA certificate. The NETCONF server will derive all NETCONF usernames using the same derivation algorithm. The NETCONF server requires only a single list entry to configure this behavior. Once a matching list entry has been found, the NETCONF server uses the map-type value to determine how the NETCONF username associated with the session should be determined. See the map- type leaf's description for details on determining the NETCONF username value. If it is impossible to determine a NETCONF username from the list entry's data combined with the data presented in the certificate, then additional list entries MUST be searched looking for another potential match. If a resulting NETCONF username mapped from a given list entry is not compatible with the needed requirements of a NETCONF username, then it MUST be considered an invalid match and additional list entries MUST be searched looking for another potential match. If no matching and valid list entry can be found, then the NETCONF server MUST close the connection, and MUST NOT accept NETCONF messages over it. Non-consecutive values of index are acceptable and implementations should continue to the next highest numbered list entry. It is recommended that administrators skip index values to leave room for the insertion of future list entries (for example, use values of 10 and 20 when creating initial list entries). Security administrators are encouraged to make use of certificates with subjectAltName fields that can be used as NETCONF usernames so that a single root CA certificate can allow all child certificate's subjectAltName to map directly to a NETCONF usernames via a 1:1 transformation. However, this container is flexible to allow for situations where existing deployed certificate infrastructures do not provide adequate subjectAltName values for use as NETCONF usernames."; list cert-map { key "index"; description "A single list entry that specifies a mapping for an incoming TLS certificate to a NETCONF username."; leaf index { type uint32 { range "1..4294967295"; } description "A unique, prioritized index for the given entry. Lower numbers indicate a higher priority."; } container fingerprint { choice algorithm-and-hash { leaf md5 { type tls-fingerprint-type; } leaf sha1 { type tls-fingerprint-type; } leaf sha224 { type tls-fingerprint-type; } leaf sha256 { type tls-fingerprint-type; } leaf sha384 { type tls-fingerprint-type; } leaf sha512 { type tls-fingerprint-type; } description "Specifies the signature algorithm and cryptographic signature (fingerprint) used to identify an X.509 certificate. Implementations of this YANG module MAY, but are not required to, implement all of these cryptographic signature algorithms. Implementations of this YANG module MUST implement at least one of these cryptographic signature algorithms. The available choices may be extended in the future as stronger cryptographic signature algorithms become available and are deemed necessary."; reference "RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2; Section 7.4.1.4.1, Signature Algorithms"; } // choice algorithm-and-hash } // container fingerprint leaf map-type { type enumeration { enum specified { value 1; } enum rfc822Name { value 2; } enum dnsName { value 3; } enum ipAddress { value 4; } enum rfc822Name-dnsName-ipAddress { value 5; } } description "Specifies the algorithm for deriving a NETCONF username from a certificate. If a mapping succeeds, then it will return a NETCONF username. If the resulting mapped value is not compatible with the needed requirements of a NETCONF username, then subsequent list entries MUST be searched for additional NETCONF username matches to look for a mapping that succeeds. For each enumerated value listed above, the NETCONF server derives the NETCONF from the presented client certificate as described: specified Directly specifies the NETCONF username to be used for this certificate. The value of the NETCONF username to use is specified in the data leaf of the list. The data leaf MUST contain a non-zero length value or the mapping described in this list entry MUST be considered a failure. rfc822Name Maps a subjectAltName's rfc822Name to a NETCONF username. The local part of the rfc822Name is passed unaltered but the host-part of the name MUST be passed in lowercase. This mapping results in a 1:1 correspondence between equivalent subjectAltName rfc822Name values and NETCONF username values except that the host-part of the name MUST be passed in lowercase. Example rfc822Name Field: FooBar@Example.COM is mapped to NETCONF username: FooBar@example.com. dnsName Maps a subjectAltName's dNSName to a NETCONF username after first converting it to all lowercase (RFC 5280 does not specify converting to lowercase so this involves an extra step). This mapping results in a 1:1 correspondence between subjectAltName dNSName values and the NETCONF username values. reference: RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. ipAddress Maps a subjectAltName's iPAddress to a NETCONF username by transforming the binary encoded address as follows: 1) for IPv4, the value is converted into a decimal-dotted quad address (e.g., '192.0.2.1'). 2) for IPv6 addresses, the value is converted into a 32-character all lowercase hexadecimal string without any colon separators. This mapping results in a 1:1 correspondence between subjectAltName iPAddress values and the NETCONF username values. rfc822Name-dnsName-ipAddress The NETCONF server derives the NETCONF username from the subjectAltName fields rfc822Name, dnsName, and ipAddress, as described in sections above. This enumeration specifies the NETCONF server first examines the rfc822Name, then examines the dnsName, then finally examines the ipAddress. The first matching subjectAltName value found in the certificate MUST be used when deriving the NETCONF username. These mappings result in a 1:1 correspondence between subjectAltName values and NETCONF username values. The sub-mapping algorithms produced by these combined algorithms cannot produce conflicting results between themselves."; } // leaf map-type leaf data { type string { length "1..max"; } description "Auxiliary data used as optional configuration information for a given mapping specified by the map-type leaf. Only some mapping systems will make use of this leaf. When the NETCONF server derives the NETCONF username from the client's presented certificate, the value in this leaf MUST be ignored for any mapping type that does not require data present in this leaf."; } } // list cert-map } // container cert-mappings // // Objects related to deriving NETCONF usernames from TLS pre-shared // keys. // container psk-map { if-feature map-pre-shared-keys; list psk { key psk-identity; leaf psk-identity { type string; description "The PSK identity encoded as a UTF-8 string."; reference "RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)"; } leaf user-name { type nacm:user-name-type; mandatory true; description "The NETCONF username associated with this PSK identity."; } leaf valid-not-before { type yang:date-and-time; description "This PSK identity is not valid before the given data and time."; } leaf valid-not-after { type yang:date-and-time; description "This PSK identity is not valid before the given data and time."; } leaf key { type binary; nacm:default-deny-all; description "The key associated with the PSK identity"; } } } // container psk-map } From j.schoenwaelder@jacobs-university.de Wed Apr 11 11:33:14 2012 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 48EE711E808D for ; Wed, 11 Apr 2012 11:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtClCXUUDlyY for ; Wed, 11 Apr 2012 11:33:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F82521F84B9 for ; Wed, 11 Apr 2012 11:33:13 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3362120C08; Wed, 11 Apr 2012 20:33:12 +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 x3kXtZKYJLxe; Wed, 11 Apr 2012 20:33:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89DB720C11; Wed, 11 Apr 2012 20:33:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ED5991E5F06F; Wed, 11 Apr 2012 20:33:12 +0200 (CEST) Date: Wed, 11 Apr 2012 20:33:12 +0200 From: Juergen Schoenwaelder To: Alan Luchuk Message-ID: <20120411183312.GA31171@elstar.local> Mail-Followup-To: Alan Luchuk , netconf@ietf.org, mbadra@gmail.com References: <201204111536.LAA15744@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204111536.LAA15744@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updates to the ietf-netconf-tls.yang module 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, 11 Apr 2012 18:33:14 -0000 On Wed, Apr 11, 2012 at 11:36:59AM -0400, Alan Luchuk wrote: > typedef tls-fingerprint-type { > type binary { > length "1..max"; > } > description > "A cryptographic signature (fingerprint) value that can be used to > uniquely reference other data of potentially arbitrary length."; > } The binary type means the data is encoded in base64. The tools I am familiar with that produce hash values seem to generate hexadecimal representations. > container fingerprint { > choice algorithm-and-hash { > leaf md5 { > type tls-fingerprint-type; > } > leaf sha1 { > type tls-fingerprint-type; > } > leaf sha224 { > type tls-fingerprint-type; > } > leaf sha256 { > type tls-fingerprint-type; > } > leaf sha384 { > type tls-fingerprint-type; > } > leaf sha512 { > type tls-fingerprint-type; > } > description > "Specifies the signature algorithm and cryptographic > signature (fingerprint) used to identify an X.509 > certificate. > > Implementations of this YANG module MAY, but are not > required to, implement all of these cryptographic signature > algorithms. Implementations of this YANG module MUST > implement at least one of these cryptographic signature > algorithms. > > The available choices may be extended in the future as > stronger cryptographic signature algorithms become > available and are deemed necessary."; > > reference > "RFC 5246: The Transport Layer Security (TLS) Protocol > Version 1.2; Section 7.4.1.4.1, Signature Algorithms"; > } // choice algorithm-and-hash > } // container fingerprint I think we need to make this reusable, more generic and we need to put the resulting grouping under IANA control. We need the same construct for the SNMP configuration data model. So one way forward is that we draft a reusable grouping and an associated fingerprint type (or hash value type - whatever the correct term will be) to be placed into an IANA maintained modules. We can do this here or we do it in NETMOD. I personally do not care much as long as we get a consistent and reusable solution into place. > leaf data { > type string { > length "1..max"; > } > description > "Auxiliary data used as optional configuration information for > a given mapping specified by the map-type leaf. Only some > mapping systems will make use of this leaf. When the NETCONF > server derives the NETCONF username from the client's presented > certificate, the value in this leaf MUST be ignored for any > mapping type that does not require data present in this leaf."; > } > } // list cert-map > } // container cert-mappings This follows the MIB model but I am not sure this is the right way of doing this in YANG. Martin uses a slightly different approach in draft-bjorklund-netmod-snmp-cfg-02.txt. > leaf valid-not-before { > type yang:date-and-time; > description > "This PSK identity is not valid before the given data > and time."; > } s/data/date/ > leaf valid-not-after { > type yang:date-and-time; > description > "This PSK identity is not valid before the given data > and time."; > } s/data/date/ > leaf key { > type binary; > nacm:default-deny-all; > description > "The key associated with the PSK identity"; > } The same question raised above applies here. Is a base64 representation really what people feel comfortable with? Using base64 might be more OK here than above - I do not really know. /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 Apr 16 06:29:45 2012 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 68C5621F86C3 for ; Mon, 16 Apr 2012 06:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNlqsvlVFkuJ for ; Mon, 16 Apr 2012 06:29:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A007821F86C1 for ; Mon, 16 Apr 2012 06:29:44 -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 q3GDTeFQ030941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2012 15:29:40 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3GDTc61028445; Mon, 16 Apr 2012 15:29:39 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 15:29:08 +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, 16 Apr 2012 15:29:06 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Trying a consensus on the way forward with Netconf-Light thread-index: Ac0b1OXlQuYZuQC/TY+y37b10WKKDw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 16 Apr 2012 13:29:08.0028 (UTC) FILETIME=[E6A62FC0:01CD1BD4] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1791 X-purgate-ID: 151667::1334582980-00007415-D215FB25/0-0/0-0 Subject: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 16 Apr 2012 13:29:45 -0000 Dear NETCONF WG, after the discussion on the Netconf-Light, we would like to get the sense of the WG. The WG at the end needs a consensus to prepare a reasonably well scoped new charter. Current Netconf-Light specification describes a profile of the NETCONF protocol and allows devices to announce that they only support a subset of the NETCONF protocol operations. However, Netconf-Light differs from the Netconf standard and proposes to use a new namespace and a reduced set of configuration features with a new capability. The specification also discusses TLS as the potential mandatory to implement secure transport protocol. =09 With that, there are a few questions to answer to get a clarity on what the WG thinks ( questions b) and c) might be possible to combine, however please state your opinion separately): a) Assuming that we need a Netconf-Light document to define diverse details, should the Netconf-Light document be a Standard track document or an Experimental?=20 b) Should the minimal set of configuration features used in Netconf-Light be defined in the Netconf-Light document or in an applicability statement. E.g. the Netconf-Light document would define a "minimal CM feature set". An applicability statement can define a few "minimal CM feature sets" for different purposes.=20 c) Should the minimal set of configuration features be defined with a new capability or based on deviations? d) Which minimal CM feature set is appropriate for a Netconf-Light for constrained devices? Please send your response to the questions above to the Netconf ML, by April 26, 2011 EDT EOB. PS: If anybody wants to start additional discussion on a particular topic, please do so with a "new subject". Thank you. Mehmet & Bert From j.schoenwaelder@jacobs-university.de Mon Apr 16 06:57:03 2012 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 7CE6321F85C5 for ; Mon, 16 Apr 2012 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvMpUrytZJZZ for ; Mon, 16 Apr 2012 06:57:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AF6EA21F85B7 for ; Mon, 16 Apr 2012 06:57:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA92C20BF1; Mon, 16 Apr 2012 15:57:01 +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 x729JTFjugYY; Mon, 16 Apr 2012 15:57:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4062720BEF; Mon, 16 Apr 2012 15:57:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5FB781E65E33; Mon, 16 Apr 2012 15:57:02 +0200 (CEST) Date: Mon, 16 Apr 2012 15:57:01 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120416135700.GA49052@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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: Mon, 16 Apr 2012 13:57:03 -0000 On Mon, Apr 16, 2012 at 03:29:06PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > after the discussion on the Netconf-Light, we would like to get the > sense of the WG. The WG at the end needs a consensus to prepare a > reasonably well scoped new charter. > > Current Netconf-Light specification describes a profile of the NETCONF > protocol and allows devices to announce that they only support a subset > of the NETCONF protocol operations. > However, Netconf-Light differs from the Netconf standard and proposes to > use a new namespace and a reduced set of configuration features with a > new capability. The specification also discusses TLS as the potential > mandatory to implement secure transport protocol. > > With that, there are a few questions to answer to get a clarity on what > the WG thinks ( questions b) and c) might be possible to combine, > however please state your opinion separately): > > a) Assuming that we need a Netconf-Light document to define diverse > details, should the Netconf-Light document be a Standard track document > or an Experimental? > > b) Should the minimal set of configuration features used in > Netconf-Light be defined in the Netconf-Light document or in an > applicability statement. > E.g. the Netconf-Light document would define a "minimal CM feature set". > An applicability statement can define a few "minimal CM feature sets" > for different purposes. > > c) Should the minimal set of configuration features be defined with a > new capability or based on deviations? > > d) Which minimal CM feature set is appropriate for a Netconf-Light for > constrained devices? For a charter discussion, we need to agree on the scope of the problem(s) to be solved, not necessarily on all details of the solution. If we break things into abstract pieces, I see two things: a) an applicability statement document that details how to put NETCONF on constrained devices b) an implementation guidelines document that details how one can best transition from a legacy configuration frontend to a standards-based NETCONF implementation (Trying to be constructive without restarting the discussion about the details - the answers to a)-d) are interdependent.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Mon Apr 16 10:14:01 2012 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 5BD5921F8644 for ; Mon, 16 Apr 2012 10:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjyPa-NVgM9o for ; Mon, 16 Apr 2012 10:14:00 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id B087521F8633 for ; Mon, 16 Apr 2012 10:13:53 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3GHDp3F028460 for ; Mon, 16 Apr 2012 13:13:51 -0400 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:33834] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 21/9A-30492-E435C8F4; Mon, 16 Apr 2012 13:13:51 -0400 Message-ID: <4F8C534F.90002@netconfcentral.org> Date: Mon, 16 Apr 2012 10:13:51 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 16 Apr 2012 17:14:01 -0000 On 04/16/2012 06:29 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > after the discussion on the Netconf-Light, we would like to get the > sense of the WG. The WG at the end needs a consensus to prepare a > reasonably well scoped new charter. > > Current Netconf-Light specification describes a profile of the NETCONF > protocol and allows devices to announce that they only support a subset > of the NETCONF protocol operations. > However, Netconf-Light differs from the Netconf standard and proposes to > use a new namespace and a reduced set of configuration features with a > new capability. The specification also discusses TLS as the potential > mandatory to implement secure transport protocol. > > With that, there are a few questions to answer to get a clarity on what > the WG thinks ( questions b) and c) might be possible to combine, > however please state your opinion separately): > I don't think you are asking the most important questions. I don't like to reverse-engineer the charter text from a solution I-D. We should agree on the problems that need to be solved, agree on the charter text (when it exists), and then agree on the starting point draft. We can even wait to get the charter approved before making decisions about the solution. The WG was asked in Paris for consensus on working on the problem of NETCONF for constrained devices. There seemed to be consensus to do that. The WG was not asked if they wanted to work on NETCONF Light, or even to use this draft for the starting point. IMO, there is consensus to work on the problem of NETCONF for run-time resource constrained devices. The charter text needs to be very clear about the definition of a constrained device. So until there is charter text to discuss, I don't see the point in discussing solution mechanisms, or standards vs. experimental track, or other procedural issues. Andy > a) Assuming that we need a Netconf-Light document to define diverse > details, should the Netconf-Light document be a Standard track document > or an Experimental? > > b) Should the minimal set of configuration features used in > Netconf-Light be defined in the Netconf-Light document or in an > applicability statement. > E.g. the Netconf-Light document would define a "minimal CM feature set". > An applicability statement can define a few "minimal CM feature sets" > for different purposes. > > c) Should the minimal set of configuration features be defined with a > new capability or based on deviations? > > d) Which minimal CM feature set is appropriate for a Netconf-Light for > constrained devices? > > > Please send your response to the questions above to the Netconf ML, by > April 26, 2011 EDT EOB. > > PS: If anybody wants to start additional discussion on a particular > topic, please do so with a "new subject". > > Thank you. > > Mehmet& Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From mehmet.ersue@nsn.com Tue Apr 17 02:10:58 2012 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 8892A21F861C for ; Tue, 17 Apr 2012 02:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzwmU199y6kk for ; Tue, 17 Apr 2012 02:10:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EAE3521F861A for ; Tue, 17 Apr 2012 02:10:53 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3H9Aoho015181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Apr 2012 11:10:50 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3H9AiG1001382 for ; Tue, 17 Apr 2012 11:10:50 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 11:09:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 11:09:57 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403A65036@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Draft minutes of the IETF 83 NETCONF WG Session thread-index: Ac0cedvqtQ/Bpi9rSxu49Taq9tOJHA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Apr 2012 09:09:58.0968 (UTC) FILETIME=[DD19AB80:01CD1C79] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 266 X-purgate-ID: 151667::1334653851-00003570-19D2193A/0-0/0-0 Subject: [Netconf] Draft minutes of the IETF 83 NETCONF WG Session 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, 17 Apr 2012 09:10:59 -0000 Hi All, below are the draft minutes of the IETF 83 NETCONF WG Session: http://www.ietf.org/proceedings/83/minutes/minutes-83-netconf.txt Please send us your comments by April 30, 2011. Many thanks to our minute taker: Juergen Schoenwaelder Mehmet=20 From dromasca@avaya.com Tue Apr 17 03:26:48 2012 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 9470A21F859F for ; Tue, 17 Apr 2012 03:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hp3YF9bq4Jl for ; Tue, 17 Apr 2012 03:26:48 -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 B3F4221F858B for ; Tue, 17 Apr 2012 03:26:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOxCjU+HCzI1/2dsb2JhbABEsS2BB4IJAQEBAQIBEh4KPwwEAgEIDQEDBAEBAQoGDAsBBgFFCQgBAQQTCBMHh2cFnHKdI5AUYwScA4oigmk X-IronPort-AV: E=Sophos;i="4.75,434,1330923600"; d="scan'208";a="302233031" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Apr 2012 06:26:44 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Apr 2012 06:10: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: Tue, 17 Apr 2012 12:26:43 +0200 Message-ID: In-Reply-To: <20120416135700.GA49052@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Trying a consensus on the way forward with Netconf-Light Thread-Index: Ac0b2NMLpyunm7XFQUaRRh4y97AGygAq5xtw References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> <20120416135700.GA49052@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Ersue, Mehmet (NSN - DE/Munich)" Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 10:26:48 -0000 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, April 16, 2012 4:57 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Trying a consensus on the way forward with > Netconf-Light >=20 > On Mon, Apr 16, 2012 at 03:29:06PM +0200, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > Dear NETCONF WG, > > > > after the discussion on the Netconf-Light, we would like to get the > > sense of the WG. The WG at the end needs a consensus to prepare a > > reasonably well scoped new charter. > > > > Current Netconf-Light specification describes a profile of the > NETCONF > > protocol and allows devices to announce that they only support a > subset > > of the NETCONF protocol operations. > > However, Netconf-Light differs from the Netconf standard and proposes > to > > use a new namespace and a reduced set of configuration features with > a > > new capability. The specification also discusses TLS as the potential > > mandatory to implement secure transport protocol. > > > > With that, there are a few questions to answer to get a clarity on > what > > the WG thinks ( questions b) and c) might be possible to combine, > > however please state your opinion separately): > > > > a) Assuming that we need a Netconf-Light document to define diverse > > details, should the Netconf-Light document be a Standard track > document > > or an Experimental? > > > > b) Should the minimal set of configuration features used in > > Netconf-Light be defined in the Netconf-Light document or in an > > applicability statement. > > E.g. the Netconf-Light document would define a "minimal CM feature > set". > > An applicability statement can define a few "minimal CM feature sets" > > for different purposes. > > > > c) Should the minimal set of configuration features be defined with a > > new capability or based on deviations? > > > > d) Which minimal CM feature set is appropriate for a Netconf-Light > for > > constrained devices? >=20 > For a charter discussion, we need to agree on the scope of the > problem(s) to be solved, not necessarily on all details of the > solution. If we break things into abstract pieces, I see two things: >=20 > a) an applicability statement document that details how to put NETCONF > on constrained devices >=20 > b) an implementation guidelines document that details how one can best > transition from a legacy configuration frontend to a standards-based > NETCONF implementation >=20 > (Trying to be constructive without restarting the discussion about > the details - the answers to a)-d) are interdependent.) >=20 > /js >=20 I think that Juergen defined well the goals and deliverables of a possible work. I support this work.=20 Regards, Dan From lhotka@nic.cz Tue Apr 17 03:32:01 2012 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 6B14B21F841D for ; Tue, 17 Apr 2012 03:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mILqASX4tO8z for ; Tue, 17 Apr 2012 03:31:55 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA6FA21F85DB for ; Tue, 17 Apr 2012 03:31:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A319C540988; Tue, 17 Apr 2012 12:31:51 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH1eTGpS8F70; Tue, 17 Apr 2012 12:31:45 +0200 (CEST) Received: from localhost (dhcp-24-148.ripemtg.ripe.net [193.0.24.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 597D15401AC; Tue, 17 Apr 2012 12:31:45 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , "Ersue\, Mehmet \(NSN - DE\/Munich\)" In-Reply-To: <20120416135700.GA49052@elstar.local> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> <20120416135700.GA49052@elstar.local> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Tue, 17 Apr 2012 12:31:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 10:32:01 -0000 On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder wrote: > > a) an applicability statement document that details how to put NETCONF > on constrained devices I think it's a shame that (base) NETCONF doesn't work on constrained devices because my cell phone now probably has more memory, battery capacity and processing power than what my laptop had when the NETCONF WG was started. Andy has argued few times that NETCONF is not a good fit for the modern distributed computing and communication environments. Does it mean somebody will start "NETCONF-cloudy" before long? Lada > > b) an implementation guidelines document that details how one can best > transition from a legacy configuration frontend to a standards-based > NETCONF implementation > > (Trying to be constructive without restarting the discussion about > the details - the answers to a)-d) are interdependent.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Apr 17 03:57:16 2012 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 9570221F84A7 for ; Tue, 17 Apr 2012 03:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjiojRvDgM16 for ; Tue, 17 Apr 2012 03:57:16 -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 0EE7C21F84A2 for ; Tue, 17 Apr 2012 03:57:15 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C5C3B12008BC; Tue, 17 Apr 2012 12:57:14 +0200 (CEST) Date: Tue, 17 Apr 2012 12:57:13 +0200 (CEST) Message-Id: <20120417.125713.415846357.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> <20120416135700.GA49052@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 10:57:16 -0000 Ladislav Lhotka wrote: > On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder > wrote: > > > > a) an applicability statement document that details how to put NETCONF > > on constrained devices > > I think it's a shame that (base) NETCONF doesn't work on constrained devices AFAIK, we don't know how small a complete, minimal (base) NETCONF implementation (for a particular data model) would be. It is also not clear to me that NETCONF (light) is the right tool for the job. Maybe a deployment of these constrained devices have some kind of controller that can be a NETCONF server, and then the controller use some other protocol to control the constrainded devices. > Andy has argued few times that NETCONF is not a good fit for the modern > distributed computing and communication environments. ? /martin From dromasca@avaya.com Tue Apr 17 04:03:11 2012 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 7275221F858B for ; Tue, 17 Apr 2012 04:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSU3YauJFBJ4 for ; Tue, 17 Apr 2012 04:03:11 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D787B21F84AA for ; Tue, 17 Apr 2012 04:03:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAN9MjU/GmAcF/2dsb2JhbABEsS2BB4IJAQEBAQMSHgo/DAQCAQgNAQIBAQMBAQEKBgwLAQYBRQMGCAEBBAESCBqHbJxmnSqQFGMEnAOKIoJp X-IronPort-AV: E=Sophos;i="4.75,434,1330923600"; d="scan'208";a="4704515" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Apr 2012 07:03:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Apr 2012 07:01:05 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 13:03:06 +0200 Message-ID: In-Reply-To: <20120417.125713.415846357.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Trying a consensus on the way forward with Netconf-Light Thread-Index: Ac0ciNzdhOyvEDsHTpeMEml1eLyqNQAAJbEQ References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <20120417.125713.415846357.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 11:03:11 -0000 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Martin Bjorklund > Sent: Tuesday, April 17, 2012 1:57 PM > To: lhotka@nic.cz > Cc: netconf@ietf.org > Subject: Re: [Netconf] Trying a consensus on the way forward with > Netconf-Light >=20 > Ladislav Lhotka wrote: > > On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder > > wrote: > > > > > > a) an applicability statement document that details how to put > NETCONF > > > on constrained devices > > > > I think it's a shame that (base) NETCONF doesn't work on constrained > devices >=20 > AFAIK, we don't know how small a complete, minimal (base) NETCONF > implementation (for a particular data model) would be. >=20 > It is also not clear to me that NETCONF (light) is the right tool for > the job. Maybe a deployment of these constrained devices have some > kind of controller that can be a NETCONF server, and then the > controller use some other protocol to control the constrainded > devices. >=20 [[DR]] Some of them may follow this model but not all, and for sure the architecture of these devices cannot be constrained or changed because of the need to accommodate a management protocol, it should be the other way.=20 Regards, Dan From j.schoenwaelder@jacobs-university.de Tue Apr 17 04:06:25 2012 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 D920121F858B for ; Tue, 17 Apr 2012 04:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt34DwJF-X5e for ; Tue, 17 Apr 2012 04:06:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7D66321F8528 for ; Tue, 17 Apr 2012 04:06:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDF6E20C42; Tue, 17 Apr 2012 13:06:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mSX5uJpVrV_g; Tue, 17 Apr 2012 13:06:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53A8A20C8B; Tue, 17 Apr 2012 13:06:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7A62A1E6810F; Tue, 17 Apr 2012 13:06:21 +0200 (CEST) Date: Tue, 17 Apr 2012 13:06:20 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120417110620.GA54831@elstar.local> Mail-Followup-To: Ladislav Lhotka , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> <20120416135700.GA49052@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 11:06:26 -0000 On Tue, Apr 17, 2012 at 12:31:44PM +0200, Ladislav Lhotka wrote: > On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder wrote: > > > > a) an applicability statement document that details how to put NETCONF > > on constrained devices > > I think it's a shame that (base) NETCONF doesn't work on constrained devices because my cell phone now probably has more memory, battery capacity and processing power than what my laptop had when the NETCONF WG was started. > Your cell phone is most likely not a constrained device and hence not the target of a). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Tue Apr 17 05:01:02 2012 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 A6E8021F863F for ; Tue, 17 Apr 2012 05:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVIG8FqvAKsH for ; Tue, 17 Apr 2012 05:00:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC721F8646 for ; Tue, 17 Apr 2012 05:00:57 -0700 (PDT) Received: from [192.168.20.28] (93-103-13-73.static.t-2.net [93.103.13.73]) by mail.nic.cz (Postfix) with ESMTPSA id 6CDE813FA59; Tue, 17 Apr 2012 14:00:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334664056; bh=GYC6DMEQdvP2Fbzfyuqz2/OV2qs5jWdOqEp0oY21RCk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iECKdRtDk1iSEwwTZ40nNiHP0oHfO47rPxbh+JOQ6gTt4Nsc//RqrLNss8QM+Szz2 FgJ2UAUMjqlS+05Mhpk9RHbGSAccXlylIiIkiBP03kKZJSREFZzfsXqMeFtJ0M0inR Yb3hQwG6FZPFsIr3kPxnmTcek5oS9eOtY0MjnRrM= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120417110620.GA54831@elstar.local> Date: Tue, 17 Apr 2012 14:00:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6591F510-4383-4575-A542-B017E1FE7CD5@nic.cz> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> <20120416135700.GA49052@elstar.local> <20120417110620.GA54831@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 12:01:02 -0000 On Apr 17, 2012, at 1:06 PM, Juergen Schoenwaelder wrote: > On Tue, Apr 17, 2012 at 12:31:44PM +0200, Ladislav Lhotka wrote: >> On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder = wrote: >>>=20 >>> a) an applicability statement document that details how to put = NETCONF >>> on constrained devices >>=20 >> I think it's a shame that (base) NETCONF doesn't work on constrained = devices because my cell phone now probably has more memory, battery = capacity and processing power than what my laptop had when the NETCONF = WG was started. >>=20 >=20 > Your cell phone is most likely not a constrained device and hence not > the target of a). Perhaps in a year or two your constrained devices won't be constrained = any more. But my point is different: I think it would be much better to have a = clean, lean and mean baseline spec that works everywhere - i.e., = NETCONF-revisited instead of NETCONF + NETCONF-light, and maybe other = variants in the future. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Tue Apr 17 06:27:31 2012 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 F13DC21F857D for ; Tue, 17 Apr 2012 06:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bu+OQSCRYEC for ; Tue, 17 Apr 2012 06:27:27 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE9A21F84D8 for ; Tue, 17 Apr 2012 06:27:27 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3HDRQlW024419 for ; Tue, 17 Apr 2012 09:27:26 -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:36344] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 26/5B-17495-DBF6D8F4; Tue, 17 Apr 2012 09:27:26 -0400 Message-ID: <4F8D6FBE.4070108@netconfcentral.org> Date: Tue, 17 Apr 2012 06:27:26 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> <20120416135700.GA49052@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 13:27:32 -0000 On 04/17/2012 03:31 AM, Ladislav Lhotka wrote: > On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder wrote: >> >> a) an applicability statement document that details how to put NETCONF >> on constrained devices > > I think it's a shame that (base) NETCONF doesn't work on constrained devices because my cell phone now probably has more memory, battery capacity and processing power than what my laptop had when the NETCONF WG was started. > > Andy has argued few times that NETCONF is not a good fit for the modern distributed computing and communication environments. Does it mean somebody will start "NETCONF-cloudy" before long? > My objection to this work is the inclusion of server-developer-resources-constrained devices. I don't think that is a problem the WG should be solving. We all struggle with not enough time to get everything done. So what -- deal with it outside the IETF. I do not know for sure, but I suspect it would be easier to add something to CoAP to handle the tiny amount of CM needed on a constrained device, than it would be cram a usable subset of NETCONF into said device. What YANG data models are going to run on this tiny device? So far, none of the modules created in the IETF. It would be nice to have a concrete example. > Lada Andy > >> >> b) an implementation guidelines document that details how one can best >> transition from a legacy configuration frontend to a standards-based >> NETCONF implementation >> >> (Trying to be constructive without restarting the discussion about >> the details - the answers to a)-d) are interdependent.) >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From Jonathan.Hansford@generaldynamics.uk.com Tue Apr 17 06:40:22 2012 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 12D7A21F8617 for ; Tue, 17 Apr 2012 06:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be1AC8BOsJj5 for ; Tue, 17 Apr 2012 06:40:17 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA221F861C for ; Tue, 17 Apr 2012 06:40:16 -0700 (PDT) Received: from [85.158.137.83:22788] by server-10.bemta-3.messagelabs.com id 54/1D-29478-0C27D8F4; Tue, 17 Apr 2012 13:40:16 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-6.tower-140.messagelabs.com!1334670015!23463691!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10002 invoked from network); 17 Apr 2012 13:40:15 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-6.tower-140.messagelabs.com with SMTP; 17 Apr 2012 13:40:15 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 17 Apr 2012 14:40:14 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 14:40:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 14:40:13 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> In-Reply-To: <4F8D6FBE.4070108@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0cn53extB9ID0BT9SEnXLByPPFlA== References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> From: To: , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 17 Apr 2012 13:40:10.0142 (UTC) FILETIME=[9BB683E0:01CD1C9F] Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 17 Apr 2012 13:40:22 -0000 > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.org] > Sent: 17 April 2012 14:27 > To: Ladislav Lhotka > Cc: netconf@ietf.org > Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf- > Light >=20 > On 04/17/2012 03:31 AM, Ladislav Lhotka wrote: > > On Mon, 16 Apr 2012 15:57:01 +0200, Juergen > Schoenwaelder wrote: > >> > >> a) an applicability statement document that details how to put NETCONF > >> on constrained devices > > > > I think it's a shame that (base) NETCONF doesn't work on constrained > devices because my cell phone now probably has more memory, battery > capacity and processing power than what my laptop had when the NETCONF WG > was started. > > > > Andy has argued few times that NETCONF is not a good fit for the modern > distributed computing and communication environments. Does it mean > somebody will start "NETCONF-cloudy" before long? > > >=20 >=20 > My objection to this work is the inclusion of server-developer-resources- > constrained > devices. I don't think that is a problem the WG should be solving. We > all struggle > with not enough time to get everything done. So what -- deal with it > outside the IETF. >=20 > I do not know for sure, but I suspect it would be easier to add something > to CoAP to handle the tiny amount of CM needed on a constrained device, > than it would be cram a usable subset of NETCONF into said device. Does it follow that because a device is constrained its CM will be tiny? Clearly devices with memory, CPU, power or bandwidth constraints would all prefer as efficient a solution as possible, but that doesn't necessarily mean the CM will be tiny. >=20 > What YANG data models are going to run on this tiny device? > So far, none of the modules created in the IETF. > It would be nice to have a concrete example. >=20 >=20 > > Lada >=20 > Andy Jonathan >=20 > > > >> > >> b) an implementation guidelines document that details how one can best > >> transition from a legacy configuration frontend to a standards- > based > >> NETCONF implementation > >> > >> (Trying to be constructive without restarting the discussion about > >> the details - the answers to a)-d) are interdependent.) > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >> Fax: +49 421 200 3103 > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > >=20 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From andy@netconfcentral.org Tue Apr 17 07:03:01 2012 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 999D021F8568 for ; Tue, 17 Apr 2012 07:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0lwxhQlqiVi for ; Tue, 17 Apr 2012 07:03:01 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 12D4021F84D8 for ; Tue, 17 Apr 2012 07:03:00 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3HE2xOC006277 for ; Tue, 17 Apr 2012 10:02:59 -0400 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36377] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 25/07-17184-2187D8F4; Tue, 17 Apr 2012 10:02:59 -0400 Message-ID: <4F8D7813.2030907@netconfcentral.org> Date: Tue, 17 Apr 2012 07:02:59 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jonathan.Hansford@generaldynamics.uk.com References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 17 Apr 2012 14:03:01 -0000 .. > Does it follow that because a device is constrained its CM will be tiny? > Clearly devices with memory, CPU, power or bandwidth constraints would > all prefer as efficient a solution as possible, but that doesn't > necessarily mean the CM will be tiny. > This is the only type of constrained devices I think the IETF should address. What definition of resource-constrained device are you using? The definition that includes 'not enough engineering hours to get everything done in time to ship' could make every single electronics product I've ever purchased a constrained device. I find it odd that nobody has anything close to a concrete example of a constrained device and a YANG data model that would run on that device. If this is a problem ready for standardization, then somebody should already be solving it for a real product. >> >> What YANG data models are going to run on this tiny device? >> So far, none of the modules created in the IETF. >> It would be nice to have a concrete example. >> >> >>> Lada >> >> Andy > > Jonathan > Andy From kwatsen@juniper.net Tue Apr 17 11:02:01 2012 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 A4DDD21F844C for ; Tue, 17 Apr 2012 11:02: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFw2oPruQRIa for ; Tue, 17 Apr 2012 11:02:01 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id E75CC11E80A1 for ; Tue, 17 Apr 2012 11:02:00 -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 DSNKT42wFjZ7X3OWIk+I/7je/czKdRmHxVsQ@postini.com; Tue, 17 Apr 2012 11:02: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, 17 Apr 2012 11:01:45 -0700 From: Kent Watsen To: Andy Bierman , "Jonathan.Hansford@generaldynamics.uk.com" Date: Tue, 17 Apr 2012 11:01:41 -0700 Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0cos/79+pi9tXWQLW8YPEnm+uuQQAHlVAw Message-ID: <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> In-Reply-To: <4F8D7813.2030907@netconfcentral.org> 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 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 17 Apr 2012 18:02:01 -0000 > If this is a problem ready for standardization, then somebody > should already be solving it for a real product. We do, as mentioned before, we don't always implement the whole spec. Of c= ourse, we don't let those devices advertize they support NETCONF, but at le= ast our NMS can support them... BTW, we have all cases: - device resource constrained (cpu, mem, disk) - dev/time resource constrained (fact of life, in our experience, we're d= ealing with it) - adapted devices (impossible for a fa=E7ade to support when the r= eal device doesn't) I'm not sure how a NETCONF-light limits the YANG modules that can be suppor= ted - "what" and "how" seem orthogonal to me. K. From andy@netconfcentral.org Tue Apr 17 11:14:05 2012 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 3C6CB21F84DD for ; Tue, 17 Apr 2012 11:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGi5S2Ds1z8Q for ; Tue, 17 Apr 2012 11:14:04 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 84C6021F84AF for ; Tue, 17 Apr 2012 11:14:04 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3HIE3hQ027832 for ; Tue, 17 Apr 2012 14:14:03 -0400 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37690] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F6/9A-27126-AE2BD8F4; Tue, 17 Apr 2012 14:14:02 -0400 Message-ID: <4F8DB2EB.9040209@netconfcentral.org> Date: Tue, 17 Apr 2012 11:14:03 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kent Watsen References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 17 Apr 2012 18:14:05 -0000 On 04/17/2012 11:01 AM, Kent Watsen wrote: > >> If this is a problem ready for standardization, then somebody >> should already be solving it for a real product. > > > We do, as mentioned before, we don't always implement the whole spec. Of course, we don't let those devices advertize they support NETCONF, but at least our NMS can support them... > > BTW, we have all cases: > > - device resource constrained (cpu, mem, disk) > - dev/time resource constrained (fact of life, in our experience, we're dealing with it) The issue is whether the WG picks a meaningful subset of functionality or whether the vendor picks an arbitrary subset of functionality. I don't think the latter is appropriate for a standard. It wouldn't make sense to ship a router that does some arbitrary subset of BGP4. The subset has to be well-known and agreed upon by the WG. > - adapted devices (impossible for a façade to support when the real device doesn't) > If the WG thinks a "no-locking" subset is a good idea, then that should be in the solution, but it should not be up to the vendor. > > I'm not sure how a NETCONF-light limits the YANG modules that can be supported - "what" and "how" seem orthogonal to me. > > K. > > Andy From andy@netconfcentral.org Tue Apr 17 11:31:34 2012 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 1315A11E80B8 for ; Tue, 17 Apr 2012 11:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luWmEPPW1pBe for ; Tue, 17 Apr 2012 11:31:30 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 018E411E80A0 for ; Tue, 17 Apr 2012 11:31:29 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3HIVTNI019426 for ; Tue, 17 Apr 2012 14:31:29 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37735] helo=[192.168.0.9]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 51/DE-22382-007BD8F4; Tue, 17 Apr 2012 14:31:29 -0400 Message-ID: <4F8DB701.6020305@netconfcentral.org> Date: Tue, 17 Apr 2012 11:31:29 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 18:31:34 -0000 On 04/16/2012 06:29 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > a) standards-track b) NETCONF-Light document; but I prefer the name 'NETCONF for Constrained Devices' c) new capability; since deviations are not widely implemented (except in yuma and confd) they do not really solve the problem; incompatible at layer 8 - political layer d) the original suggested subset in the -00 draft. http://tools.ietf.org/html/draft-schoenw-netconf-light-00 The -00 draft was almost done. The -01 draft was not a step forward. Andy > after the discussion on the Netconf-Light, we would like to get the > sense of the WG. The WG at the end needs a consensus to prepare a > reasonably well scoped new charter. > > Current Netconf-Light specification describes a profile of the NETCONF > protocol and allows devices to announce that they only support a subset > of the NETCONF protocol operations. > However, Netconf-Light differs from the Netconf standard and proposes to > use a new namespace and a reduced set of configuration features with a > new capability. The specification also discusses TLS as the potential > mandatory to implement secure transport protocol. > > With that, there are a few questions to answer to get a clarity on what > the WG thinks ( questions b) and c) might be possible to combine, > however please state your opinion separately): > > a) Assuming that we need a Netconf-Light document to define diverse > details, should the Netconf-Light document be a Standard track document > or an Experimental? > > b) Should the minimal set of configuration features used in > Netconf-Light be defined in the Netconf-Light document or in an > applicability statement. > E.g. the Netconf-Light document would define a "minimal CM feature set". > An applicability statement can define a few "minimal CM feature sets" > for different purposes. > > c) Should the minimal set of configuration features be defined with a > new capability or based on deviations? > > d) Which minimal CM feature set is appropriate for a Netconf-Light for > constrained devices? > > > Please send your response to the questions above to the Netconf ML, by > April 26, 2011 EDT EOB. > > PS: If anybody wants to start additional discussion on a particular > topic, please do so with a "new subject". > > Thank you. > > Mehmet& Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From kwatsen@juniper.net Tue Apr 17 11:50:03 2012 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 71D5121F852E for ; Tue, 17 Apr 2012 11:50:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v1ZRNcs99qI for ; Tue, 17 Apr 2012 11:50:03 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4432421F852B for ; Tue, 17 Apr 2012 11:50:02 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT427VbeFikC2PK0rxXXxjPHHZ93eoF8K@postini.com; Tue, 17 Apr 2012 11:50:02 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, 17 Apr 2012 11:49:43 -0700 From: Kent Watsen To: Ladislav Lhotka , Juergen Schoenwaelder Date: Tue, 17 Apr 2012 11:49:41 -0700 Thread-Topic: [Netconf] Trying a consensus on the way forward with Netconf-Light Thread-Index: Ac0ckcTMUHNob5vtTda2s84IDQaZxgANrEKw Message-ID: <84600D05C20FF943918238042D7670FD48C1297D7F@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net> <20120416135700.GA49052@elstar.local> <20120417110620.GA54831@elstar.local> <6591F510-4383-4575-A542-B017E1FE7CD5@nic.cz> In-Reply-To: <6591F510-4383-4575-A542-B017E1FE7CD5@nic.cz> 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: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward with Netconf-Light 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, 17 Apr 2012 18:50:03 -0000 > But my point is different: I think it would be much better to have a clea= n, > lean and mean baseline spec that works everywhere - i.e., NETCONF-revisit= ed > instead of NETCONF + NETCONF-light, and maybe other variants in the futur= e. FWIW, this gets my vote. From kwatsen@juniper.net Tue Apr 17 12:26:20 2012 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 A98E811E80C5 for ; Tue, 17 Apr 2012 12:26:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiGzmoE3D5jD for ; Tue, 17 Apr 2012 12:26:16 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8521A11E80BA for ; Tue, 17 Apr 2012 12:26:16 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT43D1RnIMyxDvgMdVOIygJA73vlBYYpc@postini.com; Tue, 17 Apr 2012 12:26:16 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 17 Apr 2012 12:22:42 -0700 From: Kent Watsen To: Andy Bierman Date: Tue, 17 Apr 2012 12:22:40 -0700 Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0cxeAcM8vrRAIBRiaBztXhlSQX8gAAlvvw Message-ID: <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> In-Reply-To: <4F8DB2EB.9040209@netconfcentral.org> 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: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 17 Apr 2012 19:26:20 -0000 > The issue is whether the WG picks a meaningful subset of functionality > or whether the vendor picks an arbitrary subset of functionality. > I don't think the latter is appropriate for a standard. You mentioned this before, but didn't explain why it matters. Recall from = http://www.ietf.org/mail-archive/web/netconf/current/msg07436.html: But the question to ask might be, what difference does it make if "light" starts with netconf-zero? Surely it's better for the devices, and it's not like the NMSs are going to implement any less NETCONF, as they're going to need it all to interoperate with other devices. So, again, what difference does it really make? NETCONF already defines the concept of extending "base" through advertising= capabilities, NCL only lowers the bar for what "base" is. This change doe= sn't seem to alter anything fundamental, which is why I don't understand yo= ur concern. BTW, I'm equally OK with using deviations. The WG just needs to define a d= eviation for each feature in the NCL draft - a 1-1 mapping. Either way get= s us to the same point. Thanks, Kent From andy@netconfcentral.org Tue Apr 17 13:10:50 2012 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 8692521F857D for ; Tue, 17 Apr 2012 13:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGn7pQMG4rLK for ; Tue, 17 Apr 2012 13:10:49 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1051C21F8559 for ; Tue, 17 Apr 2012 13:10:48 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3HKAlwO004274 for ; Tue, 17 Apr 2012 16:10:47 -0400 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37882] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 69/21-12885-64ECD8F4; Tue, 17 Apr 2012 16:10:47 -0400 Message-ID: <4F8DCE47.1060609@netconfcentral.org> Date: Tue, 17 Apr 2012 13:10:47 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kent Watsen References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 17 Apr 2012 20:10:50 -0000 On 04/17/2012 12:22 PM, Kent Watsen wrote: >> The issue is whether the WG picks a meaningful subset of functionality >> or whether the vendor picks an arbitrary subset of functionality. >> I don't think the latter is appropriate for a standard. > > You mentioned this before, but didn't explain why it matters. Recall from http://www.ietf.org/mail-archive/web/netconf/current/msg07436.html: > > But the question to ask might be, what difference does it make if > "light" starts with netconf-zero? Surely it's better for the devices, > and it's not like the NMSs are going to implement any less NETCONF, > as they're going to need it all to interoperate with other devices. > So, again, what difference does it really make? > > NETCONF already defines the concept of extending "base" through advertising capabilities, NCL only lowers the bar for what "base" is. This change doesn't seem to alter anything fundamental, which is why I don't understand your concern. > The functionality in the NETCONF 'base' was not picked in arbitrary fashion. The issue is whether the bar is lowered by the WG to a specific point, or whether the WG standardizes a bar-lowering mechanism so vendors can set the bar wherever they want, and change it whenever they want. I don't think multi-vendor interoperability is achievable unless there is a well-known and meaningful subset of NETCONF that does CM. Just implementing a few NETCONF commands of your choosing does not mean a 3rd party application can actually use your server to do configuration management. > BTW, I'm equally OK with using deviations. The WG just needs to define a deviation for each feature in the NCL draft - a 1-1 mapping. Either way gets us to the same point. > yes -- except RFC 6020 already says how to do this. > Thanks, > Kent > Andy From kwatsen@juniper.net Tue Apr 17 17:02:06 2012 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 BED6111E80DF for ; Tue, 17 Apr 2012 17:02: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpe19eOICwp1 for ; Tue, 17 Apr 2012 17:02:06 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2C87F11E80C5 for ; Tue, 17 Apr 2012 17:02:06 -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 DSNKT44EffeyHhhPud44dC34tHtEfTw2J2/4@postini.com; Tue, 17 Apr 2012 17:02:06 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, 17 Apr 2012 17:01:50 -0700 From: Kent Watsen To: Andy Bierman Date: Tue, 17 Apr 2012 17:01:48 -0700 Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0c1i7rCxPertZQQ/24arXrbST+CAAGPRYQ Message-ID: <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> <4F8DCE47.1060609@netconfcentral.org> In-Reply-To: <4F8DCE47.1060609@netconfcentral.org> 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: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 00:02:06 -0000 > The functionality in the NETCONF 'base' was not picked in arbitrary fashi= on. I didn't say that. But now we have several years of implementation experie= nce behind us, maybe it's worth revisiting if that definition of 'base' was= best? > The issue is whether the bar is lowered by the WG to a specific point, > or whether the WG standardizes a bar-lowering mechanism so vendors can > set the bar wherever they want, and change it whenever they want. Regardless what the WG decides, it won't impact vendors, they will just imp= lement what they can. The only difference is if they will use an IETF-appr= oved mechanism to advertize that or make up their own. > I don't think multi-vendor interoperability is achievable unless > there is a well-known and meaningful subset of NETCONF that does CM. > Just implementing a few NETCONF commands of your choosing does not > mean a 3rd party application can actually use your server to do > configuration management. It's a business-decision for the vendor to decide how much NETCONF they wan= t to implement and when. They would make the decision taking into account = market ramifications, such as not being managed by particular NMSs - so be = it. On the flip-side, NMS developers might wise up and support NCL because= their market demands it. =20 > yes -- except RFC 6020 already says how to do this. Three problems with that: 1) YANG is not required for NETCONF (see 6241, appendix D) 2) 6020 says that "deviations MUST never be part of a published standard" 3) we would need said deviations to be standardized to support interopera= bility Thanks, Kent From lhotka@nic.cz Tue Apr 17 23:08:46 2012 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 BA0D521F8575 for ; Tue, 17 Apr 2012 23:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjw1b9fc8DUl for ; Tue, 17 Apr 2012 23:08:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36821F84FD for ; Tue, 17 Apr 2012 23:08:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7D614540755; Wed, 18 Apr 2012 08:08:44 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvADAw6990Jf; Wed, 18 Apr 2012 08:08:39 +0200 (CEST) Received: from localhost (93-103-13-73.static.t-2.net [93.103.13.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 539445400FB; Wed, 18 Apr 2012 08:08:39 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman In-Reply-To: <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 18 Apr 2012 08:08:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 06:08:46 -0000 On Tue, 17 Apr 2012 17:01:48 -0700, Kent Watsen wrote: > > > > The functionality in the NETCONF 'base' was not picked in arbitrary fashion. > > I didn't say that. But now we have several years of implementation experience behind us, maybe it's worth revisiting if that definition of 'base' was best? > > > > > The issue is whether the bar is lowered by the WG to a specific point, > > or whether the WG standardizes a bar-lowering mechanism so vendors can > > set the bar wherever they want, and change it whenever they want. > > Regardless what the WG decides, it won't impact vendors, they will just implement what they can. The only difference is if they will use an IETF-approved mechanism to advertize that or make up their own. > > > > > I don't think multi-vendor interoperability is achievable unless > > there is a well-known and meaningful subset of NETCONF that does CM. > > Just implementing a few NETCONF commands of your choosing does not > > mean a 3rd party application can actually use your server to do > > configuration management. > > It's a business-decision for the vendor to decide how much NETCONF they want to implement and when. They would make the decision taking into account market ramifications, such as not being managed by particular NMSs - so be it. On the flip-side, NMS developers might wise up and support NCL because their market demands it. > > > > > > yes -- except RFC 6020 already says how to do this. > > Three problems with that: > 1) YANG is not required for NETCONF (see 6241, appendix D) > 2) 6020 says that "deviations MUST never be part of a published standard" > 3) we would need said deviations to be standardized to support interoperability > > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Apr 17 23:18:00 2012 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 0BDB321F85C3 for ; Tue, 17 Apr 2012 23:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FhYJhnq95AL for ; Tue, 17 Apr 2012 23:17:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E889C21F85A2 for ; Tue, 17 Apr 2012 23:17:54 -0700 (PDT) Received: from [192.168.20.27] (93-103-13-73.static.t-2.net [93.103.13.73]) by mail.nic.cz (Postfix) with ESMTPSA id E821614106E; Wed, 18 Apr 2012 08:17:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334729874; bh=3rCe4A33sjpiT0DsVPv8zC80X/YHArq004J5uFACxuY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ppNHM2xhl7jv+l9ngb2lV/T06EK2Zx57rhhgFTyxIqvdOaOTnX975d1tdTSZzg87n Z0oXvmc9WA3LTFMaWzbF9bRgVbyEq1hkQqhMjGlVGzPrGB0NkanDkCKfh1Yaisw9Ha uIwwH+l/xf2HOIoTo4MLcI1dST9S7KSUk2EI+S28= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> Date: Wed, 18 Apr 2012 08:17:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> References: <80A0822C5E9A4440A5117C2F4CD36A6403A64CAD@DEMUEXC006.nsn-intra.net><20120416135700.GA49052@elstar.local> <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> To: Kent Watsen X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 06:18:00 -0000 Hi, sorry for the previous empty reply, my fingers don't work well early in = the morning. :-( On Apr 18, 2012, at 2:01 AM, Kent Watsen wrote: >=20 >=20 >> The functionality in the NETCONF 'base' was not picked in arbitrary = fashion. >=20 > I didn't say that. But now we have several years of implementation = experience behind us, maybe it's worth revisiting if that definition of = 'base' was best? Pragmatically, what are the features that are strictly necessary on the = server side? - Subtree filters? No. - edit-config with all its complexity? No. - Locks? No. A device implementing per-user candidate does not need = them. Turning these (and other) features into optional capabilities would mean = additional flexibility in distributing the functions between the server = and client. Lada >=20 >=20 >=20 >> The issue is whether the bar is lowered by the WG to a specific = point, >> or whether the WG standardizes a bar-lowering mechanism so vendors = can >> set the bar wherever they want, and change it whenever they want. >=20 > Regardless what the WG decides, it won't impact vendors, they will = just implement what they can. The only difference is if they will use = an IETF-approved mechanism to advertize that or make up their own. >=20 >=20 >=20 >> I don't think multi-vendor interoperability is achievable unless >> there is a well-known and meaningful subset of NETCONF that does CM. >> Just implementing a few NETCONF commands of your choosing does not >> mean a 3rd party application can actually use your server to do >> configuration management. >=20 > It's a business-decision for the vendor to decide how much NETCONF = they want to implement and when. They would make the decision taking = into account market ramifications, such as not being managed by = particular NMSs - so be it. On the flip-side, NMS developers might wise = up and support NCL because their market demands it. =20 >=20 >=20 >=20 >=20 >> yes -- except RFC 6020 already says how to do this. >=20 > Three problems with that: > 1) YANG is not required for NETCONF (see 6241, appendix D) > 2) 6020 says that "deviations MUST never be part of a published = standard" > 3) we would need said deviations to be standardized to support = interoperability >=20 >=20 > Thanks, > Kent >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Apr 18 01:01:17 2012 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 2BD9A21F85F2 for ; Wed, 18 Apr 2012 01:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSL4Nkh9VBoU for ; Wed, 18 Apr 2012 01:01:16 -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 05D4B21F850C for ; Wed, 18 Apr 2012 01:01:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B697D1200D50; Wed, 18 Apr 2012 10:01:13 +0200 (CEST) Date: Wed, 18 Apr 2012 10:01:12 +0200 (CEST) Message-Id: <20120418.100112.1647670444223448099.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> References: <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 08:01:17 -0000 Ladislav Lhotka wrote: > Pragmatically, what are the features that are strictly necessary on > the server side? > > - Subtree filters? No. > > - edit-config with all its complexity? No. > > - Locks? No. A device implementing per-user candidate does not need > - them. So all you have left is file transfer with complete configs. As Andy said, why don't you use ftp or http - and call it REST; it's a super-trivial REST protcol with just one resource, the config, and you can GET and PUT it. Done. /martin From lhotka@nic.cz Wed Apr 18 01:25:23 2012 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 B00CD21F85D2 for ; Wed, 18 Apr 2012 01:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y51kAcewnzNc for ; Wed, 18 Apr 2012 01:25:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AC28121F8649 for ; Wed, 18 Apr 2012 01:25:18 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:1d66:bb11:eca5:2b76] (unknown [IPv6:2001:67c:64:42:1d66:bb11:eca5:2b76]) by mail.nic.cz (Postfix) with ESMTPSA id E66FB1408DA; Wed, 18 Apr 2012 10:25:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334737518; bh=/462s8hdU2GE4Sdqdj5pgo6tVkTgzUnCfvSC61jy6vw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wrQ1O/YXMqA8Yom49OJyTY4lLflLV6vWcftb4ttH77U1Q7iFh6kHAP9pipBNqMkvz JSsu0vDcozHyE9IcO2nIHqWcGZpzT0gj8CQCyeN6gWUyPXjIPOz+wHV3VwDl7G6wJE HL3hjO5LZDbS873XpG+WlbghQ7KceubBw7DlWPeM= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120418.100112.1647670444223448099.mbj@tail-f.com> Date: Wed, 18 Apr 2012 10:25:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FBDA1D5-BFA4-464F-9356-43FF2D76D658@nic.cz> References: <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 08:25:23 -0000 On Apr 18, 2012, at 10:01 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Pragmatically, what are the features that are strictly necessary on >> the server side? >>=20 >> - Subtree filters? No. >>=20 >> - edit-config with all its complexity? No. >>=20 >> - Locks? No. A device implementing per-user candidate does not need >> - them. >=20 > So all you have left is file transfer with complete configs. As Andy > said, why don't you use ftp or http - and call it REST; it's a > super-trivial REST protcol with just one resource, the config, and you > can GET and PUT it. Done. Yes, this may be perfectly fine in some deployments, or I may just want = to use alternative (perhaps more robust) means instead of those that = incidentally ended up in 4741. I may be biased but IMO it is the data layer that is most important and = interesting. A system using YANG-based data over HTTPS with PUT, GET, = POST etc. can still be a decent CM solution. And I actually don't want to call it REST because (i) it is a dodgy = buzzword and (ii) REST is designed for a human user clicking links in a = browser rather than automated machine-machine communication. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Apr 18 02:31:19 2012 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 4EB6A21F85BB for ; Wed, 18 Apr 2012 02:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.155 X-Spam-Level: X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpLFg3nBv8NP for ; Wed, 18 Apr 2012 02:31:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F328F21F85D9 for ; Wed, 18 Apr 2012 02:31:14 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A37720CA8; Wed, 18 Apr 2012 11:31: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 8EjcTl6hHoqH; Wed, 18 Apr 2012 11:31:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1DFE20CA6; Wed, 18 Apr 2012 11:31:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7F7591E69F71; Wed, 18 Apr 2012 11:31:14 +0200 (CEST) Date: Wed, 18 Apr 2012 11:31:13 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120418093112.GB58587@elstar.local> Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netconf@ietf.org" References: <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 09:31:19 -0000 On Wed, Apr 18, 2012 at 08:17:55AM +0200, Ladislav Lhotka wrote: > Hi, > > sorry for the previous empty reply, my fingers don't work well early in the morning. :-( > > On Apr 18, 2012, at 2:01 AM, Kent Watsen wrote: > > > > > > >> The functionality in the NETCONF 'base' was not picked in arbitrary fashion. > > > > I didn't say that. But now we have several years of implementation experience behind us, maybe it's worth revisiting if that definition of 'base' was best? > > Pragmatically, what are the features that are strictly necessary on the server side? > > - Subtree filters? No. > > - edit-config with all its complexity? No. > > - Locks? No. A device implementing per-user candidate does not need them. Yes, with the minor detail that there is no per-user candidate in the standards either (and on some systems, a lock is actually much less costly to implement than a per-user candidate). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Wed Apr 18 02:51:06 2012 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 8226C21F864D for ; Wed, 18 Apr 2012 02:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKYo89ldNN1K for ; Wed, 18 Apr 2012 02:51:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EF2CA21F861D for ; Wed, 18 Apr 2012 02:51:00 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:8d1c:c47e:11ed:6c8b] (unknown [IPv6:2001:67c:64:42:8d1c:c47e:11ed:6c8b]) by mail.nic.cz (Postfix) with ESMTPSA id 369FE14108B; Wed, 18 Apr 2012 11:51:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334742660; bh=SjJuhA4iDn5XFEafrcLXy62+gAsCvmgEG85z0xpN6/g=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Pq2Rzs19BwPSieWnjmQhdGulUA4p6mPUAyQUQXWGr8WVYIGwnIX5UF8Ieb92oKh/W joFV/b5WjA2klGQVrJS/OI/4lHgR8Fg09FkBgbMg6iQULIgbhIzKmsFxAvb+6up9mm QguQsZf5kQwLNpfjT9ce+9igTUNs8vlKoZ449ChI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120418093112.GB58587@elstar.local> Date: Wed, 18 Apr 2012 11:51:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <905C25BB-EE70-4DC6-BB25-0FA4640F6746@nic.cz> References: <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418093112.GB58587@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 09:51:06 -0000 On Apr 18, 2012, at 11:31 AM, Juergen Schoenwaelder wrote: > On Wed, Apr 18, 2012 at 08:17:55AM +0200, Ladislav Lhotka wrote: >> Hi, >>=20 >> sorry for the previous empty reply, my fingers don't work well early = in the morning. :-( >>=20 >> On Apr 18, 2012, at 2:01 AM, Kent Watsen wrote: >>=20 >>>=20 >>>=20 >>>> The functionality in the NETCONF 'base' was not picked in arbitrary = fashion. >>>=20 >>> I didn't say that. But now we have several years of implementation = experience behind us, maybe it's worth revisiting if that definition of = 'base' was best? >>=20 >> Pragmatically, what are the features that are strictly necessary on = the server side? >>=20 >> - Subtree filters? No. >>=20 >> - edit-config with all its complexity? No. >>=20 >> - Locks? No. A device implementing per-user candidate does not need = them. >=20 > Yes, with the minor detail that there is no per-user candidate in the This is really a minor detail because it can be standardized as an = optional capability. The global candidate is broken. > standards either (and on some systems, a lock is actually much less > costly to implement than a per-user candidate). Could be. My idea is to represent per-user candidate as a sequence of = edits performed by a given user, which shouldn't be too demanding - and = also helps with avoiding some of the race conditions. And I am not saying there is anything wrong with locks, they could = become just another optional capability. Lada >=20 > /js=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Wed Apr 18 03:01:34 2012 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 B2DB021F85A7 for ; Wed, 18 Apr 2012 03:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gia7fg+QCDXM for ; Wed, 18 Apr 2012 03:01:30 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF1121F8597 for ; Wed, 18 Apr 2012 03:01:30 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3IA1Rkg003816 for ; Wed, 18 Apr 2012 06:01:27 -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:40821] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 8E/87-17495-7F09E8F4; Wed, 18 Apr 2012 06:01:27 -0400 Message-ID: <4F8E90F8.20107@netconfcentral.org> Date: Wed, 18 Apr 2012 03:01:28 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418093112.GB58587@elstar.local> <905C25BB-EE70-4DC6-BB25-0FA4640F6746@nic.cz> In-Reply-To: <905C25BB-EE70-4DC6-BB25-0FA4640F6746@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 10:01:34 -0000 On 04/18/2012 02:51 AM, Ladislav Lhotka wrote: > > On Apr 18, 2012, at 11:31 AM, Juergen Schoenwaelder wrote: > >> On Wed, Apr 18, 2012 at 08:17:55AM +0200, Ladislav Lhotka wrote: >>> Hi, >>> >>> sorry for the previous empty reply, my fingers don't work well early in the morning. :-( >>> >>> On Apr 18, 2012, at 2:01 AM, Kent Watsen wrote: >>> >>>> >>>> >>>>> The functionality in the NETCONF 'base' was not picked in arbitrary fashion. >>>> >>>> I didn't say that. But now we have several years of implementation experience behind us, maybe it's worth revisiting if that definition of 'base' was best? >>> >>> Pragmatically, what are the features that are strictly necessary on the server side? >>> >>> - Subtree filters? No. >>> >>> - edit-config with all its complexity? No. >>> >>> - Locks? No. A device implementing per-user candidate does not need them. >> >> Yes, with the minor detail that there is no per-user candidate in the > > This is really a minor detail because it can be standardized as an optional capability. The global candidate is broken. > Actually, designing private candidates is non-trivial. Not ready for standardization. >> standards either (and on some systems, a lock is actually much less >> costly to implement than a per-user candidate). > > Could be. My idea is to represent per-user candidate as a sequence of edits performed by a given user, which shouldn't be too demanding - and also helps with avoiding some of the race conditions. > It may solve some race race conditions, but it introduces very complex conflict resolution. First one wins, and every other concurrent commit fails is too simplistic and fragile. Serializing transactions via locking avoids conflict resolution, but it creates a bottleneck. > And I am not saying there is anything wrong with locks, they could become just another optional capability. > > Lada > > Andy >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From lhotka@nic.cz Wed Apr 18 03:31:20 2012 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 8BF4221F862F for ; Wed, 18 Apr 2012 03:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkQA0L570n6t for ; Wed, 18 Apr 2012 03:31:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2B97821F8593 for ; Wed, 18 Apr 2012 03:31:15 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:8d1c:c47e:11ed:6c8b] (unknown [IPv6:2001:67c:64:42:8d1c:c47e:11ed:6c8b]) by mail.nic.cz (Postfix) with ESMTPSA id 61A881410C8; Wed, 18 Apr 2012 12:31:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334745074; bh=RX1FlAEcP4bnwDy5FMOgdkB7sYViQWo3ZnPQbyVSMIA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nb6XSgPCLHgNVSKSrygPt/mxjyQfriL36CSkQlprLyzSZUZtl/S/1tO/iDUBQRscK Vm6auMpJoQJo9qcbPIbgvQmJWdi1JZ0cF4mepo490HC9EteKcAv+p6E1qwlbw2zLzL 9Yo96VuSAVhdnnghA+v0CWTba9Hn8fEkUm8eQPJA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F8E90F8.20107@netconfcentral.org> Date: Wed, 18 Apr 2012 12:31:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8D6FBE.4070108@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462069C043A@GDUKADH850.uk1.r-org.net> <4F8D7813.2030907@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297CE7@EMBX01-HQ.jnpr.net> <4F8DB2EB.9040209@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1297DE7@EMBX01-HQ.jnpr.net> <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418093112.GB58587@elstar.local> <905C25BB-EE70-4DC6-BB25-0FA4640F6746@nic.cz> <4F8E90F8.20107@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 18 Apr 2012 10:31:20 -0000 On Apr 18, 2012, at 12:01 PM, Andy Bierman wrote: > On 04/18/2012 02:51 AM, Ladislav Lhotka wrote: >>=20 >> On Apr 18, 2012, at 11:31 AM, Juergen Schoenwaelder wrote: >>=20 >>> On Wed, Apr 18, 2012 at 08:17:55AM +0200, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> sorry for the previous empty reply, my fingers don't work well = early in the morning. :-( >>>>=20 >>>> On Apr 18, 2012, at 2:01 AM, Kent Watsen wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>> The functionality in the NETCONF 'base' was not picked in = arbitrary fashion. >>>>>=20 >>>>> I didn't say that. But now we have several years of = implementation experience behind us, maybe it's worth revisiting if that = definition of 'base' was best? >>>>=20 >>>> Pragmatically, what are the features that are strictly necessary on = the server side? >>>>=20 >>>> - Subtree filters? No. >>>>=20 >>>> - edit-config with all its complexity? No. >>>>=20 >>>> - Locks? No. A device implementing per-user candidate does not need = them. >>>=20 >>> Yes, with the minor detail that there is no per-user candidate in = the >>=20 >> This is really a minor detail because it can be standardized as an = optional capability. The global candidate is broken. >>=20 >=20 > Actually, designing private candidates is non-trivial. > Not ready for standardization. This is OK. I used per-user candidate just as an illustration of the = fact that the locking capability is not a sine qua non condition for a = CM system. >=20 >>> standards either (and on some systems, a lock is actually much less >>> costly to implement than a per-user candidate). >>=20 >> Could be. My idea is to represent per-user candidate as a sequence of = edits performed by a given user, which shouldn't be too demanding - and = also helps with avoiding some of the race conditions. >>=20 >=20 > It may solve some race race conditions, but it introduces very complex > conflict resolution. First one wins, and every other concurrent = commit fails > is too simplistic and fragile. Serializing transactions via locking No, a concurrent commit would fail only if different users happen to = have edited the same data nodes. And even then the conflict can be taken = back to the private candidate and the user may be given a chance to = resolve it. I am not saying this is going to be easy but distributed VC = systems like darcs or git demonstrate that it can be done in a reliable = way and without locks. Lada =20 > avoids conflict resolution, but it creates a bottleneck. >=20 >=20 >> And I am not saying there is anything wrong with locks, they could = become just another optional capability. >>=20 >> Lada >>=20 >>=20 >=20 > Andy >=20 >>>=20 >>> /js >>>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From Jonathan.Hansford@generaldynamics.uk.com Thu Apr 19 01:56:34 2012 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 854AE21F85CF for ; Thu, 19 Apr 2012 01:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ost3m8hxuYPc for ; Thu, 19 Apr 2012 01:56:34 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 66FF421F85C5 for ; Thu, 19 Apr 2012 01:56:32 -0700 (PDT) Received: from [85.158.137.35:43944] by server-8.bemta-3.messagelabs.com id DD/F0-24428-F33DF8F4; Thu, 19 Apr 2012 08:56:31 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-12.tower-134.messagelabs.com!1334825791!21775369!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26654 invoked from network); 19 Apr 2012 08:56:31 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-12.tower-134.messagelabs.com with SMTP; 19 Apr 2012 08:56:31 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 19 Apr 2012 09:56:29 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 09:56:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Apr 2012 09:56:28 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> In-Reply-To: <20120418.100112.1647670444223448099.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0eCk7Fs5gkAZ7FRuKpuzNqO2T1wQ== References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> From: To: , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 19 Apr 2012 08:56:31.0056 (UTC) FILETIME=[505F9500:01CD1E0A] Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 19 Apr 2012 08:56:34 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 18 April 2012 09:01 > To: lhotka@nic.cz > Cc: netconf@ietf.org > Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf- > Light >=20 > Ladislav Lhotka wrote: > > Pragmatically, what are the features that are strictly necessary on > > the server side? > > > > - Subtree filters? No. > > > > - edit-config with all its complexity? No. > > > > - Locks? No. A device implementing per-user candidate does not need > > - them. >=20 > So all you have left is file transfer with complete configs. As Andy > said, why don't you use ftp or http - and call it REST; it's a > super-trivial REST protcol with just one resource, the config, and you > can GET and PUT it. Done. >=20 You have a route for someone to introduce NETCONF in two stages. You also have an implementation that can be subsequently upgraded to full NETCONF should you be looking to replace your device with something less constrained in the future. Jonathan >=20 > /martin This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From andy@netconfcentral.org Thu Apr 19 02:49:32 2012 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 6D81D21F8584 for ; Thu, 19 Apr 2012 02:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bh8lZtLGOv2 for ; Thu, 19 Apr 2012 02:49:31 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id B669721F8565 for ; Thu, 19 Apr 2012 02:49:31 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3J9nUtS028922 for ; Thu, 19 Apr 2012 05:49:30 -0400 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:34504] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CD/9F-30492-9AFDF8F4; Thu, 19 Apr 2012 05:49:30 -0400 Message-ID: <4F8FDFA9.7080401@netconfcentral.org> Date: Thu, 19 Apr 2012 02:49:29 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jonathan.Hansford@generaldynamics.uk.com References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 19 Apr 2012 09:49:32 -0000 On 04/19/2012 01:56 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com] >> Sent: 18 April 2012 09:01 >> To: lhotka@nic.cz >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Trying a consensus on the way forward > withNetconf- >> Light >> >> Ladislav Lhotka wrote: >>> Pragmatically, what are the features that are strictly necessary on >>> the server side? >>> >>> - Subtree filters? No. >>> >>> - edit-config with all its complexity? No. >>> >>> - Locks? No. A device implementing per-user candidate does not need >>> - them. >> >> So all you have left is file transfer with complete configs. As Andy >> said, why don't you use ftp or http - and call it REST; it's a >> super-trivial REST protcol with just one resource, the config, and you >> can GET and PUT it. Done. >> > > You have a route for someone to introduce NETCONF in two stages. > > You also have an implementation that can be subsequently upgraded to > full NETCONF should you be looking to replace your device with something > less constrained in the future. > It takes about 10 minutes to write some code to use curl to push or pull a file with HTTP. I don't know why people would bother to invent a new version of NETCONF, and then re-engineer a NETCONF-based CM system, just to move a config file back and forth. But I keep looking at this problem in terms of what the application developer gets out of the deal, not what the server vendor gets. > Jonathan > >> >> /martin Andy From j.schoenwaelder@jacobs-university.de Thu Apr 19 02:52:40 2012 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 75E7F21F8562 for ; Thu, 19 Apr 2012 02:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TydIR0b6n+W1 for ; Thu, 19 Apr 2012 02:52:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1932F21F8456 for ; Thu, 19 Apr 2012 02:52:36 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63A7620C9D; Thu, 19 Apr 2012 11:52:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gH0RVyqFaSeS; Thu, 19 Apr 2012 11:52:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A049820CBB; Thu, 19 Apr 2012 11:52:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1DB621E6BF83; Thu, 19 Apr 2012 11:52:34 +0200 (CEST) Date: Thu, 19 Apr 2012 11:52:34 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120419095234.GA62254@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netconf@ietf.org References: <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120418.100112.1647670444223448099.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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: Thu, 19 Apr 2012 09:52:40 -0000 On Wed, Apr 18, 2012 at 10:01:12AM +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Pragmatically, what are the features that are strictly necessary on > > the server side? > > > > - Subtree filters? No. > > > > - edit-config with all its complexity? No. > > > > - Locks? No. A device implementing per-user candidate does not need > > - them. > > So all you have left is file transfer with complete configs. As Andy > said, why don't you use ftp or http - and call it REST; it's a > super-trivial REST protcol with just one resource, the config, and you > can GET and PUT it. Done. Yes, I am sure something like that can be made to work. However, I think we have two options (and I think I stated that before): a) Take a decision to provide a way for devices to support a reduced subset of base NETCONF so that they can more easily integrate / participate in NETCONF configuration management systems. b) Or, take a decision that we leave the configuration management of certain devices to other protocols, likely developed by other people / working groups, likely also ending up with a rather different view of the data models. Orthogonal to all this is the desire to have REST interfaces by some parts of the larger community talking about managing complex service driven networks or clouds rather than devices and by other parts of the community that talk about large numbers of small embedded systems with serious resource constraints. I think we have to answer some strategic questions here about where the NETCONF / YANG community wants to go, whether we are fine with what we have accomplished or whether we want to react to address requirements that go beyond what was driving NETCONF initially. /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 Thu Apr 19 02:59:18 2012 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 4A58321F85B1 for ; Thu, 19 Apr 2012 02:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YarFkScNyGpL for ; Thu, 19 Apr 2012 02:59:17 -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 6057A21F8491 for ; Thu, 19 Apr 2012 02:59:17 -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 1SKo8s-0000Se-S3; Thu, 19 Apr 2012 11:59:15 +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 1SKo8s-00029p-A8; Thu, 19 Apr 2012 11:59:10 +0200 Message-ID: <4F8FE1EE.3050004@bwijnen.net> Date: Thu, 19 Apr 2012 11:59:10 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> In-Reply-To: <4F8FDFA9.7080401@netconfcentral.org> 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: 86ab03e524994f79ca2c75a176445dd4899ed23d336cf6f75da5a87a81e3ffb2 Cc: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 19 Apr 2012 09:59:18 -0000 Inline On 4/19/12 11:49 AM, Andy Bierman wrote: > On 04/19/2012 01:56 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: >>> -----Original Message----- >>> From: Martin Bjorklund [mailto:mbj@tail-f.com] >>> Sent: 18 April 2012 09:01 >>> To: lhotka@nic.cz >>> Cc: netconf@ietf.org >>> Subject: Re: [Netconf] Trying a consensus on the way forward >> withNetconf- >>> Light >>> >>> Ladislav Lhotka wrote: >>>> Pragmatically, what are the features that are strictly necessary on >>>> the server side? >>>> >>>> - Subtree filters? No. >>>> >>>> - edit-config with all its complexity? No. >>>> >>>> - Locks? No. A device implementing per-user candidate does not need >>>> - them. >>> >>> So all you have left is file transfer with complete configs. As Andy >>> said, why don't you use ftp or http - and call it REST; it's a >>> super-trivial REST protcol with just one resource, the config, and you >>> can GET and PUT it. Done. >>> >> >> You have a route for someone to introduce NETCONF in two stages. >> >> You also have an implementation that can be subsequently upgraded to >> full NETCONF should you be looking to replace your device with something >> less constrained in the future. >> > > > It takes about 10 minutes to write some code to use curl to push or pull > a file with HTTP. I don't know why people would bother to invent a new > version of NETCONF, and then re-engineer a NETCONF-based CM system, > just to move a config file back and forth. > > But I keep looking at this problem in terms of what the application > developer gets out of the deal, not what the server vendor gets. > Speaking as an individual contributor. I would think that specifically at the "application developer" side, it would be handy/useful/desirable to be able to "manage/configure" ALL devices (also the constrained ones) with the same NM infrastructure i.e. YANG and NETCONF. Is that naive thinking? Bert >> Jonathan >> >>> >>> /martin > > Andy From dromasca@avaya.com Thu Apr 19 03:06:05 2012 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 87FD021F85A5 for ; Thu, 19 Apr 2012 03:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8rLAf9f+cmj for ; Thu, 19 Apr 2012 03:06:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D929921F8568 for ; Thu, 19 Apr 2012 03:06:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACfjj0+HCzI1/2dsb2JhbABDsT+BB4IJAQEBAQMSHgo6BQwEAgEIDQQEAQEBCgYMCwEGAUUJCAEBBAEJCQgah22dIp1DinELhF5jBJwFiiWCaYFUBg X-IronPort-AV: E=Sophos;i="4.75,446,1330923600"; d="scan'208";a="5126206" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Apr 2012 06:06:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Apr 2012 05:49:27 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Apr 2012 12:06:00 +0200 Message-ID: In-Reply-To: <4F8FE1EE.3050004@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Trying a consensus on the way forwardwithNetconf-Light Thread-Index: Ac0eExmb5OZA7Z4SQ82pCKHQ2sv7GwAAHfjQ References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz><20120418.100112.1647670444223448099.mbj@tail-f.com><83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net><4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Andy Bierman" Cc: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forwardwithNetconf-Light 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, 19 Apr 2012 10:06:05 -0000 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Bert Wijnen (IETF) > Sent: Thursday, April 19, 2012 12:59 PM > To: Andy Bierman > Cc: Jonathan.Hansford@generaldynamics.uk.com; netconf@ietf.org > Subject: Re: [Netconf] Trying a consensus on the way > forwardwithNetconf-Light >=20 > Inline >=20 > On 4/19/12 11:49 AM, Andy Bierman wrote: > > On 04/19/2012 01:56 AM, Jonathan.Hansford@generaldynamics.uk.com > wrote: > >>> -----Original Message----- > >>> From: Martin Bjorklund [mailto:mbj@tail-f.com] > >>> Sent: 18 April 2012 09:01 > >>> To: lhotka@nic.cz > >>> Cc: netconf@ietf.org > >>> Subject: Re: [Netconf] Trying a consensus on the way forward > >> withNetconf- > >>> Light > >>> > >>> Ladislav Lhotka wrote: > >>>> Pragmatically, what are the features that are strictly necessary > on > >>>> the server side? > >>>> > >>>> - Subtree filters? No. > >>>> > >>>> - edit-config with all its complexity? No. > >>>> > >>>> - Locks? No. A device implementing per-user candidate does not > need > >>>> - them. > >>> > >>> So all you have left is file transfer with complete configs. As > Andy > >>> said, why don't you use ftp or http - and call it REST; it's a > >>> super-trivial REST protcol with just one resource, the config, and > you > >>> can GET and PUT it. Done. > >>> > >> > >> You have a route for someone to introduce NETCONF in two stages. > >> > >> You also have an implementation that can be subsequently upgraded to > >> full NETCONF should you be looking to replace your device with > something > >> less constrained in the future. > >> > > > > > > It takes about 10 minutes to write some code to use curl to push or > pull > > a file with HTTP. I don't know why people would bother to invent a > new > > version of NETCONF, and then re-engineer a NETCONF-based CM system, > > just to move a config file back and forth. > > > > But I keep looking at this problem in terms of what the application > > developer gets out of the deal, not what the server vendor gets. > > >=20 > Speaking as an individual contributor. >=20 > I would think that specifically at the "application developer" side, > it would be handy/useful/desirable to be able to "manage/configure" > ALL devices (also the constrained ones) with the same NM infrastructure > i.e. YANG and NETCONF. Is that naive thinking? >=20 > Bert >=20 [[DR]] Yes, and also from the operators perspective this opens the chance to share data models, which I do not know how would be done if we continue to rely on (proprietary) file transfers.=20 In the terms of Juergen's mail, if we do not do a) (provide a way for devices to support a reduced subset of base NETCONF) the world will default to b) ending up with a rather different view of the data models. Regards, Dan From lhotka@nic.cz Thu Apr 19 03:22:23 2012 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 591AD21F84B8 for ; Thu, 19 Apr 2012 03:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSp9C+2iSE7Y for ; Thu, 19 Apr 2012 03:22:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AD67221F84B6 for ; Thu, 19 Apr 2012 03:22:17 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:7066:3a4f:ed2a:398c] (unknown [IPv6:2001:67c:64:42:7066:3a4f:ed2a:398c]) by mail.nic.cz (Postfix) with ESMTPSA id B8DCA14106E; Thu, 19 Apr 2012 12:22:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334830936; bh=Qmkz09brB3cJI5sMxZIu2+fN0TR14dDE6omwvPWftk4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QjWCBYFkq3E79M1i7iDsEdPt1Txv2jcCbX09JQ6EUJSMjporb5OCs5GXDeFmQ6VQt aunqsjCoDN3wR7sBssrGzqyEbSWl17Z5RL0gIh9e70jtJ3CX+re2X8SV+QUQ7QhyK7 B0qicfYWhIqizhpXtb2qE1uy0FOvUSl193XbVv0A= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120419095234.GA62254@elstar.local> Date: Thu, 19 Apr 2012 12:22:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <20120419095234.GA62254@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 19 Apr 2012 10:22:23 -0000 On Apr 19, 2012, at 11:52 AM, Juergen Schoenwaelder wrote: > On Wed, Apr 18, 2012 at 10:01:12AM +0200, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Pragmatically, what are the features that are strictly necessary on >>> the server side? >>>=20 >>> - Subtree filters? No. >>>=20 >>> - edit-config with all its complexity? No. >>>=20 >>> - Locks? No. A device implementing per-user candidate does not need >>> - them. >>=20 >> So all you have left is file transfer with complete configs. As Andy >> said, why don't you use ftp or http - and call it REST; it's a >> super-trivial REST protcol with just one resource, the config, and = you >> can GET and PUT it. Done. >=20 > Yes, I am sure something like that can be made to work. However, I > think we have two options (and I think I stated that before): >=20 > a) Take a decision to provide a way for devices to support a reduced > subset of base NETCONF so that they can more easily integrate / > participate in NETCONF configuration management systems. >=20 > b) Or, take a decision that we leave the configuration management of > certain devices to other protocols, likely developed by other > people / working groups, likely also ending up with a rather > different view of the data models. This is probably already happening in many places. It might be useful = though to promote YANG for data modelling outside NETCONF. And I would also add c) Take a decision to develop NETCONF 2.0 as a barebone version that = would work for all devices and make other features currently included in = base NETCONF 1.1 into optional (some of them perhaps RECOMMENDED) = capabilities. For existing implementations this would only mean advertising a few = additional capabilities. Lada=20 =20 >=20 > Orthogonal to all this is the desire to have REST interfaces by some > parts of the larger community talking about managing complex service > driven networks or clouds rather than devices and by other parts of > the community that talk about large numbers of small embedded systems > with serious resource constraints. >=20 > I think we have to answer some strategic questions here about where > the NETCONF / YANG community wants to go, whether we are fine with > what we have accomplished or whether we want to react to address > requirements that go beyond what was driving NETCONF initially. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Apr 19 03:28:46 2012 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 6D8B121F85DF for ; Thu, 19 Apr 2012 03:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxJwWIFIgEyH for ; Thu, 19 Apr 2012 03:28:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 14CE621F85D9 for ; Thu, 19 Apr 2012 03:28:42 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E9B020CD0; Thu, 19 Apr 2012 12:28:41 +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 FLUbQfldRFEJ; Thu, 19 Apr 2012 12:28:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A1E820CC8; Thu, 19 Apr 2012 12:28:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 757F81E6C209; Thu, 19 Apr 2012 12:28:42 +0200 (CEST) Date: Thu, 19 Apr 2012 12:28:42 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120419102842.GB62360@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netconf@ietf.org References: <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <20120419095234.GA62254@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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: Thu, 19 Apr 2012 10:28:46 -0000 On Thu, Apr 19, 2012 at 12:22:15PM +0200, Ladislav Lhotka wrote: > > On Apr 19, 2012, at 11:52 AM, Juergen Schoenwaelder wrote: > > > On Wed, Apr 18, 2012 at 10:01:12AM +0200, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: > >>> Pragmatically, what are the features that are strictly necessary on > >>> the server side? > >>> > >>> - Subtree filters? No. > >>> > >>> - edit-config with all its complexity? No. > >>> > >>> - Locks? No. A device implementing per-user candidate does not need > >>> - them. > >> > >> So all you have left is file transfer with complete configs. As Andy > >> said, why don't you use ftp or http - and call it REST; it's a > >> super-trivial REST protcol with just one resource, the config, and you > >> can GET and PUT it. Done. > > > > Yes, I am sure something like that can be made to work. However, I > > think we have two options (and I think I stated that before): > > > > a) Take a decision to provide a way for devices to support a reduced > > subset of base NETCONF so that they can more easily integrate / > > participate in NETCONF configuration management systems. > > > > b) Or, take a decision that we leave the configuration management of > > certain devices to other protocols, likely developed by other > > people / working groups, likely also ending up with a rather > > different view of the data models. > > This is probably already happening in many places. It might be useful though to promote YANG for data modelling outside NETCONF. > > And I would also add > > c) Take a decision to develop NETCONF 2.0 as a barebone version that would work for all devices and make other features currently included in base NETCONF 1.1 into optional (some of them perhaps RECOMMENDED) capabilities. I tried to stay away from _how_ to do this instead focusing on the question whether there is something to do or not. So I think your c) is not really a c). ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Thu Apr 19 04:32:13 2012 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 BE9EB21F858F for ; Thu, 19 Apr 2012 04:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlcW+oNZ39Dn for ; Thu, 19 Apr 2012 04:32:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B400A21F85F9 for ; Thu, 19 Apr 2012 04:32:07 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:41f3:7e02:a06d:1db9] (unknown [IPv6:2001:67c:64:42:41f3:7e02:a06d:1db9]) by mail.nic.cz (Postfix) with ESMTPSA id F1F2214106E; Thu, 19 Apr 2012 13:32:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334835127; bh=LI3mHV4AAchiBjcrnYV+CHXIHMpSW8ikylFZVejM+uQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LOfuiHUmOdue5yY7JlcVxZpNXChQUDVsV9SjgeH+qnyvBt1uX/FwtY4jocRCbn08v 2cym5h4mV0hN6on9+Ognxp1BrjOzhx5UZc/e7R5E0d5osX3I+0A+0ETdj3BODFRpj5 ON6UU5umn/hkSZswCIs98KCPCjLwIfw9RrFkIfLE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120419102842.GB62360@elstar.local> Date: Thu, 19 Apr 2012 13:32:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16CB30FE-D1CA-41E9-A139-4A21FCB4BFBC@nic.cz> References: <4F8DCE47.1060609@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net> <71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <20120419095234.GA62254@elstar.local> <20120419102842.GB62360@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 19 Apr 2012 11:32:13 -0000 On Apr 19, 2012, at 12:28 PM, Juergen Schoenwaelder wrote: > On Thu, Apr 19, 2012 at 12:22:15PM +0200, Ladislav Lhotka wrote: >>=20 >> On Apr 19, 2012, at 11:52 AM, Juergen Schoenwaelder wrote: >>=20 >>> On Wed, Apr 18, 2012 at 10:01:12AM +0200, Martin Bjorklund wrote: >>>> Ladislav Lhotka wrote: >>>>> Pragmatically, what are the features that are strictly necessary = on >>>>> the server side? >>>>>=20 >>>>> - Subtree filters? No. >>>>>=20 >>>>> - edit-config with all its complexity? No. >>>>>=20 >>>>> - Locks? No. A device implementing per-user candidate does not = need >>>>> - them. >>>>=20 >>>> So all you have left is file transfer with complete configs. As = Andy >>>> said, why don't you use ftp or http - and call it REST; it's a >>>> super-trivial REST protcol with just one resource, the config, and = you >>>> can GET and PUT it. Done. >>>=20 >>> Yes, I am sure something like that can be made to work. However, I >>> think we have two options (and I think I stated that before): >>>=20 >>> a) Take a decision to provide a way for devices to support a reduced >>> subset of base NETCONF so that they can more easily integrate / >>> participate in NETCONF configuration management systems. >>>=20 >>> b) Or, take a decision that we leave the configuration management of >>> certain devices to other protocols, likely developed by other >>> people / working groups, likely also ending up with a rather >>> different view of the data models. >>=20 >> This is probably already happening in many places. It might be useful = though to promote YANG for data modelling outside NETCONF. >>=20 >> And I would also add >>=20 >> c) Take a decision to develop NETCONF 2.0 as a barebone version that = would work for all devices and make other features currently included in = base NETCONF 1.1 into optional (some of them perhaps RECOMMENDED) = capabilities. >=20 > I tried to stay away from _how_ to do this instead focusing on the > question whether there is something to do or not. So I think your c) > is not really a c). ;-) OK. On a side note, I am now attending RIPE 64 and just saw a demonstration = of a switch which can be configured via Jabber. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Thu Apr 19 08:16:30 2012 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 5315221F8639 for ; Thu, 19 Apr 2012 08:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5rA8TpN69lD for ; Thu, 19 Apr 2012 08:16:29 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 11BC121F8606 for ; Thu, 19 Apr 2012 08:16:28 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3JFGRYU000609 for ; Thu, 19 Apr 2012 11:16:27 -0400 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:34950] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F3/46-17184-A4C209F4; Thu, 19 Apr 2012 11:16:27 -0400 Message-ID: <4F902C4A.8070809@netconfcentral.org> Date: Thu, 19 Apr 2012 08:16:26 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> In-Reply-To: <4F8FE1EE.3050004@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 19 Apr 2012 15:16:30 -0000 On 04/19/2012 02:59 AM, Bert Wijnen (IETF) wrote: > Inline > > On 4/19/12 11:49 AM, Andy Bierman wrote: >> On 04/19/2012 01:56 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: >>>> -----Original Message----- >>>> From: Martin Bjorklund [mailto:mbj@tail-f.com] >>>> Sent: 18 April 2012 09:01 >>>> To: lhotka@nic.cz >>>> Cc: netconf@ietf.org >>>> Subject: Re: [Netconf] Trying a consensus on the way forward >>> withNetconf- >>>> Light >>>> >>>> Ladislav Lhotka wrote: >>>>> Pragmatically, what are the features that are strictly necessary on >>>>> the server side? >>>>> >>>>> - Subtree filters? No. >>>>> >>>>> - edit-config with all its complexity? No. >>>>> >>>>> - Locks? No. A device implementing per-user candidate does not need >>>>> - them. >>>> >>>> So all you have left is file transfer with complete configs. As Andy >>>> said, why don't you use ftp or http - and call it REST; it's a >>>> super-trivial REST protcol with just one resource, the config, and you >>>> can GET and PUT it. Done. >>>> >>> >>> You have a route for someone to introduce NETCONF in two stages. >>> >>> You also have an implementation that can be subsequently upgraded to >>> full NETCONF should you be looking to replace your device with something >>> less constrained in the future. >>> >> >> >> It takes about 10 minutes to write some code to use curl to push or pull >> a file with HTTP. I don't know why people would bother to invent a new >> version of NETCONF, and then re-engineer a NETCONF-based CM system, >> just to move a config file back and forth. >> >> But I keep looking at this problem in terms of what the application >> developer gets out of the deal, not what the server vendor gets. >> > > Speaking as an individual contributor. > > I would think that specifically at the "application developer" side, > it would be handy/useful/desirable to be able to "manage/configure" > ALL devices (also the constrained ones) with the same NM infrastructure > i.e. YANG and NETCONF. Is that naive thinking? > Having YANG data models everywhere would help. Having the instance naming from SNMP traps and SYSLOG messages match up with the instance naming in the NETCONF datastore and the CLI would help a lot. Being able to reuse your code that starts up a NETCONF session is not very interesting. Code like curl already does all that for you. It's the operations that really matter. "Get the entire config" "Replace the entire config" Assuming this is the minimum functionality set, there are lots of protocols that could perform these tasks. This is separate from the schema language used to define the contents of the config. > Bert > >>> Jonathan >>> >>>> >>>> /martin >> >> Andy > > Andy From kwatsen@juniper.net Mon Apr 23 09:10:58 2012 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 4153E21F856C for ; Mon, 23 Apr 2012 09:10:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEU8H-eDUgvB for ; Mon, 23 Apr 2012 09:10:57 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 057C521F858E for ; Mon, 23 Apr 2012 09:10:56 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT5V/C/HztkFiLV81famWnsQb5ZMlAwsc@postini.com; Mon, 23 Apr 2012 09:10:57 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; Mon, 23 Apr 2012 09:10:37 -0700 From: Kent Watsen To: Andy Bierman , "Bert Wijnen (IETF)" Date: Mon, 23 Apr 2012 09:10:34 -0700 Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0eP2i2YLZc/jLVQkqH2D/HfARfXQDKxFjQ Message-ID: <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> In-Reply-To: <4F902C4A.8070809@netconfcentral.org> 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: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 23 Apr 2012 16:10:58 -0000 > Being able to reuse your code that starts up a NETCONF session is not > very interesting. Code like curl already does all that for you. > It's the operations that really matter. > > "Get the entire config" > "Replace the entire config" > > Assuming this is the minimum functionality set, there are lots of protoco= ls > that could perform these tasks. This is separate from the schema languag= e > used to define the contents of the config. True, but for a vendor who has many devices, some constrained and some not,= it would be very nice to have some continuity between them, even if it's j= ust the transport (i.e. netconf-zero). For instance, our BUs prioritize im= plementing our proprietary NETCONF capabilities over NETCONF's CM operation= s. For constrained devices, our primary market demands would be satisfied = even if they could only do entire-config operations plus a few of the extra= RPCs we defined. Thanks, Kent From andy@netconfcentral.org Mon Apr 23 09:43:22 2012 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 C792021F86F7 for ; Mon, 23 Apr 2012 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfmTacn+zA4P for ; Mon, 23 Apr 2012 09:43:21 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 464F921F86E4 for ; Mon, 23 Apr 2012 09:43:21 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3NGhJ7f027725 for ; Mon, 23 Apr 2012 12:43:19 -0400 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48628] helo=[192.168.0.9]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 6D/EF-14453-7A6859F4; Mon, 23 Apr 2012 12:43:19 -0400 Message-ID: <4F9586A9.80804@netconfcentral.org> Date: Mon, 23 Apr 2012 09:43:21 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kent Watsen References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 23 Apr 2012 16:43:22 -0000 On 04/23/2012 09:10 AM, Kent Watsen wrote: >> Being able to reuse your code that starts up a NETCONF session is not >> very interesting. Code like curl already does all that for you. >> It's the operations that really matter. >> >> "Get the entire config" >> "Replace the entire config" >> >> Assuming this is the minimum functionality set, there are lots of protocols >> that could perform these tasks. This is separate from the schema language >> used to define the contents of the config. > > True, but for a vendor who has many devices, some constrained and some not, it would be very nice to have some continuity between them, even if it's just the transport (i.e. netconf-zero). For instance, our BUs prioritize implementing our proprietary NETCONF capabilities over NETCONF's CM operations. For constrained devices, our primary market demands would be satisfied even if they could only do entire-config operations plus a few of the extra RPCs we defined. > Well netconf-zero would certainly fix your feature development priority issues. You could just implement the and maybe get around to some operations some day. IMO, netconf-zero is a non-starter. Locking is an important component of NETCONF. If only 1 session at a time is allowed it is trivial. If more than 1 concurrent session is allowed it is important to have. Subtree filtering and are not really must-have features. Not sure if my minimum must-implement list now exactly matches draft-00: - copy-config - close-session - get-config (no filtering) - lock - unlock This allows multiple sessions to safely inspect, edit offline, and replace the config. I can't see lowering the bar any lower than this, and still call the device "NETCONF manageable". > Thanks, > Kent > Andy From lhotka@nic.cz Mon Apr 23 11:48:40 2012 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 A831521F85F7 for ; Mon, 23 Apr 2012 11:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjeeCxzDpB3v for ; Mon, 23 Apr 2012 11:48:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64421F85EA for ; Mon, 23 Apr 2012 11:48:30 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id EF57B141068; Mon, 23 Apr 2012 20:48:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335206909; bh=o0ccUIfzdjYO0SyXBOjVNgGLHjcArnbez36qDYsolvc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EsHBVCVPQIFYIH2Sdor92e1y9vikb/z8lywdURBERSO7VEIJbA21hSU0Y+ExkQOfh t7K5tKzuGUbrCE5ztTdkO6Z8JtGnIwUm3zcrteK10be5hHed4l1opT78V2n/t9PcbL kjvEy7dkPcqwbtb8oPr59Zry5ee/JvWWsPXdRniA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F9586A9.80804@netconfcentral.org> Date: Mon, 23 Apr 2012 20:48:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 23 Apr 2012 18:48:40 -0000 On Apr 23, 2012, at 6:43 PM, Andy Bierman wrote: > On 04/23/2012 09:10 AM, Kent Watsen wrote: >>> Being able to reuse your code that starts up a NETCONF session is = not >>> very interesting. Code like curl already does all that for you. >>> It's the operations that really matter. >>>=20 >>> "Get the entire config" >>> "Replace the entire config" >>>=20 >>> Assuming this is the minimum functionality set, there are lots of = protocols >>> that could perform these tasks. This is separate from the schema = language >>> used to define the contents of the config. >>=20 >> True, but for a vendor who has many devices, some constrained and = some not, it would be very nice to have some continuity between them, = even if it's just the transport (i.e. netconf-zero). For instance, our = BUs prioritize implementing our proprietary NETCONF capabilities over = NETCONF's CM operations. For constrained devices, our primary market = demands would be satisfied even if they could only do entire-config = operations plus a few of the extra RPCs we defined. >>=20 >=20 > Well netconf-zero would certainly fix your feature development = priority issues. > You could just implement the and maybe get around to some = operations some day. > IMO, netconf-zero is a non-starter. >=20 > Locking is an important component of NETCONF. > If only 1 session at a time is allowed it is trivial. > If more than 1 concurrent session is allowed it is important to have. >=20 > Subtree filtering and are not really must-have features. > Not sure if my minimum must-implement list now exactly matches = draft-00: >=20 > - copy-config > - close-session > - get-config (no filtering) > - lock > - unlock Without edit-config, I don't see any need for locking the repository = because it can only be modified via copy-config which is presumably = atomic. Am I missing something? Lada >=20 > This allows multiple sessions to safely inspect, edit offline, and = replace the config. > I can't see lowering the bar any lower than this, and still call the > device "NETCONF manageable". >=20 >=20 >> Thanks, >> Kent >>=20 >=20 > Andy >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Mon Apr 23 11:50:53 2012 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 64B9121F85C2 for ; Mon, 23 Apr 2012 11:50:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRz5xgj7PAyk for ; Mon, 23 Apr 2012 11:50:52 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3621F85C0 for ; Mon, 23 Apr 2012 11:50:51 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT5WkhYILEsJEnUDGWUFnIpy6nmhYI+rW@postini.com; Mon, 23 Apr 2012 11:50:51 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 23 Apr 2012 11:49:17 -0700 From: Kent Watsen To: Andy Bierman Date: Mon, 23 Apr 2012 11:49:16 -0700 Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0hcDOr8aIfeZYrTv2apvqIJegFGQACQwqw Message-ID: <84600D05C20FF943918238042D7670FD48C1810402@EMBX01-HQ.jnpr.net> References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> In-Reply-To: <4F9586A9.80804@netconfcentral.org> 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: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 23 Apr 2012 18:50:53 -0000 > Well netconf-zero would certainly fix your feature development priority i= ssues. > You could just implement the and maybe get around to some operati= ons some day. Yes, this is exactly what some of our devices currently do. Of course, we = also made up a strategy for expressing the device doesn't support CM, since= NETCONF hasn't provided one yet ;) > IMO, netconf-zero is a non-starter. I wonder if anyone else on the list feels this way, so far, IIRC, yours is = the only dissenting opinion > Locking is an important component of NETCONF. > If only 1 session at a time is allowed it is trivial. > If more than 1 concurrent session is allowed it is important to have. Devices that only support writable-running sometimes don't implement a lock= , as the developers assume the CLI is instantaneously always up to date (I'= ve seen this more than once). Naturally, these devices wouldn't implement = NETCONF, due to their CLI-centric worldview, and so NMS systems are incenti= vized to implement a NETCONF-adapter for them. We have that very case, an= d our off-box NETCONF adapter *lies* about the RPC succeeding. BTW, we also have a device that implemented user-specific candidate configs= as default. I pointed out to the dev-team that the RFC called for a globa= l candidate datastore, but they didn't care, citing that user-specific was = even more useful. I bring this up because, in this case, it seems that loc= king is also somewhat unnecessary. I know that NETCONF doesn't support use= r-specific candidate datastores yet, but given that vendors are already doi= ng it, it seems the writing is on the wall... =20 > Subtree filtering and are not really must-have features. > Not sure if my minimum must-implement list now exactly matches draft-00: > > - copy-config > - close-session > - get-config (no filtering) > - lock > - unlock > > This allows multiple sessions to safely inspect, edit offline, and replac= e the config. > I can't see lowering the bar any lower than this, and still call the > device "NETCONF manageable". I don't know if "NETCONF manageable" is a defined term, but at least half o= ur devices have a different notion of what it means to be managed than your= s. For some of them, the configuration can be dynamically learned from the= network, what needs to centralized is software-distribution and licensing = (some of what our proprietary capabilities enable) K. From andy@netconfcentral.org Mon Apr 23 12:20:12 2012 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 F05C421F85A3 for ; Mon, 23 Apr 2012 12:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HUqpSMWJioo for ; Mon, 23 Apr 2012 12:20:11 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 35B3B21F8555 for ; Mon, 23 Apr 2012 12:20:11 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3NJKAhC027357 for ; Mon, 23 Apr 2012 15:20:10 -0400 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48867] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 88/37-02293-96BA59F4; Mon, 23 Apr 2012 15:20:10 -0400 Message-ID: <4F95AB6C.1070408@netconfcentral.org> Date: Mon, 23 Apr 2012 12:20:12 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 23 Apr 2012 19:20:12 -0000 On 04/23/2012 11:48 AM, Ladislav Lhotka wrote: > > On Apr 23, 2012, at 6:43 PM, Andy Bierman wrote: > >> On 04/23/2012 09:10 AM, Kent Watsen wrote: >>>> Being able to reuse your code that starts up a NETCONF session is not >>>> very interesting. Code like curl already does all that for you. >>>> It's the operations that really matter. >>>> >>>> "Get the entire config" >>>> "Replace the entire config" >>>> >>>> Assuming this is the minimum functionality set, there are lots of protocols >>>> that could perform these tasks. This is separate from the schema language >>>> used to define the contents of the config. >>> >>> True, but for a vendor who has many devices, some constrained and some not, it would be very nice to have some continuity between them, even if it's just the transport (i.e. netconf-zero). For instance, our BUs prioritize implementing our proprietary NETCONF capabilities over NETCONF's CM operations. For constrained devices, our primary market demands would be satisfied even if they could only do entire-config operations plus a few of the extra RPCs we defined. >>> >> >> Well netconf-zero would certainly fix your feature development priority issues. >> You could just implement the and maybe get around to some operations some day. >> IMO, netconf-zero is a non-starter. >> >> Locking is an important component of NETCONF. >> If only 1 session at a time is allowed it is trivial. >> If more than 1 concurrent session is allowed it is important to have. >> >> Subtree filtering and are not really must-have features. >> Not sure if my minimum must-implement list now exactly matches draft-00: >> >> - copy-config >> - close-session >> - get-config (no filtering) >> - lock >> - unlock > > Without edit-config, I don't see any need for locking the repository because it can only be modified via copy-config which is presumably atomic. Am I missing something? > I don't think NETCONF provides any atomicity across sessions. Messages within a session are serialized but not across multiple sessions. Sometimes locking is used just to retrieve a clean response that has not been partially altered during the retrieval. But I agree locking is not critical if the server does 1 operation at a time, and the entire config is retrieved or replaced in 1 operation. I don't think this counts as network configuration, which is the charter of the NETCONF working group. So we are back to a file transfer protocol for 1 hardwired file: - copy-config - close-session - get-config (no filtering) > Lada Andy From mbadra@gmail.com Mon Apr 23 13:08:31 2012 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 8C49421F85F2 for ; Mon, 23 Apr 2012 13:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b14GbtSMyqBy for ; Mon, 23 Apr 2012 13:08:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB421F85EF for ; Mon, 23 Apr 2012 13:08:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so9843641vbb.31 for ; Mon, 23 Apr 2012 13:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KB1hcNaRIZfvxxTA7+tMOr3P73Yrk3p8fSsUn1faRSE=; b=ZH3fOizBb9k7+gK/KdK8uQnWyWMOwVEtzXP5KkREgRM+iq4LRTGn6Is78YTm3wnXsn nrljYDo0Ex7V9orCqzZslhPMHL3ON4YW3juIgSv2G8yz5LcqFzh+/iIh2ZKfUdq84Aex kvF/RF3fy3iwc86L0vkhYAdbGvm9EX/4SPRo3JqKkElOiHHc3yMfXG25KNMLSTgMYwkd 6LhvdB7w+WkxmgP3AgkFo+ZBUM3PRJgTA2iR/Dna2u9tVoNqiDdlIFagQRlsL8qDtoTo aWnrXdXz8t4yOmpJcI6NnJTNadmgurF0cvBRrQNRtUNRRKpqc3voLmSrRGOzoYRbq8/N N5ZQ== MIME-Version: 1.0 Received: by 10.52.175.231 with SMTP id cd7mr2221288vdc.68.1335211707863; Mon, 23 Apr 2012 13:08:27 -0700 (PDT) Received: by 10.220.5.20 with HTTP; Mon, 23 Apr 2012 13:08:27 -0700 (PDT) In-Reply-To: <20120411183312.GA31171@elstar.local> References: <201204111536.LAA15744@adminfs.snmp.com> <20120411183312.GA31171@elstar.local> Date: Mon, 23 Apr 2012 22:08:27 +0200 Message-ID: From: Mohamad Badra To: Juergen Schoenwaelder , Alan Luchuk , netconf@ietf.org, mbadra@gmail.com Content-Type: multipart/alternative; boundary=bcaec5171e878c11cc04be5e33e6 Subject: Re: [Netconf] Updates to the ietf-netconf-tls.yang module 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, 23 Apr 2012 20:08:31 -0000 --bcaec5171e878c11cc04be5e33e6 Content-Type: text/plain; charset=ISO-8859-1 Dear Juergen, > typedef tls-fingerprint-type { > > type binary { > > length "1..max"; > > } > > description > > "A cryptographic signature (fingerprint) value that can be used to > > uniquely reference other data of potentially arbitrary length."; > > } > > The binary type means the data is encoded in base64. The tools I am > familiar with that produce hash values seem to generate hexadecimal > representations. Do you mean something like that? leaf key { type string { pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; } nacm:default-deny-all; description "The key associated with the PSK identity"; } > leaf key { > > type binary; > > nacm:default-deny-all; > > description > > "The key associated with the PSK identity"; > > } > > The same question raised above applies here. Is a base64 > representation really what people feel comfortable with? Using base64 > might be more OK here than above - I do not really know. > And: typedef tls-fingerprint-type { type string { pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; } } Best regards, Badra --bcaec5171e878c11cc04be5e33e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Juergen,

> =A0t= ypedef tls-fingerprint-type {
> =A0 =A0type binary {
> =A0 =A0 =A0length "1..max";
> =A0 =A0}
> =A0 =A0description
> =A0 =A0 =A0"A cryptographic signature (fingerprint) value that ca= n be used to
> =A0 =A0 =A0 uniquely reference other data of potentially arbitrary len= gth.";
> =A0}

The binary type means the data is encoded in base64. The tools I am familiar with that produce hash values seem to generate hexadecimal
representations.

Do you mean something like= that?

leaf key {
type string {
= pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*';
<= div class=3D"gmail_extra" style>
}
=A0 =A0 =A0 =A0 nacm:default-deny-all;
=A0 =A0 =A0 =A0 descriptio= n
=A0 =A0 =A0 =A0 =A0 "The key associated with the PSK identity&quo= t;;
=A0 =A0 =A0 =A0}

> =A0 =A0 =A0leaf key {
> =A0 =A0 =A0 =A0type binary;
> =A0 =A0 =A0 =A0nacm:default-deny-all;
> =A0 =A0 =A0 =A0description
> =A0 =A0 =A0 =A0 =A0"The key associated with the PSK identity"= ;;
> =A0 =A0 =A0}

The same question raised above applies here. Is a base64
representation really what people feel comfortable with? Using base64
might be more OK here than above - I do not really know.

<= div>And:

=A0 typedef tls-fingerprint-type {
type string {
pattern '([0-9a-fA-F])= {2}(:([0-9a-fA-F]){2})*';
}
}=A0

Be= st regards,
Badra
--bcaec5171e878c11cc04be5e33e6-- From luchuk@snmp.com Wed Apr 25 13:01:37 2012 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 92C9E21F87BD for ; Wed, 25 Apr 2012 13:01:37 -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_28=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAkqDXF2TeJh for ; Wed, 25 Apr 2012 13:01:37 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id B84CD21F881B for ; Wed, 25 Apr 2012 13:01:36 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA25462; Wed, 25 Apr 2012 16:01:35 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id QAA15345; Wed, 25 Apr 2012 16:01:35 -0400 (EDT) Date: Wed, 25 Apr 2012 16:01:35 -0400 (EDT) From: Alan Luchuk Message-Id: <201204252001.QAA15345@adminfs.snmp.com> To: andy@netconfcentral.org Cc: netconf@ietf.org Subject: [Netconf] NETCONF message serialization 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, 25 Apr 2012 20:01:37 -0000 Hello, On Mon, 23 Apr 2012, Andy Bierman wrote: AB>I don't think NETCONF provides any atomicity across sessions. AB>Messages within a session are serialized but not across multiple sessions. Where is this behavior specified? RFC 6241 Section 4.5 says: 4.5. Pipelining NETCONF requests MUST be processed serially by the managed device. Additional requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received. I interpret section 4.5 as "all messages (from all sessions) must be serialized." Have I missed a clarification specified somewhere else? Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From andy@netconfcentral.org Wed Apr 25 13:19:23 2012 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 7345C21F8966 for ; Wed, 25 Apr 2012 13:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lcDB+PhX81q for ; Wed, 25 Apr 2012 13:19:23 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7B21F88F7 for ; Wed, 25 Apr 2012 13:19:21 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3PKJKG4020804 for ; Wed, 25 Apr 2012 16:19:20 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:56693] helo=[192.168.0.9]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 64/E0-22382-74C589F4; Wed, 25 Apr 2012 16:19:20 -0400 Message-ID: <4F985C4B.7010304@netconfcentral.org> Date: Wed, 25 Apr 2012 13:19:23 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alan Luchuk References: <201204252001.QAA15345@adminfs.snmp.com> In-Reply-To: <201204252001.QAA15345@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message serialization 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, 25 Apr 2012 20:19:23 -0000 On 04/25/2012 01:01 PM, Alan Luchuk wrote: > Hello, > > On Mon, 23 Apr 2012, Andy Bierman wrote: > > AB>I don't think NETCONF provides any atomicity across sessions. > AB>Messages within a session are serialized but not across multiple sessions. > > > Where is this behavior specified? RFC 6241 Section 4.5 says: > > 4.5. Pipelining > > NETCONF requests MUST be processed serially by the managed > device. Additional requests MAY be sent before previous ones > have been completed. The managed device MUST send responses only in > the order the requests were received. > > I interpret section 4.5 as "all messages (from all sessions) must be > serialized." Have I missed a clarification specified somewhere else? > I thought there was text that this serialization was just within a single session. I remember that was the intent of the co-authors. Imagine if one session is doing a of the entire device over a slow link. The server is supposed to lock out all other sessions until that RPC is done? I hope not. That does not scale well. I think Sec. 4 refers to within a single session. There is also the possibility that the datastore is altered from some other protocol than NETCONF, in which case this serialization rule does not apply at all. > Regards, > --Alan > Andy From kwatsen@juniper.net Wed Apr 25 13:24:54 2012 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 4069E11E8080 for ; Wed, 25 Apr 2012 13:24:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmSJnDxkkdwy for ; Wed, 25 Apr 2012 13:24:52 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9548C11E8089 for ; Wed, 25 Apr 2012 13:24:48 -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 DSNKT5hdhnrzR0Bm9382vF26h+fzovB53o5H@postini.com; Wed, 25 Apr 2012 13:24:48 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, 25 Apr 2012 13:24:06 -0700 From: Kent Watsen To: Andy Bierman , Alan Luchuk Date: Wed, 25 Apr 2012 13:24:04 -0700 Thread-Topic: [Netconf] NETCONF message serialization Thread-Index: Ac0jILYHYFWm3EMATUazaxw/by1auQAAHyMg Message-ID: <84600D05C20FF943918238042D7670FD48C1B288D9@EMBX01-HQ.jnpr.net> References: <201204252001.QAA15345@adminfs.snmp.com> <4F985C4B.7010304@netconfcentral.org> In-Reply-To: <4F985C4B.7010304@netconfcentral.org> 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: "netconf@ietf.org" Subject: Re: [Netconf] NETCONF message serialization 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, 25 Apr 2012 20:24:54 -0000 > I thought there was text that this serialization was just within a single= session. Agreed. This is how it was intended, and how we implemented it... K. From mbj@tail-f.com Wed Apr 25 13:44:33 2012 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 DDA6921F8899 for ; Wed, 25 Apr 2012 13:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEwWUuFddjh6 for ; Wed, 25 Apr 2012 13:44:33 -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 EBDA521F8895 for ; Wed, 25 Apr 2012 13:44:32 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D11D512008BF; Wed, 25 Apr 2012 22:44:30 +0200 (CEST) Date: Wed, 25 Apr 2012 22:44:30 +0200 (CEST) Message-Id: <20120425.224430.289915194.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD48C1B288D9@EMBX01-HQ.jnpr.net> References: <201204252001.QAA15345@adminfs.snmp.com> <4F985C4B.7010304@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1B288D9@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message serialization 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, 25 Apr 2012 20:44:34 -0000 Kent Watsen wrote: > > I thought there was text that this serialization was just within a single > > session. > > Agreed. This is how it was intended, and how we implemented it... Same here. It would be pretty bad if one time-consuming rpc would lock out any other session trying to read a single state leaf, for example. /martin From luchuk@snmp.com Thu Apr 26 11:41:55 2012 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 32F5121E815D for ; Thu, 26 Apr 2012 11:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSFMzNzpr6Lz for ; Thu, 26 Apr 2012 11:41:54 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5F32D21E816B for ; Thu, 26 Apr 2012 11:41:53 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA10349; Thu, 26 Apr 2012 14:41:40 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id OAA20118; Thu, 26 Apr 2012 14:41:22 -0400 (EDT) Date: Thu, 26 Apr 2012 14:41:22 -0400 (EDT) From: Alan Luchuk Message-Id: <201204261841.OAA20118@adminfs.snmp.com> To: andy@netconfcentral.org Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message serialization 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, 26 Apr 2012 18:41:55 -0000 Hello, AB>I thought there was text that this serialization was just within a single AB>session. I remember that was the intent of the co-authors. Thanks to Andy, Martin, and Kent for clarifying the intended behavior. Should there be an update to RFC 6241, I suggest adding a few words to Section 4.5 to clarify that the serialization occurs per-session. Something like: 4.5. Pipelining NETCONF requests received on a single session MUST be processed serially by the managed device. Additional requests MAY be sent on a single session before previous ones have been completed. The managed device MUST send responses on the session only in the order the requests were received. A managed device is not required to serially process requests received from different sessions. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From lhotka@nic.cz Thu Apr 26 22:18:35 2012 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 5FE5921F8702 for ; Thu, 26 Apr 2012 22:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybvXfl944ZpS for ; Thu, 26 Apr 2012 22:18:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B821F86FA for ; Thu, 26 Apr 2012 22:18:33 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 909AA13F9D4; Fri, 27 Apr 2012 07:18:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335503912; bh=GXp7jwwAhYV8MipdHIfNWJ7cCBEREi0Pe3iqN5tLklo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=RsapE3eM4e2RgOuQmcGf3hG+6KtQSJx72sD5ysFzlCvSJAF3HzDClOnm871e3Ow4x wqwCnAmOqYBjuB+yQaP/7xAn/abqPHGIUhFTqrHeZhwm41BqayLoiTbD9AjKFaJ0bH XYphHNenL6SSQqZw3Qn71ubUb9sE/rJOpzICKrwI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201204261841.OAA20118@adminfs.snmp.com> Date: Fri, 27 Apr 2012 07:18:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201204261841.OAA20118@adminfs.snmp.com> To: Alan Luchuk X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF message serialization 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, 27 Apr 2012 05:18:35 -0000 Hi, I think it is very reasonable to require atomicity of all writes to all = datastores, even across sessions, otherwise a concurrent may = obtain inconsistent data - even with locks. Lada On Apr 26, 2012, at 8:41 PM, Alan Luchuk wrote: > Hello, >=20 > AB>I thought there was text that this serialization was just within a = single=20 > AB>session. I remember that was the intent of the co-authors. >=20 >=20 > Thanks to Andy, Martin, and Kent for clarifying the intended behavior. = =20 > Should there be an update to RFC 6241, I suggest adding a few words to=20= > Section 4.5 to clarify that the serialization occurs per-session. =20 > Something like: >=20 > 4.5. Pipelining >=20 > NETCONF requests received on a single session MUST be = processed=20 > serially by the managed device. Additional requests MAY be = sent=20 > on a single session before previous ones have been completed. The=20= > managed device MUST send responses on the session only in the order = the=20 > requests were received. A managed device is not required to = serially > process requests received from different sessions. >=20 >=20 > Regards, > --Alan >=20 > = --------------------------------------------------------------------------= ---- > Alan Luchuk SNMP Research, Inc. Voice: +1 865 = 573 1434 > Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 = 573 9197 > luchuk@snmp.com Knoxville, TN 37920-9716 = http://www.snmp.com/ > = --------------------------------------------------------------------------= ---- >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Fri Apr 27 07:34:16 2012 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 71E8721F861E for ; Fri, 27 Apr 2012 07:34:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+iOigeZYF-g for ; Fri, 27 Apr 2012 07:34:15 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 76FBC21F861A for ; Fri, 27 Apr 2012 07:34:15 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT5quYdd//kiKZ+2biuys59RcsX+jSuLX@postini.com; Fri, 27 Apr 2012 07:34:15 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; Fri, 27 Apr 2012 07:33:58 -0700 From: Kent Watsen To: Andy Bierman , Ladislav Lhotka Date: Fri, 27 Apr 2012 07:33:54 -0700 Thread-Topic: [Netconf] Trying a consensus on the way forward withNetconf-Light Thread-Index: Ac0hhhsg/pVASA+US1yvKl3fe82N0QC+pc0w Message-ID: <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> <4F95AB6C.1070408@netconfcentral.org> In-Reply-To: <4F95AB6C.1070408@netconfcentral.org> 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: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 27 Apr 2012 14:34:16 -0000 Andy Bierman wrote: > So we are back to a file transfer protocol for 1 hardwired file: > - copy-config > - close-session > - get-config (no filtering) This set of operations for a new "base" looks good to me, but I'd like it t= o be the case that the new "base" capability doesn't have to be advertized.= For instance, assuming we define a "base:2.0": urn:ietf:params:netconf:base:2.0 http://acme.com/foobar/1.0 4 Means it supports the three operations listed above plus whatever foobar/1.= 0 defines, whereas: http://acme.com/foobar/1.0 4 Means it only supports whatever foobar/1.0 defines - is this OK? Thanks, Kent From andy@netconfcentral.org Fri Apr 27 08:18:51 2012 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 3AC6121F86EC for ; Fri, 27 Apr 2012 08:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTzFyAn+xeqq for ; Fri, 27 Apr 2012 08:18:49 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6D90121F86DB for ; Fri, 27 Apr 2012 08:18:49 -0700 (PDT) Received: from cm-omr6 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q3RFIl5f010886 for ; Fri, 27 Apr 2012 11:18:47 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:40499] helo=[192.168.0.9]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3F/39-22382-6D8BA9F4; Fri, 27 Apr 2012 11:18:47 -0400 Message-ID: <4F9AB8DB.805@netconfcentral.org> Date: Fri, 27 Apr 2012 08:18:51 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kent Watsen References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> <4F95AB6C.1070408@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 27 Apr 2012 15:18:51 -0000 On 04/27/2012 07:33 AM, Kent Watsen wrote: > > Andy Bierman wrote: >> So we are back to a file transfer protocol for 1 hardwired file: >> - copy-config >> - close-session >> - get-config (no filtering) > > > This set of operations for a new "base" looks good to me, but I'd like it to be the case that the new "base" capability doesn't have to be advertized. For instance, assuming we define a "base:2.0": > > > > > urn:ietf:params:netconf:base:2.0 > > > http://acme.com/foobar/1.0 > > > 4 > > > Means it supports the three operations listed above plus whatever foobar/1.0 defines, whereas: > > > > > http://acme.com/foobar/1.0 > > > 4 > > > Means it only supports whatever foobar/1.0 defines - is this OK? > Not to me. I agree with Martin that other protocols such as FTP or HTTP can be used to transfer the entire config back and forth. But netconf-zero doesn't even do that. It is even less useful than a simple HTTP GET. Even worse than providing zero mandatory-to-implement features, the use-cases in section 2.2 "Gradually Adding NETCONF Support" are meant to codify and standardize instability, without any predictability. Random incremental protocol changes are really not the BCPs that we should be standardizing. The only issue that matters right now is the one Bob Cole raised: Is the WG specifying the minimum functionality for netconf-light or not? > > Thanks, > Kent > > > Andy From lhotka@nic.cz Fri Apr 27 08:22:39 2012 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 5439B21F876A for ; Fri, 27 Apr 2012 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-E7iEgAdH6C for ; Fri, 27 Apr 2012 08:22:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 43E6E21F876E for ; Fri, 27 Apr 2012 08:22:38 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 5EB0A13F9D4; Fri, 27 Apr 2012 17:22:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335540157; bh=bnQmT1DkNGr8wLSInICHOZ3UMecKuOw5WAcYEQieppw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ty8D1FmV2rl5S1GucQZcZyhvQKrBEdmHq80tQB+kbVONPkketIc5pdnelHsl0t6/1 pZoscrWBdphDS4uI4GxSBKqMUaRqCjAWF3RVp+9k3CM2kr/s5v823M2H4DH4AZ7zzj 7eulqd0FbDZnAlQREIpy1DLOAOZYWVppgExZLyMk= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> Date: Fri, 27 Apr 2012 17:22:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2B94EAC7-635A-442E-894B-42D58620F4D2@nic.cz> References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> <4F95AB6C.1070408@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> To: Kent Watsen X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netconf@ietf.org" , "Jonathan.Hansford@generaldynamics.uk.com" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 27 Apr 2012 15:22:39 -0000 On Apr 27, 2012, at 4:33 PM, Kent Watsen wrote: >=20 > Andy Bierman wrote: >> So we are back to a file transfer protocol for 1 hardwired file: >> - copy-config >> - close-session >> - get-config (no filtering) >=20 >=20 > This set of operations for a new "base" looks good to me, but I'd like = it to be the case that the new "base" capability doesn't have to be = advertized. For instance, assuming we define a "base:2.0": >=20 > > > > urn:ietf:params:netconf:base:2.0 > > > http://acme.com/foobar/1.0 > > > 4 > >=20 > Means it supports the three operations listed above plus whatever = foobar/1.0 defines, whereas: >=20 > > > > http://acme.com/foobar/1.0 > > > 4 > >=20 > Means it only supports whatever foobar/1.0 defines - is this OK? So it means really netconf-zero where essentially only remains = and everything else is optional. This looks good to me but I would = change the namespace URI for to = urn:ietf:params:xml:ns:netconf:base:2.0 and use something else for the capability defining the three "base" = operations (this could actually be a YANG capability). Lada >=20 >=20 > Thanks, > Kent >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Fri Apr 27 09:07:38 2012 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 D73AA21F869D for ; Fri, 27 Apr 2012 09:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMnR2F-xOtHw for ; Fri, 27 Apr 2012 09:07:38 -0700 (PDT) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id 079A321F8688 for ; Fri, 27 Apr 2012 09:07:37 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q3RG7bQl001473 for ; Fri, 27 Apr 2012 12:07:37 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:40573] helo=[192.168.0.9]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F2/EA-22382-844CA9F4; Fri, 27 Apr 2012 12:07:37 -0400 Message-ID: <4F9AC44D.7060203@netconfcentral.org> Date: Fri, 27 Apr 2012 09:07:41 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> <4F95AB6C.1070408@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> <2B94EAC7-635A-442E-894B-42D58620F4D2@nic.cz> In-Reply-To: <2B94EAC7-635A-442E-894B-42D58620F4D2@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 27 Apr 2012 16:07:39 -0000 On 04/27/2012 08:22 AM, Ladislav Lhotka wrote: > > On Apr 27, 2012, at 4:33 PM, Kent Watsen wrote: > >> >> Andy Bierman wrote: >>> So we are back to a file transfer protocol for 1 hardwired file: >>> - copy-config >>> - close-session >>> - get-config (no filtering) >> >> >> This set of operations for a new "base" looks good to me, but I'd like it to be the case that the new "base" capability doesn't have to be advertized. For instance, assuming we define a "base:2.0": >> >> >> >> >> urn:ietf:params:netconf:base:2.0 >> >> >> http://acme.com/foobar/1.0 >> >> >> 4 >> >> >> Means it supports the three operations listed above plus whatever foobar/1.0 defines, whereas: >> >> >> >> >> http://acme.com/foobar/1.0 >> >> >> 4 >> >> >> Means it only supports whatever foobar/1.0 defines - is this OK? > > So it means really netconf-zero where essentially only remains and everything else is optional. This looks good to me but I would change the namespace URI for to urn:ietf:params:xml:ns:netconf:base:2.0 > and use something else for the capability defining the three "base" operations (this could actually be a YANG capability). > This message advertises a single proprietary URI. No standard operations. No YANG modules. All the standard operations have been replaced by proprietary operations, implied by the "foobar" URI. You really think it is a good idea to standardize this? > Lada > >> Andy From lhotka@nic.cz Fri Apr 27 09:13:11 2012 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 8FE0D21F8613 for ; Fri, 27 Apr 2012 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zquKi2-j1EB4 for ; Fri, 27 Apr 2012 09:13:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D394321F85FD for ; Fri, 27 Apr 2012 09:12:14 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id BF2DB13F9D4; Fri, 27 Apr 2012 18:12:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335543133; bh=fZYfavrUcXL2RBADZXYPZJgtE8IRhNEX7Gt5uDL0q14=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=u6P4AUsPB6gfK5Vm6l2Lvmar9H3Jf4jTa831krlVjtYyHzr0+XxZRS4FaZ2d7jJ3E PCSUbj/lTHn5+8lhT36At4D2YWZqwTUSkWVuoqZ0E7G6O+4aLz3GxVpDAd6xMHABQf TajnNv1EnvSdrHRkiRWd3DG+UUUzA58VUYzNIvr4= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F9AB8DB.805@netconfcentral.org> Date: Fri, 27 Apr 2012 18:12:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> <4F95AB6C.1070408@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> <4F9AB8DB.805@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 27 Apr 2012 16:13:11 -0000 On Apr 27, 2012, at 5:18 PM, Andy Bierman wrote: > On 04/27/2012 07:33 AM, Kent Watsen wrote: >>=20 >> Andy Bierman wrote: >>> So we are back to a file transfer protocol for 1 hardwired file: >>> - copy-config >>> - close-session >>> - get-config (no filtering) >>=20 >>=20 >> This set of operations for a new "base" looks good to me, but I'd = like it to be the case that the new "base" capability doesn't have to be = advertized. For instance, assuming we define a "base:2.0": >>=20 >> >> >> >> urn:ietf:params:netconf:base:2.0 >> >> >> http://acme.com/foobar/1.0 >> >> >> 4 >> >>=20 >> Means it supports the three operations listed above plus whatever = foobar/1.0 defines, whereas: >>=20 >> >> >> >> http://acme.com/foobar/1.0 >> >> >> 4 >> >>=20 >> Means it only supports whatever foobar/1.0 defines - is this OK? >>=20 >=20 > Not to me. I agree with Martin that other protocols such as FTP or = HTTP > can be used to transfer the entire config back and forth. But = netconf-zero > doesn't even do that. It is even less useful than a simple HTTP GET. Yes, netconf-zero would be just a communication protocol with the = ability to advertise the server's capabilities and data models (both can = be defined using YANG). Of course, each device has to implement some set = of operations that enable the client to do what's necessary but these = sets may widely differ between different classes of devices. >=20 > Even worse than providing zero mandatory-to-implement features, > the use-cases in section 2.2 "Gradually Adding NETCONF Support" > are meant to codify and standardize instability, without any = predictability. > Random incremental protocol changes are really not the BCPs that we = should be standardizing. We can hardly expect any client to be able to deal with all capabilities = that can potentially be thrown on it, so each deployment will have to = make sure the capabilities on the servers' side match those that the = client(s) can handle. >=20 > The only issue that matters right now is the one Bob Cole raised: > Is the WG specifying the minimum functionality for netconf-light or = not? I think what's needed is not neconf-light but rather netconf-2.0 that = works everywhere, and this new baseline could be netconf-zero or = something more capable. Zero is an absolute minimum functionality. Lada >=20 >=20 >>=20 >> Thanks, >> Kent >>=20 >>=20 >>=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Fri Apr 27 09:23:15 2012 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 D728E21F8646 for ; Fri, 27 Apr 2012 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOtVx2AtwRLT for ; Fri, 27 Apr 2012 09:23:14 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id D853421F8647 for ; Fri, 27 Apr 2012 09:23:13 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3RGNDvH016429 for ; Fri, 27 Apr 2012 12:23:13 -0400 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:40588] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C4/A4-17184-0F7CA9F4; Fri, 27 Apr 2012 12:23:13 -0400 Message-ID: <4F9AC7F5.8090400@netconfcentral.org> Date: Fri, 27 Apr 2012 09:23:17 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> <4F95AB6C.1070408@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> <4F9AB8DB.805@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 27 Apr 2012 16:23:16 -0000 On 04/27/2012 09:12 AM, Ladislav Lhotka wrote: > > On Apr 27, 2012, at 5:18 PM, Andy Bierman wrote: > >> On 04/27/2012 07:33 AM, Kent Watsen wrote: ... > I think what's needed is not neconf-light but rather netconf-2.0 that works everywhere, and this new baseline could be netconf-zero or something more capable. Zero is an absolute minimum functionality. > It works everywhere because all it does is advertise a random or proprietary version of the protocol. It will be up to the IESG to decide if netconf-zero advances multi-vendor interoperability or not. They have to approve the charter. > Lada > Andy From lhotka@nic.cz Fri Apr 27 09:33:03 2012 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 CE3B621F86A7 for ; Fri, 27 Apr 2012 09:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubdYaXDQJ91T for ; Fri, 27 Apr 2012 09:33:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4609E21F8691 for ; Fri, 27 Apr 2012 09:33:03 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 7E09213F9D4; Fri, 27 Apr 2012 18:33:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335544382; bh=HtlaLSJazqceFQBHw9zjZuH9zllIf5WAmM3KjMU2VXU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=k0Uax0VOR1X367F/+Vz+9bw0UcFJcNqfbtE+NQ2hnw3/CArhCFbylwcRAAtN6rXaj s2SV1mSdz4QNVxt+dWzyCEn5+8JUkTrynKen6W0HZIeBbXvV0v2Ogs2PnL8pSINXUS QPZwvj9BkR4Cn6ivQBqrrlHczgNuDYkj4jbuxcTA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F9AC7F5.8090400@netconfcentral.org> Date: Fri, 27 Apr 2012 18:33:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93438BAC-B44F-411E-8F1B-6D0AF42B1192@nic.cz> References: <4F8DCE47.1060609@netconfcentral.org><84600D05C20FF943918238042D7670FD48C12980D6@EMBX01-HQ.jnpr.net><71AA57AB-A7B2-4998-9B45-8B52B2FE31CC@nic.cz> <20120418.100112.1647670444223448099.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462069C07AF@GDUKADH850.uk1.r-org.net> <4F8FDFA9.7080401@netconfcentral.org> <4F8FE1EE.3050004@bwijnen.net> <4F902C4A.8070809@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C18101F0@EMBX01-HQ.jnpr.net> <4F9586A9.80804@netconfcentral.org> <4F95AB6C.1070408@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C1CB1EED@EMBX01-HQ.jnpr.net> <4F9AB8DB.805@netconfcentral.org> <4F9AC7F5.8090400@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "Jonathan.Hansford@generaldynamics.uk.com" , "netconf@ietf.org" Subject: Re: [Netconf] Trying a consensus on the way forward withNetconf-Light 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, 27 Apr 2012 16:33:03 -0000 On Apr 27, 2012, at 6:23 PM, Andy Bierman wrote: > On 04/27/2012 09:12 AM, Ladislav Lhotka wrote: >>=20 >> On Apr 27, 2012, at 5:18 PM, Andy Bierman wrote: >>=20 >>> On 04/27/2012 07:33 AM, Kent Watsen wrote: > ... >> I think what's needed is not neconf-light but rather netconf-2.0 that = works everywhere, and this new baseline could be netconf-zero or = something more capable. Zero is an absolute minimum functionality. >>=20 >=20 >=20 > It works everywhere because all it does is advertise a random or = proprietary > version of the protocol. The version of the protocol would be always the same, and the set of = capabilities would be adjusted to the problem at hand and properly = advertised. >=20 > It will be up to the IESG to decide if netconf-zero advances = multi-vendor > interoperability or not. They have to approve the charter. If there is any tendency to undercut the baseline, via deviations or = otherwise, it's IMO even worse for interoperability. Lada >=20 >=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbadra@gmail.com Sat Apr 28 05:43:18 2012 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 7309721F8711 for ; Sat, 28 Apr 2012 05:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJG6JMQaymUm for ; Sat, 28 Apr 2012 05:43:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF6521F858F for ; Sat, 28 Apr 2012 05:43:16 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1377773vcb.31 for ; Sat, 28 Apr 2012 05:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aZ/Bjj/d+BEspfjlK3Jue4Q+3fwou94DJfrwoVLSIJY=; b=gw0lXhyL+F5oJOw8K0UpZu6xeHZIGI2Lcb6AH1qqugEW7hA6FjWs/sGGAvdrs0AQCF OGH864GSxxF5QGrfb5sts2kGGqPbYacATtR7phdx2Hz2BKm0EkYcLCWXV6x1oE47ElDq vX9F83cHPeqzlU0RwwsqsCIu+9CT71SnnisUt33b0bNNI9P6UxoZ1ooVDC7ic7xcWvLA nQm1/4KXi37vxbASEW0eRGdMcT/6hJgMuA8nXEjGX1IaoHHvXYAqNZ8Wf8AcNJoyaT4q HyeDy7JKvbUynLYblugkXNzBV57FaPCa7d+GyFu/baObVg1+wiwY7LptDgrfNty5I4ws Hsvw== MIME-Version: 1.0 Received: by 10.52.90.225 with SMTP id bz1mr3748002vdb.92.1335616996457; Sat, 28 Apr 2012 05:43:16 -0700 (PDT) Received: by 10.220.5.20 with HTTP; Sat, 28 Apr 2012 05:43:16 -0700 (PDT) Date: Sat, 28 Apr 2012 14:43:16 +0200 Message-ID: From: Mohamad Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=20cf307d010ca13ba104bebc905d Subject: [Netconf] Netconf over TLS (rfc5539bis) 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, 28 Apr 2012 12:43:18 -0000 --20cf307d010ca13ba104bebc905d Content-Type: text/plain; charset=ISO-8859-1 Dear All, I just posted a revised version of the document draft-badra-netconf-rfc5539bis http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-02.txt Your comments are highly appreciated. Best regards, Badra --20cf307d010ca13ba104bebc905d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,

I just posted a revised ver= sion of the document=A0draft-badra-netconf-rfc5539bis

http://www.ietf.org/id/draft-badra-netco= nf-rfc5539bis-02.txt

Your = comments are highly appreciated.

=
Best regards,
Ba= dra
--20cf307d010ca13ba104bebc905d--