From bertietf@bwijnen.net Mon Jan 2 03:02: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 76DE321F8B37 for ; Mon, 2 Jan 2012 03:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 sZmg6pBY62T5 for ; Mon, 2 Jan 2012 03:02:22 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 8856C21F8B30 for ; Mon, 2 Jan 2012 03:02:22 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Rhfek-0002oW-1B for netconf@ietf.org; Mon, 02 Jan 2012 12:02:20 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest219.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Rhfej-0004gf-Sb for netconf@ietf.org; Mon, 02 Jan 2012 12:02:17 +0100 Message-ID: <4F018EBA.20707@bwijnen.net> Date: Mon, 02 Jan 2012 12:02:18 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: netconf References: <03E146553DC644748AA096E6839D172B@BertLaptop> In-Reply-To: <03E146553DC644748AA096E6839D172B@BertLaptop> X-Forwarded-Message-Id: <03E146553DC644748AA096E6839D172B@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd422167647998c1a9237044031e005cf23 Subject: [Netconf] Reminder: Pls check before COB Jan 6th, 2012: draft-ietf-netconf-access-control-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 11:02:23 -0000 First: Happy new year and all the best for 2012. This is a gentle reminder. Because of the Holidays, you might not have noticed (or by now forgotten about) the below. Bert document shepherd. -------- Original Message -------- Subject: [Netconf] Pls check before COB Jan 6th, 2012: draft-ietf-netconf-access-control-07.txt Date: Tue, 27 Dec 2011 17:48:52 +0100 From: Bert Wijnen (IETF) Organization: Consultant To: Netconf Dear WG participants, Just on Xmas eve, we cleared the IESG comments and DISCUSS on this document. To clear the discuss, we had to add a knob in the ietf-netconf-acm YANG module that allows an administartor to enable/disable dynamic addtion of external groups: leaf enable-external-groups { type boolean; default true; description "Controls whether the server uses the groups reported by the NETCONF transport layer when it assigns the user to a set of NACM groups. If this leaf has the value 'false', any group names reported by the transport layer are ignored by the server."; } That is the only substantial change, and we want to be sure the WG agrees with that. Other than that we believe that the changes are only editorial and/or clarifications. Pls let us know if you agree or disagree. Bert Wijnen, document shepherd ----- Original Message ----- From: To: Cc: Sent: Friday, December 23, 2011 1:57 PM Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Network Configuration Working > Group of the IETF. > > Title : Network Configuration Protocol (NETCONF) Access Control > Model > Author(s) : Andy Bierman > Martin Bjorklund > Filename : draft-ietf-netconf-access-control-07.txt > Pages : 54 > Date : 2011-12-23 > > The standardization of network configuration interfaces for use with > the NETCONF protocol requires a structured and secure operating > environment that promotes human usability and multi-vendor > interoperability. There is a need for standard mechanisms to > restrict NETCONF protocol access for particular users to a pre- > configured subset of all available NETCONF protocol operations and > content. This document defines such an access control model. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-07.txt > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From andy@netconfcentral.org Mon Jan 2 10:32:27 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 6D83711E80A5 for ; Mon, 2 Jan 2012 10:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgKuVxUK1k7W for ; Mon, 2 Jan 2012 10:32:26 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id E441F11E8093 for ; Mon, 2 Jan 2012 10:32:22 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q02IWKre030266 for ; Mon, 2 Jan 2012 13:32:22 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:44015] helo=[192.168.0.126]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F4/41-15882-338F10F4; Mon, 02 Jan 2012 13:32:19 -0500 Message-ID: <4F01F831.20703@netconfcentral.org> Date: Mon, 02 Jan 2012 10:32:17 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 18:32:27 -0000 Hi, I am running into some yuma implementation issues that may have some impact on NACM. A server cannot really preserve the individual edits on candidate by multiple writers, when applying the commit. The safe thing to do is determine which nodes are really changing in the running config at commit time. (e.g., consider multiple edits on the same node). Since the server has to derive edit operations based on the actual differences between candidate and running, the NACM rules can be affected. The granularity for NACM access is probably too fine. E.g, session A has full rights to /foo/* and creates a /foo list entry in the candidate. Session B has only full access to the /foo/knob1 leaf, and it creates /foo/leaf1 in the candidate. At this point /foo does not exist in the running config. Depending on the NACM rules and candidate contents, perhaps no session has enough rights for a commit to succeed at this point. (We assume A can still commit here ;-) This /foo/leaf1 write access will not fail in NACM when the is done because the implicit (or explicit) edit operation on /foo is 'none'. However, a commit attempt by session B must fail because it cannot create the /foo node. There are many corner cases one could construct where individual edits to the candidate will be OK for a given group, but not the end result commit request. I don't think the NACM draft needs to change, but I suspect multi-writer candidate commits will not be implemented correctly (like yuma right now ;-) Andy From mbj@tail-f.com Mon Jan 2 12:43: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 BDD4B21F84B1 for ; Mon, 2 Jan 2012 12:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 W5qK26SZZ2St for ; Mon, 2 Jan 2012 12:43:07 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9C21F84AE for ; Mon, 2 Jan 2012 12:43:07 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E1E981200050; Mon, 2 Jan 2012 21:43:03 +0100 (CET) Date: Mon, 02 Jan 2012 21:43:03 +0100 (CET) Message-Id: <20120102.214303.140235524.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F01F831.20703@netconfcentral.org> References: <4F01F831.20703@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 20:43:07 -0000 Hi, Andy Bierman wrote: > A server cannot really preserve the individual edits on candidate by multiple > writers, > when applying the commit. The safe thing to do is determine which nodes are > really > changing in the running config at commit time. This is also described in the draft: 3.2.6. Operation The server MUST determine the exact nodes in the running configuration datastore which are actually different, and only check "create", "update", and "delete" access permissions for this set of nodes, which could be empty. > Since the server has to derive edit operations based on the actual differences > between > candidate and running, the NACM rules can be affected. > > The granularity for NACM access is probably too fine. > E.g, session A has full rights to /foo/* and creates a /foo list entry in the > candidate. > Session B has only full access to the /foo/knob1 leaf, and it creates > /foo/leaf1 > in the candidate. At this point /foo does not exist in the running config. > Depending on the NACM rules and candidate contents, perhaps no session has > enough > rights for a commit to succeed at this point. (We assume A can still commit > here ;-) > > This /foo/leaf1 write access will not fail in NACM when the is > done > because the implicit (or explicit) edit operation on /foo is 'none'. > However, a commit attempt by session B must fail because it cannot create the > /foo node. > > There are many corner cases one could construct where individual edits to the > candidate will be OK for a given group, but not the end result commit request. Yes, this has been discussed before. > I don't think the NACM draft needs to change, but I suspect multi-writer > candidate > commits will not be implemented correctly (like yuma right now ;-) /martin From andy@netconfcentral.org Mon Jan 2 13:44: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 1A79F1F0C47 for ; Mon, 2 Jan 2012 13:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86ln5+lWMsIc for ; Mon, 2 Jan 2012 13:44:45 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFBA1F0C35 for ; Mon, 2 Jan 2012 13:44:45 -0800 (PST) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q02LifJ7006410 for ; Mon, 2 Jan 2012 16:44:43 -0500 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:60108] helo=[192.168.0.126]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E8/C1-18653-945220F4; Mon, 02 Jan 2012 16:44:41 -0500 Message-ID: <4F022547.9070507@netconfcentral.org> Date: Mon, 02 Jan 2012 13:44:39 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Bjorklund References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> In-Reply-To: <20120102.214303.140235524.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 21:44:46 -0000 On 01/02/2012 12:43 PM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> A server cannot really preserve the individual edits on candidate by multiple >> writers, >> when applying the commit. The safe thing to do is determine which nodes are >> really >> changing in the running config at commit time. > This is also described in the draft: > > 3.2.6. Operation > > The server MUST determine the exact nodes in the running > configuration datastore which are actually different, and only check > "create", "update", and "delete" access permissions for this set of > nodes, which could be empty. > > >> Since the server has to derive edit operations based on the actual differences >> between >> candidate and running, the NACM rules can be affected. >> >> The granularity for NACM access is probably too fine. >> E.g, session A has full rights to /foo/* and creates a /foo list entry in the >> candidate. >> Session B has only full access to the /foo/knob1 leaf, and it creates >> /foo/leaf1 >> in the candidate. At this point /foo does not exist in the running config. >> Depending on the NACM rules and candidate contents, perhaps no session has >> enough >> rights for a commit to succeed at this point. (We assume A can still commit >> here ;-) >> >> This /foo/leaf1 write access will not fail in NACM when the is >> done >> because the implicit (or explicit) edit operation on /foo is 'none'. >> However, a commit attempt by session B must fail because it cannot create the >> /foo node. >> >> There are many corner cases one could construct where individual edits to the >> candidate will be OK for a given group, but not the end result commit request. > Yes, this has been discussed before. OK -- I guess administrators will be careful with NACM rules. Complete write access (CUD) vs. no write access at all will always work as expected. Did we cover this case, or is it implied: list mylist { key idx; leaf idx { type int32; } leaf delnode { when "../leaf1 = 5"; type string; } leaf leaf1 { type int32; } } Start: 1 ok to delete me? 5 User A has write access to /mylist/leaf1, but not /mylist/delnode. User A changes /mylist/leaf1 from '5' to '42' in the candidate config, which works. User A attempts a commit, which fails with 'access-denied' error for deleting /mylist/delnode. Should only an actual attempt will produce this error, or should the function return the same error? Does mean "this config is OK" or "this config is OK and you can perform all the requested edits"? IMO, it has to be the former because there may be no target config specified (w/ inline ) to derive edit operations. Andy > >> I don't think the NACM draft needs to change, but I suspect multi-writer >> candidate >> commits will not be implemented correctly (like yuma right now ;-) > > > /martin > > From mehmet.ersue@nsn.com Thu Jan 5 03:05: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 58DCF21F87B5 for ; Thu, 5 Jan 2012 03:05:52 -0800 (PST) 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 hz6T4Z3Gi9uf for ; Thu, 5 Jan 2012 03:05:51 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8EC21F87CA for ; Thu, 5 Jan 2012 03:05:51 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q05B5mPY018421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Jan 2012 12:05:48 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q05B5lV9018337 for ; Thu, 5 Jan 2012 12:05:47 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 12:05:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 12:05:47 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64033807F8@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Session in IETF 83 Thread-Index: AczLmfpQqzGpc1gLT0yA+xPf3Tg8zA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 05 Jan 2012 11:05:47.0740 (UTC) FILETIME=[FA57E1C0:01CCCB99] Subject: [Netconf] Netconf Session in IETF 83 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 11:05:52 -0000 Hi All, please let us know the topics you would like to discuss in IETF 83=20 NETCONF session. Who is going to submit an update (e.g. 5539bis)?=20 Are there any new drafts or remaining issues? Mehmet & Bert From tomoyuki.iijima.fg@hitachi.com Fri Jan 6 00:17: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 1132D11E80B3 for ; Fri, 6 Jan 2012 00:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXnWadUyeud1 for ; Fri, 6 Jan 2012 00:17:56 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 278C711E8096 for ; Fri, 6 Jan 2012 00:17:51 -0800 (PST) Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id BE91537ACA for ; Fri, 6 Jan 2012 17:17:49 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv3.hitachi.co.jp (8.13.1/8.13.1) id q068Hn5X015682; Fri, 6 Jan 2012 17:17:49 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q068HmYH024158 for ; Fri, 6 Jan 2012 17:17:49 +0900 X-AuditID: b753bd60-a3089ba000000655-eb-4f06ae2c5dc3 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id CA8427742DE for ; Fri, 6 Jan 2012 17:17:48 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id q068HlW15839402; Fri, 6 Jan 2012 17:17:47 +0900 Message-ID: <4F06AE2F.2070005@hitachi.com> Date: Fri, 06 Jan 2012 17:17:51 +0900 From: Tomoyuki Iijima User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A64033807F8@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64033807F8@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Netconf Session in IETF 83 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:17:57 -0000 Hi Mehmet & Bert, I'd like to inform update of NETCONF over WebSocket and an idea for 4743bis, although I-Ds are to be published later on. I'd appreciate it if you could spare me a 5-10 minutes slot. Kind regards, Tomoyuki Iijima (2012/01/05 20:05), Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > please let us know the topics you would like to discuss in IETF 83 > NETCONF session. Who is going to submit an update (e.g. 5539bis)? > Are there any new drafts or remaining issues? > > Mehmet& Bert > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From bertietf@bwijnen.net Mon Jan 9 01:21: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 1307C21F864B for ; Mon, 9 Jan 2012 01:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 CC87bXVfTw9L for ; Mon, 9 Jan 2012 01:21:34 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7C121F863C for ; Mon, 9 Jan 2012 01:21:33 -0800 (PST) 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 1RkBQ3-000187-90; Mon, 09 Jan 2012 10:21:32 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest219.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RkBQ2-0007YP-Nr; Mon, 09 Jan 2012 10:21:31 +0100 Message-ID: <4F0AB19A.3080403@bwijnen.net> Date: Mon, 09 Jan 2012 10:21:30 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer References: <201111211559.pALFxthw007924@idle.juniper.net> In-Reply-To: <201111211559.pALFxthw007924@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40ae7bedf93affed3c2a821a44411f9d4 Cc: netconf Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:21:35 -0000 Hi Phil. So, I hear no "we will help to update the netconf over beep document"... and we NEED volunteers if we want to do anything with these documents. Can you tell us if your implementation is indeed the spec as documented in RFC 4744? Bert On 11/21/11 4:59 PM, Phil Shafer wrote: > "Bert Wijnen (IETF)" writes: >> 1 - There are multiple implementations >> 2 - There is real production deployment >> 3 - There are multiple people in the WG who want to work >> on such a revision. >> 4 - The existing implementations (if any) are also willing >> to implement such a revision > > We have an implementation of NETCONF over BEEP in JUNOS that is > used in real deployments. I'm mostly on hiatus from IETF work due > to "day job" commitments and travel restrictions, so that's two out > of four for me. > > Thanks, > Phil > From bertietf@bwijnen.net Mon Jan 9 07:42: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 7B7E121F8820 for ; Mon, 9 Jan 2012 07:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 MKsddn4FKCSF for ; Mon, 9 Jan 2012 07:42:03 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 5134F21F881C for ; Mon, 9 Jan 2012 07:41:50 -0800 (PST) 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 1RkHM2-0006aB-0t for netconf@ietf.org; Mon, 09 Jan 2012 16:41:47 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest126.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RkHM1-0007QP-RN for netconf@ietf.org; Mon, 09 Jan 2012 16:41:45 +0100 Message-ID: <4F0B0AB9.7010409@bwijnen.net> Date: Mon, 09 Jan 2012 16:41:45 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Netconf References: <4F0AB370.8070404@bwijnen.net> In-Reply-To: <4F0AB370.8070404@bwijnen.net> X-Forwarded-Message-Id: <4F0AB370.8070404@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ea8b0fb834f7c84c4ac05bc7ffc691ad Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:42:07 -0000 Dear WG participants, We asked for input on this topic on Nov 21st (2011) and asked you to respond by Dec 15th (2011). See email below. Sofar, we have received responses/reports of: - ONE implementation of Netconf over BEEP - ONE implementation of Netconf over SOAP We have not yet heard any volunteering for updating the Netconf over Beep document. We have heard from 1 person who is willing to update the Netconf over SOAP document. The deadline was Dec 15th. We do not think we can claim that we a good case and enough volunteers to actually do that work. So it seems we indeed better obsolete the two documents: RFC 4743 RFC 4744 For that, we probably have to write a small document too. Who volunteers for that? Bert and Mehmet. On 11/21/11 3:10 PM, Bert Wijnen (IETF) wrote: > > Response requested from all WG participants by December 15th 2011. > > During our meeting at IETF82, the question was raised if > we should consider to obsolete (and make HISTORIC) 2 of > the NETCONF transport protocols: > > - RFC4743 - Netconf over SOAP > - RFC4744 - Netconf over BEEP > > It was noted, that they are currently at PS (Proposed Standard), > but that they have a normative reference to the obsoleted Netconf > Protocol (RFC4741). They cannot just depend on the new RFC6241 > without being updated to also support the :base:1.1 capability, > specifically: > > o Introduced a NETCONF username and a requirement for transport > protocols to explain how a username is derived. > > One option would be to do a revision of those 2 RFCs (similar > to the revision of RFC6242 (which obsoleted RFC4742) and > rfc5539-bis work. > > However, it seems that as a WG, we should ONLY consider that > option IF: > > 1 - There are multiple implementations > 2 - There is real production deployment > 3 - There are multiple people in the WG who want to work > on such a revision. > 4 - The existing implementations (if any) are also willing > to implement such a revision > > Without that, it seems that OBSOLETING is the best path forward. > > We (WG chairs) propose that the default path forward will be > to obsolete RFC4743 and RFC4744. > > Anyone opposing that, please speak up asap but do so > BEFORE December 15. > > And, if you do object, then please include answers to > the 4 IFs above. > > Anyone in support of "obsoleting RFC4743 and RFC4744", > please let us know by December 15 as well. It is good to > also know that we have indeed WG consensus on this. > > The editors/authors of the documents have been (bbc) copied. > > Bert and Mehmet. > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From phil@juniper.net Mon Jan 9 09:17: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 6498311E80AC for ; Mon, 9 Jan 2012 09:17:22 -0800 (PST) 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 WnBuXqWpo2jy for ; Mon, 9 Jan 2012 09:17:21 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id D502B11E809A for ; Mon, 9 Jan 2012 09:17:18 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTwshHn7WjyVUqvwtO0h2tOsTKpccWCNl@postini.com; Mon, 09 Jan 2012 09:17:20 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 9 Jan 2012 09:12:37 -0800 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 q09HCKS32962; Mon, 9 Jan 2012 09:12:35 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q09GgpFJ022922; Mon, 9 Jan 2012 16:42:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201091642.q09GgpFJ022922@idle.juniper.net> To: "Bert Wijnen (IETF)" In-Reply-To: <4F0AB19A.3080403@bwijnen.net> Date: Mon, 9 Jan 2012 11:42:51 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:17:22 -0000 "Bert Wijnen (IETF)" writes: >Can you tell us if your implementation is indeed >the spec as documented in RFC 4744? It is, but given the lack of interest in the WG (and in Juniper) and given that this is only really used internally (between a single NM product and JUNOS boxes), I'd say just let it go quietly into the dust bin of history. Thanks, Phil From bertietf@bwijnen.net Tue Jan 10 04:45: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 8076421F851E for ; Tue, 10 Jan 2012 04:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 JzsB53OSCpFb for ; Tue, 10 Jan 2012 04:45:11 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id E361921F8504 for ; Tue, 10 Jan 2012 04:45:10 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Rkb4c-00032M-Qz; Tue, 10 Jan 2012 13:45:07 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Rkb4c-0008Cd-4c; Tue, 10 Jan 2012 13:45:06 +0100 Message-ID: <4F0C32D1.4090200@bwijnen.net> Date: Tue, 10 Jan 2012 13:45:05 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dan Romascanu , netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49afbb27930db6a6e781bfe8ec79f3959 Subject: [Netconf] Next step for: draft-ietf-netconf-access-control-07 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, 10 Jan 2012 12:45:11 -0000 Dan, with revision 07 of the document, all discusses have been cleared, and all comments have been either responded to or addressed in revision 7. I have give the WG over a week to check if they had any further comments or objections (because we added a YANG leaf in revision7 to address DBH discuss). No objections have been raised, so I believe the document is ready to be sent to the RFC-Editor. Thanks, Bert Wijnen document shepherd From wjhns1@hardakers.net Tue Jan 10 06:32: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 DFCF421F85FD for ; Tue, 10 Jan 2012 06:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2sV124bNuEB for ; Tue, 10 Jan 2012 06:32:03 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 517DF21F85F8 for ; Tue, 10 Jan 2012 06:32:03 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id B9E35415; Tue, 10 Jan 2012 06:32:01 -0800 (PST) From: Wes Hardaker To: Andy Bierman References: <4F01F831.20703@netconfcentral.org> Date: Tue, 10 Jan 2012 06:32:01 -0800 In-Reply-To: <4F01F831.20703@netconfcentral.org> (Andy Bierman's message of "Mon, 02 Jan 2012 10:32:17 -0800") Message-ID: <0laa5v7hni.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] NACM issue? 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, 10 Jan 2012 14:32:04 -0000 >>>>> On Mon, 02 Jan 2012 10:32:17 -0800, Andy Bierman said: AB> There are many corner cases one could construct where individual edits AB> to the candidate will be OK for a given group, but not the end result AB> commit request. I think you've all heard my "global operations are dangerous" speech too many times, so I won't repeat it :-P One of these days I'll have the hours to write some drafts to fix my problems. But, one other thing to note: race conditions exist as well and NACM can't be implemented properly without locking. Specifically, even if only a single user edits the candidate config and NACM checks it and ensures it can be copied to running, if the copy operation and NACM both pull from the actual candidate config (as opposed to a temporary copy of it), then there is a race. T+0 NACM checks and verifies T+2 copy-config places the copy into running Obviously, the problem is: T+1 user B edits /foo/bar -- Wes Hardaker SPARTA, Inc. From andy@netconfcentral.org Tue Jan 10 07:51: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 42C2221F85FD for ; Tue, 10 Jan 2012 07:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 MFzFxh5Lj2tR for ; Tue, 10 Jan 2012 07:51:41 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 459AD21F85F7 for ; Tue, 10 Jan 2012 07:51:41 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0AFpceI029855 for ; Tue, 10 Jan 2012 10:51:40 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:39159] helo=[192.168.0.126]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 33/C7-03964-98E5C0F4; Tue, 10 Jan 2012 10:51:37 -0500 Message-ID: <4F0C5E89.90305@netconfcentral.org> Date: Tue, 10 Jan 2012 07:51:37 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Wes Hardaker References: <4F01F831.20703@netconfcentral.org> <0laa5v7hni.fsf@wjh.hardakers.net> In-Reply-To: <0laa5v7hni.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] NACM issue? 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, 10 Jan 2012 15:51:42 -0000 On 01/10/2012 06:32 AM, Wes Hardaker wrote: >>>>>> On Mon, 02 Jan 2012 10:32:17 -0800, Andy Bierman said: > > AB> There are many corner cases one could construct where individual edits > AB> to the candidate will be OK for a given group, but not the end result > AB> commit request. > > I think you've all heard my "global operations are dangerous" speech too > many times, so I won't repeat it :-P One of these days I'll have the > hours to write some drafts to fix my problems. > Good - write a draft > But, one other thing to note: race conditions exist as well and NACM > can't be implemented properly without locking. Specifically, even if > only a single user edits the candidate config and NACM checks it and > ensures it can be copied to running, if the copy operation and NACM both > pull from the actual candidate config (as opposed to a temporary copy of > it), then there is a race. > > T+0 NACM checks and verifies > T+2 copy-config places the copy into running > > Obviously, the problem is: > > T+1 user B edits /foo/bar > I'm not following this example. The server does not check candidate for NACM rules, just running. Some internal caching of ACM details insures that the rules in affect at the start of the message are used throughout the entire message. Andy From randy_presuhn@mindspring.com Tue Jan 10 09:15:13 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7682F21F868A for ; Tue, 10 Jan 2012 09:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsUuX8AvNgaP for ; Tue, 10 Jan 2012 09:15:12 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 79CD821F8686 for ; Tue, 10 Jan 2012 09:15:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=L9AQNKvc9GAqssWTy+d3HSngjnNw+NxYcUisb+xbiifIr2S9FVgl6f2a3Y6e1U+1; 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.38.144.30] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RkfHz-0004sX-Ge for netconf@ietf.org; Tue, 10 Jan 2012 12:15:11 -0500 Message-ID: <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "NETCONF" References: <4F01F831.20703@netconfcentral.org><0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> Date: Tue, 10 Jan 2012 09:18:25 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f82db2771e48bb6492faf6a52e0298665350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.30 Subject: Re: [Netconf] NACM issue? 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, 10 Jan 2012 17:15:13 -0000 Hi - > From: "Andy Bierman" > To: "Wes Hardaker" > Cc: "NETCONF" > Sent: Tuesday, January 10, 2012 7:51 AM > Subject: Re: [Netconf] NACM issue? > > On 01/10/2012 06:32 AM, Wes Hardaker wrote: > >>>>>> On Mon, 02 Jan 2012 10:32:17 -0800, Andy Bierman said: > > > > AB> There are many corner cases one could construct where individual edits > > AB> to the candidate will be OK for a given group, but not the end result > > AB> commit request. > > > > I think you've all heard my "global operations are dangerous" speech too > > many times, so I won't repeat it :-P One of these days I'll have the > > hours to write some drafts to fix my problems. > > > > > Good - write a draft > > > > But, one other thing to note: race conditions exist as well and NACM > > can't be implemented properly without locking. Specifically, even if > > only a single user edits the candidate config and NACM checks it and > > ensures it can be copied to running, if the copy operation and NACM both > > pull from the actual candidate config (as opposed to a temporary copy of > > it), then there is a race. > > > > T+0 NACM checks and verifies > > T+2 copy-config places the copy into running > > > > Obviously, the problem is: > > > > T+1 user B edits /foo/bar > > > > I'm not following this example. > The server does not check candidate for NACM rules, just running. > Some internal caching of ACM details insures that the rules in affect > at the start of the message are used throughout the entire message. This problem isn't a question of where the NACM rules live. The heart of the problem is the candidate / running / copy-config way of doing things in the presence of multiple users with potentially differing permissions. In the example Wes gives, changes made by user B, which have not been checked against user *A*'s permissions, get copied into the running configuration as a side-effect of copy-config. Randy From andy@netconfcentral.org Tue Jan 10 09:48: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 5458421F868A for ; Tue, 10 Jan 2012 09:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 ITHIxAcBi8+J for ; Tue, 10 Jan 2012 09:48:56 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id A11E221F8688 for ; Tue, 10 Jan 2012 09:48:56 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0AHmrj6016242 for ; Tue, 10 Jan 2012 12:48:56 -0500 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:38035] helo=[192.168.0.126]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 9E/D9-28181-50A7C0F4; Tue, 10 Jan 2012 12:48:53 -0500 Message-ID: <4F0C7A05.4000903@netconfcentral.org> Date: Tue, 10 Jan 2012 09:48:53 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Presuhn References: <4F01F831.20703@netconfcentral.org><0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> In-Reply-To: <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] NACM issue? 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, 10 Jan 2012 17:48:57 -0000 On 01/10/2012 09:18 AM, Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Wes Hardaker" >> Cc: "NETCONF" >> Sent: Tuesday, January 10, 2012 7:51 AM >> Subject: Re: [Netconf] NACM issue? >> >> On 01/10/2012 06:32 AM, Wes Hardaker wrote: >>>>>>>> On Mon, 02 Jan 2012 10:32:17 -0800, Andy Bierman said: >>> >>> AB> There are many corner cases one could construct where individual edits >>> AB> to the candidate will be OK for a given group, but not the end result >>> AB> commit request. >>> >>> I think you've all heard my "global operations are dangerous" speech too >>> many times, so I won't repeat it :-P One of these days I'll have the >>> hours to write some drafts to fix my problems. >>> >> >> >> Good - write a draft >> >> >>> But, one other thing to note: race conditions exist as well and NACM >>> can't be implemented properly without locking. Specifically, even if >>> only a single user edits the candidate config and NACM checks it and >>> ensures it can be copied to running, if the copy operation and NACM both >>> pull from the actual candidate config (as opposed to a temporary copy of >>> it), then there is a race. >>> >>> T+0 NACM checks and verifies >>> T+2 copy-config places the copy into running >>> >>> Obviously, the problem is: >>> >>> T+1 user B edits /foo/bar >>> >> >> I'm not following this example. >> The server does not check candidate for NACM rules, just running. >> Some internal caching of ACM details insures that the rules in affect >> at the start of the message are used throughout the entire message. > > This problem isn't a question of where the NACM rules live. The heart > of the problem is the candidate / running / copy-config way of doing things > in the presence of multiple users with potentially differing permissions. > In the example Wes gives, changes made by user B, which have not been > checked against user *A*'s permissions, get copied into the running > configuration as a side-effect of copy-config. It is an implementation detail, but a server can figure out what actually changed in a commit or copy-config. The session attempting the or 'external' operation has to be authorized to perform all the edits (derived from the XML-diff), even for deletion of false when-stmt nodes that happen to turn false as a side effect of other edits. The candidate can deadlock, where no 1 user has enough rights to commit all the edits, and thus require some user to invoke to clear the deadlock. Direct writes to running cannot cause such a deadlock, since a full validation is required for each edit. > > Randy > Andy From randy_presuhn@mindspring.com Tue Jan 10 16:45: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 A7A535E8001 for ; Tue, 10 Jan 2012 16:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEGU2kuT+9ey for ; Tue, 10 Jan 2012 16:45:32 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id D66DB21F87F1 for ; Tue, 10 Jan 2012 16:45:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nr+F5XqSsWjyl6j12Q36UnQm1okqBkPTXBwUcuGaXH9vRnxtMOzV3ZpruAkfbEpr; 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.38.144.30] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RkmJm-0005KH-0P for netconf@ietf.org; Tue, 10 Jan 2012 19:45:30 -0500 Message-ID: <000e01cccffa$c788b2a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "NETCONF" References: <4F01F831.20703@netconfcentral.org><0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> <4F0C7A05.4000903@netconfcentral.org> Date: Tue, 10 Jan 2012 16:48:46 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f3a66b7290983a1b4d7b459ec70fcb10e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.30 Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 00:45:33 -0000 Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: "NETCONF" > Sent: Tuesday, January 10, 2012 9:48 AM > Subject: Re: [Netconf] NACM issue? ... > The candidate can deadlock, where no 1 user has enough rights to > commit all the edits, and thus require some user to invoke > to clear the deadlock. ... Sounds like a recipe for a DoS attack, in which a relatively unprivileged user could prevent another user from getting his/her work done. Trivial example: A and B have rights to modify disjoint subsets of information. Either can block the other indefinitely. Randy From tomoyuki.iijima.fg@hitachi.com Tue Jan 10 17:18:36 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 E752611E80A6 for ; Tue, 10 Jan 2012 17:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIALRkZ0Aq4D for ; Tue, 10 Jan 2012 17:18:36 -0800 (PST) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 390DE21F858F for ; Tue, 10 Jan 2012 17:18:35 -0800 (PST) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id B1C8733CC3 for ; Wed, 11 Jan 2012 10:18:34 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id q0B1IY1K025006; Wed, 11 Jan 2012 10:18:34 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q0B1IWv7021884 for ; Wed, 11 Jan 2012 10:18:33 +0900 X-AuditID: b753bd60-98392ba000007b1b-5c-4f0ce3676b77 Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id CCFAF2043B7 for ; Wed, 11 Jan 2012 10:18:31 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id q0B1ITo5390466; Wed, 11 Jan 2012 10:18:29 +0900 Message-ID: <4F0CE365.7030309@hitachi.com> Date: Wed, 11 Jan 2012 10:18:29 +0900 From: Tomoyuki Iijima User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: netconf@ietf.org References: <4F0AB370.8070404@bwijnen.net> <4F0B0AB9.7010409@bwijnen.net> In-Reply-To: <4F0B0AB9.7010409@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 01:18:37 -0000 Hi, > We do not think we can claim that we a good case > and enough volunteers to actually do that work. > So it seems we indeed better obsolete the two > documents: > > RFC 4743 > RFC 4744 Regarding RFC 4743, I was asked by chairs privately to answer following questions in the mailing list. For what it's worth, let me answer here. - Your company(Hitachi)'s SOAP implementation and Alaxala's one are the same? - Yes, that's correct. - Do you have a plan to update current implementation? - As of now, no, I'm just considering how to implement. As for future road map of commercial products, I can't say for sure (since I'm not in a managerial position). Chairs, above are catching your intentions? Kind regards, Tomoyuki Iijima (2012/01/10 0:41), Bert Wijnen (IETF) wrote: > Dear WG participants, > > We asked for input on this topic on Nov 21st (2011) and > asked you to respond by Dec 15th (2011). See email below. > > Sofar, we have received responses/reports of: > > - ONE implementation of Netconf over BEEP > - ONE implementation of Netconf over SOAP > > We have not yet heard any volunteering for updating > the Netconf over Beep document. > We have heard from 1 person who is willing to > update the Netconf over SOAP document. > > The deadline was Dec 15th. > > We do not think we can claim that we a good case > and enough volunteers to actually do that work. > So it seems we indeed better obsolete the two > documents: > > RFC 4743 > RFC 4744 > > For that, we probably have to write a small document > too. Who volunteers for that? > > Bert and Mehmet. > > On 11/21/11 3:10 PM, Bert Wijnen (IETF) wrote: >> >> Response requested from all WG participants by December 15th 2011. >> >> During our meeting at IETF82, the question was raised if >> we should consider to obsolete (and make HISTORIC) 2 of >> the NETCONF transport protocols: >> >> - RFC4743 - Netconf over SOAP >> - RFC4744 - Netconf over BEEP >> >> It was noted, that they are currently at PS (Proposed Standard), >> but that they have a normative reference to the obsoleted Netconf >> Protocol (RFC4741). They cannot just depend on the new RFC6241 >> without being updated to also support the :base:1.1 capability, >> specifically: >> >> o Introduced a NETCONF username and a requirement for transport >> protocols to explain how a username is derived. >> >> One option would be to do a revision of those 2 RFCs (similar >> to the revision of RFC6242 (which obsoleted RFC4742) and >> rfc5539-bis work. >> >> However, it seems that as a WG, we should ONLY consider that >> option IF: >> >> 1 - There are multiple implementations >> 2 - There is real production deployment >> 3 - There are multiple people in the WG who want to work >> on such a revision. >> 4 - The existing implementations (if any) are also willing >> to implement such a revision >> >> Without that, it seems that OBSOLETING is the best path forward. >> >> We (WG chairs) propose that the default path forward will be >> to obsolete RFC4743 and RFC4744. >> >> Anyone opposing that, please speak up asap but do so >> BEFORE December 15. >> >> And, if you do object, then please include answers to >> the 4 IFs above. >> >> Anyone in support of "obsoleting RFC4743 and RFC4744", >> please let us know by December 15 as well. It is good to >> also know that we have indeed WG consensus on this. >> >> The editors/authors of the documents have been (bbc) copied. >> >> Bert and Mehmet. >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From bertietf@bwijnen.net Wed Jan 11 00:35: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 9117821F86E1 for ; Wed, 11 Jan 2012 00:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 IEAyzO6FFr2W for ; Wed, 11 Jan 2012 00:35:44 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 642B821F86D0 for ; Wed, 11 Jan 2012 00:35:42 -0800 (PST) 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 1Rktek-0002pK-C0; Wed, 11 Jan 2012 09:35:39 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Rktej-0004qf-Qm; Wed, 11 Jan 2012 09:35:38 +0100 Message-ID: <4F0D49D9.3000907@bwijnen.net> Date: Wed, 11 Jan 2012 09:35:37 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tomoyuki Iijima References: <4F0AB370.8070404@bwijnen.net> <4F0B0AB9.7010409@bwijnen.net> <4F0CE365.7030309@hitachi.com> In-Reply-To: <4F0CE365.7030309@hitachi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4dfac38d912c06fd4da33215cec9cebaa Cc: netconf@ietf.org Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 08:35:45 -0000 Inline On 1/11/12 2:18 AM, Tomoyuki Iijima wrote: > Hi, > > > We do not think we can claim that we a good case > > and enough volunteers to actually do that work. > > So it seems we indeed better obsolete the two > > documents: > > > > RFC 4743 > > RFC 4744 > > Regarding RFC 4743, I was asked by chairs privately to answer following questions in the mailing list. For what it's worth, let me > answer here. > > - Your company(Hitachi)'s SOAP implementation and Alaxala's one are the same? > - Yes, that's correct. > So it is basically ONE implementation, not two. > - Do you have a plan to update current implementation? > - As of now, no, I'm just considering how to implement. As for future road map of commercial products, I can't say for sure (since > I'm not in a managerial position). > I guess you mean: you are considering how to implement the changes needed to support the netconf 1:1 functionality which would mean that netconf over SOAP needs to be updated. From that I then would conclude that you are willing to work on this. > Chairs, above are catching your intentions? > Yes. Hope my conclusions are also correct. Thanks for the public posting. Bert > Kind regards, > > Tomoyuki Iijima > > (2012/01/10 0:41), Bert Wijnen (IETF) wrote: >> Dear WG participants, >> >> We asked for input on this topic on Nov 21st (2011) and >> asked you to respond by Dec 15th (2011). See email below. >> >> Sofar, we have received responses/reports of: >> >> - ONE implementation of Netconf over BEEP >> - ONE implementation of Netconf over SOAP >> >> We have not yet heard any volunteering for updating >> the Netconf over Beep document. >> We have heard from 1 person who is willing to >> update the Netconf over SOAP document. >> >> The deadline was Dec 15th. >> >> We do not think we can claim that we a good case >> and enough volunteers to actually do that work. >> So it seems we indeed better obsolete the two >> documents: >> >> RFC 4743 >> RFC 4744 >> >> For that, we probably have to write a small document >> too. Who volunteers for that? >> >> Bert and Mehmet. >> >> On 11/21/11 3:10 PM, Bert Wijnen (IETF) wrote: >>> >>> Response requested from all WG participants by December 15th 2011. >>> >>> During our meeting at IETF82, the question was raised if >>> we should consider to obsolete (and make HISTORIC) 2 of >>> the NETCONF transport protocols: >>> >>> - RFC4743 - Netconf over SOAP >>> - RFC4744 - Netconf over BEEP >>> >>> It was noted, that they are currently at PS (Proposed Standard), >>> but that they have a normative reference to the obsoleted Netconf >>> Protocol (RFC4741). They cannot just depend on the new RFC6241 >>> without being updated to also support the :base:1.1 capability, >>> specifically: >>> >>> o Introduced a NETCONF username and a requirement for transport >>> protocols to explain how a username is derived. >>> >>> One option would be to do a revision of those 2 RFCs (similar >>> to the revision of RFC6242 (which obsoleted RFC4742) and >>> rfc5539-bis work. >>> >>> However, it seems that as a WG, we should ONLY consider that >>> option IF: >>> >>> 1 - There are multiple implementations >>> 2 - There is real production deployment >>> 3 - There are multiple people in the WG who want to work >>> on such a revision. >>> 4 - The existing implementations (if any) are also willing >>> to implement such a revision >>> >>> Without that, it seems that OBSOLETING is the best path forward. >>> >>> We (WG chairs) propose that the default path forward will be >>> to obsolete RFC4743 and RFC4744. >>> >>> Anyone opposing that, please speak up asap but do so >>> BEFORE December 15. >>> >>> And, if you do object, then please include answers to >>> the 4 IFs above. >>> >>> Anyone in support of "obsoleting RFC4743 and RFC4744", >>> please let us know by December 15 as well. It is good to >>> also know that we have indeed WG consensus on this. >>> >>> The editors/authors of the documents have been (bbc) copied. >>> >>> Bert and Mehmet. >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> . >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From lhotka@cesnet.cz Wed Jan 11 02:18: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 7F8D221F8845 for ; Wed, 11 Jan 2012 02:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX98tuVByKVe for ; Wed, 11 Jan 2012 02:18:44 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id C1BE221F883C for ; Wed, 11 Jan 2012 02:18:44 -0800 (PST) Received: from queeg.w2lan.cesnet.cz (queeg.w2lan.cesnet.cz [195.113.228.69]) by office2.cesnet.cz (Postfix) with ESMTPSA id 68CB62CDE057; Wed, 11 Jan 2012 11:18:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120102.214303.140235524.mbj@tail-f.com> Date: Wed, 11 Jan 2012 11:18:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:18:45 -0000 On Jan 2, 2012, at 9:43 PM, Martin Bjorklund wrote: > Hi, >=20 > Andy Bierman wrote: >> A server cannot really preserve the individual edits on candidate by = multiple >> writers, >> when applying the commit. The safe thing to do is determine which = nodes are >> really >> changing in the running config at commit time. >=20 > This is also described in the draft: >=20 > 3.2.6. Operation >=20 > The server MUST determine the exact nodes in the running > configuration datastore which are actually different, and only check > "create", "update", and "delete" access permissions for this set of > nodes, which could be empty. The cardinal question is what "different" means here. Is it (a) diff of candidate versus running, or (b) set of changes that the user made to candidate? I assume it must be (a), because candidate is copied to running at = commit. But then the following nasty conflict may easily happen: User A works on candidate and in the mean time somebody changes running = in a place to which A has no write permission. If user A were now = allowed to commit the candidate, the changes to running would be = reverted, which is not possible. So the commit must be denied even = though all changes A really made to candidate are fine.=20 Lada =20 >=20 >=20 >> Since the server has to derive edit operations based on the actual = differences >> between >> candidate and running, the NACM rules can be affected. >>=20 >> The granularity for NACM access is probably too fine. >> E.g, session A has full rights to /foo/* and creates a /foo list = entry in the >> candidate. >> Session B has only full access to the /foo/knob1 leaf, and it creates >> /foo/leaf1 >> in the candidate. At this point /foo does not exist in the running = config. >> Depending on the NACM rules and candidate contents, perhaps no = session has >> enough >> rights for a commit to succeed at this point. (We assume A can still = commit >> here ;-) >>=20 >> This /foo/leaf1 write access will not fail in NACM when the = is >> done >> because the implicit (or explicit) edit operation on /foo is 'none'. >> However, a commit attempt by session B must fail because it cannot = create the >> /foo node. >>=20 >> There are many corner cases one could construct where individual = edits to the >> candidate will be OK for a given group, but not the end result commit = request. >=20 > Yes, this has been discussed before. >=20 >> I don't think the NACM draft needs to change, but I suspect = multi-writer >> candidate >> commits will not be implemented correctly (like yuma right now ;-) >=20 >=20 >=20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Jan 11 02:24: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 AD81A21F870A for ; Wed, 11 Jan 2012 02:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=0.950, 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 z5YtKWIWLz5Z for ; Wed, 11 Jan 2012 02:24:16 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A86D521F864A for ; Wed, 11 Jan 2012 02:24:15 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BD73E1200050; Wed, 11 Jan 2012 11:24:14 +0100 (CET) Date: Wed, 11 Jan 2012 11:24:13 +0100 (CET) Message-Id: <20120111.112413.2230909040529245804.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:24:16 -0000 Ladislav Lhotka wrote: > > On Jan 2, 2012, at 9:43 PM, Martin Bjorklund wrote: > > > Hi, > > > > Andy Bierman wrote: > >> A server cannot really preserve the individual edits on candidate by > >> multiple > >> writers, > >> when applying the commit. The safe thing to do is determine which > >> nodes are > >> really > >> changing in the running config at commit time. > > > > This is also described in the draft: > > > > 3.2.6. Operation > > > > The server MUST determine the exact nodes in the running > > configuration datastore which are actually different, and only check > > "create", "update", and "delete" access permissions for this set of > > nodes, which could be empty. > > The cardinal question is what "different" means here. Is it > > (a) diff of candidate versus running, or > (b) set of changes that the user made to candidate? > > I assume it must be (a), because candidate is copied to running at > commit. Yes. I suppose this could be further clarified as: The server MUST determine the exact nodes in the running configuration datastore which are actually different compared with the candidate datastore, and check "create", "update", and "delete" access permissions for this set of nodes, which could be empty. > But then the following nasty conflict may easily happen: > > User A works on candidate and in the mean time somebody changes > running in a place to which A has no write permission. If user A were > now allowed to commit the candidate, the changes to running would be > reverted, which is not possible. So the commit must be denied even > though all changes A really made to candidate are fine. Yes, but only if :writable-running and :candidate is advertised at the same time, and I think we have agreed that this is a Bad Idea. /martin From bclaise@cisco.com Wed Jan 11 02:25: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 AC5B321F8783 for ; Wed, 11 Jan 2012 02:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 r9TrF5ENyc-8 for ; Wed, 11 Jan 2012 02:25:55 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9121F84DE for ; Wed, 11 Jan 2012 02:25:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0BAPps0026305; Wed, 11 Jan 2012 11:25:51 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0BAPpns016649; Wed, 11 Jan 2012 11:25:51 +0100 (CET) Message-ID: <4F0D63AF.6060201@cisco.com> Date: Wed, 11 Jan 2012 11:25:51 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4ECA2643.3060102@ripe.net> <4ECA5BCD.4040106@bwijnen.net> In-Reply-To: <4ECA5BCD.4040106@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Sunil Gudurvalmiki \(sunilgv\)" , netconf Subject: Re: [Netconf] Obsoleting Netconf over SOAP(RFC4743)/BEEP(RFC4744) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:25:55 -0000 Bert, [sorry for the delay in replying] In Cisco IOS, we have an implementation of NETCONF over BEEP, but we are in the process of deprecating that feature. Regards, Benoit. > > Response requested from all WG participants by December 15th 2011. > > During our meeting at IETF82, the question was raised if > we should consider to obsolete (and make HISTORIC) 2 of > the NETCONF transport protocols: > > - RFC4743 - Netconf over SOAP > - RFC4744 - Netconf over BEEP > > It was noted, that they are currently at PS (Proposed Standard), > but that they have a normative reference to the obsoleted Netconf > Protocol (RFC4741). They cannot just depend on the new RFC6241 > without being updated to also support the :base:1.1 capability, > specifically: > > o Introduced a NETCONF username and a requirement for transport > protocols to explain how a username is derived. > > One option would be to do a revision of those 2 RFCs (similar > to the revision of RFC6242 (which obsoleted RFC4742) and > rfc5539-bis work. > > However, it seems that as a WG, we should ONLY consider that > option IF: > > 1 - There are multiple implementations > 2 - There is real production deployment > 3 - There are multiple people in the WG who want to work > on such a revision. > 4 - The existing implementations (if any) are also willing > to implement such a revision > > Without that, it seems that OBSOLETING is the best path forward. > > We (WG chairs) propose that the default path forward will be > to obsolete RFC4743 and RFC4744. > > Anyone opposing that, please speak up asap but do so > BEFORE December 15. > > And, if you do object, then please include answers to > the 4 IFs above. > > Anyone in support of "obsoleting RFC4743 and RFC4744", > please let us know by December 15 as well. It is good to > also know that we have indeed WG consensus on this. > > The editors/authors of the documents have been (bbc) copied. > > Bert and Mehmet. > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From lhotka@cesnet.cz Wed Jan 11 02:27: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 4A55021F8858 for ; Wed, 11 Jan 2012 02:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjwKJ947Av8C for ; Wed, 11 Jan 2012 02:27:10 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id A5B3721F879F for ; Wed, 11 Jan 2012 02:27:10 -0800 (PST) Received: from queeg.w2lan.cesnet.cz (queeg.w2lan.cesnet.cz [195.113.228.69]) by office2.cesnet.cz (Postfix) with ESMTPSA id 03D682CDE04B; Wed, 11 Jan 2012 11:27:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <000e01cccffa$c788b2a0$6b01a8c0@oemcomputer> Date: Wed, 11 Jan 2012 11:27:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D48FA49-C51E-43EB-AD64-15CD488BCA97@cesnet.cz> References: <4F01F831.20703@netconfcentral.org><0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> <4F0C7A05.4000903@netconfcentral.org> <000e01cccffa$c788b2a0$6b01a8c0@oemcomputer> To: "Randy Presuhn" X-Mailer: Apple Mail (2.1251.1) Cc: NETCONF Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:27:11 -0000 On Jan 11, 2012, at 1:48 AM, Randy Presuhn wrote: > Hi - >=20 >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: "NETCONF" >> Sent: Tuesday, January 10, 2012 9:48 AM >> Subject: Re: [Netconf] NACM issue? > ... >> The candidate can deadlock, where no 1 user has enough rights to >> commit all the edits, and thus require some user to invoke = >> to clear the deadlock. > ... >=20 > Sounds like a recipe for a DoS attack, in which a relatively > unprivileged user could prevent another user from getting his/her > work done. Trivial example: A and B have rights to modify disjoint > subsets of information. Either can block the other indefinitely. This issue has been discussed some six months ago, with no resolution: http://www.ietf.org/mail-archive/web/netconf/current/msg07063.html I think a really robust solution would have to use per user candidate = which is actually regarded as a patchset - a sequence of edits. Lada >=20 > Randy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Jan 11 02:28: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 620EC21F8753 for ; Wed, 11 Jan 2012 02:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFb8oTx-qbcL for ; Wed, 11 Jan 2012 02:28:55 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id BE3FC21F84DE for ; Wed, 11 Jan 2012 02:28:55 -0800 (PST) Received: from queeg.w2lan.cesnet.cz (queeg.w2lan.cesnet.cz [195.113.228.69]) by office2.cesnet.cz (Postfix) with ESMTPSA id 191BA2CDE04B; Wed, 11 Jan 2012 11:28:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120111.112413.2230909040529245804.mbj@tail-f.com> Date: Wed, 11 Jan 2012 11:28:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A886F0B-3B6F-43CD-8CA6-879FB06863A2@cesnet.cz> References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:28:56 -0000 On Jan 11, 2012, at 11:24 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Jan 2, 2012, at 9:43 PM, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> Andy Bierman wrote: >>>> A server cannot really preserve the individual edits on candidate = by >>>> multiple >>>> writers, >>>> when applying the commit. The safe thing to do is determine which >>>> nodes are >>>> really >>>> changing in the running config at commit time. >>>=20 >>> This is also described in the draft: >>>=20 >>> 3.2.6. Operation >>>=20 >>> The server MUST determine the exact nodes in the running >>> configuration datastore which are actually different, and only = check >>> "create", "update", and "delete" access permissions for this set of >>> nodes, which could be empty. >>=20 >> The cardinal question is what "different" means here. Is it >>=20 >> (a) diff of candidate versus running, or >> (b) set of changes that the user made to candidate? >>=20 >> I assume it must be (a), because candidate is copied to running at >> commit. >=20 > Yes. I suppose this could be further clarified as: >=20 > The server MUST determine the exact nodes in the running > configuration datastore which are actually different compared with > the candidate datastore, and check "create", "update", and "delete" > access permissions for this set of nodes, which could be empty. >=20 >=20 >> But then the following nasty conflict may easily happen: >>=20 >> User A works on candidate and in the mean time somebody changes >> running in a place to which A has no write permission. If user A were >> now allowed to commit the candidate, the changes to running would be >> reverted, which is not possible. So the commit must be denied even >> though all changes A really made to candidate are fine. >=20 > Yes, but only if :writable-running and :candidate is advertised at the > same time, and I think we have agreed that this is a Bad Idea. Hmm, perhaps running can be changed outside NETCONF (e.g. via CLI). Then = you get the same problem. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.org Wed Jan 11 03:13: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 F165021F8675 for ; Wed, 11 Jan 2012 03:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 DXoKyL7gdNSU for ; Wed, 11 Jan 2012 03:13:27 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFE021F8526 for ; Wed, 11 Jan 2012 03:13:27 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0BBDNYq020632 for ; Wed, 11 Jan 2012 06:13:25 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:49695] helo=[192.168.0.126]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3D/1C-17660-3DE6D0F4; Wed, 11 Jan 2012 06:13:23 -0500 Message-ID: <4F0D6ED2.1010500@netconfcentral.org> Date: Wed, 11 Jan 2012 03:13:22 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F01F831.20703@netconfcentral.org><0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> <4F0C7A05.4000903@netconfcentral.org> <000e01cccffa$c788b2a0$6b01a8c0@oemcomputer> <4D48FA49-C51E-43EB-AD64-15CD488BCA97@cesnet.cz> In-Reply-To: <4D48FA49-C51E-43EB-AD64-15CD488BCA97@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 11:13:29 -0000 On 01/11/2012 02:27 AM, Ladislav Lhotka wrote: > > On Jan 11, 2012, at 1:48 AM, Randy Presuhn wrote: > >> Hi - >> >>> From: "Andy Bierman" >>> To: "Randy Presuhn" >>> Cc: "NETCONF" >>> Sent: Tuesday, January 10, 2012 9:48 AM >>> Subject: Re: [Netconf] NACM issue? >> ... >>> The candidate can deadlock, where no 1 user has enough rights to >>> commit all the edits, and thus require some user to invoke >>> to clear the deadlock. >> ... >> >> Sounds like a recipe for a DoS attack, in which a relatively >> unprivileged user could prevent another user from getting his/her >> work done. Trivial example: A and B have rights to modify disjoint >> subsets of information. Either can block the other indefinitely. > > This issue has been discussed some six months ago, with no resolution: > http://www.ietf.org/mail-archive/web/netconf/current/msg07063.html > > I think a really robust solution would have to use per user candidate which is actually regarded as a patchset - a sequence of edits. > If the client uses global locking, there is no problem. I am finding that locking is being used in application development. > Lada > >> >> Randy Andy From lhotka@cesnet.cz Wed Jan 11 03:31: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 4637221F879A for ; Wed, 11 Jan 2012 03:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iomqz9v0-JTr for ; Wed, 11 Jan 2012 03:31:24 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86C21F8799 for ; Wed, 11 Jan 2012 03:31:24 -0800 (PST) Received: from [IPv6:2001:718:1:6:cc0c:cbe0:61df:18c9] (unknown [IPv6:2001:718:1:6:cc0c:cbe0:61df:18c9]) by office2.cesnet.cz (Postfix) with ESMTPSA id 7A3662CDE05E; Wed, 11 Jan 2012 12:31:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F0D6ED2.1010500@netconfcentral.org> Date: Wed, 11 Jan 2012 12:31:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18C83821-D7E6-4E5A-8482-882A413CE6CA@cesnet.cz> References: <4F01F831.20703@netconfcentral.org><0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> <4F0C7A05.4000903@netconfcentral.org> <000e01cccffa$c788b2a0$6b01a8c0@oemcomputer> <4D48FA49-C51E-43EB-AD64-15CD488BCA97@cesnet.cz> <4F0D6ED2.1010500@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1251.1) Cc: NETCONF Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 11:31:25 -0000 On Jan 11, 2012, at 12:13 PM, Andy Bierman wrote: > On 01/11/2012 02:27 AM, Ladislav Lhotka wrote: >>=20 >> On Jan 11, 2012, at 1:48 AM, Randy Presuhn wrote: >>=20 >>> Hi - >>>=20 >>>> From: "Andy Bierman" >>>> To: "Randy Presuhn" >>>> Cc: "NETCONF" >>>> Sent: Tuesday, January 10, 2012 9:48 AM >>>> Subject: Re: [Netconf] NACM issue? >>> ... >>>> The candidate can deadlock, where no 1 user has enough rights to >>>> commit all the edits, and thus require some user to = invoke >>>> to clear the deadlock. >>> ... >>>=20 >>> Sounds like a recipe for a DoS attack, in which a relatively >>> unprivileged user could prevent another user from getting his/her >>> work done. Trivial example: A and B have rights to modify disjoint >>> subsets of information. Either can block the other indefinitely. >>=20 >> This issue has been discussed some six months ago, with no = resolution: >> http://www.ietf.org/mail-archive/web/netconf/current/msg07063.html >>=20 >> I think a really robust solution would have to use per user candidate = which is actually regarded as a patchset - a sequence of edits. >>=20 >=20 > If the client uses global locking, there is no problem. > I am finding that locking is being used in application development. I my scenario from the said old thread, the global lock would have to be = really looong-term which is not a good option either. Lada >=20 >> Lada >>=20 >>>=20 >>> Randy >=20 >=20 > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bwijnen@ripe.net Wed Jan 11 07:13: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 2FBA421F8577 for ; Wed, 11 Jan 2012 07:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WEIRD_PORT=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 RoFdx7OTi4SU for ; Wed, 11 Jan 2012 07:13:42 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9321F8530 for ; Wed, 11 Jan 2012 07:13:42 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Rkzrv-00060w-6I for netconf@ietf.org; Wed, 11 Jan 2012 16:13:40 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Rkzru-0005RG-MH for netconf@ietf.org; Wed, 11 Jan 2012 16:13:39 +0100 Message-ID: <4F0DA722.3040505@ripe.net> Date: Wed, 11 Jan 2012 16:13:38 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885edb96e42861026a866b5db5f7a207e729 Subject: [Netconf] Mantychore uses NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:13:43 -0000 WG participants, I had not heard about Mamtychore up till today when someone mentioned it to me. A very quick check shows that they are using NETCONF. See http://jira.i2cat.net:8090/display/MANTECH/System+Architecture towards the bottom where it describes "protocols used" and "workflow". Just so you are informed about this usage of NETCONF. Bert From iesg-secretary@ietf.org Wed Jan 11 08:54: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 2A79C21F86CE; Wed, 11 Jan 2012 08:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 NbCujIQ11MC1; Wed, 11 Jan 2012 08:54:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD2F21F86D0; Wed, 11 Jan 2012 08:54:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111165441.27888.37722.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 08:54:41 -0800 Cc: netconf mailing list , netconf chair , RFC Editor Subject: [Netconf] Protocol Action: 'Network Configuration Protocol (NETCONF) Access Control Model' to Proposed Standard (draft-ietf-netconf-access-control-07.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 16:54:42 -0000 The IESG has approved the following document: - 'Network Configuration Protocol (NETCONF) Access Control Model' (draft-ietf-netconf-access-control-07.txt) as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ Technical Summary The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. Working Group Summary There is strong consensus in the WG to publish this document. The document has been extensively discussed in the Working Group, including several WG Last Calls. The comments and reviews helped to improve the document a lot and the current version reflects the consensus of the Working Group. The Security ADs have also reviewed revision 5 of the document. The WG chairs specifically asked for a Detailed Security review, because the content of this document is all about access control and secure and properly authorized access to the NETCONF protocol and content. The last WGLC did raise only minor issues. The changes have been accepted by the WG. Document Quality Implementations of earlier drafts do (partially) exist and it is expected that NETCONF implementations will be extended once this document gets published as proposed standard. Personnel Bert Wijnen is the Document Shepherd for this document Dan Romascanu is the Responsible Area Director. From wjhns1@hardakers.net Wed Jan 11 09:27:40 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527C321F87FA for ; Wed, 11 Jan 2012 09:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU1v7PdCY1AZ for ; Wed, 11 Jan 2012 09:27:39 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4D121F87AE for ; Wed, 11 Jan 2012 09:27:39 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 31208488; Wed, 11 Jan 2012 09:27:36 -0800 (PST) From: Wes Hardaker To: Andy Bierman References: <4F01F831.20703@netconfcentral.org> <0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> Date: Wed, 11 Jan 2012 09:27:36 -0800 In-Reply-To: <4F0C5E89.90305@netconfcentral.org> (Andy Bierman's message of "Tue, 10 Jan 2012 07:51:37 -0800") Message-ID: <0lsjjmkv3r.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:27:40 -0000 >>>>> On Tue, 10 Jan 2012 07:51:37 -0800, Andy Bierman said: >> I think you've all heard my "global operations are dangerous" speech too >> many times, so I won't repeat it :-P One of these days I'll have the >> hours to write some drafts to fix my problems. AB> Good - write a draft I'd love to, but I don't have work funding to do it and my personal life is currently overburdened with volunteering to multiple public service organizations. >> T+0 NACM checks and verifies >> T+2 copy-config places the copy into running >> >> Obviously, the problem is: >> >> T+1 user B edits /foo/bar >> AB> I'm not following this example. AB> The server does not check candidate for NACM rules, just running. AB> Some internal caching of ACM details insures that the rules in affect AB> at the start of the message are used throughout the entire message. Well, it's really checking the changes right to ensure that the modification imposed by the copying was legal or not. There are multiple ways of implementing it. - You could copy first, then check, then revert (which would be bad for the fraction of a second it was in place). - You could check first and then copy, but then you need to make sure that nothing changes between the point it was checked and the point it was copied (in *either* storage place). That's really the example I was trying to state. - ... I'm sure there are others ... The problem is we don't give implementation advice, but when it comes to security features like ACM modules it's rather critical you get it right or bad things happen. But we don't document all the ways you could implement it poorly (with some good reason: it'd be an exhaustive list). -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Wed Jan 11 09:32: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 2131521F87DA for ; Wed, 11 Jan 2012 09:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfOegrJerhxN for ; Wed, 11 Jan 2012 09:32:47 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FC121F8751 for ; Wed, 11 Jan 2012 09:32:47 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 498B6426; Wed, 11 Jan 2012 09:32:45 -0800 (PST) From: Wes Hardaker To: Ladislav Lhotka References: <4F01F831.20703@netconfcentral.org> <0laa5v7hni.fsf@wjh.hardakers.net> <4F0C5E89.90305@netconfcentral.org> <003501cccfbb$de3bd980$6b01a8c0@oemcomputer> <4F0C7A05.4000903@netconfcentral.org> <000e01cccffa$c788b2a0$6b01a8c0@oemcomputer> <4D48FA49-C51E-43EB-AD64-15CD488BCA97@cesnet.cz> Date: Wed, 11 Jan 2012 09:32:45 -0800 In-Reply-To: <4D48FA49-C51E-43EB-AD64-15CD488BCA97@cesnet.cz> (Ladislav Lhotka's message of "Wed, 11 Jan 2012 11:27:08 +0100") Message-ID: <0lobuakuv6.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:32:48 -0000 >>>>> On Wed, 11 Jan 2012 11:27:08 +0100, Ladislav Lhotka said: LL> This issue has been discussed some six months ago, with no resolution: LL> http://www.ietf.org/mail-archive/web/netconf/current/msg07063.html Actually, we discussed it two San Diego's ago (my new favorite unit of time measurement) I think and it was decided you had to use locks. And that it was ok that the protocol didn't really support simultaneous edits by multiple people very well, as that wasn't an important goal as it's not used in 95% of deployments. -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Wed Jan 11 09:36: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 56A4321F8841 for ; Wed, 11 Jan 2012 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gQZx6OCAGEC for ; Wed, 11 Jan 2012 09:36:11 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id C342221F883E for ; Wed, 11 Jan 2012 09:36:10 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 92C68426; Wed, 11 Jan 2012 09:36:09 -0800 (PST) From: Wes Hardaker To: Martin Bjorklund References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> Date: Wed, 11 Jan 2012 09:36:09 -0800 In-Reply-To: <20120111.112413.2230909040529245804.mbj@tail-f.com> (Martin Bjorklund's message of "Wed, 11 Jan 2012 11:24:13 +0100 (CET)") Message-ID: <0lhb02kupi.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:36:11 -0000 >>>>> On Wed, 11 Jan 2012 11:24:13 +0100 (CET), Martin Bjorklund said: MB> Yes, but only if :writable-running and :candidate is advertised at the MB> same time, and I think we have agreed that this is a Bad Idea. Or :writable-running and copy from URL. Or :candidate and copy from URL with two people editing 2 different copies and trying to copy them in from different locations. -- Wes Hardaker SPARTA, Inc. From bertietf@bwijnen.net Wed Jan 11 09:56: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 18FC921F87B9 for ; Wed, 11 Jan 2012 09:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.758 X-Spam-Level: X-Spam-Status: No, score=-99.758 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGQUs+e+PnNs for ; Wed, 11 Jan 2012 09:56:55 -0800 (PST) Received: from relay54.tele2.vuurwerk.nl (relay54.tele2.vuurwerk.nl [62.250.3.54]) by ietfa.amsl.com (Postfix) with ESMTP id 599C421F86D1 for ; Wed, 11 Jan 2012 09:56:55 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1Rl2Pt-0006nu-Rz for netconf@ietf.org; Wed, 11 Jan 2012 18:56:54 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 11 Jan 2012 18:56:40 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [Netconf] Fw: Protocol Action: 'Network Configuration Protocol (NETCONF) AccessControl Model' to Proposed Standard(draft-ietf-netconf-access-control-07.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:56:56 -0000 Congrats to this WG for this achievement. Special thanks to the Editors Andy Bierman and Martin Bjorklund for their many many efforts to get this in good shape so it could be approved. Bert ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: "netconf mailing list" ; "netconf chair" ; "RFC Editor" Sent: Wednesday, January 11, 2012 5:54 PM Subject: Protocol Action: 'Network Configuration Protocol (NETCONF) AccessControl Model' to Proposed Standard(draft-ietf-netconf-access-control-07.txt) > The IESG has approved the following document: > - 'Network Configuration Protocol (NETCONF) Access Control Model' > (draft-ietf-netconf-access-control-07.txt) as a Proposed Standard > > This document is the product of the Network Configuration Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ > > > > > Technical Summary > > The standardization of network configuration interfaces for use with > the NETCONF protocol requires a structured and secure operating > environment that promotes human usability and multi-vendor > interoperability. There is a need for standard mechanisms to > restrict NETCONF protocol access for particular users to a pre- > configured subset of all available NETCONF protocol operations and > content. This document defines such an access control model. > > Working Group Summary > > There is strong consensus in the WG to publish this document. > The document has been extensively discussed in the Working Group, > including several WG Last Calls. The comments and reviews helped > to improve the document a lot and the current version reflects the > consensus of the Working Group. > The Security ADs have also reviewed revision 5 of the document. > The WG chairs specifically asked for a Detailed Security review, because > the content of this document is all about access control and > secure and properly authorized access to the NETCONF protocol and > content. The last WGLC did raise only minor issues. The changes > have been accepted by the WG. > > Document Quality > > Implementations of earlier drafts do (partially) exist and it > is expected that NETCONF implementations will be extended once > this document gets published as proposed standard. > > Personnel > > Bert Wijnen is the Document Shepherd for this document > Dan Romascanu is the Responsible Area Director. > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From andy@netconfcentral.org Wed Jan 11 10:07:59 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 9F62C21F86D6 for ; Wed, 11 Jan 2012 10:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 3a1i+pRmbene for ; Wed, 11 Jan 2012 10:07:59 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01721F865D for ; Wed, 11 Jan 2012 10:07:58 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0BI7tQa030664 for ; Wed, 11 Jan 2012 13:07:57 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:60634] helo=[192.168.0.126]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id FB/E1-24407-AFFCD0F4; Wed, 11 Jan 2012 13:07:55 -0500 Message-ID: <4F0DCFFA.7050706@netconfcentral.org> Date: Wed, 11 Jan 2012 10:07:54 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Wes Hardaker References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> <0lhb02kupi.fsf@wjh.hardakers.net> In-Reply-To: <0lhb02kupi.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:07:59 -0000 On 01/11/2012 09:36 AM, Wes Hardaker wrote: >>>>>> On Wed, 11 Jan 2012 11:24:13 +0100 (CET), Martin Bjorklund said: > > MB> Yes, but only if :writable-running and :candidate is advertised at the > MB> same time, and I think we have agreed that this is a Bad Idea. > > Or :writable-running and copy from URL. > > Or :candidate and copy from URL with two people editing 2 different > copies and trying to copy them in from different locations. RFC 6241, sec 8.3.1, para 3: The candidate configuration can be shared among multiple sessions. Unless a client has specific information that the candidate configuration is not shared, it MUST assume that other sessions are able to modify the candidate configuration at the same time. It is therefore prudent for a client to lock the candidate configuration before modifying it. I admit the RFC does not scream USE LOCKS! as much as it should, but this problem existed with multiple CLI sessions way before NETCONF came around, and operators don't seem to care. Andy From wjhns1@hardakers.net Wed Jan 11 10:13:59 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 2BDFD21F87D0 for ; Wed, 11 Jan 2012 10:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDaKPtSWbV13 for ; Wed, 11 Jan 2012 10:13:58 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9120821F858D for ; Wed, 11 Jan 2012 10:13:58 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id B1603A2; Wed, 11 Jan 2012 10:13:57 -0800 (PST) From: Wes Hardaker To: Andy Bierman References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> <0lhb02kupi.fsf@wjh.hardakers.net> <4F0DCFFA.7050706@netconfcentral.org> Date: Wed, 11 Jan 2012 10:13:57 -0800 In-Reply-To: <4F0DCFFA.7050706@netconfcentral.org> (Andy Bierman's message of "Wed, 11 Jan 2012 10:07:54 -0800") Message-ID: <0lk44yjee2.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:13:59 -0000 >>>>> On Wed, 11 Jan 2012 10:07:54 -0800, Andy Bierman said: AB> The candidate configuration can be shared among multiple sessions. AB> Unless a client has specific information that the candidate AB> configuration is not shared, it MUST assume that other sessions are AB> able to modify the candidate configuration at the same time. It is AB> therefore prudent for a client to lock the candidate configuration AB> before modifying it. AB> I admit the RFC does not scream USE LOCKS! as much as it should, AB> but this problem existed with multiple CLI sessions way before AB> NETCONF came around, and operators don't seem to care. It's not just that, though. Both candidate and running must be locked to prevent problems. Only locking one won't fully protect you. -- Wes Hardaker SPARTA, Inc. From andy@netconfcentral.org Wed Jan 11 10:19: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 B86F321F8680 for ; Wed, 11 Jan 2012 10:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 B9WVLafTcMCH for ; Wed, 11 Jan 2012 10:19:49 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id E8B6621F8667 for ; Wed, 11 Jan 2012 10:19:48 -0800 (PST) Received: from cm-omr3 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q0BIJlgk031893 for ; Wed, 11 Jan 2012 13:19:47 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:35187] helo=[192.168.0.126]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C9/B5-24407-3C2DD0F4; Wed, 11 Jan 2012 13:19:47 -0500 Message-ID: <4F0DD2BF.3090703@netconfcentral.org> Date: Wed, 11 Jan 2012 10:19:43 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Wes Hardaker References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> <0lhb02kupi.fsf@wjh.hardakers.net> In-Reply-To: <0lhb02kupi.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:19:49 -0000 On 01/11/2012 09:36 AM, Wes Hardaker wrote: >>>>>> On Wed, 11 Jan 2012 11:24:13 +0100 (CET), Martin Bjorklund said: > > MB> Yes, but only if :writable-running and :candidate is advertised at the > MB> same time, and I think we have agreed that this is a Bad Idea. > > Or :writable-running and copy from URL. > > Or :candidate and copy from URL with two people editing 2 different > copies and trying to copy them in from different locations. Also from RFC 6241: 4.5. Pipelining NETCONF requests MUST be processed serially by the managed device. Additional requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received. Your comments seem to assume that edits from different requests can be applied concurrently in the server. (Maybe some servers, but yuma is not that clever, so N is completed before N+1 is started). IMO, the text above implies that internal edits will be serialized, not just processing, so even multi-threaded servers need to preserve the order of edits. Andy From lhotka@cesnet.cz Wed Jan 11 10:28: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 31D7611E80AC for ; Wed, 11 Jan 2012 10:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgCK5v+CruAn for ; Wed, 11 Jan 2012 10:28:34 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 9236811E80AA for ; Wed, 11 Jan 2012 10:28:34 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 1CE002CDE058 for ; Wed, 11 Jan 2012 19:28:33 +0100 (CET) Message-ID: <4F0DD4D0.9020905@cesnet.cz> Date: Wed, 11 Jan 2012 19:28:32 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: netconf@ietf.org References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> <0lhb02kupi.fsf@wjh.hardakers.net> <4F0DCFFA.7050706@netconfcentral.org> In-Reply-To: <4F0DCFFA.7050706@netconfcentral.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:28:35 -0000 Dne 11.1.2012 19:07, Andy Bierman napsal(a): > On 01/11/2012 09:36 AM, Wes Hardaker wrote: >>>>>>> On Wed, 11 Jan 2012 11:24:13 +0100 (CET), Martin >>>>>>> Bjorklund said: >> >> MB> Yes, but only if :writable-running and :candidate is advertised at >> the >> MB> same time, and I think we have agreed that this is a Bad Idea. >> >> Or :writable-running and copy from URL. >> >> Or :candidate and copy from URL with two people editing 2 different >> copies and trying to copy them in from different locations. > > RFC 6241, sec 8.3.1, para 3: > > The candidate configuration can be shared among multiple sessions. > Unless a client has specific information that the candidate > configuration is not shared, it MUST assume that other sessions are > able to modify the candidate configuration at the same time. It is > therefore prudent for a client to lock the candidate configuration > before modifying it. In fact, a client shouldn't release the lock before *commiting*, which can be much more annoying. > > I admit the RFC does not scream USE LOCKS! as much as it should, > but this problem existed with multiple CLI sessions way before > NETCONF came around, and operators don't seem to care. The fine-grained permissions of NACM make this problem worse. Lada > > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Wed Jan 11 10:52: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 4C02111E807A for ; Wed, 11 Jan 2012 10:52:10 -0800 (PST) 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 1jDBZm3c6Dx5 for ; Wed, 11 Jan 2012 10:52:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36F11E8073 for ; Wed, 11 Jan 2012 10:52:09 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0BIq79T025288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 19:52:07 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0BIq59X031173; Wed, 11 Jan 2012 19:52:07 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 19:52:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 19:52:04 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640341E995@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Fw: Protocol Action: 'Network Configuration Protocol(NETCONF) AccessControl Model' to ProposedStandard(draft-ietf-netconf-access-control-07.txt) Thread-Index: AczQimxSpp0sargrSMaWXmlqZMTr4QABxCdg References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , "Netconf" X-OriginalArrivalTime: 11 Jan 2012 18:52:05.0859 (UTC) FILETIME=[1D148B30:01CCD092] Subject: Re: [Netconf] Fw: Protocol Action: 'Network Configuration Protocol(NETCONF) AccessControl Model' to ProposedStandard(draft-ietf-netconf-access-control-07.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:52:10 -0000 Same here for this huge step forward to get NETCONF better and useful. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Bert Wijnen (IETF) > Sent: Wednesday, January 11, 2012 6:57 PM > To: Netconf > Subject: [Netconf] Fw: Protocol Action: 'Network Configuration Protocol(NETCONF) > AccessControl Model' to ProposedStandard(draft-ietf-netconf-access-control-07.txt) >=20 > Congrats to this WG for this achievement. >=20 > Special thanks to the Editors Andy Bierman > and Martin Bjorklund for their many many > efforts to get this in good shape so it could > be approved. >=20 > Bert >=20 > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: "netconf mailing list" ; "netconf chair" > ; "RFC Editor" > Sent: Wednesday, January 11, 2012 5:54 PM > Subject: Protocol Action: 'Network Configuration Protocol (NETCONF) > AccessControl Model' to Proposed > Standard(draft-ietf-netconf-access-control-07.txt) >=20 >=20 > > The IESG has approved the following document: > > - 'Network Configuration Protocol (NETCONF) Access Control Model' > > (draft-ietf-netconf-access-control-07.txt) as a Proposed Standard > > > > This document is the product of the Network Configuration Working Group. > > > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > > > A URL of this Internet Draft is: > > http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ > > > > > > > > > > Technical Summary > > > > The standardization of network configuration interfaces for use with > > the NETCONF protocol requires a structured and secure operating > > environment that promotes human usability and multi-vendor > > interoperability. There is a need for standard mechanisms to > > restrict NETCONF protocol access for particular users to a pre- > > configured subset of all available NETCONF protocol operations and > > content. This document defines such an access control model. > > > > Working Group Summary > > > > There is strong consensus in the WG to publish this document. > > The document has been extensively discussed in the Working Group, > > including several WG Last Calls. The comments and reviews helped > > to improve the document a lot and the current version reflects the > > consensus of the Working Group. > > The Security ADs have also reviewed revision 5 of the document. > > The WG chairs specifically asked for a Detailed Security review, because > > the content of this document is all about access control and > > secure and properly authorized access to the NETCONF protocol and > > content. The last WGLC did raise only minor issues. The changes > > have been accepted by the WG. > > > > Document Quality > > > > Implementations of earlier drafts do (partially) exist and it > > is expected that NETCONF implementations will be extended once > > this document gets published as proposed standard. > > > > Personnel > > > > Bert Wijnen is the Document Shepherd for this document > > Dan Romascanu is the Responsible Area Director. > > > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From wjhns1@hardakers.net Wed Jan 11 12:16:41 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 D123711E80AB for ; Wed, 11 Jan 2012 12:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTJwKxrDxPqa for ; Wed, 11 Jan 2012 12:16:40 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id A38EF11E808C for ; Wed, 11 Jan 2012 12:16:40 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id C711219C; Wed, 11 Jan 2012 12:16:38 -0800 (PST) From: Wes Hardaker To: Andy Bierman References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> <0lhb02kupi.fsf@wjh.hardakers.net> <4F0DD2BF.3090703@netconfcentral.org> Date: Wed, 11 Jan 2012 12:16:38 -0800 In-Reply-To: <4F0DD2BF.3090703@netconfcentral.org> (Andy Bierman's message of "Wed, 11 Jan 2012 10:19:43 -0800") Message-ID: <0l39bmj8pl.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:16:41 -0000 >>>>> On Wed, 11 Jan 2012 10:19:43 -0800, Andy Bierman said: AB> 4.5. Pipelining AB> NETCONF requests MUST be processed serially by the managed AB> device. Additional requests MAY be sent before previous ones AB> have been completed. The managed device MUST send responses only in AB> the order the requests were received. AB> Your comments seem to assume that edits from different AB> requests can be applied concurrently in the server. (Maybe some AB> servers, but yuma is not that clever, so N is completed before AB> N+1 is started). I had forgotten about that clause, so thanks for reminding me of it. My visions are sometimes more grandiose toward the future, when every machine has multiple cores, multiple threads and multiple servers because the configuration space is simply that big. We learned in the SNMP world that forced pipe-lining was a bad thing for data retrieval requests (IE, GETs) because it blocked multiple managers querying the agent at the same time when some queries were long in executing. One of the most annoying things of SNMP, and now with netconf, was that there wasn't a way to state that two different data sets are independent and are allowed to be acted on simultaneously. For config, it's probably not as much of a problem since it really should be a copy and should be instantaneous. Oh wait, unless you need to restart process X because the config changed. Oh wait, and you need to unload a kernel module because the config changed, etc. As configuration grows (which it never seems to stop doing), the whole system will continue to explode into huge numbers of things that can be twiddled. Which means without paralyzing some stuff, the single configuration engine will become the bottleneck. But you're right, the above rule does prohibit some of the issues I'm worrying about and my other grandiose problems won't be seen for a while yet :-) -- Wes Hardaker SPARTA, Inc. From dromasca@avaya.com Thu Jan 12 02:44: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 7307B21F85A7 for ; Thu, 12 Jan 2012 02:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.168, 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 GQa2jFSWV+Gj for ; Thu, 12 Jan 2012 02:44:34 -0800 (PST) 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 9968221F85A3 for ; Thu, 12 Jan 2012 02:44:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKW4Dk/GmAcF/2dsb2JhbABDrQaBBYFyAQEBAQMBAQEPHgo0FwQCAQgNBAQBAQsGDAcEAQYBJh8JCAEBBAESCBqHYJwymymCVYhlYwSaf4xL X-IronPort-AV: E=Sophos;i="4.71,497,1320642000"; d="scan'208";a="226383541" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Jan 2012 05:44:33 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Jan 2012 05:40:08 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2012 11:44:30 +0100 Message-ID: In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640341E995@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Fw: Protocol Action: 'Network ConfigurationProtocol(NETCONF) AccessControl Model' toProposedStandard(draft-ietf-netconf-access-control-07.txt) Thread-Index: AczQimxSpp0sargrSMaWXmlqZMTr4QABxCdgACFnB/A= References: <80A0822C5E9A4440A5117C2F4CD36A640341E995@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext Bert Wijnen (IETF)" , "Netconf" Subject: Re: [Netconf] Fw: Protocol Action: 'Network ConfigurationProtocol(NETCONF) AccessControl Model' toProposedStandard(draft-ietf-netconf-access-control-07.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:44:35 -0000 Thanks and congratulations to the editors, chairs and the whole WG! Dan > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Ersue, Mehmet (NSN - DE/Munich) > Sent: Wednesday, January 11, 2012 8:52 PM > To: ext Bert Wijnen (IETF); Netconf > Subject: Re: [Netconf] Fw: Protocol Action: 'Network > ConfigurationProtocol(NETCONF) AccessControl Model' > toProposedStandard(draft-ietf-netconf-access-control-07.txt) >=20 > Same here for this huge step forward to get NETCONF better and useful. >=20 > Cheers, > Mehmet >=20 >=20 > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext > > Bert Wijnen (IETF) > > Sent: Wednesday, January 11, 2012 6:57 PM > > To: Netconf > > Subject: [Netconf] Fw: Protocol Action: 'Network Configuration > Protocol(NETCONF) > > AccessControl Model' to > ProposedStandard(draft-ietf-netconf-access-control-07.txt) > > > > Congrats to this WG for this achievement. > > > > Special thanks to the Editors Andy Bierman > > and Martin Bjorklund for their many many > > efforts to get this in good shape so it could > > be approved. > > > > Bert > > > > ----- Original Message ----- > > From: "The IESG" > > To: "IETF-Announce" > > Cc: "netconf mailing list" ; "netconf chair" > > ; "RFC Editor" > > > Sent: Wednesday, January 11, 2012 5:54 PM > > Subject: Protocol Action: 'Network Configuration Protocol (NETCONF) > > AccessControl Model' to Proposed > > Standard(draft-ietf-netconf-access-control-07.txt) > > > > > > > The IESG has approved the following document: > > > - 'Network Configuration Protocol (NETCONF) Access Control Model' > > > (draft-ietf-netconf-access-control-07.txt) as a Proposed Standard > > > > > > This document is the product of the Network Configuration Working > Group. > > > > > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > > > > > A URL of this Internet Draft is: > > > http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ > > > > > > > > > > > > > > > Technical Summary > > > > > > The standardization of network configuration interfaces for use > with > > > the NETCONF protocol requires a structured and secure operating > > > environment that promotes human usability and multi-vendor > > > interoperability. There is a need for standard mechanisms to > > > restrict NETCONF protocol access for particular users to a pre- > > > configured subset of all available NETCONF protocol operations > and > > > content. This document defines such an access control model. > > > > > > Working Group Summary > > > > > > There is strong consensus in the WG to publish this document. > > > The document has been extensively discussed in the Working Group, > > > including several WG Last Calls. The comments and reviews > helped > > > to improve the document a lot and the current version reflects > the > > > consensus of the Working Group. > > > The Security ADs have also reviewed revision 5 of the document. > > > The WG chairs specifically asked for a Detailed Security review, > because > > > the content of this document is all about access control and > > > secure and properly authorized access to the NETCONF protocol > and > > > content. The last WGLC did raise only minor issues. The > changes > > > have been accepted by the WG. > > > > > > Document Quality > > > > > > Implementations of earlier drafts do (partially) exist and it > > > is expected that NETCONF implementations will be extended once > > > this document gets published as proposed standard. > > > > > > Personnel > > > > > > Bert Wijnen is the Document Shepherd for this document > > > Dan Romascanu is the Responsible Area Director. > > > > > > > > > > > > _______________________________________________ > > > IETF-Announce mailing list > > > IETF-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@netconfcentral.org Thu Jan 12 09:23: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 8795021F85A2 for ; Thu, 12 Jan 2012 09:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 yByBbf5Swa3Q for ; Thu, 12 Jan 2012 09:23:51 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id CF28821F859A for ; Thu, 12 Jan 2012 09:23:50 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0CHNlg3002300 for ; Thu, 12 Jan 2012 12:23:47 -0500 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43858] helo=[192.168.0.126]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id DF/AC-28181-2271F0F4; Thu, 12 Jan 2012 12:23:47 -0500 Message-ID: <4F0F1722.5030409@netconfcentral.org> Date: Thu, 12 Jan 2012 09:23:46 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Wes Hardaker References: <4F01F831.20703@netconfcentral.org> <20120102.214303.140235524.mbj@tail-f.com> <89869801-3319-493C-8826-764FDD5DE62B@cesnet.cz> <20120111.112413.2230909040529245804.mbj@tail-f.com> <0lhb02kupi.fsf@wjh.hardakers.net> <4F0DD2BF.3090703@netconfcentral.org> <0l39bmj8pl.fsf@wjh.hardakers.net> In-Reply-To: <0l39bmj8pl.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? 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, 12 Jan 2012 17:23:51 -0000 On 01/11/2012 12:16 PM, Wes Hardaker wrote: >>>>>> On Wed, 11 Jan 2012 10:19:43 -0800, Andy Bierman said: > > AB> 4.5. Pipelining > > AB> NETCONF requests MUST be processed serially by the managed > AB> device. Additional requests MAY be sent before previous ones > AB> have been completed. The managed device MUST send responses only in > AB> the order the requests were received. > > AB> Your comments seem to assume that edits from different > AB> requests can be applied concurrently in the server. (Maybe some > AB> servers, but yuma is not that clever, so N is completed before > AB> N+1 is started). > > I had forgotten about that clause, so thanks for reminding me of it. > > My visions are sometimes more grandiose toward the future, when every > machine has multiple cores, multiple threads and multiple servers > because the configuration space is simply that big. > That doesn't mean the monolithic CLI management model will remain in place. I think the trend towards 'private candidates' or even virtual servers will solve this problem. > We learned in the SNMP world that forced pipe-lining was a bad thing for > data retrieval requests (IE, GETs) because it blocked multiple managers > querying the agent at the same time when some queries were long in > executing. I agree this is a useful feature, not specific to SNMP. > One of the most annoying things of SNMP, and now with netconf, was that > there wasn't a way to state that two different data sets are independent > and are allowed to be acted on simultaneously. For config, it's > probably not as much of a problem since it really should be a copy and > should be instantaneous. Oh wait, unless you need to restart process X > because the config changed. Oh wait, and you need to unload a kernel > module because the config changed, etc. As configuration grows (which > it never seems to stop doing), the whole system will continue to explode > into huge numbers of things that can be twiddled. Which means without > paralyzing some stuff, the single configuration engine will become the > bottleneck. But you're right, the above rule does prohibit some of the > issues I'm worrying about and my other grandiose problems won't be seen > for a while yet :-) I agree that the NETCONF/YANG configuration model is still incomplete. But the ad-hoc nature of NM features is the fault of the vendors, not the standards. If a product requires several manual steps, like restart a process, reboot the device, set 5 knobs in some exact order, then the inherent complexity of the overall system will be huge (like what we see now with routers ;-) Developers (and their managers) don't seem to understand that their random acts of 'schedule beating' design choices have a huge impact on the usability of the software. The reason NM is still in the Stone Ages has nothing to do with SNMP vs. NETCONF vs. CLI, or ASN.1/BER vs. XML .vs. JSON, and everything to do with the ad-hoc, poorly documented 'recipes' needed to cook up any particular networking feature. (There's some hope REST will solve this.) Andy From phil@juniper.net Thu Jan 12 11:22:59 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 BF53921F8678 for ; Thu, 12 Jan 2012 11:22:59 -0800 (PST) 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 8jcQOmLdGnJ0 for ; Thu, 12 Jan 2012 11:22:59 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53621F8675 for ; Thu, 12 Jan 2012 11:22:55 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTw8zDM1LSX/5T0hod8pP69bq9PIWC6T5@postini.com; Thu, 12 Jan 2012 11:22:58 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 12 Jan 2012 11:21:08 -0800 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 q0CJL6S01503; Thu, 12 Jan 2012 11:21:07 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0CIpZcF052857; Thu, 12 Jan 2012 18:51:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201121851.q0CIpZcF052857@idle.juniper.net> To: Wes Hardaker In-Reply-To: <0l39bmj8pl.fsf@wjh.hardakers.net> Date: Thu, 12 Jan 2012 13:51:35 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? 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, 12 Jan 2012 19:22:59 -0000 Wes Hardaker writes: >We learned in the SNMP world that forced pipe-lining was a bad thing for >data retrieval requests (IE, GETs) because it blocked multiple managers >querying the agent at the same time when some queries were long in >executing. IIRC nothing in NETCONF prevents multiple simultaneous queries. Simultaneous locks/changes, yes, not queries. In the CLI world, we learned if you don't apply changes in distinct change-sets (ala commit), then simple operations like "backup/restore" become obnoxiously difficult (since you can't know if what you archived was a complete configuration). We also learned that forcing operations to be performed in certain orders makes simple operations (like changing a filter) into complex ones (since it might require the filter to be built multiple times). Using a candidate config increases the chances of accurate config changes while decreasing the amount of work required to make them. I think these lessons carry over directly into the APIs, where one wants to make a particular operation (add a service) and wants to know the service is added correctly, works correctly, and can be undone if it does not. Accuracy and simplicity win over multiple writers. >One of the most annoying things of SNMP, and now with netconf, was that >there wasn't a way to state that two different data sets are independent >and are allowed to be acted on simultaneously. If the data sets are truly independent, consider distinct datastores. One area we haven't explored is "learned pseudo configuration", where one considered "configuration data" is taken to be permanent, but "learned data" is some of the same knobs, but learned from services that don't wish them to be permanent. Consider subscriber management as the best example. When the subscriber is present, some external app wants to tell us how their port should be configured, but they don't want it to be real configuration data. In JUNOS, we do this via a second datastore (called the dynamic database). It's never saved/restored, and one only looks at it when debugging the subscriber management app. Food for thought.... Thanks, Phil (who is only lurking here these days) From mbj@tail-f.com Thu Jan 12 12:50: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 6EC9A11E8095 for ; Thu, 12 Jan 2012 12:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 xPL-Bt5m+YL7 for ; Thu, 12 Jan 2012 12:50:55 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BF93621F861A for ; Thu, 12 Jan 2012 12:50:54 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D29281200052; Thu, 12 Jan 2012 21:50:52 +0100 (CET) Date: Thu, 12 Jan 2012 21:50:51 +0100 (CET) Message-Id: <20120112.215051.146941877.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201201121851.q0CIpZcF052857@idle.juniper.net> References: <0l39bmj8pl.fsf@wjh.hardakers.net> <201201121851.q0CIpZcF052857@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? 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, 12 Jan 2012 20:50:55 -0000 Phil Shafer wrote: > Wes Hardaker writes: > >We learned in the SNMP world that forced pipe-lining was a bad thing for > >data retrieval requests (IE, GETs) because it blocked multiple managers > >querying the agent at the same time when some queries were long in > >executing. > > IIRC nothing in NETCONF prevents multiple simultaneous queries. Correct. > Simultaneous locks/changes, yes, not queries. The standard doesn't prevent simultaneous changes either, only simultaneous global locks (obviously...). With partial locks, you can have multiple (protected) simultaneous writers as well. (Yes I know partial locks only works with running, and some sort of private candidates are needed...) /martin From j.schoenwaelder@jacobs-university.de Thu Jan 12 23:25: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 452B221F84DC for ; Thu, 12 Jan 2012 23:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 jGwnzwIolP0u for ; Thu, 12 Jan 2012 23:25:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7127F21F84D9 for ; Thu, 12 Jan 2012 23:25:24 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9642E20BD8; Fri, 13 Jan 2012 08:25:23 +0100 (CET) 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 9QCdH-XngL6T; Fri, 13 Jan 2012 08:25:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3259220BCD; Fri, 13 Jan 2012 08:25:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C0091C81E08; Fri, 13 Jan 2012 08:25:05 +0100 (CET) Date: Fri, 13 Jan 2012 08:25:05 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20120113072505.GB97667@elstar.local> Mail-Followup-To: Phil Shafer , Wes Hardaker , netconf@ietf.org References: <0l39bmj8pl.fsf@wjh.hardakers.net> <201201121851.q0CIpZcF052857@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201121851.q0CIpZcF052857@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 07:25:25 -0000 On Thu, Jan 12, 2012 at 01:51:35PM -0500, Phil Shafer wrote: > One area we haven't explored is "learned pseudo configuration", > where one considered "configuration data" is taken to be permanent, > but "learned data" is some of the same knobs, but learned from > services that don't wish them to be permanent. > > Consider subscriber management as the best example. When the > subscriber is present, some external app wants to tell us how their > port should be configured, but they don't want it to be real > configuration data. In JUNOS, we do this via a second datastore > (called the dynamic database). It's never saved/restored, and one > only looks at it when debugging the subscriber management app. The lack of support to handle this kind of operational (config) state is well known. Are we getting ready to finally do something about it? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Fri Jan 13 09:24: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 DB3AF21F852B for ; Fri, 13 Jan 2012 09:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgZ4j9FeK+xW for ; Fri, 13 Jan 2012 09:24:32 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7405121F8522 for ; Fri, 13 Jan 2012 09:24:32 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 15CF0790; Fri, 13 Jan 2012 09:24:30 -0800 (PST) From: Wes Hardaker To: Phil Shafer References: <201201121851.q0CIpZcF052857@idle.juniper.net> Date: Fri, 13 Jan 2012 09:24:30 -0800 In-Reply-To: <201201121851.q0CIpZcF052857@idle.juniper.net> (Phil Shafer's message of "Thu, 12 Jan 2012 13:51:35 -0500") Message-ID: <0lk44v348h.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? 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, 13 Jan 2012 17:24:33 -0000 >>>>> On Thu, 12 Jan 2012 13:51:35 -0500, Phil Shafer said: PS> If the data sets are truly independent, consider distinct datastores. Yes, but netconf doesn't really push that concept well. You'd need separate ports (or at least ssh service names) for each datastore for each back-end independent config. That's not ideal. Netconf has re-implemented the windows registry when operators really just want a set of editable /etc files wrapped with 'git push' into it. -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Fri Jan 13 09:25: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 1534621F8559 for ; Fri, 13 Jan 2012 09:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up9su2oFwiUu for ; Fri, 13 Jan 2012 09:25:56 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3913921F8551 for ; Fri, 13 Jan 2012 09:25:48 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 97AD03DE; Fri, 13 Jan 2012 09:25:47 -0800 (PST) From: Wes Hardaker To: Wes Hardaker References: <201201121851.q0CIpZcF052857@idle.juniper.net> <0lk44v348h.fsf@wjh.hardakers.net> Date: Fri, 13 Jan 2012 09:25:47 -0800 In-Reply-To: <0lk44v348h.fsf@wjh.hardakers.net> (Wes Hardaker's message of "Fri, 13 Jan 2012 09:24:30 -0800") Message-ID: <0lfwfj346c.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? 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, 13 Jan 2012 17:25:57 -0000 >>>>> On Fri, 13 Jan 2012 09:24:30 -0800, Wes Hardaker said: WH> Netconf has re-implemented the windows registry when operators really WH> just want a set of editable /etc files wrapped with 'git push' into it. Ok, first off: sorry for the negativity. Don't get me wrong: I think netconf has come a very long way and good things have been done. I don't want to say the entire system isn't useful, and the above text does sound that way. It is a good system, but IMHO, still incomplete from where we need it to get to. -- Wes Hardaker SPARTA, Inc. From lhotka@cesnet.cz Fri Jan 13 12:39: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 690E021F865A for ; Fri, 13 Jan 2012 12:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-tg3CcEpisX for ; Fri, 13 Jan 2012 12:39:48 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id C0A2021F8643 for ; Fri, 13 Jan 2012 12:39:47 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3B5FA2CDE05C for ; Fri, 13 Jan 2012 21:39:46 +0100 (CET) Message-ID: <4F109692.6020602@cesnet.cz> Date: Fri, 13 Jan 2012 21:39:46 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: netconf@ietf.org References: <201201121851.q0CIpZcF052857@idle.juniper.net> <0lk44v348h.fsf@wjh.hardakers.net> In-Reply-To: <0lk44v348h.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] NACM issue? 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, 13 Jan 2012 20:39:48 -0000 Dne 13.1.2012 18:24, Wes Hardaker napsal(a): >>>>>> On Thu, 12 Jan 2012 13:51:35 -0500, Phil Shafer said: > > PS> If the data sets are truly independent, consider distinct datastores. > > Yes, but netconf doesn't really push that concept well. You'd need > separate ports (or at least ssh service names) for each datastore for > each back-end independent config. That's not ideal. > > Netconf has re-implemented the windows registry when operators really > just want a set of editable /etc files wrapped with 'git push' into it. Yes, I think we can learn a thing or two from the modern DVCS systems. A 'pull' strategy might also be considered, where a superuser decides what changes prepared by somebody else will be accepted and when. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Fri Jan 13 12:44: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 F32D421F8673 for ; Fri, 13 Jan 2012 12:44:50 -0800 (PST) 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 194P48sywuPu for ; Fri, 13 Jan 2012 12:44:50 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id E69DA21F8670 for ; Fri, 13 Jan 2012 12:44:37 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCXsL3wU0+X+jQF0k9jvVVJ3s7OPnss@postini.com; Fri, 13 Jan 2012 12:44:50 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Jan 2012 12:32:24 -0800 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 q0DKWNS65951; Fri, 13 Jan 2012 12:32:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0DK2oIJ061425; Fri, 13 Jan 2012 20:02:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201132002.q0DK2oIJ061425@idle.juniper.net> To: Wes Hardaker In-Reply-To: <0lk44v348h.fsf@wjh.hardakers.net> Date: Fri, 13 Jan 2012 15:02:50 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? 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, 13 Jan 2012 20:44:51 -0000 Wes Hardaker writes: >Netconf has re-implemented the windows registry when operators really >just want a set of editable /etc files wrapped with 'git push' into it. That's not what I hear from operators, but maybe our customer overlap is zero. Viewing config as a set of /etc files in a source repository would be a nightmare IMHO. FWIW, the most common comment I get is that as long as they have to use Expect scripts to configure non-NETCONF routers, using fancier methods with our gear isn't a sufficient win. Thanks, Phil From lhotka@cesnet.cz Fri Jan 13 12:54: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 E83671F0C46 for ; Fri, 13 Jan 2012 12:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF+owJElOFFn for ; Fri, 13 Jan 2012 12:54:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 612D81F0C35 for ; Fri, 13 Jan 2012 12:54:02 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 839632CDE059 for ; Fri, 13 Jan 2012 21:54:01 +0100 (CET) Message-ID: <4F1099EA.6020607@cesnet.cz> Date: Fri, 13 Jan 2012 21:54:02 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: netconf@ietf.org References: <201201132002.q0DK2oIJ061425@idle.juniper.net> In-Reply-To: <201201132002.q0DK2oIJ061425@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] NACM issue? 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, 13 Jan 2012 20:54:03 -0000 Dne 13.1.2012 21:02, Phil Shafer napsal(a): > Wes Hardaker writes: >> Netconf has re-implemented the windows registry when operators really >> just want a set of editable /etc files wrapped with 'git push' into it. > > That's not what I hear from operators, but maybe our customer overlap > is zero. Viewing config as a set of /etc files in a source repository > would be a nightmare IMHO. Instead of files in a directory we can think about subtrees in a repository. Lada > > FWIW, the most common comment I get is that as long as they have > to use Expect scripts to configure non-NETCONF routers, using fancier > methods with our gear isn't a sufficient win. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.org Fri Jan 13 16:03: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 B10EA11E8095 for ; Fri, 13 Jan 2012 16:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 JyTOJ5A4E5bV for ; Fri, 13 Jan 2012 16:03:09 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id D92971F0C38 for ; Fri, 13 Jan 2012 16:03:01 -0800 (PST) Received: from cm-omr3 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q0E02vhC015738 for ; Fri, 13 Jan 2012 19:02:59 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:45750] helo=[192.168.0.126]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 8E/E0-24407-036C01F4; Fri, 13 Jan 2012 19:02:56 -0500 Message-ID: <4F10C630.8040308@netconfcentral.org> Date: Fri, 13 Jan 2012 16:02:56 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer , Wes Hardaker , netconf@ietf.org References: <0l39bmj8pl.fsf@wjh.hardakers.net> <201201121851.q0CIpZcF052857@idle.juniper.net> <20120113072505.GB97667@elstar.local> In-Reply-To: <20120113072505.GB97667@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] user write restrictions (was Re: NACM issue?) 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, 14 Jan 2012 00:03:09 -0000 On 01/12/2012 11:25 PM, Juergen Schoenwaelder wrote: > On Thu, Jan 12, 2012 at 01:51:35PM -0500, Phil Shafer wrote: > >> One area we haven't explored is "learned pseudo configuration", >> where one considered "configuration data" is taken to be permanent, >> but "learned data" is some of the same knobs, but learned from >> services that don't wish them to be permanent. >> >> Consider subscriber management as the best example. When the >> subscriber is present, some external app wants to tell us how their >> port should be configured, but they don't want it to be real >> configuration data. In JUNOS, we do this via a second datastore >> (called the dynamic database). It's never saved/restored, and one >> only looks at it when debugging the subscriber management app. > > The lack of support to handle this kind of operational (config) state > is well known. Are we getting ready to finally do something about it? > I am finally addressing this issue in yuma with a YANG extension. This comes up from time to time in user requests. IMO, there are several use cases for restricting user create, update, and/or delete operations, and the following YANG extension covers all of them (I hope). (Shameless plug -- this will be in the next release of yuma at the end of the month) extension user-write { description "Used within database configuration data definition statements to control user write access to the database object containing this statement. The 'permitted' argument is a list of operations that users are permitted to invoke for the specified node. These permissions will over-ride all NACM access control rules, even if NACM is disabled. This extension does not apply to descendant nodes! This extension has no effect if config-stmt is false! The following values are supported: * create : allow users to create instances of the object * update : allow users to modify instances of the object * delete : allow users to delete instances of the object To dis-allow all user access, provide an empty string for the 'permitted' parameter (user-write '';) To allow only create and delete user access, provide the string 'create delete' for the 'permitted' parameter. Use this for parameters that cannot be changed once they are set. Providing all 3 parameters has the same affect as not using this extension at all, but can be used anyway. leaf user-write { description 'equivalent YANG definition'; type bits { bit create; bit update; bit delete; } default 'create update delete'; } "; argument exceptions { yin-element true; } } Examples: container interfaces { ncx:user-write update; // only system can create & delete ... } leaf set-once { // cannot modify; instrumentation only supports delete and re-add ncx:user-write "create delete"; ... } leaf uuid { // only system allowed to write this leaf ncx:user-write ""; ... } > /js > Andy From andy@netconfcentral.org Fri Jan 13 16:59: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 504BC1F0C53 for ; Fri, 13 Jan 2012 16:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_64=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 kSFwKnK4dG4B for ; Fri, 13 Jan 2012 16:59:30 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id BF04F1F0C3D for ; Fri, 13 Jan 2012 16:59:30 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0E0xRpC006268 for ; Fri, 13 Jan 2012 19:59:29 -0500 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:58853] helo=[192.168.0.126]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B6/8C-12338-F63D01F4; Fri, 13 Jan 2012 19:59:27 -0500 Message-ID: <4F10D36E.5030500@netconfcentral.org> Date: Fri, 13 Jan 2012 16:59:26 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer , Wes Hardaker , netconf@ietf.org References: <0l39bmj8pl.fsf@wjh.hardakers.net> <201201121851.q0CIpZcF052857@idle.juniper.net> <20120113072505.GB97667@elstar.local> <4F10C630.8040308@netconfcentral.org> In-Reply-To: <4F10C630.8040308@netconfcentral.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] user write restrictions (was Re: NACM issue?) 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, 14 Jan 2012 00:59:31 -0000 On 01/13/2012 04:02 PM, Andy Bierman wrote: > On 01/12/2012 11:25 PM, Juergen Schoenwaelder wrote: >> On Thu, Jan 12, 2012 at 01:51:35PM -0500, Phil Shafer wrote: .... >>> Consider subscriber management as the best example. When the >>> subscriber is present, some external app wants to tell us how their >>> port should be configured, but they don't want it to be real >>> configuration data. In JUNOS, we do this via a second datastore >>> (called the dynamic database). It's never saved/restored, and one >>> only looks at it when debugging the subscriber management app. >> Actually, the user-write extension addresses a different problem. You can easily solve this problem now with a special RPC operation, like 'set-subscriber-port'. You can put the temp config in read-only if needed. It isn't really config if it is not meant to be saved. That has been our definition for a long time, and it still seems valid. To use config=true, there would need to be some new YANG mechanism to indicate when to delete the data, and not to save it in NV-store. (See old email logs for 'tconfig' transient-config email discussions for config=true data that never gets NV-saved, and gets dropped across a reboot. (I like to remind you that I wanted 3 states for config-stmt way-back-when :-) Andy From calle@tail-f.com Sat Jan 14 00:24: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 E5ED521F8534 for ; Sat, 14 Jan 2012 00:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 iJHXpn4lMJCI for ; Sat, 14 Jan 2012 00:24:51 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 428F521F852D for ; Sat, 14 Jan 2012 00:24:50 -0800 (PST) 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 3D56B1200052; Sat, 14 Jan 2012 09:24:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: <0lk44v348h.fsf@wjh.hardakers.net> Date: Sat, 14 Jan 2012 09:24:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18ADD573-C9BB-4661-92A5-14FA1887AFFE@tail-f.com> References: <201201121851.q0CIpZcF052857@idle.juniper.net> <0lk44v348h.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1251.1) Cc: netconf@ietf.org Subject: Re: [Netconf] NACM issue? 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, 14 Jan 2012 08:24:52 -0000 On Jan 13, 2012, at 18:24 PM, Wes Hardaker wrote: >>>>>> On Thu, 12 Jan 2012 13:51:35 -0500, Phil Shafer = said: >=20 > PS> If the data sets are truly independent, consider distinct = datastores. >=20 > Yes, but netconf doesn't really push that concept well. You'd need > separate ports (or at least ssh service names) for each datastore for > each back-end independent config. That's not ideal. >=20 > Netconf has re-implemented the windows registry when operators really > just want a set of editable /etc files wrapped with 'git push' into = it. Ok, I'll bite. Yes, NETCONF has introduced the concept of a consistent interface and behavior for a set of managed objects that may or may not be implemented in a consistent manner. If that is re-implementing the = Windows Registry then there are many things in the computer industry that are = mere re-implementations of that. For the second half of the sentence; no they don't. They want a = combination of a useful CLI (network-wide if possible) and comfortable scripting = and programming environments (e.g. based on NETCONF and perhaps REST) with support for transactions. They also would like standard data models for core protocols. They also want to keep SNMP for traps and simple PM and FM functions. Regards, -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From andy@netconfcentral.org Wed Jan 18 16:39: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 953D111E80D7 for ; Wed, 18 Jan 2012 16:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_20=-0.74] 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 LArnzM2y483U for ; Wed, 18 Jan 2012 16:39:15 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0816511E80D1 for ; Wed, 18 Jan 2012 16:39:14 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0J0dBAr000526 for ; Wed, 18 Jan 2012 19:39:13 -0500 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:58720] helo=[192.168.0.9]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B6/21-23644-F26671F4; Wed, 18 Jan 2012 19:39:11 -0500 Message-ID: <4F17662E.3010209@netconfcentral.org> Date: Wed, 18 Jan 2012 16:39:10 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 00:39:15 -0000 Hi, I was looking over this draft: http://www.ietf.org/id/draft-schoenw-netconf-light-01.txt I can agree with the problem statement: There is a need for a constrained server which supports a limited subset of NETCONF operations. I don't agree with the solution, since it is not backward-compatible with any version of NETCONF. A base:1.0 or base:1.1 peer will simply terminate the session when a NETCONF Light peer does not advertise either of these capabilities. YANG deviations can be used to fully describe the operations subset that a server implements, and this is backward-compatible with the current version of NETCONF. Andy From phil@juniper.net Wed Jan 18 21:03: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 6F82211E80FC for ; Wed, 18 Jan 2012 21:03:38 -0800 (PST) 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 Ia+a5aiprwFo for ; Wed, 18 Jan 2012 21:03:37 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id B502F11E8076 for ; Wed, 18 Jan 2012 21:03:36 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTxekHFva7xUcKvVNFh5D8ZKYIdKm3JSX@postini.com; Wed, 18 Jan 2012 21:03:37 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 18 Jan 2012 21:03:23 -0800 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 q0J53M137926; Wed, 18 Jan 2012 21:03:22 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0J4Xjsd012533; Thu, 19 Jan 2012 04:33:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201190433.q0J4Xjsd012533@idle.juniper.net> To: Andy Bierman In-Reply-To: <4F17662E.3010209@netconfcentral.org> Date: Wed, 18 Jan 2012 23:33:45 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 05:03:38 -0000 Andy Bierman writes: >A base:1.0 or base:1.1 peer will simply terminate >the session when a NETCONF Light peer does not advertise either of these capabilities. Haven't read the draft, but doesn't the Postel principle hold here? IIRC JUNOS doesn't require the at all. It was mostly useless in RFC4741 NETCONF. Thanks, Phil From andy@netconfcentral.org Wed Jan 18 23:33: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 6D8C021F856D for ; Wed, 18 Jan 2012 23:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 VCNGChkoAewj for ; Wed, 18 Jan 2012 23:33:28 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id BAD1421F856C for ; Wed, 18 Jan 2012 23:33:28 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0J7XQt0008143 for ; Thu, 19 Jan 2012 02:33:26 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59141] helo=[192.168.0.9]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1B/54-15882-547C71F4; Thu, 19 Jan 2012 02:33:26 -0500 Message-ID: <4F17C745.9020201@netconfcentral.org> Date: Wed, 18 Jan 2012 23:33:25 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer References: <201201190433.q0J4Xjsd012533@idle.juniper.net> In-Reply-To: <201201190433.q0J4Xjsd012533@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 07:33:29 -0000 On 01/18/2012 08:33 PM, Phil Shafer wrote: > Andy Bierman writes: >> A base:1.0 or base:1.1 peer will simply terminate >> the session when a NETCONF Light peer does not advertise either of these capabilities. > > Haven't read the draft, but doesn't the Postel principle hold here? > IIRC JUNOS doesn't require the at all. It was mostly useless > in RFC4741 NETCONF. > No, because the SSH framing is determined by the base:1.x capability advertised. This isn't the only MUST that I've seen server implementations ignore. But even if the solution-space argument "it doesn't matter to the client" is used, I could argue "just use the standard correctly and send operation-not-supported errors -- a new capability + features does not help at all". There is already a standard solution that will work that is backward-compatible so why bother inventing a new solution that is not backward-compatible? The "Don't waste our time" Principle holds here. > Thanks, > Phil > > Andy From j.schoenwaelder@jacobs-university.de Wed Jan 18 23:44: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 4F18C21F85BE for ; Wed, 18 Jan 2012 23:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 KsYqk-3OcVxI for ; Wed, 18 Jan 2012 23:44:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D021F85A3 for ; Wed, 18 Jan 2012 23:44:18 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89C7220BCD; Thu, 19 Jan 2012 08:44:15 +0100 (CET) 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 PCSw0fygNX2D; Thu, 19 Jan 2012 08:44:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A6CF20BC1; Thu, 19 Jan 2012 08:44:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 651EE1C913AF; Thu, 19 Jan 2012 08:43:57 +0100 (CET) Date: Thu, 19 Jan 2012 08:43:57 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120119074356.GA31476@elstar.local> Mail-Followup-To: Andy Bierman , NETCONF References: <4F17662E.3010209@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F17662E.3010209@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETCONF Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 07:44:19 -0000 On Wed, Jan 18, 2012 at 04:39:10PM -0800, Andy Bierman wrote: > Hi, > > I was looking over this draft: > > http://www.ietf.org/id/draft-schoenw-netconf-light-01.txt > > I can agree with the problem statement: > There is a need for a constrained server which supports a limited subset of NETCONF operations. > > I don't agree with the solution, since it is not backward-compatible with > any version of NETCONF. A base:1.0 or base:1.1 peer will simply terminate > the session when a NETCONF Light peer does not advertise either of these capabilities. And this is correct. A NETCONF Light server does not implement base:1.0 nor base:1.1 - so announcing it would be bad. > YANG deviations can be used to fully describe the operations subset > that a server implements, and this is backward-compatible with the > current version of NETCONF. There are two concerns with this: 1) YANG says deviations can't be standardized: Deviations define the way a device or class of devices deviate from a standard. This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards. 2) Can we reasonably expect all client implementations, including scripts, to handle deviations correctly? If not, announcing the base:1.x with deviations will likely lead dumb clients to assume the server speaks NETCONF while it does not. By using a different capability, it is explicit from the start that the device implements NETCONF Lite. I believe it is more robust to use a different capability + features than using the NETCONF base:1.1 capability + deviations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jan 19 00:03: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 5FBAA11E8083 for ; Thu, 19 Jan 2012 00:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.312, 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 BF+WbXey52fa for ; Thu, 19 Jan 2012 00:03:16 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D106E11E8072 for ; Thu, 19 Jan 2012 00:03:15 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B05E1200AC0; Thu, 19 Jan 2012 09:03:14 +0100 (CET) Date: Thu, 19 Jan 2012 09:03:13 +0100 (CET) Message-Id: <20120119.090313.2163197152303479154.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201201190433.q0J4Xjsd012533@idle.juniper.net> References: <4F17662E.3010209@netconfcentral.org> <201201190433.q0J4Xjsd012533@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 08:03:16 -0000 Phil Shafer wrote: > Andy Bierman writes: > >A base:1.0 or base:1.1 peer will simply terminate > >the session when a NETCONF Light peer does not advertise either of > >these capabilities. > > Haven't read the draft, but doesn't the Postel principle hold here? > IIRC JUNOS doesn't require the at all. It was mostly useless > in RFC4741 NETCONF. I think Andy refers to the client - to the client, is not meaningless. Anyway, I don't think it is a problem if this new protocol is not compatible with old clients. I have another comment. The draft needs to discuss the transport layer. RFC 6242 uses the :base capability to determine framing, and since this protocol doesn't advertise :base, it is not clear what a client should do. /martin From andy@netconfcentral.org Thu Jan 19 00:37: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 05F4221F846E for ; Thu, 19 Jan 2012 00:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 uMm8e6xi8vFi for ; Thu, 19 Jan 2012 00:37:37 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 07DE121F86C4 for ; Thu, 19 Jan 2012 00:37:36 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0J8bXCU020822 for ; Thu, 19 Jan 2012 03:37:33 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59176] helo=[192.168.0.9]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D3/02-15882-D46D71F4; Thu, 19 Jan 2012 03:37:33 -0500 Message-ID: <4F17D64D.2050701@netconfcentral.org> Date: Thu, 19 Jan 2012 00:37:33 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: NETCONF References: <4F17662E.3010209@netconfcentral.org> <20120119074356.GA31476@elstar.local> In-Reply-To: <20120119074356.GA31476@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 08:37:38 -0000 On 01/18/2012 11:43 PM, Juergen Schoenwaelder wrote: > On Wed, Jan 18, 2012 at 04:39:10PM -0800, Andy Bierman wrote: >> Hi, >> >> I was looking over this draft: >> >> http://www.ietf.org/id/draft-schoenw-netconf-light-01.txt >> >> I can agree with the problem statement: >> There is a need for a constrained server which supports a limited subset of NETCONF operations. >> >> I don't agree with the solution, since it is not backward-compatible with >> any version of NETCONF. A base:1.0 or base:1.1 peer will simply terminate >> the session when a NETCONF Light peer does not advertise either of these capabilities. > > And this is correct. A NETCONF Light server does not implement > base:1.0 nor base:1.1 - so announcing it would be bad. > >> YANG deviations can be used to fully describe the operations subset >> that a server implements, and this is backward-compatible with the >> current version of NETCONF. > > There are two concerns with this: > > 1) YANG says deviations can't be standardized: > > Deviations define the way a device or class of devices deviate from a > standard. This means that deviations MUST never be part of a > published standard, since they are the mechanism for learning how > implementations vary from the standards. > The purpose of deviations is to describe to the client what details in the API are different than the 'contract'. YANG deviations are designed and included in the standard for exactly the purpose that a NETCONF light server needs. > 2) Can we reasonably expect all client implementations, including > scripts, to handle deviations correctly? If not, announcing the > base:1.x with deviations will likely lead dumb clients to assume > the server speaks NETCONF while it does not. By using a different > capability, it is explicit from the start that the device > implements NETCONF Lite. > Yes, we can expect clients that implement YANG correctly to understand deviations. IMO this 'light' solution is a hack -- a client would be better off ignoring all of this and just going by the operation-not-supported errors it gets back. A new client would have to be coded to look for the special new URI instead of the old ones, then apply the features from the fake 'light' module to the ietf-netconf module, and use the ietf-netconf module XML namespace as well. Or, an existing client could ignore all the deviations and URIs and just attempt operations to see if they worked. > I believe it is more robust to use a different capability + features > than using the NETCONF base:1.1 capability + deviations. > IMO, robust would be if the solution did not break with existing versions of the standard. A non-backward-compatible solution is not robust at all. > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Jan 19 01:10: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 ACBEC21F86F2 for ; Thu, 19 Jan 2012 01:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.225 X-Spam-Level: X-Spam-Status: No, score=-103.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 onoZn+cdPaI8 for ; Thu, 19 Jan 2012 01:10:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EBAD121F86EA for ; Thu, 19 Jan 2012 01:10:08 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCBC020BEA; Thu, 19 Jan 2012 10:10:00 +0100 (CET) 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 BW7nNQWWNdbm; Thu, 19 Jan 2012 10:10:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C4A420BE6; Thu, 19 Jan 2012 10:10:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6B94D1C91668; Thu, 19 Jan 2012 10:09:42 +0100 (CET) Date: Thu, 19 Jan 2012 10:09:41 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120119090941.GA31884@elstar.local> Mail-Followup-To: Andy Bierman , NETCONF References: <4F17662E.3010209@netconfcentral.org> <20120119074356.GA31476@elstar.local> <4F17D64D.2050701@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F17D64D.2050701@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETCONF Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 09:10:09 -0000 On Thu, Jan 19, 2012 at 12:37:33AM -0800, Andy Bierman wrote: > IMO this 'light' solution is a hack -- a client would be better off > ignoring all of this and just going by the operation-not-supported > errors it gets back. A new client would have to be coded to look > for the special new URI instead of the old ones, then apply the > features from the fake 'light' module to the ietf-netconf module, > and use the ietf-netconf module XML namespace as well. > > Or, an existing client could ignore all the deviations and URIs > and just attempt operations to see if they worked. Some people prefer to know upfront what they can expect. Lets overcome the old SNMP idea to try and if something expected is not there assume there is smart code to try something else instead. I prefer a yangcli that _upon_startup_ says "sorry the remote end does not do NETCONF". Much better than a yangcli that fails badly in the middle while I am trying to get a job done. And if yangcli gets extended to support NETCONF Light, it can tell the user upon startup that its talking to a NETCONF Light server and adapt the commands offered to the user to what the server supports. Feature negotiation is in my view much better than failing unexpectedly. Of course, your mileage can vary. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jan 19 01:16: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 E3F0B21F86B3 for ; Thu, 19 Jan 2012 01:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.278, 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 C6bWST5FSY4o for ; Thu, 19 Jan 2012 01:16:08 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1E21F86B2 for ; Thu, 19 Jan 2012 01:16:08 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 77B901200D00; Thu, 19 Jan 2012 10:16:07 +0100 (CET) Date: Thu, 19 Jan 2012 10:16:06 +0100 (CET) Message-Id: <20120119.101606.23933925964563865.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120119090941.GA31884@elstar.local> References: <20120119074356.GA31476@elstar.local> <4F17D64D.2050701@netconfcentral.org> <20120119090941.GA31884@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 09:16:09 -0000 Juergen Schoenwaelder wrote: > On Thu, Jan 19, 2012 at 12:37:33AM -0800, Andy Bierman wrote: > > > IMO this 'light' solution is a hack -- a client would be better off > > ignoring all of this and just going by the operation-not-supported > > errors it gets back. A new client would have to be coded to look > > for the special new URI instead of the old ones, then apply the > > features from the fake 'light' module to the ietf-netconf module, > > and use the ietf-netconf module XML namespace as well. > > > > Or, an existing client could ignore all the deviations and URIs > > and just attempt operations to see if they worked. > > Some people prefer to know upfront what they can expect. Lets overcome > the old SNMP idea to try and if something expected is not there assume > there is smart code to try something else instead. +1 /martin From j.schoenwaelder@jacobs-university.de Thu Jan 19 03:55: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 3AAAF21F8606 for ; Thu, 19 Jan 2012 03:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 IGuPbHG+aNXa for ; Thu, 19 Jan 2012 03:55:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 740F721F85CD for ; Thu, 19 Jan 2012 03:55:51 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C311620C58; Thu, 19 Jan 2012 12:55:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pL_NXdbeirPP; Thu, 19 Jan 2012 12:55:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 673CC20C57; Thu, 19 Jan 2012 12:55:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 424F91C91B91; Thu, 19 Jan 2012 12:55:32 +0100 (CET) Date: Thu, 19 Jan 2012 12:55:31 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120119115531.GA32806@elstar.local> Mail-Followup-To: Martin Bjorklund , phil@juniper.net, netconf@ietf.org References: <4F17662E.3010209@netconfcentral.org> <201201190433.q0J4Xjsd012533@idle.juniper.net> <20120119.090313.2163197152303479154.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120119.090313.2163197152303479154.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 11:55:52 -0000 On Thu, Jan 19, 2012 at 09:03:13AM +0100, Martin Bjorklund wrote: > > I have another comment. The draft needs to discuss the transport > layer. RFC 6242 uses the :base capability to determine framing, and > since this protocol doesn't advertise :base, it is not clear what a > client should do. > Here the proposed fix: OLD: NETCONF Light uses the NETCONF message framing as defined in [RFC6241]. In particular, it uses the same XML encoding and XML namespace. NEW: NETCONF Light uses the NETCONF message format as defined in [RFC6241]. In particular, it uses the same XML encoding and XML namespace. Furthermore, NETCONF Light uses the same NETCONF transports such as NETCONF over SSH as defined in [RFC6242]. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jan 19 03:59: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 9012121F8609 for ; Thu, 19 Jan 2012 03:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.250, 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 evno5QBF0oOe for ; Thu, 19 Jan 2012 03:59:57 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 11D2121F8575 for ; Thu, 19 Jan 2012 03:59:56 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 079D31200AC0; Thu, 19 Jan 2012 12:59:56 +0100 (CET) Date: Thu, 19 Jan 2012 12:59:55 +0100 (CET) Message-Id: <20120119.125955.2020313308935266464.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120119115531.GA32806@elstar.local> References: <201201190433.q0J4Xjsd012533@idle.juniper.net> <20120119.090313.2163197152303479154.mbj@tail-f.com> <20120119115531.GA32806@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 11:59:57 -0000 Juergen Schoenwaelder wrote: > On Thu, Jan 19, 2012 at 09:03:13AM +0100, Martin Bjorklund wrote: > > > > I have another comment. The draft needs to discuss the transport > > layer. RFC 6242 uses the :base capability to determine framing, and > > since this protocol doesn't advertise :base, it is not clear what a > > client should do. > > > > Here the proposed fix: > > OLD: > > NETCONF Light uses the NETCONF message framing as defined in > [RFC6241]. In particular, it uses the same XML encoding and XML > namespace. > > NEW: > > NETCONF Light uses the NETCONF message format as defined in > [RFC6241]. In particular, it uses the same XML encoding and XML > namespace. Furthermore, NETCONF Light uses the same NETCONF > transports such as NETCONF over SSH as defined in [RFC6242]. Unless you want to use the old SSH framing, the problem is this in 6242: If the :base:1.1 capability is advertised by both peers, the chunked framing mechanism (see Section 4.2) is used for the remainder of the NETCONF session. Otherwise, the old end-of- message-based mechanism (see Section 4.3) is used. /martin From andy@netconfcentral.org Thu Jan 19 04:23: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 20E8D21F8619 for ; Thu, 19 Jan 2012 04:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 gd7sTrq8Nbpp for ; Thu, 19 Jan 2012 04:23:00 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD2C21F85FC for ; Thu, 19 Jan 2012 04:23:00 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q0JCMtlN026316 for ; Thu, 19 Jan 2012 07:22:57 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59277] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 70/31-03964-E1B081F4; Thu, 19 Jan 2012 07:22:55 -0500 Message-ID: <4F180B1E.2040402@netconfcentral.org> Date: Thu, 19 Jan 2012 04:22:54 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: NETCONF References: <4F17662E.3010209@netconfcentral.org> <20120119074356.GA31476@elstar.local> <4F17D64D.2050701@netconfcentral.org> <20120119090941.GA31884@elstar.local> In-Reply-To: <20120119090941.GA31884@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 12:23:02 -0000 On 01/19/2012 01:09 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 19, 2012 at 12:37:33AM -0800, Andy Bierman wrote: > >> IMO this 'light' solution is a hack -- a client would be better off >> ignoring all of this and just going by the operation-not-supported >> errors it gets back. A new client would have to be coded to look >> for the special new URI instead of the old ones, then apply the >> features from the fake 'light' module to the ietf-netconf module, >> and use the ietf-netconf module XML namespace as well. >> >> Or, an existing client could ignore all the deviations and URIs >> and just attempt operations to see if they worked. > > Some people prefer to know upfront what they can expect. Lets overcome > the old SNMP idea to try and if something expected is not there assume > there is smart code to try something else instead. > This isn't about SNMP. It is about using the YANG deviations that already exist for the purpose that they were designed for, or ignoring them, and producing new solutions that do not work with the existing standard. > I prefer a yangcli that _upon_startup_ says "sorry the remote end does > not do NETCONF". Much better than a yangcli that fails badly in the > middle while I am trying to get a job done. And if yangcli gets > extended to support NETCONF Light, it can tell the user upon startup > that its talking to a NETCONF Light server and adapt the commands > offered to the user to what the server supports. Feature negotiation > is in my view much better than failing unexpectedly. Of course, your > mileage can vary. yangcli already supports deviations in data model modules. It would be much easier to complete that work for the protocol operations than it would to re-engineer for a new hello exchange, and map the fake light 'features' to the ietf-netconf module. > > /js > Andy From andy@netconfcentral.org Thu Jan 19 04:38: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 035AA21F8611 for ; Thu, 19 Jan 2012 04:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 EkSlDhVmN8vx for ; Thu, 19 Jan 2012 04:38:51 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4CD21F860F for ; Thu, 19 Jan 2012 04:38:51 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0JCcmrP024134 for ; Thu, 19 Jan 2012 07:38:50 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59291] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0F/BA-05356-8DE081F4; Thu, 19 Jan 2012 07:38:48 -0500 Message-ID: <4F180ED8.7050409@netconfcentral.org> Date: Thu, 19 Jan 2012 04:38:48 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20120119074356.GA31476@elstar.local> <4F17D64D.2050701@netconfcentral.org> <20120119090941.GA31884@elstar.local> <20120119.101606.23933925964563865.mbj@tail-f.com> In-Reply-To: <20120119.101606.23933925964563865.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 12:38:52 -0000 On 01/19/2012 01:16 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Thu, Jan 19, 2012 at 12:37:33AM -0800, Andy Bierman wrote: >> >>> IMO this 'light' solution is a hack -- a client would be better off >>> ignoring all of this and just going by the operation-not-supported >>> errors it gets back. A new client would have to be coded to look >>> for the special new URI instead of the old ones, then apply the >>> features from the fake 'light' module to the ietf-netconf module, >>> and use the ietf-netconf module XML namespace as well. >>> >>> Or, an existing client could ignore all the deviations and URIs >>> and just attempt operations to see if they worked. >> >> Some people prefer to know upfront what they can expect. Lets overcome >> the old SNMP idea to try and if something expected is not there assume >> there is smart code to try something else instead. > > +1 > If the code was smart, it would pay attention to the server instead of ignoring it. My comment above is pointing out that if the client is not going to use the deviations, why would it bother to use this new capability plus all the fake YANG features (they apply to the ietf-module, not the light module)? Processing all the tells you what the server may do in advance, if implemented correctly, for 1 specific error-tag (operation-not-supported). The client still needs to be coded to handle all the other error-tags that can occur, such as in-use, resource-denied, operation-failed. In a way, it is a myth that the hello solves any real coding problems in the NMS. > > /martin > > Andy From j.schoenwaelder@jacobs-university.de Thu Jan 19 05:30: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 2FE6921F85C7 for ; Thu, 19 Jan 2012 05:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.022, 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 hiAwvG7WWvBo for ; Thu, 19 Jan 2012 05:30:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 64FB921F85C2 for ; Thu, 19 Jan 2012 05:30:01 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7C5420C79; Thu, 19 Jan 2012 14:30:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rTa7E7FiTzI2; Thu, 19 Jan 2012 14:30:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56E1820C76; Thu, 19 Jan 2012 14:30:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6A0D11C91D47; Thu, 19 Jan 2012 14:29:41 +0100 (CET) Date: Thu, 19 Jan 2012 14:29:41 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120119132941.GA33392@elstar.local> Mail-Followup-To: Andy Bierman , NETCONF References: <4F17662E.3010209@netconfcentral.org> <20120119074356.GA31476@elstar.local> <4F17D64D.2050701@netconfcentral.org> <20120119090941.GA31884@elstar.local> <4F180B1E.2040402@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F180B1E.2040402@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETCONF Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 13:30:02 -0000 On Thu, Jan 19, 2012 at 04:22:54AM -0800, Andy Bierman wrote: > This isn't about SNMP. > It is about using the YANG deviations that already exist for the > purpose that they were designed for, or ignoring them, and producing > new solutions that do not work with the existing standard. There is a standard that says: Deviations define the way a device or class of devices deviate from a standard. This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards. We are compliant with that. ;-) > >I prefer a yangcli that _upon_startup_ says "sorry the remote end does > >not do NETCONF". Much better than a yangcli that fails badly in the > >middle while I am trying to get a job done. And if yangcli gets > >extended to support NETCONF Light, it can tell the user upon startup > >that its talking to a NETCONF Light server and adapt the commands > >offered to the user to what the server supports. Feature negotiation > >is in my view much better than failing unexpectedly. Of course, your > >mileage can vary. > > yangcli already supports deviations in data model modules. > It would be much easier to complete that work for the protocol operations > than it would to re-engineer for a new hello exchange, and map the > fake light 'features' to the ietf-netconf module. There is no new hello exchange. We just announce a different version of NETCONF - that has happened before. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Thu Jan 19 08:05: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 92B5C21F868A for ; Thu, 19 Jan 2012 08:05:21 -0800 (PST) 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 PmwC1vAKm25U for ; Thu, 19 Jan 2012 08:05:21 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 244D221F8685 for ; Thu, 19 Jan 2012 08:05:17 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTxg/MPnV4AqPfHnsqJb5OFIdyszZKCQE@postini.com; Thu, 19 Jan 2012 08:05:20 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 08:02:56 -0800 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 q0JG2t169797; Thu, 19 Jan 2012 08:02:55 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0JFXISF019580; Thu, 19 Jan 2012 15:33:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201191533.q0JFXISF019580@idle.juniper.net> To: Andy Bierman In-Reply-To: <4F180ED8.7050409@netconfcentral.org> Date: Thu, 19 Jan 2012 10:33:18 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:05:21 -0000 Andy Bierman writes: >If the code was smart, it would pay attention to the server instead >of ignoring it. The vast majority of our client connections aren't smart. And they don't want to be. They've been given a XML-encoded RPC and want to issue it to the remote side and pass the XML-encoded results back to the user. The idea is that a NETCONF client _CAN_ be smart, not that it _MUST_ be smart. But if we're doing a "light" version, can we do something to address connection startup time? ssh startup is expensive and then we do our hello handshake on top of that. If we're being light and not worrying about backwards compatibility (which seems strange), can we make the officially optional, since clients can use the RPC (get-hello?) get the hello contents? I keep noodling our resident ssh guy to come up with a means of caching keys between connections to reduce the exchange ssh does at startup. Thanks, Phil From phil@juniper.net Thu Jan 19 08:08: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 7419021F8619 for ; Thu, 19 Jan 2012 08:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKpv9UuYI86k for ; Thu, 19 Jan 2012 08:08:38 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id BB8A021F8617 for ; Thu, 19 Jan 2012 08:08:34 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTxhAAm7kWsEyAOwNKTCN+JmWG/+rQ/Bp@postini.com; Thu, 19 Jan 2012 08:08:38 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 08:07:45 -0800 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 q0JG7i171829; Thu, 19 Jan 2012 08:07:44 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0JFc7EX019678; Thu, 19 Jan 2012 15:38:07 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201191538.q0JFc7EX019678@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120119.090313.2163197152303479154.mbj@tail-f.com> Date: Thu, 19 Jan 2012 10:38:07 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:08:39 -0000 Martin Bjorklund writes: >I think Andy refers to the client - to the client, is not >meaningless. My experience may be different, since my devices are more permanent and don't DHCP, but... To most of our clients, the hello is meaningless. The OSS system above them knows what the server device is, has generated configuration for it, and wants the client library to commit that code. The typical client just wants to open the connection, toss the RPCs, and return something useful to the caller. Except for a sanity check (to see that the device hasn't suddenly transmogrified into a new box), the hello is ignored. Thanks, Phil From j.schoenwaelder@jacobs-university.de Thu Jan 19 08:22:32 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D153C21F84DD for ; Thu, 19 Jan 2012 08:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 KBmXlK9qXzaU for ; Thu, 19 Jan 2012 08:22:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8074521F84D4 for ; Thu, 19 Jan 2012 08:22:29 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1F1320C70; Thu, 19 Jan 2012 17:22:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kttpTjLFDNRT; Thu, 19 Jan 2012 17:22:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2ED5420BCD; Thu, 19 Jan 2012 17:22:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1D4791C9261E; Thu, 19 Jan 2012 17:22:09 +0100 (CET) Date: Thu, 19 Jan 2012 17:22:09 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20120119162209.GA33914@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , netconf@ietf.org References: <4F180ED8.7050409@netconfcentral.org> <201201191533.q0JFXISF019580@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201191533.q0JFXISF019580@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:22:32 -0000 On Thu, Jan 19, 2012 at 10:33:18AM -0500, Phil Shafer wrote: > But if we're doing a "light" version, can we do something to address > connection startup time? ssh startup is expensive and then we do > our hello handshake on top of that. If we're being light and not > worrying about backwards compatibility (which seems strange), can > we make the officially optional, since clients can use the > RPC (get-hello?) get the hello contents? The big hit is the key generation - the is a piece of cake compared to that. > I keep noodling our resident ssh guy to come up with a means of > caching keys between connections to reduce the exchange ssh does > at startup. You may be interested in this: http://dx.doi.org/10.1109/INM.2009.5188805 If someone needs access because your company does not have IEEE eXplore access, contact me privately. I am not sure how to get something like this into common open source implementations... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Thu Jan 19 08:29: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 4089B21F850D for ; Thu, 19 Jan 2012 08:29:31 -0800 (PST) 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 6EoLEmN7JTHl for ; Thu, 19 Jan 2012 08:29:30 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5369F21F8475 for ; Thu, 19 Jan 2012 08:29:27 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTxhE5uR7pnBSbkbmUF3jaVoH6C7uV9ME@postini.com; Thu, 19 Jan 2012 08:29:30 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 08:28:02 -0800 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 q0JGS1183130; Thu, 19 Jan 2012 08:28:01 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0JFwNJr020065; Thu, 19 Jan 2012 15:58:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201191558.q0JFwNJr020065@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20120119162209.GA33914@elstar.local> Date: Thu, 19 Jan 2012 10:58:23 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:29:31 -0000 Juergen Schoenwaelder writes: >http://dx.doi.org/10.1109/INM.2009.5188805 Exactly! >If someone needs access because your company does not have IEEE >eXplore access, contact me privately. I am not sure how to get >something like this into common open source implementations... You send a patch to openssh.com ;^) Thanks, Phil From andy@netconfcentral.org Thu Jan 19 09: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 868A421F86B9 for ; Thu, 19 Jan 2012 09:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 PzWePQobomWB for ; Thu, 19 Jan 2012 09:02:58 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id D0C4821F86AD for ; Thu, 19 Jan 2012 09:02:57 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0JH2t92007873 for ; Thu, 19 Jan 2012 12:02:57 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59440] helo=[192.168.0.9]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 35/07-17660-EBC481F4; Thu, 19 Jan 2012 12:02:55 -0500 Message-ID: <4F184CBE.4070105@netconfcentral.org> Date: Thu, 19 Jan 2012 09:02:54 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer References: <201201191538.q0JFc7EX019678@idle.juniper.net> In-Reply-To: <201201191538.q0JFc7EX019678@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:02:58 -0000 On 01/19/2012 07:38 AM, Phil Shafer wrote: > Martin Bjorklund writes: >> I think Andy refers to the client - to the client, is not >> meaningless. > > My experience may be different, since my devices are more permanent > and don't DHCP, but... > > To most of our clients, the hello is meaningless. The OSS system > above them knows what the server device is, has generated configuration > for it, and wants the client library to commit that code. The > typical client just wants to open the connection, toss the RPCs, > and return something useful to the caller. Except for a sanity > check (to see that the device hasn't suddenly transmogrified into > a new box), the hello is ignored. Not all applications are hard-coded to your server data models. It is quite possible to use the server to figure out the exact YANG content and NETCONF capabilities supported. The is very important to application developers who do not want to hard-code everything for a specific version of 1 server implementations. > > Thanks, > Phil > > Andy From mbj@tail-f.com Thu Jan 19 09:19: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 B6F3C21F85A3 for ; Thu, 19 Jan 2012 09:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 7AITc35lyKCv for ; Thu, 19 Jan 2012 09:19:20 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B7CAB21F85A2 for ; Thu, 19 Jan 2012 09:19:19 -0800 (PST) Received: from localhost (unknown [212.181.100.8]) by mail.tail-f.com (Postfix) with ESMTPSA id 379BD1200AC0; Thu, 19 Jan 2012 18:19:18 +0100 (CET) Date: Thu, 19 Jan 2012 18:19:17 +0100 (CET) Message-Id: <20120119.181917.159545890.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201201191538.q0JFc7EX019678@idle.juniper.net> References: <20120119.090313.2163197152303479154.mbj@tail-f.com> <201201191538.q0JFc7EX019678@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:19:20 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >I think Andy refers to the client - to the client, is not > >meaningless. > > My experience may be different, since my devices are more permanent > and don't DHCP, but... > > To most of our clients, the hello is meaningless. The OSS system > above them knows what the server device is, has generated configuration > for it, and wants the client library to commit that code. The > typical client just wants to open the connection, toss the RPCs, > and return something useful to the caller. Except for a sanity > check (to see that the device hasn't suddenly transmogrified into > a new box), the hello is ignored. So it isn't ignored - you do the sanity check. Expanding a bit on this, what we do is the first time the OSS system connects it performs a discovery, checking the protocol capabilities and data models supported on the device. The next times it connects, it will do the sanity check, in order to handle software upgrades etc. And of course, the new SSH framing scheme in 6242 is dependent on the hello message. I can easily imagine another design w/o a big hello message that would achieve the same goals (minimal hello + mandatory rpc), but I don't think it is worth the trouble changing it, especially not in NC/light. /martin From phil@juniper.net Thu Jan 19 09:36: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 3A6E021F845E for ; Thu, 19 Jan 2012 09:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0vMiC-as6lI for ; Thu, 19 Jan 2012 09:36:55 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D537B21F8608 for ; Thu, 19 Jan 2012 09:36:52 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTxhUqKcEFXBlR44eOyMnOxUTLmfTmTO8@postini.com; Thu, 19 Jan 2012 09:36:55 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 09:34:49 -0800 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 q0JHYm116338; Thu, 19 Jan 2012 09:34:49 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0JH5Bea020714; Thu, 19 Jan 2012 17:05:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201191705.q0JH5Bea020714@idle.juniper.net> To: Andy Bierman In-Reply-To: <4F184CBE.4070105@netconfcentral.org> Date: Thu, 19 Jan 2012 12:05:11 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:36:56 -0000 Andy Bierman writes: >Not all applications are hard-coded to your server data models. Clearly, that's neither what I said, nor what I meant. The OSS system keeps an inventory of all devices, their type/model/os information, supported data models and capabilities, as well as ports, installed hardware, etc. When the OSS user asks to provision a tunnel between two interfaces on two devices, the OSS system knows (by virtue of that inventory information) what those devices support. It generates a configuration payload that is specific to those devices, both in content and data model. When it goes to talk to the device, it's not interested in new inventory/data model/capability information. It wants to perform the RPCs given to it by the upper levels of its OSS brain. It might use that data as a sanity check, but the content is already in the pipeline and it's not going to change during the hello phase. Thanks, Phil From phil@juniper.net Thu Jan 19 09:38:27 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 82B0521F8611 for ; Thu, 19 Jan 2012 09:38:27 -0800 (PST) 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 o-ir4vdAqhzO for ; Thu, 19 Jan 2012 09:38:27 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49521F8609 for ; Thu, 19 Jan 2012 09:38:24 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTxhVD/7DvB1O/qU2Hs0vLd8gkOWPJE5T@postini.com; Thu, 19 Jan 2012 09:38:26 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 09:37:17 -0800 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 q0JHbG118126; Thu, 19 Jan 2012 09:37:16 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0JH7d7G020733; Thu, 19 Jan 2012 17:07:39 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201191707.q0JH7d7G020733@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120119.181917.159545890.mbj@tail-f.com> Date: Thu, 19 Jan 2012 12:07:39 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:38:27 -0000 Martin Bjorklund writes: >And of course, the new SSH framing scheme in 6242 is dependent on the >hello message. > >I can easily imagine another design w/o a big hello message that would >achieve the same goals (minimal hello + mandatory rpc), but I don't >think it is worth the trouble changing it, especially not in NC/light. I guess I should go read the draft, since it seems like if we're not worrying with backward compatibility, then removing the hello and forcing the new framing protocol would be a great outcome. Thanks, Phil From mbj@tail-f.com Thu Jan 19 09:44: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 C4FCB21F86B1 for ; Thu, 19 Jan 2012 09:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 miK+-fqB56pB for ; Thu, 19 Jan 2012 09:44:37 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 85F6121F86A9 for ; Thu, 19 Jan 2012 09:44:36 -0800 (PST) Received: from localhost (unknown [212.181.100.8]) by mail.tail-f.com (Postfix) with ESMTPSA id A0DA11200AC0; Thu, 19 Jan 2012 18:44:35 +0100 (CET) Date: Thu, 19 Jan 2012 18:44:34 +0100 (CET) Message-Id: <20120119.184434.362930325.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201201191707.q0JH7d7G020733@idle.juniper.net> References: <20120119.181917.159545890.mbj@tail-f.com> <201201191707.q0JH7d7G020733@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:44:37 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >And of course, the new SSH framing scheme in 6242 is dependent on the > >hello message. > > > >I can easily imagine another design w/o a big hello message that would > >achieve the same goals (minimal hello + mandatory rpc), but I don't > >think it is worth the trouble changing it, especially not in NC/light. > > I guess I should go read the draft, since it seems like if we're > not worrying with backward compatibility, Right, this is a new protocol. Or rather a new version of NETCONF. Sort of. It uses the same port, same subsystem, I believe. Should we do a NETCONF 2.0 instead with a more modular approach to the operations? > then removing the hello > and forcing the new framing protocol would be a great outcome. I'm glad we had the hello as it was, b/c otherwise we couldn't have done the new framing the way we did... so I think we need some sort of hello; maybe only advertising the protocol version and some hash or something of the rest. If the client's cached hash doesn't match the server, it can ask for the rest using a new rpc. /martin From mbj@tail-f.com Thu Jan 19 10: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 0FC5E21F8570 for ; Thu, 19 Jan 2012 10:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 M6-GcCjoy-5h for ; Thu, 19 Jan 2012 10:02:37 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7467821F84B2 for ; Thu, 19 Jan 2012 10:02:37 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B75811200AC0; Thu, 19 Jan 2012 19:02:36 +0100 (CET) Date: Thu, 19 Jan 2012 19:02:35 +0100 (CET) Message-Id: <20120119.190235.431758737.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <20120119.184434.362930325.mbj@tail-f.com> References: <20120119.181917.159545890.mbj@tail-f.com> <201201191707.q0JH7d7G020733@idle.juniper.net> <20120119.184434.362930325.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 18:02:38 -0000 Martin Bjorklund wrote: > Right, this is a new protocol. Or rather a new version of NETCONF. > Sort of. It uses the same port, same subsystem, I believe. Should we > do a NETCONF 2.0 instead with a more modular approach to the > operations? My own answer to this question: No, we shouldn't ;-) /martin From andy@netconfcentral.org Thu Jan 19 10:04: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 BB81D21F8624 for ; Thu, 19 Jan 2012 10:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Hjqqe9pIqJcW for ; Thu, 19 Jan 2012 10:04:05 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD0E21F8621 for ; Thu, 19 Jan 2012 10:04:04 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0JI42QB020735 for ; Thu, 19 Jan 2012 13:04:04 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59478] helo=[192.168.0.9]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C0/E5-24407-11B581F4; Thu, 19 Jan 2012 13:04:02 -0500 Message-ID: <4F185B12.8050903@netconfcentral.org> Date: Thu, 19 Jan 2012 10:04:02 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20120119.181917.159545890.mbj@tail-f.com> <201201191707.q0JH7d7G020733@idle.juniper.net> <20120119.184434.362930325.mbj@tail-f.com> In-Reply-To: <20120119.184434.362930325.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 18:04:05 -0000 On 01/19/2012 09:44 AM, Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> And of course, the new SSH framing scheme in 6242 is dependent on the >>> hello message. >>> >>> I can easily imagine another design w/o a big hello message that would >>> achieve the same goals (minimal hello + mandatory rpc), but I don't >>> think it is worth the trouble changing it, especially not in NC/light. >> >> I guess I should go read the draft, since it seems like if we're >> not worrying with backward compatibility, > > Right, this is a new protocol. Or rather a new version of NETCONF. > Sort of. It uses the same port, same subsystem, I believe. Should we > do a NETCONF 2.0 instead with a more modular approach to the > operations? > Back up a second... I don't agree that constrained devices warrant a special, non-backward-compatible version of NETCONF. IMO, a device that can only move its bulk config to and from the device can just use a file transfer protocol. NETCONF is the wrong tool for the job. What about all the NETCONF capabilities like :writable-running, :startup, etc? Are these hard-wired for all Light implementations as well? Deviations can be used to let a server advertise any 'less than full' NETCONF, not just the handful of deviations hard-coded into NETCONF Light YANG features, and the client can implement this standard mechanism in a uniform way. (Nothing special about 'not-implemented' for the get/filter parameter vs. any other RPC input parameter). The base:1.1 protocol was only published 6 months ago. I don't think there are enough new problems with the protocol to work on any new version. >> then removing the hello >> and forcing the new framing protocol would be a great outcome. > > I'm glad we had the hello as it was, b/c otherwise we couldn't have > done the new framing the way we did... so I think we need some sort > of hello; maybe only advertising the protocol version and some hash or > something of the rest. If the client's cached hash doesn't match the > server, it can ask for the rest using a new rpc. > > > /martin > > Andy From andy@netconfcentral.org Thu Jan 19 11:22: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 C725B21F8503 for ; Thu, 19 Jan 2012 11:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 SmiktGeDr4P5 for ; Thu, 19 Jan 2012 11:22:55 -0800 (PST) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 31B7921F8501 for ; Thu, 19 Jan 2012 11:22:54 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0JJMqIt012545 for ; Thu, 19 Jan 2012 14:22:52 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59658] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3D/88-11818-B8D681F4; Thu, 19 Jan 2012 14:22:52 -0500 Message-ID: <4F186D8C.9030904@netconfcentral.org> Date: Thu, 19 Jan 2012 11:22:52 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer References: <201201191707.q0JH7d7G020733@idle.juniper.net> In-Reply-To: <201201191707.q0JH7d7G020733@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 19:22:55 -0000 On 01/19/2012 09:07 AM, Phil Shafer wrote: > Martin Bjorklund writes: >> And of course, the new SSH framing scheme in 6242 is dependent on the >> hello message. >> >> I can easily imagine another design w/o a big hello message that would >> achieve the same goals (minimal hello + mandatory rpc), but I don't >> think it is worth the trouble changing it, especially not in NC/light. > > I guess I should go read the draft, since it seems like if we're > not worrying with backward compatibility, then removing the hello > and forcing the new framing protocol would be a great outcome. > Yes -- read the draft. I just read it carefully, and it is hard to recognize what features of NETCONF are actually retained in NETCONF Light. Comments: * A server does not have to implement anything, not even . NMS developers like to code only to mandatory-to-implement server features, and there are none in NETCONF Light. * There is no mention of all the NETCONF capabilities like :candidate, :writable-running, and :startup, which is very important to NETCONF clients. I assume there is just a running config, and if the edit-config or copy-config feature is advertised, the client converts that to the :writable-running capability. * It is not clear whether base:1.0 or base:1.1 protocol operation versions are used. * It is not clear if any YANG modules representing content are advertised. How does the client know what database contents are supported? * It is not clear if any existing capabilities, such as :partial-lock, :notifications, :with-defaults, etc., could be supported by the server, or if it is assumed this is not supported * It is not clear if a server could support custom RPC operations, or how a client would know about them. * There is no mention of the operation. I assume this is because the server only has a running config, and that config is always supposed to be valid. * If the server only has a running config, then makes no sense. Editorial: * sec. 3.1.1 has a cut-and-paste error about edit-config Andy From andy@netconfcentral.org Thu Jan 19 11:47: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 7D82121F85AC for ; Thu, 19 Jan 2012 11:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 sbXi4NieIlWE for ; Thu, 19 Jan 2012 11:47:29 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id D3E8721F8559 for ; Thu, 19 Jan 2012 11:47:28 -0800 (PST) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0JJlSKS026733 for ; Thu, 19 Jan 2012 14:47:28 -0500 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59676] helo=[192.168.0.9]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7F/7F-08454-F43781F4; Thu, 19 Jan 2012 14:47:28 -0500 Message-ID: <4F187350.2040500@netconfcentral.org> Date: Thu, 19 Jan 2012 11:47:28 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: NETCONF References: <4F17662E.3010209@netconfcentral.org> <20120119074356.GA31476@elstar.local> <4F17D64D.2050701@netconfcentral.org> <20120119090941.GA31884@elstar.local> <4F180B1E.2040402@netconfcentral.org> <20120119132941.GA33392@elstar.local> In-Reply-To: <20120119132941.GA33392@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 19:47:29 -0000 On 01/19/2012 05:29 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 19, 2012 at 04:22:54AM -0800, Andy Bierman wrote: > >> This isn't about SNMP. >> It is about using the YANG deviations that already exist for the >> purpose that they were designed for, or ignoring them, and producing >> new solutions that do not work with the existing standard. > > There is a standard that says: > > Deviations define the way a device or class of devices deviate from a > standard. This means that deviations MUST never be part of a > published standard, since they are the mechanism for learning how > implementations vary from the standards. > > We are compliant with that. ;-) > Why did we put that text in there? I argued for a more robust conformance model in YANG but lost that debate. All we have is "implement everything, or here is the list that flags you as non-compliant to all your competitors and customers". SMIv2 conformance allows for standard deviations ;-) >>> I prefer a yangcli that _upon_startup_ says "sorry the remote end does >>> not do NETCONF". Much better than a yangcli that fails badly in the >>> middle while I am trying to get a job done. And if yangcli gets >>> extended to support NETCONF Light, it can tell the user upon startup >>> that its talking to a NETCONF Light server and adapt the commands >>> offered to the user to what the server supports. Feature negotiation >>> is in my view much better than failing unexpectedly. Of course, your >>> mileage can vary. ... > There is no new hello exchange. We just announce a different version > of NETCONF - that has happened before. If NETCONF Light had a useful set of mandatory-implement functionality, I could see this approach being worthwhile: * A server MUST provide a writable, running configuration datastore * A server MUST NOT support the candidate or startup datastores * A server MUST advertise any NETCONF capability it supports, such as :xpath or :url * A server MUST support the , *, and operations. (* == not included in this requirement) * A server MUST advertise a YANG module capability for each module it supports * If or subtree filtering is supported, the :with-defaults basic-mode capability MUST be advertised > > /js > Andy From kwatsen@juniper.net Thu Jan 19 12:17: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 1401A21F854D for ; Thu, 19 Jan 2012 12:17:57 -0800 (PST) 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 RDOW0SdEji55 for ; Thu, 19 Jan 2012 12:17:56 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id EF42E21F853F for ; Thu, 19 Jan 2012 12:17:55 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTxh6cEfbLbLzy5OL5riKCKFuflo4L+zv@postini.com; Thu, 19 Jan 2012 12:17:56 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 19 Jan 2012 12:15:59 -0800 From: Kent Watsen To: Martin Bjorklund , Phil Shafer Date: Thu, 19 Jan 2012 12:15:57 -0800 Thread-Topic: [Netconf] quick comment on NETCONF Light draft Thread-Index: AczW1ImfIURnwWS2QJKYjT9H/aYkswAESRuw Message-ID: <84600D05C20FF943918238042D7670FD48A2332734@EMBX01-HQ.jnpr.net> References: <20120119.181917.159545890.mbj@tail-f.com> <201201191707.q0JH7d7G020733@idle.juniper.net> <20120119.184434.362930325.mbj@tail-f.com> <20120119.190235.431758737.mbj@tail-f.com> In-Reply-To: <20120119.190235.431758737.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 20:17:57 -0000 >Martin Bjorklund wrote: >> Right, this is a new protocol. Or rather a new version of NETCONF. >> Sort of. It uses the same port, same subsystem, I believe. Should we >> do a NETCONF 2.0 instead with a more modular approach to the >> operations? > > My own answer to this question: No, we shouldn't ;-) Agreed, as that wouldn't be backwards compatible. But an observation we ha= d was that this is how NETCONF should've been presented in the first place = and that "NETCONF Light", if given wings, has the potential of eclipsing NE= TCONF over time. To this end, I suggested renaming it to something that wo= uld better allow it serve that purpose it the future - that is, now we see = it as a light version of NETCONF, later it might be the primary protocol. From kwatsen@juniper.net Thu Jan 19 12:47:13 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3EF21F84FF for ; Thu, 19 Jan 2012 12:47:13 -0800 (PST) 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 XDq4Tjy7b4kp for ; Thu, 19 Jan 2012 12:47:13 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E421F8470 for ; Thu, 19 Jan 2012 12:47:13 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTxiBUNB0K0/JAFDmjf894EFU4dbGrKLF@postini.com; Thu, 19 Jan 2012 12:47:13 PST 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; Thu, 19 Jan 2012 12:42:54 -0800 From: Kent Watsen To: Phil Shafer , Andy Bierman Date: Thu, 19 Jan 2012 12:42:52 -0800 Thread-Topic: [Netconf] quick comment on NETCONF Light draft Thread-Index: AczW0PPOZ8VlthzzTxSZd/u9uajB6AAFj4NA Message-ID: <84600D05C20FF943918238042D7670FD48A2332779@EMBX01-HQ.jnpr.net> References: <4F184CBE.4070105@netconfcentral.org> <201201191705.q0JH5Bea020714@idle.juniper.net> In-Reply-To: <201201191705.q0JH5Bea020714@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 20:47:13 -0000 Phif Shafer writes: > When it goes to talk to the device, it's not interested in new > inventory/data model/capability information. It wants to perform > the RPCs given to it by the upper levels of its OSS brain. It > might use that data as a sanity check, but the content is already > in the pipeline and it's not going to change during the hello > phase. A couple comments on this aspect of the discussion: 1. Our NMS systems are heavily dependent on what devices present in their <= hello>. For instance, if the user right-clicks on a device in the UI, the = user-options are directly keyed off of what the device advertised. For ins= tance, if the device didn't advertize our vendor-specific "license" capabil= ity, the option to "View/Manage Licenses" would be grayed-out for that devi= ce. Likewise, if the device doesn't advertize support for configuration (i= .e. the :base capability), we disable the ability for the user to View/Mana= ge Configuration. 2. When pushing config to the device, our NMS systems pass down to their lo= wer-layers enough information for them to generate the messag= e to send to the device. We do this so that the upper-layers don't have to= be concerned with various combinations of optional capabilities devices ca= n present - both IETF's (:writable-running, :candidate, :confirmed-commit, = etc.) as well as our own (:rename, :ordered-list, :deactivate, :implicit-ch= ange, etc.). It's not the case the that upper-layer constructs the message= for the lower-layer to blindly push to the device. Thanks, Kent From andy@netconfcentral.org Thu Jan 19 13:02: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 4541121F85DB for ; Thu, 19 Jan 2012 13:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 vslHuuhnhyQI for ; Thu, 19 Jan 2012 13:02:20 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 91A5E21F85D4 for ; Thu, 19 Jan 2012 13:02:20 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0JL2Dwr014047 for ; Thu, 19 Jan 2012 16:02:15 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59722] helo=[192.168.0.9]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 47/5E-23837-5D4881F4; Thu, 19 Jan 2012 16:02:13 -0500 Message-ID: <4F1884D5.9070308@netconfcentral.org> Date: Thu, 19 Jan 2012 13:02:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kent Watsen References: <4F184CBE.4070105@netconfcentral.org> <201201191705.q0JH5Bea020714@idle.juniper.net> <84600D05C20FF943918238042D7670FD48A2332779@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48A2332779@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 21:02:21 -0000 On 01/19/2012 12:42 PM, Kent Watsen wrote: > > > Phif Shafer writes: >> When it goes to talk to the device, it's not interested in new inventory/data model/capability information. It wants to perform the RPCs given to it by the upper levels of its OSS brain. It >> might use that data as a sanity check, but the content is already in the pipeline and it's not going to change during the hello phase. > > > A couple comments on this aspect of the discussion: > > 1. Our NMS systems are heavily dependent on what devices present in their. For instance, if the user right-clicks on a device in the UI, the user-options are directly keyed off of what the > device advertised. For instance, if the device didn't advertize our vendor-specific "license" capability, the option to "View/Manage Licenses" would be grayed-out for that device. Likewise, if > the device doesn't advertize support for configuration (i.e. the :base capability), we disable the ability for the user to View/Manage Configuration. > Good! This is an important part of NETCONF. I like the 'big '. Its size scales with the device complexity so a tiny server will have a tiny message. If implemented correctly by the server, then 3rd party applications have some hope of supporting proprietary servers, even if it is 1 esoteric capability at a time. Allowing a client to key off a list of capability URIs is a big advance over the complete trial-and-error data silo approach of the past. (This all seems absent from NETCONF Light though.) > 2. When pushing config to the device, our NMS systems pass down to their lower-layers enough information for them to generate the message to send to the device. We do this so that > the upper-layers don't have to be concerned with various combinations of optional capabilities devices can present - both IETF's (:writable-running, :candidate, :confirmed-commit, etc.) as well as > our own (:rename, :ordered-list, :deactivate, :implicit-change, etc.). It's not the case the that upper-layer constructs the message for the lower-layer to blindly push to the device. > > Thanks, Kent > > > Andy From kwatsen@juniper.net Thu Jan 19 15:13: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 2040721F86E8 for ; Thu, 19 Jan 2012 15:13:45 -0800 (PST) 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 jLBRvkYt2w9a for ; Thu, 19 Jan 2012 15:13:44 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4642A21F8565 for ; Thu, 19 Jan 2012 15:13:44 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTxijmoJ7Ff72djRlSeXA/0ScR3U2GCFm@postini.com; Thu, 19 Jan 2012 15:13:44 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 19 Jan 2012 15:11:34 -0800 From: Kent Watsen To: Andy Bierman , Phil Shafer Date: Thu, 19 Jan 2012 15:11:33 -0800 Thread-Topic: [Netconf] quick comment on NETCONF Light draft Thread-Index: AczW38EY3PRyIaDXQb+i1W8bYD+q4gADaIZg Message-ID: <84600D05C20FF943918238042D7670FD48A23329A2@EMBX01-HQ.jnpr.net> References: <201201191707.q0JH7d7G020733@idle.juniper.net> <4F186D8C.9030904@netconfcentral.org> In-Reply-To: <4F186D8C.9030904@netconfcentral.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 23:13:45 -0000 > * A server does not have to implement anything, not even = . > NMS developers like to code only to mandatory-to-implement server feat= ures, > and there are none in NETCONF Light. I would think that an NMS coded to support NETCONF Light would support all = the operations, if it wishes to be competitive with other NMS offerings. B= ut this is a decision for the NMS vendor to make, to sink or swim - or mayb= e the NMS only desires to support the vendor's in-house devices... > * There is no mention of all the NETCONF capabilities like :candidate, > :writable-running, and :startup, which is very important > to NETCONF clients. I assume there is just a running config, and if t= he > edit-config or copy-config feature is advertised, the client converts = that to > the :writable-running capability. Section 3 says: A NETCONF Light implementation, like any NETCONF implementation, does not have to support any of the optional NETCONF capabilities. The normal NETCONF rules apply for the capability exchange with messages. A more explicit statement could be useful. > * It is not clear whether base:1.0 or base:1.1 protocol operation versio= ns are used. This may have been left out, but the intent was that NETCONF Light would sh= adow NETCONF revisions going forward. This release is the modularization o= f base/1.1. If ever there is a base/1.2 or base/2.0, we'd simultaneously r= elease a revision to NETCONF Light to support a modularized version of it. > * It is not clear if any YANG modules representing content are advertise= d. > How does the client know what database contents are supported? They may be (see above) > * It is not clear if any existing capabilities, such as :partial-lock, := notifications, > :with-defaults, etc., could be supported by the server, or if it is as= sumed > this is not supported They may be (see above) > * It is not clear if a server could support custom RPC operations, or ho= w a > client would know about them. They may be (see above). Actually, the first bullet-point in both Section = 2.2 and Appendix B directly address this case. > * There is no mention of the operation. I assume this is bec= ause the > server only has a running config, and that config is always supposed t= o be valid. All and any standard NETCONF capabilities may be advertized. The "descript= ion" in the YANG module says: "Advertizing all NETCONF Light features is equivalent to advertizing th= e NETCONF base capability itself." > * If the server only has a running config, then makes no= sense. This is an issue in the NETCONF protocol too, right? Kent From phil@juniper.net Thu Jan 19 18:27: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 DE91E21F858A for ; Thu, 19 Jan 2012 18:27:23 -0800 (PST) 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 rnxrlK-tJheD for ; Thu, 19 Jan 2012 18:27:23 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2C21F8584 for ; Thu, 19 Jan 2012 18:27:22 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTxjQ/jX86ZUURO1kUlf5h++Mj+Pn96Y9@postini.com; Thu, 19 Jan 2012 18:27:23 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 18:25:24 -0800 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 q0K2PN181954; Thu, 19 Jan 2012 18:25:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q0K1tj8H024138; Fri, 20 Jan 2012 01:55:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201201200155.q0K1tj8H024138@idle.juniper.net> To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD48A2332779@EMBX01-HQ.jnpr.net> Date: Thu, 19 Jan 2012 20:55:45 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] quick comment on NETCONF Light draft 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, 20 Jan 2012 02:27:24 -0000 Kent Watsen writes: >1. Our NMS systems are heavily dependent on what devices present in their < >hello>. For instance, if the user right-clicks on a device in the UI, the >user-options are directly keyed off of what the device advertised.... I make the assumption that when the user right clicks, the information being used to display the menu comes from local database, not from the device itself. You've reaped this data and recorded it locally. > It's not the case the that upper-layer constructs the message > for the lower-layer to blindly push to the device. "upper" and "lower" may be confusing here. My point is that you make the configuration before contacting the device. You use box data that you've recorded, not live from the device. The layers are typically: [ service oriented layer; knows what you are trying to do ] | v [ translation/adapter layer; knows how to turn service to device and vice versa] | v [ netconf library; knows the netconf protocols] This allows multiple adapters and multiple protocols, allowing your app to talk to many types of devices over many mgmt protocols. Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Jan 20 00:16: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 2CE2821F8615 for ; Fri, 20 Jan 2012 00:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 BWqWhbrIS-mr for ; Fri, 20 Jan 2012 00:15:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 950D421F85BD for ; Fri, 20 Jan 2012 00:15:56 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F310820BE3; Fri, 20 Jan 2012 09:15:53 +0100 (CET) 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 Zr2GQOQnRo-J; Fri, 20 Jan 2012 09:15:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4CDA20BE1; Fri, 20 Jan 2012 09:15:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F05731C93935; Fri, 20 Jan 2012 09:15:33 +0100 (CET) Date: Fri, 20 Jan 2012 09:15:33 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120120081533.GC35225@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , netconf@ietf.org References: <201201191707.q0JH7d7G020733@idle.juniper.net> <4F186D8C.9030904@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F186D8C.9030904@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 08:16:03 -0000 On Thu, Jan 19, 2012 at 11:22:52AM -0800, Andy Bierman wrote: > > Yes -- read the draft. > I just read it carefully, and it is hard to recognize what features of NETCONF > are actually retained in NETCONF Light. Thanks. Perhaps the document can improve. > Comments: > > * A server does not have to implement anything, not even . > NMS developers like to code only to mandatory-to-implement server features, > and there are none in NETCONF Light. Correct. Instead of making an arbitrary choice, we left it open, giving the WG something to discuss. :) > * There is no mention of all the NETCONF capabilities like :candidate, > :writable-running, and :startup, which is very important > to NETCONF clients. I assume there is just a running config, and if the > edit-config or copy-config feature is advertised, the client converts that to > the :writable-running capability. > * It is not clear whether base:1.0 or base:1.1 protocol operation versions are used. Count the references to RFC 6241 for that matter. I fail to see how someone can come to the conclusion NETCONF Light is based on RFC 4741. > * It is not clear if any YANG modules representing content are advertised. > How does the client know what database contents are supported? No change here. NETCONF Light really only modularizes the number of operations that must be supported and makes subtree filtering optional. > * It is not clear if any existing capabilities, such as :partial-lock, :notifications, > :with-defaults, etc., could be supported by the server, or if it is assumed > this is not supported See the document. > * It is not clear if a server could support custom RPC operations, or how a > client would know about them. No change from NETCONF as defined in RFC6241. > * There is no mention of the operation. I assume this is because the > server only has a running config, and that config is always supposed to be valid. Because validate is an optional capability anyway. > * If the server only has a running config, then makes no sense. Yes. The idea is that implementors will implement and advertise meaningful combinations of operations. > Editorial: > > * sec. 3.1.1 has a cut-and-paste error about edit-config Thanks, consider it fixed. /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 Fri Jan 20 02:15: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 B2AC521F8634 for ; Fri, 20 Jan 2012 02:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 WHdHjAV7DYB0 for ; Fri, 20 Jan 2012 02:15:51 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 060F821F8628 for ; Fri, 20 Jan 2012 02:15:50 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0KAFlwG003202 for ; Fri, 20 Jan 2012 05:15:49 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:60589] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 26/5F-11818-2DE391F4; Fri, 20 Jan 2012 05:15:47 -0500 Message-ID: <4F193ED3.2080407@netconfcentral.org> Date: Fri, 20 Jan 2012 02:15:47 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer , netconf@ietf.org References: <201201191707.q0JH7d7G020733@idle.juniper.net> <4F186D8C.9030904@netconfcentral.org> <20120120081533.GC35225@elstar.local> In-Reply-To: <20120120081533.GC35225@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] quick comment on NETCONF Light draft 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, 20 Jan 2012 10:15:51 -0000 On 01/20/2012 12:15 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 19, 2012 at 11:22:52AM -0800, Andy Bierman wrote: >> >> Yes -- read the draft. >> I just read it carefully, and it is hard to recognize what features of NETCONF >> are actually retained in NETCONF Light. > > Thanks. Perhaps the document can improve. > >> Comments: >> >> * A server does not have to implement anything, not even. >> NMS developers like to code only to mandatory-to-implement server features, >> and there are none in NETCONF Light. > > Correct. Instead of making an arbitrary choice, we left it open, > giving the WG something to discuss. :) The draft talks about tiny constrained devices like the kind CORE WG is addressing, but it also refers to big routers which just can't be bothered to implement NETCONF correctly as "constrained devices", and I don't agree with that part of the charter. The draft appears to be an server-centric attempt to lower the implementation bar to zero for servers, which lowers the functionality that an NMS developer can count on to zero as well. NMS developers do not like optional features that are only present on a subset of the devices they need to support. I don't see any reason for them to be interested in NETCONF Light if it has no guaranteed features. Andy > >> * There is no mention of all the NETCONF capabilities like :candidate, >> :writable-running, and :startup, which is very important >> to NETCONF clients. I assume there is just a running config, and if the >> edit-config or copy-config feature is advertised, the client converts that to >> the :writable-running capability. > >> * It is not clear whether base:1.0 or base:1.1 protocol operation versions are used. > > Count the references to RFC 6241 for that matter. I fail to see how > someone can come to the conclusion NETCONF Light is based on RFC 4741. > >> * It is not clear if any YANG modules representing content are advertised. >> How does the client know what database contents are supported? > > No change here. NETCONF Light really only modularizes the number of > operations that must be supported and makes subtree filtering > optional. > >> * It is not clear if any existing capabilities, such as :partial-lock, :notifications, >> :with-defaults, etc., could be supported by the server, or if it is assumed >> this is not supported > > See the document. > >> * It is not clear if a server could support custom RPC operations, or how a >> client would know about them. > > No change from NETCONF as defined in RFC6241. > >> * There is no mention of the operation. I assume this is because the >> server only has a running config, and that config is always supposed to be valid. > > Because validate is an optional capability anyway. > >> * If the server only has a running config, then makes no sense. > > Yes. The idea is that implementors will implement and advertise > meaningful combinations of operations. > >> Editorial: >> >> * sec. 3.1.1 has a cut-and-paste error about edit-config > > Thanks, consider it fixed. > > /js > From mehmet.ersue@nsn.com Fri Jan 20 09:39: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 4187B21F8677 for ; Fri, 20 Jan 2012 09:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=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 mqVcoVXDgbqI for ; Fri, 20 Jan 2012 09:39:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7112521F8562 for ; Fri, 20 Jan 2012 09:39:43 -0800 (PST) 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 q0KHdXZR032714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Jan 2012 18:39:39 +0100 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 q0KHdXZA019318 for ; Fri, 20 Jan 2012 18:39:33 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 18:39:33 +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: Fri, 20 Jan 2012 18:39:31 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64034A3A4D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for NETCONF WG Session in IETF 83 Thread-Index: AczXmnee2WvtxjJPQBG2BL5eSd+M5w== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 20 Jan 2012 17:39:33.0105 (UTC) FILETIME=[785ABE10:01CCD79A] Subject: [Netconf] Draft Agenda for NETCONF WG Session in IETF 83 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, 20 Jan 2012 17:39:44 -0000 Dear NETCONF WG, this is the draft agenda for the NETCONF session in IETF 83 so far. The agenda assumes that the related drafts will be submitted early=20 before deadline. It is a good practice and useful if the document authors start an=20 appropriate discussion on issues on the maillist. If there is any other point to discuss please send us your proposal=20 ASAP. Thanks. Mehmet & Bert Agenda for NETCONF WG Session -------------------------------------- IETF 83 - Paris France March 25-30, 2012 Date: ??? Time: ??? Room: ??? WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Non-chartered items: 1. NETCONF Over TLS update - RFC 5539bis http://tools.ietf.org/html/draft-badra-netconf-rfc5539bis (15 min.)=20 2. NETCONF over WebSocket - Tomoyuki Iijima (10 min.)=20 http://tools.ietf.org/html/draft-iijima-netconf-websocket-ps 3. NETCONF-Light - J. Schoenwaelder et. al. (10 min.) http://tools.ietf.org/html/draft-schoenw-netconf-light 4. NETCONF over BEEP and NETCONF over SOAP to historic - Bert&Mehmet (10 min). http://tools.ietf.org/html/draft-wijnen-beep-soap-to-historic (planned to submit before deadline) Open mike: . . . AOB From kwatsen@juniper.net Fri Jan 20 13:08: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 5BE1321F8589 for ; Fri, 20 Jan 2012 13:08:35 -0800 (PST) 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 FZrWblfNF3hm for ; Fri, 20 Jan 2012 13:08:34 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 2392821F8575 for ; Fri, 20 Jan 2012 13:08:34 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTxnXzdZpu5LQFZcwBnCdETxp/Z8sE2RF@postini.com; Fri, 20 Jan 2012 13:08:34 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 20 Jan 2012 13:06:05 -0800 From: Kent Watsen To: Phil Shafer Date: Fri, 20 Jan 2012 13:06:04 -0800 Thread-Topic: [Netconf] quick comment on NETCONF Light draft Thread-Index: AczXGsQ3hJlgo3P/TliZ2z0C730NQAAmjgaA Message-ID: <84600D05C20FF943918238042D7670FD48A23330D1@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD48A2332779@EMBX01-HQ.jnpr.net> <201201200155.q0K1tj8H024138@idle.juniper.net> In-Reply-To: <201201200155.q0K1tj8H024138@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] quick comment on NETCONF Light draft 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, 20 Jan 2012 21:08:35 -0000 Phil Shafer writes: > [ service oriented layer; knows what you are trying to do ] > | > v > [ translation/adapter layer; knows how to turn service to device and vice= versa] > | > v > [ netconf library; knows the netconf protocols] >=20 > This allows multiple adapters and multiple protocols, allowing your > app to talk to many types of devices over many mgmt protocols. Indeed, yes, this is what we do, but this came about because you stated: "To most of our clients, the hello is meaningless. The OSS system above = them knows what the server device is, has generated configuration for it, and= wants the client library to commit that code.". =20 This isn't our case, our client (the "netconf library" in your stack?) care= s about the . What the device advertises on each connection to the = NMS is used to guide the construction of the message pushed t= o the device. If we ever implement support for the system-notification dra= ft, we would additionally key off the "netconf-capability-change" event. Thanks, Kent From kwatsen@juniper.net Fri Jan 20 15:02: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 B51CA21F86AF for ; Fri, 20 Jan 2012 15:02:50 -0800 (PST) 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 kQdzzrR36XL1 for ; Fri, 20 Jan 2012 15:02:49 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 536BD21F86AB for ; Fri, 20 Jan 2012 15:02:49 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTxnymJHwZqgJ8fPYD2ZyleYSQJDQvt4u@postini.com; Fri, 20 Jan 2012 15:02:49 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 20 Jan 2012 15:00:30 -0800 From: Kent Watsen To: Andy Bierman , Phil Shafer , "netconf@ietf.org" Date: Fri, 20 Jan 2012 15:00:27 -0800 Thread-Topic: [Netconf] quick comment on NETCONF Light draft Thread-Index: AczXXIONArqXmFaYSta37Qy4ayphPQAYGHWw Message-ID: <84600D05C20FF943918238042D7670FD48A2AF17B1@EMBX01-HQ.jnpr.net> References: <201201191707.q0JH7d7G020733@idle.juniper.net> <4F186D8C.9030904@netconfcentral.org> <20120120081533.GC35225@elstar.local> <4F193ED3.2080407@netconfcentral.org> In-Reply-To: <4F193ED3.2080407@netconfcentral.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] quick comment on NETCONF Light draft 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, 20 Jan 2012 23:02:50 -0000 > The draft talks about tiny constrained devices like the kind CORE WG is a= ddressing, > but it also refers to big routers which just can't be bothered to impleme= nt > NETCONF correctly as "constrained devices", and I don't agree with that > part of the charter. The draft doesn't say that the devices can't be bothered, but that it's eit= her impossible or because the support must be phased in over time. Juniper= mandates all devices implement NETCONF, there's no question as to if, but = when. This is reality, things like locking are sometimes not possible to i= mplement and, likewise, it takes time to define schema for a data-model and= implement convertors to/from a native implementation. > The draft appears to be an server-centric attempt to lower the implementa= tion > bar to zero for servers, which lowers the functionality that an NMS devel= oper > can count on to zero as well. It's not an attempt to lower the implementation to zero, it's an attempt to= enable servers to advertise the subset they got working. We much prefer t= hey do this than either falsely claim everything's working or delay claimin= g they have anything working until everything is working. > NMS developers do not like optional features that are only present on > a subset of the devices they need to support. I don't see any reason > for them to be interested in NETCONF Light if it has no guaranteed featur= es. As a lead developer for NMS development at my company, I assure you that we= are interested in NETCONF Light, as it enables a formal mechanism for a de= vice to advertise the subset it supports. We don't have the luxury of wai= ting until a device's NETCONF implementation is 100%, we need NETCONF Light= to avoid inconsistency issues (such as from a device blindly returning for locking) and provide better user-experience (knowing up-front is bet= ter than keying off ) Thanks, Kent From andy@netconfcentral.org Fri Jan 20 16:39: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 D04A821F8522 for ; Fri, 20 Jan 2012 16:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 utMmuEcKz26t for ; Fri, 20 Jan 2012 16:39:34 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 2769321F8517 for ; Fri, 20 Jan 2012 16:39:32 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0L0dWo7013663 for ; Fri, 20 Jan 2012 19:39:32 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:39736] helo=[192.168.0.9]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 99/C5-23837-3490A1F4; Fri, 20 Jan 2012 19:39:32 -0500 Message-ID: <4F1A0943.2000601@netconfcentral.org> Date: Fri, 20 Jan 2012 16:39:31 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kent Watsen References: <201201191707.q0JH7d7G020733@idle.juniper.net> <4F186D8C.9030904@netconfcentral.org> <20120120081533.GC35225@elstar.local> <4F193ED3.2080407@netconfcentral.org> <84600D05C20FF943918238042D7670FD48A2AF17B1@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48A2AF17B1@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] quick comment on NETCONF Light draft 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, 21 Jan 2012 00:39:35 -0000 On 01/20/2012 03:00 PM, Kent Watsen wrote: > >> The draft talks about tiny constrained devices like the kind CORE WG is addressing, >> but it also refers to big routers which just can't be bothered to implement >> NETCONF correctly as "constrained devices", and I don't agree with that >> part of the charter. > > The draft doesn't say that the devices can't be bothered, but that it's either impossible or because the support must be phased in over time. Juniper mandates all devices implement NETCONF, there's no question as to if, but when. This is reality, things like locking are sometimes not possible to implement and, likewise, it takes time to define schema for a data-model and implement convertors to/from a native implementation. > > >> The draft appears to be an server-centric attempt to lower the implementation >> bar to zero for servers, which lowers the functionality that an NMS developer >> can count on to zero as well. > > It's not an attempt to lower the implementation to zero, it's an attempt to enable servers to advertise the subset they got working. We much prefer they do this than either falsely claim everything's working or delay claiming they have anything working until everything is working. > > >> NMS developers do not like optional features that are only present on >> a subset of the devices they need to support. I don't see any reason >> for them to be interested in NETCONF Light if it has no guaranteed features. > > As a lead developer for NMS development at my company, I assure you that we are interested in NETCONF Light, as it enables a formal mechanism for a device to advertise the subset it supports. We don't have the luxury of waiting until a device's NETCONF implementation is 100%, we need NETCONF Light to avoid inconsistency issues (such as from a device blindly returning for locking) and provide better user-experience (knowing up-front is better than keying off) > > You could do this today with YANG deviations if you wanted. Implementation issues like blindly returning for locking should be fixed. At least return operation-not-supported. Hiding an rpc-error from the user is just an implementation detail. The difference between printing "operation not supported", before vs. after an RPC request, is not a compelling reason to start a new version of NETCONF. I don't think there is enough standards value in this draft to be worth implementing, but I'll shut up now since others appear to want to implement it. > Thanks, > Kent > Andy From andy@netconfcentral.org Mon Jan 23 09:44: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 5201821F8664 for ; Mon, 23 Jan 2012 09:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 23rd0Gy0D09a for ; Mon, 23 Jan 2012 09:44:11 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC021F8661 for ; Mon, 23 Jan 2012 09:44:11 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q0NHiBlf018241 for ; Mon, 23 Jan 2012 12:44:11 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:46905] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 82/E4-05356-A6C9D1F4; Mon, 23 Jan 2012 12:44:11 -0500 Message-ID: <4F1D9C6C.9040200@netconfcentral.org> Date: Mon, 23 Jan 2012 09:44:12 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Phil Shafer References: <201201191707.q0JH7d7G020733@idle.juniper.net> In-Reply-To: <201201191707.q0JH7d7G020733@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] quick comment on NETCONF Light draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:44:12 -0000 On 01/19/2012 09:07 AM, Phil Shafer wrote: > Martin Bjorklund writes: >> And of course, the new SSH framing scheme in 6242 is dependent on the >> hello message. >> >> I can easily imagine another design w/o a big hello message that would >> achieve the same goals (minimal hello + mandatory rpc), but I don't >> think it is worth the trouble changing it, especially not in NC/light. > > I guess I should go read the draft, since it seems like if we're > not worrying with backward compatibility, then removing the hello > and forcing the new framing protocol would be a great outcome. > you are sort of raising 2 new issues. 1) I like the idea of a 'short' hello and an RPC to get the full hello. The server would send just the session-id + NETCONF Light capability + a capability that had an opaque string ID that represented its current set of capabilities. (Every sys-capability-change event causes the server to change this string to a new unused value.) The client caches the 'capability-id' capability and only needs to call if the string changed value. But a full base:1.1 server needs this feature as well. The bigger the server, the more capability URIs there are. 2) framing Base:1.1 servers already have the option of rejecting a base:1.0 session request, and only supporting the new framing. We MUST keep the old EOM after the hello hack because the client may not know for sure what version server is listening on port 830, so the protocol needs to remain the same wrt/ SSH framing for the message. > Thanks, > Phil > > Andy From mehmet.ersue@nsn.com Tue Jan 31 05:55: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 52FA121F8601 for ; Tue, 31 Jan 2012 05:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_46=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 2HGtqhoLBLfl for ; Tue, 31 Jan 2012 05:55:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 813CF21F85F4 for ; Tue, 31 Jan 2012 05:55:22 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0VDtK6Y023719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 31 Jan 2012 14:55:20 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0VDtK6O014343 for ; Tue, 31 Jan 2012 14:55:20 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 14:55:20 +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, 31 Jan 2012 14:55:20 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640356407E@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64034A3A4D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for NETCONF WG Session in IETF 83 Thread-Index: AczXmnee2WvtxjJPQBG2BL5eSd+M5wIhOGWg References: <80A0822C5E9A4440A5117C2F4CD36A64034A3A4D@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 31 Jan 2012 13:55:20.0620 (UTC) FILETIME=[F897AEC0:01CCE01F] Subject: Re: [Netconf] Draft Agenda for NETCONF WG Session in IETF 83 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, 31 Jan 2012 13:55:23 -0000 Hi All, the draft agenda for the IETF 83 NETCONF session is now at: http://www.ietf.org/proceedings/83/agenda/netconf.txt=20 I would like to ask the listed draft authors to meet the submission=20 deadlines: 2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -8), upload using IETF ID Submission Tool. 2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT (UTC -7), upload using IETF ID Submission Tool. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > Ersue, Mehmet (NSN - DE/Munich) > Sent: Friday, January 20, 2012 6:40 PM > To: Netconf > Subject: [Netconf] Draft Agenda for NETCONF WG Session in IETF 83 >=20 > Dear NETCONF WG, >=20 > this is the draft agenda for the NETCONF session in IETF 83 so far. > The agenda assumes that the related drafts will be submitted early > before deadline. >=20 > It is a good practice and useful if the document authors start an > appropriate discussion on issues on the maillist. >=20 > If there is any other point to discuss please send us your proposal > ASAP. Thanks. >=20 > Mehmet & Bert >=20 >=20 > Agenda for NETCONF WG Session > -------------------------------------- >=20 > IETF 83 - Paris France > March 25-30, 2012 >=20 > Date: ??? > Time: ??? > Room: ??? >=20 >=20 > WG Chairs: > Bert Wijnen > Mehmet Ersue >=20 > Scribes (IF no_volunteers THEN wait_forever) > Agenda bashing (2 minutes) > WG status review (5 minutes) >=20 > Non-chartered items: >=20 > 1. NETCONF Over TLS update - RFC 5539bis > http://tools.ietf.org/html/draft-badra-netconf-rfc5539bis (15 > min.) >=20 > 2. NETCONF over WebSocket - Tomoyuki Iijima (10 min.) > http://tools.ietf.org/html/draft-iijima-netconf-websocket-ps >=20 > 3. NETCONF-Light - J. Schoenwaelder et. al. (10 min.) > http://tools.ietf.org/html/draft-schoenw-netconf-light >=20 > 4. NETCONF over BEEP and NETCONF over SOAP to historic - > Bert&Mehmet (10 min). > http://tools.ietf.org/html/draft-wijnen-beep-soap-to-historic > (planned to submit before deadline) >=20 > Open mike: > . . . >=20 > AOB > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf