From bertietf@bwijnen.net Wed Jun 6 14:39: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 B455411E80AD for ; Wed, 6 Jun 2012 14:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.739 X-Spam-Level: X-Spam-Status: No, score=-98.739 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 pge+cGxvfPhp for ; Wed, 6 Jun 2012 14:39:35 -0700 (PDT) Received: from relay57.tele2.vuurwerk.nl (relay57.tele2.vuurwerk.nl [62.250.3.57]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5D11E8091 for ; Wed, 6 Jun 2012 14:39:35 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1ScNwz-0005xH-Vq for netconf@ietf.org; Wed, 06 Jun 2012 23:39:34 +0200 Message-ID: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 6 Jun 2012 23:39:19 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Wed, 06 Jun 2012 21:39:35 -0000 Dear WG participants, it seem very difficult to converge on the topic of NetConf Light. We have evaluated the mailing lists discussions and have had conversations with several key participants. We also discussed this with our AD. From all that, we believe that an acceptable approach will be that we try to get approval (i.e. a chartered work item) for: Develop standards track NETCONF 2.0 with a new modular base version, which has a reduced set of mandatory features. The present functionality can be used as optional capabilities or YANG features. The "reduced set of mandatory features" is of course to be developed by the WG once we are chartered for this work. Please express your support or objections w.r.t. to this proposal. Pls do so asap, but in any event, no later than June 20th 2012 (any timezone) Bert and Mehmet WG chairs for NETCONF From j.schoenwaelder@jacobs-university.de Wed Jun 6 14:50:29 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 800C221F8620 for ; Wed, 6 Jun 2012 14:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[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 y7LN4SEPuruk for ; Wed, 6 Jun 2012 14:50:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C0C5B21F861F for ; Wed, 6 Jun 2012 14:50:28 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DB0220C07; Wed, 6 Jun 2012 23:50:27 +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 BKD3ZWENW6dN; Wed, 6 Jun 2012 23:50:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D18120BFC; Wed, 6 Jun 2012 23:50:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B5511FB80F0; Wed, 6 Jun 2012 23:50:25 +0200 (CEST) Date: Wed, 6 Jun 2012 23:50:25 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20120606215025.GA50525@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensus on the way forwardwithNetconf-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, 06 Jun 2012 21:50:29 -0000 On Wed, Jun 06, 2012 at 11:39:19PM +0200, Bert Wijnen (IETF) wrote: > Dear WG participants, > > it seem very difficult to converge on the topic of NetConf > Light. We have evaluated the mailing lists discussions and > have had conversations with several key participants. We > also discussed this with our AD. From all that, we believe > that an acceptable approach will be that we try to get > approval (i.e. a chartered work item) for: > > Develop standards track NETCONF 2.0 with a new > modular base version, which has a reduced set of > mandatory features. > The present functionality can be used as optional > capabilities or YANG features. > > The "reduced set of mandatory features" is of course to be > developed by the WG once we are chartered for this work. Is NC 2.0 limited to this or can NC 2.0 also address other issues such as how we deal with operational state data? /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 Wed Jun 6 14:51: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 ACDA711E80D7 for ; Wed, 6 Jun 2012 14:51:02 -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 xKS3Z0BIlLfp for ; Wed, 6 Jun 2012 14:51:01 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E211E80AD for ; Wed, 6 Jun 2012 14:51:00 -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 q56LoxT1017114 for ; Wed, 6 Jun 2012 17:50:59 -0400 Authentication-Results: cm-omr11 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:56421] helo=[192.168.0.168]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id 0C/18-11548-2C0DFCF4; Wed, 06 Jun 2012 17:50:59 -0400 Message-ID: <4FCFD0C1.9090706@netconfcentral.org> Date: Wed, 06 Jun 2012 14:50:57 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> In-Reply-To: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Wed, 06 Jun 2012 21:51:03 -0000 On 06/06/2012 02:39 PM, Bert Wijnen (IETF) wrote: > Dear WG participants, > > it seem very difficult to converge on the topic of NetConf > Light. We have evaluated the mailing lists discussions and > have had conversations with several key participants. We > also discussed this with our AD. From all that, we believe > that an acceptable approach will be that we try to get > approval (i.e. a chartered work item) for: > > Develop standards track NETCONF 2.0 with a new > modular base version, which has a reduced set of > mandatory features. > The present functionality can be used as optional > capabilities or YANG features. > > The "reduced set of mandatory features" is of course to be > developed by the WG once we are chartered for this work. > I don't want to spend WG time to figure out how to make the standard do less than it does now. Jumping from 1.1 to 2.0 implies some new features. Increased modularity is just 1 of the features I would expect to be on the table. I hope we would not make the same mistake as SMIng and EOS many years ago and isolate protocol and data modeling language updates unless both WGs decide they cannot rely on the other WG to do X, so that's why we can't do Y. If a real NETCONF 2.0 with new features needs new YANG functionality, then that should be already in the charter. Andy > Please express your support or objections w.r.t. to this > proposal. Pls do so asap, but in any event, no later than > June 20th 2012 (any timezone) > > Bert and Mehmet > WG chairs for NETCONF > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bertietf@bwijnen.net Thu Jun 7 00:22:56 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 54D4911E80B4 for ; Thu, 7 Jun 2012 00:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 C6fMBR5bXh7s for ; Thu, 7 Jun 2012 00:22:55 -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 8708D11E8085 for ; Thu, 7 Jun 2012 00:22:53 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ScX3T-0008RX-RU for netconf@ietf.org; Thu, 07 Jun 2012 09:22:52 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest151.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1ScX3T-0001IR-NT for netconf@ietf.org; Thu, 07 Jun 2012 09:22:51 +0200 Message-ID: <4FD056CB.20806@bwijnen.net> Date: Thu, 07 Jun 2012 09:22:51 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Netconf References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120606215025.GA50525@elstar.local> In-Reply-To: <20120606215025.GA50525@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120607 clean 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: 86ab03e524994f79ca2c75a176445dd4a134f6195a4a916ec877e3390d4d19a6 Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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, 07 Jun 2012 07:22:56 -0000 Inline On 6/6/12 11:50 PM, Juergen Schoenwaelder wrote: > On Wed, Jun 06, 2012 at 11:39:19PM +0200, Bert Wijnen (IETF) wrote: >> Dear WG participants, >> >> it seem very difficult to converge on the topic of NetConf >> Light. We have evaluated the mailing lists discussions and >> have had conversations with several key participants. We >> also discussed this with our AD. From all that, we believe >> that an acceptable approach will be that we try to get >> approval (i.e. a chartered work item) for: >> >> Develop standards track NETCONF 2.0 with a new >> modular base version, which has a reduced set of >> mandatory features. >> The present functionality can be used as optional >> capabilities or YANG features. >> >> The "reduced set of mandatory features" is of course to be >> developed by the WG once we are chartered for this work. > > Is NC 2.0 limited to this or can NC 2.0 also address other issues such > as how we deal with operational state data? > Sofar, the "netconf-lite" type work (i.e. netconf for constrained devices) had been agreed by the WG as something that we want to look at and address. I had not heard that we have agreed on other topics. But if we have agreement on what things we want tio do additionally, then fine. What I don't think we want to do is to define a work item that is open-ended in terms of what can be added over the course of some years. Bert (personal opinion) > /js > From mbj@tail-f.com Thu Jun 7 00:26: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 79A7A21F85FF for ; Thu, 7 Jun 2012 00:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZXg8l-WcqD6 for ; Thu, 7 Jun 2012 00:26:44 -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 84E0321F8609 for ; Thu, 7 Jun 2012 00:26:44 -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 703AF1200B84; Thu, 7 Jun 2012 09:26:42 +0200 (CEST) Date: Thu, 07 Jun 2012 09:26:42 +0200 (CEST) Message-Id: <20120607.092642.1739865688728946112.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> X-Mailer: Mew version 6.4 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] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 07:26:45 -0000 "Bert Wijnen \(IETF\)" wrote: > Dear WG participants, > > it seem very difficult to converge on the topic of NetConf > Light. We have evaluated the mailing lists discussions and > have had conversations with several key participants. We > also discussed this with our AD. From all that, we believe > that an acceptable approach will be that we try to get > approval (i.e. a chartered work item) for: > > Develop standards track NETCONF 2.0 with a new > modular base version, which has a reduced set of > mandatory features. > The present functionality can be used as optional > capabilities or YANG features. > > The "reduced set of mandatory features" is of course to be > developed by the WG once we are chartered for this work. With the new coma initiative, isn't it a bit premature to do develop this now? Shouldn't we wait for some conclusions from coma first? /martin From j.schoenwaelder@jacobs-university.de Thu Jun 7 00:28: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 7864621F85F1 for ; Thu, 7 Jun 2012 00:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[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 myfpnwvZxu2M for ; Thu, 7 Jun 2012 00:28:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A32A721F8541 for ; Thu, 7 Jun 2012 00:28:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 961CB20BCD; Thu, 7 Jun 2012 09:28:09 +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 YFPVG6VG6oNw; Thu, 7 Jun 2012 09:28:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A41520AFE; Thu, 7 Jun 2012 09:28:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2088C1FB86C1; Thu, 7 Jun 2012 09:28:09 +0200 (CEST) Date: Thu, 7 Jun 2012 09:28:09 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20120607072809.GB51734@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120606215025.GA50525@elstar.local> <4FD056CB.20806@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD056CB.20806@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensus on the way forwardwithNetconf-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, 07 Jun 2012 07:28:11 -0000 On Thu, Jun 07, 2012 at 09:22:51AM +0200, Bert Wijnen (IETF) wrote: > Inline > > On 6/6/12 11:50 PM, Juergen Schoenwaelder wrote: > >On Wed, Jun 06, 2012 at 11:39:19PM +0200, Bert Wijnen (IETF) wrote: > >>Dear WG participants, > >> > >>it seem very difficult to converge on the topic of NetConf > >>Light. We have evaluated the mailing lists discussions and > >>have had conversations with several key participants. We > >>also discussed this with our AD. From all that, we believe > >>that an acceptable approach will be that we try to get > >>approval (i.e. a chartered work item) for: > >> > >> Develop standards track NETCONF 2.0 with a new > >> modular base version, which has a reduced set of > >> mandatory features. > >> The present functionality can be used as optional > >> capabilities or YANG features. > >> > >>The "reduced set of mandatory features" is of course to be > >>developed by the WG once we are chartered for this work. > > > >Is NC 2.0 limited to this or can NC 2.0 also address other issues such > >as how we deal with operational state data? > > > > Sofar, the "netconf-lite" type work (i.e. netconf for constrained devices) > had been agreed by the WG as something that we want to look at and address. > > I had not heard that we have agreed on other topics. > But if we have agreement on what things we want tio do additionally, then > fine. > > What I don't think we want to do is to define a work item that is > open-ended in terms of what can be added over the course of some years. Sure. But if we start a project such as NC 2.0, we may want to think a bit more about what to include/exclude. /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 Jun 7 00:56: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 9AEA021F869C for ; Thu, 7 Jun 2012 00:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 YBR9KxKA-XOy for ; Thu, 7 Jun 2012 00:56:14 -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 270DF21F8669 for ; Thu, 7 Jun 2012 00:56:14 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ScXZi-0000sh-L5; Thu, 07 Jun 2012 09:56:13 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest151.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1ScXZi-00040c-E9; Thu, 07 Jun 2012 09:56:10 +0200 Message-ID: <4FD05E9A.5090200@bwijnen.net> Date: Thu, 07 Jun 2012 09:56:10 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120607.092642.1739865688728946112.mbj@tail-f.com> In-Reply-To: <20120607.092642.1739865688728946112.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120607 clean 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: 86ab03e524994f79ca2c75a176445dd4f3b43232a8913d619e5bc5dabf7083ae Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 07:56:14 -0000 On 6/7/12 9:26 AM, Martin Bjorklund wrote: > "Bert Wijnen \(IETF\)" wrote: ... snip.. >> The "reduced set of mandatory features" is of course to be >> developed by the WG once we are chartered for this work. > > With the new coma initiative, isn't it a bit premature to do develop > this now? Shouldn't we wait for some conclusions from coma first? > Sure we can wait. We can ALWAYS WAIT. The WG decides. > > /martin > From dromasca@avaya.com Thu Jun 7 03:19: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 B123321F879F for ; Thu, 7 Jun 2012 03:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 rl0XhDg2IK4z for ; Thu, 7 Jun 2012 03:19:30 -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 E41FD21F878B for ; Thu, 7 Jun 2012 03:19:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFx/0E/GmAcF/2dsb2JhbABFtB2BB4IYAQEBAQMBAQEPHgo0FwQCAQgNBAQBAQsGDAcEAQYBJh8JCAEBBAESCBqHaQubd5x+BIsdhShgA5sSigWCYg X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="309733268" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jun 2012 06:18:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jun 2012 06:17:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2012 12:19:04 +0200 Message-ID: In-Reply-To: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensuson the way forwardwithNetconf-Light] Thread-Index: Ac1ELOBmdX6cicypRB+w4aNH7Sg7HgAadxbg References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Netconf" Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensuson 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, 07 Jun 2012 10:19:30 -0000 By 'present functionality' we mean Netconf 1.0 and 1.1? =20 Dan > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Bert Wijnen (IETF) > Sent: Thursday, June 07, 2012 12:39 AM > To: Netconf > Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a > consensuson the way forwardwithNetconf-Light] >=20 > Dear WG participants, >=20 > it seem very difficult to converge on the topic of NetConf > Light. We have evaluated the mailing lists discussions and > have had conversations with several key participants. We > also discussed this with our AD. From all that, we believe > that an acceptable approach will be that we try to get > approval (i.e. a chartered work item) for: >=20 > Develop standards track NETCONF 2.0 with a new > modular base version, which has a reduced set of > mandatory features. > The present functionality can be used as optional > capabilities or YANG features. >=20 > The "reduced set of mandatory features" is of course to be > developed by the WG once we are chartered for this work. >=20 > Please express your support or objections w.r.t. to this > proposal. Pls do so asap, but in any event, no later than > June 20th 2012 (any timezone) >=20 > Bert and Mehmet > WG chairs for NETCONF >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From dromasca@avaya.com Thu Jun 7 03:23:10 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 A5ADE21F86DA for ; Thu, 7 Jun 2012 03:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.53 X-Spam-Level: X-Spam-Status: No, score=-103.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 N92dLYRJ1L4K for ; Thu, 7 Jun 2012 03:23:10 -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 E483F21F86D9 for ; Thu, 7 Jun 2012 03:23:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFx/0E+HCzI1/2dsb2JhbABFtB2BB4IYAQEBAQMSHgo0CwwEAgEIDQEDBAEBAQoGDAsBBgFFCQgBAQQBEggah2mcAp0Cix2FKGADmxKKBYJi X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="309733817" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jun 2012 06:21:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Jun 2012 06:04:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2012 12:22:05 +0200 Message-ID: In-Reply-To: <20120607.092642.1739865688728946112.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? Thread-Index: Ac1EfukGm+nO+YOlS5+QWKkf85pYxQAGBiLA References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120607.092642.1739865688728946112.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 10:23:10 -0000 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Martin Bjorklund > Sent: Thursday, June 07, 2012 10:27 AM > To: bertietf@bwijnen.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? >=20 > "Bert Wijnen \(IETF\)" wrote: > > Dear WG participants, > > > > it seem very difficult to converge on the topic of NetConf > > Light. We have evaluated the mailing lists discussions and > > have had conversations with several key participants. We > > also discussed this with our AD. From all that, we believe > > that an acceptable approach will be that we try to get > > approval (i.e. a chartered work item) for: > > > > Develop standards track NETCONF 2.0 with a new > > modular base version, which has a reduced set of > > mandatory features. > > The present functionality can be used as optional > > capabilities or YANG features. > > > > The "reduced set of mandatory features" is of course to be > > developed by the WG once we are chartered for this work. >=20 > With the new coma initiative, isn't it a bit premature to do develop > this now? Shouldn't we wait for some conclusions from coma first? >=20 My understanding is that coma (if it will succeed) will write a set of requirements for management of constrained devices and networks. These may be relevant or relevant in part to Netconf, but the outcome is not meant to be tailored on Netconf (or Netconf-light or such).=20 Which does not mean that contributions to coma from the Netconf folks are not welcome and needed. Actually the time for these is right now.=20 Dan =20 From mbj@tail-f.com Thu Jun 7 03:27: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 E99B921F86F8 for ; Thu, 7 Jun 2012 03:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDqhlv+tHn50 for ; Thu, 7 Jun 2012 03:27:53 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5E94B21F86F2 for ; Thu, 7 Jun 2012 03:27:53 -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 832D81200AE5; Thu, 7 Jun 2012 12:27:52 +0200 (CEST) Date: Thu, 07 Jun 2012 12:27:52 +0200 (CEST) Message-Id: <20120607.122752.1245962305696149968.mbj@tail-f.com> To: dromasca@avaya.com From: Martin Bjorklund In-Reply-To: References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120607.092642.1739865688728946112.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 10:27:54 -0000 "Romascanu, Dan (Dan)" wrote: > > > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Martin Bjorklund > > Sent: Thursday, June 07, 2012 10:27 AM > > To: bertietf@bwijnen.net > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? > > > > "Bert Wijnen \(IETF\)" wrote: > > > Dear WG participants, > > > > > > it seem very difficult to converge on the topic of NetConf > > > Light. We have evaluated the mailing lists discussions and > > > have had conversations with several key participants. We > > > also discussed this with our AD. From all that, we believe > > > that an acceptable approach will be that we try to get > > > approval (i.e. a chartered work item) for: > > > > > > Develop standards track NETCONF 2.0 with a new > > > modular base version, which has a reduced set of > > > mandatory features. > > > The present functionality can be used as optional > > > capabilities or YANG features. > > > > > > The "reduced set of mandatory features" is of course to be > > > developed by the WG once we are chartered for this work. > > > > With the new coma initiative, isn't it a bit premature to do develop > > this now? Shouldn't we wait for some conclusions from coma first? > > > > My understanding is that coma (if it will succeed) will write a set of > requirements for management of constrained devices and networks. These > may be relevant or relevant in part to Netconf, but the outcome is not > meant to be tailored on Netconf (or Netconf-light or such). Right. For example, if the coma works results in a new protocol for configuration of constrained devices, should we still be doing this work with NETCONF? Or, if coma thinks they can use NETCONF, but only if we do X, and we just published 2.0 without X, that would be unfortunate. So I guess I am saying we should sync with coma. /martin From dromasca@avaya.com Thu Jun 7 03:50: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 5B4E721F85F8 for ; Thu, 7 Jun 2012 03:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.031 X-Spam-Level: X-Spam-Status: No, score=-103.031 tagged_above=-999 required=5 tests=[AWL=-0.432, 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 fdy59Jdx7nTh for ; Thu, 7 Jun 2012 03:50:57 -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 D363E21F85F7 for ; Thu, 7 Jun 2012 03:50:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD+H0E/GmAcF/2dsb2JhbABFtB2BB4IYAQEBAQMSHgo0CwwEAgEIDQEDBAEBAQoGDAsBBgFFCQgBAQQTCBqHaZwQnQOLHYUoYAObEooFgmI X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="12713719" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 Jun 2012 06:48:57 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jun 2012 06:40:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2012 12:41:42 +0200 Message-ID: In-Reply-To: <20120607.122752.1245962305696149968.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? Thread-Index: Ac1EmV2QNbqtajp2Qk2tVpRvI41WYQAAFxCQ References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop><20120607.092642.1739865688728946112.mbj@tail-f.com> <20120607.122752.1245962305696149968.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 10:50:58 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, June 07, 2012 1:28 PM > To: Romascanu, Dan (Dan) > Cc: bertietf@bwijnen.net; netconf@ietf.org > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? >=20 > "Romascanu, Dan (Dan)" wrote: > > > > > > > > > > > -----Original Message----- > > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > > Behalf Of Martin Bjorklund > > > Sent: Thursday, June 07, 2012 10:27 AM > > > To: bertietf@bwijnen.net > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? > > > > > > "Bert Wijnen \(IETF\)" wrote: > > > > Dear WG participants, > > > > > > > > it seem very difficult to converge on the topic of NetConf > > > > Light. We have evaluated the mailing lists discussions and > > > > have had conversations with several key participants. We > > > > also discussed this with our AD. From all that, we believe > > > > that an acceptable approach will be that we try to get > > > > approval (i.e. a chartered work item) for: > > > > > > > > Develop standards track NETCONF 2.0 with a new > > > > modular base version, which has a reduced set of > > > > mandatory features. > > > > The present functionality can be used as optional > > > > capabilities or YANG features. > > > > > > > > The "reduced set of mandatory features" is of course to be > > > > developed by the WG once we are chartered for this work. > > > > > > With the new coma initiative, isn't it a bit premature to do > develop > > > this now? Shouldn't we wait for some conclusions from coma first? > > > > > > > My understanding is that coma (if it will succeed) will write a set > of > > requirements for management of constrained devices and networks. > These > > may be relevant or relevant in part to Netconf, but the outcome is > not > > meant to be tailored on Netconf (or Netconf-light or such). >=20 > Right. For example, if the coma works results in a new protocol for > configuration of constrained devices, should we still be doing this > work with NETCONF? Or, if coma thinks they can use NETCONF, but only > if we do X, and we just published 2.0 without X, that would be > unfortunate. So I guess I am saying we should sync with coma. >=20 >=20 > /martin I like 'sync' better than 'wait for' :-) For example it would be useful if you can provide (as input to coma) use cases of applications and configurations that could be addressed by using NETCONF. They may not solve all coma needs but would help understanding the gaps.=20 Dan From bertietf@bwijnen.net Thu Jun 7 04:23: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 7114D21F87BA for ; Thu, 7 Jun 2012 04:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 bHYMNm69yODA for ; Thu, 7 Jun 2012 04:23:19 -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 D3C6B21F864D for ; Thu, 7 Jun 2012 04:23:18 -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 1Scao8-0004gF-C4; Thu, 07 Jun 2012 13:23:17 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest151.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Scao8-0004OA-2y; Thu, 07 Jun 2012 13:23:16 +0200 Message-ID: <4FD08F23.2090200@bwijnen.net> Date: Thu, 07 Jun 2012 13:23:15 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120607 clean 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: 86ab03e524994f79ca2c75a176445dd422fa0d97925d8da52545857a0617bc15 Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 11:23:19 -0000 Yes, I would think that those are the current set of fucntions to choose from. Bert On 6/7/12 12:19 PM, Romascanu, Dan (Dan) wrote: > By 'present functionality' we mean Netconf 1.0 and 1.1? > > Dan From bertietf@bwijnen.net Thu Jun 7 04:24:21 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 F07A621F87BD for ; Thu, 7 Jun 2012 04:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 veyIo2WFgtxj for ; Thu, 7 Jun 2012 04:24:21 -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 649D321F8783 for ; Thu, 7 Jun 2012 04:24:21 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Scap8-0007Ou-9j; Thu, 07 Jun 2012 13:24:19 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest151.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Scap8-0004Qt-09; Thu, 07 Jun 2012 13:24:18 +0200 Message-ID: <4FD08F61.3060206@bwijnen.net> Date: Thu, 07 Jun 2012 13:24:17 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop><20120607.092642.1739865688728946112.mbj@tail-f.com> <20120607.122752.1245962305696149968.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120607 clean 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: 86ab03e524994f79ca2c75a176445dd49e97a885e9a4748e32219a78cd141cc0 Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 11:24:22 -0000 I have nor problem to add a sentence to our possibly charter work item that says that we need to interface and sync with coma. Bert On 6/7/12 12:41 PM, Romascanu, Dan (Dan) wrote: >> > Right. For example, if the coma works results in a new protocol for >> > configuration of constrained devices, should we still be doing this >> > work with NETCONF? Or, if coma thinks they can use NETCONF, but only >> > if we do X, and we just published 2.0 without X, that would be >> > unfortunate. So I guess I am saying we should sync with coma. >> > >> > >> > /martin > I like 'sync' better than 'wait for':-) For example it would be useful > if you can provide (as input to coma) use cases of applications and > configurations that could be addressed by using NETCONF. They may not > solve all coma needs but would help understanding the gaps. > > Dan > > From lhotka@nic.cz Thu Jun 7 06:59: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 4FB1621F88C9 for ; Thu, 7 Jun 2012 06:59:39 -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=[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 ugtquHh7m1Jd for ; Thu, 7 Jun 2012 06:59: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 63FD221F8882 for ; Thu, 7 Jun 2012 06:59:38 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 3BBD7141644; Thu, 7 Jun 2012 15:59:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339077577; bh=lpXLO/eI+H/6HHZxNXfDgsrVuedvMXPIGfTaa5r7YmU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZJ1QJHYd0dhJVrWYaIYAszllh7isMXLwSWc25L3Y+aqh2rM5dJifbDXNH3/EKieSU PdJqE9cxHj2UB+kHZNuA/+qIQnw/CIItqWPb/MZyQROOeU2TimEemQwuLyBbIyGakR P6QMPWFqLeKdhyTcQKFn0pFBqic8GxRoK/OUEMzQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4FCFD0C1.9090706@netconfcentral.org> Date: Thu, 7 Jun 2012 15:59:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84BF3B3B-2AA1-4D57-8FDD-F44FB08B8007@nic.cz> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <4FCFD0C1.9090706@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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, 07 Jun 2012 13:59:39 -0000 On Jun 6, 2012, at 11:50 PM, Andy Bierman wrote: > On 06/06/2012 02:39 PM, Bert Wijnen (IETF) wrote: >> Dear WG participants, >>=20 >> it seem very difficult to converge on the topic of NetConf >> Light. We have evaluated the mailing lists discussions and >> have had conversations with several key participants. We >> also discussed this with our AD. =46rom all that, we believe >> that an acceptable approach will be that we try to get >> approval (i.e. a chartered work item) for: >>=20 >> Develop standards track NETCONF 2.0 with a new >> modular base version, which has a reduced set of >> mandatory features. >> The present functionality can be used as optional >> capabilities or YANG features. >>=20 >> The "reduced set of mandatory features" is of course to be >> developed by the WG once we are chartered for this work. >>=20 >=20 > I don't want to spend WG time to figure out how to make > the standard do less than it does now. Jumping from 1.1 to 2.0 = implies > some new features. Increased modularity is just 1 of the features > I would expect to be on the table. Sure, but the new features can be developed as optional, separately from = the core spec. I think that making the *current* functionality available = in a modular way would be a good start that shouldn't require much = discussion (I hope). The benefit of doing so is that it would still be = possible to use the old stuff while, at the same time, somebody may = develop new approaches as alternatives to the old stuff. =20 >=20 > I hope we would not make the same mistake as SMIng and EOS > many years ago and isolate protocol and data modeling language > updates unless both WGs decide they cannot rely on the other WG to do = X, > so that's why we can't do Y. If a real NETCONF 2.0 with new features > needs new YANG functionality, then that should be already in the = charter. Yes, YANG should be more tightly integrated into NETCONF. IMO there are = two areas that should be addressed and improved in NETCONF 2.0: 1. signalling of conformance and revisions 2. configuration versus operational state data versus statistics. Lada >=20 >=20 > Andy >=20 >=20 >=20 >=20 >> Please express your support or objections w.r.t. to this >> proposal. Pls do so asap, but in any event, no later than >> June 20th 2012 (any timezone) >>=20 >> Bert and Mehmet >> WG chairs for NETCONF >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=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 andy@netconfcentral.org Thu Jun 7 07:06: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 AB08321F87FF for ; Thu, 7 Jun 2012 07:06: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=[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 4626hSWAGhai for ; Thu, 7 Jun 2012 07:06:15 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id A0E0121F87FD for ; Thu, 7 Jun 2012 07:06:06 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q57E65TZ022981 for ; Thu, 7 Jun 2012 10:06:05 -0400 Authentication-Results: cm-omr6 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:46180] helo=[192.168.0.168]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id 6D/49-06495-C45B0DF4; Thu, 07 Jun 2012 10:06:05 -0400 Message-ID: <4FD0B54B.8080005@netconfcentral.org> Date: Thu, 07 Jun 2012 07:06:03 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop><20120607.092642.1739865688728946112.mbj@tail-f.com> <20120607.122752.1245962305696149968.mbj@tail-f.com> <4FD08F61.3060206@bwijnen.net> In-Reply-To: <4FD08F61.3060206@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 14:06:16 -0000 On 06/07/2012 04:24 AM, Bert Wijnen (IETF) wrote: > I have nor problem to add a sentence to our possibly > charter work item that says that we need to interface > and sync with coma. Why would we presume to know more about their charter than they do? So far, nobody has produced a YANG file which they claim they want to run on their constrained device. Is it 10 lists? Is is 50 leafs? Is it 2 leafs? Is session-based to retrieve or write the entire config at once really the correct approach, whether it's 2 or 50? > > Bert Andy > > On 6/7/12 12:41 PM, Romascanu, Dan (Dan) wrote: >>> > Right. For example, if the coma works results in a new protocol for >>> > configuration of constrained devices, should we still be doing this >>> > work with NETCONF? Or, if coma thinks they can use NETCONF, but only >>> > if we do X, and we just published 2.0 without X, that would be >>> > unfortunate. So I guess I am saying we should sync with coma. >>> > >>> > >>> > /martin >> I like 'sync' better than 'wait for':-) For example it would be useful >> if you can provide (as input to coma) use cases of applications and >> configurations that could be addressed by using NETCONF. They may not >> solve all coma needs but would help understanding the gaps. >> >> Dan >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From andy@netconfcentral.org Thu Jun 7 08:00: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 3274021F85FC for ; Thu, 7 Jun 2012 08:00:09 -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 w7MFb+RlPCrq for ; Thu, 7 Jun 2012 08:00:08 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id F38F221F85DB for ; Thu, 7 Jun 2012 08:00:04 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q57F00mH015751 for ; Thu, 7 Jun 2012 11:00:01 -0400 Authentication-Results: cm-omr10 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:47206] helo=[192.168.0.168]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id 31/50-15363-0F1C0DF4; Thu, 07 Jun 2012 11:00:00 -0400 Message-ID: <4FD0C1EE.9050202@netconfcentral.org> Date: Thu, 07 Jun 2012 07:59:58 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <4FCFD0C1.9090706@netconfcentral.org> <84BF3B3B-2AA1-4D57-8FDD-F44FB08B8007@nic.cz> In-Reply-To: <84BF3B3B-2AA1-4D57-8FDD-F44FB08B8007@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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, 07 Jun 2012 15:00:12 -0000 ... >> I don't want to spend WG time to figure out how to make >> the standard do less than it does now. Jumping from 1.1 to 2.0 implies >> some new features. Increased modularity is just 1 of the features >> I would expect to be on the table. > Sure, but the new features can be developed as optional, separately from the core spec. I think that making the *current* functionality available in a modular way would be a good start that shouldn't require much discussion (I hope). The benefit of doing so is that it would still be possible to use the old stuff while, at the same time, somebody may develop new approaches as alternatives to the old stuff. > Agreed. That's why I called the feature "increased modularity". I would also add to the feature list (in no particular order): - conformance model - transaction model - operational state - HTTP/RESTful API - optimized bulk retrieval - YANG XPath updates >> I hope we would not make the same mistake as SMIng and EOS >> many years ago and isolate protocol and data modeling language >> updates unless both WGs decide they cannot rely on the other WG to do X, >> so that's why we can't do Y. If a real NETCONF 2.0 with new features >> needs new YANG functionality, then that should be already in the charter. > Yes, YANG should be more tightly integrated into NETCONF. IMO there are two areas that should be addressed and improved in NETCONF 2.0: > > 1. signalling of conformance and revisions > 2. configuration versus operational state data versus statistics. Yes -- my wish list makes no attempt to partition items between the 2 WGs at this time. There are a summary from Juergen about the ad-hoc meeting feature list at IETF 83. That's the list we should start with I guess. > Lada Andy From andy@netconfcentral.org Thu Jun 7 08:23:04 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 B3DD621F867F for ; Thu, 7 Jun 2012 08:23:04 -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 fYR+u2dESyvd for ; Thu, 7 Jun 2012 08:23:04 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0199B21F861D for ; Thu, 7 Jun 2012 08:23:03 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q57FN3KI022755 for ; Thu, 7 Jun 2012 11:23:03 -0400 Authentication-Results: cm-omr3 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:47624] helo=[192.168.0.168]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id BE/FB-14279-657C0DF4; Thu, 07 Jun 2012 11:23:03 -0400 Message-ID: <4FD0C754.6040403@netconfcentral.org> Date: Thu, 07 Jun 2012 08:23:00 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop><20120607.092642.1739865688728946112.mbj@tail-f.com> <20120607.122752.1245962305696149968.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 07 Jun 2012 15:23:04 -0000 ... >> Right. For example, if the coma works results in a new protocol for >> configuration of constrained devices, should we still be doing this >> work with NETCONF? Or, if coma thinks they can use NETCONF, but only >> if we do X, and we just published 2.0 without X, that would be >> unfortunate. So I guess I am saying we should sync with coma. >> >> >> /martin > I like 'sync' better than 'wait for' :-) For example it would be useful > if you can provide (as input to coma) use cases of applications and > configurations that could be addressed by using NETCONF. They may not > solve all coma needs but would help understanding the gaps. IMO, NETCONF may be too heavyweight for a tiny device, even if it is stripped down to just : * Sessions and XML parsing just get in the way in this use-case. * Keeping a session open to avoid the startup overhead is just different overhead. * A generic NETCONF client has to wait to receive the server before sending the first I would think a minimal subset of YANG-API would be better suited to a tiny device: * No sessions (or session startup overhead, or need for extra round-trip) * JSON encoding smaller and easier to parse than XML * less state kept in the server Example Request to replace 2 leaf module: PUT /yang-api/datastore/fooconf HTTP/1.1 Host: example.com Content-Type: application/vnd.yang.data+json {"fooconf":{"mtu":1500, "hostname":"tiny.example.com"}} OK Reply: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2012 17:04:00 GMT Server: example-server > Dan Andy From mehmet.ersue@nsn.com Fri Jun 8 03:33: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 DD9AD21F86F5 for ; Fri, 8 Jun 2012 03:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 uxmMhzfbcVKQ for ; Fri, 8 Jun 2012 03:33:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2548121F86A2 for ; Fri, 8 Jun 2012 03:33:33 -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 q58AXQDv004960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jun 2012 12:33:26 +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 q58AXQ7M030824; Fri, 8 Jun 2012 12:33:26 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 12:33:26 +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: Fri, 8 Jun 2012 12:33:24 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB831@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? Thread-Index: Ac1EmV2QNbqtajp2Qk2tVpRvI41WYQAAFxCQACzYCUA= References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop><20120607.092642.1739865688728946112.mbj@tail-f.com><20120607.122752.1245962305696149968.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "Martin Bjorklund" X-OriginalArrivalTime: 08 Jun 2012 10:33:26.0169 (UTC) FILETIME=[231AE890:01CD4562] 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: 1669 X-purgate-ID: 151667::1339151606-00003CDD-6F6ACD65/0-0/0-0 Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 08 Jun 2012 10:33:35 -0000 > > > My understanding is that coma (if it will succeed) will write a set > > of > > > requirements for management of constrained devices and networks. > > These > > > may be relevant or relevant in part to Netconf, but the outcome is > > not > > > meant to be tailored on Netconf (or Netconf-light or such). > > > > Right. For example, if the coma works results in a new protocol for > > configuration of constrained devices, should we still be doing this > > work with NETCONF? Or, if coma thinks they can use NETCONF, but only > > if we do X, and we just published 2.0 without X, that would be > > unfortunate. So I guess I am saying we should sync with coma. > > > > > > /martin >=20 > I like 'sync' better than 'wait for' :-) For example it would be useful > if you can provide (as input to coma) use cases of applications and > configurations that could be addressed by using NETCONF. They may not > solve all coma needs but would help understanding the gaps. >=20 > Dan Both activities could run in parallel and could be synced, however we might not be interested to integrate everything coming up in Coma into a Netconf 2.0. Current proposal for Netconf 2.0 aims to address the flexibility for the implementation of capabilities by avoiding competing standards.=20 If Coma results suggest the development of a new protocol (e.g. a Netconf-Constrained) this can be for sure done by using the basics of the Netconf standard. As I understand our AD supports such a protocol addressing Coma requirements. Those who are interested in such a protocol please join Coma and contribute your requirements. Cheers,=20 Mehmet From phil@juniper.net Mon Jun 11 05:49: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 919DC21F8566 for ; Mon, 11 Jun 2012 05:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 dfOuro9mpsg6 for ; Mon, 11 Jun 2012 05:49:57 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3749A21F8473 for ; Mon, 11 Jun 2012 05:49:55 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT9XpckJWbEUsihABEXApb0zJ7M/++62X@postini.com; Mon, 11 Jun 2012 05:49:56 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Jun 2012 05:48:32 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q5BCmE164389; Mon, 11 Jun 2012 05:48:30 -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 q5BCmC02017907; Mon, 11 Jun 2012 08:48:13 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206111248.q5BCmC02017907@idle.juniper.net> To: "Bert Wijnen (IETF)" In-Reply-To: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> Date: Mon, 11 Jun 2012 08:48:12 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 12:49:57 -0000 "Bert Wijnen \(IETF\)" writes: >Please express your support or objections w.r.t. to this >proposal. Pls do so asap, but in any event, no later than >June 20th 2012 (any timezone) I object to any "2.0" efforts. We have a new set of technologies that need some development, field testing, and experience. Revisiting them for a "2.0" effort before the paint is dry on the "1.0" will be detrimental efforts to gain mindshare. Thanks, Phil From lhotka@nic.cz Mon Jun 11 06:29: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 3347D21F859A for ; Mon, 11 Jun 2012 06:29:05 -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 XgtMdeptsyvm for ; Mon, 11 Jun 2012 06:29:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A004A21F858D for ; Mon, 11 Jun 2012 06:29:04 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 1A688141281; Mon, 11 Jun 2012 15:29:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339421340; bh=Zh27AW9Aq44HBlj6W14wth4xMjzwyjIIO0qlpKf2C7s=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eI6jDzrZl9Yfh2dy61bcW67YUKbM45LCUgGlwLexnBY9a/5fSuT5afPDD3STm53TJ XU579D97LJFGTUVtXLtdChsR5YqkNRuyN3Xq6iZ1JTY89TaXDg1JwS8RfxhfGfvSSa 0isIaGJKpkZVYKWMdxdc34rBHJK2dVtosParIPks= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201206111248.q5BCmC02017907@idle.juniper.net> Date: Mon, 11 Jun 2012 15:28:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> References: <201206111248.q5BCmC02017907@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 13:29:05 -0000 On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: > "Bert Wijnen \(IETF\)" writes: >> Please express your support or objections w.r.t. to this >> proposal. Pls do so asap, but in any event, no later than >> June 20th 2012 (any timezone) >=20 > I object to any "2.0" efforts. We have a new set of technologies > that need some development, field testing, and experience. Revisiting > them for a "2.0" effort before the paint is dry on the "1.0" will > be detrimental efforts to gain mindshare. I don't know whether the paint is dry on IPv6 but RFC 6434 recently = introduced relatively significant changes in terms of what is required = from an IPv6 node. For instance, IPSec used to be a MUST, now it is a = SHOULD - simply because almost nobody bothered to implement it but still = claimed to have a standard IPv6 implementation. Apparently, NETCONF also has a few features that are too heavy-weight, = clumsy or broken. There is already a decent amount of operational = experience and I believe it is time - after about ten years - to adjust = NETCONF to the current reality, which actually also includes YANG. Lada >=20 > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From calle@tail-f.com Mon Jun 11 06:45: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 29F7F21F859A for ; Mon, 11 Jun 2012 06:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujgds5D20umb for ; Mon, 11 Jun 2012 06:45:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7E621F8599 for ; Mon, 11 Jun 2012 06:45:25 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F406F1200CF2; Mon, 11 Jun 2012 15:45:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> Date: Mon, 11 Jun 2012 15:45:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 13:45:26 -0000 On Jun 11, 2012, at 15:28 PM, Ladislav Lhotka wrote: >=20 > On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: >=20 >> "Bert Wijnen \(IETF\)" writes: >>> Please express your support or objections w.r.t. to this >>> proposal. Pls do so asap, but in any event, no later than >>> June 20th 2012 (any timezone) >>=20 >> I object to any "2.0" efforts. We have a new set of technologies >> that need some development, field testing, and experience. = Revisiting >> them for a "2.0" effort before the paint is dry on the "1.0" will >> be detrimental efforts to gain mindshare. >=20 > I don't know whether the paint is dry on IPv6 but RFC 6434 recently = introduced relatively significant changes in terms of what is required = from an IPv6 node. For instance, IPSec used to be a MUST, now it is a = SHOULD - simply because almost nobody bothered to implement it but still = claimed to have a standard IPv6 implementation. >=20 > Apparently, NETCONF also has a few features that are too heavy-weight, = clumsy or broken. There is already a decent amount of operational = experience and I believe it is time - after about ten years - to adjust = NETCONF to the current reality, which actually also includes YANG. For the record; I don't actually see any strong suggestions that there = are any features that are "too heavy-weight, clumsy or broken" in = NETCONF or YANG. At least I have never heard that type of feedback from = the implementations that we've been working with. Sure, there are issues = and challenges with implementing server-side NETCONF (and YANG) = particularly around retrofitting it on top of existing software = infrastructure, but I have no experience that there are show stopping = aspects to it that must be fixed. I agree with Phil, let's get (lots) more development, testing and = experience before we move. Only now do we see signs of network = management software that leverages the features of NETCONF (instead of = retrofitting it onto SNMP-centric architecture) and I would like to see = how that pans out before drawing any conclusions. As was mentioned in our side-meeting in Paris; even better if we could = get hold of a handful of those fabled "EMS developers" (that everyone is = referring to but noone seems to be able to produce) and see what they = think. The discussions we have had this far is based solely on strawmen. Regards, -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com From andy@yumaworks.com Mon Jun 11 07:27: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 2E51421F8473 for ; Mon, 11 Jun 2012 07:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 otlTI-oqkfp4 for ; Mon, 11 Jun 2012 07:27:24 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36BDB21F85B1 for ; Mon, 11 Jun 2012 07:27:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2980374ghb.31 for ; Mon, 11 Jun 2012 07:27:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EZFb0Rx50YE5tNOw0pmQ5H7RMggeHuBSLvuHlIZ+dn0=; b=VwDabXbukL2d69rR+JklHj+jQu+lkxvms0ulVRYugzdBoV3q4nYFCPGGN0Um+JSSKg wg4+uaN/nwcarNWPKVneTvFk/jsPPAbbj8u6mWFqhxaiEih4KQ4ea7R4mX8lmiFUmlNO WpufhwLyVqFIrS5CZNQF5A/oxWcKJ0dd6C2GAYKlLgMlBh091cAgS0O2vkECzU1aIbUo HhZVlZRJ5ClBSoupo+MjD751RG2EugVRR4XwuOOSgiOj2hY4hbeleT/sOAaDChLSsFjJ ZxNfkSv2309NHr624XyHUQNJirn/M3q6ZiB7STt8DZ32vWg2kO1UCcxEY8ZK3pwe/8QT uhNg== MIME-Version: 1.0 Received: by 10.50.46.201 with SMTP id x9mr6380097igm.34.1339424842452; Mon, 11 Jun 2012 07:27:22 -0700 (PDT) Received: by 10.50.193.232 with HTTP; Mon, 11 Jun 2012 07:27:22 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> Date: Mon, 11 Jun 2012 07:27:22 -0700 Message-ID: From: Andy Bierman To: Carl Moberg Content-Type: multipart/alternative; boundary=14dae9340cd9f00f3904c233256d X-Gm-Message-State: ALoCoQmd50ngrSf3t1ydZv/F38sEXKPosG7VNsHKcO0FXDoLqcH0wBdUOdqqTgiDfjCV5F5oqP5b Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 14:27:25 -0000 --14dae9340cd9f00f3904c233256d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 11, 2012 at 6:45 AM, Carl Moberg wrote: > > On Jun 11, 2012, at 15:28 PM, Ladislav Lhotka wrote: > > > > > On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: > > > >> "Bert Wijnen \(IETF\)" writes: > >>> Please express your support or objections w.r.t. to this > >>> proposal. Pls do so asap, but in any event, no later than > >>> June 20th 2012 (any timezone) > >> > >> I object to any "2.0" efforts. We have a new set of technologies > >> that need some development, field testing, and experience. Revisiting > >> them for a "2.0" effort before the paint is dry on the "1.0" will > >> be detrimental efforts to gain mindshare. > > > > I don't know whether the paint is dry on IPv6 but RFC 6434 recently > introduced relatively significant changes in terms of what is required from > an IPv6 node. For instance, IPSec used to be a MUST, now it is a SHOULD - > simply because almost nobody bothered to implement it but still claimed to > have a standard IPv6 implementation. > > > > Apparently, NETCONF also has a few features that are too heavy-weight, > clumsy or broken. There is already a decent amount of operational > experience and I believe it is time - after about ten years - to adjust > NETCONF to the current reality, which actually also includes YANG. > > > For the record; I don't actually see any strong suggestions that there > are any features that are "too heavy-weight, clumsy or broken" in NETCONF > or YANG. At least I have never heard that type of feedback from the > implementations that we've been working with. Sure, there are issues and > challenges with implementing server-side NETCONF (and YANG) particularly > around retrofitting it on top of existing software infrastructure, but I > have no experience that there are show stopping aspects to it that must be > fixed. > > I agree with Phil, let's get (lots) more development, testing and > experience before we move. Only now do we see signs of network management > software that leverages the features of NETCONF (instead of retrofitting it > onto SNMP-centric architecture) and I would like to see how that pans out > before drawing any conclusions. > > As was mentioned in our side-meeting in Paris; even better if we could > get hold of a handful of those fabled "EMS developers" (that everyone is > referring to but noone seems to be able to produce) and see what they > think. The discussions we have had this far is based solely on strawmen. > > The feature list identified in Paris is not a strawman. Transactions, conformance, and some other areas could be improved in NETCONF. RFC 6241 was a small incremental update to RFC 4271. IMO, a NETCONF version of (HTTP or FTP) put and get does not advance interoperability or operator utility. A version of NETCONF with nothiing mandatory to implement except a (netconf-zero) is even less useful to end users. Andy --14dae9340cd9f00f3904c233256d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 11, 2012 at 6:45 AM, Carl Mo= berg <calle@tail-f.com> wrote:

On Jun 11, 2012, at 15:28 PM, Ladislav Lhotka wrote:

>
> On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote:
>
>> "Bert Wijnen \(IETF\)" writes:
>>> Please express your support or objections w.r.t. to this
>>> proposal. Pls do so asap, but in any event, no later than
>>> June 20th 2012 (any timezone)
>>
>> I object to any "2.0" efforts. =A0We have a new set of t= echnologies
>> that need some development, field testing, and experience. =A0Revi= siting
>> them for a "2.0" effort before the paint is dry on the &= quot;1.0" will
>> be detrimental efforts to gain mindshare.
>
> I don't know whether the paint is dry on IPv6 but RFC 6434 recentl= y introduced relatively significant changes in terms of what is required fr= om an IPv6 node. For instance, IPSec used to be a MUST, now it is a SHOULD = - simply because almost nobody bothered to implement it but still claimed t= o have a standard IPv6 implementation.
>
> Apparently, NETCONF also has a few features that are too heavy-weight,= clumsy or broken. There is already a decent amount of operational experien= ce and I believe it is time - after about ten years - to adjust NETCONF to = the current reality, which actually also includes YANG.


=A0For the record; I don't actually see any strong suggestions that the= re are any features that are "too heavy-weight, clumsy or broken"= in NETCONF or YANG. At least I have never heard that type of feedback from= the implementations that we've been working with. Sure, there are issu= es and challenges with implementing server-side NETCONF (and YANG) particul= arly around retrofitting it on top of existing software infrastructure, but= I have no experience that there are show stopping aspects to it that must = be fixed.

=A0I agree with Phil, let's get (lots) more development, testing and ex= perience before we move. Only now do we see signs of network management sof= tware that leverages the features of NETCONF (instead of retrofitting it on= to SNMP-centric architecture) and I would like to see how that pans out bef= ore drawing any conclusions.

=A0As was mentioned in our side-meeting in Paris; even better if we could g= et hold of a handful of those fabled "EMS developers" (that every= one is referring to but noone seems to be able to produce) and see what the= y think. The discussions we have had this far is based solely on strawmen.<= br>


The feature list identi= fied in Paris is not a strawman.
Transactions, conformance, and s= ome other areas could be improved
in NETCONF. =A0RFC 6241 was a s= mall incremental update to RFC 4271.

IMO, a NETCONF version of (HTTP or FTP) put and get doe= s not advance
interoperability or operator utility. =A0A version = of NETCONF with nothiing
mandatory to implement except a <hell= o> (netconf-zero) is even less useful to end users.


Andy


--14dae9340cd9f00f3904c233256d-- From lhotka@nic.cz Mon Jun 11 07:33: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 2C3D421F860F for ; Mon, 11 Jun 2012 07:33:38 -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 Q35tIP7RrNNP for ; Mon, 11 Jun 2012 07:33:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 89DB621F855D for ; Mon, 11 Jun 2012 07:33:34 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 1BA9614181B; Mon, 11 Jun 2012 16:33:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339425211; bh=1iQrAyvENO9R7eGmrK8nQ3QYjpX9WTD4fleEQoJi/ZY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K7sTlAxcoWJCK5rIORdgur1teJt3CM8+AnqPm/k0apVU3T2nfbcL4oE5RjA+3nNNz PGmq9ViIgh3fOjMYJg0O8oi9z7HF07ZnGCPhL1sEB8AQIxj+HWp4IvtoZZgbbagloK ege4e7zIKFDEPttx1yCtpZamNQjtMojyqiWeOqH8= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Jun 2012 16:33:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> To: Carl Moberg X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 14:33:38 -0000 On Jun 11, 2012, at 3:45 PM, Carl Moberg wrote: >=20 > On Jun 11, 2012, at 15:28 PM, Ladislav Lhotka wrote: >=20 >>=20 >> On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: >>=20 >>> "Bert Wijnen \(IETF\)" writes: >>>> Please express your support or objections w.r.t. to this >>>> proposal. Pls do so asap, but in any event, no later than >>>> June 20th 2012 (any timezone) >>>=20 >>> I object to any "2.0" efforts. We have a new set of technologies >>> that need some development, field testing, and experience. = Revisiting >>> them for a "2.0" effort before the paint is dry on the "1.0" will >>> be detrimental efforts to gain mindshare. >>=20 >> I don't know whether the paint is dry on IPv6 but RFC 6434 recently = introduced relatively significant changes in terms of what is required = from an IPv6 node. For instance, IPSec used to be a MUST, now it is a = SHOULD - simply because almost nobody bothered to implement it but still = claimed to have a standard IPv6 implementation. >>=20 >> Apparently, NETCONF also has a few features that are too = heavy-weight, clumsy or broken. There is already a decent amount of = operational experience and I believe it is time - after about ten years = - to adjust NETCONF to the current reality, which actually also includes = YANG. >=20 >=20 > For the record; I don't actually see any strong suggestions that there = are any features that are "too heavy-weight, clumsy or broken" in = NETCONF or YANG. At least I have never heard that type of feedback from = the implementations that we've been working with. Sure, there are issues = and challenges with implementing server-side NETCONF (and YANG) = particularly around retrofitting it on top of existing software = infrastructure, but I have no experience that there are show stopping = aspects to it that must be fixed. Apparently there are implementations that tend to avoid, for various = reasons, certain features that are mandatory in NETCONF, hence NETCONF = Light. Lada >=20 > I agree with Phil, let's get (lots) more development, testing and = experience before we move. Only now do we see signs of network = management software that leverages the features of NETCONF (instead of = retrofitting it onto SNMP-centric architecture) and I would like to see = how that pans out before drawing any conclusions. >=20 > As was mentioned in our side-meeting in Paris; even better if we could = get hold of a handful of those fabled "EMS developers" (that everyone is = referring to but noone seems to be able to produce) and see what they = think. The discussions we have had this far is based solely on strawmen. >=20 > Regards, > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Jun 11 07:52: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 CE20821F862B for ; Mon, 11 Jun 2012 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 4r3e1NJQE2bH for ; Mon, 11 Jun 2012 07:52:08 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC6FA21F8611 for ; Mon, 11 Jun 2012 07:52:07 -0700 (PDT) Received: by yhq56 with SMTP id 56so3063247yhq.31 for ; Mon, 11 Jun 2012 07:52:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=bBR/u4EkfvfAZtsh0/P/gRFG4ycnvgf2JijAMlHhZpU=; b=IYb4CwGXTlg+DhrCeTV/6M6ScDee0MZK4uZ9rmGSqkjSem6Uc7xuBSkrGjbkw5BCnr RD1vXkJ7kuudZIoS9e4WmNSy4dCAU/T0hUblfgd8nRbrht7c4ePfavg6qEy2qgjhWZud VBatt6B+j+LiderShVkELnnpaYUlMI/D47T1y0tvl0+c+o2jcJIaDTdQWWvyRlvfNuPZ awoHEN4c8ZasfTAL2EjqV33ToE3lR6OTN4MBww1sWvECc6wcT7XvKQm7rEyXqp49TrvP j2YMN01R+BM9xOWiwe7mOhtt2RiF3bXuv+cV3rh0QH8emS8F+ZQZsxoUDR/SSKX0pZZy //Jg== MIME-Version: 1.0 Received: by 10.50.186.196 with SMTP id fm4mr6448204igc.34.1339426326690; Mon, 11 Jun 2012 07:52:06 -0700 (PDT) Received: by 10.50.193.232 with HTTP; Mon, 11 Jun 2012 07:52:06 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> Date: Mon, 11 Jun 2012 07:52:06 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=14dae9340fe767bcd804c2337e69 X-Gm-Message-State: ALoCoQlJ/vNT8daGJvmNWyIWnORGn3gkD1uEUUaZE/Lgl4sqh1vwfbpWqc7Hkt0bQrEbaP66IIzU Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 14:52:09 -0000 --14dae9340fe767bcd804c2337e69 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 11, 2012 at 7:33 AM, Ladislav Lhotka wrote: > > On Jun 11, 2012, at 3:45 PM, Carl Moberg wrote: > > > > > On Jun 11, 2012, at 15:28 PM, Ladislav Lhotka wrote: > > > >> > >> On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: > >> > >>> "Bert Wijnen \(IETF\)" writes: > >>>> Please express your support or objections w.r.t. to this > >>>> proposal. Pls do so asap, but in any event, no later than > >>>> June 20th 2012 (any timezone) > >>> > >>> I object to any "2.0" efforts. We have a new set of technologies > >>> that need some development, field testing, and experience. Revisiting > >>> them for a "2.0" effort before the paint is dry on the "1.0" will > >>> be detrimental efforts to gain mindshare. > >> > >> I don't know whether the paint is dry on IPv6 but RFC 6434 recently > introduced relatively significant changes in terms of what is required from > an IPv6 node. For instance, IPSec used to be a MUST, now it is a SHOULD - > simply because almost nobody bothered to implement it but still claimed to > have a standard IPv6 implementation. > >> > >> Apparently, NETCONF also has a few features that are too heavy-weight, > clumsy or broken. There is already a decent amount of operational > experience and I believe it is time - after about ten years - to adjust > NETCONF to the current reality, which actually also includes YANG. > > > > > > For the record; I don't actually see any strong suggestions that there > are any features that are "too heavy-weight, clumsy or broken" in NETCONF > or YANG. At least I have never heard that type of feedback from the > implementations that we've been working with. Sure, there are issues and > challenges with implementing server-side NETCONF (and YANG) particularly > around retrofitting it on top of existing software infrastructure, but I > have no experience that there are show stopping aspects to it that must be > fixed. > > Apparently there are implementations that tend to avoid, for various > reasons, certain features that are mandatory in NETCONF, hence NETCONF > Light. > > I think we should focus on the utility that is delivered to network operators. The art of engineering NETCONF-Light is removing features that have the biggest impact on memory and CPU footprint, while still providing utility to network operators. BTW, there are 2 independent implementations for all of RFC 6241, so instead from being too heavyweight to implement, it is ready to advance on the standards track (after some interop testing). > Lada > Andy > > > > > I agree with Phil, let's get (lots) more development, testing and > experience before we move. Only now do we see signs of network management > software that leverages the features of NETCONF (instead of retrofitting it > onto SNMP-centric architecture) and I would like to see how that pans out > before drawing any conclusions. > > > > As was mentioned in our side-meeting in Paris; even better if we could > get hold of a handful of those fabled "EMS developers" (that everyone is > referring to but noone seems to be able to produce) and see what they > think. The discussions we have had this far is based solely on strawmen. > > > > Regards, > > -- > > Carl Moberg, Tail-f Systems > > mailto:calle@tail-f.com > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --14dae9340fe767bcd804c2337e69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 11, 2012 at 7:33 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
Lada

Andy
=A0

>
> I agree with Phil, let's get (lots) more development, testing and = experience before we move. Only now do we see signs of network management s= oftware that leverages the features of NETCONF (instead of retrofitting it = onto SNMP-centric architecture) and I would like to see how that pans out b= efore drawing any conclusions.
>
> As was mentioned in our side-meeting in Paris; even better if we could= get hold of a handful of those fabled "EMS developers" (that eve= ryone is referring to but noone seems to be able to produce) and see what t= hey think. The discussions we have had this far is based solely on strawmen= .
>
> Regards,
> --
> Carl Moberg, Tail-f Systems
> mailto:calle@tail-f.com

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--14dae9340fe767bcd804c2337e69-- From lhotka@nic.cz Mon Jun 11 08:20:10 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 6FFA121F84B3 for ; Mon, 11 Jun 2012 08:20:10 -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=[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 W-gddYeGricu for ; Mon, 11 Jun 2012 08:20:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A08DA21F862A for ; Mon, 11 Jun 2012 08:20:09 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 99BED141281; Mon, 11 Jun 2012 17:20:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339428008; bh=Q79K470i2b1bWb7VjoeFPDsM9zV7/RM3cQhFoF8og3c=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N5uxZBK+M6Nj27TG07MwwFn27WIeJBqPWD5EDB1L+s/cvvahdGof8LKu/O+B5AVDO hRir1R5bnjbiYYOe9maTv0Pbp/aRZjxva1iYEt6dNW0zUeB4K7N9ZE+ikOiyltRk3R QwLIPtSODeBuZLj2nkgeZbeeSrmaLKnaxSEA03Jc= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Jun 2012 17:20:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <685AEBB6-D761-4B0F-9F0B-6BF2B9862517@nic.cz> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 15:20:10 -0000 On Jun 11, 2012, at 4:52 PM, Andy Bierman wrote: >=20 > I think we should focus on the utility that is delivered to network = operators. > The art of engineering NETCONF-Light is removing features that have = the biggest impact > on memory and CPU footprint, while still providing utility to network = operators. =85 or development manpower, =85 My original point was that instead of standardizing NETCONF Light it = would be better to have NETCONF 2.0 whose barebone version is a common = denominator for everybody. And those who have/need more functionality = would just advertise it as additional capabilities. >=20 > BTW, there are 2 independent implementations for all of RFC 6241, > so instead from being too heavyweight to implement, it is ready to = advance > on the standards track (after some interop testing). Sure, but this is not in conflict with any 2.0-related efforts. Lada >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Jun 11 08:48:49 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 E970521F8555 for ; Mon, 11 Jun 2012 08:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Tqik4bfeNs+o for ; Mon, 11 Jun 2012 08:48:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37FB521F856C for ; Mon, 11 Jun 2012 08:48:45 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4448699lbb.31 for ; Mon, 11 Jun 2012 08:48:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=mR0JBVNzCwRo8xod28Vu8dcSQC0pLRUE+u5ZLolvx5c=; b=BWfIbJf/Ktu2Sx1xG/iLW7kLD2lkbvFp7q1DeSqDzcwBlzwhmR/WCk63tOIUFNwz+g th01xgI7XM84L2iUI3hKpLYrBld8JrMqn35mDow3PBMilanqJ8Nghd107yKXWDs8Z8JR ptNLtyatKWqot5IQnG+RiyBSy4RKaz1kEQIpCQBL6JuWQEwctxG3ym9x/dWoLI5nuJm2 QBORORW6d/JRavML6JhkYlBkEN5G9w7iOykv+8d/hZV8cO20glVpyElmNU5K2TZr2NJh 5PYbRYAcL3UZ5MAk+L7PYJ6iFqNzGGvPo59kzbxEx7Do0jObuNUt1oncuanQJ8f1cYK0 /J9Q== MIME-Version: 1.0 Received: by 10.152.146.163 with SMTP id td3mr18072849lab.26.1339429724134; Mon, 11 Jun 2012 08:48:44 -0700 (PDT) Received: by 10.114.65.17 with HTTP; Mon, 11 Jun 2012 08:48:44 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <685AEBB6-D761-4B0F-9F0B-6BF2B9862517@nic.cz> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <685AEBB6-D761-4B0F-9F0B-6BF2B9862517@nic.cz> Date: Mon, 11 Jun 2012 08:48:44 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=e89a8f234567e89b5604c23448cb X-Gm-Message-State: ALoCoQna9CWnwhN2Q0eOUlR8bL89cprHOcimDBxwtpwEcWT2pbRytZ8bBRzE5WjZVdtfkSaSrq0w Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 15:48:50 -0000 --e89a8f234567e89b5604c23448cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 8:20 AM, Ladislav Lhotka wrote: > > On Jun 11, 2012, at 4:52 PM, Andy Bierman wrote: > > > > > I think we should focus on the utility that is delivered to network > operators. > > The art of engineering NETCONF-Light is removing features that have the > biggest impact > > on memory and CPU footprint, while still providing utility to network > operators. > > =85 or development manpower, =85 > IMO impact on the Internet and interoperability should be the highest priorities. The charter is for network configuration, and multiple independent implementations should be able to perform network configuration using the standard protocol= . > My original point was that instead of standardizing NETCONF Light it woul= d > be better to have NETCONF 2.0 whose barebone version is a common > denominator for everybody. And those who have/need more functionality wou= ld > just advertise it as additional capabilities. > > I strongly oppose this approach, as well as calling it NETCONF 2.0. The message is not a common denominator the configuration management. > > > BTW, there are 2 independent implementations for all of RFC 6241, > > so instead from being too heavyweight to implement, it is ready to > advance > > on the standards track (after some interop testing). > > Sure, but this is not in conflict with any 2.0-related efforts. > > I don't think there is consensus to work on a "2.0" at this time. Nothing mainstream is broken - not even conformance. We might find in the future that module imports prevents us from ever changing an exportable typedef or grouping. The simple workaround is to use a different name. Some think this is a better approach anyway. It's OK with me if we don't work on any new versions of NETCONF now. Lada > > Andy --e89a8f234567e89b5604c23448cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 11, 2012 at 8:20 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:

My original point was that instead of standardizing NETCONF Light it would = be better to have NETCONF 2.0 whose barebone version is a common denominato= r for everybody. And those who have/need more functionality would just adve= rtise it as additional capabilities.


I strongly oppose this approach, as we= ll as calling it NETCONF 2.0.
The <hello> message is not a = common denominator the configuration
management.


>
> BTW, there are 2 independent implementations for all of RFC 6241,
> so instead from being too heavyweight to implement, it is ready to adv= ance
> on the standards track (after some interop testing).

Sure, but this is not in conflict with any 2.0-related efforts.



I don't think there= is consensus to work on a "2.0" at this time.
Nothing = mainstream is broken - not even conformance. =A0We might find in the future=
that module imports prevents us from ever changing an exportable
=
typedef or=A0grouping. =A0The simple workaround is to use a different = name.
Some think this is a better approach anyway.

It's OK with me if we don't work on any new versions of = NETCONF now.


Lada


Andy
=A0
--e89a8f234567e89b5604c23448cb-- From lhotka@nic.cz Mon Jun 11 09:11:49 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 C4D6221F8634 for ; Mon, 11 Jun 2012 09:11:49 -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=[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 TGXMDpSmcaiw for ; Mon, 11 Jun 2012 09:11:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B4FEF21F859A for ; Mon, 11 Jun 2012 09:11:48 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id E64D8141281; Mon, 11 Jun 2012 18:11:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339431108; bh=VkErKz3QwlB9dniHjsPrI5x6OOmYwEzE2cXP+rIwA50=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kS+AT7xX4RcYR3uX9cH0U2ag7Psj8+X1lkRf2o5xAYe8PHYXxozBHbrfjyViizjXR v5e+LVYSUzxDrb68KauSLNcbp70XqRTSojxSThueayNcG25vKiPJOPx+wJx0vVeXCZ ALg2GMPR+sQtE9D922yVlq7WeflXgD06DwkYP9J0= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Jun 2012 18:11:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <685AEBB6-D761-4B0F-9F0B-6BF2B9862517@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 16:11:49 -0000 On Jun 11, 2012, at 5:48 PM, Andy Bierman wrote: >=20 >=20 > On Mon, Jun 11, 2012 at 8:20 AM, Ladislav Lhotka = wrote: >=20 > On Jun 11, 2012, at 4:52 PM, Andy Bierman wrote: >=20 > > > > I think we should focus on the utility that is delivered to network = operators. > > The art of engineering NETCONF-Light is removing features that have = the biggest impact > > on memory and CPU footprint, while still providing utility to = network operators. >=20 > =85 or development manpower, =85 >=20 > IMO impact on the Internet and interoperability should be the highest = priorities. > The charter is for network configuration, and multiple independent = implementations > should be able to perform network configuration using the standard = protocol. >=20 >=20 >=20 > My original point was that instead of standardizing NETCONF Light it = would be better to have NETCONF 2.0 whose barebone version is a common = denominator for everybody. And those who have/need more functionality = would just advertise it as additional capabilities. >=20 >=20 > I strongly oppose this approach, as well as calling it NETCONF 2.0. > The message is not a common denominator the configuration > management. I don't get it. A server can now say in , e. g. "I implement = NACM", or "I implement defaults in this way". What is then the = difference if it also says "I implement global locks"? Another server = might instead say "I implement transactions" and avoid the overhead of = implementing locks. Lada >=20 >=20 > > > > BTW, there are 2 independent implementations for all of RFC 6241, > > so instead from being too heavyweight to implement, it is ready to = advance > > on the standards track (after some interop testing). >=20 > Sure, but this is not in conflict with any 2.0-related efforts. >=20 >=20 >=20 > I don't think there is consensus to work on a "2.0" at this time. > Nothing mainstream is broken - not even conformance. We might find in = the future > that module imports prevents us from ever changing an exportable > typedef or grouping. The simple workaround is to use a different = name. > Some think this is a better approach anyway. >=20 > It's OK with me if we don't work on any new versions of NETCONF now. >=20 >=20 > Lada >=20 >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Jun 11 09:26: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 9147821F85B9 for ; Mon, 11 Jun 2012 09:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rLnPAJCvhwZY for ; Mon, 11 Jun 2012 09:26:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9621F85A3 for ; Mon, 11 Jun 2012 09:26:54 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4484838lbb.31 for ; Mon, 11 Jun 2012 09:26:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TqAan4OfK3gCrNQ+BgchCDF1unfNwHJn5Xc1H7VfJmA=; b=b0ltEoHH2oFSpRb2EmtpJ5QB9n5CPaMdM+7MFf/11RToFoZc4RQFbVAnXeyuS4gPtr o2AY7+KjxkhODF/PHr8y0+b4MPUX6ShtNttMlKRXMJxuDL6MFP3qhLt92d9sj7rhlBpB VaN63i+mJhtSXbuUO/EV18EtwOoZ5113cxQlmes9JAq1S18tMFEORKddGQT667ZiRao0 Rfdco3PdfdNEoICE+xVPEd7vWL3gxeuJPHhF68UwwLUTYo5l9y19+eC4ciS/BLwrToNi LvWiqhe56dfv7RATPeWzc01qEdqbb5BiJoyKaQbVleR4jte/sWIhBFziWlgNLYRuiMwj ZQ9g== MIME-Version: 1.0 Received: by 10.112.48.39 with SMTP id i7mr3549434lbn.31.1339432013169; Mon, 11 Jun 2012 09:26:53 -0700 (PDT) Received: by 10.114.65.17 with HTTP; Mon, 11 Jun 2012 09:26:53 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <685AEBB6-D761-4B0F-9F0B-6BF2B9862517@nic.cz> Date: Mon, 11 Jun 2012 09:26:53 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec554dcaa58839e04c234d13b X-Gm-Message-State: ALoCoQlYha3lOOv1kwZZa8WjUNcWO4c5AHiig7GOMyVjegHjn6OOYpRuI1zeS6c6VsYLKrAmV/fS Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 16:26:55 -0000 --bcaec554dcaa58839e04c234d13b Content-Type: text/plain; charset=ISO-8859-1 > > ... > > > > I strongly oppose this approach, as well as calling it NETCONF 2.0. > > The message is not a common denominator the configuration > > management. > > I don't get it. A server can now say in , e. g. "I implement NACM", > or "I implement defaults in this way". What is then the difference if it > also says "I implement global locks"? Another server might instead say "I > implement transactions" and avoid the overhead of implementing locks. > > The issue is not the stuff already optional to implement, but rather the mandatory-to-implement parts of NETCONF base:1.1. The issue is how much can a client do with netconf-light -- i.e., how much is still mandatory-to-implement? Lada > Andy --bcaec554dcaa58839e04c234d13b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
...
>
> I strongly oppose this approach, as well as calling it NETCONF 2.0. > The <hello> message is not a common denominator the configuratio= n
> management.

I don't get it. A server can now say in <hello>, e. g. "I im= plement NACM", or "I implement defaults in this way". What i= s then the difference if it also says "I implement global locks"?= Another server might instead say "I implement transactions" and = avoid the overhead of implementing locks.


The issue is not the stuff already opt= ional to implement,
but rather the mandatory-to-implement parts o= f NETCONF base:1.1.
The issue is how much can a client do with ne= tconf-light -- i.e.,
how much is still mandatory-to-implement?

Lada

Andy
=A0
--bcaec554dcaa58839e04c234d13b-- From calle@tail-f.com Mon Jun 11 09:38: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 1DE9A21F856D for ; Mon, 11 Jun 2012 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqolK-OoJNxe for ; Mon, 11 Jun 2012 09:38:21 -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 4223321F848A for ; Mon, 11 Jun 2012 09:38:20 -0700 (PDT) Received: from [192.168.1.162] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id B7FCE1200D46; Mon, 11 Jun 2012 18:38:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Carl Moberg In-Reply-To: Date: Mon, 11 Jun 2012 18:38:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <111F4BDA-0249-4C3B-A413-99F63B8E44C2@tail-f.com> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 16:38:22 -0000 On Jun 11, 2012, at 16:27 PM, Andy Bierman wrote: >=20 >=20 > On Mon, Jun 11, 2012 at 6:45 AM, Carl Moberg wrote: >=20 > On Jun 11, 2012, at 15:28 PM, Ladislav Lhotka wrote: >=20 > > > > On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: > > > >> "Bert Wijnen \(IETF\)" writes: > >>> Please express your support or objections w.r.t. to this > >>> proposal. Pls do so asap, but in any event, no later than > >>> June 20th 2012 (any timezone) > >> > >> I object to any "2.0" efforts. We have a new set of technologies > >> that need some development, field testing, and experience. = Revisiting > >> them for a "2.0" effort before the paint is dry on the "1.0" will > >> be detrimental efforts to gain mindshare. > > > > I don't know whether the paint is dry on IPv6 but RFC 6434 recently = introduced relatively significant changes in terms of what is required = from an IPv6 node. For instance, IPSec used to be a MUST, now it is a = SHOULD - simply because almost nobody bothered to implement it but still = claimed to have a standard IPv6 implementation. > > > > Apparently, NETCONF also has a few features that are too = heavy-weight, clumsy or broken. There is already a decent amount of = operational experience and I believe it is time - after about ten years = - to adjust NETCONF to the current reality, which actually also includes = YANG. >=20 >=20 > For the record; I don't actually see any strong suggestions that = there are any features that are "too heavy-weight, clumsy or broken" in = NETCONF or YANG. At least I have never heard that type of feedback from = the implementations that we've been working with. Sure, there are issues = and challenges with implementing server-side NETCONF (and YANG) = particularly around retrofitting it on top of existing software = infrastructure, but I have no experience that there are show stopping = aspects to it that must be fixed. >=20 > I agree with Phil, let's get (lots) more development, testing and = experience before we move. Only now do we see signs of network = management software that leverages the features of NETCONF (instead of = retrofitting it onto SNMP-centric architecture) and I would like to see = how that pans out before drawing any conclusions. >=20 > As was mentioned in our side-meeting in Paris; even better if we = could get hold of a handful of those fabled "EMS developers" (that = everyone is referring to but noone seems to be able to produce) and see = what they think. The discussions we have had this far is based solely on = strawmen. >=20 >=20 >=20 > The feature list identified in Paris is not a strawman. > Transactions, conformance, and some other areas could be improved > in NETCONF. RFC 6241 was a small incremental update to RFC 4271. Agree that they can be improved, but my impression is still that the = there is no factual feedback from real-world users that point us in that = direction. It's just that *we* know that there are some irregularities = that could be improved. > IMO, a NETCONF version of (HTTP or FTP) put and get does not advance > interoperability or operator utility. A version of NETCONF with = nothiing > mandatory to implement except a (netconf-zero) is even less = useful to end users. Agreed. > Andy >=20 >=20 -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From calle@tail-f.com Mon Jun 11 09:39: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 7D2DA21F856D for ; Mon, 11 Jun 2012 09:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 N9TQPvDfmdAZ for ; Mon, 11 Jun 2012 09:39:38 -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 9EA6121F848A for ; Mon, 11 Jun 2012 09:39:37 -0700 (PDT) Received: from [192.168.1.162] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id D01BD1200D46; Mon, 11 Jun 2012 18:39:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: Date: Mon, 11 Jun 2012 18:39:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D7C606A-7892-48EB-853D-BB1A5A8CF18C@tail-f.com> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 16:39:38 -0000 On Jun 11, 2012, at 16:33 PM, Ladislav Lhotka wrote: >=20 > On Jun 11, 2012, at 3:45 PM, Carl Moberg wrote: >=20 >>=20 >> On Jun 11, 2012, at 15:28 PM, Ladislav Lhotka wrote: >>=20 >>>=20 >>> On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: >>>=20 >>>> "Bert Wijnen \(IETF\)" writes: >>>>> Please express your support or objections w.r.t. to this >>>>> proposal. Pls do so asap, but in any event, no later than >>>>> June 20th 2012 (any timezone) >>>>=20 >>>> I object to any "2.0" efforts. We have a new set of technologies >>>> that need some development, field testing, and experience. = Revisiting >>>> them for a "2.0" effort before the paint is dry on the "1.0" will >>>> be detrimental efforts to gain mindshare. >>>=20 >>> I don't know whether the paint is dry on IPv6 but RFC 6434 recently = introduced relatively significant changes in terms of what is required = from an IPv6 node. For instance, IPSec used to be a MUST, now it is a = SHOULD - simply because almost nobody bothered to implement it but still = claimed to have a standard IPv6 implementation. >>>=20 >>> Apparently, NETCONF also has a few features that are too = heavy-weight, clumsy or broken. There is already a decent amount of = operational experience and I believe it is time - after about ten years = - to adjust NETCONF to the current reality, which actually also includes = YANG. >>=20 >>=20 >> For the record; I don't actually see any strong suggestions that = there are any features that are "too heavy-weight, clumsy or broken" in = NETCONF or YANG. At least I have never heard that type of feedback from = the implementations that we've been working with. Sure, there are issues = and challenges with implementing server-side NETCONF (and YANG) = particularly around retrofitting it on top of existing software = infrastructure, but I have no experience that there are show stopping = aspects to it that must be fixed. >=20 > Apparently there are implementations that tend to avoid, for various = reasons, certain features that are mandatory in NETCONF, hence NETCONF = Light. Yes, but the reasons seems to have little to do with protocol design, = but with aspects of software development that protocols are poor at = addressing. > Lada >=20 >>=20 >> I agree with Phil, let's get (lots) more development, testing and = experience before we move. Only now do we see signs of network = management software that leverages the features of NETCONF (instead of = retrofitting it onto SNMP-centric architecture) and I would like to see = how that pans out before drawing any conclusions. >>=20 >> As was mentioned in our side-meeting in Paris; even better if we = could get hold of a handful of those fabled "EMS developers" (that = everyone is referring to but noone seems to be able to produce) and see = what they think. The discussions we have had this far is based solely on = strawmen. >>=20 >> Regards, >> -- >> Carl Moberg, Tail-f Systems >> mailto:calle@tail-f.com >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From lhotka@nic.cz Mon Jun 11 09:57: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 EBDCA21F854C for ; Mon, 11 Jun 2012 09:57:32 -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 epEECiqRJXYU for ; Mon, 11 Jun 2012 09:57:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5E921F8526 for ; Mon, 11 Jun 2012 09:57:32 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 6B663141281; Mon, 11 Jun 2012 18:57:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339433851; bh=CL669ichDGTPS4lHEIbTd7eZvFjgJ76JE1GCb/ZhNXg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UloHbxbo153CP4HiqIbNSh6JV+kwErbo9mHdnVSqjFT8e/DWqwAV0fry6l88yyvRx 1Ft+5wFpM4VNGs8YpRI6OU6GCZr08AQqTt9UtudsjM48RDgXL/ayXACWQYEnaPRziX 2drcPfQfRqy6CfeDJT/hP/1H04q3P/7YjXiGypwY= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Jun 2012 18:57:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <685AEBB6-D761-4B0F-9F0B-6BF2B9862517@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 16:57:33 -0000 On Jun 11, 2012, at 6:26 PM, Andy Bierman wrote: > ... > > > > I strongly oppose this approach, as well as calling it NETCONF 2.0. > > The message is not a common denominator the configuration > > management. >=20 > I don't get it. A server can now say in , e. g. "I implement = NACM", or "I implement defaults in this way". What is then the = difference if it also says "I implement global locks"? Another server = might instead say "I implement transactions" and avoid the overhead of = implementing locks. >=20 >=20 > The issue is not the stuff already optional to implement, > but rather the mandatory-to-implement parts of NETCONF base:1.1. > The issue is how much can a client do with netconf-light -- i.e., > how much is still mandatory-to-implement? Well, NACM is IMO quite critical, too, but still it is not mandatory.=20 Lada >=20 >=20 > Lada >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From calle@tail-f.com Mon Jun 11 10:17: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 E8EED21F8622 for ; Mon, 11 Jun 2012 10:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, 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 XAz5vkI6B3os for ; Mon, 11 Jun 2012 10:17:18 -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 2A69F21F860E for ; Mon, 11 Jun 2012 10:17:18 -0700 (PDT) Received: from [192.168.1.162] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id 0CC9C1200D46; Mon, 11 Jun 2012 19:17:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Carl Moberg In-Reply-To: Date: Mon, 11 Jun 2012 19:17:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <607566BF-3F1D-443F-AF33-41A9D393ACD0@tail-f.com> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <685AEBB6-D761-4B0F-9F0B-6BF2B9862517@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Mon, 11 Jun 2012 17:17:19 -0000 On Jun 11, 2012, at 18:57 PM, Ladislav Lhotka wrote: >=20 > On Jun 11, 2012, at 6:26 PM, Andy Bierman wrote: >=20 >> ... >>>=20 >>> I strongly oppose this approach, as well as calling it NETCONF 2.0. >>> The message is not a common denominator the configuration >>> management. >>=20 >> I don't get it. A server can now say in , e. g. "I implement = NACM", or "I implement defaults in this way". What is then the = difference if it also says "I implement global locks"? Another server = might instead say "I implement transactions" and avoid the overhead of = implementing locks. >>=20 >>=20 >> The issue is not the stuff already optional to implement, >> but rather the mandatory-to-implement parts of NETCONF base:1.1. >> The issue is how much can a client do with netconf-light -- i.e., >> how much is still mandatory-to-implement? >=20 > Well, NACM is IMO quite critical, too, but still it is not mandatory.=20= Perhaps this is more a game of words, but I certainly don't see the = current lack of NACM implementations in the market as "critical". Yes, = we would certainly be better off with a universally accepted access = control design and implementation(s) but I've yet to hear any = implementor (client or server) classify this as blocking their = development. In which case it would truly be critical, no? -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From alex@cisco.com Mon Jun 11 14:24: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 494BB21F8518 for ; Mon, 11 Jun 2012 14:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SJRMmqOm4YO for ; Mon, 11 Jun 2012 14:24:38 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5002221F8514 for ; Mon, 11 Jun 2012 14:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=3222; q=dns/txt; s=iport; t=1339449878; x=1340659478; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=3z1bkkAJay13NOSTY+lL39sVoDCxQvwa8JJGShIjcLI=; b=DAN1p0ItFzf0yM/B/QVE1JDuX2rmcwJP/kzt25UAV+eQOU1+2wuEGQy9 lEvJTqr4epwR39XYZhI2unYiolDu7m9DOXHZ6C3s1SeVgTFfM2N5ey2Vu S+jZXQ2e74dz37LBd4p9m7MAwq3Vx5Lg37kRMKxENl/r3qZtnVkooA8rN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP1g1k+rRDoH/2dsb2JhbABEtRiBB4IYAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYTBAEGASYfCQgBAQQBEggMDodoAQuYdJ9jBIskhTFgA4hAmnOBZoMA X-IronPort-AV: E=Sophos;i="4.75,751,1330905600"; d="scan'208";a="45959163" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 Jun 2012 21:24:38 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5BLObl9010066; Mon, 11 Jun 2012 21:24:37 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jun 2012 14:24:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2012 14:24:36 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE8DA@xmb-sjc-239.amer.cisco.com> In-Reply-To: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensuson the way forwardwithNetconf-Light] Thread-Index: Ac1ELORZxvi7PENJTV+c4HvK8uEQLwD60fMw References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> From: "Alexander Clemm (alex)" To: "Bert Wijnen (IETF)" , "Netconf" X-OriginalArrivalTime: 11 Jun 2012 21:24:37.0819 (UTC) FILETIME=[9ADCD0B0:01CD4818] Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensuson 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: Mon, 11 Jun 2012 21:24:39 -0000 I am kind of new to the working group, but for what it's worth, here are my thoughts on this: - To Bert's question: I echo the sentiment that it is not clear that definition of greater modularity alone such as proposed in Netconf Light is enough to define Netconf 2.0. I agree with Juergen that with the start of a project like this, we may want to consider if there are other items are to be pursued. There were a couple of items that were mentioned e.g. by Andy on the list earlier, from alternative encodings/JSON via improved ways to handle capabilities to supporting e.g. REST and connectionless models. Those are all sensible ideas, and those particular examples are things which I would like to see pursued. Changing to 2.0 seems like a major revision change, so it would be good to be clear which of those goals would be covered (also to avoid scope/feature creep etc) - On the current Netconf Light proposal: While I agree in sentiment with allowing for a lighter version and making things modular and like it from a conceptual perspective, I am skeptical of making everything optional from a practical standpoint. My concerns would be that this impedes interoperability and hence hurts rather than helps the Netconf value proposition. Lighter version, yes, but not with a potentially empty set of functionality=20 - That said, modularity _is_ of course important, and a 2.0 hopefully will not make things heavier but "better". =20 - On the coma stuff, it would seem that if the goal of Netconf light is particularly to address the needs of constrained devices, it will be important to be in sync with that community, as pointed out by Martin. However, I don't think a Netconf 2.0 has to depend on that community, as long as the goals are clearly articulated (and go beyond support of constrained devices). =20 Regards --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) Sent: Wednesday, June 06, 2012 2:39 PM To: Netconf Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensuson the way forwardwithNetconf-Light] Dear WG participants, it seem very difficult to converge on the topic of NetConf Light. We have evaluated the mailing lists discussions and have had conversations with several key participants. We also discussed this with our AD. From all that, we believe that an acceptable approach will be that we try to get approval (i.e. a chartered work item) for: Develop standards track NETCONF 2.0 with a new modular base version, which has a reduced set of mandatory features. The present functionality can be used as optional capabilities or YANG features. The "reduced set of mandatory features" is of course to be developed by the WG once we are chartered for this work. =20 Please express your support or objections w.r.t. to this proposal. Pls do so asap, but in any event, no later than June 20th 2012 (any timezone) Bert and Mehmet WG chairs for NETCONF _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Tue Jun 12 00:15: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 54E4E21F8568 for ; Tue, 12 Jun 2012 00:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 O5t+o2yewpzo for ; Tue, 12 Jun 2012 00:15:31 -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 58DAE21F8555 for ; Tue, 12 Jun 2012 00:15:31 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SeLK3-0001tO-SF for netconf@ietf.org; Tue, 12 Jun 2012 09:15:29 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SeLK3-00070d-HR for netconf@ietf.org; Tue, 12 Jun 2012 09:15:27 +0200 Message-ID: <4FD6EC8F.7000601@bwijnen.net> Date: Tue, 12 Jun 2012 09:15:27 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: netconf References: <316729C3-4C8C-4F75-813B-A4CFB2275480@opennetworking.org> In-Reply-To: <316729C3-4C8C-4F75-813B-A4CFB2275480@opennetworking.org> X-Forwarded-Message-Id: <316729C3-4C8C-4F75-813B-A4CFB2275480@opennetworking.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120612 clean 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: 86ab03e524994f79ca2c75a176445dd4240cd3e955ef604a8efaed96f520e8ab Subject: [Netconf] Fwd: Liaison letter from ONF to IETF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 07:15:33 -0000 FYI. NetConf and NetMod (not YANG) are mentioned in here. Bert -------- Original Message -------- Subject: Liaison letter from ONF to IETF Date: Wed, 6 Jun 2012 16:11:29 -0700 From: Dan Pitt To: ietf@ietf.org, iesg@ietf.org CC: Dan Pitt , iab@iab.org To: IETF From: Dan Pitt, executive director, ONF Subject: Liaison between ONF and IETF ONF (www.opennetworking.org) was established to promote Software Defined Networking (SDN) by creating a forum for users and vendors to discuss all aspects of SDNs, to create technical specifications and standards, and to evangelize SDNs to the networking industry and its customers. ONF’s scope spans data planes, control planes, and management planes, enabling programmability and management of the SDN. ONF's first task has been to standardize the OpenFlow protocol, the lowest level building block upon which SDN networks can be built. OpenFlow conveys flow-based forwarding information from a logical entity called a controller (or network operating system), which embodies the control-plane intelligence, to the network switches, which actually forward the packets based on directions received from the controller. The OpenFlow protocol therefore represents the controller’s southbound interface, and a protocol is indeed necessary because the switches and controller are assumed to be physically and geographically separate. The controller’s conceptual northbound interface permits other software entities representing such factors as policy, security, traffic engineering, and energy management to influence the controller’s determination of flow paths. ONF has not yet standardized the controller’s northbound interface, or determined its nature, and so it is too early to standardize orchestration of SDNs controlled via ONF standards. We in ONF are very interested to discuss potential SDN use cases developed by the IETF with a view to demonstrating how these can be expressed with ONF constructs, possibly as direct functions of the controller. ONF is further interested in the IETF’s orchestration of existing, stable non-SDN data and control planes that already have stable northbound interfaces (e.g., SNMP MIB, Netconf/Netmod). We recommend that ONF and IETF work together on SDN specifications, under the ONF framework of chartered ONF Working Groups (via mailing lists, wikis, and conference calls), ONF discussion groups (via mailing lists, wikis, and conference calls), and the ONF Technical Advisory Group (for oversight). ONF specifications will use and interact with IETF standards, such as Netconf and BFD. As ONF develops SDN specifications, ONF will work with IETF to bring requests for additions and changes to existing IETF specifications, and for new code points, as the need arises. ONF further believes there would be considerable benefit if code points defined in ONF specifications are assigned from registries managed by the IANA (Internet Assigned Numbers Authority). We would like to discuss with you the best way to achieve this. Finally, ONF is interested in discussing cross-publishing future specifications at the IETF, and would welcome a discussion on how best to accomplish this as well. Dan Pitt Executive Director Open Networking Foundation Palo Alto, California m. 617-803-5938 dan.pitt@opennetworking.org www.opennetworking.org From dromasca@avaya.com Tue Jun 12 01:28:04 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 CAC4F21F8510 for ; Tue, 12 Jun 2012 01:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.439 X-Spam-Level: X-Spam-Status: No, score=-103.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 HAqobG+TY16J for ; Tue, 12 Jun 2012 01:28:03 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5A98B21F84FB for ; Tue, 12 Jun 2012 01:28:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMD81k+HCzI1/2dsb2JhbABFtTiBB4IYAQEBAQMSHgpLBAIBCA0IDQYMBwQBBgFFEQEBBAESCAwOh2mcHZxqkFRgA5sUigaCYg X-IronPort-AV: E=Sophos;i="4.77,394,1336363200"; d="scan'208";a="352260498" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jun 2012 04:25:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jun 2012 04:09:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2012 10:27:49 +0200 Message-ID: In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE8DA@xmb-sjc-239.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensuson the way forwardwithNetconf-Light] Thread-Index: Ac1ELORZxvi7PENJTV+c4HvK8uEQLwD60fMwABcwzdA= References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <196FFAC4F80A9142A8C30A7EE9C33B790BBDE8DA@xmb-sjc-239.amer.cisco.com> From: "Romascanu, Dan (Dan)" To: "Alexander Clemm (alex)" , "Bert Wijnen (IETF)" , "Netconf" Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensuson 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: Tue, 12 Jun 2012 08:28:05 -0000 Hi, The coma work is still very much in scope debating phase, but the declared goals it started from are 'management of constrained networks and devices' - so not only 'constrained devices'.=20 Regards, Dan > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Alexander Clemm (alex) > - On the coma stuff, it would seem that if the goal of Netconf > light is particularly to address the needs of constrained devices, it > will be important to be in sync with that community, as pointed out by > Martin. However, I don't think a Netconf 2.0 has to depend on that > community, as long as the goals are clearly articulated (and go beyond > support of constrained devices). >=20 > Regards > --- Alex From lhotka@nic.cz Tue Jun 12 02:58: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 75E1221F8532 for ; Tue, 12 Jun 2012 02:58:54 -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 oxVbB6TMCp+j for ; Tue, 12 Jun 2012 02:58:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D9CC321F8512 for ; Tue, 12 Jun 2012 02:58:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 319ED5401E6; Tue, 12 Jun 2012 11:58:52 +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 sQDOkE8YCSMX; Tue, 12 Jun 2012 11:58:45 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 23A83540061; Tue, 12 Jun 2012 11:58:44 +0200 (CEST) From: Ladislav Lhotka To: Carl Moberg In-Reply-To: References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Tue, 12 Jun 2012 11:58:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Tue, 12 Jun 2012 09:58:54 -0000 Carl Moberg writes: > For the record; I don't actually see any strong suggestions that there are any features that are "too heavy-weight, clumsy or broken" in NETCONF or YANG. At least I have never heard that type of feedback from the implementations that we've been working with. Sure, there are issues and challenges with implementing server-side NETCONF (and YANG) particularly around retrofitting it on top of existing software infrastructure, but I have no experience that there are show stopping aspects to it that must be fixed. OK, let me mention one thing: the design of is wrong. A standard approach would be to have one expression for locating the node to be updated and another one for specifying the changes. This is how it is done e.g. in XQuery Update or in databases. attempts to do both steps in one shot which doesn't really work all that great. While this may not be a showstopper, it certainly causes problems - cf. the parallel discussion in the NETMOD list regarding keys for route lists. With a separate locator expression, the NETCONF client wouldn't have to care about list keys all that much and just use any appropriate attributes for selecting a list entry. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From calle@tail-f.com Tue Jun 12 06:51: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 5BB2321F859A for ; Tue, 12 Jun 2012 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-iDETtBMsFL for ; Tue, 12 Jun 2012 06:51:52 -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 8F06021F8597 for ; Tue, 12 Jun 2012 06:51:52 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7AAA11200AD8; Tue, 12 Jun 2012 15:51:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: Date: Tue, 12 Jun 2012 15:51:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Tue, 12 Jun 2012 13:51:53 -0000 On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: > Carl Moberg writes: >> For the record; I don't actually see any strong suggestions that = there are any features that are "too heavy-weight, clumsy or broken" in = NETCONF or YANG. At least I have never heard that type of feedback from = the implementations that we've been working with. Sure, there are issues = and challenges with implementing server-side NETCONF (and YANG) = particularly around retrofitting it on top of existing software = infrastructure, but I have no experience that there are show stopping = aspects to it that must be fixed. >=20 > OK, let me mention one thing: the design of is wrong. A = standard approach would be to have one expression for locating the node = to be updated and another one for specifying the changes. This is how it = is done e.g. in XQuery Update or in databases. attempts to = do both steps in one shot which doesn't really work all that great. = While this may not be a showstopper, it certainly causes problems - cf. = the parallel discussion in the NETMOD list regarding keys for route = lists. With a separate locator expression, the NETCONF client wouldn't = have to care about list keys all that much and just use any appropriate = attributes for selecting a list entry. I agree that it's not perfect. It's about as good/bad as some other = protocols (e.g. SNMP). But the point that I come back to is that it's = certainly good enough (even with that imperfection and others) that it = has the potential to radically improve the way we do configuration = management in networks. Making it a moving target instead of widely = applying what we have would be a case of over optimization IMHO. Now, this looks like one dead horse :-) -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From phil@juniper.net Tue Jun 12 07:11: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 15FA021F85CD for ; Tue, 12 Jun 2012 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 TvLqagm3m792 for ; Tue, 12 Jun 2012 07:11:30 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1227021F8613 for ; Tue, 12 Jun 2012 07:11:24 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT9dOC9SP8J1EllYsEBpqPJ3cO5B4/RTH@postini.com; Tue, 12 Jun 2012 07:11:27 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Jun 2012 07:11:06 -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 q5CEB4124001; Tue, 12 Jun 2012 07:11:05 -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 q5CEB35n047937; Tue, 12 Jun 2012 10:11:03 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206121411.q5CEB35n047937@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Tue, 12 Jun 2012 10:11:03 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Tue, 12 Jun 2012 14:11:31 -0000 Ladislav Lhotka writes: >OK, let me mention one thing: the design of is wrong. Where "wrong" means "I don't care for it"? Certainly there's nothing provably wrong here. The current functionality has worked well for us for > 10 yrs. It uses a consistent approach for both finding targets, changing targets, and rendering targets. One can fetch an policy, add the "replace" attribute value, and load that data as a "patch" on multiple boxes. It puts larger responsibilities on the client than the server, with the assumption that the client has more resources and more current software, where the device is dumber and will be upgraded as rarely as possible. It's not XQuery, but one of the goals was making it accessable to non-programmers, and I think the declarative nature allows this. I would not want to see NETCONF turn into XQuery. Yeah, I know. You were just checking to see if I was still here ;^) Thanks, Phil From lhotka@nic.cz Tue Jun 12 07:36: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 9DC5B21F8683 for ; Tue, 12 Jun 2012 07:36:09 -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=[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 iXr-HYdgB-4U for ; Tue, 12 Jun 2012 07:36:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E79D621F8682 for ; Tue, 12 Jun 2012 07:36:08 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 2969F1412F9; Tue, 12 Jun 2012 16:36:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339511768; bh=jxp9WIG/wR4/LyW02yCw2tkUfNLamG3GUVObKlKBCH8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mmT0oJl4nc56gexwFlWegti/eAtGhoBovV4n0iLM25Utg4r7Kdoras1q+2guSFSeM Y8xhrxCkRkeDOlN+BvUJXlTQsQw9rqlamYANoUqAVckq0Gpk8I5mBRXn7llh/ydJ5V sGnRyvfP1CAxeA+WPvGaz/tXWmxJdF1XEF/tMddk= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> Date: Tue, 12 Jun 2012 16:36:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4140B099-A12A-40BA-9011-962D74833C76@nic.cz> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> To: Carl Moberg X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Tue, 12 Jun 2012 14:36:09 -0000 On Jun 12, 2012, at 3:51 PM, Carl Moberg wrote: >=20 > On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: >=20 >> Carl Moberg writes: >>> For the record; I don't actually see any strong suggestions that = there are any features that are "too heavy-weight, clumsy or broken" in = NETCONF or YANG. At least I have never heard that type of feedback from = the implementations that we've been working with. Sure, there are issues = and challenges with implementing server-side NETCONF (and YANG) = particularly around retrofitting it on top of existing software = infrastructure, but I have no experience that there are show stopping = aspects to it that must be fixed. >>=20 >> OK, let me mention one thing: the design of is wrong. A = standard approach would be to have one expression for locating the node = to be updated and another one for specifying the changes. This is how it = is done e.g. in XQuery Update or in databases. attempts to = do both steps in one shot which doesn't really work all that great. = While this may not be a showstopper, it certainly causes problems - cf. = the parallel discussion in the NETMOD list regarding keys for route = lists. With a separate locator expression, the NETCONF client wouldn't = have to care about list keys all that much and just use any appropriate = attributes for selecting a list entry. >=20 >=20 >=20 > I agree that it's not perfect. It's about as good/bad as some other = protocols (e.g. SNMP). But the point that I come back to is that it's = certainly good enough (even with that imperfection and others) that it = has the potential to radically improve the way we do configuration = management in networks. Making it a moving target instead of widely = applying what we have would be a case of over optimization IMHO. If NETCONF (ever) gets widely deployed, it will become next to = impossible to make any incompatible changes. Similar arguments were raised against fixing the SSH end-of-message = marker and yet everyone now seems happy with it. Things that are known = to be broken should be fixed. Lada =20 >=20 > Now, this looks like one dead horse :-) >=20 > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Jun 12 07:41: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 8903C21F86C7 for ; Tue, 12 Jun 2012 07:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 c+2juGkHYLhL for ; Tue, 12 Jun 2012 07:41:31 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91CCF21F865B for ; Tue, 12 Jun 2012 07:41:22 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so615737lbb.31 for ; Tue, 12 Jun 2012 07:41:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=impCcl4lm9/CDHizUlyZoZY5AWylMf34quqBXeTNmK8=; b=fH5XH9tg8m8lnlA3805Y4VKjRyfqidQL/rLaU4Jv3JP4fqaBEbF3pLO/G+IedteCdi DuVo1IwOPeZdWBKxjTYmoYytRTcMd6rKb1FliJim0kcbdKD1YJR4QzpQaMs5obM0tjiV 7Acb7EWvN5ZtTmoSKx2g9dXO0OIX7G4k1CkNGpElh4pBkssttpD7Jk47NNHtf+r5/+hl VbKwFfov9GBueSSUharIiz+EmIgLqTmnIZHwNqdZZ3VkjCe4axORCmLwLgiBO2EmscjY xFZNq93Ja7n2WJb75TXGCJqebJrJ5/RGB98jLhIKJkQfU4KrwVGdUftFn7FKK2XZ1KZP VLNA== MIME-Version: 1.0 Received: by 10.152.125.236 with SMTP id mt12mr20741541lab.12.1339512081384; Tue, 12 Jun 2012 07:41:21 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Tue, 12 Jun 2012 07:41:21 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <201206121411.q5CEB35n047937@idle.juniper.net> References: <201206121411.q5CEB35n047937@idle.juniper.net> Date: Tue, 12 Jun 2012 07:41:21 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: multipart/alternative; boundary=f46d04426e90c8842f04c2477522 X-Gm-Message-State: ALoCoQmukLAbadeWDgZ9qblqBLF9xiB5QWR2Rfe/4GV+ZHhEVEt78kh+RJU1HGSl8wmpWclzpv8p Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Tue, 12 Jun 2012 14:41:32 -0000 --f46d04426e90c8842f04c2477522 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 12, 2012 at 7:11 AM, Phil Shafer wrote: > Ladislav Lhotka writes: > >OK, let me mention one thing: the design of is wrong. > > Where "wrong" means "I don't care for it"? Certainly there's nothing > provably wrong here. The current functionality has worked well for > us for > 10 yrs. > > It uses a consistent approach for both finding targets, changing > targets, and rendering targets. One can fetch an policy, add the > "replace" attribute value, and load that data as a "patch" on > multiple boxes. > > It puts larger responsibilities on the client than the server, with > the assumption that the client has more resources and more current > software, where the device is dumber and will be upgraded as rarely > as possible. > > It's not XQuery, but one of the goals was making it accessable to > non-programmers, and I think the declarative nature allows this. > > I would not want to see NETCONF turn into XQuery. > > Agreed. But I think the approach Lada describes has its use-cases, such as constrained devices or open systems. There is plenty of complexity on the server to implement . It is harder to make N arbitrary edits work together than 1 edit at a time. There is some presumption that for writing is somehow way easier than to implement. It is still N arbitrary edits, except the operation is always "replace". NETCONF servers should go out of their way to prevent glitches to the device for config that is not really changing in a . Is a constrained device going to do this or just reset everything? If not, then an approach where the client picks a single subtree as the target resource (e.g., YANG-API) may be better. Specifying the path to the target resource is simpler and smaller as a path expression, than as an XML subtree. Encoding the path from root to the target resource in the subtree is inefficient for both client and server. The current approach is better if the client needs to do multiple edits at once. Yeah, I know. You were just checking to see if I was still here ;^) > > Thanks, > Phil > Andy --f46d04426e90c8842f04c2477522 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 12, 2012 at 7:11 AM, Phil Sh= afer <phil@juniper.net> wrote:
Ladislav Lhotka writes:
>OK, let me mention one thing: the design of <edit-config> is wron= g.

Where "wrong" means "I don't care for it"? =A0Certa= inly there's nothing
provably wrong here. =A0The current functionality has worked well for
us for > 10 yrs.

It uses a consistent approach for both finding targets, changing
targets, and rendering targets. =A0One can fetch an policy, add the
"replace" attribute value, and load that data as a "patch&qu= ot; on
multiple boxes.

It puts larger responsibilities on the client than the server, with
the assumption that the client has more resources and more current
software, where the device is dumber and will be upgraded as rarely
as possible.

It's not XQuery, but one of the goals was making it accessable to
non-programmers, and I think the declarative nature allows this.

I would not want to see NETCONF turn into XQuery.


Agreed. But I think the approach Lada = describes has its use-cases,
such as constrained devices or open = systems.

There is plenty of complexity on the serv= er to implement <edit-config>.
It is harder to make N arbitrary edits work together than 1 edit at a = time.
There is some presumption that <copy-config> for writ= ing is somehow way
easier than <edit-config> to implement. = =A0It is still N arbitrary edits, except
the operation is always "replace".

= NETCONF servers should go out of their way to prevent glitches to the devic= e
for config that is not really changing in a <copy-config>= . =A0Is a constrained device going to
do this or just reset everything? =A0If not, then an approach where th= e
client picks a single subtree as the target resource (e.g., YAN= G-API)
may be better.

Specifying the pat= h to the target resource is simpler and smaller as a path
expression, than as an XML subtree. =A0Encoding the path
fro= m root to the target resource in the <config> subtree is inefficient<= /div>
for both client and server.

The current = approach is better if the client needs to do multiple edits at once.



Yeah, I know. =A0You were just checking to see if I was still here ;^)

Thanks,
=A0Phil

Andy

--f46d04426e90c8842f04c2477522-- From lhotka@nic.cz Tue Jun 12 08:24: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 DC7AD21F86A4 for ; Tue, 12 Jun 2012 08:24:05 -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=[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 hKFCUayg7sJF for ; Tue, 12 Jun 2012 08:24:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5816A21F8513 for ; Tue, 12 Jun 2012 08:24:03 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 6C69F1412F9; Tue, 12 Jun 2012 17:24:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339514641; bh=RIKYgtfGYyVrpYbCGpa4SdYC9QzXhSR0y7G60w23kYs=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=JeAea3y8ujIzCFz5Kp7tcK41ovOkdTuZJwCmsYxU7QvLwC/EqORyP4I6i/+AUOafV QVTcvVCW680UGm0qMWecvQWGC6y8IqtdajtOIjd2rtzCN9Bg0mzFI8GNE0Dsb5jW7m EgUmJaDuIIzMSI5eO//t+mm19CSIwm6wMTwdZJ5s= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201206121411.q5CEB35n047937@idle.juniper.net> Date: Tue, 12 Jun 2012 17:23:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201206121411.q5CEB35n047937@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Tue, 12 Jun 2012 15:24:06 -0000 On Jun 12, 2012, at 4:11 PM, Phil Shafer wrote: > Ladislav Lhotka writes: >> OK, let me mention one thing: the design of is wrong. >=20 > Where "wrong" means "I don't care for it"? Certainly there's nothing > provably wrong here. The current functionality has worked well for > us for > 10 yrs. It was fixed in YANG by introducing mandatory list keys and additional = rules for , but they also make some things harder than = necessary. >=20 > It uses a consistent approach for both finding targets, changing > targets, and rendering targets. One can fetch an policy, add the > "replace" attribute value, and load that data as a "patch" on > multiple boxes. But you can only use keys for selecting list entries, and the key of an = entry cannot be changed. >=20 > It puts larger responsibilities on the client than the server, with > the assumption that the client has more resources and more current > software, where the device is dumber and will be upgraded as rarely > as possible. >=20 > It's not XQuery, but one of the goals was making it accessable to > non-programmers, and I think the declarative nature allows this. IMO with separate locator and update spec it would be even more = accessible and flexible. >=20 > I would not want to see NETCONF turn into XQuery. Neither would I, it was just an example. Actually, HTTP methods work the = same way. >=20 > Yeah, I know. You were just checking to see if I was still here ;^) Why, you started this thread, didn't you? :-) Lada >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From alex@cisco.com Tue Jun 12 10:58: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 0A32021F8568 for ; Tue, 12 Jun 2012 10:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuRRuingDRJX for ; Tue, 12 Jun 2012 10:58:10 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 33C9621F84B6 for ; Tue, 12 Jun 2012 10:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=2890; q=dns/txt; s=iport; t=1339523890; x=1340733490; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AAQdi6gZu0toK7sUvZu3zmP2oQ8FqQa3vaoqk9yA8L0=; b=maU+IeTA4ElxJ8KVRTFIIj0RI3jv1nVvwJk6X8s8phrF3vCvsw7ERvlS FWVCJ/jyxHC1N9WCidjREI/2NnWJk98yky3JhcMekRnIQImTlZ2nwIOJp SUTYOwWzu4hEU94Z0so1n0p/nKzyufqpLm8PQdP+3OuN6dvjCznTk+AwG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKGC10+rRDoH/2dsb2JhbABFtTeBB4IYAQEBAwEBAQEPAR0KNAsFBwQCAQgOAwQBAQsGEwQBBgEmHwkIAQEEARIIGodkBAELmU2fd4snhTFgA4hAmnSBZoMA X-IronPort-AV: E=Sophos;i="4.75,759,1330905600"; d="scan'208";a="48647343" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 12 Jun 2012 17:58:10 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5CHw9lr029504; Tue, 12 Jun 2012 17:58:09 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 10:58:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2012 10:58:08 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC8821B@xmb-sjc-239.amer.cisco.com> In-Reply-To: <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] Thread-Index: Ac1IoojOCOCB2ayZTTWsfO9kbxK78AAIT0HQ References: <201206111248.q5BCmC02017907@idle.juniper.net><3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> From: "Alexander Clemm (alex)" To: "Carl Moberg" , "Ladislav Lhotka" X-OriginalArrivalTime: 12 Jun 2012 17:58:09.0609 (UTC) FILETIME=[ED53BB90:01CD48C4] Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus 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: Tue, 12 Jun 2012 17:58:11 -0000 Just my 2 cents, one aspect that seems a bit clumsy in YANG concerns the specification of conditions and constraints. While it is certainly possible to argue that it does the job, it is fairly hard to use. If it is hard to use, things might be left up to implementations while they really should be captured in the spec. It might be worthwhile to consider possible alternatives to the current scheme, such as being able to refer to a more "procedural" way to refer to constraints, rather than the declarative way it is now.=20 --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Carl Moberg Sent: Tuesday, June 12, 2012 6:52 AM To: Ladislav Lhotka Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: > Carl Moberg writes: >> For the record; I don't actually see any strong suggestions that there are any features that are "too heavy-weight, clumsy or broken" in NETCONF or YANG. At least I have never heard that type of feedback from the implementations that we've been working with. Sure, there are issues and challenges with implementing server-side NETCONF (and YANG) particularly around retrofitting it on top of existing software infrastructure, but I have no experience that there are show stopping aspects to it that must be fixed. >=20 > OK, let me mention one thing: the design of is wrong. A standard approach would be to have one expression for locating the node to be updated and another one for specifying the changes. This is how it is done e.g. in XQuery Update or in databases. attempts to do both steps in one shot which doesn't really work all that great. While this may not be a showstopper, it certainly causes problems - cf. the parallel discussion in the NETMOD list regarding keys for route lists. With a separate locator expression, the NETCONF client wouldn't have to care about list keys all that much and just use any appropriate attributes for selecting a list entry. I agree that it's not perfect. It's about as good/bad as some other protocols (e.g. SNMP). But the point that I come back to is that it's certainly good enough (even with that imperfection and others) that it has the potential to radically improve the way we do configuration management in networks. Making it a moving target instead of widely applying what we have would be a case of over optimization IMHO. Now, this looks like one dead horse :-) -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From randy_presuhn@mindspring.com Tue Jun 12 11: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 3FE0A21F85B6 for ; Tue, 12 Jun 2012 11:04:50 -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 VuVvj4HhiYkh for ; Tue, 12 Jun 2012 11:04:49 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id A972721F85A4 for ; Tue, 12 Jun 2012 11:04:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=q/DTM/otdQXUgN+dgt/FGOpevPOYYwKiDu1eJij3dR+koNwVMGpOomsjhmHirTpz; 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.48.158] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SeVST-00005P-1x for netconf@ietf.org; Tue, 12 Jun 2012 14:04:49 -0400 Message-ID: <002f01cd48c6$54569fa0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf" References: <201206121411.q5CEB35n047937@idle.juniper.net> Date: Tue, 12 Jun 2012 11:08:10 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f8876adb7d83ca336a4aa97b3323c7ac8f3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.158 Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus 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: Tue, 12 Jun 2012 18:04:50 -0000 Hi - > From: "Ladislav Lhotka" > To: "Phil Shafer" > Cc: "Netconf" > Sent: Tuesday, June 12, 2012 8:23 AM > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] ... > IMO with separate locator and update spec it would be even more accessible and flexible. ...or at least clearly distinguishing them in the operator syntax. Other benefits of separation: - it makes implementing access control a bit more efficient (allows earlier detection of "deny" cases) - it makes support for "subagents" and other forms of dynamically added / removed instrumentation much easier to deal with - it allows straightforward implementation of operators that do "the same thing" to a whole set of objects (e.g. disable all interfaces currently in alarm states) - it potentially allows one to talk about locks and granularity in more reasonable terms This separation was one of the things CMIP got right, and SNMP got perhaps half right, though I fear mentioning that might endanger it here. What might seem like a downside (but really isn't) is that it forces the protocol design to acknowledge at least the gestalt of the naming architecture. Imposing those constraints is actually a good thing, because it makes it possible, even necessary to forbid the really pathological architectures a priori. Randy From calle@tail-f.com Tue Jun 12 12:23:29 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 6C32321F86C8 for ; Tue, 12 Jun 2012 12:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, 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 k8Sr+2Cm6BKG for ; Tue, 12 Jun 2012 12:23:28 -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 96CF521F8625 for ; Tue, 12 Jun 2012 12:23:28 -0700 (PDT) Received: from [192.168.1.162] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id 40D141200D62; Tue, 12 Jun 2012 21:23:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: <4140B099-A12A-40BA-9011-962D74833C76@nic.cz> Date: Tue, 12 Jun 2012 21:23:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A1EA643-A52F-465A-ACEF-285CF048E68A@tail-f.com> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> <4140B099-A12A-40BA-9011-962D74833C76@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Tue, 12 Jun 2012 19:23:29 -0000 On Jun 12, 2012, at 16:36 PM, Ladislav Lhotka wrote: >=20 > On Jun 12, 2012, at 3:51 PM, Carl Moberg wrote: >=20 >>=20 >> On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: >>=20 >>> Carl Moberg writes: >>>> For the record; I don't actually see any strong suggestions that = there are any features that are "too heavy-weight, clumsy or broken" in = NETCONF or YANG. At least I have never heard that type of feedback from = the implementations that we've been working with. Sure, there are issues = and challenges with implementing server-side NETCONF (and YANG) = particularly around retrofitting it on top of existing software = infrastructure, but I have no experience that there are show stopping = aspects to it that must be fixed. >>>=20 >>> OK, let me mention one thing: the design of is wrong. = A standard approach would be to have one expression for locating the = node to be updated and another one for specifying the changes. This is = how it is done e.g. in XQuery Update or in databases. = attempts to do both steps in one shot which doesn't really work all that = great. While this may not be a showstopper, it certainly causes problems = - cf. the parallel discussion in the NETMOD list regarding keys for = route lists. With a separate locator expression, the NETCONF client = wouldn't have to care about list keys all that much and just use any = appropriate attributes for selecting a list entry. >>=20 >>=20 >>=20 >> I agree that it's not perfect. It's about as good/bad as some other = protocols (e.g. SNMP). But the point that I come back to is that it's = certainly good enough (even with that imperfection and others) that it = has the potential to radically improve the way we do configuration = management in networks. Making it a moving target instead of widely = applying what we have would be a case of over optimization IMHO. >=20 > If NETCONF (ever) gets widely deployed, it will become next to = impossible to make any incompatible changes. >=20 > Similar arguments were raised against fixing the SSH end-of-message = marker and yet everyone now seems happy with it. Things that are known = to be broken should be fixed. I think the difference is significant. The concerns around the = end-of-message marker was related to potential (or actual) security = issues that could seriously undermine the willingness to adopt the = NETCONF protocol. I'd argue that the edit-config concern you're raising = is not "broken", it could potentially be improved for some unspecified = application context. -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From bwijnen@ripe.net Wed Jun 13 01:12: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 8224221F86B8 for ; Wed, 13 Jun 2012 01:11:59 -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 Sea5gtFVVc0d for ; Wed, 13 Jun 2012 01:11:58 -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 29E3221F86B5 for ; Wed, 13 Jun 2012 01:11:56 -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 1SeigE-00037c-MF for netconf@ietf.org; Wed, 13 Jun 2012 10:11:56 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SeigE-0004Iq-FX for netconf@ietf.org; Wed, 13 Jun 2012 10:11:54 +0200 Message-ID: <4FD84B4A.9000907@ripe.net> Date: Wed, 13 Jun 2012 10:11:54 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120613 clean 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 -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885eb610c5fe9c9cf6d4609cee349a4b54e4 Subject: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 08:12:00 -0000 Dear WG participants, We have 7 days (one week) left for responses to our consensus call for NetConf 2.0. Anyone who still wants to express an opinion or wants to comment on the discussions so far, please do so by June 20th. In that case, PLEASE use as subject line: Subject: WG Consensus call: Netconf 2.0? From the discussion so far, it is pretty clear that we are NOT CONVERGING towards consensus. As a matter of fact, it feels to us that the WG is very much diverged as to what kind of work needs to be done and with what priority/sequence. The NetConf Lite discussion did not get us to consensus. Yet, the WG expressed in Paris that we DO WANT/NEED to work (or at least investigate) in the area of NetConf for constrained devices. The idea of the WG chairs was: If we can do a NetConf 2.0 (or if NetConf 1.2 is more appropriate, that is fine too) that we define with a minimum (but agreed by the WG) set of mandatory features, then all current NetConf 1.0 and 1.1 features can still be published by existing implementations, and they are in the same good shape as they are today. But it DOES allow for constrained devices to choose the minimum (agreed) to NetConf 2.0 (or 1.2) functionality and to expand on that depending on the capabilities and needs of the constrained device. At the same time, by providing that modularity, all the other features that have been discussed can be added as new features (capabilities) to NetConf 2.0 (1.2). We wanted to restrict the first step to "Making NetConf more modular" to start with. Then adding other work items (as discussed on the list) can be done over time. It seems to us that that first step could be a pretty focused and soon-to-be-completed work item. But ... it seems not to be so. Was this thinking completely wrong? Or is it that we just rather keep discussing all sorts of possible (or more important?) work instead of making the first step? We're confused. Please enlighten us. Bert and Mehmet From bwijnen@ripe.net Wed Jun 13 01:41: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 B91AB21F865C for ; Wed, 13 Jun 2012 01:41: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 i5u5Lx+GnJQk for ; Wed, 13 Jun 2012 01:41:26 -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 DA59221F8642 for ; Wed, 13 Jun 2012 01:41:25 -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 1Sej8l-00046F-8z; Wed, 13 Jun 2012 10:41:24 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Sej8l-0006F7-19; Wed, 13 Jun 2012 10:41:23 +0200 Message-ID: <4FD85231.9000408@ripe.net> Date: Wed, 13 Jun 2012 10:41:21 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FD84B4A.9000907@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120613 clean 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 -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e2a2609ab039871ded3e546f5fbb5dc75 Cc: netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 08:41:26 -0000 On 6/13/12 10:24 AM, Romascanu, Dan (Dan) wrote: > Hi Bert, Mehmet, > > I apologize for not using the required subject line but I am doing it on > purpose. I am confused. The reason is that by discussing and asking for > consensus for Netconf 2.0 you seem to be asking much more than: > >> We wanted to restrict the first step to "Making NetConf >> more modular" to start with. > > This is different than: > >> allow for >> constrained devices to choose the minimum (agreed) to >> NetConf 2.0 (or 1.2) functionality and to expand on that >> depending on the capabilities and needs of the constrained >> device. > > Can you clarify what the call for consensus is? (or what am I missing?) > > Is it only for 'modularized' Netconf? > I believe that is what we were asking for: Develop standards track NETCONF 2.0 with a new modular base version, which has a reduced set of mandatory features. The present functionality can be used as optional capabilities or YANG features. Bert > Thanks and Regards, > > Dan > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Bert Wijnen >> Sent: Wednesday, June 13, 2012 11:12 AM >> To: Netconf >> Subject: [Netconf] we are NOT CONVERGING towards consensus >> >> >> Dear WG participants, >> >> We have 7 days (one week) left for responses to our consensus >> call for NetConf 2.0. Anyone who still wants to express an >> opinion or wants to comment on the discussions so far, please >> do so by June 20th. In that case, PLEASE use as subject line: >> >> Subject: WG Consensus call: Netconf 2.0? >> >> From the discussion so far, it is pretty clear that we are >> NOT CONVERGING towards consensus. As a matter of fact, it >> feels to us that the WG is very much diverged as to what >> kind of work needs to be done and with what priority/sequence. >> >> The NetConf Lite discussion did not get us to consensus. >> Yet, the WG expressed in Paris that we DO WANT/NEED to work >> (or at least investigate) in the area of NetConf for >> constrained devices. >> >> The idea of the WG chairs was: >> >> If we can do a NetConf 2.0 (or if NetConf 1.2 is more >> appropriate, that is fine too) that we define with a >> minimum (but agreed by the WG) set of mandatory features, >> then all current NetConf 1.0 and 1.1 features can still be >> published by existing implementations, and they are in the >> same good shape as they are today. But it DOES allow for >> constrained devices to choose the minimum (agreed) to >> NetConf 2.0 (or 1.2) functionality and to expand on that >> depending on the capabilities and needs of the constrained >> device. >> >> At the same time, by providing that modularity, all the >> other features that have been discussed can be added as >> new features (capabilities) to NetConf 2.0 (1.2). >> >> We wanted to restrict the first step to "Making NetConf >> more modular" to start with. Then adding other work items >> (as discussed on the list) can be done over time. It seems >> to us that that first step could be a pretty focused and >> soon-to-be-completed work item. >> >> But ... it seems not to be so. >> Was this thinking completely wrong? >> Or is it that we just rather keep discussing all sorts of >> possible (or more important?) work instead of making the >> first step? >> >> We're confused. Please enlighten us. >> Bert and Mehmet >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Wed Jun 13 01:46: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 EC0B121F86A4 for ; Wed, 13 Jun 2012 01:46:28 -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 AFj0Tb4HWD5D for ; Wed, 13 Jun 2012 01:46:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E915F21F8693 for ; Wed, 13 Jun 2012 01:46:27 -0700 (PDT) Received: from dhcp-232.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id E61401412CA; Wed, 13 Jun 2012 10:46:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339577187; bh=QJqLxn7Gl1kGtQaqvuiZH/xu5UydxyBJJQubZH3LAEk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xM4vR98LzTxmXg2HabceXBOYpkROlfE7kIidUN5nYPj3Cun130eJno8OPzGJKI/XX NWTFDSDjszdr504ylWf2oMY0UT3Pe1/9OfPQB41ACYnygKsEpLEUiB0BFXFP+TzQcO mPSlYXsDoQfzQfILhukNkulNF8CZfHS8dHAJcH70= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4FD84B4A.9000907@ripe.net> Date: Wed, 13 Jun 2012 10:46:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> References: <4FD84B4A.9000907@ripe.net> To: Bert Wijnen X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 08:46:29 -0000 On Jun 13, 2012, at 10:11 AM, Bert Wijnen wrote: >=20 > Dear WG participants, >=20 > We have 7 days (one week) left for responses to our consensus > call for NetConf 2.0. Anyone who still wants to express an > opinion or wants to comment on the discussions so far, please > do so by June 20th. In that case, PLEASE use as subject line: >=20 > Subject: WG Consensus call: Netconf 2.0? >=20 > =46rom the discussion so far, it is pretty clear that we are > NOT CONVERGING towards consensus. As a matter of fact, it > feels to us that the WG is very much diverged as to what > kind of work needs to be done and with what priority/sequence. >=20 > The NetConf Lite discussion did not get us to consensus. > Yet, the WG expressed in Paris that we DO WANT/NEED to work > (or at least investigate) in the area of NetConf for > constrained devices. >=20 > The idea of the WG chairs was: >=20 > If we can do a NetConf 2.0 (or if NetConf 1.2 is more > appropriate, that is fine too) that we define with a > minimum (but agreed by the WG) set of mandatory features, > then all current NetConf 1.0 and 1.1 features can still be > published by existing implementations, and they are in the > same good shape as they are today. But it DOES allow for > constrained devices to choose the minimum (agreed) to > NetConf 2.0 (or 1.2) functionality and to expand on that > depending on the capabilities and needs of the constrained > device. >=20 > At the same time, by providing that modularity, all the > other features that have been discussed can be added as > new features (capabilities) to NetConf 2.0 (1.2). >=20 > We wanted to restrict the first step to "Making NetConf > more modular" to start with. Then adding other work items > (as discussed on the list) can be done over time. It seems > to us that that first step could be a pretty focused and > soon-to-be-completed work item. IMO this is a very sensible scenario that is backward-compatible with = NETCONF 1.1, includes NETCONF Light, and opens the space for new = development and tests of alternative approaches. I believe it could also = eventually help the development of more complex YANG models because, for = example, the issue of configuration versus state data is still largely = unresolved. I understand though that the scenario somewhat undermines marketing = assets of NETCONF. Lada =20 >=20 > But ... it seems not to be so. > Was this thinking completely wrong? > Or is it that we just rather keep discussing all sorts of > possible (or more important?) work instead of making the > first step? >=20 > We're confused. Please enlighten us. > Bert and Mehmet >=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 dromasca@avaya.com Wed Jun 13 01:47: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 6A72521F84FF for ; Wed, 13 Jun 2012 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.621 X-Spam-Level: X-Spam-Status: No, score=-103.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 hOqUy0j18BFJ for ; Wed, 13 Jun 2012 01:47:45 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0223A21F84CD for ; Wed, 13 Jun 2012 01:47:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPtS2E/GmAcF/2dsb2JhbABFtTqBB4IYAQEBAQMSCxMKPwwEAgEIDQEDBAEBAQoGDAsBBgFFCQgBAQQTCBqHaZx/nRWLJ4UxYAObF4oGgmI X-IronPort-AV: E=Sophos;i="4.77,402,1336363200"; d="scan'208";a="352463426" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Jun 2012 04:45:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jun 2012 04:46:03 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 10:47:42 +0200 Message-ID: In-Reply-To: <4FD85231.9000408@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] we are NOT CONVERGING towards consensus Thread-Index: Ac1JQFP5K2iHJPd6RMKJzyBsmIrPvQAACOuQ References: <4FD84B4A.9000907@ripe.net> <4FD85231.9000408@ripe.net> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen" Cc: netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 08:47:46 -0000 > -----Original Message----- > From: Bert Wijnen [mailto:bwijnen@ripe.net] > Sent: Wednesday, June 13, 2012 11:41 AM > To: Romascanu, Dan (Dan) > Cc: netconf > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus >=20 > On 6/13/12 10:24 AM, Romascanu, Dan (Dan) wrote: > > Hi Bert, Mehmet, > > > > I apologize for not using the required subject line but I am doing it > on > > purpose. I am confused. The reason is that by discussing and asking > for > > consensus for Netconf 2.0 you seem to be asking much more than: > > > >> We wanted to restrict the first step to "Making NetConf > >> more modular" to start with. > > > > This is different than: > > > >> allow for > >> constrained devices to choose the minimum (agreed) to > >> NetConf 2.0 (or 1.2) functionality and to expand on that > >> depending on the capabilities and needs of the constrained > >> device. > > > > Can you clarify what the call for consensus is? (or what am I > missing?) > > > > Is it only for 'modularized' Netconf? > > >=20 > I believe that is what we were asking for: >=20 > Develop standards track NETCONF 2.0 with a new > modular base version, which has a reduced set of > mandatory features. > The present functionality can be used as optional > capabilities or YANG features. >=20 > Bert >=20 Hi Bert, The language is not clear that this is about 'modularizing' existing functionality. Calling it Netconf 2.0 increases the confusion. But if it is only about defining the new modular version based on existing functionality - I support it.=20 Regards, Dan From lhotka@nic.cz Wed Jun 13 02:12: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 4223A21F8570 for ; Wed, 13 Jun 2012 02:12:45 -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=[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 6kdxWGZ7eJ9P for ; Wed, 13 Jun 2012 02:12:44 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E5E8221F843F for ; Wed, 13 Jun 2012 02:12:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B636C5402FE; Wed, 13 Jun 2012 11:12:41 +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 833VChE5En2K; Wed, 13 Jun 2012 11:12:38 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5D5855402C8; Wed, 13 Jun 2012 11:12:36 +0200 (CEST) From: Ladislav Lhotka To: "Alexander Clemm \(alex\)" , Carl Moberg In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC8821B@xmb-sjc-239.amer.cisco.com> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8821B@xmb-sjc-239.amer.cisco.com> User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 13 Jun 2012 11:12:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus 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: Wed, 13 Jun 2012 09:12:45 -0000 "Alexander Clemm (alex)" writes: > Just my 2 cents, one aspect that seems a bit clumsy in YANG concerns the > specification of conditions and constraints. While it is certainly > possible to argue that it does the job, it is fairly hard to use. If it Could you be more specific? What is exactly hard? Is it that, for example, one needs to carefully count the number of double dots in order to get to a remote node? Or missing semantics? > is hard to use, things might be left up to implementations while they > really should be captured in the spec. It might be worthwhile to > consider possible alternatives to the current scheme, such as being able > to refer to a more "procedural" way to refer to constraints, rather than > the declarative way it is now. We have been discussing the addition of several new XPath functions, but mainly for supporting special YANG data types, so nothing really procedural. Can you give some examples? Thanks, Lada > --- Alex > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Carl Moberg > Sent: Tuesday, June 12, 2012 6:52 AM > To: Ladislav Lhotka > Cc: Netconf > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying > aconsensus on the way forwardwithNetconf-Light] > > > On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: > >> Carl Moberg writes: >>> For the record; I don't actually see any strong suggestions that > there are any features that are "too heavy-weight, clumsy or broken" in > NETCONF or YANG. At least I have never heard that type of feedback from > the implementations that we've been working with. Sure, there are issues > and challenges with implementing server-side NETCONF (and YANG) > particularly around retrofitting it on top of existing software > infrastructure, but I have no experience that there are show stopping > aspects to it that must be fixed. >> >> OK, let me mention one thing: the design of is wrong. A > standard approach would be to have one expression for locating the node > to be updated and another one for specifying the changes. This is how it > is done e.g. in XQuery Update or in databases. attempts to > do both steps in one shot which doesn't really work all that great. > While this may not be a showstopper, it certainly causes problems - cf. > the parallel discussion in the NETMOD list regarding keys for route > lists. With a separate locator expression, the NETCONF client wouldn't > have to care about list keys all that much and just use any appropriate > attributes for selecting a list entry. > > > > I agree that it's not perfect. It's about as good/bad as some other > protocols (e.g. SNMP). But the point that I come back to is that it's > certainly good enough (even with that imperfection and others) that it > has the potential to radically improve the way we do configuration > management in networks. Making it a moving target instead of widely > applying what we have would be a case of over optimization IMHO. > > Now, this looks like one dead horse :-) > > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From per@tail-f.com Wed Jun 13 02:20: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 CDC6221F8679 for ; Wed, 13 Jun 2012 02:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 YmmUNf7WT0fp for ; Wed, 13 Jun 2012 02:20:11 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id DC23B21F8675 for ; Wed, 13 Jun 2012 02:20:10 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2361C1200DB2; Wed, 13 Jun 2012 11:20:09 +0200 (CEST) Message-ID: <4FD85B48.2070700@tail-f.com> Date: Wed, 13 Jun 2012 11:20:08 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> In-Reply-To: <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 09:20:12 -0000 On 2012-06-13 10:46, Ladislav Lhotka wrote: > > On Jun 13, 2012, at 10:11 AM, Bert Wijnen wrote: > >> >> Dear WG participants, >> >> We have 7 days (one week) left for responses to our consensus >> call for NetConf 2.0. Anyone who still wants to express an >> opinion or wants to comment on the discussions so far, please >> do so by June 20th. In that case, PLEASE use as subject line: >> >> Subject: WG Consensus call: Netconf 2.0? >> >> From the discussion so far, it is pretty clear that we are >> NOT CONVERGING towards consensus. As a matter of fact, it >> feels to us that the WG is very much diverged as to what >> kind of work needs to be done and with what priority/sequence. >> >> The NetConf Lite discussion did not get us to consensus. >> Yet, the WG expressed in Paris that we DO WANT/NEED to work >> (or at least investigate) in the area of NetConf for >> constrained devices. >> >> The idea of the WG chairs was: >> >> If we can do a NetConf 2.0 (or if NetConf 1.2 is more >> appropriate, that is fine too) that we define with a >> minimum (but agreed by the WG) set of mandatory features, >> then all current NetConf 1.0 and 1.1 features can still be >> published by existing implementations, and they are in the >> same good shape as they are today. But it DOES allow for >> constrained devices to choose the minimum (agreed) to >> NetConf 2.0 (or 1.2) functionality and to expand on that >> depending on the capabilities and needs of the constrained >> device. >> >> At the same time, by providing that modularity, all the >> other features that have been discussed can be added as >> new features (capabilities) to NetConf 2.0 (1.2). >> >> We wanted to restrict the first step to "Making NetConf >> more modular" to start with. Then adding other work items >> (as discussed on the list) can be done over time. It seems >> to us that that first step could be a pretty focused and >> soon-to-be-completed work item. > > IMO this is a very sensible scenario that is backward-compatible with NETCONF 1.1, includes NETCONF Light, and opens the space for new development and tests of alternative approaches. I believe it could also eventually help the development of more complex YANG models because, for example, the issue of configuration versus state data is still largely unresolved. [following the trend of ignoring Bert's request for a different subject] Whatever opinions anyone may have on this, it should be a crystal clear *fact* that making previously mandatory server functionality optional (in any protocol) can *never* be considered backward-compatible, since it breaks client implementations that rely on the presence of this functionality. My opinion: Making such non-backward-compatible changes in general, and making optional in particular, at this point in the life of NETCONF, will kill any remaining hope of having it become a ubiquitous and truly interoperable way to manage device configuration. --Per Hedeland > I understand though that the scenario somewhat undermines marketing assets of NETCONF. > > Lada > >> >> But ... it seems not to be so. >> Was this thinking completely wrong? >> Or is it that we just rather keep discussing all sorts of >> possible (or more important?) work instead of making the >> first step? >> >> We're confused. Please enlighten us. >> Bert and Mehmet >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > -- > 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 Jun 13 02:27: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 38E4021F8543 for ; Wed, 13 Jun 2012 02:27:32 -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=[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 1TqzwZktxbYU for ; Wed, 13 Jun 2012 02:27:31 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AABC321F8542 for ; Wed, 13 Jun 2012 02:27:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DDDBA5402FE; Wed, 13 Jun 2012 11:27:30 +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 uPBDLoo9nUUF; Wed, 13 Jun 2012 11:27:27 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id ED9745402C8; Wed, 13 Jun 2012 11:27:26 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Phil Shafer In-Reply-To: References: <201206121411.q5CEB35n047937@idle.juniper.net> User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 13 Jun 2012 11:27:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: 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: Wed, 13 Jun 2012 09:27:32 -0000 Andy Bierman writes: > > Specifying the path to the target resource is simpler and smaller as a path > expression, than as an XML subtree. Encoding the path > from root to the target resource in the subtree is inefficient > for both client and server. > > The current approach is better if the client needs to do multiple edits at > once. This is only an issue if you need to perform a larger atomic edit on "running", but this is quite problematic anyway. With "candidate" (or transactions) it can be done chunk-by-chunk. And, as Randy writes, such simple edits would be much easier to validate in terms of access control. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Jun 13 03:03: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 4B5A621F8679 for ; Wed, 13 Jun 2012 03:03:30 -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 BBHk2pyY2Rgq for ; Wed, 13 Jun 2012 03:03:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 48F7A21F8675 for ; Wed, 13 Jun 2012 03:03:29 -0700 (PDT) Received: from dhcp-232.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 4C5E913FACC; Wed, 13 Jun 2012 12:03:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339581808; bh=pwGZrxZ+m1F4jttkIn4RqEAMEOZnOWbayIcQBmOs7oc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=h/QVKOYspnPtAB6tGlzRm/nJWSlPd/gfpZgELHGk/BT9T5pZbNVy6yRnppjTTWXvk e88zbOuWe2gvQPTplcezl9ILTPNg2J7MB2T3+K7j399q8AVZTQ1NGuIqR89wQaLjrw Dpaem0tFu1DVi8q7jrNleIaV/6VoZVsNmFxN0fO0= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4FD85B48.2070700@tail-f.com> Date: Wed, 13 Jun 2012 12:03:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> To: Per Hedeland X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 10:03:30 -0000 On Jun 13, 2012, at 11:20 AM, Per Hedeland wrote: > On 2012-06-13 10:46, Ladislav Lhotka wrote: >>=20 >> On Jun 13, 2012, at 10:11 AM, Bert Wijnen wrote: >>=20 >>>=20 >>> Dear WG participants, >>>=20 >>> We have 7 days (one week) left for responses to our consensus >>> call for NetConf 2.0. Anyone who still wants to express an >>> opinion or wants to comment on the discussions so far, please >>> do so by June 20th. In that case, PLEASE use as subject line: >>>=20 >>> Subject: WG Consensus call: Netconf 2.0? >>>=20 >>> =46rom the discussion so far, it is pretty clear that we are >>> NOT CONVERGING towards consensus. As a matter of fact, it >>> feels to us that the WG is very much diverged as to what >>> kind of work needs to be done and with what priority/sequence. >>>=20 >>> The NetConf Lite discussion did not get us to consensus. >>> Yet, the WG expressed in Paris that we DO WANT/NEED to work >>> (or at least investigate) in the area of NetConf for >>> constrained devices. >>>=20 >>> The idea of the WG chairs was: >>>=20 >>> If we can do a NetConf 2.0 (or if NetConf 1.2 is more >>> appropriate, that is fine too) that we define with a >>> minimum (but agreed by the WG) set of mandatory features, >>> then all current NetConf 1.0 and 1.1 features can still be >>> published by existing implementations, and they are in the >>> same good shape as they are today. But it DOES allow for >>> constrained devices to choose the minimum (agreed) to >>> NetConf 2.0 (or 1.2) functionality and to expand on that >>> depending on the capabilities and needs of the constrained >>> device. >>>=20 >>> At the same time, by providing that modularity, all the >>> other features that have been discussed can be added as >>> new features (capabilities) to NetConf 2.0 (1.2). >>>=20 >>> We wanted to restrict the first step to "Making NetConf >>> more modular" to start with. Then adding other work items >>> (as discussed on the list) can be done over time. It seems >>> to us that that first step could be a pretty focused and >>> soon-to-be-completed work item. >>=20 >> IMO this is a very sensible scenario that is backward-compatible with = NETCONF 1.1, includes NETCONF Light, and opens the space for new = development and tests of alternative approaches. I believe it could also = eventually help the development of more complex YANG models because, for = example, the issue of configuration versus state data is still largely = unresolved. >=20 > [following the trend of ignoring Bert's request for a different = subject] >=20 > Whatever opinions anyone may have on this, it should be a crystal = clear > *fact* that making previously mandatory server functionality optional > (in any protocol) can *never* be considered backward-compatible, since > it breaks client implementations that rely on the presence of this > functionality. The functionality required by the old client can be provided as a = module. Of course, the client will have to accept new NETCONF-2.0 = capability URIs in the first place but other changes should not be = needed. This is what I call backward compatibility. It is pretty much like moving from a monolithic kernel to a modular one. = The latter is not incompatible with the former, provided all necessary = modules are properly loaded. And I don't believe a server upgrade ever happens without considering = the impact on clients. Lada >=20 > My opinion: Making such non-backward-compatible changes in general, = and > making optional in particular, at this point in the life > of NETCONF, will kill any remaining hope of having it become a > ubiquitous and truly interoperable way to manage device configuration. >=20 > --Per Hedeland >=20 >> I understand though that the scenario somewhat undermines marketing = assets of NETCONF. >>=20 >> Lada >>=20 >>>=20 >>> But ... it seems not to be so. >>> Was this thinking completely wrong? >>> Or is it that we just rather keep discussing all sorts of >>> possible (or more important?) work instead of making the >>> first step? >>>=20 >>> We're confused. Please enlighten us. >>> Bert and Mehmet >>>=20 >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From per@tail-f.com Wed Jun 13 03:52:43 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 A5DA021F860F for ; Wed, 13 Jun 2012 03:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 r32NeCE4KINN for ; Wed, 13 Jun 2012 03:52:43 -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 9F1D621F8564 for ; Wed, 13 Jun 2012 03:52:42 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 562DC1200DB2; Wed, 13 Jun 2012 12:52:41 +0200 (CEST) Message-ID: <4FD870F9.7000608@tail-f.com> Date: Wed, 13 Jun 2012 12:52:41 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> In-Reply-To: <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 10:52:43 -0000 On 2012-06-13 12:03, Ladislav Lhotka wrote: > > On Jun 13, 2012, at 11:20 AM, Per Hedeland wrote: > >> On 2012-06-13 10:46, Ladislav Lhotka wrote: >>> >>> On Jun 13, 2012, at 10:11 AM, Bert Wijnen wrote: >>> >>>> >>>> Dear WG participants, >>>> >>>> We have 7 days (one week) left for responses to our consensus >>>> call for NetConf 2.0. Anyone who still wants to express an >>>> opinion or wants to comment on the discussions so far, please >>>> do so by June 20th. In that case, PLEASE use as subject line: >>>> >>>> Subject: WG Consensus call: Netconf 2.0? >>>> >>>> From the discussion so far, it is pretty clear that we are >>>> NOT CONVERGING towards consensus. As a matter of fact, it >>>> feels to us that the WG is very much diverged as to what >>>> kind of work needs to be done and with what priority/sequence. >>>> >>>> The NetConf Lite discussion did not get us to consensus. >>>> Yet, the WG expressed in Paris that we DO WANT/NEED to work >>>> (or at least investigate) in the area of NetConf for >>>> constrained devices. >>>> >>>> The idea of the WG chairs was: >>>> >>>> If we can do a NetConf 2.0 (or if NetConf 1.2 is more >>>> appropriate, that is fine too) that we define with a >>>> minimum (but agreed by the WG) set of mandatory features, >>>> then all current NetConf 1.0 and 1.1 features can still be >>>> published by existing implementations, and they are in the >>>> same good shape as they are today. But it DOES allow for >>>> constrained devices to choose the minimum (agreed) to >>>> NetConf 2.0 (or 1.2) functionality and to expand on that >>>> depending on the capabilities and needs of the constrained >>>> device. >>>> >>>> At the same time, by providing that modularity, all the >>>> other features that have been discussed can be added as >>>> new features (capabilities) to NetConf 2.0 (1.2). >>>> >>>> We wanted to restrict the first step to "Making NetConf >>>> more modular" to start with. Then adding other work items >>>> (as discussed on the list) can be done over time. It seems >>>> to us that that first step could be a pretty focused and >>>> soon-to-be-completed work item. >>> >>> IMO this is a very sensible scenario that is backward-compatible with NETCONF 1.1, includes NETCONF Light, and opens the space for new development and tests of alternative approaches. I believe it could also eventually help the development of more complex YANG models because, for example, the issue of configuration versus state data is still largely unresolved. >> >> [following the trend of ignoring Bert's request for a different subject] >> >> Whatever opinions anyone may have on this, it should be a crystal clear >> *fact* that making previously mandatory server functionality optional >> (in any protocol) can *never* be considered backward-compatible, since >> it breaks client implementations that rely on the presence of this >> functionality. > > The functionality required by the old client can be provided as a module. I don't see how the form of the potential implementation of some optional functionality is relevant. The point is that the client, per the old spec, expects the functionality be present in any server implementing the protocol - and with the change in the protocol, this expectation is no longer fulfilled. This is non-backwards-compatibility. Unless you assume that "someone" will somehow provide and deploy "modules" implementing the optional functionality for every server implementation and installation - in which case making it optional would seem to be unnecessary. > Of course, the client will have to accept new NETCONF-2.0 capability URIs in the first place but other changes should not be needed. This is what I call backward compatibility. In that case I find your terminology to be at odds with commonly accepted usage. > It is pretty much like moving from a monolithic kernel to a modular one. The latter is not incompatible with the former, provided all necessary modules are properly loaded. Not at all, this is an implementation detail. The application writer can still rely on (say) the open(2) system call being present, since it is mandatory per the POSIX standard - whether it is implemented in a monolithic kernel or a module doesn't matter. > And I don't believe a server upgrade ever happens without considering the impact on clients. I guess this is where your problem is - you're thinking in the narrow scenario of dedicated clients talking to specific servers. If terms like "standard protocol" and "backwards compatibility" for such a protocol should have any meaning, you need to consider all combinations of client and server implementations, whether they actually happen to be talking to each other in any real-life deployment or not. The very point of standardizing a protocol is of course that all such combinations *should* be able to function correctly. --Per > Lada > >> >> My opinion: Making such non-backward-compatible changes in general, and >> making optional in particular, at this point in the life >> of NETCONF, will kill any remaining hope of having it become a >> ubiquitous and truly interoperable way to manage device configuration. >> >> --Per Hedeland >> >>> I understand though that the scenario somewhat undermines marketing assets of NETCONF. >>> >>> Lada >>> >>>> >>>> But ... it seems not to be so. >>>> Was this thinking completely wrong? >>>> Or is it that we just rather keep discussing all sorts of >>>> possible (or more important?) work instead of making the >>>> first step? >>>> >>>> We're confused. Please enlighten us. >>>> Bert and Mehmet >>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From dromasca@avaya.com Wed Jun 13 04:17: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 5D46221F8443 for ; Wed, 13 Jun 2012 04:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.617 X-Spam-Level: X-Spam-Status: No, score=-103.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 HB7WjqHwta9w for ; Wed, 13 Jun 2012 04:17:24 -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 7F27121F852E for ; Wed, 13 Jun 2012 04:17:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACt12E/GmAcF/2dsb2JhbABFtTqBB4IYAQEBAQIBEh4KPwwEAgEIDQgBDAYMCwEGAUURAQEEARIIEQIHh2QFnHWdFYsxhTFgA5sXigaCYg X-IronPort-AV: E=Sophos;i="4.77,402,1336363200"; d="scan'208";a="310773218" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jun 2012 07:15:48 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jun 2012 07:15:26 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 13:17:04 +0200 Message-ID: In-Reply-To: <4FD870F9.7000608@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] we are NOT CONVERGING towards consensus Thread-Index: Ac1JUq1tX3pwPvgtRreAlv+ZUBraqQAAqvvQ References: <4FD84B4A.9000907@ripe.net><84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz><4FD85B48.2070700@tail-f.com><933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Per Hedeland" , "Ladislav Lhotka" Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 11:17:25 -0000 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Per Hedeland > Sent: Wednesday, June 13, 2012 1:53 PM > To: Ladislav Lhotka ... > > The functionality required by the old client can be provided as a > module. >=20 > I don't see how the form of the potential implementation of some > optional functionality is relevant. The point is that the client, per > the old spec, expects the functionality be present in any server > implementing the protocol - and with the change in the protocol, this > expectation is no longer fulfilled. This is non-backwards- > compatibility. > Unless you assume that "someone" will somehow provide and deploy > "modules" implementing the optional functionality for every server > implementation and installation - in which case making it optional > would > seem to be unnecessary. >=20 > > Of course, the client will have to accept new NETCONF-2.0 capability > URIs in the first place but other changes should not be needed. This is > what I call backward compatibility. >=20 > In that case I find your terminology to be at odds with commonly > accepted usage. >=20 > > It is pretty much like moving from a monolithic kernel to a modular > one. The latter is not incompatible with the former, provided all > necessary modules are properly loaded. >=20 > Not at all, this is an implementation detail. The application writer > can > still rely on (say) the open(2) system call being present, since it is > mandatory per the POSIX standard - whether it is implemented in a > monolithic kernel or a module doesn't matter. >=20 > > And I don't believe a server upgrade ever happens without considering > the impact on clients. >=20 > I guess this is where your problem is - you're thinking in the narrow > scenario of dedicated clients talking to specific servers. If terms > like > "standard protocol" and "backwards compatibility" for such a protocol > should have any meaning, you need to consider all combinations of > client > and server implementations, whether they actually happen to be talking > to each other in any real-life deployment or not. The very point of > standardizing a protocol is of course that all such combinations > *should* be able to function correctly. >=20 > --Per >=20 Hi Per, So, are you saying that NETCONF will never be able to be modularized in such a way that it can be used as a solution for managing devices with restrained resources?=20 Regards, Dan From per@tail-f.com Wed Jun 13 04:42: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 4803C21F85C4 for ; Wed, 13 Jun 2012 04:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.300, 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 uZPLaPpk29YO for ; Wed, 13 Jun 2012 04:42:27 -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 AC95F21F8678 for ; Wed, 13 Jun 2012 04:42:27 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id ED9A51200DB3; Wed, 13 Jun 2012 13:42:26 +0200 (CEST) Message-ID: <4FD87CA2.40502@tail-f.com> Date: Wed, 13 Jun 2012 13:42:26 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FD84B4A.9000907@ripe.net><84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz><4FD85B48.2070700@tail-f.com><933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 11:42:28 -0000 On 2012-06-13 13:17, Romascanu, Dan (Dan) wrote: > > So, are you saying that NETCONF will never be able to be modularized in > such a way that it can be used as a solution for managing devices with > restrained resources? No, I'm mainly objecting to the use of "backwards compatible" to describe changes that clearly aren't. Obviously non-backwards-compatible changes are sometimes deemed necessary, or at least better than other alternatives - it's a trade-off decision like so many others. My *opinion*, as already stated, is that making such changes to NETCONF would be seriously detrimental to the general "success" of the protocol. I don't really have an opinion on whether implementation of the currently mandatory functionality actually is "too hard" for some unspecified class of "constrained" devices, nor whether it would be a disaster if such devices do "something else" in that case. --Per From bwijnen@ripe.net Wed Jun 13 05:04: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 E602321F8647 for ; Wed, 13 Jun 2012 05:04:09 -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 cG0uCjpf54L9 for ; Wed, 13 Jun 2012 05:04:09 -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 2504421F8503 for ; Wed, 13 Jun 2012 05:04:09 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SemIv-0003Zl-MO; Wed, 13 Jun 2012 14:04:06 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SemIu-0002Rm-EB; Wed, 13 Jun 2012 14:04:05 +0200 Message-ID: <4FD881B4.4040704@ripe.net> Date: Wed, 13 Jun 2012 14:04:04 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Per Hedeland References: <4FD84B4A.9000907@ripe.net><84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz><4FD85B48.2070700@tail-f.com><933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> <4FD87CA2.40502@tail-f.com> In-Reply-To: <4FD87CA2.40502@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120613 clean 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 -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e0dde6ba78784cadd86d84e744f1469e0 Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 12:04:10 -0000 On 6/13/12 1:42 PM, Per Hedeland wrote: > On 2012-06-13 13:17, Romascanu, Dan (Dan) wrote: >> >> So, are you saying that NETCONF will never be able to be modularized in >> such a way that it can be used as a solution for managing devices with >> restrained resources? > > No, I'm mainly objecting to the use of "backwards compatible" to > describe changes that clearly aren't. Obviously non-backwards-compatible > changes are sometimes deemed necessary, or at least better than other > alternatives - it's a trade-off decision like so many others. > I would think that an existing NetConf 1.1 client will check if the managed device supports NetConf 1.1 If so, it probably keeps using that set of capabilities. And so I see no problem. If a more advanced NetConf 2.0 client check if a managed device does NetConf 2.0, and if it does, then it also needs to check if the proper capabilities (those that were mandatory in Netconf 1.0 and 1.1) are supported by the managed device, and if so... boom we're running. If not, the client can try to fallback to NetConf 1.1. Is supported .. boom we're running. If not supported, then that means a new (constrained) device is being managed, and probably there are fewer capabilities than those on NetConf 1.1. The client can decide to not support that new (constrained) device, or it can decide to try to manage it with the lesser set of capabilities. All existing/fielded Netconf 1.0 and 1.1 operational configurations should continue to work wothout a problem. Is that not BACKWARD COMPATIBLE ?? Maybe I do not understand the term at all?? Bert > My *opinion*, as already stated, is that making such changes to NETCONF > would be seriously detrimental to the general "success" of the protocol. > I don't really have an opinion on whether implementation of the > currently mandatory functionality actually is "too hard" for some > unspecified class of "constrained" devices, nor whether it would be a > disaster if such devices do "something else" in that case. > > --Per From dromasca@avaya.com Wed Jun 13 06:05: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 C104C21F85D1 for ; Wed, 13 Jun 2012 06:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.616 X-Spam-Level: X-Spam-Status: No, score=-103.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 3X9Os2WbXjGj for ; Wed, 13 Jun 2012 06:05:51 -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 F157221F85A8 for ; Wed, 13 Jun 2012 06:05:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADqO2E/GmAcF/2dsb2JhbAA7CrU+gQeCGAEBAQEDEh4KPwwEAgEIDQEDBAEBAQoGDAsBBgFFCQgBAQQBEggTB4dpnRudDIsxEIUhYAObF4oGgmI X-IronPort-AV: E=Sophos;i="4.77,403,1336363200"; d="scan'208";a="310789162" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jun 2012 09:04:14 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jun 2012 09:04:07 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 15:05:45 +0200 Message-ID: In-Reply-To: <4FD881B4.4040704@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] we are NOT CONVERGING towards consensus Thread-Index: Ac1JXKUnuHGFreBWTd6oxUQxjGc38AACALyQ References: <4FD84B4A.9000907@ripe.net><84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz><4FD85B48.2070700@tail-f.com><933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> <4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen" , "Per Hedeland" Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 13:05:51 -0000 Hi, I am with Bert on this. Backwards compatibility in this context does not mean to me that any version of an old client must work with any future version of a server. This would be forwards compatibility :-) Backwards compatibility means IMO the capability to identify the version of the protocol run by the server and its capabilities and to be able to manage what matches the agent version level, and to gracefully ignore and alert the operator when the protocol interaction is not possible.=20 Regards, Dan > -----Original Message----- > From: Bert Wijnen [mailto:bwijnen@ripe.net] > Sent: Wednesday, June 13, 2012 3:04 PM > To: Per Hedeland > Cc: Romascanu, Dan (Dan); Ladislav Lhotka; Netconf > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus >=20 > On 6/13/12 1:42 PM, Per Hedeland wrote: > > On 2012-06-13 13:17, Romascanu, Dan (Dan) wrote: > >> > >> So, are you saying that NETCONF will never be able to be modularized > in > >> such a way that it can be used as a solution for managing devices > with > >> restrained resources? > > > > No, I'm mainly objecting to the use of "backwards compatible" to > > describe changes that clearly aren't. Obviously non-backwards- > compatible > > changes are sometimes deemed necessary, or at least better than other > > alternatives - it's a trade-off decision like so many others. > > >=20 > I would think that an existing NetConf 1.1 client will check if the > managed > device supports NetConf 1.1 If so, it probably keeps using that set of > capabilities. And so I see no problem. >=20 > If a more advanced NetConf 2.0 client check if a managed device does > NetConf 2.0, and if it does, then it also needs to check if the > proper capabilities (those that were mandatory in Netconf 1.0 and 1.1) > are supported by the managed device, and if so... boom we're running. > If not, the client can try to fallback to NetConf 1.1. > Is supported .. boom we're running. > If not supported, then that means a new (constrained) device is being > managed, and probably there are fewer capabilities than those on > NetConf 1.1. The client can decide to not support that new > (constrained) > device, or it can decide to try to manage it with the lesser set of > capabilities. >=20 > All existing/fielded Netconf 1.0 and 1.1 operational configurations > should > continue to work wothout a problem. >=20 > Is that not BACKWARD COMPATIBLE ?? >=20 > Maybe I do not understand the term at all?? >=20 > Bert >=20 >=20 >=20 >=20 > > My *opinion*, as already stated, is that making such changes to > NETCONF > > would be seriously detrimental to the general "success" of the > protocol. > > I don't really have an opinion on whether implementation of the > > currently mandatory functionality actually is "too hard" for some > > unspecified class of "constrained" devices, nor whether it would be a > > disaster if such devices do "something else" in that case. > > > > --Per From andy@yumaworks.com Wed Jun 13 07:40:07 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 B6DE121F864B for ; Wed, 13 Jun 2012 07:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 9SfqMq6GkYb3 for ; Wed, 13 Jun 2012 07:40:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 426F121F863E for ; Wed, 13 Jun 2012 07:40:06 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1563020lbb.31 for ; Wed, 13 Jun 2012 07:40:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9fuXOx7+ueWw4xg2BzSwWZBnPurcDsI3CaUWFc/vslQ=; b=FQmlRDbtFGlxQSYdPhjfPJTdxLEjHmGAwI12/BlkkvS5iTslwbF2cJzBhHUqauDmn/ WOzLsk9aVEaPP8DOjX8HyV2wVNzynAfJIwgBx2Zt3fQDPWhuLb9PR6x1AlXtbB3g+JBe jXkmb9CEe5RNLY7VyabQKcr6+4KBr2Y12gDW+330ASnB5mJQFf+2OdOQOhmbmQNimQ4r zIazgO8X4mtH4DOS37kzvFyiDMj8MydLxMUGlGNrZS//ibU3xGGi94jun7pmehmxfX2l eGWOe1oicIvIEw07nvI2CkHIkKzOC+l4EugaCqSRjRmQFtX9YT5jECC8d3eQknjSarfg O8Pg== MIME-Version: 1.0 Received: by 10.112.83.136 with SMTP id q8mr6305298lby.60.1339598404927; Wed, 13 Jun 2012 07:40:04 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Wed, 13 Jun 2012 07:40:04 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> Date: Wed, 13 Jun 2012 07:40:04 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=f46d04016d8f1141ce04c25b8f4d X-Gm-Message-State: ALoCoQnKGfR2AvSd+RCq0UafZAfZTV8xrVoOtbqiy5h8MUaYGCD01VSYMlFd7BPvlVcvzyWHPCmy Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 14:40:07 -0000 --f46d04016d8f1141ce04c25b8f4d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 13, 2012 at 3:03 AM, Ladislav Lhotka wrote: > > On Jun 13, 2012, at 11:20 AM, Per Hedeland wrote: > > > On 2012-06-13 10:46, Ladislav Lhotka wrote: > >> > >> On Jun 13, 2012, at 10:11 AM, Bert Wijnen wrote: > >> > >>> > >>> Dear WG participants, > >>> > >>> We have 7 days (one week) left for responses to our consensus > >>> call for NetConf 2.0. Anyone who still wants to express an > >>> opinion or wants to comment on the discussions so far, please > >>> do so by June 20th. In that case, PLEASE use as subject line: > >>> > >>> Subject: WG Consensus call: Netconf 2.0? > >>> > >>> From the discussion so far, it is pretty clear that we are > >>> NOT CONVERGING towards consensus. As a matter of fact, it > >>> feels to us that the WG is very much diverged as to what > >>> kind of work needs to be done and with what priority/sequence. > >>> > >>> The NetConf Lite discussion did not get us to consensus. > >>> Yet, the WG expressed in Paris that we DO WANT/NEED to work > >>> (or at least investigate) in the area of NetConf for > >>> constrained devices. > >>> > >>> The idea of the WG chairs was: > >>> > >>> If we can do a NetConf 2.0 (or if NetConf 1.2 is more > >>> appropriate, that is fine too) that we define with a > >>> minimum (but agreed by the WG) set of mandatory features, > >>> then all current NetConf 1.0 and 1.1 features can still be > >>> published by existing implementations, and they are in the > >>> same good shape as they are today. But it DOES allow for > >>> constrained devices to choose the minimum (agreed) to > >>> NetConf 2.0 (or 1.2) functionality and to expand on that > >>> depending on the capabilities and needs of the constrained > >>> device. > >>> > >>> At the same time, by providing that modularity, all the > >>> other features that have been discussed can be added as > >>> new features (capabilities) to NetConf 2.0 (1.2). > >>> > >>> We wanted to restrict the first step to "Making NetConf > >>> more modular" to start with. Then adding other work items > >>> (as discussed on the list) can be done over time. It seems > >>> to us that that first step could be a pretty focused and > >>> soon-to-be-completed work item. > >> > >> IMO this is a very sensible scenario that is backward-compatible with > NETCONF 1.1, includes NETCONF Light, and opens the space for new > development and tests of alternative approaches. I believe it could also > eventually help the development of more complex YANG models because, for > example, the issue of configuration versus state data is still largely > unresolved. > > > > [following the trend of ignoring Bert's request for a different subject] > > > > Whatever opinions anyone may have on this, it should be a crystal clear > > *fact* that making previously mandatory server functionality optional > > (in any protocol) can *never* be considered backward-compatible, since > > it breaks client implementations that rely on the presence of this > > functionality. > > The functionality required by the old client can be provided as a module. > Of course, the client will have to accept new NETCONF-2.0 capability URIs > in the first place but other changes should not be needed. This is what I > call backward compatibility. > > It is pretty much like moving from a monolithic kernel to a modular one. > The latter is not incompatible with the former, provided all necessary > modules are properly loaded. > > And I don't believe a server upgrade ever happens without considering the > impact on clients. > This isn't an upgrade. A base:1.0 or 1.1 server would never upgrade to this so-called "NETCONF 1.2". A base:1.2 server would never advertise 1.0 or 1.1 so an existing client will reject the server and drop the session. I think NETCONF-Light is a better name and capability than "NETCONF 1.2". The false appearance of a protocol update would completely confuse the market place. I strongly object to calling the work NETCONF 1.2 since it is not an upgrade. I also think many of the WG members do not understand what makes a NETCONF server heavyweight or not (e.g., getting rid of global but keeping full-blown XML encoding). I agree with Per that if a device does not have a standard way to do configuration editing, then it isn't a NETCONF device. It should be called something else. > Lada > Andy > > > > > My opinion: Making such non-backward-compatible changes in general, and > > making optional in particular, at this point in the life > > of NETCONF, will kill any remaining hope of having it become a > > ubiquitous and truly interoperable way to manage device configuration. > > > > --Per Hedeland > > > >> I understand though that the scenario somewhat undermines marketing > assets of NETCONF. > >> > >> Lada > >> > >>> > >>> But ... it seems not to be so. > >>> Was this thinking completely wrong? > >>> Or is it that we just rather keep discussing all sorts of > >>> possible (or more important?) work instead of making the > >>> first step? > >>> > >>> We're confused. Please enlighten us. > >>> Bert and Mehmet > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f46d04016d8f1141ce04c25b8f4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 13, 2012 at 3:03 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:

Lada


Andy
=A0<= /div>

>
> My opinion: Making such non-backward-compatible changes in general, an= d
> making <edit-config> optional in particular, at this point in th= e life
> of NETCONF, will kill any remaining hope of having it become a
> ubiquitous and truly interoperable way to manage device configuration.=
>
> --Per Hedeland
>
>> I understand though that the scenario somewhat undermines marketin= g assets of NETCONF.
>>
>> Lada
>>
>>>
>>> But ... it seems not to be so.
>>> Was this thinking completely wrong?
>>> Or is it that we just rather keep discussing all sorts of
>>> possible (or more important?) work instead of making the
>>> first step?
>>>
>>> We're confused. Please enlighten us.
>>> Bert and Mehmet
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--f46d04016d8f1141ce04c25b8f4d-- From lhotka@nic.cz Wed Jun 13 08:02: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 F16C421F85AF for ; Wed, 13 Jun 2012 08:02:37 -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 YGZrOOmDKYUz for ; Wed, 13 Jun 2012 08:02:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6821F852D for ; Wed, 13 Jun 2012 08:02:36 -0700 (PDT) Received: from [192.168.43.183] (89-24-51-2.i4g.tmcz.cz [89.24.51.2]) by mail.nic.cz (Postfix) with ESMTPSA id D908E13F64F; Wed, 13 Jun 2012 17:02:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339599755; bh=c1oYjnUp8IZrB4rsSyv30B7qD3r6bXATiohAvatGtmk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IkLSSE8O3grY4uLhkoG0SSN6srOqHYxIxnlwZ1bTtfRZHevN/UgBRyDZoR9m2Ib7u avoyDHhH/UzEQ406WtG4KoMoh9qi84sm7jb/Erb8K6htjeNtL3D6lKX+wOQ0JVxGQM zmywpmIds8Dh5vv+Qgu7BWSxkk0u9jhQ+2xbUXeQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: Date: Wed, 13 Jun 2012 17:02:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 15:02:38 -0000 On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: > I think NETCONF-Light is a better name and capability than "NETCONF = 1.2". > The false appearance of a protocol update would completely confuse the = market place. > I strongly object to calling the work NETCONF 1.2 since it is not an = upgrade. >=20 > I also think many of the WG members do not understand what makes > a NETCONF server heavyweight or not (e.g., getting rid of global = > but keeping full-blown XML encoding). Earlier today I heard a presentation of a guy who actively develops BIND = 10. Guess what - the wrote something quite similar to NETCONF based on = JSON. They did evaluate NETCONF but rejected it. =20 >=20 > I agree with Per that if a device does not have a standard way to > do configuration editing, then it isn't a NETCONF device. > It should be called something else. OK, if it is only a branding issue, I don't mind calling it YUM-YUM 0.1. Lada >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From calle@tail-f.com Wed Jun 13 08:23: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 93B1821F8550 for ; Wed, 13 Jun 2012 08:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, 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 NurGTcPXHBiE for ; Wed, 13 Jun 2012 08:23:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D068A21F850B for ; Wed, 13 Jun 2012 08:23:24 -0700 (PDT) Received: from [192.168.1.162] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id A75341200DB5; Wed, 13 Jun 2012 17:23:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: Date: Wed, 13 Jun 2012 17:23:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 15:23:25 -0000 On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: >=20 > On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: >=20 >> I think NETCONF-Light is a better name and capability than "NETCONF = 1.2". >> The false appearance of a protocol update would completely confuse = the market place. >> I strongly object to calling the work NETCONF 1.2 since it is not an = upgrade. >>=20 >> I also think many of the WG members do not understand what makes >> a NETCONF server heavyweight or not (e.g., getting rid of global = >> but keeping full-blown XML encoding). >=20 > Earlier today I heard a presentation of a guy who actively develops = BIND 10. Guess what - the wrote something quite similar to NETCONF based = on JSON. They did evaluate NETCONF but rejected it. I could tell you many stories where people reviewed and rejected = NETCONF since it didn't meet their requirements. So; why (based on which = criteria) did they reject NETCONF? Would they have done otherwise if we = had a "NETCONF 2.0" now? -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From andy@yumaworks.com Wed Jun 13 09:48: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 8AA9F21F853E for ; Wed, 13 Jun 2012 09:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nKaYYWJVMesX for ; Wed, 13 Jun 2012 09:48:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5821F84FC for ; Wed, 13 Jun 2012 09:48:08 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1672985lbb.31 for ; Wed, 13 Jun 2012 09:48:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BpqgjaJiuFUiFG/rKzgxA63qaOzKwxuoM8BitLvcq30=; b=oQJIX2qwxaCk7egCL2LYRqvfDwhn+vgRCUob/CMY6EaEhh+vcPotyJBDdl1pPM+QPt GOVuIqgp+0kUcu98+LLrK/P157Xoim2Ia9i/XErZFimhgz3dpJz9FIJEPpgSM2+Cq0J2 j/1F8XoeZnXrls6gfXEfF/OWrqBNXspeNa6a+6x0AqC0Bl5OH2mOpA5IqIU55VhWDp72 YA/89oxzv9up51gdLggIz011rXs9eHvYFK6Sxu9/VIKZ05SgXYEKOYX8KbvtKwCk2r7b G3qUEwbkPRh0VmsGLlPR6BOdfAGIE+MUt9ozMmGzDHgzI8OsuoML3Pgd0cmVVM57RSN5 bstw== MIME-Version: 1.0 Received: by 10.152.125.236 with SMTP id mt12mr24971285lab.12.1339606087520; Wed, 13 Jun 2012 09:48:07 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Wed, 13 Jun 2012 09:48:07 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> Date: Wed, 13 Jun 2012 09:48:07 -0700 Message-ID: From: Andy Bierman To: Carl Moberg Content-Type: multipart/alternative; boundary=f46d04426e90fc509504c25d5892 X-Gm-Message-State: ALoCoQnlHS+l5PinS3EA2bTCwjwYoLIx5GV4rFLMbkJRLf3+N1/s7ddfs8bPvA6H4ttmNI1U/7XT Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 16:48:20 -0000 --f46d04426e90fc509504c25d5892 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 13, 2012 at 8:23 AM, Carl Moberg wrote: > > On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: > > > > > On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: > > > >> I think NETCONF-Light is a better name and capability than "NETCONF > 1.2". > >> The false appearance of a protocol update would completely confuse the > market place. > >> I strongly object to calling the work NETCONF 1.2 since it is not an > upgrade. > >> > >> I also think many of the WG members do not understand what makes > >> a NETCONF server heavyweight or not (e.g., getting rid of global > >> but keeping full-blown XML encoding). > > > > Earlier today I heard a presentation of a guy who actively develops BIND > 10. Guess what - the wrote something quite similar to NETCONF based on > JSON. They did evaluate NETCONF but rejected it. > > I could tell you many stories where people reviewed and rejected NETCONF > since it didn't meet their requirements. So; why (based on which criteria) > did they reject NETCONF? Would they have done otherwise if we had a > "NETCONF 2.0" now? > > And we could tell stories about companies using NETCONF too... I'm biased, but I think YANG-API addresses many of the issues that cause NETCONF to be rejected as a solution by application developers. I don't think these people share the same requirements and toolsets as traditional NMS developers. Each group needs their own API. The traditional NMS group is covered with NETCONF 1.1. I don't think configuration of a constrained device should use the same hammer as a router. Making the hammer smaller only works to a point. Stateless RESTful operations encoded in JSON can be much less heavyweight than NETCONF. I think YANG-API scales from very small devices to huge routers with multiple candidates. -- > Carl Moberg, Tail-f Systems > Andy --f46d04426e90fc509504c25d5892 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 13, 2012 at 8:23 AM, Carl Mo= berg <calle@tail-f.com> wrote:

On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote:

>
> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote:
>
>> I think NETCONF-Light is a better name and capability than "N= ETCONF 1.2".
>> The false appearance of a protocol update would completely confuse= the market place.
>> I strongly object to calling the work NETCONF 1.2 since it is not = an upgrade.
>>
>> I also think many of the WG members do not understand what makes >> a NETCONF server heavyweight or not (e.g., getting rid of global &= lt;lock>
>> but keeping full-blown XML encoding).
>
> Earlier today I heard a presentation of a guy who actively develops BI= ND 10. Guess what - the wrote something quite similar to NETCONF based on J= SON. They did evaluate NETCONF but rejected it.

=A0I could tell you many stories where people reviewed and rejected NETCONF= since it didn't meet their requirements. So; why (based on which crite= ria) did they reject NETCONF? Would they have done otherwise if we had a &q= uot;NETCONF 2.0" now?


And we could tell stories about compan= ies using NETCONF too...

<shameless-plug>
I'm biased, but I think YANG-API addresses many of the issues
that cause NETCONF to be rejected as a solution by application
developers. =A0I don't think these people share the same requirement= s
and toolsets as traditional NMS developers. =A0Each group needs=
their own API. The traditional NMS group is covered with NETCONF 1.1.<= /div>

I don't think configuration of a constrained d= evice should use the same
hammer as a router. =A0Making the hamme= r smaller only works to a point.

Stateless RESTful operations encoded in JSON can be muc= h less
heavyweight than NETCONF. =A0I think YANG-API scales from = very
small devices to huge routers with multiple candidates.
</shameless-plug>


--
Carl Moberg, Tail-f Systems

Andy
<= div>
--f46d04426e90fc509504c25d5892-- From lhotka@nic.cz Wed Jun 13 09:49: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 DA80D21F85A3 for ; Wed, 13 Jun 2012 09:49:37 -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 SjkI+7LSuHap for ; Wed, 13 Jun 2012 09:49:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 567CA21F8592 for ; Wed, 13 Jun 2012 09:49:37 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 8C49813F63E; Wed, 13 Jun 2012 18:49:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339606176; bh=kqxvpjXdnDkvwTq3gUGCkUYu/3jgwau/HtdNQfEd+0M=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=q3CTsCp+4NmSmd4eV3U+mMny3fSOIL/NLBj5EXMBN19j2vtmfwbLIwmS/YqMHs2ej lpTsF9Toz9YX4ZCmf74lNWorTS6AgXhsrp6uf1x7PA1qzOBz6Ok0dRDxnNHKAz5Q1Q 6SceBQUy+U/QCz/Wjnx/bQ5D6wrRqPMHICx5cl3A= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Wed, 13 Jun 2012 18:49:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> To: Carl Moberg X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 16:49:38 -0000 On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote: >=20 > On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: >=20 >>=20 >> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: >>=20 >>> I think NETCONF-Light is a better name and capability than "NETCONF = 1.2". >>> The false appearance of a protocol update would completely confuse = the market place. >>> I strongly object to calling the work NETCONF 1.2 since it is not an = upgrade >>> I also think many of the WG members do not understand what makes >>> a NETCONF server heavyweight or not (e.g., getting rid of global = >>> but keeping full-blown XML encoding). >>=20 >> Earlier today I heard a presentation of a guy who actively develops = BIND 10. Guess what - the wrote something quite similar to NETCONF based = on JSON. They did evaluate NETCONF but rejected it. >=20 > I could tell you many stories where people reviewed and rejected = NETCONF since it didn't meet their requirements. So; why (based on which = criteria) did they reject NETCONF? Would they have done otherwise if we = had a "NETCONF 2.0" now? Probably not, their "configuration manager" (we would call it server) = uses RESTful API and JSON. Lada >=20 > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Jun 13 10:03: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 6AACE21F84D5 for ; Wed, 13 Jun 2012 10:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 V+l0g5dfoAVD for ; Wed, 13 Jun 2012 10:03:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E27B321F8510 for ; Wed, 13 Jun 2012 10:03:18 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1684423lbb.31 for ; Wed, 13 Jun 2012 10:03:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BoL0RTZRwjkw/DNY+l0mmFDrHL2iaEa3LAC5Ubj30VA=; b=bqzk1+N3hKh9/Luw3KEg/25FSotwwzRwYlYLpJxiOqSTIK7dz1qLTH0wxJKOVoZ6II ik3jXQwpLyrJ9GBTBJTN+6uCJbhnfMfJ1XF7UeOz9Yci94tvg45tZU8gH0B7NSr7WgIJ Id3neSJOgNZUSwnXA7xUnbkjU/N67O2dPnYudkaibyDeNWtDETres2ZvqSSqG5irKdan GE6GZ2eUO+Q5nRe/vlR5D1qzXX7lc1yMm/jdpwsVUhcThR2FTTJTeCyNk+F0MO3Yq3CY 7VY7bpqc53sH1rhSTdrVAve/vr6j+DoFNNXK0vLG21AY0nDvouVweWWCrNXlrnH3os0b hPaA== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr25051192lab.51.1339606997822; Wed, 13 Jun 2012 10:03:17 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Wed, 13 Jun 2012 10:03:17 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <002f01cd48c6$54569fa0$6b01a8c0@oemcomputer> References: <201206121411.q5CEB35n047937@idle.juniper.net> <002f01cd48c6$54569fa0$6b01a8c0@oemcomputer> Date: Wed, 13 Jun 2012 10:03:17 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=e89a8f22bfb13e6e6004c25d8f1e X-Gm-Message-State: ALoCoQlqk/W9xElj1phIqaxTewrjDRlSq8vhMGnsF+L+njmsnuCHQvUnLxFcfiuTU06O7dje0U1R Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus 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: Wed, 13 Jun 2012 17:03:20 -0000 --e89a8f22bfb13e6e6004c25d8f1e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 12, 2012 at 11:08 AM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > > From: "Ladislav Lhotka" > > To: "Phil Shafer" > > Cc: "Netconf" > > Sent: Tuesday, June 12, 2012 8:23 AM > > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying > aconsensus on the way forwardwithNetconf-Light] > ... > > IMO with separate locator and update spec it would be even more > accessible and flexible. > > ...or at least clearly distinguishing them in the operator syntax. > Other benefits of separation: > - it makes implementing access control a bit more efficient (allows > earlier > detection of "deny" cases) > - it makes support for "subagents" and other forms of dynamically added / > removed instrumentation much easier to deal with > - it allows straightforward implementation of operators that do "the > same thing" > to a whole set of objects (e.g. disable all interfaces currently in > alarm states) > - it potentially allows one to talk about locks and granularity in more > reasonable > terms > > Nice list. The 3rd bullet is one of the things in HTTP that I like the most. The separation of headers and message body (meta-data and data) is much cleaner than anything we have in NM protocols. Not only does it allow for reusable headers that do "the same thing" across many media types, it makes it easy to extend the set of operators independently of the base protocol or the data model. This separation was one of the things CMIP got right, and SNMP got perhaps > half right, though I fear mentioning that might endanger it here. > > What might seem like a downside (but really isn't) is that it forces the > protocol > design to acknowledge at least the gestalt of the naming architecture. > The thing we need the most is a unified naming architecture. The protocols and APIs can be tuned for different use-cases, but the data needs to be "glued together" somehow by the apps, (e.g. CLI, WEBui, REST-API, SNMP. NETCONF., syslog) > Imposing those constraints is actually a good thing, because it makes it > possible, even necessary to forbid the really pathological architectures a > priori. > > Randy > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --e89a8f22bfb13e6e6004c25d8f1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 12, 2012 at 11:08 AM, Randy = Presuhn <randy_presuhn@mindspring.com> wrote:
=
Hi -

> From: "Ladislav Lhotka" <lhotka@nic.cz>
> To: "Phil Shafer" <ph= il@juniper.net>
> Cc: "Netconf" <netcon= f@ietf.org>
> Sent: Tuesday, June 12, 2012 8:23 AM
> Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying ac= onsensus on the way forwardwithNetconf-Light]
...
> IMO with separate locator and update spec it would be even more access= ible and flexible.

...or at least clearly distinguishing them in the operator syntax.
Other benefits of separation:
=A0 - it makes implementing access control a bit more efficient (allows ea= rlier
=A0 =A0 detection of "deny" cases)
=A0 - it makes support for "subagents" and other forms of dynami= cally added /
=A0 =A0 removed instrumentation much easier to deal with
=A0 - it allows straightforward implementation of operators that do "= the same thing"
=A0 =A0 to a whole set of objects (e.g. disable all interfaces currently i= n alarm states)
=A0 - it potentially allows one to talk about locks and granularity in mor= e reasonable
=A0 =A0 terms


Nice list. =A0The 3rd bullet is one of= the things in HTTP that I like the most.
The separation of heade= rs and message body (meta-data and data)
is much cleaner than any= thing=A0we have in NM protocols.

Not only does it allow for reusable headers that do &qu= ot;the same thing"
across many media types, it makes it easy= to extend the set of operators
independently of the base protoco= l or the data model.=A0


This separation was one of the things CMIP got right, and SNMP got perhaps<= br> half right, though I fear mentioning that might endanger it here.

What might seem like a downside (but really isn't) is that it forces th= e protocol
design to acknowledge at least the gestalt of the naming architecture.
<= /blockquote>

The thing we need the most is a unified nam= ing architecture.
The protocols and APIs can be tuned for differe= nt use-cases,
but the data needs to be "glued together" somehow by the app= s,
(e.g. CLI, WEBui, REST-API, SNMP. NETCONF., syslog)
=
=A0
Imposing those constraints is actually a good thing, because it makes it possible, even necessary to forbid the really pathological architectures a = priori.

Randy


Andy
=A0
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--e89a8f22bfb13e6e6004c25d8f1e-- From lhotka@nic.cz Wed Jun 13 10:17: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 4ABA121F8643 for ; Wed, 13 Jun 2012 10:17:19 -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 KPH5O2-621ia for ; Wed, 13 Jun 2012 10:17: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 9617621F863F for ; Wed, 13 Jun 2012 10:17:18 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id D73B713F63E; Wed, 13 Jun 2012 19:17:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339607837; bh=xVYFe8xMa2g1T/Iw68EUkCxbmD5hBDXxlIolJ4PihLk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QjeoVMIjbOYZfXnYucZilsd+5DsfhNgqHK6MApGUli+oCHtd4NGeJs8gVZVn+pE/Y l5s1tARUUJ2hkzOuOy1gp2PVNemgBBlFRJnzmjQGMzP4ZlWX6vuz2e29sJINpmHSBN 8M00bKPSLld4fvdnclxbvEqn6T/hj5fzTFdDPxgI= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: Date: Wed, 13 Jun 2012 19:17:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:17:19 -0000 On Jun 13, 2012, at 6:48 PM, Andy Bierman wrote: > > I'm biased, but I think YANG-API addresses many of the issues Everyone here is biased. :-) > that cause NETCONF to be rejected as a solution by application > developers. I don't think these people share the same requirements > and toolsets as traditional NMS developers. Each group needs > their own API. The traditional NMS group is covered with NETCONF 1.1. >=20 > I don't think configuration of a constrained device should use the = same > hammer as a router. Making the hammer smaller only works to a point. Well, a multi-core DNS server cannot be classified as a constrained = device. I don't think a RESTful API is a priori more primitive or = technically inferior compared to NETCONF. =20 >=20 > Stateless RESTful operations encoded in JSON can be much less > heavyweight than NETCONF. I think YANG-API scales from very > small devices to huge routers with multiple candidates. Yes, I like it. Perhaps it makes more sense to develop this approach = instead of fighting around NETCONF 2.0. Lada =20 > >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From calle@tail-f.com Wed Jun 13 10:20:24 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 0EFB611E809A for ; Wed, 13 Jun 2012 10:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, 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 dD7wkW4rnW6p for ; Wed, 13 Jun 2012 10:20:23 -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 CD3A811E8098 for ; Wed, 13 Jun 2012 10:20:22 -0700 (PDT) Received: from [192.168.1.162] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id A792C1200DB3; Wed, 13 Jun 2012 19:20:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: Date: Wed, 13 Jun 2012 19:20:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:20:24 -0000 On Jun 13, 2012, at 18:49 PM, Ladislav Lhotka wrote: >=20 > On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote: >=20 >>=20 >> On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: >>=20 >>>=20 >>> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: >>>=20 >>>> I think NETCONF-Light is a better name and capability than "NETCONF = 1.2". >>>> The false appearance of a protocol update would completely confuse = the market place. >>>> I strongly object to calling the work NETCONF 1.2 since it is not = an upgrade >>>> I also think many of the WG members do not understand what makes >>>> a NETCONF server heavyweight or not (e.g., getting rid of global = >>>> but keeping full-blown XML encoding). >>>=20 >>> Earlier today I heard a presentation of a guy who actively develops = BIND 10. Guess what - the wrote something quite similar to NETCONF based = on JSON. They did evaluate NETCONF but rejected it. >>=20 >> I could tell you many stories where people reviewed and rejected = NETCONF since it didn't meet their requirements. So; why (based on which = criteria) did they reject NETCONF? Would they have done otherwise if we = had a "NETCONF 2.0" now? >=20 > Probably not, their "configuration manager" (we would call it server) = uses RESTful API and JSON. So how does this contribute to our understanding of the criticality of = the perceived shortcomings in NETCONF (and YANG)? I know about people that use XMPP for configuration, does this mean = that REST needs to be fixed because they didn't use that? -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From andy@yumaworks.com Wed Jun 13 10:40: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 20E8D21F8674 for ; Wed, 13 Jun 2012 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hGzN0n+K-jrl for ; Wed, 13 Jun 2012 10:40:08 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6092721F851A for ; Wed, 13 Jun 2012 10:40:07 -0700 (PDT) Received: by lagv3 with SMTP id v3so681215lag.31 for ; Wed, 13 Jun 2012 10:40:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=DR24wjMQ7cZQ57mPNw82b9o653nbtx0YdfWXHQi0GFY=; b=bExh8wNjvqYWhg1iUd7MpFsHzN23qVc3vrJIBtAdTL1tsb8LDqL+dwC5ou3HXB+qqt kKo/Cy57W+BfGER9/jeNkQBaFjPUqNCaOGV8hSgI/mf/giw+Xc6Kme7QqnCpr8AIoexd 0i2UbTfj/NWJd1sRC+xkKFU4PYArIaUSnCOoazSHwTCTV3Ry1qwXAFIatnlm1mrmGQzc TENGl1x8RPq0jeFzMO2D5byvuXiBSRQsI2BxvpY5Q/+2cVrrliwkAiXZ//OVktlYGOTJ WXVtLtTly/C87b3uVImL/ESnQ11moWJb5U1KRm5sEbQMYI4L2qwETrKCqDg594x59hSZ RN2A== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr5271681lab.29.1339609206228; Wed, 13 Jun 2012 10:40:06 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Wed, 13 Jun 2012 10:40:06 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> Date: Wed, 13 Jun 2012 10:40:06 -0700 Message-ID: From: Andy Bierman To: Carl Moberg Content-Type: multipart/alternative; boundary=f46d04088ef5e005ad04c25e1219 X-Gm-Message-State: ALoCoQn63NLxpLXzX9eu7d1vrvvh4aooiUQe6DD1/NvE3NuP/5mYZ4RrWR3aI+H+7kzE7USMEmMc Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:40:09 -0000 --f46d04088ef5e005ad04c25e1219 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 13, 2012 at 10:20 AM, Carl Moberg wrote: > > On Jun 13, 2012, at 18:49 PM, Ladislav Lhotka wrote: > > > > > On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote: > > > >> > >> On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: > >> > >>> > >>> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: > >>> > >>>> I think NETCONF-Light is a better name and capability than "NETCONF > 1.2". > >>>> The false appearance of a protocol update would completely confuse > the market place. > >>>> I strongly object to calling the work NETCONF 1.2 since it is not an > upgrade > >>>> I also think many of the WG members do not understand what makes > >>>> a NETCONF server heavyweight or not (e.g., getting rid of global > > >>>> but keeping full-blown XML encoding). > >>> > >>> Earlier today I heard a presentation of a guy who actively develops > BIND 10. Guess what - the wrote something quite similar to NETCONF based on > JSON. They did evaluate NETCONF but rejected it. > >> > >> I could tell you many stories where people reviewed and rejected > NETCONF since it didn't meet their requirements. So; why (based on which > criteria) did they reject NETCONF? Would they have done otherwise if we had > a "NETCONF 2.0" now? > > > > Probably not, their "configuration manager" (we would call it server) > uses RESTful API and JSON. > > So how does this contribute to our understanding of the criticality of > the perceived shortcomings in NETCONF (and YANG)? > > I know about people that use XMPP for configuration, does this mean that > REST needs to be fixed because they didn't use that? > > http://dnsccm.org/ Here is a project that is using NETCONF/YANG to configure DNS. I don't think 1-size-fits-all is realistic. Different tools supporting different protocols leads to multiple ways to do the same thing. It solves the "can't get there from here" problem though. -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ > > Andy --f46d04088ef5e005ad04c25e1219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 13, 2012 at 10:20 AM, Carl M= oberg <calle@tail-f.com> wrote:

On Jun 13, 2012, at 18:49 PM, Ladislav Lhotka wrote:

>
> On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote:
>
>>
>> On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote:
>>
>>>
>>> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote:
>>>
>>>> I think NETCONF-Light is a better name and capability than= "NETCONF 1.2".
>>>> The false appearance of a protocol update would completely= confuse the market place.
>>>> I strongly object to calling the work NETCONF 1.2 since it= is not an upgrade
>>>> I also think many of the WG members do not understand what= makes
>>>> a NETCONF server heavyweight or not (e.g., getting rid of = global <lock>
>>>> but keeping full-blown XML encoding).
>>>
>>> Earlier today I heard a presentation of a guy who actively dev= elops BIND 10. Guess what - the wrote something quite similar to NETCONF ba= sed on JSON. They did evaluate NETCONF but rejected it.
>>
>> I could tell you many stories where people reviewed and rejected N= ETCONF since it didn't meet their requirements. So; why (based on which= criteria) did they reject NETCONF? Would they have done otherwise if we ha= d a "NETCONF 2.0" now?
>
> Probably not, their "configuration manager" (we would call i= t server) uses RESTful API and JSON.

=A0So how does this contribute to our understanding of the criticality of t= he perceived shortcomings in NETCONF (and YANG)?

=A0I know about people that use XMPP for configuration, does this mean that= REST needs to be fixed because they didn't use that?



Here is a project that is using NE= TCONF/YANG to configure DNS.
I don't think 1-size-fits-all is= realistic. =A0Different tools supporting
different protocols leads to multiple ways to do the same thing.
=
It solves the "can't get there from here" problem though= .



--
Carl Moberg, Tail-f Systems
mailto:calle@tail-f.com
twitter: @cmoberg
http://www.tail-f.com/=


Andy

--f46d04088ef5e005ad04c25e1219-- From lhotka@nic.cz Wed Jun 13 10:56: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 AE39021F861F for ; Wed, 13 Jun 2012 10:56:26 -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=[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 hHZSioA2k1lS for ; Wed, 13 Jun 2012 10:56:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8E21F85A4 for ; Wed, 13 Jun 2012 10:56:26 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 195BF13F63E; Wed, 13 Jun 2012 19:56:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339610185; bh=ZFboeyyVr01rkHz1zrcVpOImSW8xDsXF+MwoJFsQdSo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HmFC1/zrOgbI0bYbGDvLUhogLl45spIvUbU4klFFRCJlVyroYEO1LwQ8poNWo3bNu a4cJn8leVqnDpPVLkEYU+VxtRTVdTBIa4bD3ho8vjlmFnpaxBInfaP4BkzN5uWEOCQ dN5wxWuM1tUDXoQqyPN/sOA+nt3ciS38YgV6eIqg= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Wed, 13 Jun 2012 19:56:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> To: Carl Moberg X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:56:26 -0000 On Jun 13, 2012, at 7:20 PM, Carl Moberg wrote: >=20 > On Jun 13, 2012, at 18:49 PM, Ladislav Lhotka wrote: >=20 >>=20 >> On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote: >>=20 >>>=20 >>> On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: >>>=20 >>>>=20 >>>> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: >>>>=20 >>>>> I think NETCONF-Light is a better name and capability than = "NETCONF 1.2". >>>>> The false appearance of a protocol update would completely confuse = the market place. >>>>> I strongly object to calling the work NETCONF 1.2 since it is not = an upgrade >>>>> I also think many of the WG members do not understand what makes >>>>> a NETCONF server heavyweight or not (e.g., getting rid of global = >>>>> but keeping full-blown XML encoding). >>>>=20 >>>> Earlier today I heard a presentation of a guy who actively develops = BIND 10. Guess what - the wrote something quite similar to NETCONF based = on JSON. They did evaluate NETCONF but rejected it. >>>=20 >>> I could tell you many stories where people reviewed and rejected = NETCONF since it didn't meet their requirements. So; why (based on which = criteria) did they reject NETCONF? Would they have done otherwise if we = had a "NETCONF 2.0" now? >>=20 >> Probably not, their "configuration manager" (we would call it server) = uses RESTful API and JSON. >=20 > So how does this contribute to our understanding of the criticality of = the perceived shortcomings in NETCONF (and YANG)? It contributes to my understanding that NETCONF isn't a terribly = attractive option for an average developer these days. >=20 > I know about people that use XMPP for configuration, does this mean = that REST needs to be fixed because they didn't use that? XMPP is only a message layer, so we'd need to see their application = protocol. Sure, REST is a trendy word, but it is also condensed = experience of almost twenty years of web application programming, so I = don't think it can be labelled as just another hype. Lada >=20 > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Jun 13 11:41: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 0417511E8086 for ; Wed, 13 Jun 2012 11:41:57 -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=[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 5BGzUjg9joUS for ; Wed, 13 Jun 2012 11:41:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA2E11E8083 for ; Wed, 13 Jun 2012 11:41:54 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 5B8DB13F63E for ; Wed, 13 Jun 2012 20:41:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339612912; bh=bKNXshQWosKcrA6usMi+BlCi0QScBdkcOogHU3GuYjc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Eew2KIa9bT+IKg/8Ftp47S9uXRuvIxwQdwTDjP5SsKRKAibvaLfIotTQcTLcHuZuZ wpsq3cyX+KW6hEyX8NSOcLMwhsqRcMq56a4fPJEXI1potmDglgHRQJhAMoh4TKsImD t6rYxIbyWT8z6feDhtjqrubvqOTefl/GLpH05xdk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Ladislav Lhotka In-Reply-To: <908FC529-4601-4EBB-B972-35A605C5C643@tail-f.com> Date: Wed, 13 Jun 2012 20:41:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <908FC529-4601-4EBB-B972-35A605C5C643@tail-f.com> To: Netconf X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:41:57 -0000 On Jun 13, 2012, at 8:08 PM, Carl Moberg wrote: >=20 >=20 >=20 >=20 > On 13 jun 2012, at 19:56, Ladislav Lhotka wrote: >=20 >>=20 >> On Jun 13, 2012, at 7:20 PM, Carl Moberg wrote: >>=20 >>>=20 >>> On Jun 13, 2012, at 18:49 PM, Ladislav Lhotka wrote: >>>=20 >>>>=20 >>>> On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote: >>>>=20 >>>>>=20 >>>>> On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: >>>>>=20 >>>>>>=20 >>>>>> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: >>>>>>=20 >>>>>>> I think NETCONF-Light is a better name and capability than = "NETCONF 1.2". >>>>>>> The false appearance of a protocol update would completely = confuse the market place. >>>>>>> I strongly object to calling the work NETCONF 1.2 since it is = not an upgrade >>>>>>> I also think many of the WG members do not understand what makes >>>>>>> a NETCONF server heavyweight or not (e.g., getting rid of global = >>>>>>> but keeping full-blown XML encoding). >>>>>>=20 >>>>>> Earlier today I heard a presentation of a guy who actively = develops BIND 10. Guess what - the wrote something quite similar to = NETCONF based on JSON. They did evaluate NETCONF but rejected it. >>>>>=20 >>>>> I could tell you many stories where people reviewed and rejected = NETCONF since it didn't meet their requirements. So; why (based on which = criteria) did they reject NETCONF? Would they have done otherwise if we = had a "NETCONF 2.0" now? >>>>=20 >>>> Probably not, their "configuration manager" (we would call it = server) uses RESTful API and JSON. >>>=20 >>> So how does this contribute to our understanding of the criticality = of the perceived shortcomings in NETCONF (and YANG)? >>=20 >> It contributes to my understanding that NETCONF isn't a terribly = attractive option for an average developer these days. >=20 > In order to try and avoid going around one more time: what was the = reasons for NOT using NETCONF in the example that you're presenting? = Without knowing that I think it's hard to move the doscussion forward, = no? I don't really know the whole story, for sure XML was one of the reasons = against NETCONF. >=20 >>>=20 >>> I know about people that use XMPP for configuration, does this mean = that REST needs to be fixed because they didn't use that? >>=20 >> XMPP is only a message layer, so we'd need to see their application = protocol. Sure, REST is a trendy word, but it is also condensed = experience of almost twenty years of web application programming, so I = don't think it can be labelled as just another hype. >=20 > Ok, my point was that inferring that "X is broken because a group of = people went for Y instead" is less useful unless we know the selection = criteria. I never said that. Thing is, developers prefer to use technologies they = already know and NETCONF is an obscure and relatively complex stuff for = them. Who wants to investigate the hairy details of if the = familiar HTTP methods work just fine? Keep it simple, stupid. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Wed Jun 13 13:23: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 DC0E821F8478 for ; Wed, 13 Jun 2012 13:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 F1iCkYMsux4d for ; Wed, 13 Jun 2012 13:23:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5005D21F846D for ; Wed, 13 Jun 2012 13:23:21 -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 q5DGsANg006863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jun 2012 18:54:10 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5DGs7eu018624; Wed, 13 Jun 2012 18:54:10 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 18:54:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 18:54:07 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403E538C9@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] we are NOT CONVERGING towards consensus Thread-Index: Ac1JXKUnuHGFreBWTd6oxUQxjGc38AACALyQAAgCz4A= References: <4FD84B4A.9000907@ripe.net><84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz><4FD85B48.2070700@tail-f.com><933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz><4FD870F9.7000608@tail-f.com><4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "Bert Wijnen" , "Netconf" X-OriginalArrivalTime: 13 Jun 2012 16:54:09.0419 (UTC) FILETIME=[26CEFDB0:01CD4985] 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: 5191 X-purgate-ID: 151667::1339606450-00003CDD-39A13D4C/0-0/0-0 Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:23:23 -0000 Hi All, speaking as an individual. I support the idea to provide a modular version of Netconf to enable the implementers to choose the capabilities they would like to implement. Let's call it Netconf 1.2 as Netconf 2.0 associates with substantial changes nobody wants to have right now. I also support the proposal that the WG should decide on the minimal set of mandatory features where my impression was actually that we are converging. I agree with Bert and Dan that providing a Netconf 1.2 does not necessarily cause any issue with the backward compatibility. If a Netconf 1.2 implementation aims to be compatible with Netconf 1.1 and 1.0 this can be achieved. I believe that a modular Netconf can be useful for different deployment scenarios including the implementation for those devices with less memory and resources.=20 I also think that we should avoid a competing standard with Netconf-Light as a standard track document. The modularity Netconf-Light is proposing can be integrated into the Netconf 1.2 specification. However, it is clear that this version of Netconf does not aim to and cannot solve the issue of the management of constrained devices in general. Instead of opening a new and huge construction site I am in favor of defining a focused and concrete work which can be completed soon. Those who discuss on the coma maillist will most likely need more time to define the work items addressing all management needs for the constrained devices and the resource constrained networks. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Romascanu, Dan (Dan) > Sent: Wednesday, June 13, 2012 3:06 PM > To: Bert Wijnen; Per Hedeland > Cc: Netconf > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus >=20 >=20 > Hi, >=20 > I am with Bert on this. Backwards compatibility in this context does not > mean to me that any version of an old client must work with any future > version of a server. This would be forwards compatibility :-) Backwards > compatibility means IMO the capability to identify the version of the > protocol run by the server and its capabilities and to be able to manage > what matches the agent version level, and to gracefully ignore and alert > the operator when the protocol interaction is not possible. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Bert Wijnen [mailto:bwijnen@ripe.net] > > Sent: Wednesday, June 13, 2012 3:04 PM > > To: Per Hedeland > > Cc: Romascanu, Dan (Dan); Ladislav Lhotka; Netconf > > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus > > > > On 6/13/12 1:42 PM, Per Hedeland wrote: > > > On 2012-06-13 13:17, Romascanu, Dan (Dan) wrote: > > >> > > >> So, are you saying that NETCONF will never be able to be > modularized > > in > > >> such a way that it can be used as a solution for managing devices > > with > > >> restrained resources? > > > > > > No, I'm mainly objecting to the use of "backwards compatible" to > > > describe changes that clearly aren't. Obviously non-backwards- > > compatible > > > changes are sometimes deemed necessary, or at least better than > other > > > alternatives - it's a trade-off decision like so many others. > > > > > > > I would think that an existing NetConf 1.1 client will check if the > > managed > > device supports NetConf 1.1 If so, it probably keeps using that set of > > capabilities. And so I see no problem. > > > > If a more advanced NetConf 2.0 client check if a managed device does > > NetConf 2.0, and if it does, then it also needs to check if the > > proper capabilities (those that were mandatory in Netconf 1.0 and 1.1) > > are supported by the managed device, and if so... boom we're running. > > If not, the client can try to fallback to NetConf 1.1. > > Is supported .. boom we're running. > > If not supported, then that means a new (constrained) device is being > > managed, and probably there are fewer capabilities than those on > > NetConf 1.1. The client can decide to not support that new > > (constrained) > > device, or it can decide to try to manage it with the lesser set of > > capabilities. > > > > All existing/fielded Netconf 1.0 and 1.1 operational configurations > > should > > continue to work wothout a problem. > > > > Is that not BACKWARD COMPATIBLE ?? > > > > Maybe I do not understand the term at all?? > > > > Bert > > > > > > > > > > > My *opinion*, as already stated, is that making such changes to > > NETCONF > > > would be seriously detrimental to the general "success" of the > > protocol. > > > I don't really have an opinion on whether implementation of the > > > currently mandatory functionality actually is "too hard" for some > > > unspecified class of "constrained" devices, nor whether it would be > a > > > disaster if such devices do "something else" in that case. > > > > > > --Per >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From calle@tail-f.com Wed Jun 13 13:36: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 EC27521F8526 for ; Wed, 13 Jun 2012 13:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, MIME_QP_LONG_LINE=1.396] 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 E49xKPS-PLxZ for ; Wed, 13 Jun 2012 13:36:14 -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 5ED0F21F851C for ; Wed, 13 Jun 2012 13:36:13 -0700 (PDT) Received: from [10.169.209.41] (host-95-199-17-41.mobileonline.telia.com [95.199.17.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C4A71200DB0; Wed, 13 Jun 2012 20:08:09 +0200 (CEST) References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <908FC529-4601-4EBB-B972-35A605C5C643@tail-f.com> X-Mailer: iPhone Mail (9B206) From: Carl Moberg Date: Wed, 13 Jun 2012 20:08:02 +0200 To: Ladislav Lhotka Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:36:15 -0000 On 13 jun 2012, at 19:56, Ladislav Lhotka wrote: >=20 > On Jun 13, 2012, at 7:20 PM, Carl Moberg wrote: >=20 >>=20 >> On Jun 13, 2012, at 18:49 PM, Ladislav Lhotka wrote: >>=20 >>>=20 >>> On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote: >>>=20 >>>>=20 >>>> On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: >>>>=20 >>>>>=20 >>>>> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: >>>>>=20 >>>>>> I think NETCONF-Light is a better name and capability than "NETCONF 1= .2". >>>>>> The false appearance of a protocol update would completely confuse th= e market place. >>>>>> I strongly object to calling the work NETCONF 1.2 since it is not an u= pgrade >>>>>> I also think many of the WG members do not understand what makes >>>>>> a NETCONF server heavyweight or not (e.g., getting rid of global >>>>>> but keeping full-blown XML encoding). >>>>>=20 >>>>> Earlier today I heard a presentation of a guy who actively develops BI= ND 10. Guess what - the wrote something quite similar to NETCONF based on JS= ON. They did evaluate NETCONF but rejected it. >>>>=20 >>>> I could tell you many stories where people reviewed and rejected NETCON= F since it didn't meet their requirements. So; why (based on which criteria)= did they reject NETCONF? Would they have done otherwise if we had a "NETCON= F 2.0" now? >>>=20 >>> Probably not, their "configuration manager" (we would call it server) us= es RESTful API and JSON. >>=20 >> So how does this contribute to our understanding of the criticality of th= e perceived shortcomings in NETCONF (and YANG)? >=20 > It contributes to my understanding that NETCONF isn't a terribly attractiv= e option for an average developer these days. In order to try and avoid going around one more time: what was the reasons f= or NOT using NETCONF in the example that you're presenting? Without knowing t= hat I think it's hard to move the doscussion forward, no? >>=20 >> I know about people that use XMPP for configuration, does this mean that R= EST needs to be fixed because they didn't use that? >=20 > XMPP is only a message layer, so we'd need to see their application protoc= ol. Sure, REST is a trendy word, but it is also condensed experience of almo= st twenty years of web application programming, so I don't think it can be l= abelled as just another hype. Ok, my point was that inferring that "X is broken because a group of people w= ent for Y instead" is less useful unless we know the selection criteria. > Lada >=20 >=20 >>=20 >> -- >> Carl Moberg, Tail-f Systems >> mailto:calle@tail-f.com >> twitter: @cmoberg >> http://www.tail-f.com/ >>=20 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 From mehmet.ersue@nsn.com Wed Jun 13 14:26:07 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 5B23A11E809A for ; Wed, 13 Jun 2012 14:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 7MXuCfOeEgnQ for ; Wed, 13 Jun 2012 14:26:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0F11E8097 for ; Wed, 13 Jun 2012 14:26:05 -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 q5DHVnXf021741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jun 2012 19:31:50 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5DHVn6n012854; Wed, 13 Jun 2012 19:31:49 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 19:31:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 19:31:47 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403E538D5@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Netconf] we are NOT CONVERGING towards consensus Thread-Index: Ac1JXKUnuHGFreBWTd6oxUQxjGc38AACALyQAAgCz4AAAWOkMA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 13 Jun 2012 17:31:49.0793 (UTC) FILETIME=[6A18B110:01CD498A] 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: 5191 X-purgate-ID: 151667::1339608710-0000425E-8B428AB3/0-0/0-0 Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:26:07 -0000 Hi All, speaking as an individual. I support the idea to provide a modular version of Netconf to enable the implementers to choose the capabilities they would like to implement. Let's call it Netconf 1.2 as Netconf 2.0 associates with substantial changes nobody wants to have right now. I also support the proposal that the WG should decide on the minimal set of mandatory features where my impression was actually that we are converging. I agree with Bert and Dan that providing a Netconf 1.2 does not necessarily cause any issue with the backward compatibility. If a Netconf 1.2 implementation aims to be compatible with Netconf 1.1 and 1.0 this can be achieved. I believe that a modular Netconf can be useful for different deployment scenarios including the implementation for those devices with less memory and resources.=20 I also think that we should avoid a competing standard with Netconf-Light as a standard track document. The modularity Netconf-Light is proposing can be integrated into the Netconf 1.2 specification. However, it is clear that this version of Netconf does not aim to and cannot solve the issue of the management of constrained devices in general. Instead of opening a new and huge construction site I am in favor of defining a focused and concrete work which can be completed soon. Those who discuss on the coma maillist will most likely need more time to define the work items addressing all management needs for the constrained devices and the resource constrained networks. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Romascanu, Dan (Dan) > Sent: Wednesday, June 13, 2012 3:06 PM > To: Bert Wijnen; Per Hedeland > Cc: Netconf > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus >=20 >=20 > Hi, >=20 > I am with Bert on this. Backwards compatibility in this context does not > mean to me that any version of an old client must work with any future > version of a server. This would be forwards compatibility :-) Backwards > compatibility means IMO the capability to identify the version of the > protocol run by the server and its capabilities and to be able to manage > what matches the agent version level, and to gracefully ignore and alert > the operator when the protocol interaction is not possible. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Bert Wijnen [mailto:bwijnen@ripe.net] > > Sent: Wednesday, June 13, 2012 3:04 PM > > To: Per Hedeland > > Cc: Romascanu, Dan (Dan); Ladislav Lhotka; Netconf > > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus > > > > On 6/13/12 1:42 PM, Per Hedeland wrote: > > > On 2012-06-13 13:17, Romascanu, Dan (Dan) wrote: > > >> > > >> So, are you saying that NETCONF will never be able to be > modularized > > in > > >> such a way that it can be used as a solution for managing devices > > with > > >> restrained resources? > > > > > > No, I'm mainly objecting to the use of "backwards compatible" to > > > describe changes that clearly aren't. Obviously non-backwards- > > compatible > > > changes are sometimes deemed necessary, or at least better than > other > > > alternatives - it's a trade-off decision like so many others. > > > > > > > I would think that an existing NetConf 1.1 client will check if the > > managed > > device supports NetConf 1.1 If so, it probably keeps using that set of > > capabilities. And so I see no problem. > > > > If a more advanced NetConf 2.0 client check if a managed device does > > NetConf 2.0, and if it does, then it also needs to check if the > > proper capabilities (those that were mandatory in Netconf 1.0 and 1.1) > > are supported by the managed device, and if so... boom we're running. > > If not, the client can try to fallback to NetConf 1.1. > > Is supported .. boom we're running. > > If not supported, then that means a new (constrained) device is being > > managed, and probably there are fewer capabilities than those on > > NetConf 1.1. The client can decide to not support that new > > (constrained) > > device, or it can decide to try to manage it with the lesser set of > > capabilities. > > > > All existing/fielded Netconf 1.0 and 1.1 operational configurations > > should > > continue to work wothout a problem. > > > > Is that not BACKWARD COMPATIBLE ?? > > > > Maybe I do not understand the term at all?? > > > > Bert > > > > > > > > > > > My *opinion*, as already stated, is that making such changes to > > NETCONF > > > would be seriously detrimental to the general "success" of the > > protocol. > > > I don't really have an opinion on whether implementation of the > > > currently mandatory functionality actually is "too hard" for some > > > unspecified class of "constrained" devices, nor whether it would be > a > > > disaster if such devices do "something else" in that case. > > > > > > --Per >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From calle@tail-f.com Wed Jun 13 14:36: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 8898F21F845F for ; Wed, 13 Jun 2012 14:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Z9rXaA-Dco9F for ; Wed, 13 Jun 2012 14:36:44 -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 7862E21F844C for ; Wed, 13 Jun 2012 14:36:44 -0700 (PDT) Received: from [192.168.1.162] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id BC2091200DB2; Wed, 13 Jun 2012 23:36:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: Date: Wed, 13 Jun 2012 23:36:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29C30561-9607-4F67-814C-C9CB310C2FCD@tail-f.com> References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <908FC529-4601-4EBB-B972-35A605C5C643@tail-f.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1278) Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:36:45 -0000 On Jun 13, 2012, at 20:41 PM, Ladislav Lhotka wrote: >=20 > On Jun 13, 2012, at 8:08 PM, Carl Moberg wrote: >=20 >>=20 >>=20 >>=20 >>=20 >> On 13 jun 2012, at 19:56, Ladislav Lhotka wrote: >>=20 >>>=20 >>> On Jun 13, 2012, at 7:20 PM, Carl Moberg wrote: >>>=20 >>>>=20 >>>> On Jun 13, 2012, at 18:49 PM, Ladislav Lhotka wrote: >>>>=20 >>>>>=20 >>>>> On Jun 13, 2012, at 5:23 PM, Carl Moberg wrote: >>>>>=20 >>>>>>=20 >>>>>> On Jun 13, 2012, at 17:02 PM, Ladislav Lhotka wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 13, 2012, at 4:40 PM, Andy Bierman wrote: >>>>>>>=20 >>>>>>>> I think NETCONF-Light is a better name and capability than = "NETCONF 1.2". >>>>>>>> The false appearance of a protocol update would completely = confuse the market place. >>>>>>>> I strongly object to calling the work NETCONF 1.2 since it is = not an upgrade >>>>>>>> I also think many of the WG members do not understand what = makes >>>>>>>> a NETCONF server heavyweight or not (e.g., getting rid of = global >>>>>>>> but keeping full-blown XML encoding). >>>>>>>=20 >>>>>>> Earlier today I heard a presentation of a guy who actively = develops BIND 10. Guess what - the wrote something quite similar to = NETCONF based on JSON. They did evaluate NETCONF but rejected it. >>>>>>=20 >>>>>> I could tell you many stories where people reviewed and rejected = NETCONF since it didn't meet their requirements. So; why (based on which = criteria) did they reject NETCONF? Would they have done otherwise if we = had a "NETCONF 2.0" now? >>>>>=20 >>>>> Probably not, their "configuration manager" (we would call it = server) uses RESTful API and JSON. >>>>=20 >>>> So how does this contribute to our understanding of the criticality = of the perceived shortcomings in NETCONF (and YANG)? >>>=20 >>> It contributes to my understanding that NETCONF isn't a terribly = attractive option for an average developer these days. >>=20 >> In order to try and avoid going around one more time: what was the = reasons for NOT using NETCONF in the example that you're presenting? = Without knowing that I think it's hard to move the doscussion forward, = no? >=20 > I don't really know the whole story, for sure XML was one of the = reasons against NETCONF. I'm getting confused; are you proposing NETCONF move away from XML on = the wire? If not; what is the reasoning behind bringing up the example = in a discussion around NETCONF next steps? >>=20 >>>>=20 >>>> I know about people that use XMPP for configuration, does this mean = that REST needs to be fixed because they didn't use that? >>>=20 >>> XMPP is only a message layer, so we'd need to see their application = protocol. Sure, REST is a trendy word, but it is also condensed = experience of almost twenty years of web application programming, so I = don't think it can be labelled as just another hype. >>=20 >> Ok, my point was that inferring that "X is broken because a group of = people went for Y instead" is less useful unless we know the selection = criteria. >=20 > I never said that. Thing is, developers prefer to use technologies = they already know and NETCONF is an obscure and relatively complex stuff = for them. Who wants to investigate the hairy details of if = the familiar HTTP methods work just fine? Keep it simple, stupid. This one is easy: the ones that buy into the many features of NETCONF = that provides benefits well above and beyond the alternatives (including = SNMP, SOAP, and REST)! If you don't think NETCONF provides tangible = benefits over the alternatives; then don't use it. -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From alex@cisco.com Wed Jun 13 18:38: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 25C5721F8554 for ; Wed, 13 Jun 2012 18:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+22haSwwIKw for ; Wed, 13 Jun 2012 18:38:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 215BE21F8552 for ; Wed, 13 Jun 2012 18:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=5135; q=dns/txt; s=iport; t=1339637880; x=1340847480; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=foXW5n4zNesEFqPihrXacYpcwvLMnu2wXVuZIX+vKkI=; b=D7PRLRo9ojYv1bA+1hvTqbLdkJONgGtphOEqrjpHx+fl2RtyHJ00B+px tXfkno6YjlHvw7isIXkxRkIlU9zT7a/7vWn+fmt+9uJOurhSt+dg47Slf 6g0Q7mnG6Qmt8LikjFDInckFRZk+qyHAyESwLpeOfbtenuMzSLOWR4Ywq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAN4/2U+rRDoJ/2dsb2JhbAA8CbVBgQeCGAEBAQMBAQEBDwEdCjQLBQcEAgEIEQQBAQEKBhMEAQYBJh8JCAEBBAESCBqHZAQBC5o+oAmLMBGFIGADiEGadoFmgwA X-IronPort-AV: E=Sophos;i="4.75,768,1330905600"; d="scan'208";a="45762247" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 14 Jun 2012 01:37:59 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5E1bxVv008608; Thu, 14 Jun 2012 01:37:59 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 18:37:59 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {D42E295E-2D01-49DB-A135-E814D7A1C61B} x-cr-hashedpuzzle: CKEl FBT6 H0nq JDPu KEjz OrQq SKvf SpwK VNDn V6yS WZ82 W4Iu ZsXF aNsm hzsx jM80; 3; YwBhAGwAbABlAEAAdABhAGkAbAAtAGYALgBjAG8AbQA7AGwAaABvAHQAawBhAEAAbgBpAGMALgBjAHoAOwBuAGUAdABjAG8AbgBmAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D42E295E-2D01-49DB-A135-E814D7A1C61B}; YQBsAGUAeABAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 14 Jun 2012 01:37:52 GMT; UgBFADoAIABbAE4AZQB0AGMAbwBuAGYAXQAgAFcARwAgAEMAbwBuAHMAZQBuAHMAdQBzACAAYwBhAGwAbAA6ACAATgBlAHQAYwBvAG4AZgAgADIALgAwAD8AIABbAHcAYQBzADoAIABUAHIAeQBpAG4AZwAgAGEAYwBvAG4AcwBlAG4AcwB1AHMAIABvAG4AIAB0AGgAZQAgAHcAYQB5ACAAZgBvAHIAdwBhAHIAZAB3AGkAdABoAE4AZQB0AGMAbwBuAGYALQBMAGkAZwBoAHQAXQA= Content-class: urn:content-classes:message Date: Wed, 13 Jun 2012 18:37:52 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC8884B@xmb-sjc-239.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] Thread-Index: Ac1JRLjIBGcGPe2TQUaBM9n0RQxkbAAh9umA References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8821B@xmb-sjc-239.amer.cisco.com> From: "Alexander Clemm (alex)" To: "Ladislav Lhotka" , "Carl Moberg" X-OriginalArrivalTime: 14 Jun 2012 01:37:59.0560 (UTC) FILETIME=[54A1E880:01CD49CE] Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus 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, 14 Jun 2012 01:38:01 -0000 Hi, here is one example: The definition of identity allows to specify a base identity, allowing to build an "identity hierarchy". However, if I subsequently want to specify a condition or a constraint that pertains to all identities that were derived from the same base identity, I need to enumerate every single one of the identities. This makes the definition of the condition/constraint unnecessarily complex. Even worse, every time I introduce a new identity that is derived from the same base identity, I need to update the conditions/constraints which may have been defined in an entirely different place. This basically also defeats the purpose of using identities, instead of enums, to allow for extending a set of enumerated values without having to revise the original definition. =20 For example, think of the following identity hierarchy: flow +-- audioflow +-- pandora +-- rhapsody +-- spotify +-- ... =20 If I have a constraint that pertains to audioflows, I need to enumerate a long list of subidentities instead of the single base identity, and need to update that constraint whenever a new identity that identifies a new audioflow is introduced. =20 (Maybe this part of the thread actually belongs on the netmod mailer, not netconf) --- Alex -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Wednesday, June 13, 2012 2:13 AM To: Alexander Clemm (alex); Carl Moberg Cc: Netconf Subject: RE: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] "Alexander Clemm (alex)" writes: > Just my 2 cents, one aspect that seems a bit clumsy in YANG concerns the > specification of conditions and constraints. While it is certainly > possible to argue that it does the job, it is fairly hard to use. If it Could you be more specific? What is exactly hard? Is it that, for example, one needs to carefully count the number of double dots in order to get to a remote node? Or missing semantics? > is hard to use, things might be left up to implementations while they > really should be captured in the spec. It might be worthwhile to > consider possible alternatives to the current scheme, such as being able > to refer to a more "procedural" way to refer to constraints, rather than > the declarative way it is now. We have been discussing the addition of several new XPath functions, but mainly for supporting special YANG data types, so nothing really procedural. Can you give some examples? Thanks, Lada =20 > --- Alex > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Carl Moberg > Sent: Tuesday, June 12, 2012 6:52 AM > To: Ladislav Lhotka > Cc: Netconf > Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying > aconsensus on the way forwardwithNetconf-Light] > > > On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: > >> Carl Moberg writes: >>> For the record; I don't actually see any strong suggestions that > there are any features that are "too heavy-weight, clumsy or broken" in > NETCONF or YANG. At least I have never heard that type of feedback from > the implementations that we've been working with. Sure, there are issues > and challenges with implementing server-side NETCONF (and YANG) > particularly around retrofitting it on top of existing software > infrastructure, but I have no experience that there are show stopping > aspects to it that must be fixed. >>=20 >> OK, let me mention one thing: the design of is wrong. A > standard approach would be to have one expression for locating the node > to be updated and another one for specifying the changes. This is how it > is done e.g. in XQuery Update or in databases. attempts to > do both steps in one shot which doesn't really work all that great. > While this may not be a showstopper, it certainly causes problems - cf. > the parallel discussion in the NETMOD list regarding keys for route > lists. With a separate locator expression, the NETCONF client wouldn't > have to care about list keys all that much and just use any appropriate > attributes for selecting a list entry. > > > > I agree that it's not perfect. It's about as good/bad as some other > protocols (e.g. SNMP). But the point that I come back to is that it's > certainly good enough (even with that imperfection and others) that it > has the potential to radically improve the way we do configuration > management in networks. Making it a moving target instead of widely > applying what we have would be a case of over optimization IMHO. > > Now, this looks like one dead horse :-) > > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Thu Jun 14 02:16:24 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 9052F21F8679 for ; Thu, 14 Jun 2012 02:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF8oSDaZev1O for ; Thu, 14 Jun 2012 02:16:24 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id D185121F866D for ; Thu, 14 Jun 2012 02:16:23 -0700 (PDT) Received: from mail46-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 09:15:16 +0000 Received: from mail46-va3 (localhost [127.0.0.1]) by mail46-va3-R.bigfish.com (Postfix) with ESMTP id 1951330040A; Thu, 14 Jun 2012 09:15:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT007.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I542M1432I1418I4015Izz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail46-va3 (localhost.localdomain [127.0.0.1]) by mail46-va3 (MessageSwitch) id 1339665313879100_16858; Thu, 14 Jun 2012 09:15:13 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.242]) by mail46-va3.bigfish.com (Postfix) with ESMTP id C9A992A0048; Thu, 14 Jun 2012 09:15:13 +0000 (UTC) Received: from DB3PRD0702HT007.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 09:15:12 +0000 Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by pod51017.outlook.com (10.3.4.168) with Microsoft SMTP Server (TLS) id 14.15.74.2; Thu, 14 Jun 2012 09:16:13 +0000 Message-ID: <02f001cd4a0d$e417aec0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> Date: Thu, 14 Jun 2012 10:12:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.244.213] X-OriginatorOrg: btconnect.com Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 09:16:24 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Phil Shafer" Cc: "Netconf" Sent: Monday, June 11, 2012 2:28 PM > > On Jun 11, 2012, at 2:48 PM, Phil Shafer wrote: > > > "Bert Wijnen \(IETF\)" writes: > >> Please express your support or objections w.r.t. to this > >> proposal. Pls do so asap, but in any event, no later than > >> June 20th 2012 (any timezone) > > > > I object to any "2.0" efforts. We have a new set of technologies > > that need some development, field testing, and experience. Revisiting > > them for a "2.0" effort before the paint is dry on the "1.0" will > > be detrimental efforts to gain mindshare. > > I don't know whether the paint is dry on IPv6 but RFC 6434 recently introduced relatively significant changes in terms of what is required from an IPv6 node. For instance, IPSec used to be a MUST, now it is a SHOULD - simply because almost nobody bothered to implement it but still claimed to have a standard IPv6 implementation. I think that IPv6 is the poster child on how not to introduce a new flavour of a protocol. It is too complex and it is always being meddled with for what seems like no other reason that the instigators have little better else to do while waiting to see if anyone adopts it. In answer to Bert's other thread, Yes. There should be a lighter weight version of Netconf that makes chunks optional but changes nothing - 'improving' the edit capabilities is the sort of death by meddling that afflicts IPv6. As pointed out elsewhere, calling it 2.0 will put people off - new major versions imply large, incompatible changes. Whether it is possible to come up with an agreed lighter weight version I am unsure about, the only way to find out is to try. (Using my older workstation, I struggle with some websites and believe that it is the insane complexity of the scripts that render them unusable, but doubt if I will ever see an HTML option to cut down on script processing:-( Tom Petch > > Apparently, NETCONF also has a few features that are too heavy-weight, clumsy or broken. There is already a decent amount of operational experience and I believe it is time - after about ten years - to adjust NETCONF to the current reality, which actually also includes YANG. > > Lada > > > > > Thanks, > > Phil From per@tail-f.com Thu Jun 14 03:54: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 BE14121F865D for ; Thu, 14 Jun 2012 03:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.200, 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 XFzxXlZw-OXO for ; Thu, 14 Jun 2012 03:54:48 -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 3E50621F8562 for ; Thu, 14 Jun 2012 03:54:48 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E6BE1200DBB; Thu, 14 Jun 2012 12:54:47 +0200 (CEST) Message-ID: <4FD9C2F6.9090105@tail-f.com> Date: Thu, 14 Jun 2012 12:54:46 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bert Wijnen References: <4FD84B4A.9000907@ripe.net><84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz><4FD85B48.2070700@tail-f.com><933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> <4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> In-Reply-To: <4FD881B4.4040704@ripe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 10:54:48 -0000 On 2012-06-13 14:04, Bert Wijnen wrote: > > I would think that an existing NetConf 1.1 client will check if the managed > device supports NetConf 1.1 If so, it probably keeps using that set of > capabilities. And so I see no problem. > > If a more advanced NetConf 2.0 client check if a managed device does > NetConf 2.0, and if it does, then it also needs to check if the > proper capabilities (those that were mandatory in Netconf 1.0 and 1.1) > are supported by the managed device, and if so... boom we're running. [snip] > All existing/fielded Netconf 1.0 and 1.1 operational configurations should > continue to work wothout a problem. > > Is that not BACKWARD COMPATIBLE ?? I guess the problem is that we are throwing around the term without saying what is backward compatible with what. What you are saying is basically that if a server supporting 1.1 is (unlikely or not) upgraded to also support 2.0, that is a backwards compatible change. And I of course agree with that - but it doesn't mean that 2.0 is backwards compatible with 1.1. Maybe there is some point in making the statement "2.0 is a backwards compatible change to the protocol" even though 2.0 *isn't* backward compatible with any earlier version - but then it basically only means that there is a well-defined way for a 1.1-only client to find out that it is unable to interoperate with a 2.0-only server. The only way you could make a *non* backwards compatible change would be to fail to bump the version number when you should have, which IMO should be called "broken" or "bug". Thus I find the statement at best meaningless, at worst misleading. --Per From andy@yumaworks.com Thu Jun 14 06:33: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 D6DF721F864A for ; Thu, 14 Jun 2012 06:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rVZNa6BkgzhH for ; Thu, 14 Jun 2012 06:33:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66FA321F8644 for ; Thu, 14 Jun 2012 06:33:11 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2361908lbb.31 for ; Thu, 14 Jun 2012 06:33:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=n1UhDm3spGV4n6YWgX5GwVkWvF1UbhNyE0NGE5w0oX0=; b=G2ihGsCMqTH4uaAW123FBRcN0hXvYJJDlRk6PU70PVK1L5da8jxI3OS9UtNCBYBnJy eXTEeUHT3fFjnAfusOc/wtzxqVJdrjYtGpw8myyvzJTfl+ZoVoZeyYoaGLP860NxAAef L3QkwUHD/9ii7IgxTAvzUPiN67RkZ/4N3dZjjqPBI+tPKwcdgNkNVVNgrzMT4fa7Rtop dTVWn9tRb6q+mnSGrVN45ip6PmX1XqJVEVZBhGvGDXkGkRE057vilfRnfvyOSXwYuSHe OWdCK1lgoABCq8Nh1H0ud/V5xmpxorrnyEIVrSZlcsB73shooItCKPo1Mc475jdHXacC La0g== MIME-Version: 1.0 Received: by 10.152.103.109 with SMTP id fv13mr1922500lab.33.1339680790077; Thu, 14 Jun 2012 06:33:10 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Thu, 14 Jun 2012 06:33:09 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <4FD9C2F6.9090105@tail-f.com> References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> <4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> <4FD9C2F6.9090105@tail-f.com> Date: Thu, 14 Jun 2012 06:33:09 -0700 Message-ID: From: Andy Bierman To: Per Hedeland Content-Type: multipart/alternative; boundary=f46d040890c79ae17004c26ebd6a X-Gm-Message-State: ALoCoQkyeSZn8hLMjyKNT4SQDh/FmMNn0u93VFPpEnh49sqWf5ZHNJnAwarz/RrXorsLm2hRDQeO Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:33:13 -0000 --f46d040890c79ae17004c26ebd6a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 14, 2012 at 3:54 AM, Per Hedeland wrote: > On 2012-06-13 14:04, Bert Wijnen wrote: > > > > I would think that an existing NetConf 1.1 client will check if the > managed > > device supports NetConf 1.1 If so, it probably keeps using that set of > > capabilities. And so I see no problem. > > > > If a more advanced NetConf 2.0 client check if a managed device does > > NetConf 2.0, and if it does, then it also needs to check if the > > proper capabilities (those that were mandatory in Netconf 1.0 and 1.1) > > are supported by the managed device, and if so... boom we're running. > [snip] > > All existing/fielded Netconf 1.0 and 1.1 operational configurations > should > > continue to work wothout a problem. > > > > Is that not BACKWARD COMPATIBLE ?? > > I guess the problem is that we are throwing around the term without > saying what is backward compatible with what. What you are saying is > basically that if a server supporting 1.1 is (unlikely or not) upgraded > to also support 2.0, that is a backwards compatible change. And I of > course agree with that - but it doesn't mean that 2.0 is backwards > compatible with 1.1. > > The end result of NETCONF-Light would be that the "base:1.1" capability string gets replaced by N different capability strings. A server which conforms to base:1.1 will be able to send both base:1.1 and all the new capability strings as well. For a server that already implements base:1.1, the "new" protocol will be a step backwards -- it does the same thing as before but just takes more bytes on the wire to do it. The the only way NETCONF Light can be backward compatible with existing clients is to advertise base:1.0 or base:1.1. If it could do that, then it wouldn't need NETCONF Light. The theory is that the client developers will rewrite their code so instead of sending a request and getting back an 'operation-not-supported' error, the app can use the capabilities, and print that error message without sending a request. NETCONF Light is not intended to be backward-compatible. It is intended to be implemented by new servers that cannot advertise base 1.0 or base:1.1 for whatever reason. Whether the application business logic still works after taking away significant CM functionality seems to be a secondary issue to some, but to me it is the most important factor. > Maybe there is some point in making the statement "2.0 is a backwards > compatible change to the protocol" even though 2.0 *isn't* backward > compatible with any earlier version - but then it basically only means > that there is a well-defined way for a 1.1-only client to find out that > it is unable to interoperate with a 2.0-only server. The only way you > could make a *non* backwards compatible change would be to fail to bump > the version number when you should have, which IMO should be called > "broken" or "bug". Thus I find the statement at best meaningless, at > worst misleading. > > I strongly oppose the name NETCONF 1.2 because it is not an upgrade. The capability (and draft) is called NETCONF Light. I don't understand how that morphed into NETCONF 1.2. > --Per > Andy --f46d040890c79ae17004c26ebd6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 14, 2012 at 3:54 AM, Per Hed= eland <per@tail-f.com> wrote:
On 2012-06-13 14:04, Bert Wijnen wrote:
>
> I would think that an existing NetConf 1.1 client will check if the ma= naged
> device supports NetConf 1.1 If so, it probably keeps using that set of=
> capabilities. And so I see no problem.
>
> If a more advanced NetConf 2.0 client check if a managed device does > NetConf 2.0, and if it does, then it also needs to check if the
> proper capabilities (those that were mandatory in Netconf 1.0 and 1.1)=
> are supported by the managed device, and if so... boom we're runni= ng.
[snip]
> All existing/fielded Netconf 1.0 and 1.1 operational configurations sh= ould
> continue to work wothout a problem.
>
> Is that not BACKWARD COMPATIBLE ??

I guess the problem is that we are throwing around the term without
saying what is backward compatible with what. What you are saying is
basically that if a server supporting 1.1 is (unlikely or not) upgraded
to also support 2.0, that is a backwards compatible change. And I of
course agree with that - but it doesn't mean that 2.0 is backwards
compatible with 1.1.


The end result of NETCONF-Light would = be that the "base:1.1" capability
string gets replaced = by N different capability strings.
A server which conforms to bas= e:1.1 will be able to send
both base:1.1 and all the new capability strings as well.
Fo= r a server that already implements base:1.1, the "new" protocol
will be a step backwards -- it does the same thing as before
but just takes more bytes on the wire to do it. =A0The the only way
NETCONF Light can be backward compatible with existing clients
is to advertise base:1.0 or base:1.1. =A0If it could do that, then it=
wouldn't need NETCONF Light.

The theory i= s that the client developers will rewrite their code
so instead o= f sending a request and getting back an 'operation-not-supported'
error, the app can use the capabilities, and print that error message = without
sending a request.

NETCONF Light= is not intended to be backward-compatible.
It is intended to be = implemented by new servers that cannot advertise base 1.0
or base:1.1 for whatever reason.

Whether the = application business logic still works after taking away significant
<= div>CM functionality seems to be a secondary issue to some, but to me it
is the most important factor.


= =A0
Maybe there is some point in making the statement "2.0 is a backwards<= br> compatible change to the protocol" even though 2.0 *isn't* backwar= d
compatible with any earlier version - but then it basically only means
that there is a well-defined way for a 1.1-only client to find out that
it is unable to interoperate with a 2.0-only server. The only way you
could make a *non* backwards compatible change would be to fail to bump
the version number when you should have, which IMO should be called
"broken" or "bug". Thus I find the statement at best me= aningless, at
worst misleading.



I strongly oppose the n= ame NETCONF 1.2 because it is not an upgrade.
The capability (and= draft) is called NETCONF Light.
I don't understand how that = morphed into NETCONF 1.2.
=A0
--Per

Andy

=A0=
--f46d040890c79ae17004c26ebd6a-- From j.schoenwaelder@jacobs-university.de Thu Jun 14 07:07:29 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 B95DC21F866A for ; Thu, 14 Jun 2012 07:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 BmYtmiFmmyPb for ; Thu, 14 Jun 2012 07:07:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5A321F8448 for ; Thu, 14 Jun 2012 07:07:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21E7020BDA; Thu, 14 Jun 2012 16:07:27 +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 uYcM81IPpwaJ; Thu, 14 Jun 2012 16:07:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B579520BD8; Thu, 14 Jun 2012 16:07:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0CF311FC97F6; Thu, 14 Jun 2012 16:07:24 +0200 (CEST) Date: Thu, 14 Jun 2012 16:07:23 +0200 From: Juergen Schoenwaelder To: Netconf Message-ID: <20120614140721.GA77511@elstar.local> Mail-Followup-To: Netconf References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> <4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> <4FD9C2F6.9090105@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Netconf] we are NOT CONVERGING towards consensus 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, 14 Jun 2012 14:07:29 -0000 On Thu, Jun 14, 2012 at 06:33:09AM -0700, Andy Bierman wrote: > NETCONF Light is not intended to be backward-compatible. It is > intended to be implemented by new servers that cannot advertise base > 1.0 or base:1.1 for whatever reason. So we call it NETCONF 0.5. ;-) But, seriously, there was a reason why we originally called it NETCONF Light and not NETCONF. I agree that if a possible future NETCONF 2.0 version would be more modular, then NETCONF Light would not be needed. That alone, however, does not seem a reasonable reason to do NETCONF 2.0 (and probably not even for 1.2 since 1.1 and 1.2 implies likely more compatibility than a major version number bump). I have to study the REST API more closely and ideally get implementation experience with it. If it maps nicely to CoAP, this might be a much better choice for the constrained devices I have in mind than NETCONF Light ever was. But I lack implementation experience with this - so I do not really know. My personal conclusion from this discussion is to do nothing about NETCONF Light at the moment. We better spent our time on a REST API, this seems far more important than NETCONF Light and might make NETCONF Light a non-issue. /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 Jun 14 07:13: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 6421E21F8650 for ; Thu, 14 Jun 2012 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050, 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 QBgZPWbbJ48I for ; Thu, 14 Jun 2012 07:13:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D11B321F8649 for ; Thu, 14 Jun 2012 07:12:59 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 0B22F13FB24 for ; Thu, 14 Jun 2012 16:12:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339683179; bh=u0QQc6od7ziJs4HRSh8Kwmj1wX7J379RZ3/wfLa/0FU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=YbBU1K9TDjjF+0ZWnkpCtJUT5yjf7ty0Yv7gG8CjLprOfMU/bP2fwGfaPPRoX9fyB Yc/BmvHB1cZdaJPBS+v+VU6dSOLgvFpK8f/uHXJ8ZMrnPK7WB1lmob16MEuMDp2LYX sF3ZgkwhzPFniKyVvgltyhrmVo17rQ+ybC85bOcI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Ladislav Lhotka In-Reply-To: Date: Thu, 14 Jun 2012 16:12:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24993CBE-FD67-4A69-9634-1D618A9262AD@nic.cz> References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> <4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> <4FD9C2F6.9090105@tail-f.com> To: Netconf X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:13:00 -0000 On Jun 14, 2012, at 3:33 PM, Andy Bierman wrote: >=20 > The end result of NETCONF-Light would be that the "base:1.1" = capability > string gets replaced by N different capability strings. > A server which conforms to base:1.1 will be able to send > both base:1.1 and all the new capability strings as well. > For a server that already implements base:1.1, the "new" protocol > will be a step backwards -- it does the same thing as before > but just takes more bytes on the wire to do it. The the only way But a new server can easily replace some of the non-core capabilities = with alternative functionality - for example, to provide transactions = with optimistic execution instead of locks. In my view, this is an = improvement. =20 ... >=20 > I strongly oppose the name NETCONF 1.2 because it is not an upgrade. > The capability (and draft) is called NETCONF Light. > I don't understand how that morphed into NETCONF 1.2. Because there is no point in keeping two separate versions if one = modularized version can eventually be used everywhere. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Jun 14 07:17: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 690E421F85DF for ; Thu, 14 Jun 2012 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.047, 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 85GnL9NKUo7e for ; Thu, 14 Jun 2012 07:17:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CB47021F854A for ; Thu, 14 Jun 2012 07:17:47 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 1AF2113FB24; Thu, 14 Jun 2012 16:17:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339683467; bh=Z4o1K0kyocyqrS+ViishoupEUD8CZFzrYYTJ/G1B0hw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=n+rcJ71hsH+/q4PcsLMGbeWa256p8ZwmV+YVtD/2xmBoWS1LRPV39LTrvY+qDM/jD WLilY8NnH/6I8gcdH2pnMXdOGo5cx0qj0bCvZsq1jBdjJJlo7OwFuAxhP7Tosxpvr7 XQRZ7b8XhqUuI6suCbzMUKKz53v0ABq//FzhRQmA= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120614140721.GA77511@elstar.local> Date: Thu, 14 Jun 2012 16:17:46 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4FD84B4A.9000907@ripe.net> <84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz> <4FD85B48.2070700@tail-f.com> <933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz> <4FD870F9.7000608@tail-f.com> <4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> <4FD9C2F6.9090105@tail-f.com> <20120614140721.GA77511@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:17:48 -0000 On Jun 14, 2012, at 4:07 PM, Juergen Schoenwaelder wrote: > On Thu, Jun 14, 2012 at 06:33:09AM -0700, Andy Bierman wrote: > >> NETCONF Light is not intended to be backward-compatible. It is >> intended to be implemented by new servers that cannot advertise base >> 1.0 or base:1.1 for whatever reason. > > So we call it NETCONF 0.5. ;-) > > But, seriously, there was a reason why we originally called it NETCONF > Light and not NETCONF. I agree that if a possible future NETCONF 2.0 > version would be more modular, then NETCONF Light would not be > needed. That alone, however, does not seem a reasonable reason to do > NETCONF 2.0 (and probably not even for 1.2 since 1.1 and 1.2 implies > likely more compatibility than a major version number bump). > > I have to study the REST API more closely and ideally get > implementation experience with it. If it maps nicely to CoAP, this > might be a much better choice for the constrained devices I have in > mind than NETCONF Light ever was. But I lack implementation experience > with this - so I do not really know. > > My personal conclusion from this discussion is to do nothing about > NETCONF Light at the moment. We better spent our time on a REST API, > this seems far more important than NETCONF Light and might make > NETCONF Light a non-issue. +1 Lada > > /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 ietfc@btconnect.com Thu Jun 14 08:38: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 68A1621F86EA for ; Thu, 14 Jun 2012 08:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1jKWA4eT3NI for ; Thu, 14 Jun 2012 08:38:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2E421F86E8 for ; Thu, 14 Jun 2012 08:38:15 -0700 (PDT) Received: from mail214-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 15:37:07 +0000 Received: from mail214-ch1 (localhost [127.0.0.1]) by mail214-ch1-R.bigfish.com (Postfix) with ESMTP id 03BFC3A06A9; Thu, 14 Jun 2012 15:37:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT010.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371I936eI542M1432I1418Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail214-ch1 (localhost.localdomain [127.0.0.1]) by mail214-ch1 (MessageSwitch) id 1339688224511860_3039; Thu, 14 Jun 2012 15:37:04 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail214-ch1.bigfish.com (Postfix) with ESMTP id 7B10720008D; Thu, 14 Jun 2012 15:37:04 +0000 (UTC) Received: from DB3PRD0702HT010.eurprd07.prod.outlook.com (157.55.224.141) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 15:37:03 +0000 Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by pod51017.outlook.com (10.3.4.178) with Microsoft SMTP Server (TLS) id 14.15.74.2; Thu, 14 Jun 2012 15:38:10 +0000 Message-ID: <008d01cd4a43$3f4d30a0$4001a8c0@gateway.2wire.net> From: t.petch To: "Romascanu, Dan (Dan)" References: <4FD84B4A.9000907@ripe.net><84B709C0-4C67-4DCC-985D-08AD58B8BA55@nic.cz><4FD85B48.2070700@tail-f.com><933F8BB7-4FF5-4B2B-BABD-F75C637B5301@nic.cz><4FD870F9.7000608@tail-f.com><4FD87CA2.40502@tail-f.com> <4FD881B4.4040704@ripe.net> Date: Thu, 14 Jun 2012 16:34:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.5] X-OriginatorOrg: btconnect.com Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:38:17 -0000 ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Bert Wijnen" ; "Per Hedeland" Cc: "Netconf" Sent: Wednesday, June 13, 2012 2:05 PM > I am with Bert on this. Backwards compatibility in this context does not > mean to me that any version of an old client must work with any future > version of a server. This would be forwards compatibility :-) Backwards > compatibility means IMO the capability to identify the version of the > protocol run by the server and its capabilities and to be able to manage > what matches the agent version level, and to gracefully ignore and alert > the operator when the protocol interaction is not possible. > Dan I think that what you describe is a very sophisticated flavour of compatibility, that is that if one is prepared to write sophisticated enough code, almost anything can be made to work with almost anything else, the exception being when B shuts down the connection and refuses to respond ever again on receiving something it does not understand from A. I think that the more common parlance is making optional additions without which something meaningful can still be achieved, so B remains out in the sticks unaltered for years, while A gets new features which allow it to get more from upgraded boxes but can still do something meaningful with old-fashioned B. What is being discussed here seems quite at odds with that. Tom Petch > Regards, > > Dan > > > > > > -----Original Message----- > > From: Bert Wijnen [mailto:bwijnen@ripe.net] > > Sent: Wednesday, June 13, 2012 3:04 PM > > To: Per Hedeland > > Cc: Romascanu, Dan (Dan); Ladislav Lhotka; Netconf > > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus > > > > On 6/13/12 1:42 PM, Per Hedeland wrote: > > > On 2012-06-13 13:17, Romascanu, Dan (Dan) wrote: > > >> > > >> So, are you saying that NETCONF will never be able to be > modularized > > in > > >> such a way that it can be used as a solution for managing devices > > with > > >> restrained resources? > > > > > > No, I'm mainly objecting to the use of "backwards compatible" to > > > describe changes that clearly aren't. Obviously non-backwards- > > compatible > > > changes are sometimes deemed necessary, or at least better than > other > > > alternatives - it's a trade-off decision like so many others. > > > > > > > I would think that an existing NetConf 1.1 client will check if the > > managed > > device supports NetConf 1.1 If so, it probably keeps using that set of > > capabilities. And so I see no problem. > > > > If a more advanced NetConf 2.0 client check if a managed device does > > NetConf 2.0, and if it does, then it also needs to check if the > > proper capabilities (those that were mandatory in Netconf 1.0 and 1.1) > > are supported by the managed device, and if so... boom we're running. > > If not, the client can try to fallback to NetConf 1.1. > > Is supported .. boom we're running. > > If not supported, then that means a new (constrained) device is being > > managed, and probably there are fewer capabilities than those on > > NetConf 1.1. The client can decide to not support that new > > (constrained) > > device, or it can decide to try to manage it with the lesser set of > > capabilities. > > > > All existing/fielded Netconf 1.0 and 1.1 operational configurations > > should > > continue to work wothout a problem. > > > > Is that not BACKWARD COMPATIBLE ?? > > > > Maybe I do not understand the term at all?? > > > > Bert > > > > > > > > > > > My *opinion*, as already stated, is that making such changes to > > NETCONF > > > would be seriously detrimental to the general "success" of the > > protocol. > > > I don't really have an opinion on whether implementation of the > > > currently mandatory functionality actually is "too hard" for some > > > unspecified class of "constrained" devices, nor whether it would be > a > > > disaster if such devices do "something else" in that case. > > > > > > --Per > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From phil@juniper.net Thu Jun 14 08:49: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 BE1B021F870F for ; Thu, 14 Jun 2012 08:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 mUwCPX6aCToA for ; Thu, 14 Jun 2012 08:49:35 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id BEA7521F870B for ; Thu, 14 Jun 2012 08:49:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT9oIB8kTpE09TcZgkw7QXKoFdQHSmUDl@postini.com; Thu, 14 Jun 2012 08:49:32 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Jun 2012 08:47:09 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q5EFl7178968; Thu, 14 Jun 2012 08:47:07 -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 q5EFl6x1075204; Thu, 14 Jun 2012 11:47:06 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206141547.q5EFl6x1075204@idle.juniper.net> To: "Romascanu, Dan (Dan)" In-Reply-To: Date: Thu, 14 Jun 2012 11:47:06 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:49:35 -0000 "Romascanu, Dan (Dan)" writes: >I am with Bert on this. Backwards compatibility in this context does not >mean to me that any version of an old client must work with any future >version of a server. This would be forwards compatibility :-) It's a relative question, since you've got two directions here. Backwards compatibility means "continues to work with old input". Forwards compatibility means "continues to work with new input". So for a client/server system, backwards compatibility means if a client send old data, the server needs to be able to handle it and if the server send old data, the client needs to be able to handle it. Similarly for forwards compatibility, if the client sends new input, the server needs to be able to handle it. If the server send new input, the client needs to be able to handle it. In the real world, if you break either of these, you have irate customers and get called into meetings with senior mgmt to explain why your change is more important than the customer ;^) Me, I'm still having trouble understanding why folks are more interested in perturbing N/Y. Shouldn't we be putting time into evangelizing, promoting, using, building, and things that will help adoption instead of "2.0" efforts that will hamper it? Thanks, Phil From phil@juniper.net Thu Jun 14 09:11: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 A878E21F850C for ; Thu, 14 Jun 2012 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 jXP06jJ35Nwo for ; Thu, 14 Jun 2012 09:11:39 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id DD76921F84A1 for ; Thu, 14 Jun 2012 09:11:38 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT9oNOkMOXdnJ73rfpU/25QFw0HHrAwJO@postini.com; Thu, 14 Jun 2012 09:11:38 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Jun 2012 09:08:26 -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 q5EG8Q193001 for ; Thu, 14 Jun 2012 09:08:26 -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 q5EG8PQb075493 for ; Thu, 14 Jun 2012 12:08:25 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206141608.q5EG8PQb075493@idle.juniper.net> To: Netconf In-Reply-To: <29C30561-9607-4F67-814C-C9CB310C2FCD@tail-f.com> Date: Thu, 14 Jun 2012 12:08:25 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 16:11:39 -0000 On Jun 13, 2012, at 20:41 PM, Ladislav Lhotka wrote: > I don't really know the whole story, for sure XML was one of the reasons against NETCONF. Okay, so they liked: interfaces: { interface: { name: "fe-0/0/0"; description: "Local interface"; } } instead of: fe-0/0/0 Local interface I'm assuming the story can't be this simple. N/Y offers _much_ more than a local, custom, JSON-based protocol can. The volume of functionality they'll have to brew on their own is large. So that means we can either believe that N/Y adoption is limited because: (a) we do not have open source tools of sufficient quality and functionality. (b) those tools do not have a community of support for them. (c) we are not evangelizing our story sufficiently for folks to understand the value of the technologies. (d) we do not integrate well with other software. (e) we aren't putting our time into issues that matter. _or_ we can believe N/Y adoption is limited because: (1) users have an insane fear of angle brackets. (2) connection startup is ugly. FWIW: I can easily admit that dealing with JSON in javascript is easier than dealing with XML, but I firmly believe if we had a XMLParse() that made natively-keyed objects like JSONParse(), this would not be an issue. (And I don't know how many network mgmt apps are being written in javascript anyway. I'm guessing that bind10 is not.) Thanks, Phil From andy@yumaworks.com Thu Jun 14 09:28:52 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 2AA1A21F8681 for ; Thu, 14 Jun 2012 09:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 c0yNHuf+d3ox for ; Thu, 14 Jun 2012 09:28:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6A2121F8514 for ; Thu, 14 Jun 2012 09:28:50 -0700 (PDT) Received: by lagv3 with SMTP id v3so1476140lag.31 for ; Thu, 14 Jun 2012 09:28:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=d96QWPTsC46oQVWDBk/X0jqpIsctz/2XU4o3HjFNEFg=; b=OcUlLG7a1dBZB6PSVgceQTLnQmZ/g624oHWrnsVhYG/YYxmsB9PHRi6owIVOMKB2EO T6b9wo7DzTxLtDPgVdFlWjZXyI11KlNuZ/OkEYC+A5qCLr8Z5++R4y0lCiEHX8BEwr/G pzIsiA74FmTRCfj0f2nYdZrtW4qGI2UrD1BV0fBRc+LmANo1tzupo2mcYu0iEtytTsr1 gFAVFt+Rg1KK+x5x/Qxi0r41VlCUgaUKNRdguxytCT045mAlsQQrwBRnaWUJVb+dK1t3 qCOJaBUlbPvxzJmLU88UTXDYK8aWZfCFNgMi6eLVtzVx8blGA6K0c2YWN4Uko4/19aji hlcQ== MIME-Version: 1.0 Received: by 10.112.102.8 with SMTP id fk8mr1233299lbb.71.1339691329706; Thu, 14 Jun 2012 09:28:49 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Thu, 14 Jun 2012 09:28:49 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <201206141547.q5EFl6x1075204@idle.juniper.net> References: <201206141547.q5EFl6x1075204@idle.juniper.net> Date: Thu, 14 Jun 2012 09:28:49 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: multipart/alternative; boundary=f46d0401730bd0dba104c271311a X-Gm-Message-State: ALoCoQnG7a2/nWvQENXNT544R8b2tO35NZRKCaaLjrt/fzuiq6fFpfoye0pX7yLWFl/mC25dyXKu Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 16:28:52 -0000 --f46d0401730bd0dba104c271311a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 14, 2012 at 8:47 AM, Phil Shafer wrote: > "Romascanu, Dan (Dan)" writes: > >I am with Bert on this. Backwards compatibility in this context does not > >mean to me that any version of an old client must work with any future > >version of a server. This would be forwards compatibility :-) > > It's a relative question, since you've got two directions here. > > Backwards compatibility means "continues to work with old input". > Forwards compatibility means "continues to work with new input". > > So for a client/server system, backwards compatibility means > if a client send old data, the server needs to be able to handle > it and if the server send old data, the client needs to be able > to handle it. > > Similarly for forwards compatibility, if the client sends new input, > the server needs to be able to handle it. If the server send new > input, the client needs to be able to handle it. > > In the real world, if you break either of these, you have irate > customers and get called into meetings with senior mgmt to explain > why your change is more important than the customer ;^) > > I agree. The argument that the new server will advertise all versions of the protocol doesn't apply when you are talking about removing mandatory-to-implement things. I think NETCONF has enough server options already, and making almost everything optional is not a step forward. > Me, I'm still having trouble understanding why folks are more > interested in perturbing N/Y. Shouldn't we be putting time into > evangelizing, promoting, using, building, and things that will > help adoption instead of "2.0" efforts that will hamper it? > > I agree that nothing is broken and tweaking is optional. I don't want to make NETCONF 1.1 appear obsolete. We have customers interested in "NETCONF Light", not NETCONF 1.2 or 2.0. They expect the server resources to be dramatically reduced by NETCONF Light, so it can fit on small boxes. I don't think removing major features is the best approach. For small devices that already have a tiny WEB server, a REST API using JSON is going to be way less additional overhead than adding SSH and XML support. > Thanks, > Phil > Andy --f46d0401730bd0dba104c271311a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 14, 2012 at 8:47 AM, Phil Sh= afer <phil@juniper.net> wrote:
"Romascanu, Dan (Dan)" writes:
>I am with Bert on this. Backwards compatibility in this context does no= t
>mean to me that any version of an old client must work with any future<= br> >version of a server. This would be forwards compatibility :-)

It's a relative question, since you've got two directions here.

Backwards compatibility means "continues to work with old input".=
Forwards compatibility means "continues to work with new input".<= br>
So for a client/server system, backwards compatibility means
if a client send old data, the server needs to be able to handle
it and if the server send old data, the client needs to be able
to handle it.

Similarly for forwards compatibility, if the client sends new input,
the server needs to be able to handle it. =A0If the server send new
input, the client needs to be able to handle it.

In the real world, if you break either of these, you have irate
customers and get called into meetings with senior mgmt to explain
why your change is more important than the customer ;^)


I agree. =A0The argument that the new = server will advertise all
versions of the protocol doesn't ap= ply when you are talking
about removing mandatory-to-implement th= ings.
I think NETCONF has enough server options already,
and makin= g almost everything optional is not a step forward.
=A0
Me, I'm still having trouble understanding why folks are more
interested in perturbing N/Y. =A0Shouldn't we be putting time into
evangelizing, promoting, using, building, and things that will
help adoption instead of "2.0" efforts that will hamper it?


I agree that nothing is broken and twe= aking is optional.
I don't want to make NETCONF 1.1 appear ob= solete.
We have customers interested in "NETCONF Light"= , not NETCONF 1.2 or 2.0.
They expect the server resources to be dramatically reduced
= by NETCONF Light, so it can fit on small boxes.

I = don't think removing major features is the best approach.
For small devices that already have a tiny WEB server, a REST API
using JSON is going to be way less additional overhead than adding
SSH and XML support.


=A0
Thanks,
=A0Phil

Andy
=A0
--f46d0401730bd0dba104c271311a-- From lhotka@nic.cz Thu Jun 14 13:56: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 7736A21F854F for ; Thu, 14 Jun 2012 13:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.044, 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 mxxK38PwwadM for ; Thu, 14 Jun 2012 13:56:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C4CCF21F8550 for ; Thu, 14 Jun 2012 13:56:05 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id BFC2713F653; Thu, 14 Jun 2012 22:56:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339707364; bh=uncbMkkzZT40Xf5sCzXAz5S2lgH8zhI7AIcHbm8sIfQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZDeUiQezC1Sq1oc4AN3+SKxyOuZrIPUfOiqRvGRWUVAAdjqCEvLzOdOfC/YbFItka KlaMiRMX2ynq0yGKZl9r8uK2KUT6XOmjAlQdNRO+X6M9kcXOVsnF7hYzSe2U655NYS 9LyW0Pj6cAE43w3Wotq1zy6Jlkff5aGVo2FDiQfA= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201206141608.q5EG8PQb075493@idle.juniper.net> Date: Thu, 14 Jun 2012 22:55:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <985436A4-856A-4315-8D37-E158EC95EF7B@nic.cz> References: <201206141608.q5EG8PQb075493@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:56:06 -0000 On Jun 14, 2012, at 6:08 PM, Phil Shafer wrote: > On Jun 13, 2012, at 20:41 PM, Ladislav Lhotka wrote: >> I don't really know the whole story, for sure XML was one of the = reasons against NETCONF. >=20 > Okay, so they liked: >=20 > interfaces: { > interface: { > name: "fe-0/0/0"; > description: "Local interface"; > } > } Looks familiar. :-) >=20 > instead of: >=20 > > > fe-0/0/0 > Local interface > > >=20 > I'm assuming the story can't be this simple. N/Y offers _much_ > more than a local, custom, JSON-based protocol can. The volume of > functionality they'll have to brew on their own is large. They already had some infrastructure for messaging among daemons, so = they reused it for remote configuration purposes. And I don't think it = is so difficult to find generic components providing the necessary = functionality.=20 >=20 > So that means we can either believe that N/Y adoption is limited = because: >=20 > (a) we do not have open source tools of sufficient quality and > functionality. > (b) those tools do not have a community of support for them. > (c) we are not evangelizing our story sufficiently for folks to > understand the value of the technologies. > (d) we do not integrate well with other software. > (e) we aren't putting our time into issues that matter. >=20 > _or_ we can believe N/Y adoption is limited because: >=20 > (1) users have an insane fear of angle brackets. > (2) connection startup is ugly. Most projects, including BIND 10, just write their own client (or simply = use a web browser) and maintain it as a part of the system. Without = hellos etc., the communication protocol is not a big deal.=20 >=20 > FWIW: I can easily admit that dealing with JSON in javascript is > easier than dealing with XML, but I firmly believe if we had a > XMLParse() that made natively-keyed objects like JSONParse(), this > would not be an issue. (And I don't know how many network mgmt > apps are being written in javascript anyway. I'm guessing that > bind10 is not.) No, it's C++ and Python. But JSON parser is trivial, unlike XML parser. Lada >=20 > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Thu Jun 14 15:41:21 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 522C221F8542 for ; Thu, 14 Jun 2012 15:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 ly5NLE+9tNQR for ; Thu, 14 Jun 2012 15:41:19 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 577E421F8484 for ; Thu, 14 Jun 2012 15:41:17 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT9pojWxeA3ECelC4dHuce0qv+TyBSU1f@postini.com; Thu, 14 Jun 2012 15:41:19 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Jun 2012 15:40:04 -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 q5EMe2199472; Thu, 14 Jun 2012 15:40:03 -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 q5EMe20N078860; Thu, 14 Jun 2012 18:40:02 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206142240.q5EMe20N078860@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <985436A4-856A-4315-8D37-E158EC95EF7B@nic.cz> Date: Thu, 14 Jun 2012 18:40:02 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 22:41:21 -0000 Ladislav Lhotka writes: >No, it's C++ and Python. But JSON parser is trivial, unlike XML parser. libxml2 and libxslt have python bindings. Part of the value of standards is that you don't need to roll your own (JSON or XML) and can use libjson or libxml2. Thanks, Phil From rohit.pobbathi@huawei.com Thu Jun 14 21:57: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 43C7721F8564 for ; Thu, 14 Jun 2012 21:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.148 X-Spam-Level: X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_MIMEOLE=0.001, MSGID_MULTIPLE_AT=1.449, 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 EJM+h-uxr205 for ; Thu, 14 Jun 2012 21:57:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 659C921F8562 for ; Thu, 14 Jun 2012 21:57:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHE79303; Fri, 15 Jun 2012 00:57:50 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 14 Jun 2012 21:57:48 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 14 Jun 2012 21:57:45 -0700 Received: from blrprnc10ns (10.18.96.99) by szxeml420-hub.china.huawei.com (10.82.67.159) with Microsoft SMTP Server id 14.1.323.3; Fri, 15 Jun 2012 12:57:39 +0800 From: Rohit Pobbathi To: Date: Fri, 15 Jun 2012 10:27:38 +0530 Organization: Htipl Message-ID: <000f01cd4ab3$63f849b0$2be8dd10$@pobbathi@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CD4AE1.7DB085B0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1KFwwFj7pBw2OOQSm4O+f4ze9C9wAAClZQACcEcgA= Importance: High Content-Language: en-us X-Originating-IP: [10.18.96.99] X-CFilter-Loop: Reflected Subject: [Netconf] RFC 6536 query X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rohit.pobbathi@huawei.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 04:57:51 -0000 ------=_NextPart_000_0010_01CD4AE1.7DB085B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have a query regarding Section 3.2.2 of RFC 6536 (NACM). It is mentioned "Data nodes to which the client does not have read access are silently omitted from the message". If the operation contains a subtree filter only for a data node (as a selection node) for which read access is restricted, then should the message contain empty OR "access-denied" " ? Scenario: a) Access rule exists to DENY READ access to "/top/users" data node b) with NO FILTER will OMIT the data node /top/users (even if records exist for this Container) c) with a Selection FILTER for "/top/users" [records exist for "users" in the device] What should be the response for below request ? i) with EMPTY , OR ii) with "access-denied" Regards, Rohit ------=_NextPart_000_0010_01CD4AE1.7DB085B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

I have a = query regarding Section 3.2.2 of RFC 6536 (NACM).

It is = mentioned "Data nodes to which the client does not have read access = are silently omitted from the <rpc-reply> message". =

If the = <get-config> operation contains a subtree filter only for a data = node (as a selection node) for which read access is restricted, then = should the <rpc-reply> message contain empty <data> OR = "access-denied" <rpc-error>" ?

Scenario:
a) Access = rule exists to DENY READ access to "/top/users" data = node

b) = <get-config> with NO FILTER will OMIT the data node /top/users = (even if records exist for this Container)
<rpc = message-id=3D"101" = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> =
 <get= -config>
  = <source>
  =  <running/>
  = </source>
 </ge= t-config>
</rpc><= /span>

c) = <get-config> with a Selection FILTER for "/top/users" = [records exist for "users" in the device]
  =  What should be the response for below request = ?
  =  i) <rpc-reply> with EMPTY <data>, OR
  =  ii) <rpc-reply> with "access-denied" = <rpc-error>

<rpc = message-id=3D"102" = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> =
 <get= -config>
  = <source>
  =  <running/>
  = </source>
  = <filter type=3D"subtree">
  =  <top = xmlns=3D"http://example.com/schema/1.2/config"> =
  =   <users/>
  =  </top>
  = </filter>
 </ge= t-config>
</rpc><= /span>

 

Regards,=

Rohit

 

 

------=_NextPart_000_0010_01CD4AE1.7DB085B0-- From lhotka@nic.cz Fri Jun 15 00:43: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 661A021F85C0 for ; Fri, 15 Jun 2012 00:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.041, 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 8fEM6j+myScS for ; Fri, 15 Jun 2012 00:43:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 761CB21F856D for ; Fri, 15 Jun 2012 00:43:46 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 71DE813FD87; Fri, 15 Jun 2012 09:43:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339746223; bh=wgPsOQg+1oSQDjhDW+eYupll9imPQRJWGyl6Md50Hus=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hufahObT+97uOcuQZIi0raBQ9qMaXvVfCESWFEOI71YnTtO9k9XkaGw7bEvD/dWXD fYHLH2ZwjWjGvVL2adTsAKjV1CBpDxnkYyqYFqjED/4JKJ4YBaanpQo5gG6OgB1Mzh l3RIeCGU+tdUErnX6/epzUvL2cGRVRUSHaPQGEjI= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201206142240.q5EMe20N078860@idle.juniper.net> Date: Fri, 15 Jun 2012 09:43:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <868CC5DD-D1DD-4110-93D9-08AFEA7286D7@nic.cz> References: <201206142240.q5EMe20N078860@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 07:43:53 -0000 On Jun 15, 2012, at 12:40 AM, Phil Shafer wrote: > Ladislav Lhotka writes: >> No, it's C++ and Python. But JSON parser is trivial, unlike XML = parser. >=20 > libxml2 and libxslt have python bindings. Part of the value of > standards is that you don't need to roll your own (JSON or XML) > and can use libjson or libxml2. Sure, but adding libxml2 to your dependencies is not without cost. = Moreover, JSON is parsed straight to C structures or Python = dictionaries, while with XML you get a DOM or something similar. Of course, nobody can blame NETCONF for choosing XML in 2003. Lada=20 >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Fri Jun 15 09:00: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 72CA921F85AE for ; Fri, 15 Jun 2012 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 hd-zW9nmSW87 for ; Fri, 15 Jun 2012 09:00:02 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id C9AC121F84C8 for ; Fri, 15 Jun 2012 08:59:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT9tb/+rbaIVCS7p50j2HKLw41ktSQ18F@postini.com; Fri, 15 Jun 2012 09:00:02 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Jun 2012 08:58:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q5FFwg192106; Fri, 15 Jun 2012 08:58:42 -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 q5FFwgKY083225; Fri, 15 Jun 2012 11:58:42 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206151558.q5FFwgKY083225@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <868CC5DD-D1DD-4110-93D9-08AFEA7286D7@nic.cz> Date: Fri, 15 Jun 2012 11:58:42 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:00:03 -0000 Ladislav Lhotka writes: >Of course, nobody can blame NETCONF for choosing XML in 2003. And hopefully no one will blame the w3c for choosing it for HTML5 (in 2009 ;^). FWIW, I favor XML because it gives three axis of richness (hierarchy, namespaces, attributes). Hierarchy gives you rich data, namespaces give you rich extensibility, and attributes give you rich metadata. NETCONF/YANG uses all three. Thanks, Phil From andy@yumaworks.com Fri Jun 15 10:02: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 7D85421F85D9 for ; Fri, 15 Jun 2012 10:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 W-TOpTLqcnjA for ; Fri, 15 Jun 2012 10:02:58 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F421F85BD for ; Fri, 15 Jun 2012 10:02:57 -0700 (PDT) Received: by lagv3 with SMTP id v3so2336956lag.31 for ; Fri, 15 Jun 2012 10:02:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Mz/cP7uIKwfejRY8RS4O5ucWlL1Rdxyh9qadk2zGmqQ=; b=HymHX/TRnMHMxDtyXOBNh1Y6/SQRXcFgvAlCZhKhGaFEo+AYfUXt0KRxVogCstIZ59 +sdBULSqtZT/2evJFIlKhZe43ZK38N8fI8Flmp7x/hrXaRMSRGSnQIr8t1muPdBh+0Gp dknn5nVCxX37Ws2Vbv/uQhjrZqr0IqADHhXz/0Ylt3TkNTvDkeHkktLjmCZhZp7JCUhO h8G/5NYyTdXEK+RGpETGKHqH6wS20um8Zc5dil55gFGDV7p91qlPH32Zj/xEQ1rQvOCt XdD/S+vPLvWsXx6NH+AdMJBhsOy1s8lM4P77zMfVdulszuqxGpqRb1RmMCAaLg+3HC8/ TJnQ== MIME-Version: 1.0 Received: by 10.112.102.8 with SMTP id fk8mr2790147lbb.71.1339779776189; Fri, 15 Jun 2012 10:02:56 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Fri, 15 Jun 2012 10:02:55 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <201206151558.q5FFwgKY083225@idle.juniper.net> References: <868CC5DD-D1DD-4110-93D9-08AFEA7286D7@nic.cz> <201206151558.q5FFwgKY083225@idle.juniper.net> Date: Fri, 15 Jun 2012 10:02:55 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: multipart/alternative; boundary=f46d0401730ba313f904c285c9bf X-Gm-Message-State: ALoCoQnOt5f/UINxQ9Rn4Vo6yX/eDQZIoRdTxkiv5mwLE8TT2a0Q9pVHchQoqQ4uFeL7dUYIzA9K Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:02:58 -0000 --f46d0401730ba313f904c285c9bf Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 15, 2012 at 8:58 AM, Phil Shafer wrote: > Ladislav Lhotka writes: > >Of course, nobody can blame NETCONF for choosing XML in 2003. > > And hopefully no one will blame the w3c for choosing it for HTML5 > (in 2009 ;^). > > FWIW, I favor XML because it gives three axis of richness (hierarchy, > namespaces, attributes). Hierarchy gives you rich data, namespaces > give you rich extensibility, and attributes give you rich metadata. > NETCONF/YANG uses all three. > > Perhaps the YANG/NETCONF/XML combination is not the right solution for every use-case. XML also has processing instructions, and lots of complex flexibility how namespaces are used. JSON encoding of YANG with module namespaces provides 2 of the 3: http://tools.ietf.org/html/draft-lhotka-yang-json-01 HTTP separates meta-data as headers instead of including it in the data. This can be easier to use if it replaces lots of attributes. The arbitrary mix of nc:operation attributes within the tree allows fine-grained control for the client, but it can be expensive to implement in the server. I think NETCONF, CLI, WEBui, HTTP/REST, SNMP, and even SYSLOG all need to operate within a unified management framework. YANG could be the glue that pulls them all together. I like NETCONF 1.1 + XML just fine and would not use any other access method for a traditional NMS or EMS. I wouldn't pick it for some other use-cases though. > Thanks, > Phil > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f46d0401730ba313f904c285c9bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 15, 2012 at 8:58 AM, Phil Sh= afer <phil@juniper.net> wrote:
Ladislav Lhotka writes:
>Of course, nobody can blame NETCONF for choosing XML in 2003.

And hopefully no one will blame the w3c for choosing it for HTML5
(in 2009 ;^).

FWIW, I favor XML because it gives three axis of richness (hierarchy,
namespaces, attributes). =A0Hierarchy gives you rich data, namespaces
give you rich extensibility, and attributes give you rich metadata.
NETCONF/YANG uses all three.


Perhaps the YANG/NETCONF/XML combinati= on is not the right solution
for every use-case. =A0XML also has = processing instructions, and lots of
complex flexibility how name= spaces are used.

JSON encoding of YANG with module namespaces provides 2= of the 3:

HTTP separates meta-data as headers instead of includin= g it in the data.
This can be easier to use if it replaces lots o= f attributes. =A0The arbitrary mix
of nc:operation attributes wit= hin the <edit-config> tree allows fine-grained control
for the client, but it can be expensive to implement in the server.

I think NETCONF, CLI, WEBui, HTTP/REST, SNMP, and ev= en SYSLOG all need to
operate within a unified management framewo= rk. YANG could be the glue that pulls
them all together. =A0I like NETCONF 1.1 + XML just fine and would not= use any other
access method for a traditional NMS or EMS. =A0 I = wouldn't pick it for some other use-cases though.

<= div>
=A0
Thanks,
=A0Phil

Andy
=A0
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--f46d0401730ba313f904c285c9bf-- From lhotka@nic.cz Fri Jun 15 13:47: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 2AD5221F85A5 for ; Fri, 15 Jun 2012 13:47:09 -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.039, 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 p9FmApnysNOO for ; Fri, 15 Jun 2012 13:47:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC9521F8559 for ; Fri, 15 Jun 2012 13:47:02 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id C8C5B13FB25; Fri, 15 Jun 2012 22:47:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339793220; bh=wz8BT0vlLh9m3ARsBxl01buLtrd1dFmLXBXDfSEttbE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=r9pRYz0tGoqIiSCFlG1RCtXenQGpTILCcjRC5mR3tq3cPZVN0Lr70t+xkrcWJl01R f6SfHEItoyg5qywv6UXLyEbMuynTIh1DNPsyKb28Es7HnNBEn3uB9W6f8gRE0yXQLl hkZTSQnGeJwYb/xoe2FTd4nDo1O4hXJzxiNeh5Mw= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201206151558.q5FFwgKY083225@idle.juniper.net> Date: Fri, 15 Jun 2012 22:46:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7396D5CB-D0FB-4D2F-97E5-332FFAABB487@nic.cz> References: <201206151558.q5FFwgKY083225@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:47:09 -0000 On Jun 15, 2012, at 5:58 PM, Phil Shafer wrote: > Ladislav Lhotka writes: >> Of course, nobody can blame NETCONF for choosing XML in 2003. >=20 > And hopefully no one will blame the w3c for choosing it for HTML5 > (in 2009 ;^). This is something else - HTML is text with markup, i.e. mixed content. = For hierarchical data, the game is over. Last year I attended an XML = conference, and a good deal of papers was actually about JSON. Lada >=20 > FWIW, I favor XML because it gives three axis of richness (hierarchy, > namespaces, attributes). Hierarchy gives you rich data, namespaces > give you rich extensibility, and attributes give you rich metadata. > NETCONF/YANG uses all three. >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sat Jun 16 07:24: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 70BD821F856C for ; Sat, 16 Jun 2012 07:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QMSGqjZyes0D for ; Sat, 16 Jun 2012 07:24:05 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6921F8559 for ; Sat, 16 Jun 2012 07:24:04 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3812053lbb.31 for ; Sat, 16 Jun 2012 07:24:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5KALS3uRs0idlc9GeEZbhMrai938iROkkuOYgN6ggHk=; b=cD1mjS2VCwDJ1Xizsz0n2arlO2KyeSGFytA3f8s/VUUWAIU8+P09F21JSFEe7dcI0P j8Pdy0M9230Pyb1KAi9f0nYP5YTt0VJugPGE0q7OKou+It0S9bB7/fGVyKmBmTucCru+ iUKJjpbl5bYb+Ff6Mgpy39KDDtebmjAM5spCdXrwSIEkkgNVzRu3I0Sl/tKXfFzB328D 3m8GtdAVShvsA55bgRZZ0xFngcaZjSa/QCbLlQc+DsiY/bwHRuRZXPolXOVQnwYV0/rM RVLttpptMMsKiZJe2JLwZ23Ob+eoWnKDiG0AF/BeSoVHogrgDnJiYLlCr3Rh5hcmZmpL qcAA== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr8639628lab.51.1339856643676; Sat, 16 Jun 2012 07:24:03 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Sat, 16 Jun 2012 07:24:03 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <4fdac0d4.c5f1440a.2af8.2778SMTPIN_ADDED@mx.google.com> References: <4fdac0d4.c5f1440a.2af8.2778SMTPIN_ADDED@mx.google.com> Date: Sat, 16 Jun 2012 07:24:03 -0700 Message-ID: From: Andy Bierman To: rohit.pobbathi@huawei.com Content-Type: multipart/alternative; boundary=e89a8f22bfb14bdb2d04c297afa6 X-Gm-Message-State: ALoCoQkkRFmqgJNijLhDvyBRvgDyL1Gisf75qJqdc0lRDkbV+rcT6ENvhqQ4gFv4rfeGZlz4otay Cc: netconf@ietf.org Subject: Re: [Netconf] RFC 6536 query X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 14:24:06 -0000 --e89a8f22bfb14bdb2d04c297afa6 Content-Type: text/plain; charset=ISO-8859-1 The server would return empty data. access-denied errors do not get generated for read operations. On Thu, Jun 14, 2012 at 9:57 PM, Rohit Pobbathi wrote: > Hi, > > I have a query regarding Section 3.2.2 of RFC 6536 (NACM). > > It is mentioned "Data nodes to which the client does not have read access > are silently omitted from the message". > > *If the operation contains a subtree filter only for a data > node (as a selection node) for which read access is restricted, then should > the message contain empty OR "access-denied" " > **?* > > *Scenario:* > a) Access rule exists to DENY READ access to "/top/users" data node > > b) with NO FILTER will OMIT the data node /top/users (even if > records exist for this Container) > > > > > > > > > c) with a Selection FILTER for "/top/users" [records exist > for "users" in the device] > *What should be the response for below request ?** > ** i) with EMPTY , OR > ** ii) with "access-denied" > * > > > > > > > > > > > > **** > > ** ** > > Regards,**** > > Rohit**** > > ** ** > > ** ** > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --e89a8f22bfb14bdb2d04c297afa6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The server would return empty data. access-denied errors do not get
gen= erated for read operations.


On= Thu, Jun 14, 2012 at 9:57 PM, Rohit Pobbathi <rohit.pobbathi@huaw= ei.com> wrote:

Hi,

I have a query regarding Section 3.2.2 of RFC 6536 (NACM).

It is mentioned "Data nodes to which the clie= nt does not have read access are silently omitted from the <rpc-reply>= ; message".

If the <get-config> operation contains a subtree fi= lter only for a data node (as a selection node) for which read access is re= stricted, then should the <rpc-reply> message contain empty <data&= gt; OR "access-denied" <rpc-error>" ?

Scenario:
a) Access rule= exists to DENY READ access to "/top/users" data node

b) <get-config> with NO FILTER will OMIT the data node= /top/users (even if records exist for this Container)
<rpc message-id=3D"101" xmlns=3D"urn:ietf:params:xml:ns= :netconf:base:1.0">
=A0<get-config>
=A0 <source>
=A0 =A0<running/>
=A0 </source>= ;
=A0</get-config>
</rpc>=

c) <get-config> with a Selection FILTER for "/top= /users" [records exist for "users" in the device] =A0 =A0What should be the response for below request ?=
=A0 =A0i) <rpc-reply> = with EMPTY <data>, OR
=A0 =A0ii) <rpc-reply> with "access-den= ied" <rpc-error>

<rpc messa= ge-id=3D"102" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1= .0">
=A0<get-config>
=A0 <source>
=A0 =A0<running/>
=A0 </source>= ;
=A0 <filter type=3D"subtree">
=A0 =A0<top xmlns=3D"http://example.com/schema/1.2/config">=
=A0 =A0 <users/>
=A0 =A0</top>=
=A0 </filter>
=A0</get-config>=
</rpc>

=A0

Regards,

Rohit

=A0<= /p>

=A0


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--e89a8f22bfb14bdb2d04c297afa6-- From ietfc@btconnect.com Mon Jun 18 02:20:42 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 9E08C21F8593 for ; Mon, 18 Jun 2012 02:20:42 -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=-1.300, BAYES_50=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 7mFuYL+RRzZC for ; Mon, 18 Jun 2012 02:20:42 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id A96EC21F858A for ; Mon, 18 Jun 2012 02:20:41 -0700 (PDT) Received: from mail8-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Jun 2012 09:19:22 +0000 Received: from mail8-db3 (localhost [127.0.0.1]) by mail8-db3-R.bigfish.com (Postfix) with ESMTP id 6C62940371 for ; Mon, 18 Jun 2012 09:19:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT006.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432I4015Izz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail8-db3 (localhost.localdomain [127.0.0.1]) by mail8-db3 (MessageSwitch) id 134001116199263_24159; Mon, 18 Jun 2012 09:19:21 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.229]) by mail8-db3.bigfish.com (Postfix) with ESMTP id 14734400048; Mon, 18 Jun 2012 09:19:21 +0000 (UTC) Received: from DB3PRD0702HT006.eurprd07.prod.outlook.com (157.55.224.141) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 09:19:21 +0000 Received: from SN2PRD0610HT005.namprd06.prod.outlook.com (157.56.234.133) by pod51017.outlook.com (10.3.4.165) with Microsoft SMTP Server (TLS) id 14.15.86.1; Mon, 18 Jun 2012 09:20:37 +0000 Message-ID: <023f01cd4d33$27c7f8a0$4001a8c0@gateway.2wire.net> From: t.petch To: Phil Shafer References: <201206151558.q5FFwgKY083225@idle.juniper.net> Date: Mon, 18 Jun 2012 10:17:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.234.133] X-FOPE-CRA-Verdict: 157.55.224.141$juniper.net%12218%2%btconnect.com%True%True%0$ X-OriginatorOrg: btconnect.com Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 09:20:42 -0000 ---- Original Message ----- From: "Phil Shafer" To: "Ladislav Lhotka" Cc: "Netconf" Sent: Friday, June 15, 2012 4:58 PM > Ladislav Lhotka writes: > >Of course, nobody can blame NETCONF for choosing XML in 2003. > > And hopefully no one will blame the w3c for choosing it for HTML5 > (in 2009 ;^). > > FWIW, I favor XML because it gives three axis of richness (hierarchy, > namespaces, attributes). Hierarchy gives you rich data, namespaces > give you rich extensibility, and attributes give you rich metadata. > NETCONF/YANG uses all three. Three axes of complexity, three axes within which to foul things up:-( When I first studied XML, I read a series of papers on its richness, how it could do things this way or that, you could use one way or another, etc etc etc. So someone creating with it has an easy task, they pick the options they are comfortable with. Those consuming have a difficult task, having to cope with every single option since someone somewhere will have used it. More generally, the creators of such things as XML underestimate the complexity of what they are living with day in, day out, and then do not realise why their ideas are not immediately seen for how good they are. To the creators, what they have created should seem simple, elementary, else it will be too complex for those not living with it day in day out. Not quite the same thing as producing a subset for constrained devices, more a question of producing a subset for constrained (human) users. Tom Petch > Thanks, > Phil > From Jonathan.Hansford@generaldynamics.uk.com Mon Jun 18 03:42: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 922D921F854E for ; Mon, 18 Jun 2012 03:42:47 -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 4QTOJfXtwrIT for ; Mon, 18 Jun 2012 03:42:46 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 59CE221F8510 for ; Mon, 18 Jun 2012 03:42:45 -0700 (PDT) Received: from [194.106.220.51:14967] by server-5.bemta-14.messagelabs.com id 71/FB-04343-4260FDF4; Mon, 18 Jun 2012 10:42:44 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-3.tower-92.messagelabs.com!1340016164!9950918!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13198 invoked from network); 18 Jun 2012 10:42:44 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-3.tower-92.messagelabs.com with SMTP; 18 Jun 2012 10:42:44 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 18 Jun 2012 11:42:45 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.137]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jun 2012 11:42:43 +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: Mon, 18 Jun 2012 11:42:44 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206C7E5D5@GDUKADH850.uk1.r-org.net> In-Reply-To: <201206141608.q5EG8PQb075493@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] we are NOT CONVERGING towards consensus Thread-Index: Ac1NPxgOQELj3XOQRpWLVcApyqD9gw== References: <29C30561-9607-4F67-814C-C9CB310C2FCD@tail-f.com> <201206141608.q5EG8PQb075493@idle.juniper.net> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 18 Jun 2012 10:42:43.0838 (UTC) FILETIME=[17A1F1E0:01CD4D3F] Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 10:42:47 -0000 Having returned to this thread after a few days off and therefore reading all the emails in one sitting, one thing seemed to crop up once in a while without apparently being followed up: On Wednesday, Carl wrote: This one is easy: the ones that buy into the many features of NETCONF that provides benefits well above and beyond the alternatives (including SNMP, SOAP, and REST)! If you don't think NETCONF provides tangible benefits over the alternatives; then don't use it. On Thursday, Phil wrote: Shouldn't we be putting time into evangelizing, promoting, using, building, and things that will help adoption instead of "2.0" efforts that will hamper it? And again: (c) we are not evangelizing our story sufficiently for folks to understand the value of the technologies. Over the last couple of years I have been trying to identify the most appropriate management approach for future programmes and finally came to the conclusion that NETCONF/YANG seemed to provide what we needed. However, apart from NETCONF Central and YANG Central, there was nothing readily available to help me reach that conclusion. (I at least managed to find a book on CIM/WBEM which managed to convince me that was not the direction I wanted to take!) Subsequently I have been reading the RFCs and following the netconf and netmod mailing lists. However I have often found it hard to see the wood for the trees. RFCs by their nature have to be rigorous and, for those already in the know, are a useful reference and reminder, but they do not provide an easy way into the subject. Back in February Juergen, replying to one of my emails, stated: If you want to start a draft on implementation guidelines, by all means, please do so. I am not saying everything is totally obvious from the specs. (And I guess this is even more true for NETCONF than it is for YANG.) Having a NETCONF / YANG implementation guidelines document at some point in time might really be useful. Unfortunately, even now I don't feel anywhere near knowledgeable enough to embark on such an endeavour, though such a document would certainly help.=20 And the problem I have is that I am trying to convince developers of the benefits of NETCONF/YANG when they are working flat out and don't have the time to get up to speed on a new technology, particularly with sparse documentation by way of an introduction to the benefits of such an approach. I have written a couple of documents introducing NETCONF and YANG, but would really benefit from some introductory documentation from those who already know both. I guess what I am trying to say is that, from a newby's perspective, there is a need for more evangelising and introductory material. If that could be made available, I would be more than willing to be an ignorant guinea pig who could review the output (though I like to think I am not as ignorant as once I was). For developers, An O'Relly publication (or, if necessary, a NETCONF/YANG for Dummies) would be really helpful. But together with that, something more lightweight and digestible might convince more of the benefits. One other thing, before I get off my soapbox... RFC3535 "Overview of the 2002 IAB Network Management Workshop" obviously had an influence on the development of NETCONF. Pulling on the information in that RFC (which many would probably not even stumble across) would make an excellent introduction to the reasons for NETCONF and the benefits it brings. I'll climb down now! Jonathan > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: 14 June 2012 17:08 > To: Netconf > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus >=20 > On Jun 13, 2012, at 20:41 PM, Ladislav Lhotka wrote: > > I don't really know the whole story, for sure XML was one of the reasons > against NETCONF. >=20 > Okay, so they liked: >=20 > interfaces: { > interface: { > name: "fe-0/0/0"; > description: "Local interface"; > } > } >=20 > instead of: >=20 > > > fe-0/0/0 > Local interface > > >=20 > I'm assuming the story can't be this simple. N/Y offers _much_ > more than a local, custom, JSON-based protocol can. The volume of > functionality they'll have to brew on their own is large. >=20 > So that means we can either believe that N/Y adoption is limited because: >=20 > (a) we do not have open source tools of sufficient quality and > functionality. > (b) those tools do not have a community of support for them. > (c) we are not evangelizing our story sufficiently for folks to > understand the value of the technologies. > (d) we do not integrate well with other software. > (e) we aren't putting our time into issues that matter. >=20 > _or_ we can believe N/Y adoption is limited because: >=20 > (1) users have an insane fear of angle brackets. > (2) connection startup is ugly. >=20 > FWIW: I can easily admit that dealing with JSON in javascript is > easier than dealing with XML, but I firmly believe if we had a > XMLParse() that made natively-keyed objects like JSONParse(), this > would not be an issue. (And I don't know how many network mgmt > apps are being written in javascript anyway. I'm guessing that > bind10 is not.) >=20 > Thanks, > Phil 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@yumaworks.com Mon Jun 18 08:00: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 840C121F86DE for ; Mon, 18 Jun 2012 08:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 em+rcEajHIy9 for ; Mon, 18 Jun 2012 08:00:32 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAC521F86DB for ; Mon, 18 Jun 2012 08:00:27 -0700 (PDT) Received: by eekd4 with SMTP id d4so1818538eek.31 for ; Mon, 18 Jun 2012 08:00:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OOTIKStzzHmufpqRSJLASiRbahewsgj8J2UW8Azj5kQ=; b=BxmVzWQxT/2nKT8fsWvaOeI2H54N9aYiuQvh/kl5gsbnNOKYNigTjvG6kqcuISJ8IZ 2+9DlpMdC/VWVY986eozef4X3iQadYhOws9olq1+yhnlzX/+IGvtRiQ+5FRA9VDPgx4b h9C40UnnletKH/xj9IC04x9tfZpUh7SRvzVw5vut7eREj/ydfYG/rird5mmkl1H+ZmLj TeWq5ARzTmrJZIKFDni2Y1IouR3Q4Hmehj/H4gW+p5VnAiuDnH6SJ44Z2A9rEyqU1Ido f7vBd7ajaAa8qtYScPa/vB2Oj7P9UygpdGjPsosUfGUBoMVlam3DBqHFE27i3iQSy13j vz0w== MIME-Version: 1.0 Received: by 10.152.105.235 with SMTP id gp11mr9078187lab.44.1340031626895; Mon, 18 Jun 2012 08:00:26 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Mon, 18 Jun 2012 08:00:26 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <023f01cd4d33$27c7f8a0$4001a8c0@gateway.2wire.net> References: <201206151558.q5FFwgKY083225@idle.juniper.net> <023f01cd4d33$27c7f8a0$4001a8c0@gateway.2wire.net> Date: Mon, 18 Jun 2012 08:00:26 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=f46d0407143b1be2e004c2c06de7 X-Gm-Message-State: ALoCoQk9nsWT4RV3iiwgs3q7BiYoTSnwlJZpGomzLbp/b1YYka424lggLIgMnSm9INlGDzw21T5s Cc: Netconf Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 15:00:34 -0000 --f46d0407143b1be2e004c2c06de7 Content-Type: text/plain; charset=ISO-8859-1 Hi, I think it was probably a mistake to couple the NETCONF protocol to XML encoding. It relies on XML attributes for to work. The other uses of XML attributes were just ad-hoc decisions that could have been done with elements instead. Andy On Mon, Jun 18, 2012 at 2:17 AM, t.petch wrote: > ---- Original Message ----- > From: "Phil Shafer" > To: "Ladislav Lhotka" > Cc: "Netconf" > Sent: Friday, June 15, 2012 4:58 PM > > > Ladislav Lhotka writes: > > >Of course, nobody can blame NETCONF for choosing XML in 2003. > > > > And hopefully no one will blame the w3c for choosing it for HTML5 > > (in 2009 ;^). > > > > FWIW, I favor XML because it gives three axis of richness (hierarchy, > > namespaces, attributes). Hierarchy gives you rich data, namespaces > > give you rich extensibility, and attributes give you rich metadata. > > NETCONF/YANG uses all three. > > Three axes of complexity, three axes within which to foul things up:-( > > When I first studied XML, I read a series of papers on its richness, how > it could do things this way or that, you could use one way or another, > etc etc etc. So someone creating with it has an easy task, they pick > the options they are comfortable with. Those consuming have a difficult > task, having to cope with every single option since someone somewhere > will have used it. > > More generally, the creators of such things as XML underestimate the > complexity of what they are living with day in, day out, and then do not > realise why their ideas are not immediately seen for how good they are. > To the creators, what they have created should seem simple, elementary, > else it will be too complex for those not living with it day in day out. > > Not quite the same thing as producing a subset for constrained devices, > more a question of producing a subset for constrained (human) users. > > Tom Petch > > > Thanks, > > Phil > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f46d0407143b1be2e004c2c06de7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I think it was probably a mistake to couple the NETC= ONF protocol to XML encoding.
It relies on XML attributes for <= ;edit-config> to work. =A0The other uses of XML attributes
wer= e just ad-hoc decisions that could have been done with elements instead.


Andy

=A0
<= div>
On Mon, Jun 18, 2012 at 2:17 AM, t.petch= <ietfc@btconnect.com> wrote:
---- Original Message -----
From: "Phil Shafer" <phil@= juniper.net>
To: "Ladislav Lhotka" <lhotka= @nic.cz>
Cc: "Netconf" <netconf@iet= f.org>
Sent: Friday, June 15, 2012 4:58 PM

> Ladislav Lhotka writes:
> >Of course, nobody can blame NETCONF for choosing XML in 2003.
>
> And hopefully no one will blame the w3c for choosing it for HTML5
> (in 2009 ;^).
>
> FWIW, I favor XML because it gives three axis of richness (hierarchy,<= br> > namespaces, attributes). =A0Hierarchy gives you rich data, namespaces<= br> > give you rich extensibility, and attributes give you rich metadata. > NETCONF/YANG uses all three.

Three axes of complexity, three axes within which to foul things up:-(

When I first studied XML, I read a series of papers on its richness, how it could do things this way or that, you could use one way or another,
etc etc etc. =A0So someone creating with it has an easy task, they pick
the options they are comfortable with. =A0Those consuming have a difficult<= br> task, having to cope with every single option since someone somewhere
will have used it.

More generally, the creators of such things as XML underestimate the
complexity of what they are living with day in, day out, and then do not realise why their ideas are not immediately seen for how good they are.
To the creators, what they have created should seem simple, elementary,
else it will be too complex for those not living with it day in day out.
Not quite the same thing as producing a subset for constrained devices,
more a question of producing a subset for constrained (human) users.

Tom Petch

> Thanks,
> =A0Phil
>


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--f46d0407143b1be2e004c2c06de7-- From andy@yumaworks.com Mon Jun 18 08:54:04 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 24FD421F85A5 for ; Mon, 18 Jun 2012 08:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 V9Y+0N-TZaMV for ; Mon, 18 Jun 2012 08:54:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E81921F858D for ; Mon, 18 Jun 2012 08:54:02 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4933536lbb.31 for ; Mon, 18 Jun 2012 08:54:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zl9+ZG+91kT2oNbLPGY79cH1PYn+cWsm4bXvOemoqZc=; b=BREEnqpr29WHemKsn02o+dlCyF4heuOSONE6OgZUew4CezJHRRzlwUJdXuyZunaccN zMx5MlCTHyMAkBbYrTiHHSyDigq2Ux/l8XGkEzZSOo2H8lW3+GdGoW+lQfN2zEhXXbz1 BgLqlnWQvBk0CozeQemg51CquORrMjKx2J4+5AKpqD9uUFoyNU56CB54MXqLzqmvFZsn hMb7M9DNnWN22JuJn/XLomI3vGVtavQTemAFlYQspRO69vI8RPM7+b1roTHlmsyW+bvg 3Ybr76UP801HPdD4SQhCOBtYUE3AOCx++qDpaQHPWY9xOWlRvUlPkLv3aVdYgcIhXsAP G4sg== MIME-Version: 1.0 Received: by 10.152.113.199 with SMTP id ja7mr4491934lab.10.1340034840907; Mon, 18 Jun 2012 08:54:00 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Mon, 18 Jun 2012 08:54:00 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206C7E5D5@GDUKADH850.uk1.r-org.net> References: <29C30561-9607-4F67-814C-C9CB310C2FCD@tail-f.com> <201206141608.q5EG8PQb075493@idle.juniper.net> <83C941F7F59F3F42AC017AD1E650546206C7E5D5@GDUKADH850.uk1.r-org.net> Date: Mon, 18 Jun 2012 08:54:00 -0700 Message-ID: From: Andy Bierman To: Jonathan.Hansford@generaldynamics.uk.com Content-Type: multipart/alternative; boundary=f46d04088ee5add0b504c2c12cdd X-Gm-Message-State: ALoCoQlH49SsDB824m4v+JF47tzKkxhNP0UBxh7pY3tcQfaGzNDxm7ascVQy850L2ko3EVEWJ26a Cc: netconf@ietf.org Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 15:54:04 -0000 --f46d04088ee5add0b504c2c12cdd Content-Type: text/plain; charset=ISO-8859-1 Hi, For better or worse, RFCs tend to leave out most of the rationale for a particular decision. This means RFCs tend to be horrible for tutorial reading. IMO, until "Cloud" came along, NETCONF was seen by vendors as an internal protocol so the internal NMS dept. could control the hardware they sell. Now some of their customers have business cases for device programmability, so maybe the visibility of NETCONF will change. It's a lot of work to write books, free software tools, free WEB sites, etc., so I'm not surprised that these resources are scarce for NETCONF. I agree we could write more RFCs to help but nobody is volunteering. The focus is on standard data models for NETCONF at this point. But even with lots of free help, that doesn't change this thread. I would sum up this thread as: - The vendors/users of products where NETCONF is a good use-case fit don't see any need to make changes. - The vendors/users of products where device configuration is needed, but NETCONF does not look like a good fit, want to make changes to better address their use cases. I do not see any compelling reasons to introduce a new version of the NETCONF protocol at this time. NETCONF-Light is not the right CM solution for tiny boxes, so better to just leave what works alone. I don't think NETCONF-Light will have a significant impact on server implementation footprint, and it is too state-full and too flexible for the client to be efficiently implemented in the server. I am also concerned that removing and just using for replacing the entire running config at once is the wrong way to do CM. Andy On Mon, Jun 18, 2012 at 3:42 AM, wrote: > Having returned to this thread after a few days off and therefore > reading all the emails in one sitting, one thing seemed to crop up once > in a while without apparently being followed up: > > On Wednesday, Carl wrote: > > This one is easy: the ones that buy into the many features of NETCONF > that provides benefits well above and beyond the alternatives (including > SNMP, SOAP, and REST)! If you don't think NETCONF provides tangible > benefits over the alternatives; then don't use it. > > On Thursday, Phil wrote: > > Shouldn't we be putting time into evangelizing, promoting, using, > building, and things that will help adoption instead of "2.0" efforts > that will hamper it? > > And again: > > (c) we are not evangelizing our story sufficiently for folks to > understand the value of the technologies. > > Over the last couple of years I have been trying to identify the most > appropriate management approach for future programmes and finally came > to the conclusion that NETCONF/YANG seemed to provide what we needed. > However, apart from NETCONF Central and YANG Central, there was nothing > readily available to help me reach that conclusion. (I at least managed > to find a book on CIM/WBEM which managed to convince me that was not the > direction I wanted to take!) > > Subsequently I have been reading the RFCs and following the netconf and > netmod mailing lists. However I have often found it hard to see the wood > for the trees. RFCs by their nature have to be rigorous and, for those > already in the know, are a useful reference and reminder, but they do > not provide an easy way into the subject. > > Back in February Juergen, replying to one of my emails, stated: > > If you want to start a draft on implementation guidelines, by all means, > please do so. I am not saying everything is totally obvious from the > specs. (And I guess this is even more true for NETCONF than it is for > YANG.) Having a NETCONF / YANG implementation guidelines document at > some point in time might really be useful. > > Unfortunately, even now I don't feel anywhere near knowledgeable enough > to embark on such an endeavour, though such a document would certainly > help. > > And the problem I have is that I am trying to convince developers of the > benefits of NETCONF/YANG when they are working flat out and don't have > the time to get up to speed on a new technology, particularly with > sparse documentation by way of an introduction to the benefits of such > an approach. > > I have written a couple of documents introducing NETCONF and YANG, but > would really benefit from some introductory documentation from those who > already know both. > > I guess what I am trying to say is that, from a newby's perspective, > there is a need for more evangelising and introductory material. If that > could be made available, I would be more than willing to be an ignorant > guinea pig who could review the output (though I like to think I am not > as ignorant as once I was). > > For developers, An O'Relly publication (or, if necessary, a NETCONF/YANG > for Dummies) would be really helpful. But together with that, something > more lightweight and digestible might convince more of the benefits. > > One other thing, before I get off my soapbox... RFC3535 "Overview of the > 2002 IAB Network Management Workshop" obviously had an influence on the > development of NETCONF. Pulling on the information in that RFC (which > many would probably not even stumble across) would make an excellent > introduction to the reasons for NETCONF and the benefits it brings. > > I'll climb down now! > > Jonathan > > > -----Original Message----- > > From: Phil Shafer [mailto:phil@juniper.net] > > Sent: 14 June 2012 17:08 > > To: Netconf > > Subject: Re: [Netconf] we are NOT CONVERGING towards consensus > > > > On Jun 13, 2012, at 20:41 PM, Ladislav Lhotka wrote: > > > I don't really know the whole story, for sure XML was one of the > reasons > > against NETCONF. > > > > Okay, so they liked: > > > > interfaces: { > > interface: { > > name: "fe-0/0/0"; > > description: "Local interface"; > > } > > } > > > > instead of: > > > > > > > > fe-0/0/0 > > Local interface > > > > > > > > I'm assuming the story can't be this simple. N/Y offers _much_ > > more than a local, custom, JSON-based protocol can. The volume of > > functionality they'll have to brew on their own is large. > > > > So that means we can either believe that N/Y adoption is limited > because: > > > > (a) we do not have open source tools of sufficient quality and > > functionality. > > (b) those tools do not have a community of support for them. > > (c) we are not evangelizing our story sufficiently for folks to > > understand the value of the technologies. > > (d) we do not integrate well with other software. > > (e) we aren't putting our time into issues that matter. > > > > _or_ we can believe N/Y adoption is limited because: > > > > (1) users have an insane fear of angle brackets. > > (2) connection startup is ugly. > > > > FWIW: I can easily admit that dealing with JSON in javascript is > > easier than dealing with XML, but I firmly believe if we had a > > XMLParse() that made natively-keyed objects like JSONParse(), this > > would not be an issue. (And I don't know how many network mgmt > > apps are being written in javascript anyway. I'm guessing that > > bind10 is not.) > > > > Thanks, > > Phil > > > > 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 should > not disclose, distribute, print, copy or make other use of this email or > its attachments. Such actions, in fact, may be unlawful. In compliance with > the various Regulations and Acts, General Dynamics United Kingdom Limited > reserves the right to monitor (and examine for viruses) all emails and > email attachments, both inbound and outbound. Email communications and > their attachments may not be secure or error- or virus-free and the company > does not accept liability or responsibility for such matters or the > consequences thereof. General Dynamics United Kingdom Limited, Registered > Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and > Wales No: 1911653. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f46d04088ee5add0b504c2c12cdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

For better or worse, RFCs tend to leave out most of = the rationale for a particular decision.
This means RFCs tend to = be horrible for tutorial reading.

IMO, until "= ;Cloud" came along, NETCONF was seen by vendors as an internal protoco= l so
the internal NMS dept. could control the hardware they sell. =A0Now so= me of their customers
have business cases for device programmabil= ity, so maybe the visibility of NETCONF will change.

It's a lot of work to write books, free software tools, free WEB s= ites, etc.,
so I'm not surprised that these resources are sca= rce for NETCONF.
I agree we could write more RFCs to help but nob= ody is volunteering.
The focus is on standard data models for NETCONF at this point.
<= div>
But even with lots of free help, that doesn't change= this thread.

I would sum up this thread as:

=A0 - The vendors/users of products where NETCONF is a = good use-case fit don't see any
=A0 =A0 =A0need to make chang= es.

=A0- The vendors/users of products where devic= e configuration is needed, but NETCONF does not
=A0 =A0 look like a good fit, want to make changes to better address t= heir use cases.

I do not see any compelling reason= s to introduce a new version of the NETCONF protocol
at this time= . =A0NETCONF-Light is not the right CM solution for tiny boxes, so better t= o
just leave what works alone.

I don't thin= k NETCONF-Light will have a significant impact on server implementation=A0f= ootprint, and
it is too state-full and too flexible for the clien= t to be efficiently implemented in the server.
I am also concerned that removing <edit-config> and just using &= lt;copy-config>
for replacing the entire running config at onc= e is the wrong way to do CM.


Andy


On Mon, Jun 1= 8, 2012 at 3:42 AM, <Jonathan.Hansford@generaldyna= mics.uk.com> wrote:
Having returned to this thread after a few d= ays off and therefore
reading all the emails in one sitting, one thing seemed to crop up once
in a while without apparently being followed up:

On Wednesday, Carl wrote:

This one is easy: the ones that buy into the many features of NETCONF
that provides benefits well above and beyond the alternatives (including SNMP, SOAP, and REST)! If you don't think NETCONF provides tangible
benefits over the alternatives; then don't use it.

On Thursday, Phil wrote:

Shouldn't we be putting time into evangelizing, promoting, using,
building, and things that will help adoption instead of "2.0" eff= orts
that will hamper it?

And again:

(c) we are not evangelizing our story sufficiently for folks to
understand the value of the technologies.

Over the last couple of years I have been trying to identify the most
appropriate management approach for future programmes and finally came
to the conclusion that NETCONF/YANG seemed to provide what we needed.
However, apart from NETCONF Central and YANG Central, there was nothing
readily available to help me reach that conclusion. (I at least managed
to find a book on CIM/WBEM which managed to convince me that was not the direction I wanted to take!)

Subsequently I have been reading the RFCs and following the netconf and
netmod mailing lists. However I have often found it hard to see the wood for the trees. RFCs by their nature have to be rigorous and, for those
already in the know, are a useful reference and reminder, but they do
not provide an easy way into the subject.

Back in February Juergen, replying to one of my emails, stated:

If you want to start a draft on implementation guidelines, by all means, please do so. I am not saying everything is totally obvious from the
specs. (And I guess this is even more true for NETCONF than it is for
YANG.) Having a NETCONF / YANG implementation guidelines document at
some point in time might really be useful.

Unfortunately, even now I don't feel anywhere near knowledgeable enough=
to embark on such an endeavour, though such a document would certainly
help.

And the problem I have is that I am trying to convince developers of the benefits of NETCONF/YANG when they are working flat out and don't have<= br> the time to get up to speed on a new technology, particularly with
sparse documentation by way of an introduction to the benefits of such
an approach.

I have written a couple of documents introducing NETCONF and YANG, but
would really benefit from some introductory documentation from those who already know both.

I guess what I am trying to say is that, from a newby's perspective, there is a need for more evangelising and introductory material. If that could be made available, I would be more than willing to be an ignorant
guinea pig who could review the output (though I like to think I am not
as ignorant as once I was).

For developers, An O'Relly publication (or, if necessary, a NETCONF/YAN= G
for Dummies) would be really helpful. But together with that, something
more lightweight and digestible might convince more of the benefits.

One other thing, before I get off my soapbox... RFC3535 "Overview of t= he
2002 IAB Network Management Workshop" obviously had an influence on th= e
development of NETCONF. Pulling on the information in that RFC (which
many would probably not even stumble across) would make an excellent
introduction to the reasons for NETCONF and the benefits it brings.

I'll climb down now!

Jonathan

> -----Original Message-----
> From: Phil Shafer [mailto:phil@jun= iper.net]
> Sent: 14 June 2012 17:08
> To: Netconf
> Subject: Re: [Netconf] we are NOT CONVERGING towards consensus
>
> On Jun 13, 2012, at 20:41 PM, Ladislav Lhotka wrote:
> > I don't really know the whole story, for sure XML was one of = the
reasons
> against NETCONF.
>
> Okay, so they liked:
>
> interfaces: {
> =A0 =A0 interface: {
> =A0 =A0 =A0 =A0 name: "fe-0/0/0";
> =A0 =A0 =A0 =A0 description: "Local interface";
> =A0 =A0 }
> }
>
> instead of:
>
> <interfaces>
> =A0 =A0 <interface>
> =A0 =A0 =A0 =A0 <name>fe-0/0/0</name>
> =A0 =A0 =A0 =A0 <description>Local interface</description>=
> =A0 =A0 </interface>
> </interfaces>
>
> I'm assuming the story can't be this simple. =A0N/Y offers _mu= ch_
> more than a local, custom, JSON-based protocol can. =A0The volume of > functionality they'll have to brew on their own is large.
>
> So that means we can either believe that N/Y adoption is limited
because:
>
> (a) we do not have open source tools of sufficient quality and
> functionality.
> (b) those tools do not have a community of support for them.
> (c) we are not evangelizing our story sufficiently for folks to
> understand the value of the technologies.
> (d) we do not integrate well with other software.
> (e) we aren't putting our time into issues that matter.
>
> _or_ we can believe N/Y adoption is limited because:
>
> (1) users have an insane fear of angle brackets.
> (2) connection startup is ugly.
>
> FWIW: =A0I can easily admit that dealing with JSON in javascript is > easier than dealing with XML, but I firmly believe if we had a
> XMLParse() that made natively-keyed objects like JSONParse(), this
> would not be an issue. =A0(And I don't know how many network mgmt<= br> > apps are being written in javascript anyway. =A0I'm guessing that<= br> > bind10 is not.)
>
> Thanks,
> =A0Phil



This email and any files attached are intended for the addressee and may co= ntain information of a confidential nature. If you are not the intended rec= ipient, be aware that this email was sent to you in error and you should no= t disclose, distribute, print, copy or make other use of this email or its = attachments. Such actions, in fact, may be unlawful. In compliance with the= various Regulations and Acts, General Dynamics United Kingdom Limited rese= rves the right to monitor (and examine for viruses) all emails and email at= tachments, both inbound and outbound. Email communications and their attach= ments may not be secure or error- or virus-free and the company does not ac= cept liability or responsibility for such matters or the consequences there= of. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn = Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--f46d04088ee5add0b504c2c12cdd-- From ietfc@btconnect.com Mon Jun 18 10:16: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 3AA1221F86EE for ; Mon, 18 Jun 2012 10:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFsiLVuD4CzL for ; Mon, 18 Jun 2012 10:16:32 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2E321F86E0 for ; Mon, 18 Jun 2012 10:16:32 -0700 (PDT) Received: from mail109-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Jun 2012 17:15:12 +0000 Received: from mail109-va3 (localhost [127.0.0.1]) by mail109-va3-R.bigfish.com (Postfix) with ESMTP id CC9622601BC; Mon, 18 Jun 2012 17:15:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT007.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail109-va3 (localhost.localdomain [127.0.0.1]) by mail109-va3 (MessageSwitch) id 1340039710273614_1899; Mon, 18 Jun 2012 17:15:10 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.245]) by mail109-va3.bigfish.com (Postfix) with ESMTP id 3F3816003F; Mon, 18 Jun 2012 17:15:10 +0000 (UTC) Received: from DB3PRD0702HT007.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 17:15:09 +0000 Received: from DB3PRD0510HT001.eurprd05.prod.outlook.com (157.56.252.37) by pod51017.outlook.com (10.3.4.168) with Microsoft SMTP Server (TLS) id 14.15.86.1; Mon, 18 Jun 2012 17:16:25 +0000 Message-ID: <00b801cd4d75$9f6dd4a0$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <29C30561-9607-4F67-814C-C9CB310C2FCD@tail-f.com><201206141608.q5EG8PQb075493@idle.juniper.net> <83C941F7F59F3F42AC017AD1E650546206C7E5D5@GDUKADH850.uk1.r-org.net> Date: Mon, 18 Jun 2012 18:12:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.37] X-OriginatorOrg: btconnect.com Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 17:16:33 -0000 ----- Original Message ----- From: To: Sent: Monday, June 18, 2012 11:42 AM > Having returned to this thread after a few days off and therefore > reading all the emails in one sitting, one thing seemed to crop up once > in a while without apparently being followed up: > > On Wednesday, Carl wrote: > > This one is easy: the ones that buy into the many features of NETCONF > that provides benefits well above and beyond the alternatives (including > SNMP, SOAP, and REST)! If you don't think NETCONF provides tangible > benefits over the alternatives; then don't use it. > > On Thursday, Phil wrote: > > Shouldn't we be putting time into evangelizing, promoting, using, > building, and things that will help adoption instead of "2.0" efforts > that will hamper it? > > And again: > > (c) we are not evangelizing our story sufficiently for folks to > understand the value of the technologies. > > Over the last couple of years I have been trying to identify the most > appropriate management approach for future programmes and finally came > to the conclusion that NETCONF/YANG seemed to provide what we needed. > However, apart from NETCONF Central and YANG Central, there was nothing > readily available to help me reach that conclusion. (I at least managed > to find a book on CIM/WBEM which managed to convince me that was not the > direction I wanted to take!) > > Subsequently I have been reading the RFCs and following the netconf and > netmod mailing lists. However I have often found it hard to see the wood > for the trees. RFCs by their nature have to be rigorous and, for those > already in the know, are a useful reference and reminder, but they do > not provide an easy way into the subject. > > Back in February Juergen, replying to one of my emails, stated: > > If you want to start a draft on implementation guidelines, by all means, > please do so. I am not saying everything is totally obvious from the > specs. (And I guess this is even more true for NETCONF than it is for > YANG.) Having a NETCONF / YANG implementation guidelines document at > some point in time might really be useful. > > Unfortunately, even now I don't feel anywhere near knowledgeable enough > to embark on such an endeavour, though such a document would certainly > help. Jonathan That probably makes you best qualified to produce such a document. As I say every now and then, experts sometimes produce documents that are comprehensible only to other experts, whereas someone less knowledgeable better recognises what is hard to understand, what the key points are and what is needed to make it clear. Yes, you may get a lot wrong before you get it right, but what you eventually produce may well be better than that which anyone else could produce. Honest. Tom Petch > And the problem I have is that I am trying to convince developers of the > benefits of NETCONF/YANG when they are working flat out and don't have > the time to get up to speed on a new technology, particularly with > sparse documentation by way of an introduction to the benefits of such > an approach. > > I have written a couple of documents introducing NETCONF and YANG, but > would really benefit from some introductory documentation from those who > already know both. > > I guess what I am trying to say is that, from a newby's perspective, > there is a need for more evangelising and introductory material. If that > could be made available, I would be more than willing to be an ignorant > guinea pig who could review the output (though I like to think I am not > as ignorant as once I was). > > For developers, An O'Relly publication (or, if necessary, a NETCONF/YANG > for Dummies) would be really helpful. But together with that, something > more lightweight and digestible might convince more of the benefits. > > One other thing, before I get off my soapbox... RFC3535 "Overview of the > 2002 IAB Network Management Workshop" obviously had an influence on the > development of NETCONF. Pulling on the information in that RFC (which > many would probably not even stumble across) would make an excellent > introduction to the reasons for NETCONF and the benefits it brings. > > I'll climb down now! > > Jonathan From kwatsen@juniper.net Mon Jun 18 10:54: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 3F3E221F86E0 for ; Mon, 18 Jun 2012 10:54:14 -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 BP2-1wibmreK for ; Mon, 18 Jun 2012 10:54:13 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD721F86D6 for ; Mon, 18 Jun 2012 10:54:13 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT99rP7Qzf5xeb46CnwMswn00IjLdxAW2@postini.com; Mon, 18 Jun 2012 10:54:13 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; Mon, 18 Jun 2012 10:53:27 -0700 From: Kent Watsen To: Netconf Date: Mon, 18 Jun 2012 10:53:24 -0700 Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? Thread-Index: Ac1ELOWid2Byi1GTSGqfdXnT5PQrRgJRm0dA Message-ID: References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> In-Reply-To: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 17:54:14 -0000 [just back from PTO, hence the delayed response] I support a "netconf:base:1.2" that requires the following reduced set of b= ase features: - copy-config - close-session - get-config (no filtering) And defines distinct capabilities to enable all the base:1.1 operations. Notes: 1. I've read all the postings to date 2. I'm OK calling this an "upgrade". It doesn't seem too much of a stret= ch to consider "modularization" as the feature being added. =20 3. I'm OK with the "backwards compatibility" of the solution, as existing= servers would continue to advertise their currently supported 1.0 and/or 1.1 b= ases and, as section 8.1 says: "If more than one protocol version URI in common = is present,=20 then the highest numbered (most recent) protocol version MUST be used = by both peers." =20 4. The reduced set of operations listed above are the same that Andy list= ed here (http://www.ietf.org/mail-archive/web/netconf/current/msg07501.html). = Even in the most extreme case, I rather have a device provide this NETCONF bas= e than=20 have to resort to another protocol (ftp). That said, none of Juniper= 's devices are this constrained: one would only not advertise "locking" and anoth= er would only not advertize "subtree filtering" (assuming "base:1.2" is adverti= zed)=20 =20 Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Bert Wijnen (IETF) Sent: Wednesday, June 06, 2012 5:39 PM To: Netconf Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensus= on the way forwardwithNetconf-Light] Dear WG participants, it seem very difficult to converge on the topic of NetConf Light. We have evaluated the mailing lists discussions and have had conversations with several key participants. We also discussed this with our AD. From all that, we believe that an acceptable approach will be that we try to get approval (i.e. a chartered work item) for: Develop standards track NETCONF 2.0 with a new modular base version, which has a reduced set of mandatory features. The present functionality can be used as optional capabilities or YANG features. The "reduced set of mandatory features" is of course to be developed by the WG once we are chartered for this work. =20 Please express your support or objections w.r.t. to this proposal. Pls do so asap, but in any event, no later than June 20th 2012 (any timezone) Bert and Mehmet WG chairs for NETCONF _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Mon Jun 18 11:35: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 91EC821F8611 for ; Mon, 18 Jun 2012 11:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 n1GVQiveIRlT for ; Mon, 18 Jun 2012 11:35:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA44021F8620 for ; Mon, 18 Jun 2012 11:35:32 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5115933lbb.31 for ; Mon, 18 Jun 2012 11:35:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=c9ibmmz4++S3oVKIjCyppYK8mnRk6+RKtg2lgMHSyKI=; b=T+gpgvaa63ZRbCpJ4Rtoc1R5JDiiwYpiFKU9Q5NSBVhj1G90H/5ct78xQMTpHjEjov 8ZXur69zlbg75v+rm0qwsVMK0cbYPj6Ef6hZ28VJ974z/1EM75XmpdfwQELPc4ObGJyc szQVvzlGRIb/LBH0ahh9f/uoccNbs0gMLPv8saUYyto3ZseLOqvuXsuQEfu80f3r8np1 7+ntNbmdE2ZacNd+991gCGAupZd+4z3L4JIQsKFqpSfYl9AneynYrz1wgWld+NSKfGFd lzyJjll9TESX5V8kIbIGxStuw9nkQwVaHeE/5Bdot6WUt0LGACZARWAVzgSH5OO8Av7I U55w== MIME-Version: 1.0 Received: by 10.112.32.35 with SMTP id f3mr6930684lbi.47.1340044531695; Mon, 18 Jun 2012 11:35:31 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Mon, 18 Jun 2012 11:35:31 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> Date: Mon, 18 Jun 2012 11:35:31 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=bcaec554dfee4b815204c2c36e22 X-Gm-Message-State: ALoCoQm607P5Ce93kALFAAM8QxQKxX4Arb71IkyHKwr8GoGUXPO2niIdGOlC+KW27UR3sIwSNe4/ Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 18:35:37 -0000 --bcaec554dfee4b815204c2c36e22 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 18, 2012 at 10:53 AM, Kent Watsen wrote: > > [just back from PTO, hence the delayed response] > > > I support a "netconf:base:1.2" that requires the following reduced set of > base features: > > - copy-config > - close-session > - get-config (no filtering) > > And defines distinct capabilities to enable all the base:1.1 operations. > > I prefer the current name and capability "netconf-light". That is more clear to users. Using copy-config to write to the device is optional-to-implement, but a capability flag 'writes-allowed' could fix that. Copy-config requires the entire config be present every time anything is edited. This seems inefficient, even for small devices. Copy-config allows an arbitrary mix of all-or-nothing changes just like "big NETCONF". This seems much more expensive to implement than 1-resource-at-a-time (like CLI or REST). I do not strongly object to NETCONF-Light, but I think it will have a negative impact on NETCONF usability and interoperability. There is some assumption that vendors will start here and raise the bar by adding missing standard components. It would be perfectly valid for a vendor to "raise the bar" by replacing the missing standard components with proprietary components. That reduces the standard to a read-only get-config w/o any standard filtering. The read-only copy-config is redundant. It is only relevant here for writing, which is optional. Andy > Notes: > > 1. I've read all the postings to date > > 2. I'm OK calling this an "upgrade". It doesn't seem too much of a > stretch to > consider "modularization" as the feature being added. > > 3. I'm OK with the "backwards compatibility" of the solution, as existing > servers > would continue to advertise their currently supported 1.0 and/or 1.1 > bases and, > as section 8.1 says: "If more than one protocol version URI in common > is present, > then the highest numbered (most recent) protocol version MUST be used > by both > peers." > > 4. The reduced set of operations listed above are the same that Andy > listed here > (http://www.ietf.org/mail-archive/web/netconf/current/msg07501.html). > Even in > the most extreme case, I rather have a device provide this NETCONF > base than > have to resort to another protocol (ftp). That said, none of > Juniper's devices > are this constrained: one would only not advertise "locking" and > another would > only not advertize "subtree filtering" (assuming "base:1.2" is > advertized) > > > Thanks, > Kent > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Bert Wijnen (IETF) > Sent: Wednesday, June 06, 2012 5:39 PM > To: Netconf > Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a > consensus on the way forwardwithNetconf-Light] > > Dear WG participants, > > it seem very difficult to converge on the topic of NetConf > Light. We have evaluated the mailing lists discussions and > have had conversations with several key participants. We > also discussed this with our AD. From all that, we believe > that an acceptable approach will be that we try to get > approval (i.e. a chartered work item) for: > > Develop standards track NETCONF 2.0 with a new > modular base version, which has a reduced set of > mandatory features. > The present functionality can be used as optional > capabilities or YANG features. > > The "reduced set of mandatory features" is of course to be > developed by the WG once we are chartered for this work. > > Please express your support or objections w.r.t. to this > proposal. Pls do so asap, but in any event, no later than > June 20th 2012 (any timezone) > > Bert and Mehmet > WG chairs for NETCONF > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --bcaec554dfee4b815204c2c36e22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 18, 2012 at 10:53 AM, Kent W= atsen <kwatsen@juniper.net> wrote:

[just back from PTO, hence the delayed response]


I support a "netconf:base:1.2" that requires the following reduce= d set of base features:

=A0 - copy-config
=A0 - close-session
=A0 - get-config (no filtering)

And defines distinct capabilities to enable all the base:1.1 operations.

I prefer the current name and capabili= ty "netconf-light".
That is more clear to users.=A0

Using copy-config to write=A0to the device is optiona= l-to-implement,=A0
but a capability flag 'writes-allowed' could fix that.

Copy-config requires the entire config be present every t= ime anything is edited.
This seems inefficient, even for small de= vices. =A0Copy-config allows an arbitrary
mix of all-or-nothing changes just like "big NETCONF". =A0Th= is seems much more expensive
to implement than 1-resource-at-a-ti= me (like CLI or REST).

I do not strongly object to= NETCONF-Light, but I think it will have a negative impact
on NETCONF usability and interoperability. There is some assumption th= at vendors will
start here and raise the bar by adding missing st= andard components.

It would be perfectly valid for= a vendor to "raise the bar" by replacing the
missing standard components with proprietary components.
Tha= t reduces the standard to a read-only get-config w/o any standard filtering= .
The read-only copy-config is redundant. =A0It is only relevant = here=A0for writing, which is optional.




Andy
=



Notes:

=A01. I've read all the postings to date

=A02. I'm OK calling this an "upgrade". =A0It doesn't se= em too much of a stretch to
=A0 =A0 consider "modularization" as the feature being added.
=A03. I'm OK with the "backwards compatibility" of the solut= ion, as existing servers
=A0 =A0 would continue to advertise their currently supported 1.0 and/or 1= .1 bases and,
=A0 =A0 as section 8.1 says: "If more than one protocol version URI i= n common is present,
=A0 =A0 then the highest numbered (most recent) protocol version MUST be u= sed by both
=A0 =A0 peers."

=A04. The reduced set of operations listed above are the same that Andy li= sted here
=A0 =A0 (http://www.ietf.org/mail-archive/web/netcon= f/current/msg07501.html). =A0Even in
=A0 =A0 the most extreme case, I rather have a device provide this NETCONF= base than
=A0 =A0 have to resort to another protocol (ftp). =A0 That said, none of J= uniper's devices
=A0 =A0 are this constrained: one would only not advertise "locking&q= uot; and another would
=A0 =A0 only not advertize "subtree filtering" (assuming "b= ase:1.2" is advertized)


Thanks,
Kent


-----Original Message-----
From: netconf-bounces@ietf.org<= /a> [mailto:netconf-bounces@iet= f.org] On Behalf Of Bert Wijnen (IETF)
Sent: Wednesday, June 06, 2012 5:39 PM
To: Netconf
Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensus= on the way forwardwithNetconf-Light]

Dear WG participants,

it seem very difficult to converge on the topic of NetConf
Light. We have evaluated the mailing lists discussions and
have had conversations with several key participants. We
also discussed this with our AD. From all that, we believe
that an acceptable approach will be that we try to get
approval (i.e. a chartered work item) for:

=A0 =A0 Develop standards track NETCONF 2.0 with a new
=A0 =A0 modular base version, which has a reduced set of
=A0 =A0 mandatory features.
=A0 =A0 The present functionality can be used as optional
=A0 =A0 capabilities or YANG features.

The "reduced set of mandatory features" is of course to be
developed by the WG once we are chartered for this work.

=A0Please express your support or objections w.r.t. to this
proposal. Pls do so asap, but in any event, no later than
June 20th 2012 (any timezone)

Bert and Mehmet
WG chairs for NETCONF

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--bcaec554dfee4b815204c2c36e22-- From ietf-ipr@ietf.org Mon Jun 18 08:52: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 902E321F858D; Mon, 18 Jun 2012 08:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 6GSxPy8CQ+bv; Mon, 18 Jun 2012 08:52:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE64D21F85A5; Mon, 18 Jun 2012 08:52:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: rob.enns@gmail.com, mbj@tail-f.com, andy.bierman@brocade.com, j.schoenwaelder@jacobs-university.de X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120618155204.21779.94112.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 08:52:04 -0700 X-Mailman-Approved-At: Mon, 18 Jun 2012 14:17:40 -0700 Cc: rbonica@juniper.net, netconf@ietf.org, ipr-announce@ietf.org Subject: [Netconf] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6241 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 15:52:06 -0000 Dear Rob Enns, Martin Bjorklund, Andy Bierman, Juergen Schoenwaelder: An IPR disclosure that pertains to your RFC entitled "Network Configuration Protocol (NETCONF)" (RFC6241) was submitted to the IETF Secretariat on 2012-06-15 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1800/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to= RFC 6241.""); The IETF Secretariat From Jonathan.Hansford@generaldynamics.uk.com Tue Jun 19 02:00: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 D762021F85F0 for ; Tue, 19 Jun 2012 02:00:28 -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 34iUqYwYeoW9 for ; Tue, 19 Jun 2012 02:00:27 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD9321F85DF for ; Tue, 19 Jun 2012 02:00:25 -0700 (PDT) Received: from [85.158.139.3:11421] by server-5.bemta-5.messagelabs.com id 42/F1-02722-8AF30EF4; Tue, 19 Jun 2012 09:00:24 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-3.tower-90.messagelabs.com!1340096423!28483088!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3452 invoked from network); 19 Jun 2012 09:00:23 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-3.tower-90.messagelabs.com with SMTP; 19 Jun 2012 09:00:23 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 19 Jun 2012 10:00:20 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.137]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 10:00:21 +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, 19 Jun 2012 10:00:21 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206CDD1E7@GDUKADH850.uk1.r-org.net> In-Reply-To: <00b801cd4d75$9f6dd4a0$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] we are NOT CONVERGING towards consensus Thread-Index: Ac1NdhwMBm6enNZEQkODcnNa7socUgAgo3yw References: <29C30561-9607-4F67-814C-C9CB310C2FCD@tail-f.com><201206141608.q5EG8PQb075493@idle.juniper.net> <83C941F7F59F3F42AC017AD1E650546206C7E5D5@GDUKADH850.uk1.r-org.net> <00b801cd4d75$9f6dd4a0$4001a8c0@gateway.2wire.net> From: To: , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 19 Jun 2012 09:00:21.0886 (UTC) FILETIME=[F52831E0:01CD4DF9] Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 09:00:29 -0000 > > Back in February Juergen, replying to one of my emails, stated: > > > > If you want to start a draft on implementation guidelines, by all > means, > > please do so. I am not saying everything is totally obvious from the > > specs. (And I guess this is even more true for NETCONF than it is for > > YANG.) Having a NETCONF / YANG implementation guidelines document at > > some point in time might really be useful. > > > > Unfortunately, even now I don't feel anywhere near knowledgeable > enough > > to embark on such an endeavour, though such a document would certainly > > help. >=20 > Jonathan >=20 > That probably makes you best qualified to produce such a document. >=20 > As I say every now and then, experts sometimes produce documents that > are comprehensible only to other experts, whereas someone less > knowledgeable better recognises what is hard to understand, what the key > points are and what is needed to make it clear. >=20 > Yes, you may get a lot wrong before you get it right, but what you > eventually produce may well be better than that which anyone else could > produce. >=20 > Honest. >=20 > Tom Petch So, if one were to contemplate such an endeavour, should the outcome be an RFC or some other form of publication? What is a more appropriate medium in which to evangelise? For example, print or web, formal or informal, etc? And what level of peer review could one expect? As you say, there are plenty of opportunities to "get a lot wrong" and, without peer review, this task would ultimately have involved a lot of nugatory effort. Misinformation is far more damaging than no information. 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 j.schoenwaelder@jacobs-university.de Tue Jun 19 04:00: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 0B7F721F8618 for ; Tue, 19 Jun 2012 04:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 WBj4NuEtryNT for ; Tue, 19 Jun 2012 04:00:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5811D21F85D0 for ; Tue, 19 Jun 2012 04:00:16 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5AAC20BEE; Tue, 19 Jun 2012 13:00:14 +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 oIaoWGHLh0Yo; Tue, 19 Jun 2012 13:00: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 B351920BEC; Tue, 19 Jun 2012 13:00:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BC6D31FD3076; Tue, 19 Jun 2012 13:00:12 +0200 (CEST) Date: Tue, 19 Jun 2012 13:00:12 +0200 From: Juergen Schoenwaelder To: Jonathan.Hansford@generaldynamics.uk.com Message-ID: <20120619110010.GB95623@elstar.local> Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, ietfc@btconnect.com, netconf@ietf.org References: <29C30561-9607-4F67-814C-C9CB310C2FCD@tail-f.com> <201206141608.q5EG8PQb075493@idle.juniper.net> <83C941F7F59F3F42AC017AD1E650546206C7E5D5@GDUKADH850.uk1.r-org.net> <00b801cd4d75$9f6dd4a0$4001a8c0@gateway.2wire.net> <83C941F7F59F3F42AC017AD1E650546206CDD1E7@GDUKADH850.uk1.r-org.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206CDD1E7@GDUKADH850.uk1.r-org.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] we are NOT CONVERGING towards consensus X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 11:00:18 -0000 On Tue, Jun 19, 2012 at 10:00:21AM +0100, Jonathan.Hansford@generaldynamics.uk.com wrote: > > And what level of peer review could one expect? As you say, there are > plenty of opportunities to "get a lot wrong" and, without peer review, > this task would ultimately have involved a lot of nugatory effort. > Misinformation is far more damaging than no information. > I am confident that there are enough people here who will help with reviews because it is their interest that what is written down is technically correct. /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 Jun 20 01:29: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 9F04421F872A; Wed, 20 Jun 2012 01:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.418 X-Spam-Level: X-Spam-Status: No, score=-4.418 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, HTML_MESSAGE=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 8yclVv-6hvZr; Wed, 20 Jun 2012 01:29:51 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDB21F871E; Wed, 20 Jun 2012 01:29:49 -0700 (PDT) Received: from [85.158.136.3:60688] by server-8.bemta-5.messagelabs.com id CB/11-10278-CF981EF4; Wed, 20 Jun 2012 08:29:48 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-12.tower-123.messagelabs.com!1340180988!27338413!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23901 invoked from network); 20 Jun 2012 08:29:48 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-12.tower-123.messagelabs.com with SMTP; 20 Jun 2012 08:29:48 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 20 Jun 2012 09:29:43 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.137]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 09:29:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4EBE.D5BF20F0" Date: Wed, 20 Jun 2012 09:29:46 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Possibility of a NETCONF and YANG Primer Thread-Index: Ac1Ovtmk4Ot3qYOeQPGWncLDGfEcgA== From: To: , X-OriginalArrivalTime: 20 Jun 2012 08:29:43.0670 (UTC) FILETIME=[D7E87160:01CD4EBE] Subject: [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:29:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4EBE.D5BF20F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hi, =20 Were I to undertake writing a NETCONF and YANG primer, could someone point me at any documents or particular email threads that would help me gain an understanding of the discussions, guidelines, etc. that helped shape them? For example, would I be right in assuming that RFC3444, RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? =20 Thanks, =20 Jonathan 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 ------_=_NextPart_001_01CD4EBE.D5BF20F0 Content-Type: text/HTML; charset="us-ascii" Content-Transfer-Encoding: 7bit X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1

Hi,

 

Were I to undertake writing a NETCONF and YANG primer, could someone point me at any documents or particular email threads that would help me gain an understanding of the discussions, guidelines, etc. that helped shape them? For example, would I be right in assuming that RFC3444, RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact?

 

Thanks,

 

Jonathan

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 should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

------_=_NextPart_001_01CD4EBE.D5BF20F0-- From j.schoenwaelder@jacobs-university.de Wed Jun 20 01:43: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 D1D7421F8609; Wed, 20 Jun 2012 01:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Aajn8kbRNrfV; Wed, 20 Jun 2012 01:43:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 12F3B21F870B; Wed, 20 Jun 2012 01:43:11 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11E9320BEB; Wed, 20 Jun 2012 10:43:10 +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 l4btFIh73SWy; Wed, 20 Jun 2012 10:43:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33F6F207E0; Wed, 20 Jun 2012 10:43:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8E516201B140; Wed, 20 Jun 2012 10:43:08 +0200 (CEST) Date: Wed, 20 Jun 2012 10:43:08 +0200 From: Juergen Schoenwaelder To: Jonathan.Hansford@generaldynamics.uk.com Message-ID: <20120620084308.GA77034@elstar.local> Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org, netmod@ietf.org References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] Possibility of a NETCONF and YANG Primer 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, 20 Jun 2012 08:43:15 -0000 On Wed, Jun 20, 2012 at 09:29:46AM +0100, Jonathan.Hansford@generaldynamics.uk.com wrote: > Hi, > > Were I to undertake writing a NETCONF and YANG primer, could someone > point me at any documents or particular email threads that would help me > gain an understanding of the discussions, guidelines, etc. that helped > shape them? For example, would I be right in assuming that RFC3444, > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? > RFC3535 has been important in getting the IETF to start work on a new network configuration protocol. It also delievered some requirements but other than that it did not really influence much of the design. Some of us wrote an IEEE Communications Magazine paper providing a concise summary of what NETCONF / YANG is. Perhaps this is useful. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5560601&contentType=Journals+%26+Magazines&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number%3A5560574%29%26rowsPerPage%3D50 And then there is of course also RFC 6244 which has some motivation and introductory material. /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 Wed Jun 20 01:55: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 413FB21F8731; Wed, 20 Jun 2012 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Nd+qJgAHBnNs; Wed, 20 Jun 2012 01:55:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CCDB921F8707; Wed, 20 Jun 2012 01:55:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5K8tCY1031157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2012 10:55:12 +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 q5K8t64o029466; Wed, 20 Jun 2012 10:55:12 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 10:55:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jun 2012 10:55:05 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403EE4F64@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120620084308.GA77034@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Possibility of a NETCONF and YANG Primer Thread-Index: Ac1OwL/hr5bhecBgS+eW554dfGEKkgAAXjEA References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> <20120620084308.GA77034@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 20 Jun 2012 08:55:06.0746 (UTC) FILETIME=[63BB65A0:01CD4EC2] 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: 2058 X-purgate-ID: 151667::1340182515-0000425E-869BFCA8/0-0/0-0 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:55:22 -0000 Please check also http://tools.ietf.org/html/rfc6087=20 "Guidelines for Authors and Reviewers of YANG Data Model Documents".=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Juergen Schoenwaelder > Sent: Wednesday, June 20, 2012 10:43 AM > To: Jonathan.Hansford@generaldynamics.uk.com > Cc: netconf@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] Possibility of a NETCONF and YANG Primer >=20 > On Wed, Jun 20, 2012 at 09:29:46AM +0100, > Jonathan.Hansford@generaldynamics.uk.com wrote: > > Hi, > > > > Were I to undertake writing a NETCONF and YANG primer, could someone > > point me at any documents or particular email threads that would help me > > gain an understanding of the discussions, guidelines, etc. that helped > > shape them? For example, would I be right in assuming that RFC3444, > > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? > > >=20 > RFC3535 has been important in getting the IETF to start work on a new > network configuration protocol. It also delievered some requirements > but other than that it did not really influence much of the design. >=20 > Some of us wrote an IEEE Communications Magazine paper providing a > concise summary of what NETCONF / YANG is. Perhaps this is useful. >=20 > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=3D&arnumber=3D556060= 1&c ontentType=3D > Journals+%26+Magazines&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_N > umber%3A5560574%29%26rowsPerPage%3D50 >=20 > And then there is of course also RFC 6244 which has some motivation > and introductory material. >=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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Wed Jun 20 02: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 2048D21F86FD; Wed, 20 Jun 2012 02:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 m2PxLwB4F24r; Wed, 20 Jun 2012 02:08: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 6F2B221F86FA; Wed, 20 Jun 2012 02:08:30 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 223AD13FD87; Wed, 20 Jun 2012 11:08:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340183307; bh=MmtXVP+GZ1W+blelw/FC3ejkvrUYvzwUo7Si6c6KlhU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lgkL4EWQPSV4V1nbsYgReQYf1u7R7HUVjIyUfSeEbaPOm+kklOhcbCNzggEl6k+1Y copciqVqQ8kaZTK8sYaS2KF2IkgbYvu3YdnZwv8yu+NhzzkEt+Q01Q6TFWQ9lxjzBq DQtw5SYNZKfc/5qLTDTGm6oSun2J0akIG7Dq65LY= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> Date: Wed, 20 Jun 2012 11:08:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27FAA8EC-1DFC-47F4-9B25-A48BF5543C79@nic.cz> References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> To: X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Possibility of a NETCONF and YANG Primer X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 09:08:31 -0000 On Jun 20, 2012, at 10:29 AM, = wrote: > Hi, > =20 > Were I to undertake writing a NETCONF and YANG primer, could someone = point me at any documents or particular email threads that would help me = gain an understanding of the discussions, guidelines, etc. that helped = shape them? For example, would I be right in assuming that RFC3444, = RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? Regarding YANG and DSDL mapping, some tutorials are available at = yang-central.org. Lada > =20 > Thanks, > =20 > Jonathan >=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 should not disclose, distribute, print, copy or make other use = of this email or its attachments. Such actions, in fact, may be = unlawful. In compliance with the various Regulations and Acts, General = Dynamics United Kingdom Limited reserves the right to monitor (and = examine for viruses) all emails and email attachments, both inbound and = outbound. Email communications and their attachments may not be secure = or error- or virus-free and the company does not accept liability or = responsibility for such matters or the consequences thereof. General = Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, = London EC1A 2DY. Registered in England and Wales No: 1911653. >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Jun 20 05:39: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 047C421F870B; Wed, 20 Jun 2012 05:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGbGYdmnHl9L; Wed, 20 Jun 2012 05:39:57 -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 4516421F86DC; Wed, 20 Jun 2012 05:39:56 -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 F236B1200CF2; Wed, 20 Jun 2012 14:39:54 +0200 (CEST) Date: Wed, 20 Jun 2012 14:39:54 +0200 (CEST) Message-Id: <20120620.143954.975189795650856992.mbj@tail-f.com> To: Jonathan.Hansford@generaldynamics.uk.com From: Martin Bjorklund In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> X-Mailer: Mew version 6.4 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, netmod@ietf.org Subject: Re: [Netconf] [netmod] Possibility of a NETCONF and YANG Primer X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 12:39:58 -0000 wrote: > Hi, > > > > Were I to undertake writing a NETCONF and YANG primer, could someone > point me at any documents or particular email threads that would help me > gain an understanding of the discussions, guidelines, etc. that helped > shape them? For example, would I be right in assuming that RFC3444, > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? For YANG, there are some notes available at http://www.yang-central.org/twiki/bin/view/Main/YangDocuments, for example http://www.yang-central.org/twiki/bin/view/Main/WhyYang. I should also say that I think this is a great idea! I very much encourage you to write this document. If you start writing something, I am pretty sure others (myself included) can help with information, or even text for certain sections. /martin From randy_presuhn@mindspring.com Wed Jun 20 10:04: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 8316021F8763; Wed, 20 Jun 2012 10:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, 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 TdgHoMC2aMVb; Wed, 20 Jun 2012 10:04:47 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD8321F8700; Wed, 20 Jun 2012 10:04:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hiFS1HNX5ek0BzyVSGm30rYvkSrEEamE5LFZoWd77LZOcFOuVILf0/T3+W16SMtw; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.50.205] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ShOKk-0008RI-Dz; Wed, 20 Jun 2012 13:04:46 -0400 Message-ID: <002601cd4f07$4f8209a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> <27FAA8EC-1DFC-47F4-9B25-A48BF5543C79@nic.cz> Date: Wed, 20 Jun 2012 10:08:26 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1bbd31b5f81886e3d25738e16f00db322350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.50.205 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Possibility of a NETCONF and YANG Primer X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 17:04:48 -0000 Hi - Jonathan.Hansford@generaldynamics.uk.com wrote: > Were I to undertake writing a NETCONF and YANG primer, > could someone point me at any documents or particular email > threads that would help me gain an understanding of the discussions, > guidelines, etc. that helped shape them? ... You might also find some background material in https://datatracker.ietf.org/doc/draft-presuhn-rcdml/ Like RFC3535, though it delivered some requirements, its actual influence on the design is another question. Randy From ietfc@btconnect.com Wed Jun 20 11:18:49 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 E88E121F877E; Wed, 20 Jun 2012 11:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.839 X-Spam-Level: X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=1.760, 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 UUOsaycq789q; Wed, 20 Jun 2012 11:18:49 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4707D21F877C; Wed, 20 Jun 2012 11:18:49 -0700 (PDT) Received: from mail165-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 18:17:24 +0000 Received: from mail165-tx2 (localhost [127.0.0.1]) by mail165-tx2-R.bigfish.com (Postfix) with ESMTP id ECEE11E0290; Wed, 20 Jun 2012 18:17:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail165-tx2 (localhost.localdomain [127.0.0.1]) by mail165-tx2 (MessageSwitch) id 1340216243327275_32019; Wed, 20 Jun 2012 18:17:23 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.247]) by mail165-tx2.bigfish.com (Postfix) with ESMTP id 4D27F4A0068; Wed, 20 Jun 2012 18:17:23 +0000 (UTC) Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 18:17:21 +0000 Received: from BY2PRD0410HT004.namprd04.prod.outlook.com (157.56.236.85) by pod51017.outlook.com (10.3.4.151) with Microsoft SMTP Server (TLS) id 14.15.86.1; Wed, 20 Jun 2012 18:18:32 +0000 Message-ID: <017401cd4f10$a0873920$4001a8c0@gateway.2wire.net> From: t.petch To: , , References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> Date: Wed, 20 Jun 2012 19:15:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.85] X-OriginatorOrg: btconnect.com Subject: Re: [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 18:18:50 -0000 ----- Original Message ----- From: To: ; Sent: Wednesday, June 20, 2012 9:29 AM Were I to undertake writing a NETCONF and YANG primer, could someone point me at any documents or particular email threads that would help me gain an understanding of the discussions, guidelines, etc. that helped shape them? For example, would I be right in assuming that RFC3444, RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? I was assuming it would be an RFC, Informational. There are precedents for other protocols, although not too many. I too would be happy to review and comment. Tom Petch PS I wish you could eliminate the trailer that says your e-mails may be confidential, although I realise corporate culture makes that very difficult. Which is perhaps why there are a number of gmail addresses on IETF lists. Thanks, Jonathan From mbj@tail-f.com Wed Jun 20 13:10: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 DBE0F11E8083; Wed, 20 Jun 2012 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.154, 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 Ft5olFGTQwJQ; Wed, 20 Jun 2012 13:10:35 -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 AC47411E8087; Wed, 20 Jun 2012 13:10:35 -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 9BD001200D85; Wed, 20 Jun 2012 22:10:33 +0200 (CEST) Date: Wed, 20 Jun 2012 22:10:33 +0200 (CEST) Message-Id: <20120620.221033.441138909.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <017401cd4f10$a0873920$4001a8c0@gateway.2wire.net> References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> <017401cd4f10$a0873920$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Possibility of a NETCONF and YANG Primer X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 20:10:40 -0000 t.petch wrote: > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, June 20, 2012 9:29 AM > > Were I to undertake writing a NETCONF and YANG primer, could someone > point me at any documents or particular email threads that would help me > gain an understanding of the discussions, guidelines, etc. that helped > shape them? For example, would I be right in assuming that RFC3444, > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? > > > I was assuming it would be an RFC, Informational. There are precedents > for other protocols, although not too many. I think a web site might be better. It can be perceived as "lighter" and easier to read, and you are not limited to 72 ascii chars per line :) It is easier to make pretty pictures etc. I think both pyang and yangdump has options to generate pretty html versions of YANG modules. /martin From andy@yumaworks.com Tue Jun 26 10:06: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 672D221F85C0 for ; Tue, 26 Jun 2012 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 r+3Ush3QVIAX for ; Tue, 26 Jun 2012 10:06:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D939E21F85B1 for ; Tue, 26 Jun 2012 10:06:20 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so354380lbb.31 for ; Tue, 26 Jun 2012 10:06:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Ps6uknwu8OBghyzWCArbUEdDKbiHAb0b1syjIqe7cTo=; b=jVr88xbxOpXqlmW9+f8J7FJip3AaZ2YWdsYVo1XbSQlPAl8RFTqOnFv/QxV3gQ8OBy OVrLMAYYKfapyzFWU8NIDVd7k+WdkWHZaNduxBZGMVSOrN2vTjj5srUSyREg67nQ4Y7r gDKxyt8i1EKj+G3IadL89irmSczowpcgQud2bw9P8zS0rEhYUbWyjzbYAlF9AQ6mU/e8 wkSD1F1liAfmQGgobfNON58n+5l5hqeE1drw47KdLtYFW9q1480VDYXrrZ3eerkmtVG4 15KDOKN0tzJmFgx1OF9RiMrSxtIWVvY8+0MdeJKiLiBH9rIdyuFfjqNaIKqRcQxHeD9u lCAw== MIME-Version: 1.0 Received: by 10.112.86.132 with SMTP id p4mr7761043lbz.22.1340730379646; Tue, 26 Jun 2012 10:06:19 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 26 Jun 2012 10:06:19 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> Date: Tue, 26 Jun 2012 10:06:19 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=bcaec554d52204b6cd04c3631e5a X-Gm-Message-State: ALoCoQnci+rIxPNLtZ7fLWb9eGnCP4kTELKqGiiLTcTyvQKctyYv4VBePVY9qiCrpt4Cyo7pOjlo Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:06:22 -0000 --bcaec554d52204b6cd04c3631e5a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 18, 2012 at 10:53 AM, Kent Watsen wrote: > > [just back from PTO, hence the delayed response] > > > I support a "netconf:base:1.2" that requires the following reduced set of > base features: > > - copy-config > - close-session > - get-config (no filtering) > > And defines distinct capabilities to enable all the base:1.1 operations. > > > Why does NETCONF-Light have to be a pure subset of NETCONF? IMO, copy-config is a horrible solution for CM editing for constrained devices. A new edit function could be created instead, creating a new minimum list: - edit-resource - close-session - get-config (no filtering) rpc edit-resource { description "Edit a managed resource in the target configuration."; input { leaf target-resource { type instance-identifier; mandatory true; description "Resource to edit"; } choice config-target { // if not set the server will pick the target config // same as config-target in edit-config (candidate or running leafs) leaf candidate { if-feature candidate; type empty; description "The candidate configuration is the config target."; } leaf running { if-feature writable-running; type empty; description "The running configuration is the config source."; } } leaf operation { type nc:edit-operation-type; description "edit operation to perform"; default "merge"; } anyxml data { description "New target resource data (if needed)." } } } Also, the entire mandatory set can be encoded in JSON. IMO, the real issues impacting server complexity are related to client flexibility. In reality, too much of this is a recipe for non-interoperability. is the worst operation in NETCONF wrt/ server consistency. Instead of allowing an arbitrary mix of eedits, the server is more likely to have hidden restrictions on the order and concurrency of config changes. IMO, we should be having the discussion "What do constrained devices need to be managed effectively and efficiently?" Instead we are working backwards from a solution and asking "How much NETCONF can we agree on removing from the the mandatory subset?" Andy Notes: > > 1. I've read all the postings to date > > 2. I'm OK calling this an "upgrade". It doesn't seem too much of a > stretch to > consider "modularization" as the feature being added. > > 3. I'm OK with the "backwards compatibility" of the solution, as existing > servers > would continue to advertise their currently supported 1.0 and/or 1.1 > bases and, > as section 8.1 says: "If more than one protocol version URI in common > is present, > then the highest numbered (most recent) protocol version MUST be used > by both > peers." > > 4. The reduced set of operations listed above are the same that Andy > listed here > (http://www.ietf.org/mail-archive/web/netconf/current/msg07501.html). > Even in > the most extreme case, I rather have a device provide this NETCONF > base than > have to resort to another protocol (ftp). That said, none of > Juniper's devices > are this constrained: one would only not advertise "locking" and > another would > only not advertize "subtree filtering" (assuming "base:1.2" is > advertized) > > > Thanks, > Kent > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Bert Wijnen (IETF) > Sent: Wednesday, June 06, 2012 5:39 PM > To: Netconf > Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a > consensus on the way forwardwithNetconf-Light] > > Dear WG participants, > > it seem very difficult to converge on the topic of NetConf > Light. We have evaluated the mailing lists discussions and > have had conversations with several key participants. We > also discussed this with our AD. From all that, we believe > that an acceptable approach will be that we try to get > approval (i.e. a chartered work item) for: > > Develop standards track NETCONF 2.0 with a new > modular base version, which has a reduced set of > mandatory features. > The present functionality can be used as optional > capabilities or YANG features. > > The "reduced set of mandatory features" is of course to be > developed by the WG once we are chartered for this work. > > Please express your support or objections w.r.t. to this > proposal. Pls do so asap, but in any event, no later than > June 20th 2012 (any timezone) > > Bert and Mehmet > WG chairs for NETCONF > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --bcaec554d52204b6cd04c3631e5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 18, 2012 at 10:53 AM, Kent W= atsen <kwatsen@juniper.net> wrote:

[just back from PTO, hence the delayed response]


I support a "netconf:base:1.2" that requires the following reduce= d set of base features:

=A0 - copy-config
=A0 - close-session
=A0 - get-config (no filtering)

And defines distinct capabilities to enable all the base:1.1 operations.



Why does NETCONF-Light = have to be a pure subset of NETCONF?
IMO, copy-config is a horrib= le solution for CM editing for constrained devices.
A new edit fu= nction could be created instead, creating a new minimum list:

=A0 =A0 - edit-resource
=A0 =A0 - close-sessi= on
=A0 =A0 - get-config (no filtering)=A0

rpc edit-resource {
=A0 =A0description "Edit a managed res= ource in the target configuration.";
=A0 =A0input {
=A0 =A0 =A0leaf target-resource {
= =A0 =A0 =A0 =A0 type instance-identifier;
=A0 =A0 =A0 =A0 mandato= ry true;
=A0 =A0 =A0 =A0 description "Resource to edit"= ;
=A0 =A0 =A0}
=A0 =A0 =A0choice config-target {
=A0 =A0 =A0 =A0 =A0 =A0// if not set the server will pick the target c= onfig
=A0 =A0 =A0 =A0 =A0 =A0// same as config-target in edit-con= fig (candidate or running leafs)
      leaf candidate {
          if-feature candidate;
          type empty;
          description
             "The candidate configuration is the config target.";
      }
      leaf running {
         if-feature writable-running;
         type empty;
         description
           "The running configuration is the config source.";
     }
=A0 =A0 =A0}
=A0 =A0 =A0leaf operation {
=A0 =A0 =A0 =A0 type nc:edit-operation-type;
=A0 =A0 =A0= =A0 description "edit operation to perform";
=A0 =A0 = =A0 =A0 default "merge";
=A0 =A0 =A0}
=A0 =A0 =A0anyxml data {
=A0 =A0 =A0 = =A0 description "New target resource data (if needed)."
=A0 =A0 =A0}
=A0 }
}

Also, th= e entire mandatory set can be encoded in JSON.
IMO, the real issues impacting server complexity are related
to client flexibility. =A0In reality, too much of this is a recipe
for non-interoperability. <copy-config> is the worst operation
in NETCONF wrt/ server consistency. =A0Instead of allowing
a= n arbitrary mix of eedits, the server is more likely to have
hidd= en restrictions on the order and concurrency of config changes.


IMO, we should be having the discussion "= ;What do constrained
devices need to be managed effectively and e= fficiently?"
Instead we are working backwards from a solutio= n and asking
"How much NETCONF can we agree on removing from the
the= mandatory subset?"


Andy
=



Notes:

=A01. I've read all the postings to date

=A02. I'm OK calling this an "upgrade". =A0It doesn't se= em too much of a stretch to
=A0 =A0 consider "modularization" as the feature being added.
=A03. I'm OK with the "backwards compatibility" of the solut= ion, as existing servers
=A0 =A0 would continue to advertise their currently supported 1.0 and/or 1= .1 bases and,
=A0 =A0 as section 8.1 says: "If more than one protocol version URI i= n common is present,
=A0 =A0 then the highest numbered (most recent) protocol version MUST be u= sed by both
=A0 =A0 peers."

=A04. The reduced set of operations listed above are the same that Andy li= sted here
=A0 =A0 (http://www.ietf.org/mail-archive/web/netcon= f/current/msg07501.html). =A0Even in
=A0 =A0 the most extreme case, I rather have a device provide this NETCONF= base than
=A0 =A0 have to resort to another protocol (ftp). =A0 That said, none of J= uniper's devices
=A0 =A0 are this constrained: one would only not advertise "locking&q= uot; and another would
=A0 =A0 only not advertize "subtree filtering" (assuming "b= ase:1.2" is advertized)


Thanks,
Kent


-----Original Message-----
From: netconf-bounces@ietf.org<= /a> [mailto:netconf-bounces@iet= f.org] On Behalf Of Bert Wijnen (IETF)
Sent: Wednesday, June 06, 2012 5:39 PM
To: Netconf
Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensus= on the way forwardwithNetconf-Light]

Dear WG participants,

it seem very difficult to converge on the topic of NetConf
Light. We have evaluated the mailing lists discussions and
have had conversations with several key participants. We
also discussed this with our AD. From all that, we believe
that an acceptable approach will be that we try to get
approval (i.e. a chartered work item) for:

=A0 =A0 Develop standards track NETCONF 2.0 with a new
=A0 =A0 modular base version, which has a reduced set of
=A0 =A0 mandatory features.
=A0 =A0 The present functionality can be used as optional
=A0 =A0 capabilities or YANG features.

The "reduced set of mandatory features" is of course to be
developed by the WG once we are chartered for this work.

=A0Please express your support or objections w.r.t. to this
proposal. Pls do so asap, but in any event, no later than
June 20th 2012 (any timezone)

Bert and Mehmet
WG chairs for NETCONF

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--bcaec554d52204b6cd04c3631e5a-- From j.schoenwaelder@jacobs-university.de Tue Jun 26 20:08: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 98D8D11E80EA for ; Tue, 26 Jun 2012 20:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 K1GrWrRYvt-C for ; Tue, 26 Jun 2012 20:08:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F711E80CD for ; Tue, 26 Jun 2012 20:08:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E05420C0B; Wed, 27 Jun 2012 05:08:53 +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 RH9Z_2Qr8Oay; Wed, 27 Jun 2012 05:08:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FCD620C08; Wed, 27 Jun 2012 05:08:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64BCB202B303; Wed, 27 Jun 2012 05:08:51 +0200 (CEST) Date: Wed, 27 Jun 2012 05:08:50 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120627030848.GA47360@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , Netconf References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> 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] WG Consensus call: Netconf 2.0? 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, 27 Jun 2012 03:08:55 -0000 On Tue, Jun 26, 2012 at 10:06:19AM -0700, Andy Bierman wrote: > > Why does NETCONF-Light have to be a pure subset of NETCONF? > IMO, copy-config is a horrible solution for CM editing for constrained > devices. The devices we were implementing on had no CM at all other than loading a new firmware image. Compared to that, copy-config was a step forward. > A new edit function could be created instead, creating a new minimum list: > > - edit-resource > - close-session > - get-config (no filtering) > > rpc edit-resource { > description "Edit a managed resource in the target configuration."; > input { > leaf target-resource { > type instance-identifier; > mandatory true; > description "Resource to edit"; > } > choice config-target { > // if not set the server will pick the target config > // same as config-target in edit-config (candidate or running > leafs) > > leaf candidate { > if-feature candidate; > type empty; > description > "The candidate configuration is the config target."; > } > leaf running { > if-feature writable-running; > type empty; > description > "The running configuration is the config source."; > } > > } > leaf operation { > type nc:edit-operation-type; > description "edit operation to perform"; > default "merge"; > } > anyxml data { > description "New target resource data (if needed)." > } > } > } Sure, something like this could be considered, but we were starting from a device that really only had "load-firmware", hence copy-config was already a step forward. > Also, the entire mandatory set can be encoded in JSON. We were lucky that there was a minimal XML parser. JSON tends to be a bit smaller and less chatty but on our device, we had to pass NETCONF messages through flash since RAM was not sufficient to hold them... > IMO, the real issues impacting server complexity are related > to client flexibility. In reality, too much of this is a recipe > for non-interoperability. is the worst operation > in NETCONF wrt/ server consistency. Instead of allowing > an arbitrary mix of eedits, the server is more likely to have > hidden restrictions on the order and concurrency of config changes. That was not our problem for the things we made configurable. But I can see that such devices might want to do a warm start after config changes, which of course breaks TCP transports. As I said, the REST API looks indeed interesting and it might map to CoAP, which does not even maintain a TCP session. > IMO, we should be having the discussion "What do constrained > devices need to be managed effectively and efficiently?" > Instead we are working backwards from a solution and asking > "How much NETCONF can we agree on removing from the > the mandatory subset?" I think that is the purpose of the coma list. /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@yumaworks.com Wed Jun 27 06:33:07 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 6C7E621F8705 for ; Wed, 27 Jun 2012 06:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UqG19XbnVkH2 for ; Wed, 27 Jun 2012 06:33:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D96E221F86FE for ; Wed, 27 Jun 2012 06:33:05 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1761502lbb.31 for ; Wed, 27 Jun 2012 06:33:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=157MMz1Z1i9WTOd2n8Xjrv0nCLDkI+m7ZjC6I0zOpWU=; b=oHCVUj7+6eCA9zWW1OeEdg2ks37t5neLZQeouK/p27qm3BI4zXTSg8iqXANlM4DjgA ZmoErKoHgyqyJuOU/9C5q8UuSgQQH+siQqurj2hzHZCyXiZRXJbSnatvzn23/tTZbSWb RKSpJcgJuTSqUy3CrsOu4/HVH0KUo5JldlAcQA3JGNK+GGpZrb2zLOKOdH/rZOMHgV9q ZdPgCYRjSshNTkJwW68ZlvfF5I4o7Xuq4oG17039yom1R1hrk+WrB7myarA+MutPHQXt gW4fzJiwBHnruA6/L3iRzIGM5iTa1OruVxHRelupXbvwNLbH+jMRfIxNdMKmyYSIXshh tG0w== MIME-Version: 1.0 Received: by 10.112.43.37 with SMTP id t5mr9829964lbl.89.1340803984744; Wed, 27 Jun 2012 06:33:04 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 06:33:04 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120627030848.GA47360@elstar.local> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> Date: Wed, 27 Jun 2012 06:33:04 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary=e0cb4efe344c3963ce04c37441b2 X-Gm-Message-State: ALoCoQkoBmPPss7utyPr+0SEknNZFw6wLmRXauS9qdjZ9KMuEi6rhlZuZ5NO7+AUvulhpWj8LGpC Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:33:07 -0000 --e0cb4efe344c3963ce04c37441b2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 26, 2012 at 8:08 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jun 26, 2012 at 10:06:19AM -0700, Andy Bierman wrote: > > > > Why does NETCONF-Light have to be a pure subset of NETCONF? > > IMO, copy-config is a horrible solution for CM editing for constrained > > devices. > > The devices we were implementing on had no CM at all other than > loading a new firmware image. Compared to that, copy-config was a step > forward. > > > A new edit function could be created instead, creating a new minimum > list: > > > > - edit-resource > > - close-session > > - get-config (no filtering) > > > > rpc edit-resource { > > description "Edit a managed resource in the target configuration."; > > input { > > leaf target-resource { > > type instance-identifier; > > mandatory true; > > description "Resource to edit"; > > } > > choice config-target { > > // if not set the server will pick the target config > > // same as config-target in edit-config (candidate or running > > leafs) > > > > leaf candidate { > > if-feature candidate; > > type empty; > > description > > "The candidate configuration is the config target."; > > } > > leaf running { > > if-feature writable-running; > > type empty; > > description > > "The running configuration is the config source."; > > } > > > > } > > leaf operation { > > type nc:edit-operation-type; > > description "edit operation to perform"; > > default "merge"; > > } > > anyxml data { > > description "New target resource data (if needed)." > > } > > } > > } > > Sure, something like this could be considered, but we were starting > from a device that really only had "load-firmware", hence copy-config > was already a step forward. > > So get-config and copy-config are completely irrelevant to your implementation? Maybe you have an binary leaf called 'firmware-image' as the only object in the config? IMO this is not CM if the device has no config. NETCONF does not even have a standard load-firmware operation, so the only part of the standard you use is the . > > Also, the entire mandatory set can be encoded in JSON. > > We were lucky that there was a minimal XML parser. JSON tends to be a > bit smaller and less chatty but on our device, we had to pass NETCONF > messages through flash since RAM was not sufficient to hold them... > > > IMO, the real issues impacting server complexity are related > > to client flexibility. In reality, too much of this is a recipe > > for non-interoperability. is the worst operation > > in NETCONF wrt/ server consistency. Instead of allowing > > an arbitrary mix of eedits, the server is more likely to have > > hidden restrictions on the order and concurrency of config changes. > > That was not our problem for the things we made configurable. But I > can see that such devices might want to do a warm start after config > changes, which of course breaks TCP transports. As I said, the REST > API looks indeed interesting and it might map to CoAP, which does not > even maintain a TCP session. > That's not the point. The problem is that allows arbitrary changes, but some implementations I have seen are not good enough to do that. They reject the request or handle it wrong instead. Requiring a reboot is yet another area that NETCONF does not address. > > IMO, we should be having the discussion "What do constrained > > devices need to be managed effectively and efficiently?" > > Instead we are working backwards from a solution and asking > > "How much NETCONF can we agree on removing from the > > the mandatory subset?" > > I think that is the purpose of the coma list. > Which really makes me wonder why the NETCONF WG is solving this problem as well. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --e0cb4efe344c3963ce04c37441b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 26, 2012 at 8:08 PM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jun 26, 2012 at 10:06:19AM -0700, An= dy Bierman wrote:
>
> Why does NETCONF-Light have to be a pure subset of NETCONF?
> IMO, copy-config is a horrible solution for CM editing for constrained=
> devices.

The devices we were implementing on had no CM at all other than
loading a new firmware image. Compared to that, copy-config was a step
forward.

> A new edit function could be created instead, creating a new minimum l= ist:
>
> =A0 =A0 - edit-resource
> =A0 =A0 - close-session
> =A0 =A0 - get-config (no filtering)
>
> rpc edit-resource {
> =A0 =A0description "Edit a managed resource in the target configu= ration.";
> =A0 =A0input {
> =A0 =A0 =A0leaf target-resource {
> =A0 =A0 =A0 =A0 type instance-identifier;
> =A0 =A0 =A0 =A0 mandatory true;
> =A0 =A0 =A0 =A0 description "Resource to edit";
> =A0 =A0 =A0}
> =A0 =A0 =A0choice config-target {
> =A0 =A0 =A0 =A0 =A0 =A0// if not set the server will pick the target c= onfig
> =A0 =A0 =A0 =A0 =A0 =A0// same as config-target in edit-config (candid= ate or running
> leafs)
>
> =A0 =A0 =A0 leaf candidate {
> =A0 =A0 =A0 =A0 =A0 if-feature candidate;
> =A0 =A0 =A0 =A0 =A0 type empty;
> =A0 =A0 =A0 =A0 =A0 description
> =A0 =A0 =A0 =A0 =A0 =A0 =A0"The candidate configuration is the co= nfig target.";
> =A0 =A0 =A0 }
> =A0 =A0 =A0 leaf running {
> =A0 =A0 =A0 =A0 =A0if-feature writable-running;
> =A0 =A0 =A0 =A0 =A0type empty;
> =A0 =A0 =A0 =A0 =A0description
> =A0 =A0 =A0 =A0 =A0 =A0"The running configuration is the config s= ource.";
> =A0 =A0 =A0}
>
> =A0 =A0 =A0}
> =A0 =A0 =A0leaf operation {
> =A0 =A0 =A0 =A0 type nc:edit-operation-type;
> =A0 =A0 =A0 =A0 description "edit operation to perform";
> =A0 =A0 =A0 =A0 default "merge";
> =A0 =A0 =A0}
> =A0 =A0 =A0anyxml data {
> =A0 =A0 =A0 =A0 description "New target resource data (if needed)= ."
> =A0 =A0 =A0}
> =A0 }
> }

Sure, something like this could be considered, but we were starting
from a device that really only had "load-firmware", hence copy-co= nfig
was already a step forward.


So get-config and copy-config are comp= letely irrelevant to your
implementation? =A0Maybe you have an bi= nary leaf called 'firmware-image'
as the only object in t= he config? =A0IMO this is not CM if the device
has no config. =A0NETCONF does not even have a standard load-firmware<= /div>
operation, so the only part of the standard you use is the <he= llo>.


=A0
> Also, the entire mandatory set can be encoded in JSON.

We were lucky that there was a minimal XML parser. JSON tends to be a
bit smaller and less chatty but on our device, we had to pass NETCONF
messages through flash since RAM was not sufficient to hold them...

> IMO, the real issues impacting server complexity are related
> to client flexibility. =A0In reality, too much of this is a recipe
> for non-interoperability. <copy-config> is the worst operation > in NETCONF wrt/ server consistency. =A0Instead of allowing
> an arbitrary mix of eedits, the server is more likely to have
> hidden restrictions on the order and concurrency of config changes.
That was not our problem for the things we made configurable. But I
can see that such devices might want to do a warm start after config
changes, which of course breaks TCP transports. As I said, the REST
API looks indeed interesting and it might map to CoAP, which does not
even maintain a TCP session.

That's= not the point. =A0The problem is that <copy-config> allows
arbitrary changes, but some implementations I have seen are not good
enough to do that. =A0They reject the request or handle it wrong inste= ad.
Requiring a reboot is yet another area that NETCONF does not = address.



> IMO, we should be having the discussion "What do constrained
> devices need to be managed effectively and efficiently?"
> Instead we are working backwards from a solution and asking
> "How much NETCONF can we agree on removing from the
> the mandatory subset?"

I think that is the purpose of the coma list.

Which really makes me wonder why the NETCONF WG is solving
this problem as well.


/js


Andy

--e0cb4efe344c3963ce04c37441b2-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 06:55:44 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 3604921F8776 for ; Wed, 27 Jun 2012 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 6MNRN5orG07P for ; Wed, 27 Jun 2012 06:55:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA121F8773 for ; Wed, 27 Jun 2012 06:55:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B43F020C37; Wed, 27 Jun 2012 15:55:42 +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 DJeB5b_uZ1Mm; Wed, 27 Jun 2012 15:55:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 359EA20C2F; Wed, 27 Jun 2012 15:55:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6EE2C202CFA9; Wed, 27 Jun 2012 15:55:41 +0200 (CEST) Date: Wed, 27 Jun 2012 15:55:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120627135540.GA51402@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , Netconf References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@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] WG Consensus call: Netconf 2.0? 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, 27 Jun 2012 13:55:44 -0000 On Wed, Jun 27, 2012 at 06:33:04AM -0700, Andy Bierman wrote: > > > > Sure, something like this could be considered, but we were starting > > from a device that really only had "load-firmware", hence copy-config > > was already a step forward. > > > So get-config and copy-config are completely irrelevant to your > implementation? Maybe you have an binary leaf called 'firmware-image' > as the only object in the config? IMO this is not CM if the device > has no config. NETCONF does not even have a standard load-firmware > operation, so the only part of the standard you use is the . Sorry for expressing myself not well. We did add get-config and copy-config and we considered that an improvement over the "plug a cable and do magic to load a new firmware" there was before. > That's not the point. The problem is that allows > arbitrary changes, but some implementations I have seen are not good > enough to do that. They reject the request or handle it wrong instead. Obviously, devices and implementations differ. > Requiring a reboot is yet another area that NETCONF does not address. Yes. But that was not the point either. ;-) NETCONF also does not provide support to load new firmware (but we would likely not have used it on the devices we dealt with for other technical reasons). > > > IMO, we should be having the discussion "What do constrained > > > devices need to be managed effectively and efficiently?" > > > Instead we are working backwards from a solution and asking > > > "How much NETCONF can we agree on removing from the > > > the mandatory subset?" > > > > I think that is the purpose of the coma list. > > > > Which really makes me wonder why the NETCONF WG is solving > this problem as well. As far as I recall, the problem showed up first on this list (because there was an I-D) and then things got carried forward. And if you go back the start of this thread, you will see why the discussion is here. /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@yumaworks.com Wed Jun 27 07: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 42B3721F87A2 for ; Wed, 27 Jun 2012 07:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, 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 CPGO-iK2sBpC for ; Wed, 27 Jun 2012 07:26:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE34121F877E for ; Wed, 27 Jun 2012 07:26:46 -0700 (PDT) Received: by eaaq13 with SMTP id q13so453036eaa.31 for ; Wed, 27 Jun 2012 07:26:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=BiogGEP1+vPPc4q2IDyZb9Am74Y7LcslJNHUsbSzGyc=; b=mE3HDwMMvvB0OIRTQYyazEzd8Hfmo0y5iIYbRSqRY0jcgRImRNPVfgeV5POyZ6aHuS bkFYCjH9RR0iqiCOisi0Eyg+/9vGH18Iw7byBzSbMYodpqBkWbnTtNPNoNu43NZRrzMk M4jd5j0vM+3ZTrKhRb+4FJzzs/DJ3xiAziYBKePvl/eBqEkgqcf33kG+V5+0OseaDESa QV7IsgYrOBfK4eixagILtvo3rLePRy3N8iD9L+l2iSoGkkvlo+xcbrwxcPna/2xZAU0H 2XxGLafB/kpoD/CGEXylgRRcKP+K91FwppexwbL4pXjnNARQ3zGqd1m0fdRDeupfD2vp dZ6A== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr20643230lab.47.1340807206007; Wed, 27 Jun 2012 07:26:46 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 07:26:45 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120627135540.GA51402@elstar.local> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> <20120627135540.GA51402@elstar.local> Date: Wed, 27 Jun 2012 07:26:45 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary=f46d0435c1d239f34c04c375010d X-Gm-Message-State: ALoCoQmLGBp7C362UDMijMR53L4eWAV0s69uv3uMC+rEkDk64HeTXbb3Dy/HUZV/lIuAuF20I0S5 Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:26:48 -0000 --f46d0435c1d239f34c04c375010d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 6:55 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 27, 2012 at 06:33:04AM -0700, Andy Bierman wrote: > > > > > > Sure, something like this could be considered, but we were starting > > > from a device that really only had "load-firmware", hence copy-config > > > was already a step forward. > > > > > So get-config and copy-config are completely irrelevant to your > > implementation? Maybe you have an binary leaf called 'firmware-image' > > as the only object in the config? IMO this is not CM if the device > > has no config. NETCONF does not even have a standard load-firmware > > operation, so the only part of the standard you use is the . > > Sorry for expressing myself not well. We did add get-config and > copy-config and we considered that an improvement over the "plug a > cable and do magic to load a new firmware" there was before. > > > That's not the point. The problem is that allows > > arbitrary changes, but some implementations I have seen are not good > > enough to do that. They reject the request or handle it wrong instead. > > Obviously, devices and implementations differ. > > > Requiring a reboot is yet another area that NETCONF does not address. > > Yes. But that was not the point either. ;-) NETCONF also does not > provide support to load new firmware (but we would likely not have > used it on the devices we dealt with for other technical reasons). > > It would be nice if your insights from implementation made it into the draft. The technical issues which lead to 1 solution or another are import. There are issues that are more likely to affect small boxes: * cannot change arbitrary mix of config objects at once * cannot apply config without requiring a warmstart * special requirements for firmware-update I don't think the same exact operations that were designed for backbone routers have to be used to manage a tiny SOHO router, or an alarm clock or a light bub. In particular, copy-config has many issues which make it unsuitable. Requiring the server to process the entire config in order to change anything seems contrary to the goals one would associate with "tiny server". > > > IMO, we should be having the discussion "What do constrained > > > > devices need to be managed effectively and efficiently?" > > > > Instead we are working backwards from a solution and asking > > > > "How much NETCONF can we agree on removing from the > > > > the mandatory subset?" > > > > > > I think that is the purpose of the coma list. > > > > > > > Which really makes me wonder why the NETCONF WG is solving > > this problem as well. > > As far as I recall, the problem showed up first on this list (because > there was an I-D) and then things got carried forward. And if you go > back the start of this thread, you will see why the discussion is > here. > > OK -- we can have the discussion "what does standards-based CM look like, if these 3 operations are all that is available?". IMO, not so good. There seems to be some assumption that the difficult part of implementing edit-config is related to the nc:operation attribute, so the copy-config operation will be much easier to support. This is incorrect. 95% of the complexity is the same with both operations. But forget about implementation. Let's talk about usability. Providing the entire config for replacement in a copy-config is something only an admin user can do. Unless the client has 100% access to all objects (i.e., no access control allowed), then copy-config will fail. (The client will provide a replacement config that attempts to delete nodes it is unauthorized to access). > /js > Andy --f46d0435c1d239f34c04c375010d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 6:55 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 27, 2012 at 06:33:04AM -0700, An= dy Bierman wrote:
> >
> > Sure, something like this could be considered, but we were starti= ng
> > from a device that really only had "load-firmware", hen= ce copy-config
> > was already a step forward.
> >
> So get-config and copy-config are completely irrelevant to your
> implementation? =A0Maybe you have an binary leaf called 'firmware-= image'
> as the only object in the config? =A0IMO this is not CM if the device<= br> > has no config. =A0NETCONF does not even have a standard load-firmware<= br> > operation, so the only part of the standard you use is the <hello&g= t;.

Sorry for expressing myself not well. We did add get-config and
copy-config and we considered that an improvement over the "plug a
cable and do magic to load a new firmware" there was before.

> That's not the point. =A0The problem is that <copy-config> a= llows
> arbitrary changes, but some implementations I have seen are not good > enough to do that. =A0They reject the request or handle it wrong inste= ad.

Obviously, devices and implementations differ.

> Requiring a reboot is yet another area that NETCONF does not address.<= br>
Yes. But that was not the point either. ;-) NETCONF also does not
provide support to load new firmware (but we would likely not have
used it on the devices we dealt with for other technical reasons).



It would be nice if you= r insights from implementation made it into the draft.
The techni= cal issues which lead to 1 solution or another are import.
There = are issues that are more likely to affect small boxes:

=A0 =A0* cannot change arbitrary mix of config objects = at once
=A0 =A0* cannot apply config without requiring a warmstar= t
=A0 =A0* special requirements for firmware-update
I don't think the same exact operations that were designed for
backbone routers have to be used to manage a tiny SOHO router,
to process the entire config in order to change anything seems
c= ontrary to the goals one would associate with "tiny server".


> > > IMO, we should be having the discussion "What do constr= ained
> > > devices need to be managed effectively and efficiently?"= ;
> > > Instead we are working backwards from a solution and asking<= br> > > > "How much NETCONF can we agree on removing from the
> > > the mandatory subset?"
> >
> > I think that is the purpose of the coma list.
> >
>
> Which really makes me wonder why the NETCONF WG is solving
> this problem as well.

As far as I recall, the problem showed up first on this list (because
there was an I-D) and then things got carried forward. And if you go
back the start of this thread, you will see why the discussion is
here.


OK -- we can have the discussion "what does sta= ndards-based CM look like,
if these 3 operations are all that is = available?". =A0IMO, not so good.
There seems to be some assumption that the difficult part of implement= ing
edit-config is related to the nc:operation attribute, so the = copy-config
operation will be much easier to support. =A0This is = incorrect. =A095% of
the complexity is the same with both operations.

<= div>But forget about implementation. =A0Let's talk about usability.
Providing the entire config for replacement in a copy-config
is something only an admin user can do. =A0Unless the client
has 100% access to all objects (i.e., no access control allowed),
then copy-config will fail. =A0(The client will provide a replacement
config that attempts to delete nodes it is unauthorized to access).


=A0
/js

Andy

--f46d0435c1d239f34c04c375010d-- From andy@yumaworks.com Wed Jun 27 08:47:49 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 673C921F871A for ; Wed, 27 Jun 2012 08:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 yLRKjIMZc36G for ; Wed, 27 Jun 2012 08:47:48 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDA821F865C for ; Wed, 27 Jun 2012 08:47:48 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1921270lbb.31 for ; Wed, 27 Jun 2012 08:47:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=hLvm7BL6uJ373TxmKIGuufVLCAAGIGTc6WTLD4N1SYU=; b=WPkuiZeSwMctwQvayNBOC1kkeP11uibOqDKOrEIpviUP/lCf11XU19H77KrTbn6Oyb N8kgaLrzqHFfaVF+uP7j4BvEI9/CaMZRg3y2F6Fn4G6U+t7mN2KVYnY0JaxCSYjNVbjI hboHUsFIPIz1pdhg9lUr5fDLyjMMOpbVUotbZVAQ1Jzo3XLvkYP0kyPUvVljPIxbWju7 RFtgjrON1l2eyUEJUvgHWgV7lK1EUcX8zkkqSNIR9wa10ZMwG7VnfiJEMqCjk/NE03Ra DyLY/ZCbvqMeIyJE474iRapwXEA1AjB5NKU0vwUufspGS3gmu/XQiRewvDYpRVKUY7u4 vNTQ== MIME-Version: 1.0 Received: by 10.112.36.132 with SMTP id q4mr9840939lbj.63.1340812067367; Wed, 27 Jun 2012 08:47:47 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 08:47:47 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120627135540.GA51402@elstar.local> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> <20120627135540.GA51402@elstar.local> Date: Wed, 27 Jun 2012 08:47:47 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary=e0cb4efe3254fc6c8d04c3762227 X-Gm-Message-State: ALoCoQmTBYDtqJA/FUoU978FpnvoBodGfPmyLFq5fLSHfLinTxim0tRlUYrITL9e70fHRtJaA6hi Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:47:49 -0000 --e0cb4efe3254fc6c8d04c3762227 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 6:55 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 27, 2012 at 06:33:04AM -0700, Andy Bierman wrote: > > > > > > Sure, something like this could be considered, but we were starting > > > from a device that really only had "load-firmware", hence copy-config > > > was already a step forward. > > > > > So get-config and copy-config are completely irrelevant to your > > implementation? Maybe you have an binary leaf called 'firmware-image' > > as the only object in the config? IMO this is not CM if the device > > has no config. NETCONF does not even have a standard load-firmware > > operation, so the only part of the standard you use is the . > > Sorry for expressing myself not well. We did add get-config and > copy-config and we considered that an improvement over the "plug a > cable and do magic to load a new firmware" there was before. > > I should be clear that I like netconf-light-00 and think the WG should solve the problems presented in that version of the draft. I just don't want to assume the best solution is going to be some pure subset of base:1.1. Andy --e0cb4efe3254fc6c8d04c3762227 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 6:55 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 27, 2012 at 06:33:04AM -0700, An= dy Bierman wrote:
> >
> > Sure, something like this could be considered, but we were starti= ng
> > from a device that really only had "load-firmware", hen= ce copy-config
> > was already a step forward.
> >
> So get-config and copy-config are completely irrelevant to your
> implementation? =A0Maybe you have an binary leaf called 'firmware-= image'
> as the only object in the config? =A0IMO this is not CM if the device<= br> > has no config. =A0NETCONF does not even have a standard load-firmware<= br> > operation, so the only part of the standard you use is the <hello&g= t;.

Sorry for expressing myself not well. We did add get-config and
copy-config and we considered that an improvement over the "plug a
cable and do magic to load a new firmware" there was before.


I should be clear that I like netconf-= light-00 and think the WG should
solve the problems presented in = that version of the draft.
I just don't want to assume the be= st solution
is going to be some pure subset of base:1.1.

=
Andy

--e0cb4efe3254fc6c8d04c3762227-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 09:00: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 A877321F87C4 for ; Wed, 27 Jun 2012 09:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 DqUUiiD3Gbpu for ; Wed, 27 Jun 2012 08:59:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE6021F87C0 for ; Wed, 27 Jun 2012 08:59:58 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AD3D20BF5; Wed, 27 Jun 2012 17:59:57 +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 Pgz5mymqz6CR; Wed, 27 Jun 2012 17:59:57 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0BB520BF3; Wed, 27 Jun 2012 17:59:56 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id E3DA6202D6CC; Wed, 27 Jun 2012 17:59:56 +0200 (CEST) Date: Wed, 27 Jun 2012 17:59:56 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120627155956.GA51745@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , Netconf References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> <20120627135540.GA51402@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] WG Consensus call: Netconf 2.0? 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, 27 Jun 2012 16:00:01 -0000 On Wed, Jun 27, 2012 at 07:26:45AM -0700, Andy Bierman wrote: > > It would be nice if your insights from implementation made it into the > draft. > The technical issues which lead to 1 solution or another are import. > There are issues that are more likely to affect small boxes: > > * cannot change arbitrary mix of config objects at once > * cannot apply config without requiring a warmstart > * special requirements for firmware-update I agree. > I don't think the same exact operations that were designed for > backbone routers have to be used to manage a tiny SOHO router, > or an alarm clock or a light bub. In particular, copy-config > has many issues which make it unsuitable. Requiring the server > to process the entire config in order to change anything seems > contrary to the goals one would associate with "tiny server". Copy-config is not really bad if you for example can do a warmstart after getting the new config. ;-) Otherwise, it indeed depends on what has been modified and whether you can actually change the subsystems easily (often only true for some of them). Since a warmstart usually kills your NETCONF session, having something RESTful over CoAP might be really interesting, but we have not implemented this yet so the surprises might still be out there in the details. > But forget about implementation. Let's talk about usability. > Providing the entire config for replacement in a copy-config > is something only an admin user can do. Unless the client > has 100% access to all objects (i.e., no access control allowed), > then copy-config will fail. (The client will provide a replacement > config that attempts to delete nodes it is unauthorized to access). On really small devices, there is only an admin user. My good old home router (and I mean several years old) has a web frontend and for advanced users it can give you its config for backup purposed and you can restore it (and it is going to reinitialize itself if you do it). I assume this config download and config upload model followed by a warmstart is a rather common model for many small devices (and my home router is big compared to the devices we tried to implement NETCONF light on). /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@yumaworks.com Wed Jun 27 09:32: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 87DF221F87A1 for ; Wed, 27 Jun 2012 09:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eNYL-J2kjBhT for ; Wed, 27 Jun 2012 09:32:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39FC321F87A0 for ; Wed, 27 Jun 2012 09:32:49 -0700 (PDT) Received: by bkty8 with SMTP id y8so1248869bkt.31 for ; Wed, 27 Jun 2012 09:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=ePTCy4Aj3FYxjknvRR5v5OBG0XJ/Wa7rVra57q8WQn0=; b=CxifhZuw9HdVKHqAdTT4D5uE5QchhMrcRBSYcgIjGldX36lfwfF8sgGtGnnIna/fW5 ZaOnGhjv2ccPeMtFLBtgj6Kh5mCPTAYdBTXbPbfATh6k3wok7llHJnduIsmzJnlg3Pa7 42N3hPHYxAWwKY4FsBLaD+yQwpQ0dV6D7NScbJMQZzux3/8EM798I7EwytCdZitHu49K Ki4QXtvZ8cyU05v39rdFSeJaNnkcj0q80Wy1ZuwNILvTPULBhCMhOghH1+dlMtWlSNA8 dpDCU20/xMrwNUnoWhgOBUiQnQKPailNlQ4xoZmRSsAyYZCYtzloLSqBryN1USHwBvRa 6HWA== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr21120597lab.47.1340814768150; Wed, 27 Jun 2012 09:32:48 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 09:32:48 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120627155956.GA51745@elstar.local> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> <20120627135540.GA51402@elstar.local> <20120627155956.GA51745@elstar.local> Date: Wed, 27 Jun 2012 09:32:48 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary=f46d0435c1d2f717f104c376c3f6 X-Gm-Message-State: ALoCoQmwVwyfDicVT367rTFDXuPbScMnR0bVDjoH3bOeepnrAhgVm97En8c+mwvX1z8zT8m3tUj4 Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 16:32:50 -0000 --f46d0435c1d2f717f104c376c3f6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 8:59 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 27, 2012 at 07:26:45AM -0700, Andy Bierman wrote: > > > > It would be nice if your insights from implementation made it into the > > draft. > > The technical issues which lead to 1 solution or another are import. > > There are issues that are more likely to affect small boxes: > > > > * cannot change arbitrary mix of config objects at once > > * cannot apply config without requiring a warmstart > > * special requirements for firmware-update > > I agree. > > > I don't think the same exact operations that were designed for > > backbone routers have to be used to manage a tiny SOHO router, > > or an alarm clock or a light bub. In particular, copy-config > > has many issues which make it unsuitable. Requiring the server > > to process the entire config in order to change anything seems > > contrary to the goals one would associate with "tiny server". > > Copy-config is not really bad if you for example can do a warmstart > after getting the new config. ;-) Otherwise, it indeed depends on what > has been modified and whether you can actually change the subsystems > easily (often only true for some of them). Since a warmstart usually > kills your NETCONF session, having something RESTful over CoAP might > be really interesting, but we have not implemented this yet so the > surprises might still be out there in the details. > > > But forget about implementation. Let's talk about usability. > > Providing the entire config for replacement in a copy-config > > is something only an admin user can do. Unless the client > > has 100% access to all objects (i.e., no access control allowed), > > then copy-config will fail. (The client will provide a replacement > > config that attempts to delete nodes it is unauthorized to access). > > On really small devices, there is only an admin user. My good old home > router (and I mean several years old) has a web frontend and for > advanced users it can give you its config for backup purposed and you > can restore it (and it is going to reinitialize itself if you do it). > I assume this config download and config upload model followed by a > warmstart is a rather common model for many small devices (and my home > router is big compared to the devices we tried to implement NETCONF > light on). > You are right -- for boxes small enough, there is no access control needed. My home office boxes have 1 user and therefore no need for access control. They are not all "load-and-reboot" though. That's part of the problem. Only some WEBui changes require a reboot, not all. That's where a YANG extension might help. BTW, my little router and APs only have a WEBui - no CLI, no NETCONF, no SNMP. I would like to leverage a programmatic API out of the WEBui as efficiently as possible. That's part of the motivation behind YANG-API. > /js > Andy --f46d0435c1d2f717f104c376c3f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 8:59 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 27, 2012 at 07:26:45AM -0700, An= dy Bierman wrote:
>
> It would be nice if your insights from implementation made it into the=
> draft.
> The technical issues which lead to 1 solution or another are import. > There are issues that are more likely to affect small boxes:
>
> =A0 =A0* cannot change arbitrary mix of config objects at once
> =A0 =A0* cannot apply config without requiring a warmstart
> =A0 =A0* special requirements for firmware-update

I agree.

> I don't think the same exact operations that were designed for
> backbone routers have to be used to manage a tiny SOHO router,
> or an alarm clock or a light bub. =A0In particular, copy-config
> has many issues which make it unsuitable. =A0Requiring the server
> to process the entire config in order to change anything seems
> contrary to the goals one would associate with "tiny server"= .

Copy-config is not really bad if you for example can do a warmstart
after getting the new config. ;-) Otherwise, it indeed depends on what
has been modified and whether you can actually change the subsystems
easily (often only true for some of them). Since a warmstart usually
kills your NETCONF session, having something RESTful over CoAP might
be really interesting, but we have not implemented this yet so the
surprises might still be out there in the details.

> But forget about implementation. =A0Let's talk about usability. > Providing the entire config for replacement in a copy-config
> is something only an admin user can do. =A0Unless the client
> has 100% access to all objects (i.e., no access control allowed),
> then copy-config will fail. =A0(The client will provide a replacement<= br> > config that attempts to delete nodes it is unauthorized to access).
On really small devices, there is only an admin user. My good old home
router (and I mean several years old) has a web frontend and for
advanced users it can give you its config for backup purposed and you
can restore it (and it is going to reinitialize itself if you do it).
I assume this config download and config upload model followed by a
warmstart is a rather common model for many small devices (and my home
router is big compared to the devices we tried to implement NETCONF
light on).

You are right -- for boxes s= mall enough, there is no access control needed.
My home office bo= xes have 1 user and therefore no need for access control.
They ar= e not all "load-and-reboot" though. =A0That's part of the pro= blem.
Only some WEBui changes require a reboot, not all. =A0That's where= a
YANG extension might help.

BTW, my li= ttle router and APs only have a WEBui - no CLI, no NETCONF, no SNMP.
I would like to leverage a programmatic API out of the WEBui as effici= ently
as possible.=A0That's part of the motivation behind YAN= G-API.


/js

Andy
=A0
--f46d0435c1d2f717f104c376c3f6-- From lhotka@nic.cz Wed Jun 27 11:10: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 99AFF11E808F for ; Wed, 27 Jun 2012 11:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.045, 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 YjFVliq6---I for ; Wed, 27 Jun 2012 11:10:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C27AC11E810B for ; Wed, 27 Jun 2012 11:10:44 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 3E08D13FB5D; Wed, 27 Jun 2012 20:10:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340820636; bh=KA818UCGbAHgtq8DEkI6KhBXEukQ2J6CCWGb10crS7w=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CWaxgtllqaooIwAXAYOtHg60CVQlNjm5N3igBi/eaHQbTkMF1tfqtyHXWTDtwZD88 cv3TZrbqMjI90z5gsUTiyT6bI3oEVn8JlUen89Q7Z1KWFijKTtWyKVholUfKE1AbyD AeNTEpwx9jEUm7A6cTF71WFZAxcMqbHl4gDHWo+A= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120627155956.GA51745@elstar.local> Date: Wed, 27 Jun 2012 20:10:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72E5CA51-991E-4B04-994A-C9FC3713E229@nic.cz> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> <20120627135540.GA51402@elstar.local> <20120627155956.GA51745@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:10:45 -0000 On Jun 27, 2012, at 5:59 PM, Juergen Schoenwaelder wrote: > Copy-config is not really bad if you for example can do a warmstart > after getting the new config. ;-) Otherwise, it indeed depends on what > has been modified and whether you can actually change the subsystems > easily (often only true for some of them). Since a warmstart usually > kills your NETCONF session, having something RESTful over CoAP might > be really interesting, but we have not implemented this yet so the > surprises might still be out there in the details. FWIW, BIRD routing daemon, upon receiving the HUP signal, performs an = internal diff of the old and new configuration and restarts only the = subsystems whose configuration changed. So copy-config really needn't be that bad. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Jun 27 11:56: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 127CE11E80A1 for ; Wed, 27 Jun 2012 11:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dqr0cu2MiiFY for ; Wed, 27 Jun 2012 11:56:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2414D11E809A for ; Wed, 27 Jun 2012 11:56:27 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2138570lbb.31 for ; Wed, 27 Jun 2012 11:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=s5tUXOS7z4+EmbGiQ3Jg8lHdUvbsn6Jbpbp2ZPcF+e8=; b=igGvueS7QRSQXBKPgGEDOgUiEM3sBwGCj5oy/372SZHaP/WXyF9aQdmeAN2YXRYVYB Fv2FfIW+4plv9QejHPkW0D4SVJ1eXGTTCKNw+VZAqxdcE905eYB8InVnyX/EX7PHWcNS rHADE0NfiVrgrtok4wB5xiM3R86bX27Tw0k2a9MJt1W12R4c/Dkc+bUVc6hBBB0Flx/U MndzZH0hrDIbRLkWPjR5JMP9CnHpfvmqPtPyMnpdQK2jMAh5QJfjZaSlf+Ma39zM2Hd1 D1vXLqy39cyLlHUhdi1/9co6BSabyDcgh4sHJvN9DjUnG2u2m6dIX1JRClizY+jVPQ4R ediw== MIME-Version: 1.0 Received: by 10.112.86.132 with SMTP id p4mr9830561lbz.22.1340823387083; Wed, 27 Jun 2012 11:56:27 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 11:56:27 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <72E5CA51-991E-4B04-994A-C9FC3713E229@nic.cz> References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> <20120627135540.GA51402@elstar.local> <20120627155956.GA51745@elstar.local> <72E5CA51-991E-4B04-994A-C9FC3713E229@nic.cz> Date: Wed, 27 Jun 2012 11:56:27 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec554d522b1931b04c378c57f X-Gm-Message-State: ALoCoQmLImGThtsW4CIdRyfKwDK/j+AiODr8z16uRONnLyH8CungqOaI74I0CtCUuCOAea77JuL3 Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:56:30 -0000 --bcaec554d522b1931b04c378c57f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 11:10 AM, Ladislav Lhotka wrote: > > On Jun 27, 2012, at 5:59 PM, Juergen Schoenwaelder wrote: > > > Copy-config is not really bad if you for example can do a warmstart > > after getting the new config. ;-) Otherwise, it indeed depends on what > > has been modified and whether you can actually change the subsystems > > easily (often only true for some of them). Since a warmstart usually > > kills your NETCONF session, having something RESTful over CoAP might > > be really interesting, but we have not implemented this yet so the > > surprises might still be out there in the details. > > FWIW, BIRD routing daemon, upon receiving the HUP signal, performs an > internal diff of the old and new configuration and restarts only the > subsystems whose configuration changed. > > So copy-config really needn't be that bad. > > What do you think edit-config does? Same thing. That's my point. Lada > > Andy --bcaec554d522b1931b04c378c57f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 11:10 AM, Ladisl= av Lhotka <lhotka@nic.cz> wrote:

On Jun 27, 2012, at 5:59 PM, Juergen Schoenwaelder wrote:

> Copy-config is not really bad if you for example can do a warmstart > after getting the new config. ;-) Otherwise, it indeed depends on what=
> has been modified and whether you can actually change the subsystems > easily (often only true for some of them). Since a warmstart usually > kills your NETCONF session, having something RESTful over CoAP might > be really interesting, but we have not implemented this yet so the
> surprises might still be out there in the details.

FWIW, BIRD routing daemon, upon receiving the HUP signal, performs an inter= nal diff of the old and new configuration and restarts only the subsystems = whose configuration changed.

So copy-config really needn't be that bad.


What do you think edit-config does? = =A0Same thing. =A0That's my point.

Lada


Andy

--bcaec554d522b1931b04c378c57f-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 14:20: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 26A6911E80A5 for ; Wed, 27 Jun 2012 14:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 tvvuvE8-Ut3G for ; Wed, 27 Jun 2012 14:20:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5060911E80B6 for ; Wed, 27 Jun 2012 14:20:18 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A604420C02; Wed, 27 Jun 2012 23:20:17 +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 j4xqDSUZOgmF; Wed, 27 Jun 2012 23:20:17 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C51320BF6; Wed, 27 Jun 2012 23:20:17 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 2CBAF202DCD0; Wed, 27 Jun 2012 23:20:17 +0200 (CEST) Date: Wed, 27 Jun 2012 23:20:17 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120627212017.GA53341@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf References: <36172B1A6B1A4C3B9ED44132A7AB0780@BertLaptop> <20120627030848.GA47360@elstar.local> <20120627135540.GA51402@elstar.local> <20120627155956.GA51745@elstar.local> <72E5CA51-991E-4B04-994A-C9FC3713E229@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72E5CA51-991E-4B04-994A-C9FC3713E229@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? 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, 27 Jun 2012 21:20:19 -0000 On Wed, Jun 27, 2012 at 08:10:35PM +0200, Ladislav Lhotka wrote: > > On Jun 27, 2012, at 5:59 PM, Juergen Schoenwaelder wrote: > > > Copy-config is not really bad if you for example can do a warmstart > > after getting the new config. ;-) Otherwise, it indeed depends on what > > has been modified and whether you can actually change the subsystems > > easily (often only true for some of them). Since a warmstart usually > > kills your NETCONF session, having something RESTful over CoAP might > > be really interesting, but we have not implemented this yet so the > > surprises might still be out there in the details. > > FWIW, BIRD routing daemon, upon receiving the HUP signal, performs an internal diff of the old and new configuration and restarts only the subsystems whose configuration changed. > I doubt BIRD runs on the devices I have been talking about here. /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 Fri Jun 29 02:00: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 ABE1C21F870E for ; Fri, 29 Jun 2012 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 P9-qvgSAs-6W for ; Fri, 29 Jun 2012 02:00:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E5BB721F8714 for ; Fri, 29 Jun 2012 02:00:06 -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 q5T903fe008657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 29 Jun 2012 11:00:03 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5T900LB023174 for ; Fri, 29 Jun 2012 11:00:03 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jun 2012 11:00:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 29 Jun 2012 10:59:59 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403F7F5BF@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netconf - Requested session has been scheduled for IETF 84 Thread-Index: Ac1VZTiZ+/EEVSefQfC5DkWLimS68QAbvRTQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 29 Jun 2012 09:00:00.0766 (UTC) FILETIME=[90B309E0:01CD55D5] 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: 2858 X-purgate-ID: 151667::1340960403-0000425E-3A189285/0-0/0-0 Subject: [Netconf] FW: netconf - Requested session has been scheduled for IETF 84 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 09:00:09 -0000 SGkgQWxsLA0KDQpOZXRjb25mIHNlc3Npb24gaW4gSUVURiAjODQgaGFzIGJlZW4gc2NoZWR1bGVk IGZvciBNb25kYXkgYWZ0ZXJub29uLiBXZSBhc2tlZCBmb3IgYSBzZXNzaW9uIG9mIDEtaG91ciBi dXQgZ290IDEuNSBob3Vycy4gU2VlIHRoZSBkcmFmdCBhZ2VuZGEgYXQ6IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy84NC9hZ2VuZGEudHh0IA0KDQpJcyBhbnkga2V5IHBsYXll ciBzdWNoIGFzIGRyYWZ0IGF1dGhvciBpcyB1bmFibGUgdG8gYXR0ZW5kIHRoZSBtZWV0aW5nIGlu IFZhbmNvdXZlcj8gSU9XLCBkbyB3ZSBuZWVkIGFueSBNZWV0ZWNobyBvciBXZWJleCBzZXNzaW9u PyBJZiB5ZXMsIHBsZWFzZSBzdGF0ZSBpdCBub3cuDQoNCldlIHNlZW0gdG8gaGF2ZSBwbGVudHkg b2YgdGltZS4gSXMgdGhlcmUgYW55IGludGVyZXN0IHRvIHBsYW4gYSBzbG90IGZvciBkaXNjdXNz aW9uIG9uIGFkZGl0aW9uYWwgdG9waWNzLCBlLmcuIFJFU1QgQVBJPyBJZiB5ZXMsIHBsZWFzZSBz ZW5kIGEgbm90ZSB0byB0aGUgY28tY2hhaXJzLg0KDQpGWUk6IFRoZXJlIGlzIGEgdHV0b3JpYWwg b24gU3VuZGF5IGFmdGVybm9vbiBvbiAiTmV0d29yayBDb25maWd1cmF0aW9uIE1hbmFnZW1lbnQg d2l0aCBORVRDT05GIGFuZCBZQU5HIi4gQUZBSUsgdGhlIHByZXNlbnRlciBpcyBKdWVyZ2VuLg0K DQpDaGVlcnMsIA0KTWVobWV0IA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiAiSUVURiBTZWNyZXRhcmlhdCIgW21haWx0bzphZ2VuZGFAaWV0Zi5vcmddIA0KU2VudDogVGh1 cnNkYXksIEp1bmUgMjgsIDIwMTIgOTozNiBQTQ0KVG86IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERF L011bmljaCkNCkNjOiBuZXRjb25mLWFkc0B0b29scy5pZXRmLm9yZzsgYmVydGlldGZAYndpam5l bi5uZXQ7IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCk7IHdsb0BhbXNsLmNvbQ0KU3Vi amVjdDogbmV0Y29uZiAtIFJlcXVlc3RlZCBzZXNzaW9uIGhhcyBiZWVuIHNjaGVkdWxlZCBmb3Ig SUVURiA4NA0KDQpEZWFyIE1laG1ldCBFcnN1ZSwNCg0KVGhlIHNlc3Npb24ocykgdGhhdCB5b3Ug aGF2ZSByZXF1ZXN0ZWQgaGF2ZSBiZWVuIHNjaGVkdWxlZC4NCkJlbG93IGlzIHRoZSBzY2hlZHVs ZWQgc2Vzc2lvbiBpbmZvcm1hdGlvbiBmb2xsb3dlZCBieQ0KdGhlIG9yaWdpbmFsIHJlcXVlc3Qu IA0KDQpuZXRjb25mIFNlc3Npb24gMSAoMTowMDowMCkNCiAgICBNb25kYXksIEFmdGVybm9vbiBT ZXNzaW9uIElJIDE1NDAtMTcxMA0KICAgIFJvb20gTmFtZTogUmVnZW5jeSBBDQogICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQoNCg0KUmVxdWVz dCBJbmZvcm1hdGlvbjoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCldvcmtpbmcgR3JvdXAgTmFtZTogDQpBcmVhIE5hbWU6IA0K U2Vzc2lvbiBSZXF1ZXN0ZXI6IA0KDQpOdW1iZXIgb2YgU2Vzc2lvbnM6IDENCkxlbmd0aCBvZiBT ZXNzaW9uKHMpOiAgMSBIb3VyDQpOdW1iZXIgb2YgQXR0ZW5kZWVzOiA0MA0KQ29uZmxpY3RzIHRv IEF2b2lkOiANCiBGaXJzdCBQcmlvcml0eTogb3BzYXdnIG9wc2FyZWEgbmV0bW9kIGlwZml4IGVt YW4NCiBTZWNvbmQgUHJpb3JpdHk6IHRzdndnIHRzdmFyZWEgYXBwYXJlYSBjb3JlIGFkc2xtaWIg YXJtZCByYWRleHQgZGltZSBzaWRyDQogVGhpcmQgUHJpb3JpdHk6IG9wc2VjIGdyb3cgdjZvcHMg bWJvbmVkIHNjaW0gZG5zb3AgZGhjIGFuY3AgbHdpZw0KDQoNClNwZWNpYWwgUmVxdWVzdHM6DQog IElmIHBvc3NpYmxlIHBsZWFzZSBzY2hlZHVsZSBORVRDT05GIGFuZCBORVRNT0Qgc2Vzc2lvbnMg b24gc3Vic2VxdWVudCBkYXlzIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHdlZWssIGUuZy4gTkVU Q09ORiBvbiBNb25kYXkgYW5kIE5FVE1PRCBvbiBUdWVzZGF5LiBUaGFuayB5b3UuIA0KT3RoZXIg Y29uZmxpY3RzOiBOTVJHIERDIFNETlAgTlZPMyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo=