From mehmet.ersue@nsn.com Sun May 3 12:47:09 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D3E3A6F75; Sun, 3 May 2009 12:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkGOZ-x3v2ew; Sun, 3 May 2009 12:47:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 40D7128C1D5; Sun, 3 May 2009 12:46:05 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n43JlRdh032560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 May 2009 21:47:27 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n43JlRjs013028; Sun, 3 May 2009 21:47:27 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 21:47:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 May 2009 21:47:24 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt toProposed Standard thread-index: AcnHFqLCVujhgKtmRBaqBathBFTbowABE7bwAUL6wGA= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 03 May 2009 19:47:26.0380 (UTC) FILETIME=[FC3396C0:01C9CC27] Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [OPS-DIR] FW: Evaluation: draft-thomson-beep-async-02.txt toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 19:47:10 -0000 Hi Dan, I reviewed the document draft-thomson-beep-async-02.txt in general and for its operational impact. Summary:=20 The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes an BEEP feature that enables asynchrony for individual channels. Review summary: The draft is an extension feature to the BEEP (Blocks Extensible Exchange Protocol) protocol. BEEP provides already asnychrony based on pipelining (intra-channel) and parallelism (inter-channel). This documents provides a feature as an extension to BEEP, that enables the creation of an asynchronous channel, which is not limited to pipelining. I.e. a serving peer can process requests and respond in any order. The document aims to become a proposed standard RFC but there is no discussion on why an asynchronous channel is really needed additional to the already existing asynchrony mechanisms in the original BEEP protocol, IOW why are the existing mechanisms are not sufficient. The documents claims the necessity but there are also no examples of applications which would need the described mechanism. =20 Although the document introduces additional state information which needs to be stored and managed it does not discuss scalability sufficiently. The document also does not introduce a configurable parameter for the 'maximum count of allowed parallel asynchronous channels'.=20 Also the document misses to disscuss what happens when a response does not follow a request, i.e. is missing the exception handling thereafter. Configurability in general has not been discussed in the document.=20 Performance considerations have not been discussed in the document.=20 The reviewer couldn't find the mail archive at the URL given in the concluded BEEP WG charter page. The current maillist seems to be linked on www.beepcore.org and the "asynchronous BEEP" thread is under: http://groups.google.com/group/beepwg/browse_thread/thread/db0255c634c7e b0c/982e385e39fef215?lnk=3Dgst&q=3D+Asynchronous+BEEP#982e385e39fef215 The document shepherding info states that are a few seconders on the maillist. The reviewer of the document found a lot of mails questioning the sense of such an extension to the BEEP protocol (see URL above, e.g. "Anyways, reading through the draft, I think one reason I am resistant to this feature is that I do not fully understand when it would better than the alternatives."). Review Questions: Is the document readable? Yes. Does it contain nits? Yes (see below).=20 Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to = have RFC 2119 boilerplate text. =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, = but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 Is the document class appropriate? No. I would have nothing against such an extension if it would be Informational. I do not think this is a really necessary and long-awaited standard feature. Is the problem well stated? The mechanism has been described to some extent but exception handling and scalability discussion is not sufficient. Is the problem really a problem? The reviewer is not sure whether this feature is really needed as a standard. The necessity of the feature has been also questioned on the maillist. Does the document consider existing solutions? Obviously, there are a few products using BEEP (http://www.beepcore.org/products.html). The reviewer would like to see some use cases asking for the mechanism and requirements from BEEP users. Does the solution break existing technology? No. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Configuration parameters are not discussed in the document. Additional parameters supporting scalability would be interesting to have. Can performance be measured? How? Performance considerations have not been discussed in the document.=20 Does the solution scale well? A configurable parameter for the 'maximum count of allowed parallel asynchronous channels' would support scalability.=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: ops-dir-bounces@ietf.org=20 > [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext Romascanu,=20 > Dan (Dan) > Sent: Monday, April 27, 2009 11:32 AM > To: aaa-doctors@ietf.org; ops-dir@ietf.org; netconf@ietf.org > Subject: [OPS-DIR] FW: Evaluation:=20 > draft-thomson-beep-async-02.txt toProposed Standard >=20 >=20 > =20 >=20 >=20 > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-thomson-beep-async-0 > 2.txt-02.t > xt >=20 > Technical Summary >=20 > The Blocks Extensible Exchange Protocol (BEEP) provides a protocol > framework for the development of application protocols. This > document describes a BEEP feature that enables asynchrony for > individual channels. >=20 > Working Group Summary >=20 > This is an individual submission. >=20 > Document Quality >=20 > This was reviewed on the mailing list for the concluded BEEP WG. > There was moderate controversy about whether this extension was > needed as it is possible to work-around the lack of this feature > in BEEP at the next layer up. No other technical objections were > raised and there was explicit support from several parties. > At least one open source BEEP library implementation has agreed > to implement this extension. >=20 > Personnel >=20 > Chris Newman is the document shepherd. This has been reviewed for > the >=20 >=20 > IESG by Alexey Melnikov. Marshall Rose and other=20 > participants of the > BEEP WG mailing list reviewed this proposal. >=20 > RFC Editor Note >=20 > (Insert RFC Editor Note here or remove section) >=20 > IANA Note >=20 > (Insert IANA Note here or remove section) >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 From mbj@tail-f.com Sun May 3 13:20:20 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E73F3A6AB7 for ; Sun, 3 May 2009 13:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F1u2v1cU9Ry for ; Sun, 3 May 2009 13:20:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 93EAD3A7117 for ; Sun, 3 May 2009 13:20:19 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E796616032; Sun, 3 May 2009 22:21:44 +0200 (CEST) Date: Sun, 03 May 2009 22:21:44 +0200 (CEST) Message-Id: <20090503.222144.15510138.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49F9C1CF.9050106@netconfcentral.com> References: <20090430.155908.05601603.mbj@tail-f.com> <49F9C1CF.9050106@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - error-type X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 20:20:20 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > The error-type is defined as: > > error-type: Defines the conceptual layer that the error occurred. > > But the error-type values do not match the names of the conceptual > > layers in the picture in 1.1. > > error-type layer > > ---------- ----- > > transport transport protocol > > rpc rpc > > protocol operations > > application content > > Proposal: add this clarification. > > This means that if the error-type is 'rpc', the error happened in the > > "rpc" layer, i.e. in the element in the XML. > > The error list in Appendix A lists the error 'unknown-element', which > > can have error-type 'rpc' according to its specification. But what > > kind of XML would generate such an error in an rpc-reply? If the > > element was received, any subelements are on the > > protocol/operations layer. If some element except for is > > received, an cannot be generated. > > The same question applies to the errors 'unknown-namespace', > > 'operation-not-supported' and 'operation-failed', and maybe > > 'access-denied'. > > Comments? > > > > Not sure what OLD and NEW text is being proposed. > There are errors that can occur while processing > the element, such as resource-denied. In general, I think we should go through the error list and make sure that each error-type is correct wrt the error. In particular, I think 'rpc' should be removed from the errors listed above. /martin From Washam.Fan@huaweisymantec.com Sun May 3 18:50:38 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB963A6B24 for ; Sun, 3 May 2009 18:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMHKz2AVVkDI for ; Sun, 3 May 2009 18:50:38 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id D0DB63A710A for ; Sun, 3 May 2009 18:50:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ300AYPJUDC830@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 04 May 2009 09:51:51 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ300IX5JUBLP10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 04 May 2009 09:51:49 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 04 May 2009 09:51:47 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 04 May 2009 09:51:47 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <49F9C24F.6090702@netconfcentral.com> References: <20090430.160141.138853286.mbj@tail-f.com> <49F9C24F.6090702@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - error-path X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 01:50:39 -0000 > Martin Bjorklund wrote: > > Hi, > > > > The element is defined as > > > > Contains the absolute XPath [2] expression identifying > > the element path to the node that is associated with the error > > being reported in a particular rpc-error element. This element > > will not be present if no appropriate payload element can be > > associated with a particular error condition, [...] > > > > It is not clear what the root node is in this XPath expression, but > > from the text above which talks about "payload", it seems the root > > node must be /rpc. > > > > But this means that an operation like this: > > > > > > > > > > > > > > > > > > > > which may detect errors in the data store cannot use to > > refer to invalid elements in the candidate config. > > > > Is the intention that such data store errors should be data model > > specific and out of scope for this document? > > > > > > Can the draft say that the error-path 'stops' at the appropriate > node, based on the input. If the error node is in the RPC input > section, then the error-path will start with /rpc. Otherwise > it will start with a top-level element from some YANG module. Yes, that makes sense to me. washam > > /martin > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Sun May 3 19:09:04 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7CA3A6A46 for ; Sun, 3 May 2009 19:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FttovDZLfPOe for ; Sun, 3 May 2009 19:08:56 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 9FE553A63D3 for ; Sun, 3 May 2009 19:08:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ300A6JKOXC840@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 04 May 2009 10:10:11 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ300IYSKOVLP10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 04 May 2009 10:10:09 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 04 May 2009 10:10:07 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 04 May 2009 10:10:07 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <49F9C2E4.5000709@netconfcentral.com> References: <20090430.160226.69975872.mbj@tail-f.com> <49F9C2E4.5000709@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - error-severity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 02:09:04 -0000 > Martin Bjorklund wrote: > > Hi, > > > > is defined to be 'error' or 'warning'. In the list > > of errors in Appendix A, 'warning' never occurs. > > > > Also, according to the XSD, and cannot be returned > at > > the same time, so there is no way to return and a warning at the > > same time. > > > > There are three alternatives: > > > > 1. remove warning > > > > 2. fix warning so that it works > > > > 3. keep warning but clarify that it doesn't work > > > > > > Comments? > > > > Does anybody actually implement any warnings? > If not, then (1) is good. > > In order to choose (2), we would have to understand > what we mean by a 'warning', and write it down. > Maybe if we did that the first time, we would have > tossed this error-severity field. > I personally prefer (2). warnings are not errors, but they may lead to errors. For example, 'capabilities-changed' is more a warning than error, IMO. For affected operations, it is not the direct reason why they failed ( the direct reason would be 'operation-not-supported' or 'data-missing', etc) whileas for unaffected operations, it is only a warning, and should be returned with . Please refer to http://www.ietf.org/mail-archive/web/netconf/current/msg04493.html ( I think this email has been ignored ) washam > > > > /martin > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Sun May 3 19:34:53 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A6B3A69C4 for ; Sun, 3 May 2009 19:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Sd6St+q+TJ5 for ; Sun, 3 May 2009 19:34:51 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id B7E6B3A6834 for ; Sun, 3 May 2009 19:34:50 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ300AH2LW3C840@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 04 May 2009 10:36:05 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ300K11LW1JW20@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 04 May 2009 10:36:03 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 04 May 2009 10:36:01 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Mon, 04 May 2009 10:36:01 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090430.160342.82409955.mbj@tail-f.com> References: <20090430.160342.82409955.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - data stores X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 02:34:54 -0000 > Hi, > > There has been some discussion whether different combinations of > capabilities are allowed or not. A clarification could be that we > explicitly state that any combination is allowed unless otherwise > stated. > > One such combination is :confimed-commit and :startup. The text on > :confimed-commit says: > > If the device reboots for any reason before the confirm timeout > expires, the server MUST restore the configuration to its state > before the confirmed commit was issued. > > But this seems to contradict the fact that the startup configuration > is used when the device boots. I don't see the contradictory. If the device reboots unexpectedly in that case, (even ) has not reflected the changes yet, and the server should be in the state before the confirmed commit was issued after has been loaded. But the point is which datastore the configuration here refers to? candidate? > Proposal: > > Describe that the startup configuration is used also in this case. > > This means that if the client wants to make a config change > persistent when using the candidate and confirmed commit on a device > which also has startup, it needs to: > > commit confirmed > > commit > copy running to startup > Yes, I think so. But what if there is an error or accident encontered when syncing startup to running? what would it look like when it reboots in that case? (Maybe it is another issue) washam > Comments? > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mbj@tail-f.com Mon May 4 00:33:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC53F3A6782 for ; Mon, 4 May 2009 00:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob5PECmQWpr9 for ; Mon, 4 May 2009 00:33:50 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9CFB43A69D0 for ; Mon, 4 May 2009 00:33:49 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id ED42D616005; Mon, 4 May 2009 09:35:11 +0200 (CEST) Date: Mon, 04 May 2009 09:35:11 +0200 (CEST) Message-Id: <20090504.093511.126952205.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090430.160342.82409955.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - data stores X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:33:50 -0000 Hi, WashamFan wrote: > > Hi, > > > > There has been some discussion whether different combinations of > > capabilities are allowed or not. A clarification could be that we > > explicitly state that any combination is allowed unless otherwise > > stated. > > > > One such combination is :confimed-commit and :startup. The text on > > :confimed-commit says: > > > > If the device reboots for any reason before the confirm timeout > > expires, the server MUST restore the configuration to its state > > before the confirmed commit was issued. > > > > But this seems to contradict the fact that the startup configuration > > is used when the device boots. > > I don't see the contradictory. If the device reboots unexpectedly in that > case, (even ) has not reflected the changes yet, and > the server should be in the state before the confirmed commit was issued > after has been loaded. > > But the point is which datastore the configuration here refers to? candidate? It refers to 'running', which makes the contradiction. If startup is not present, the confimred commit modifies running. If the box reboots before the confirming commit is given, running is reverted to its state before the confirmed commit. If startup is present, and the box reboots, running will be initialized from startup, and it will (may) not be equal to what it was before the confirmed commit. /martin From balazs.lengyel@ericsson.com Mon May 4 01:01:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E9A3A6ABA for ; Mon, 4 May 2009 01:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqWAv9MmbFFJ for ; Mon, 4 May 2009 01:01:43 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C504A3A69CC for ; Mon, 4 May 2009 01:00:48 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-63-49fea104240b Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 31.7D.19078.401AEF94; Mon, 4 May 2009 10:02:13 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 10:02:12 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 10:02:12 +0200 Message-ID: <49FEA103.5060309@ericsson.com> Date: Mon, 04 May 2009 10:02:11 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090430.155707.34413266.mbj@tail-f.com> In-Reply-To: <20090430.155707.34413266.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2009 08:02:12.0279 (UTC) FILETIME=[A171EC70:01C9CC8E] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis - validate X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 08:01:50 -0000 test-only should be included, so 2 or 3 is my vote. Balazs Martin Bjorklund wrote: > Hi, > > This is the first of a couple of emails identifying some open issues > for 4741 bis. I will do more some other day. > > > The problem is that it is unclear if with inline config > must be a complete config or some kind of "partial" config. As has > been discussed earlier on the list and most recently in S.F., the way > it is defined, it must be a complete config. > > A related problem is that inline validation of a complete config is > not very useful in real life (see > e.g. http://ops.ietf.org/lists/netconf/netconf.2006/msg01229.html). > > Because of this, some implementations support a 'test-only' option to > edit-config > (http://ops.ietf.org/lists/netconf/netconf.2006/msg01206.html), which > can be used to validate partial edits to a given data store. > > There are a couple of alternatives: > > 1. Keep :validate 1.0 as it is, and clarify that inline config must be > a complete config. > > 2. As 1 + add a :validate 1.1 which adds the 'test-only' option. > A server can advertise both 1.0 and 1.1 if it wants to. > > 3. Just describe a :validate 1.1 which adds the 'test-only' option > and removes the inline config option. > > > If 1 is choosen, 'test-only' could be added in a separate capability > in another document. > > Comments? > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From dromasca@avaya.com Mon May 4 09:19:48 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F34C3A6927; Mon, 4 May 2009 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpdsCsHhjtqb; Mon, 4 May 2009 09:19:47 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D215D3A6358; Mon, 4 May 2009 09:19:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238990400"; d="scan'208";a="160271775" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 04 May 2009 12:21:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 May 2009 12:21:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 18:21:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XML Schema Definition Language (XSD) 1.1 a Candidate Recommendation (Call for Implementations) Thread-Index: AcnM0j54z7w/lRXJQECRYBDIMOGZXQAAebLw From: "Romascanu, Dan (Dan)" To: , Subject: [Netconf] FW: XML Schema Definition Language (XSD) 1.1 a Candidate Recommendation (Call for Implementations) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:19:48 -0000 =20 This announcement from W3C may be of interest for NETMOD and NETCONF.=20 Regards, Dan --------------------------- I am pleased to announce that XML Schema Definition Language (XSD) is a Candidate Recommendation: W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/ W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/ The approval and publication are in response to this transition request: http://lists.w3.org/Archives/Member/chairs/2009AprJun/0030 For the disposition of Last Call comments see: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Apr/0051 There were no Formal Objections. Patent disclosures relevant to this specification may be found on the XML Schema Working Group Working Group's patent disclosure page in conformance with W3C policy: http://www.w3.org/2004/01/pp-impl/19482/status The XML Schema Working Group Working Group expects to receive more comments in the form of implementation feedback and test cases. The Working Group does not expect to have satisfied its implementation criteria before 3 August 2009. See below for the group's "exit criteria." This Call for Implementations follows section 7.4.3 of the W3C Process Document: http://www.w3.org/2005/10/Process-20051014/tr#cfi Thank you, For Tim Berners-Lee, Director, and Liam Quin, XML Activity Activity Lead; Ian Jacobs, Head of W3C Communications =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Exit Criteria The Working Group does not plan to request transition to Proposed Recommendation until the following criteria are satisfied: 1) The XML Schema Test Suite (http://www.w3.org/XML/2004/xml-schema-test-suite/index.html) has been updated to include tests which cover all the new or changed features of these specifications since XML Schema 1.0 (Second Edition); 2) Each feature in the specifications has received two interoperable implementations as demonstrated by test suite results. These specifications contain a number of features identified by the Working Group as "Features at Risk" -- depending on implementation feedback and other input, they may be removed from the subsequent Proposed Recommendations without requiring a return to Last Call. In particular, the decision with respect to the new precisionDecimal datatype included in XML Schema 1.1 Part 2: Datatypes, which is a Feature at Risk, will depend not only on the existence of two demonstrably interoperable implementations and other feedback, but also "on the degree of uptake of [IEEE 754-2008] in the industry". Evidence of uptake to be taken into consideration will likely include support from hardware manufacturers and availability of supporting libraries for programming languages and tools, particularly when such libraries are part of standard distributions. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Quoting from the XML Schema 1.1 W3C Candidate Recommendations - 30 April 2009 Abstract (from http://www.w3.org/TR/xmlschema11-1/) -------- This document specifies the XML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends on XML Schema Definition Language 1.1 Part 2: Datatypes. Abstract (from http://www.w3.org/TR/xmlschema11-2/) -------- XML Schema: Datatypes is part 2 of the specification of the XML Schema language. It defines facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. The datatype language, which is itself represented in XML, provides a superset of the capabilities found in XML document type definitions (DTDs) for specifying datatypes on elements and attributes. Status of This Document (from both documents, leaving out ----------------------- some boilerplate and detailed change listing) This W3C Candidate Recommendation specifies W3C XML Schema Definition Language (XSD) 1.1. It is here made available for review by W3C members and the public. XSD 1.1 retains all the essential features of XSD 1.0, but adds several new features to support functionality requested by users, fixes many errors in XSD 1.0, and clarifies wording. For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (non-normative) is the recommended starting point. It summarizes both changes made since XSD 1.0 and some changes which were expected (and predicted in earlier drafts of this specification) but have not been made after all. Accompanying versions of this document display in color all changes to normative text since version 1.0 and since the previous Working Draft. The Candidate Recommendation review period for this document extends until 3 August 2009. Comments on this document should be made in W3C's public installation of Bugzilla, specifying "XML Schema" as the product. Instructions can be found at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (Public archive at http://lists.w3.org/Archives/Public/www-xml-schema-comments/) Each Bugzilla entry and email message should contain only one comment. Although feedback based on any aspect of this specification is welcome, there are certain aspects of the design presented herein for which the Working Group is particularly interested in feedback. These are designated "priority feedback" aspects of the design, and identified as such in editorial notes at appropriate points in this draft. Any feature mentioned in a priority feedback note is a "feature at risk": the feature may be retained as is or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors. The W3C XML Schema Working Group intends to request advancement of this specification and publication as a Proposed Recommendation (possibly with editorial changes, and possibly removing features identified as being at risk) as soon after 3 August 2009 as the following conditions are met. * A test suite is available which tests each required and optional feature of XSD 1.1. * Each feature of the specification has been implemented successfully by at least two independent implementations. * The Working Group has responded formally to all issues raised against this document during the Candidate Recommendation period. At the time this Candidate Recommendation was published, no interoperability or implementation report had yet been prepared. This document has been produced by the W3C XML Schema Working Group (http://www.w3.org/XML/Schema.html) as part of the W3C XML Activity (http://www.w3.org/XML/). The goals of XSD 1.1 are discussed in the document Requirements for XML Schema 1.1 (http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/). The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group (http://www.w3.org/2004/01/pp-impl/19482/status); that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. [1] http://www.w3.org/2009/04/29-xmlschema-minutes.html#item07 -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 From MARKSCOT@nortel.com Mon May 4 09:53:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9348128C0E2 for ; Mon, 4 May 2009 09:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ+wFWol1qXs for ; Mon, 4 May 2009 09:53:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6C0FD28C0E1 for ; Mon, 4 May 2009 09:53:40 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n44Gs7o24916; Mon, 4 May 2009 16:54:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 12:54:55 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC030A609E@zcarhxm0.corp.nortel.com> In-reply-to: <20090415.141217.59541259.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] dynamic capabilities Thread-Index: Acm9w3ZORAVNJ4jBTauq+s1jQn0IqQPDxmVg References: <20090407170549.GA29864@elstar.local><20090414.081508.215323178.mbj@tail-f.com><49E44535.8000704@ericsson.com> <20090415.141217.59541259.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:53:41 -0000 Martin and Balazs, Suggest we allow for an explicit client re-synch as an alternative to forcing the session to be closed: The capabilities of a NETCONF server MAY change over time. However, once a NETCONF server has announced its capabilities in the message, the capabilities for that session SHOULD NOT change unless=20 the server supports the change and the client has requested the revised capabilities for that session. Once a server has modified its capabilities: A server MUST reply with a 'capabilities-changed' error if the client sends a request which is affected by a modified capability. A server MAY choose to send 'capabilities-changed' as the response to any request other than if its capabilities has changed. A server MAY stop sending 'capabilities-changed' to a specific session after a response has been sent to that session. This gives flexibility to preserve a session in cases where a dynamic change (e.g. feature activation adds new model, hitless patch revs an interface, etc) can be supported (or ignored) by both server and client. Server can allow a specific client to continue if it explicitly requests the revised capabilities. Server can also force any session closure by always replying 'capabilities-changed' even if the client requested . I think this approach would address the concerns raised on this issue and allows for either simple implementations (force session close) or more sophisticated (clear the error on synch). Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Wednesday, April 15, 2009 8:12 AM To: balazs.lengyel@ericsson.com Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities Balazs Lengyel wrote: >=20 >=20 > Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> I believe it depends on the nature of a given capability change > >> whether this should cause a reaction in terms or an error state or can > >> be ignored. And to keep implementation costs reasonable, I believe the > >> server wants to decided based on the semantics of the capability > >> change whether it (a) does nothing or (b) signals the capability > >> change by throwing capability change errors. Having only certain > >> affected operations fail seems like a lot of complexity on the server > >> side which will likely no honored on the client side.=20 > > Agreed. > >=20 > >> This actually sounds a little bit like the defaults debate; perhaps > >> the answer is to let the client tell the server which behaviour the > >> client wants... > > I don't think we should use :with-default as a blueprint for other > > capabilities, if we can avoid it... It adds complexity to the system > > ("system" as in clients and servers). > > In this particular case I hope we can find a simpler solution. My > > proposal is to specify the error 'capabilities-changed', but let the > > server itself decide if it will issues it just for affected > > operations, or for all operations. > >=20 > Sound nice to me. So is the following text what we are looking for: >=20 > The capabilities of a NETCONF server may change during a NETCONF session. If > capabilities change, the server MAY answer any RPC request with a > 'capabilities-changed' error message; except the > request. Unless the server can assure that the capability change does not > affect a specific RPC request, it MUST answer the requests with a > 'capabilities-changed' error message. Hm. IMO the point of sending 'capabilities-changed' error is because we want to make sure that the announced capabilities does NOT change in a session. So I would rather see something like: The capabilities of a NETCONF server may change over time. However, once a NETCONF server has announced its capabilities in the message, the capabilities for that session MUST NOT change. A server MUST reply with a 'capabilities-changed' error if the client sends a request which is affected by a modified capability. And maybe add: A server MAY choose to send 'capabilities-changed' as the response to any request other than if its capabilities has changed. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Tue May 5 01:43:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC3D3A6BA9 for ; Tue, 5 May 2009 01:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTX9hAgYg5KW for ; Tue, 5 May 2009 01:43:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 000713A69F7 for ; Tue, 5 May 2009 01:43:07 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 412DE616021; Tue, 5 May 2009 10:44:31 +0200 (CEST) Date: Tue, 05 May 2009 10:44:30 +0200 (CEST) Message-Id: <20090505.104430.136954611.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC030A609E@zcarhxm0.corp.nortel.com> References: <49E44535.8000704@ericsson.com> <20090415.141217.59541259.mbj@tail-f.com> <238C6E77EA42504DA038BAEE6D1C11EC030A609E@zcarhxm0.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 08:43:08 -0000 Hi, "Mark Scott" wrote: > Martin and Balazs, > > Suggest we allow for an explicit client re-synch as an alternative to > forcing the session to be closed: This is also what Juergen suggested in http://www.ietf.org/mail-archive/web/netconf/current/msg04471.html. > The capabilities of a NETCONF server MAY change over time. However, > once a NETCONF server has announced its capabilities in the > message, the capabilities for that session SHOULD NOT change unless > the server supports the change and the client has requested the > revised > capabilities for that session. > > Once a server has modified its capabilities: > > A server MUST reply with a 'capabilities-changed' error if the client > sends a request which is affected by a modified capability. > > A server MAY choose to send 'capabilities-changed' as the response > to any request other than if its capabilities has > changed. > > A server MAY stop sending 'capabilities-changed' to a specific > session after a response has been sent to that session. I think re-synch is overkill (it's trivial to close and open a new channel), but if we do re-synch, I don't think is the right operation. retrieves one complete schema, but what is needed is a list of all new capability uris. /martin From rfc-editor@rfc-editor.org Mon May 4 16:48:59 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD6228C126; Mon, 4 May 2009 16:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.917 X-Spam-Level: X-Spam-Status: No, score=-16.917 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZHtgkRjQIrd; Mon, 4 May 2009 16:48:58 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id E044728C265; Mon, 4 May 2009 16:47:09 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 07AD929B2B6; Mon, 4 May 2009 16:45:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090504234526.07AD929B2B6@bosco.isi.edu> Date: Mon, 4 May 2009 16:45:26 -0700 (PDT) X-Mailman-Approved-At: Tue, 05 May 2009 04:25:57 -0700 Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 5539 on NETCONF over Transport Layer Security (TLS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 23:48:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5539 Title: NETCONF over Transport Layer Security (TLS) Author: M. Badra Status: Standards Track Date: May 2009 Mailbox: badra@isima.fr Pages: 7 Characters: 16073 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-tls-07.txt URL: http://www.rfc-editor.org/rfc/rfc5539.txt The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From MARKSCOT@nortel.com Tue May 5 09:14:44 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D39C3A6DCE for ; Tue, 5 May 2009 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1w93UilKM2u for ; Tue, 5 May 2009 09:14:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 895EC3A6D13 for ; Tue, 5 May 2009 09:14:42 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n45GF9624532; Tue, 5 May 2009 16:15:09 GMT 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, 5 May 2009 12:15:50 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> In-reply-to: <20090505.104430.136954611.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] dynamic capabilities Thread-Index: AcnNXbkiaits3ldGS4mkevQSLbTM8gAPFmmw References: <49E44535.8000704@ericsson.com><20090415.141217.59541259.mbj@tail-f.com><238C6E77EA42504DA038BAEE6D1C11EC030A609E@zcarhxm0.corp.nortel.com> <20090505.104430.136954611.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:14:44 -0000 Thx Martin, My rationale for avoiding the new session is that in our case this triggers client initialization/data synch which would be unnecessary in many cases. So I would like the client to have the ability to preserve the session if both the server and client can handle the change and explicitly choose to do so. (I'm assuming this was Juergen's rationale as well). On the point I may have misinterpreted that servers are expected to know the specific impacts of the capabilities change - i.e. they would selectively choose to send 'capabilities-changed' to any (not 'all') messages other than . Meaning that they know which specific schema(s) need to be synched since they know which specific requests they would reply with that error (?). If that wasn't the intent then suggest we change these two qualifiers to be: A server MAY choose to send 'capabilities-changed' as the response to ALL requests other than if its capabilities has changed. A server MAY stop sending 'capabilities-changed' to a specific session after the /netconf-state/capabilities subtree has been queried by that session. OR if it was then (my personal preference): A server MAY choose to send 'capabilities-changed' as the response to any requests other than if its capabilities has changed. A server MAY stop sending 'capabilities-changed' to a specific session after a response has been sent to that session for the specific responses which were impacted by the change. =20 Again, for servers and/or clients that want to handle this more simply they both have control. A server could send the 'capabilities-changed' error to all requests that any client makes existing sessions (incl. attempts to query the schemas). Any client can trigger new session on first instance of the 'capabilities-changed' error independent of whether the server allows the resynch or not. cheers, Mark -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, May 05, 2009 4:45 AM To: Scott, Mark (CAR:2N00) Cc: balazs.lengyel@ericsson.com; netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities Hi, "Mark Scott" wrote: > Martin and Balazs, >=20 > Suggest we allow for an explicit client re-synch as an alternative to > forcing the session to be closed: This is also what Juergen suggested in http://www.ietf.org/mail-archive/web/netconf/current/msg04471.html. > The capabilities of a NETCONF server MAY change over time. However, > once a NETCONF server has announced its capabilities in the > message, the capabilities for that session SHOULD NOT change unless=20 > the server supports the change and the client has requested the > revised > capabilities for that session. >=20 > Once a server has modified its capabilities: >=20 > A server MUST reply with a 'capabilities-changed' error if the client > sends a request which is affected by a modified capability. >=20 > A server MAY choose to send 'capabilities-changed' as the response > to any request other than if its capabilities has > changed. >=20 > A server MAY stop sending 'capabilities-changed' to a specific > session after a response has been sent to that session. I think re-synch is overkill (it's trivial to close and open a new channel), but if we do re-synch, I don't think is the right operation. retrieves one complete schema, but what is needed is a list of all new capability uris. /martin From dromasca@avaya.com Tue May 5 09:53:20 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F993A718E for ; Tue, 5 May 2009 09:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bou-kf9sFpCP for ; Tue, 5 May 2009 09:53:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4F1D13A6D3C for ; Tue, 5 May 2009 09:53:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,298,1238990400"; d="scan'208";a="144945203" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 May 2009 12:54:44 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 May 2009 12:54:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 18:54:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5539 on NETCONF over Transport Layer Security (TLS) Thread-Index: AcnNFA9kFcxTqHHJQyOViEkZm0pV0gAjgPYQ From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: RFC 5539 on NETCONF over Transport Layer Security (TLS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:53:20 -0000 Congratulations to the editor, chairs and the whole WG for achieving this milestone.=20 Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Tuesday, May 05, 2009 2:45 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: netconf@ietf.org; rfc-editor@rfc-editor.org Subject: RFC 5539 on NETCONF over Transport Layer Security (TLS) A new Request for Comments is now available in online RFC libraries. =20 RFC 5539 Title: NETCONF over Transport Layer Security=20 (TLS)=20 Author: M. Badra Status: Standards Track Date: May 2009 Mailbox: badra@isima.fr Pages: 7 Characters: 16073 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-tls-07.txt URL: http://www.rfc-editor.org/rfc/rfc5539.txt The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From mbadra@gmail.com Tue May 5 10:04:13 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96ED3A6899 for ; Tue, 5 May 2009 10:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prQtLL1WMQU3 for ; Tue, 5 May 2009 10:04:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 5556A3A6A66 for ; Tue, 5 May 2009 10:04:12 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so764211fgb.18 for ; Tue, 05 May 2009 10:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=r7U7mdY/xMbzq9QoQUVgWKXNas9XBVaz78k7bHmI5oo=; b=eWWyjgKm65og5KMMOKbIaUw24MA3+6PRkeSbAg2jGZINZmAnv1UnktWKf/I9AfsXKO +PYJF2hcpHwkgvAJ3/5kfq7t4ShK2XFnsuUJJZm0CtDCS1uSuZ27FaXSmZBmf4hUDyzi 96qPTIN6xHOLoo17puU57bKlMTILK3fFcOG6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=oHkeceVCUmaJBtfhtMMCg6CLCfIlMy2kdckXL00b0VenmEFAkSGYAHYLPKO1Sm1rA3 F7ZYQ/ePrX2xrA60roRZ4ePp5zq8SWQu/M+Krfy9iAK69smuz2Ya2N5306WCqte8gXE4 HKvbkfiNS5iZjHokWV4SNG3ZNPeqjLgRSNzb4= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.70.12 with SMTP id s12mr339066fga.69.1241543136378; Tue, 05 May 2009 10:05:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 May 2009 19:05:36 +0200 X-Google-Sender-Auth: 33782319ae3615f1 Message-ID: From: Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=000e0cd297149dff7904692d49be Subject: Re: [Netconf] FW: RFC 5539 on NETCONF over Transport Layer Security (TLS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:04:14 -0000 --000e0cd297149dff7904692d49be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks to you all for your help and comments during the document progress. Best regards, Badra > > > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: Tuesday, May 05, 2009 2:45 AM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netconf@ietf.org; rfc-editor@rfc-editor.org > Subject: RFC 5539 on NETCONF over Transport Layer Security (TLS) > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5539 > > Title: NETCONF over Transport Layer Security > (TLS) > Author: M. Badra > Status: Standards Track > Date: May 2009 > Mailbox: badra@isima.fr > Pages: 7 > Characters: 16073 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netconf-tls-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc5539.txt > > The Network Configuration Protocol (NETCONF) provides mechanisms to > install, manipulate, and delete the configuration of network devices. > This document describes how to use the Transport Layer Security (TLS) > protocol to secure NETCONF exchanges. [STANDARDS TRACK] > > This document is a product of the Network Configuration Working Group of > the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions for improvements. Please refer to the current edition of > the Internet Official Protocol Standards (STD 1) for the standardization > state and status of this protocol. Distribution of this memo is > unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > 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 > --000e0cd297149dff7904692d49be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks to you all for your help and comments during the document progr= ess.
Best regards,
Badra


-----Original Message-----
From: ietf-announce-bounces@ietf.org
= [mailto:ietf-announce-bou= nces@ietf.org] On Behalf Of
rfc-editor@rfc-editor.org<= br>
Sent: Tuesday, May 05, 2009 2:45 AM
To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org
Cc: netconf@ietf.org; rfc-editor@rfc-editor.org
Subject: RFC 5539 on NETCONF over Transport Layer Security (TLS)

A new Request for Comments is now available in online RFC libraries.

=A0 =A0 =A0 =A0RFC 5539

=A0 =A0 =A0 =A0Title: =A0 =A0 =A0NETCO= NF over Transport Layer Security
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(TLS)
=A0 =A0 =A0 =A0Author: =A0 = =A0 M. Badra
=A0 =A0 =A0 =A0Status: =A0 =A0 Standards Track
=A0 =A0 = =A0 =A0Date: =A0 =A0 =A0 May 2009
=A0 =A0 =A0 =A0Mailbox: =A0 =A0badra@isima.fr
=A0 =A0 =A0 =A0Pages: =A0 = =A0 =A07
=A0 =A0 =A0 =A0Characters: 16073
=A0 =A0 =A0 =A0Updates/Obsoletes/SeeAls= o: =A0 None

=A0 =A0 =A0 =A0I-D Tag: =A0 =A0draft-ietf-netconf-tls-07= .txt

=A0 =A0 =A0 =A0URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/r= fc5539.txt

The Network Configuration Protocol (NETCONF) provides mechanisms to
= install, manipulate, and delete the configuration of network devices.
Th= is document describes how to use the Transport Layer Security (TLS)
protocol to secure NETCONF exchanges. =A0[STANDARDS TRACK]

This docu= ment is a product of the Network Configuration Working Group of
the IETF= .

This is now a Proposed Standard Protocol.

STANDARDS TRACK: = This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and
suggesti= ons for improvements. =A0Please refer to the current edition of
the Inte= rnet Official Protocol Standards (STD 1) for the standardization
state a= nd status of this protocol. =A0Distribution of this memo is
unlimited.

This announcement is sent to the IETF-Announce and rfc-di= st lists.
To subscribe or unsubscribe, see
=A0http://www.ietf.o= rg/mailman/listinfo/ietf-announce
=A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see
http://www.rfc-editor.org/rfcsearch.= html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for= special distribution should be addressed to either the
author of the RF= C in question, or to rfc-edito= r@rfc-editor.org. =A0Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimit= ed distribution.


The RFC Editor Team
USC/Information Sciences= Institute


_______________________________________________
IETF-Announce mailing list
IET= F-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/iet= f-announce
_______________________________________________
Netconf mail= ing list
Netconf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/netconf

--000e0cd297149dff7904692d49be-- From andy@netconfcentral.com Tue May 5 10:56:30 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26AAC3A6DB2 for ; Tue, 5 May 2009 10:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE50gSwRNFKw for ; Tue, 5 May 2009 10:56:29 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 5F1BA28C102 for ; Tue, 5 May 2009 10:55:51 -0700 (PDT) Received: (qmail 97956 invoked from network); 5 May 2009 17:57:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 5 May 2009 17:57:12 -0000 X-YMail-OSG: PmCuREEVM1laseYsSvRUaNkO3vWJlQG3tck2dBpdSkTlvG.wN5EV16zLlq0mz1QrBwRplqK7rApanQVB0C7iOOtzIZaIrdlD0.wFPyrzYL8ai4V9VnlNHJmDH4N2qkd7ksf6uInvrito5pSlFeyHEe7e_VOAa.EHJ6ZpD6qn.JcmnuW1.IC9yaryo1TnehW4XSdT0vIdjqzvyAvjfr6VcEh7EBVZdR8mEeKuxDREHxIm3eDgTUjbxXU3i5mGAnb9DbQ5wyUkPWOTclUK3oADtDc2C1E9kU1F1PBAjF0kAHJrU6kEbczG X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A007DF4.8080300@netconfcentral.com> Date: Tue, 05 May 2009 10:57:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Scott References: <49E44535.8000704@ericsson.com><20090415.141217.59541259.mbj@tail-f.com><238C6E77EA42504DA038BAEE6D1C11EC030A609E@zcarhxm0.corp.nortel.com> <20090505.104430.136954611.mbj@tail-f.com> <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:56:30 -0000 Mark Scott wrote: > Thx Martin, > > My rationale for avoiding the new session is that in our case this > triggers client initialization/data synch which would be unnecessary in > many cases. So I would like the client to have the ability to preserve > the session if both the server and client can handle the change and > explicitly choose to do so. (I'm assuming this was Juergen's rationale > as well). > This proposal doesn't make a lot of sense. If a mechanism to turn off the capability-changed error is needed, then add it explicitly. I agree with Martin that starting a new session is good enough. I don't see how the manager is helped by all the optional agent behavior. I prefer a more deterministic agent design, i.e., The agent MUST return the capability-changed error (except safe RPCs ***) unless the session has invoked the operation. *** close-session, kill-session, get-schema, turn-off-capability-changed-error, lock, unlock, partial-lock, partial-unlock, discard-changes Andy > On the point I may have misinterpreted that servers are > expected to know the specific impacts of the capabilities change - i.e. > they would selectively choose to send 'capabilities-changed' to any (not > 'all') messages other than . Meaning that they know > which specific schema(s) need to be synched since they know which > specific requests they would reply with that error (?). > > If that wasn't the intent then suggest we change these two qualifiers to > be: > > A server MAY choose to send 'capabilities-changed' as the response > to ALL requests other than if its capabilities has > changed. > > A server MAY stop sending 'capabilities-changed' to a specific > session after the /netconf-state/capabilities subtree has been > queried by that session. > > OR if it was then (my personal preference): > > A server MAY choose to send 'capabilities-changed' as the response > to any requests other than if its capabilities has > changed. > > A server MAY stop sending 'capabilities-changed' to a specific > session after a response has been sent to that session > for the specific responses which were impacted by the change. > > Again, for servers and/or clients that want to handle this more simply > they both have control. A server could send the 'capabilities-changed' > error to all requests that any client makes existing sessions (incl. > attempts to query the schemas). Any client can trigger new session on > first instance of the 'capabilities-changed' error independent of > whether the server allows the resynch or not. > > cheers, > Mark > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, May 05, 2009 4:45 AM > To: Scott, Mark (CAR:2N00) > Cc: balazs.lengyel@ericsson.com; netconf@ietf.org > Subject: Re: [Netconf] dynamic capabilities > > Hi, > > "Mark Scott" wrote: >> Martin and Balazs, >> >> Suggest we allow for an explicit client re-synch as an alternative to >> forcing the session to be closed: > > This is also what Juergen suggested in > http://www.ietf.org/mail-archive/web/netconf/current/msg04471.html. > > >> The capabilities of a NETCONF server MAY change over time. However, >> once a NETCONF server has announced its capabilities in the >> message, the capabilities for that session SHOULD NOT change unless >> the server supports the change and the client has requested the >> revised >> capabilities for that session. >> >> Once a server has modified its capabilities: >> >> A server MUST reply with a 'capabilities-changed' error if the > client >> sends a request which is affected by a modified capability. >> >> A server MAY choose to send 'capabilities-changed' as the response >> to any request other than if its capabilities has >> changed. >> >> A server MAY stop sending 'capabilities-changed' to a specific >> session after a response has been sent to that session. > > I think re-synch is overkill (it's trivial to close and open a new > channel), but if we do re-synch, I don't think is the > right operation. retrieves one complete schema, but what > is needed is a list of all new capability uris. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From MARKSCOT@nortel.com Tue May 5 11:11:52 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713A43A6D3B for ; Tue, 5 May 2009 11:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DncMI8ZIzXR for ; Tue, 5 May 2009 11:11:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E6EA73A6C7F for ; Tue, 5 May 2009 11:11:50 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n45ICfm25736; Tue, 5 May 2009 18:12:41 GMT 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, 5 May 2009 14:12:38 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031647FD@zcarhxm0.corp.nortel.com> In-reply-to: <4A007DF4.8080300@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] dynamic capabilities Thread-Index: AcnNqv1pDwrNrayfRIqQe/5TBlslZQAATV+A References: <49E44535.8000704@ericsson.com><20090415.141217.59541259.mbj@tail-f.com><238C6E77EA42504DA038BAEE6D1C11EC030A609E@zcarhxm0.corp.nortel.com> <20090505.104430.136954611.mbj@tail-f.com> <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> <4A007DF4.8080300@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 18:11:52 -0000 Andy, I'm not sure what specifically doesn't make sense about wanting to preserve the session but the proposed alternative (explicit command to turn off capabilities-changed error) achieves the same goal. So I'm fine with that as well. I would be interested if others have opinions on which approach is desirable? I also like the explicit list of 'safe' RPCs when in changed capabilities state and will include these in next update to the draft. Mark -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com]=20 Sent: Tuesday, May 05, 2009 1:57 PM To: Scott, Mark (CAR:2N00) Cc: Martin Bjorklund; netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities Mark Scott wrote: > Thx Martin, >=20 > My rationale for avoiding the new session is that in our case this > triggers client initialization/data synch which would be unnecessary in > many cases. So I would like the client to have the ability to preserve > the session if both the server and client can handle the change and > explicitly choose to do so. (I'm assuming this was Juergen's rationale > as well). >=20 This proposal doesn't make a lot of sense. If a mechanism to turn off the capability-changed error is needed, then add it explicitly. I agree with Martin that starting a new session is good enough. I don't see how the manager is helped by all the optional agent behavior. I prefer a more deterministic agent design, i.e., The agent MUST return the capability-changed error (except safe RPCs ***) unless the session has invoked the operation. *** close-session, kill-session, get-schema, turn-off-capability-changed-error, lock, unlock, partial-lock, partial-unlock, discard-changes Andy > On the point I may have misinterpreted that servers are > expected to know the specific impacts of the capabilities change - i.e. > they would selectively choose to send 'capabilities-changed' to any (not > 'all') messages other than . Meaning that they know > which specific schema(s) need to be synched since they know which > specific requests they would reply with that error (?). >=20 > If that wasn't the intent then suggest we change these two qualifiers to > be: >=20 > A server MAY choose to send 'capabilities-changed' as the response > to ALL requests other than if its capabilities has > changed. >=20 > A server MAY stop sending 'capabilities-changed' to a specific > session after the /netconf-state/capabilities subtree has been > queried by that session. >=20 > OR if it was then (my personal preference): >=20 > A server MAY choose to send 'capabilities-changed' as the response > to any requests other than if its capabilities has > changed. >=20 > A server MAY stop sending 'capabilities-changed' to a specific > session after a response has been sent to that session > for the specific responses which were impacted by the change. > =20 > Again, for servers and/or clients that want to handle this more simply > they both have control. A server could send the 'capabilities-changed' > error to all requests that any client makes existing sessions (incl. > attempts to query the schemas). Any client can trigger new session on > first instance of the 'capabilities-changed' error independent of > whether the server allows the resynch or not. >=20 > cheers, > Mark >=20 >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > Sent: Tuesday, May 05, 2009 4:45 AM > To: Scott, Mark (CAR:2N00) > Cc: balazs.lengyel@ericsson.com; netconf@ietf.org > Subject: Re: [Netconf] dynamic capabilities >=20 > Hi, >=20 > "Mark Scott" wrote: >> Martin and Balazs, >> >> Suggest we allow for an explicit client re-synch as an alternative to >> forcing the session to be closed: >=20 > This is also what Juergen suggested in > http://www.ietf.org/mail-archive/web/netconf/current/msg04471.html. >=20 >=20 >> The capabilities of a NETCONF server MAY change over time. However, >> once a NETCONF server has announced its capabilities in the >> message, the capabilities for that session SHOULD NOT change unless >> the server supports the change and the client has requested the >> revised >> capabilities for that session. >> >> Once a server has modified its capabilities: >> >> A server MUST reply with a 'capabilities-changed' error if the > client >> sends a request which is affected by a modified capability. >> >> A server MAY choose to send 'capabilities-changed' as the response >> to any request other than if its capabilities has >> changed. >> >> A server MAY stop sending 'capabilities-changed' to a specific >> session after a response has been sent to that session. >=20 > I think re-synch is overkill (it's trivial to close and open a new > channel), but if we do re-synch, I don't think is the > right operation. retrieves one complete schema, but what > is needed is a list of all new capability uris. >=20 >=20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 From mehmet.ersue@nsn.com Tue May 5 12:08:47 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8131E3A6E58 for ; Tue, 5 May 2009 12:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvBdcQ3TRYqg for ; Tue, 5 May 2009 12:08:46 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 259883A6DF8 for ; Tue, 5 May 2009 12:08:45 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n45JA9oZ009872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2009 21:10:09 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n45JA9Le024987; Tue, 5 May 2009 21:10:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 21:10:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 21:10:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: RFC 5539 on NETCONF over Transport Layer Security(TLS) thread-index: AcnNFA9kFcxTqHHJQyOViEkZm0pV0gAjgPYQAAR3x4A= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 05 May 2009 19:10:09.0039 (UTC) FILETIME=[1B77F1F0:01C9CDB5] Subject: Re: [Netconf] FW: RFC 5539 on NETCONF over Transport Layer Security(TLS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:08:47 -0000 Dear NETCONF WG, same from the shepherding co-chair. The important part=20 now is the deployment. We would like to know if anybody=20 is going to implement the new RFC. Cheers,=20 Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu,=20 > Dan (Dan) > Sent: Tuesday, May 05, 2009 6:55 PM > To: netconf@ietf.org > Subject: [Netconf] FW: RFC 5539 on NETCONF over Transport=20 > Layer Security(TLS) >=20 >=20 > Congratulations to the editor, chairs and the whole WG for achieving > this milestone.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: Tuesday, May 05, 2009 2:45 AM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netconf@ietf.org; rfc-editor@rfc-editor.org > Subject: RFC 5539 on NETCONF over Transport Layer Security (TLS) >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 > =20 > RFC 5539 >=20 > Title: NETCONF over Transport Layer Security=20 > (TLS)=20 > Author: M. Badra > Status: Standards Track > Date: May 2009 > Mailbox: badra@isima.fr > Pages: 7 > Characters: 16073 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-netconf-tls-07.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc5539.txt >=20 > The Network Configuration Protocol (NETCONF) provides mechanisms to > install, manipulate, and delete the configuration of network devices. > This document describes how to use the Transport Layer Security (TLS) > protocol to secure NETCONF exchanges. [STANDARDS TRACK] >=20 > This document is a product of the Network Configuration=20 > Working Group of > the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions for improvements. Please refer to the current edition of > the Internet Official Protocol Standards (STD 1) for the=20 > standardization > state and status of this protocol. Distribution of this memo is > unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to=20 > rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > USC/Information Sciences Institute >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mbj@tail-f.com Tue May 5 13:18:29 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DC23A6D09 for ; Tue, 5 May 2009 13:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcSaEkrqGvT0 for ; Tue, 5 May 2009 13:18:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2B0573A6AD9 for ; Tue, 5 May 2009 13:18:29 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 32CFB616006; Tue, 5 May 2009 22:11:28 +0200 (CEST) Date: Tue, 05 May 2009 22:11:27 +0200 (CEST) Message-Id: <20090505.221127.99789508.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> References: <238C6E77EA42504DA038BAEE6D1C11EC030A609E@zcarhxm0.corp.nortel.com> <20090505.104430.136954611.mbj@tail-f.com> <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:18:30 -0000 Hi, "Mark Scott" wrote: > On the point I may have misinterpreted that servers are > expected to know the specific impacts of the capabilities change - i.e. > they would selectively choose to send 'capabilities-changed' to any (not > 'all') messages other than . Meaning that they know > which specific schema(s) need to be synched since they know which > specific requests they would reply with that error (?). I just meant that another rpc operation is needed for capability re-sync, if we decide to do that. Maybe which would return the capability list as defined in the msg. /martin From mbj@tail-f.com Tue May 5 13:22:02 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1033A69ED for ; Tue, 5 May 2009 13:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5D2bYSJvLO5 for ; Tue, 5 May 2009 13:22:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 843853A6940 for ; Tue, 5 May 2009 13:22:01 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EDADB616006; Tue, 5 May 2009 22:23:27 +0200 (CEST) Date: Tue, 05 May 2009 22:23:27 +0200 (CEST) Message-Id: <20090505.222327.242889432.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC031647FD@zcarhxm0.corp.nortel.com> References: <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> <4A007DF4.8080300@netconfcentral.com> <238C6E77EA42504DA038BAEE6D1C11EC031647FD@zcarhxm0.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:22:02 -0000 Hi, "Mark Scott" wrote: > I also like the explicit list of 'safe' RPCs when in changed > capabilities state and will include these in next update to the draft. Should this go into the monitoring draft, or should parts of it (everything?) go into 4741bis? I think 4741bis needs to spell out if/how capabilities are allowed to changed. /martin From andy@netconfcentral.com Tue May 5 13:42:56 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD653A6DD2 for ; Tue, 5 May 2009 13:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85TWI+4mnGcj for ; Tue, 5 May 2009 13:42:55 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id B9AD53A6D91 for ; Tue, 5 May 2009 13:42:55 -0700 (PDT) Received: (qmail 12858 invoked from network); 5 May 2009 20:44:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.38 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 5 May 2009 20:44:19 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A00A521.2030804@netconfcentral.com> Date: Tue, 05 May 2009 13:44:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com> <4A007DF4.8080300@netconfcentral.com> <238C6E77EA42504DA038BAEE6D1C11EC031647FD@zcarhxm0.corp.nortel.com> <20090505.222327.242889432.mbj@tail-f.com> In-Reply-To: <20090505.222327.242889432.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] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:42:56 -0000 Martin Bjorklund wrote: > Hi, > > "Mark Scott" wrote: >> I also like the explicit list of 'safe' RPCs when in changed >> capabilities state and will include these in next update to the draft. > > Should this go into the monitoring draft, or should parts of it > (everything?) go into 4741bis? I think 4741bis needs to spell out > if/how capabilities are allowed to changed. > I agree. I was wondering what 'next update of the draft' meant. Capabilities are part of the protocol, not specific or constrained to monitoring. > > /martin > > Andy From MARKSCOT@nortel.com Wed May 6 07:47:06 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864773A6EE9 for ; Wed, 6 May 2009 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb+oJMUrM+Xj for ; Wed, 6 May 2009 07:47:01 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8C8E93A6A8A for ; Wed, 6 May 2009 07:46:03 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n46EjwO03835; Wed, 6 May 2009 14:45:58 GMT 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, 6 May 2009 10:45:31 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC03165250@zcarhxm0.corp.nortel.com> In-reply-to: <20090505.222327.242889432.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] dynamic capabilities Thread-Index: AcnNv1x0USnwOnhLTe6xy1RlP/sDTwAmdPVA References: <238C6E77EA42504DA038BAEE6D1C11EC03110E29@zcarhxm0.corp.nortel.com><4A007DF4.8080300@netconfcentral.com><238C6E77EA42504DA038BAEE6D1C11EC031647FD@zcarhxm0.corp.nortel.com> <20090505.222327.242889432.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:47:06 -0000 I think it belongs in 4741bis. Mark -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, May 05, 2009 4:23 PM To: Scott, Mark (CAR:2N00) Cc: andy@netconfcentral.com; netconf@ietf.org Subject: Re: [Netconf] dynamic capabilities Hi, "Mark Scott" wrote: > I also like the explicit list of 'safe' RPCs when in changed > capabilities state and will include these in next update to the draft. Should this go into the monitoring draft, or should parts of it (everything?) go into 4741bis? I think 4741bis needs to spell out if/how capabilities are allowed to changed. /martin From MARKSCOT@nortel.com Wed May 6 09:40:43 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176223A6D88 for ; Wed, 6 May 2009 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+di8alGBaQj for ; Wed, 6 May 2009 09:40:36 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 027063A6AED for ; Wed, 6 May 2009 09:38:03 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n46GdNv11494; Wed, 6 May 2009 16:39:24 GMT 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, 6 May 2009 12:38:57 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC0316553A@zcarhxm0.corp.nortel.com> In-reply-to: <49D0DFFF.4090501@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] sessionId issue Thread-Index: AcmxUM68QRW/XzsPSkqHdVVQObguCQdEyk6Q References: <49D0DFFF.4090501@ericsson.com> From: "Mark Scott" To: "Balazs Lengyel" , "WashamFan" Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:40:43 -0000 Hello Washam, For the second point (sec2.1.4 of the monitoring draft) we had assumed a session-id was unique, regardless of protocol. I think this assumption is generally understood (if not formally agreed) since other operations like require uniqueness for deterministic behavior. An item we may want to formally capture in 4741bis. =20 We will clearly state this assumption in the monitoring draft. I see there are some other threads on this topic now addressing this in the broader scope (incl. how to handle connectionless session handling). Do you see any further action required in the monitoring draft on this item at this point? Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel Sent: Monday, March 30, 2009 11:07 AM To: WashamFan Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue I would rather have the sessionId unique for ALL sessions as well. What to do with SNMP and=20 alike that doesn't really have a session just a UDP packet is an interesting issue? Balazs WashamFan wrote: > Hi, >=20 > There were 2 issues: > 1) sessionId=3D0 for all non-netconf sessions. > 2) lockId is unique for all netconf locks. >=20 > After clarification wrt/ 2), now > 2*) lockId is unique for all locks (including both netconf and non-netconf locks). >=20 > But, how about 1)? >=20 > sec2.1.4, monitoring-04: >=20 > Session data pertaining to the NETCONF server. Includes data > for NETCONF and non-NETCONF management sessions. >=20 > sessionId is used as the key amongst sessions, but it can't be the key based on 1). >=20 > washam > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 --=20 Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From Washam.Fan@huaweisymantec.com Wed May 6 19:10:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C24B3A6EC1 for ; Wed, 6 May 2009 19:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQyELpdtoIXX for ; Wed, 6 May 2009 19:10:17 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 335713A6C37 for ; Wed, 6 May 2009 19:10:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ900AIG4RGRR00@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Thu, 07 May 2009 10:11:42 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJ9000AU4REOG20@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 07 May 2009 10:11:40 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 07 May 2009 10:11:38 +0800 From: WashamFan To: Mark Scott Message-id: Date: Thu, 07 May 2009 10:11:38 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <238C6E77EA42504DA038BAEE6D1C11EC0316553A@zcarhxm0.corp.nortel.com> References: <49D0DFFF.4090501@ericsson.com> <238C6E77EA42504DA038BAEE6D1C11EC0316553A@zcarhxm0.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 02:10:18 -0000 Hi, IMO, we should think about if the change is worthwhile. The rationale is, the sessionId is to differentiate multiple entries in sessions table. If we are intended to monitor both Netconf and Non-Netconf sessions, the identifier should be unique. As you mark sessionId as the key, sessionId should be unique among all sessions being monitored, regardless of protocol. Besides, I am afraid we can hardly benefit from Non-Netconf sessionId. is to force the termination of a NETCONF session, it does not affect Non-Netconf sessions as I know. It would complicate things if there is no straightforward way to address connectless session handling. The current text excludes this case, to my understanding. Any comments? washam ----- Original Message ----- From: Mark Scott Date: Thursday, May 7, 2009 0:39 am Subject: RE: [Netconf] sessionId issue To: Balazs Lengyel , WashamFan Cc: netconf@ietf.org > Hello Washam, > > For the second point (sec2.1.4 of the monitoring draft) we had > assumed a > session-id was unique, regardless of protocol. > > I think this assumption is generally understood (if not formally agreed) > since other operations like require uniqueness for > deterministic behavior. An item we may want to formally capture in > 4741bis. > > We will clearly state this assumption in the monitoring draft. > > I see there are some other threads on this topic now addressing this > in > the broader scope (incl. how to handle connectionless session handling). > > Do you see any further action required in the monitoring draft on this > item at this point? > > Mark > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Balazs Lengyel > Sent: Monday, March 30, 2009 11:07 AM > To: WashamFan > Cc: netconf@ietf.org > Subject: Re: [Netconf] sessionId issue > > I would rather have the sessionId unique for ALL sessions as well. What > to do with SNMP and > alike that doesn't really have a session just a UDP packet is an > interesting issue? > Balazs > > WashamFan wrote: > > Hi, > > > > There were 2 issues: > > 1) sessionId=0 for all non-netconf sessions. > > 2) lockId is unique for all netconf locks. > > > > After clarification wrt/ 2), now > > 2*) lockId is unique for all locks (including both netconf and > non-netconf locks). > > > > But, how about 1)? > > > > sec2.1.4, monitoring-04: > > > > Session data pertaining to the NETCONF server. Includes data > > for NETCONF and non-NETCONF management sessions. > > > > sessionId is used as the key amongst sessions, but it can't be the > key > based on 1). > > > > washam > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From j.schoenwaelder@jacobs-university.de Wed May 6 22:37:43 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7BE3A6C89 for ; Wed, 6 May 2009 22:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omkQMwmpDNyg for ; Wed, 6 May 2009 22:37:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 519283A6FE0 for ; Wed, 6 May 2009 22:37:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72CA2C013A; Thu, 7 May 2009 07:38:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DAmqruVlpwNJ; Thu, 7 May 2009 07:38:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82D51C00F3; Thu, 7 May 2009 07:38:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 38BBEADD3FC; Thu, 7 May 2009 07:38:36 +0200 (CEST) Date: Thu, 7 May 2009 07:38:36 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090507053836.GA23365@elstar.local> Mail-Followup-To: WashamFan , Mark Scott , "netconf@ietf.org" References: <49D0DFFF.4090501@ericsson.com> <238C6E77EA42504DA038BAEE6D1C11EC0316553A@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 05:37:43 -0000 On Thu, May 07, 2009 at 04:11:38AM +0200, WashamFan wrote: > IMO, we should think about if the change is worthwhile. > > The rationale is, the sessionId is to differentiate multiple entries > in sessions table. If we are intended to monitor both Netconf > and Non-Netconf sessions, the identifier should be unique. As > you mark sessionId as the key, sessionId should be unique among > all sessions being monitored, regardless of protocol. > > Besides, I am afraid we can hardly benefit from Non-Netconf > sessionId. is to force the termination of a NETCONF > session, it does not affect Non-Netconf sessions as I know. > > It would complicate things if there is no straightforward way to > address connectless session handling. The current text excludes > this case, to my understanding. I tend to agree. Why does the monitoring draft not simply use a tuple including the protocol and a protocol specific sessionId? /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.com Thu May 7 07:21:19 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7838D3A68D0 for ; Thu, 7 May 2009 07:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4UhZwoEMame for ; Thu, 7 May 2009 07:21:18 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 246513A701F for ; Thu, 7 May 2009 07:21:18 -0700 (PDT) Received: from [68.142.200.221] by n20.bullet.mail.mud.yahoo.com with NNFMP; 07 May 2009 14:22:42 -0000 Received: from [68.142.201.244] by t9.bullet.mud.yahoo.com with NNFMP; 07 May 2009 14:22:42 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 07 May 2009 14:22:42 -0000 X-Yahoo-Newman-Id: 528804.86703.bm@omp405.mail.mud.yahoo.com Received: (qmail 48910 invoked from network); 7 May 2009 14:22:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2009 14:22:41 -0000 X-YMail-OSG: Yk307QwVM1mmc43MbKJHjPdh8JzVATjzt02OJVuQ7e.7WgmRW0F55wOyOFAF949V27jmScl5kBkxBwicwbxrsoIyne43PIZvOQzjdBSeCOMrpcx6TLd8r.HAWmiwg0EoE7pJvkX9fY55XnhM_NRl45AloSZ20nLDHpmllH_1Hrb2W7DT44_n8nnKAHERVCJ96zGWnRXCmLIKYQbHm5oMIAvXRZqz6NBkS31EK2YbI4eb19rBOch7_lmwPwEfxUFvR6yISyIUM_YEEg8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A02EEAF.70803@netconfcentral.com> Date: Thu, 07 May 2009 07:22:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan , Mark Scott , "netconf@ietf.org" References: <49D0DFFF.4090501@ericsson.com> <238C6E77EA42504DA038BAEE6D1C11EC0316553A@zcarhxm0.corp.nortel.com> <20090507053836.GA23365@elstar.local> In-Reply-To: <20090507053836.GA23365@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 14:21:19 -0000 Juergen Schoenwaelder wrote: > On Thu, May 07, 2009 at 04:11:38AM +0200, WashamFan wrote: > >> IMO, we should think about if the change is worthwhile. >> >> The rationale is, the sessionId is to differentiate multiple entries >> in sessions table. If we are intended to monitor both Netconf >> and Non-Netconf sessions, the identifier should be unique. As >> you mark sessionId as the key, sessionId should be unique among >> all sessions being monitored, regardless of protocol. >> >> Besides, I am afraid we can hardly benefit from Non-Netconf >> sessionId. is to force the termination of a NETCONF >> session, it does not affect Non-Netconf sessions as I know. >> >> It would complicate things if there is no straightforward way to >> address connectless session handling. The current text excludes >> this case, to my understanding. > > I tend to agree. Why does the monitoring draft not simply use a tuple > including the protocol and a protocol specific sessionId? > Since there is no standard architecture or applicability statement for NETCONF, it is hard to tell how multi-protocol database access is supposed to work. What will the manager do with some enum that says 'SNMP', 'CLI', 'WebUI', etc? I prefer that the standard be very clear about the ARCH and AS issues wrt/ multi-protocol management, *before* jumping to conclusions about solutions. We should not 'just add another key' to a monitoring table without any written (agreed-upon) understanding of the big picture first. > /js > Andy From mbj@tail-f.com Thu May 7 07:34:01 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2E93A7093 for ; Thu, 7 May 2009 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5lRPlO-06dk for ; Thu, 7 May 2009 07:34:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A24F83A683A for ; Thu, 7 May 2009 07:33:59 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F19576C340; Thu, 7 May 2009 16:35:16 +0200 (CEST) Date: Thu, 07 May 2009 16:35:16 +0200 (CEST) Message-Id: <20090507.163516.242267381.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A02EEAF.70803@netconfcentral.com> References: <20090507053836.GA23365@elstar.local> <4A02EEAF.70803@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 14:34:01 -0000 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Thu, May 07, 2009 at 04:11:38AM +0200, WashamFan wrote: > > > >> IMO, we should think about if the change is worthwhile. > >> > >> The rationale is, the sessionId is to differentiate multiple entries > >> in sessions table. If we are intended to monitor both Netconf and > >> Non-Netconf sessions, the identifier should be unique. As you mark sessionId > >> as the key, sessionId should be unique among all sessions being monitored, > >> regardless of protocol. > >> > >> Besides, I am afraid we can hardly benefit from Non-Netconf > >> sessionId. is to force the termination of a NETCONF session, > >> it does not affect Non-Netconf sessions as I know. > >> > >> It would complicate things if there is no straightforward way to > >> address connectless session handling. The current text excludes this case, > >> to my understanding. > > I tend to agree. Why does the monitoring draft not simply use a tuple > > including the protocol and a protocol specific sessionId? > > > > Since there is no standard architecture or applicability statement > for NETCONF, it is hard to tell how multi-protocol database access > is supposed to work. > > What will the manager do with some enum that says 'SNMP', 'CLI', > 'WebUI', etc? I prefer that the standard be very clear about > the ARCH and AS issues wrt/ multi-protocol management, *before* > jumping to conclusions about solutions. > > We should not 'just add another key' to a monitoring table without any > written (agreed-upon) understanding of the big picture first. To handle multi-protocol in monitoring we should change this from an enumeration to an identity (which gives us "extensible enumerations"). Then we can define just the "netconf" identity, or maybe "netconf", "snmp", "cli". Vendors can extend this as they need for other protocols. Re sessionId usage, I think it is unfortunate that 4741 says that if the protocol is not netconf, a session id 0 is used. I interpret this as MUST be used, but maybe that was not the intention? For systems that have a common session handling for all management protocols, this is a bit too restrictive. /martin From andy@netconfcentral.com Thu May 7 07:47:50 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8868328C1E2 for ; Thu, 7 May 2009 07:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prJ9QYF7VbQj for ; Thu, 7 May 2009 07:47:49 -0700 (PDT) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 8E55528C1CC for ; Thu, 7 May 2009 07:47:49 -0700 (PDT) Received: from [68.142.200.224] by n17.bullet.mail.mud.yahoo.com with NNFMP; 07 May 2009 14:49:14 -0000 Received: from [68.142.201.240] by t5.bullet.mud.yahoo.com with NNFMP; 07 May 2009 14:49:14 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 07 May 2009 14:49:14 -0000 X-Yahoo-Newman-Id: 445712.66525.bm@omp401.mail.mud.yahoo.com Received: (qmail 8281 invoked from network); 7 May 2009 14:49:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2009 14:49:10 -0000 X-YMail-OSG: LSWTHGQVM1k1v.iUSP7G_ofbQ0icBLU2byol98vouHlQF1hw2tU11H8ZTOcOxS2EeQNtwdo8oGGW52FsEXsRD._LgdcCvwxvYztUwO2pcFNLy8pMlv02ngAmvclwuNeZKn3SuyUm790VFZIRx0dSyEsvxYuPvd4ftoFgOD2G313IyvbgiO0v0trM1cDW7vnfNQy4M08UJ6fj_HHh3KbC8dPaDNW1ae7ilDDg4RQc.aGQmkHcl26CFmyN6nhmM0Jp..dNI_9HwLPO8z4m80ZDovvUjW139p5eFdU5IRE55H4LfFzd4UjBcuUr0zJXv6DopZctM64Uc5fj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A02F4E4.8030004@netconfcentral.com> Date: Thu, 07 May 2009 07:49:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090507053836.GA23365@elstar.local> <4A02EEAF.70803@netconfcentral.com> <20090507.163516.242267381.mbj@tail-f.com> In-Reply-To: <20090507.163516.242267381.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] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 14:47:50 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, May 07, 2009 at 04:11:38AM +0200, WashamFan wrote: >>> >>>> IMO, we should think about if the change is worthwhile. >>>> >>>> The rationale is, the sessionId is to differentiate multiple entries >>>> in sessions table. If we are intended to monitor both Netconf and >>>> Non-Netconf sessions, the identifier should be unique. As you mark sessionId >>>> as the key, sessionId should be unique among all sessions being monitored, >>>> regardless of protocol. >>>> >>>> Besides, I am afraid we can hardly benefit from Non-Netconf >>>> sessionId. is to force the termination of a NETCONF session, >>>> it does not affect Non-Netconf sessions as I know. >>>> >>>> It would complicate things if there is no straightforward way to >>>> address connectless session handling. The current text excludes this case, >>>> to my understanding. >>> I tend to agree. Why does the monitoring draft not simply use a tuple >>> including the protocol and a protocol specific sessionId? >>> >> Since there is no standard architecture or applicability statement >> for NETCONF, it is hard to tell how multi-protocol database access >> is supposed to work. >> >> What will the manager do with some enum that says 'SNMP', 'CLI', >> 'WebUI', etc? I prefer that the standard be very clear about >> the ARCH and AS issues wrt/ multi-protocol management, *before* >> jumping to conclusions about solutions. >> >> We should not 'just add another key' to a monitoring table without any >> written (agreed-upon) understanding of the big picture first. > > To handle multi-protocol in monitoring we should change this from an > enumeration to an identity (which gives us "extensible > enumerations"). Then we can define just the "netconf" identity, or > maybe "netconf", "snmp", "cli". Vendors can extend this as they > need for other protocols. > > Re sessionId usage, I think it is unfortunate that 4741 says that if > the protocol is not netconf, a session id 0 is used. I interpret this > as MUST be used, but maybe that was not the intention? For systems > that have a common session handling for all management protocols, this > is a bit too restrictive. > This was done to prevent a requirement that the SNMP and NETCONF agents be coupled. It is one thing to know the database is locked by another protocol. It is quite another to share lock-ids and other data with other protocols. The requirements for this sort of multi-protocol support need to agreed-upon first. IMO, all this monitoring support for database locks is fairly worthless. These locks normally last on the order of milli-seconds or seconds. If any session is actually interested in writing the database, they just have to request a lock, and all the debugging info needed will be returned in the if the lock cannot be granted. (And don't even get me started on the 'value' of knowing what notification filters other sessions have configured. I'm still trying to figure out what NM problem that one solves.) > > /martin > > > > Andy From j.schoenwaelder@jacobs-university.de Thu May 7 08:03:31 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F18B3A7008 for ; Thu, 7 May 2009 08:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrv0ULx4Mo2W for ; Thu, 7 May 2009 08:03:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 36CC03A69DB for ; Thu, 7 May 2009 08:03:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D21AC0199; Thu, 7 May 2009 17:04:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id y8QZM-TH-Otn; Thu, 7 May 2009 17:04:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D474C0193; Thu, 7 May 2009 17:04:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 17F19AE18DE; Thu, 7 May 2009 17:04:33 +0200 (CEST) Date: Thu, 7 May 2009 17:04:33 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090507150433.GB23969@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <20090507053836.GA23365@elstar.local> <4A02EEAF.70803@netconfcentral.com> <20090507.163516.242267381.mbj@tail-f.com> <4A02F4E4.8030004@netconfcentral.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A02F4E4.8030004@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:03:31 -0000 On Thu, May 07, 2009 at 04:49:08PM +0200, Andy Bierman wrote: > > Re sessionId usage, I think it is unfortunate that 4741 says that if > > the protocol is not netconf, a session id 0 is used. I interpret this > > as MUST be used, but maybe that was not the intention? For systems > > that have a common session handling for all management protocols, this > > is a bit too restrictive. Yes, but for systems that are build out of loosely coupled components, assuming that is a single sessionId number space is also kind of broken. > This was done to prevent a requirement > that the SNMP and NETCONF agents be coupled. It is one > thing to know the database is locked by another protocol. > It is quite another to share lock-ids and other data with > other protocols. yes > IMO, all this monitoring support for database locks > is fairly worthless. These locks normally last > on the order of milli-seconds or seconds. > If any session is actually interested in writing > the database, they just have to request a lock, > and all the debugging info needed will be returned > in the if the lock cannot be granted. I tend to agree. I am also not clear how much value this monitoring data has and in particular whether this context is the right one to solve multi-management protocol management issues. > (And don't even get me started on the 'value' of knowing > what notification filters other sessions have configured. > I'm still trying to figure out what NM problem that one solves.) ;-) /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.com Thu May 7 08:26:34 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778903A6D5F for ; Thu, 7 May 2009 08:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01k4ThWtk6W7 for ; Thu, 7 May 2009 08:26:33 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id C2DC63A6886 for ; Thu, 7 May 2009 08:26:05 -0700 (PDT) Received: (qmail 8491 invoked from network); 7 May 2009 15:27:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2009 15:27:30 -0000 X-YMail-OSG: 0ZpV8zIVM1l143rOk8P6p37ugOLhfkJUPXViSy9SFf9u7u5RKhg0.Zt_1LncMnkC8vbSqYhkj1_6HCgTPWCkzo5mMpjzhRjzYlHFdU8hvmvw6ZefIIaubR6Sq3VBM58Y3_otn55SxK02EL3Xn_Qd9iTvlDXmVAnnyltTpiGa2q6piUde3CBJIUc0VFYXOVBvLDMEU3yib3XbSZMmtWRAoQmSEBWE12KqdYA9lcfFbZ9rnDiP978xS8t4xSt.eFq7Ykd4SMJlI7Byyko- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A02FDE1.9040804@netconfcentral.com> Date: Thu, 07 May 2009 08:27:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <20090507053836.GA23365@elstar.local> <4A02EEAF.70803@netconfcentral.com> <20090507.163516.242267381.mbj@tail-f.com> <4A02F4E4.8030004@netconfcentral.com> <20090507150433.GB23969@elstar.local> In-Reply-To: <20090507150433.GB23969@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:26:34 -0000 Juergen Schoenwaelder wrote: > On Thu, May 07, 2009 at 04:49:08PM +0200, Andy Bierman wrote: > >>> Re sessionId usage, I think it is unfortunate that 4741 says that if >>> the protocol is not netconf, a session id 0 is used. I interpret this >>> as MUST be used, but maybe that was not the intention? For systems >>> that have a common session handling for all management protocols, this >>> is a bit too restrictive. > > Yes, but for systems that are build out of loosely coupled components, > assuming that is a single sessionId number space is also kind of > broken. > I agree that overloading the sessionId with information about the protocol associated with the sessionId is really broken. I prefer a really loose coupling, via a union: ... key sessionIdentity; leaf sessionIdentity { type union { // NETCONF session ID type SessionId; // string describing the external session type string { length 1..max; } } } Since the external session is outside the scope of the NETCONF standard, a vendor should be able to return any string it wants. A standard format for the 'SNMP' string could be added later. The 'CLI' and 'WebUi' strings will never be standard. >> This was done to prevent a requirement >> that the SNMP and NETCONF agents be coupled. It is one >> thing to know the database is locked by another protocol. >> It is quite another to share lock-ids and other data with >> other protocols. > > yes > >> IMO, all this monitoring support for database locks >> is fairly worthless. These locks normally last >> on the order of milli-seconds or seconds. >> If any session is actually interested in writing >> the database, they just have to request a lock, >> and all the debugging info needed will be returned >> in the if the lock cannot be granted. > > I tend to agree. I am also not clear how much value this monitoring > data has and in particular whether this context is the right one to > solve multi-management protocol management issues. > The same old problems like instance naming need to be resolved to have any sort of meaningful multi-protocol support. >> (And don't even get me started on the 'value' of knowing >> what notification filters other sessions have configured. >> I'm still trying to figure out what NM problem that one solves.) > > ;-) > > /js > Andy From MARKSCOT@nortel.com Thu May 7 08:45:20 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC6728C2C2 for ; Thu, 7 May 2009 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpsamNZP75Vc for ; Thu, 7 May 2009 08:45:19 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B4A0C28C2A0 for ; Thu, 7 May 2009 08:45:18 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n47Fj4o24716; Thu, 7 May 2009 15:45:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 11:45:31 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031AE3C6@zcarhxm0.corp.nortel.com> In-reply-to: <4A02FDE1.9040804@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] sessionId issue Thread-Index: AcnPKG+9vYNXKnkLQoinON/IhIgf0wAAMROg References: <20090507053836.GA23365@elstar.local><4A02EEAF.70803@netconfcentral.com><20090507.163516.242267381.mbj@tail-f.com><4A02F4E4.8030004@netconfcentral.com><20090507150433.GB23969@elstar.local> <4A02FDE1.9040804@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" , "Martin Bjorklund" , Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:45:20 -0000 Hi Andy, This basically gets back to an earlier discussion to use a tuple (sessionId and protocol). There was discussion of a compound key (sessionId, protocol and sourceHost) but it doesn't guarantee uniqueness either. We could use even more attributes (like loginTime) but I'd prefer to continue to assume that for any vendor that wants to include non-NETCONF session needs to ensure uniqueness, rather than create an increasing complex key as more protocols (and more issues of uniqueness) are monitored. =20 Your suggestion of an arbitrary string also assumes the contents of the string are unique. So I don't see this as any better than asking that a NETCONF implementation associate all non-NETCONF session with a unique sessionId in the NETCONF context. That is, at least for purposes of what is reported/managed via NETCONF the implementation must map to a unique sessionId within NETCONF. It doesn't necessarily mean that such a sessionId is shared with all protocols on that element and for sessionless connections the mappings may be shared. I've got 2 draft emails summarizing both these issues (sessionid uniqueness, multi-protocol reporting) that I'll send in a minute or two. Feel free to respond to this or to wait for the others. Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, May 07, 2009 11:27 AM To: Andy Bierman; Martin Bjorklund; netconf@ietf.org Subject: Re: [Netconf] sessionId issue Juergen Schoenwaelder wrote: > On Thu, May 07, 2009 at 04:49:08PM +0200, Andy Bierman wrote: >=20 >>> Re sessionId usage, I think it is unfortunate that 4741 says that if >>> the protocol is not netconf, a session id 0 is used. I interpret this >>> as MUST be used, but maybe that was not the intention? For systems >>> that have a common session handling for all management protocols, this >>> is a bit too restrictive. >=20 > Yes, but for systems that are build out of loosely coupled components, > assuming that is a single sessionId number space is also kind of > broken. >=20 I agree that overloading the sessionId with information about the protocol associated with the sessionId is really broken. I prefer a really loose coupling, via a union: ... key sessionIdentity; leaf sessionIdentity { type union { // NETCONF session ID type SessionId; // string describing the external session type string { length 1..max; } } } Since the external session is outside the scope of the NETCONF standard, a vendor should be able to return any string it wants. A standard format for the 'SNMP' string could be added later. The 'CLI' and 'WebUi' strings will never be standard. >> This was done to prevent a requirement >> that the SNMP and NETCONF agents be coupled. It is one >> thing to know the database is locked by another protocol. >> It is quite another to share lock-ids and other data with >> other protocols. >=20 > yes >=20 >> IMO, all this monitoring support for database locks >> is fairly worthless. These locks normally last >> on the order of milli-seconds or seconds. >> If any session is actually interested in writing >> the database, they just have to request a lock, >> and all the debugging info needed will be returned >> in the if the lock cannot be granted. >=20 > I tend to agree. I am also not clear how much value this monitoring > data has and in particular whether this context is the right one to > solve multi-management protocol management issues. >=20 The same old problems like instance naming need to be resolved to have any sort of meaningful multi-protocol support. >> (And don't even get me started on the 'value' of knowing >> what notification filters other sessions have configured. >> I'm still trying to figure out what NM problem that one solves.) >=20 > ;-) >=20 > /js >=20 Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From MARKSCOT@nortel.com Thu May 7 09:02:39 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302F028C2E0 for ; Thu, 7 May 2009 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNJJkHkWHSBj for ; Thu, 7 May 2009 09:02:38 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 296B028C11F for ; Thu, 7 May 2009 09:02:26 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n47G39g04914; Thu, 7 May 2009 16:03:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 12:02:46 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031AE43A@zcarhxm0.corp.nortel.com> In-reply-to: <20090507.163516.242267381.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] sessionId issue Thread-Index: AcnPIQ0cfinwjrAOSZKpDmGEtA4AGwACuNfQ References: <20090507053836.GA23365@elstar.local><4A02EEAF.70803@netconfcentral.com> <20090507.163516.242267381.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 16:02:39 -0000 Martin, I read it similarly. On that assumption, is this something we could modify for 4741bis though? Or at least state in the 4741bis that this is not mandatory. Partly because it aligns with our current assumption in Monitoring that sessionId is unique but also because for NETCONF to interact with non-NETCONF sessions I think this needs to be addressed. Speaking for our implementations - session and lock management are both cases where we are considering allowing NETCONF managers to manipulate non-NETCONF sessions. Both cases where our EMS (which uses NETCONF) want control over all sessions on the NEs. So we will need to provide unique sessionIds for non-NETCONF if we are to implement these properly. We would prefer not to be in violation of 4741 in doing so. I suspect others may have use cases where similar will be expected? Mark > Re sessionId usage, I think it is unfortunate that 4741 says that if > the protocol is not netconf, a session id 0 is used. I interpret this > as MUST be used, but maybe that was not the intention? For systems > that have a common session handling for all management protocols, this > is a bit too restrictive. From MARKSCOT@nortel.com Thu May 7 10:25:13 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD83A28C256 for ; Thu, 7 May 2009 10:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9MWDtyniKyy for ; Thu, 7 May 2009 10:25:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 969C63A6C97 for ; Thu, 7 May 2009 10:25:03 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n47HObo23278; Thu, 7 May 2009 17:24:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: A7Cj JJJt OP/b Rejq S9R8 UI60 XsjG ZSmv eghy io3W j3UJ k3qW l28N q6rG tKo2 u/ae; 4; YQBuAGQAeQBAAG4AZQB0AGMAbwBuAGYAYwBlAG4AdAByAGEAbAAuAGMAbwBtADsAbQBiAGoAQAB0AGEAaQBsAC0AZgAuAGMAbwBtADsAbgBlAHQAYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA7AHcAYQBzAGgAYQBtAC4AZgBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sosha1_v1; 7; {237B7297-9AEE-4810-8ADC-D824A5306A36}; bQBhAHIAawBzAGMAbwB0AEAAbgBvAHIAdABlAGwALgBjAG8AbQA=; Thu, 07 May 2009 17:24:55 GMT; WwBOAEUAVABDAE8ATgBGAF0AIABNAG8AbgBpAHQAbwByAGkAbgBnACAAZAByAGEAZgB0ADoAIAAgAHMAZQBzAHMAaQBvAG4ASQBkACAAdQBuAGkAcQB1AGUAbgBlAHMAcwAgAHAAcgBvAHAAbwBzAGUAZAAgAHIAZQBzAG8AbAB1AHQAaQBvAG4A MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CF38.D22DCA35" x-cr-puzzleid: {237B7297-9AEE-4810-8ADC-D824A5306A36} Content-class: urn:content-classes:message Date: Thu, 7 May 2009 13:24:55 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution Thread-Index: AcnPOLzvASnCcoVERCiaCjKO2GR4gg== From: "Mark Scott" To: , "Washam Fan" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: [Netconf] [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 17:25:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CF38.D22DCA35 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, =20 In response to ML discussion for open item 'sessionID uniqueness' in the NETCONF Monitoring draft: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04 =20 Please review the issue and in particular the 'suggested resolution' below and reply with your agreement or suggestion for alternative in an attempt to reach WG consensus on this issue. =20 ISSUE: Key definition for ManagementSessionInfo ------------------------------------------------ =20 Current draft assumes sessionId will be unique for both NETCONF and non-NETCONF sessions reported via monitoring data. =20 SessionId uniqueness holds for NETCONF session. An issues arises applying same assumption to non-NETCONF sessions: =20 We have expressed opinion that sessionId uniqueness should also be mandated for all non-NETCONF entries included in the monitoring data since other protocols have similar use cases where a unique Id is required and/or a mapping scheme needs to be provided if a NETCONF implementation wants to manage non-NETCONF sessions. In particular if an implementation wants to extend support for an operation such as to non-NETCONF sessions. =20 However there is a side discussion underway on whether or not 4741 intended for sessionId=3D0 to be mandatory for non-NETCONF sessions in = all cases. Have asked for clarification in 4741bis. Until that is resolved we cannot mandate non-0 sessionId values in the monitoring data and don't want to delay monitoring on that decision. =20 Suggestions to use a tuple of existing fields were considered. In particular the use of sessionId, protocol and sourceHost but this doesn't guarantee uniqueness either. More fields (like loginTime) could be included but may lead to an increasing complex key as more protocols (and more issues of uniqueness) are monitored. =20 It is agreed we do want to keep the ability to report non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF entries needs to be added. =20 =20 SUGGESTED RESOLUTION: Add 'nativeSessionId', quality 'netconfSessionId' and extend key ------------------------------------------------------------------------ ---------------- =20 Per Andy's suggestion, refine ManagementSessionInfo, changing section 2.1.4 and model: =20 session |_netconfSessionId (key) |_associatedSession (key) |_transport |_protocol |_username |_sourceHost |_loginTime =20 netconfSessionId (type: SessionId) NETCONF identifier for the session. This is the unique sessionId used for all NETCONF operations. This is not guaranteed to be unique for non-NETCONF sessions. =20 associatedSession (type: string) Identifer used within NETCONF to associate to the native session in non-NETCONF protocol. For NETCONF sessions the value MUST match netconfSessionid. For non-NETCONF sessions, when a native session identifier is available this value should be the equal (string equivalent). It is expected this value will be unique when available for each reported particular protocol type. For non-NETCONF sessions, when a native session identifier is not available (e.g. sessionless protocol) and the NETCONF implementation chooses to report the sessions it MUST provide an associated session Id value. =20 The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be unique in all cases. xs:string is chosen to allow mapping to multiple native datatypes. =20 =20 cheers, mark ------_=_NextPart_001_01C9CF38.D22DCA35 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

 

In response to ML discussion for open item = ‘sessionID uniqueness’ in the NETCONF Monitoring draft:  http= ://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

 

Please review the issue and in particular the = 'suggested resolution' below and reply with your agreement or suggestion for = alternative in an attempt to reach WG consensus on this issue.

 

ISSUE:  Key definition for = ManagementSessionInfo

------------------------------------------------

 

Current draft assumes sessionId will be unique = for both NETCONF and non-NETCONF sessions reported via monitoring data.

 

SessionId uniqueness holds for NETCONF = session.  An issues arises applying same assumption to non-NETCONF = sessions:

 

We have expressed opinion that sessionId = uniqueness should also be mandated for all non-NETCONF entries included in the = monitoring data since other protocols have similar use cases where a unique Id is = required and/or a mapping scheme needs to be provided if a NETCONF implementation = wants to manage non-NETCONF sessions.  In particular if an implementation = wants to extend support for an operation such as <kill-session> to = non-NETCONF sessions.

 

However there is a side discussion underway on = whether or not 4741 intended for sessionId=3D0 to be mandatory for non-NETCONF = sessions in all cases.  Have asked for clarification in 4741bis.  Until = that is resolved we cannot mandate non-0 sessionId values in the monitoring data = and don’t want to delay monitoring on that decision.

 

Suggestions to use a tuple of existing fields = were considered.  In particular the use of sessionId, protocol and = sourceHost but this doesn't guarantee uniqueness either.  More fields (like = loginTime) could be included but may lead to an increasing complex key as more = protocols (and more issues of uniqueness) are monitored.

 

It is agreed we do want to keep the ability to = report non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF entries needs = to be added.

 

 

SUGGESTED RESOLUTION:  Add = ‘nativeSessionId’, quality ‘netconfSessionId’ and extend key

----------------------------------------------------= ------------------------------------

 

Per Andy’s suggestion, refine = ManagementSessionInfo, changing section 2.1.4 and model:

 

session

       = |_netconfSessionId (key)

 |_associatedSession = (key)

       = |_transport

       = |_protocol

       = |_username

       = |_sourceHost

       = |_loginTime

 

netconfSessionId (type: = SessionId)

     NETCONF identifier for = the session.

     This is the unique = sessionId used for all NETCONF operations.

     This is not guaranteed = to be unique for non-NETCONF sessions.

 

associatedSession (type: string)

     Identifer used within = NETCONF to associate to the native session in non-NETCONF protocol.

     For NETCONF sessions = the value MUST match netconfSessionid.

     For non-NETCONF = sessions, when a native session identifier is available this value should be the equal = (string equivalent).  It is expected this value will be unique when = available for each reported particular protocol type.

     For non-NETCONF = sessions, when a native session identifier is not available (e.g. sessionless protocol) = and the NETCONF implementation chooses to report the sessions it MUST provide an = associated session Id value.     

     The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be = unique in all cases.

     xs:string is chosen to = allow mapping to multiple native datatypes.

 

 

cheers,

mark

------_=_NextPart_001_01C9CF38.D22DCA35-- From mbj@tail-f.com Thu May 7 11:10:01 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C571D3A6E11 for ; Thu, 7 May 2009 11:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRfdCZwrDauE for ; Thu, 7 May 2009 11:10:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DDBDE3A6C73 for ; Thu, 7 May 2009 11:10:00 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F13876C5A1; Thu, 7 May 2009 20:11:28 +0200 (CEST) Date: Thu, 07 May 2009 20:11:27 +0200 (CEST) Message-Id: <20090507.201127.62103382.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A02F4E4.8030004@netconfcentral.com> References: <4A02EEAF.70803@netconfcentral.com> <20090507.163516.242267381.mbj@tail-f.com> <4A02F4E4.8030004@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 18:10:01 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Re sessionId usage, I think it is unfortunate that 4741 says that if > > the protocol is not netconf, a session id 0 is used. I interpret this > > as MUST be used, but maybe that was not the intention? For systems > > that have a common session handling for all management protocols, this > > is a bit too restrictive. > > > > This was done to prevent a requirement > that the SNMP and NETCONF agents be coupled. It is one > thing to know the database is locked by another protocol. > It is quite another to share lock-ids and other data with > other protocols. The requirements for this sort of > multi-protocol support need to agreed-upon first. The way the text is written is seems that the requirement is that they MUST NOT be coupled. I think we should allow for both types of systems. If you have NETCONF supporting lock, it is not uncommon to also have a CLI supporting the same locks. > IMO, all this monitoring support for database locks > is fairly worthless. These locks normally last > on the order of milli-seconds or seconds. > If any session is actually interested in writing > the database, they just have to request a lock, > and all the debugging info needed will be returned > in the if the lock cannot be granted. The only required info is the session id (which is 0 if the session happens to be a CLI or WebUI session having the lock). And if it is a human user over the CLI, the lock will probably last longer than a few milliseconds. > (And don't even get me started on the 'value' of knowing > what notification filters other sessions have configured. > I'm still trying to figure out what NM problem that one solves.) +1 /martin From MARKSCOT@nortel.com Thu May 7 11:12:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A413A6F7E for ; Thu, 7 May 2009 11:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EwRoO248ODe for ; Thu, 7 May 2009 11:12:07 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 815F828C31D for ; Thu, 7 May 2009 11:10:47 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n47IBXg18659; Thu, 7 May 2009 18:11:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CF3F.39DC54B5" Date: Thu, 7 May 2009 14:11:20 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031AE74B@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Netconf] Monitoring draft: multi-protocol session monitoring ( Thread-Index: AcnPPzlCX4DaujklTaGWOXW0LsgBBA== From: "Mark Scott" To: "Washam Fan" , "Martin Bjorklund" , , "Juergen Schoenwaelder" Cc: netconf@ietf.org Subject: Re: [Netconf] Monitoring draft: multi-protocol session monitoring ( X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 18:12:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CF3F.39DC54B5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, =20 In response to ML discussion for open item 'multi-protocol session monitoring' in the NETCONF Monitoring draft: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04 =20 Please review the issue and in particular the 'suggested resolution' below and reply with your agreement or suggestion for alternative in an attempt to reach WG consensus on this issue. =20 ISSUE: How to handle monitoring of protocols which don't support session (incl. connectionless) ------------------------------------------------------------------------ ------------------------ =20 Current draft assumes each entry will be unique for NETCONF and non-NETCONF sessions reported via monitoring data. (separate thread on SessionId=3D0 for non-NETCONF and redefining key to handle that). =20 This doesn't explicitly prohibit connectionless protocols but does assumes session oriented connections. In particular the current enumeration includes only values which are expected to be session oriented. =20 SUGGESTED RESOLUTION: Describe expectations for session less entries in monitored data ------------------------------------------------------------------------ ---------------- =20 Redefine sec 2.1.4 and model to clarify the expected session handling (independent of protocol) and provide vendor flexibility to include more protocols per Martin's earlier suggestion (change enumeration to identify): =20 All sessions reported in the monitored session data must resolve to unique ManagementSessionInfo instances. =20 If a NETCONF implementation chooses to report 'session' information for protocols which do not natively have an associated session NETCONF must create the required data to map the monitoring data to the native session equivalent. In particular in cases where NETCONF operations may be extended to manipulate such 'sessions'. =20 Alternatively the NETCONF implementation can choose to exclude these 'sessions' from the monitored data. =20 session |_netconfSessionId (key) |_associatedSession (key) |_transport |_protocol |_username |_sourceHost |_loginTime =20 netconfSessionId (type: SessionId) NETCONF identifier for the session. This is the unique sessionId used for all NETCONF operations. This is not guaranteed to be unique for non-NETCONF sessions. =20 associatedSession (type: string) Identifer used within NETCONF to associate to the native session in non-NETCONF protocol. For NETCONF sessions the value MUST match netconfSessionid. For non-NETCONF sessions, when a native session identifier is available this value should be the equal (string equivalent). It is expected this value will be unique when available for each reported particular protocol type. For non-NETCONF sessions, when a native session identifier is not available (e.g. sessionless protocol) and the NETCONF implementation chooses to report the sessions it MUST provide an associated session Id value. =20 The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be unique in all cases. xs:string is chosen to allow mapping to multiple native datatypes. =20 protocol (type: ProtocolType) Identifies the protocol being used for each session, e.g.: "NETCONF", "CLI", "WebUI". Extensible datatype to allow vendor specific extensions. =20 =20 =20 cheers, Mark ------_=_NextPart_001_01C9CF3F.39DC54B5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

 

In response to ML discussion for open item = ‘multi-protocol session monitoring' in the NETCONF Monitoring draft:  http= ://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

 

Please review the issue and in particular the = 'suggested resolution' below and reply with your agreement or suggestion for = alternative in an attempt to reach WG consensus on this issue.

 

ISSUE:  How to handle monitoring of = protocols which don't support session (incl. connectionless)

----------------------------------------------------= --------------------------------------------

 

Current draft assumes each entry will be unique = for NETCONF and non-NETCONF sessions reported via monitoring data.  (separate = thread on SessionId=3D0 for non-NETCONF and redefining key to handle = that).

 

This doesn’t explicitly prohibit = connectionless protocols but does assumes session oriented connections.  In = particular the current enumeration includes only values which are expected to be = session oriented.

 

SUGGESTED RESOLUTION:  Describe = expectations for session less entries in monitored data

----------------------------------------------------= ------------------------------------

 

Redefine sec 2.1.4 and model to clarify the = expected session handling (independent of protocol) and provide vendor = flexibility to include more protocols per Martin’s earlier suggestion (change enumeration to identify):

 

All sessions reported in the monitored session = data must resolve to unique ManagementSessionInfo instances.

 

If a NETCONF implementation chooses to report = 'session' information for protocols which do not natively have an associated = session NETCONF must create the required data to map the monitoring data to the native = session equivalent.  In particular in cases where NETCONF operations may be extended to manipulate such ‘sessions’.

 

Alternatively the NETCONF implementation can = choose to exclude these ‘sessions’ from the monitored = data.

 

session

       = |_netconfSessionId (key)

 |_associatedSession = (key)

       = |_transport

       = |_protocol

       = |_username

       = |_sourceHost

       = |_loginTime

 

netconfSessionId (type: = SessionId)

     NETCONF identifier for = the session.

     This is the unique = sessionId used for all NETCONF operations.

     This is not guaranteed = to be unique for non-NETCONF sessions.

 

associatedSession (type: string)

     Identifer used within = NETCONF to associate to the native session in non-NETCONF protocol.

     For NETCONF sessions = the value MUST match netconfSessionid.

     For non-NETCONF = sessions, when a native session identifier is available this value should be the equal = (string equivalent).  It is expected this value will be unique when = available for each reported particular protocol type.

     For non-NETCONF = sessions, when a native session identifier is not available (e.g. sessionless protocol) = and the NETCONF implementation chooses to report the sessions it MUST provide an associated session Id value.      =

     The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be = unique in all cases.

     xs:string is chosen to = allow mapping to multiple native datatypes.

 

protocol (type: ProtocolType)

     Identifies the protocol = being used for each session, e.g.: "NETCONF", "CLI", "WebUI".

     Extensible datatype to = allow vendor specific extensions. 

 

 

cheers,

Mark

------_=_NextPart_001_01C9CF3F.39DC54B5-- From j.schoenwaelder@jacobs-university.de Thu May 7 11:39:13 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2963A6FE1 for ; Thu, 7 May 2009 11:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g437iZoJYOfK for ; Thu, 7 May 2009 11:39:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7FC503A6BDE for ; Thu, 7 May 2009 11:39:09 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0D94C01B0; Thu, 7 May 2009 20:40:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ue3144GTP++w; Thu, 7 May 2009 20:40:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31F20C01A3; Thu, 7 May 2009 20:40:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E89EBAE2213; Thu, 7 May 2009 20:40:14 +0200 (CEST) Date: Thu, 7 May 2009 20:40:14 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20090507184014.GB25572@elstar.local> Mail-Followup-To: Mark Scott , "andy@netconfcentral.com" , Washam Fan , Martin Bjorklund , "netconf@ietf.org" References: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Washam Fan , "netconf@ietf.org" Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 18:39:13 -0000 On Thu, May 07, 2009 at 07:24:55PM +0200, Mark Scott wrote: > Suggestions to use a tuple of existing fields were considered. In > particular the use of sessionId, protocol and sourceHost but this > doesn't guarantee uniqueness either. More fields (like loginTime) > could be included but may lead to an increasing complex key as more > protocols (and more issues of uniqueness) are monitored. I assume that every management server (your snmpd, the clid, the netconfd, ...) running on a device can be expected to provide its own unique sessionID. The problem pops up when you expect that all these sessionIDs are unique - this is IMHO an unrealistic assumption. So in order to be save, a combination of a process id and a session id will likely work in most practical cases (and I fail to see why you want to consider things such a sourceHost). > It is agreed we do want to keep the ability to report non-NETCONF > sessions so a method to ensure uniqueness for non-NETCONF entries > needs to be added. Not sure everybody is convinced all these objects are really needed to solve actual management problems. /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.com Thu May 7 11:42:40 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A513A6B6C for ; Thu, 7 May 2009 11:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9dsDwlERTDR for ; Thu, 7 May 2009 11:42:39 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 81A6D3A6358 for ; Thu, 7 May 2009 11:42:39 -0700 (PDT) Received: (qmail 10467 invoked from network); 7 May 2009 18:44:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2009 18:44:04 -0000 X-YMail-OSG: .Qb5gu8VM1mrg1YStURzGzmGLB_6p.g7sqRZ5abUBWc60eWB0QP.eQKyhVpcL.P7PsoibhxbJzWkr6TyTBP_q9lM7HA5dq0MJoyjtpauOeGvTYhu248fL8VPeblX8_EwBJsoV5mGFRvIy9aYdwxpwheQbs0MIA3dFAr0qovtYY_SIalZ8eF3wlrWeEhKiJ1ElMzHgWF7j7XhDFsSwU4C0F9Jk_ig1gN9w7Gpwe03a8B2CnI1pUTFVAf3r.NtEgucdT4ProcRhhyT5MAfJ8K8jThQIz0Itvqs_JS2BGMMsbjI.n8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A032BF3.7030009@netconfcentral.com> Date: Thu, 07 May 2009 11:44:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Scott References: <238C6E77EA42504DA038BAEE6D1C11EC031AE74B@zcarhxm0.corp.nortel.com> In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC031AE74B@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Washam Fan , netconf@ietf.org Subject: Re: [Netconf] Monitoring draft: multi-protocol session monitoring ( X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 18:42:40 -0000 Mark Scott wrote: > Hello, > > > > In response to ML discussion for open item ‘multi-protocol session > monitoring' in the NETCONF Monitoring draft: > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04 > > > > Please review the issue and in particular the 'suggested resolution' > below and reply with your agreement or suggestion for alternative in an > attempt to reach WG consensus on this issue. > > > > ISSUE: How to handle monitoring of protocols which don't support > session (incl. connectionless) > > ------------------------------------------------------------------------------------------------ > > > > Current draft assumes each entry will be unique for NETCONF and > non-NETCONF sessions reported via monitoring data. (separate thread on > SessionId=0 for non-NETCONF and redefining key to handle that). > > > > This doesn’t explicitly prohibit connectionless protocols but does > assumes session oriented connections. In particular the current > enumeration includes only values which are expected to be session oriented. > > > > SUGGESTED RESOLUTION: Describe expectations for session less entries in > monitored data > > ---------------------------------------------------------------------------------------- > > > > Redefine sec 2.1.4 and model to clarify the expected session handling > (independent of protocol) and provide vendor flexibility to include more > protocols per Martin’s earlier suggestion (change enumeration to identify): > > > > All sessions reported in the monitored session data must resolve to > unique ManagementSessionInfo instances. > > > > If a NETCONF implementation chooses to report 'session' information for > protocols which do not natively have an associated session NETCONF must > create the required data to map the monitoring data to the native > session equivalent. In particular in cases where NETCONF operations may > be extended to manipulate such ‘sessions’. > > > > Alternatively the NETCONF implementation can choose to exclude these > ‘sessions’ from the monitored data. > > > > session > > |_netconfSessionId (key) > > |_associatedSession (key) > The current table is defined incorrectly. The key is a SessionId, not SessionIdOrZero. All non-zero numbers are NETCONF sessions. The zero index is not allowed (range 1..max). This extra layer of indexing does not actually help at all. Since all non-NETCONF sessionId values are forced to be zero, all the 'associatedSession' strings will share the same instance naming space. It is important to maintain backward compatibility with RFC 4741, unless the NETCONF WG is deciding not to support RFC 4741 (!). In that case, this data model can be shelved until RFC4741-bis is published. The same behavior is achieved with 1 index, which is a union of a SessionId and a string, as I proposed earlier. Use of identities is only interesting if there are a set of standard identity 'enums' defined. If they are all vendor-defined, then a string is good enough. Andy > |_transport > > |_protocol > > |_username > > |_sourceHost > > |_loginTime > > > > netconfSessionId (type: SessionId) > > NETCONF identifier for the session. > > This is the unique sessionId used for all NETCONF operations. > > This is not guaranteed to be unique for non-NETCONF sessions. > > > > associatedSession (type: string) > > Identifer used within NETCONF to associate to the native session in > non-NETCONF protocol. > > For NETCONF sessions the value MUST match netconfSessionid. > > For non-NETCONF sessions, when a native session identifier is > available this value should be the equal (string equivalent). It is > expected this value will be unique when available for each reported > particular protocol type. > > For non-NETCONF sessions, when a native session identifier is not > available (e.g. sessionless protocol) and the NETCONF implementation > chooses to report the sessions it MUST provide an associated session Id > value. > > The key for the ManagementSessionInfo (netconfSessionId + > associatedSessionId) MUST be unique in all cases. > > xs:string is chosen to allow mapping to multiple native datatypes. > > > > protocol (type: ProtocolType) > > Identifies the protocol being used for each session, e.g.: > "NETCONF", "CLI", "WebUI". > > Extensible datatype to allow vendor specific extensions. > > > > > > cheers, > > Mark > From MARKSCOT@nortel.com Thu May 7 13:23:03 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D575E3A6A7C for ; Thu, 7 May 2009 13:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMpkIyZAY3FH for ; Thu, 7 May 2009 13:23:02 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 999DF3A6A3C for ; Thu, 7 May 2009 13:23:02 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n47KMuo27721; Thu, 7 May 2009 20:22:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 16:23:43 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031FED4A@zcarhxm0.corp.nortel.com> In-reply-to: <20090507184014.GB25572@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution Thread-Index: AcnPQ1WVZgz5I4mXT++57pzCPw6/GQAC3zwQ References: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> <20090507184014.GB25572@elstar.local> From: "Mark Scott" To: "Juergen Schoenwaelder" Cc: Washam Fan , netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 20:23:03 -0000 I wasn't suggesting we use sourceHost - quite the opposite actually. I don't see how using process Id solves this problem any better. In some implementations multiple sessions could be handled by the same process (or group of processes) for a given protocol. So if I take session mgmt as a use case here - in our implementation we'd return the actual unique session id for the specified protocol. This allows us to target a specific session for mgmt operations independent of which process(es) are servicing that session. If another implementation wants to provide a process id, and is satisfied with killing the process that can be done as well. So I think 'associatedSessionId' covers both cases and is more extensible to handle others. Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, May 07, 2009 2:40 PM To: Scott, Mark (CAR:2N00) Cc: andy@netconfcentral.com; Washam Fan; Martin Bjorklund; netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution On Thu, May 07, 2009 at 07:24:55PM +0200, Mark Scott wrote: =20 > Suggestions to use a tuple of existing fields were considered. In > particular the use of sessionId, protocol and sourceHost but this > doesn't guarantee uniqueness either. More fields (like loginTime) > could be included but may lead to an increasing complex key as more > protocols (and more issues of uniqueness) are monitored. I assume that every management server (your snmpd, the clid, the netconfd, ...) running on a device can be expected to provide its own unique sessionID. The problem pops up when you expect that all these sessionIDs are unique - this is IMHO an unrealistic assumption. So in order to be save, a combination of a process id and a session id will likely work in most practical cases (and I fail to see why you want to consider things such a sourceHost). > It is agreed we do want to keep the ability to report non-NETCONF > sessions so a method to ensure uniqueness for non-NETCONF entries > needs to be added. Not sure everybody is convinced all these objects are really needed to solve actual management problems. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From shikhar@schmizz.net Thu May 7 13:23:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB283A6C48 for ; Thu, 7 May 2009 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=2.356, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cc-tVXtVKiH for ; Thu, 7 May 2009 13:23:24 -0700 (PDT) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 963563A6BCE for ; Thu, 7 May 2009 13:23:24 -0700 (PDT) Received: by bwz22 with SMTP id 22so1000832bwz.37 for ; Thu, 07 May 2009 13:24:49 -0700 (PDT) Received: by 10.103.221.5 with SMTP id y5mr491790muq.57.1241727889700; Thu, 07 May 2009 13:24:49 -0700 (PDT) Received: from munch.localnet (deimos.jacobs-university.de [212.201.44.249]) by mx.google.com with ESMTPS id n10sm197340mue.47.2009.05.07.13.24.48 (version=SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 13:24:49 -0700 (PDT) From: shikhar To: netconf@ietf.org Date: Thu, 7 May 2009 22:24:17 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.29-ARCH; KDE/4.2.2; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905072224.17190.shikhar@schmizz.net> Subject: [Netconf] Monitoring draft / error in example X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 20:23:25 -0000 Mismatched element in Example 4.1: -- /shikhar From MARKSCOT@nortel.com Thu May 7 13:40:00 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5146E3A6EB9 for ; Thu, 7 May 2009 13:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnnYwxWjQrSs for ; Thu, 7 May 2009 13:39:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 190C63A6802 for ; Thu, 7 May 2009 13:39:58 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n47Kejg00217; Thu, 7 May 2009 20:40:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 16:40:32 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031FED98@zcarhxm0.corp.nortel.com> In-reply-to: <4A032BF3.7030009@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Monitoring draft: multi-protocol session monitoring ( Thread-Index: AcnPQ9GDLqUEUJZ6Rde+c5kRNkjITwADijFA References: <238C6E77EA42504DA038BAEE6D1C11EC031AE74B@zcarhxm0.corp.nortel.com> <4A032BF3.7030009@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" Cc: Washam Fan , netconf@ietf.org Subject: Re: [Netconf] Monitoring draft: multi-protocol session monitoring ( X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 20:40:00 -0000 Andy, I don't consider compatibility with 4741 to be negotiable. This model must work with 4741 and 4741bis. Independent of whether sessionId=3D0 for non-NETCONF ever changes our current proposal covers = it. No? As for the data type I'm not opinionated on whether this is done with a union but leaving it separate seems simpler to me. In any case the contents of the additional string need to be well defined in the implementation (incl. name space uniqueness) to be of use to the manager. Mark -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com]=20 Sent: Thursday, May 07, 2009 2:44 PM To: Scott, Mark (CAR:2N00) Cc: Washam Fan; Martin Bjorklund; Juergen Schoenwaelder; netconf@ietf.org Subject: Re: [Netconf] Monitoring draft: multi-protocol session monitoring ( Mark Scott wrote: > Hello, >=20 > =20 >=20 > In response to ML discussion for open item 'multi-protocol session=20 > monitoring' in the NETCONF Monitoring draft: =20 > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04 >=20 > =20 >=20 > Please review the issue and in particular the 'suggested resolution'=20 > below and reply with your agreement or suggestion for alternative in an=20 > attempt to reach WG consensus on this issue. >=20 > =20 >=20 > ISSUE: How to handle monitoring of protocols which don't support=20 > session (incl. connectionless) >=20 > ------------------------------------------------------------------------ ------------------------ >=20 > =20 >=20 > Current draft assumes each entry will be unique for NETCONF and=20 > non-NETCONF sessions reported via monitoring data. (separate thread on=20 > SessionId=3D0 for non-NETCONF and redefining key to handle that). >=20 > =20 >=20 > This doesn't explicitly prohibit connectionless protocols but does=20 > assumes session oriented connections. In particular the current=20 > enumeration includes only values which are expected to be session oriented. >=20 > =20 >=20 > SUGGESTED RESOLUTION: Describe expectations for session less entries in=20 > monitored data >=20 > ------------------------------------------------------------------------ ---------------- >=20 > =20 >=20 > Redefine sec 2.1.4 and model to clarify the expected session handling=20 > (independent of protocol) and provide vendor flexibility to include more=20 > protocols per Martin's earlier suggestion (change enumeration to identify): >=20 > =20 >=20 > All sessions reported in the monitored session data must resolve to=20 > unique ManagementSessionInfo instances. >=20 > =20 >=20 > If a NETCONF implementation chooses to report 'session' information for=20 > protocols which do not natively have an associated session NETCONF must=20 > create the required data to map the monitoring data to the native=20 > session equivalent. In particular in cases where NETCONF operations may=20 > be extended to manipulate such 'sessions'. >=20 > =20 >=20 > Alternatively the NETCONF implementation can choose to exclude these=20 > 'sessions' from the monitored data. >=20 > =20 >=20 > session >=20 > |_netconfSessionId (key) >=20 > |_associatedSession (key) >=20 The current table is defined incorrectly. The key is a SessionId, not SessionIdOrZero. All non-zero numbers are NETCONF sessions. The zero index is not allowed (range 1..max). This extra layer of indexing does not actually help at all. Since all non-NETCONF sessionId values are forced to be zero, all the 'associatedSession' strings will share the same instance naming space. It is important to maintain backward compatibility with RFC 4741, unless the NETCONF WG is deciding not to support RFC 4741 (!). In that case, this data model can be shelved until RFC4741-bis is published. The same behavior is achieved with 1 index, which is a union of a SessionId and a string, as I proposed earlier. Use of identities is only interesting if there are a set of standard identity 'enums' defined. If they are all vendor-defined, then a string is good enough. Andy > |_transport >=20 > |_protocol >=20 > |_username >=20 > |_sourceHost >=20 > |_loginTime >=20 > =20 >=20 > netconfSessionId (type: SessionId) >=20 > NETCONF identifier for the session. >=20 > This is the unique sessionId used for all NETCONF operations. >=20 > This is not guaranteed to be unique for non-NETCONF sessions. >=20 > =20 >=20 > associatedSession (type: string) >=20 > Identifer used within NETCONF to associate to the native session in=20 > non-NETCONF protocol. >=20 > For NETCONF sessions the value MUST match netconfSessionid. >=20 > For non-NETCONF sessions, when a native session identifier is=20 > available this value should be the equal (string equivalent). It is=20 > expected this value will be unique when available for each reported=20 > particular protocol type. >=20 > For non-NETCONF sessions, when a native session identifier is not > available (e.g. sessionless protocol) and the NETCONF implementation=20 > chooses to report the sessions it MUST provide an associated session Id=20 > value. =20 >=20 > The key for the ManagementSessionInfo (netconfSessionId +=20 > associatedSessionId) MUST be unique in all cases. >=20 > xs:string is chosen to allow mapping to multiple native datatypes. >=20 > =20 >=20 > protocol (type: ProtocolType) >=20 > Identifies the protocol being used for each session, e.g.:=20 > "NETCONF", "CLI", "WebUI". >=20 > Extensible datatype to allow vendor specific extensions.=20 >=20 > =20 >=20 > =20 >=20 > cheers, >=20 > Mark >=20 From MARKSCOT@nortel.com Thu May 7 13:42:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1A53A70A1 for ; Thu, 7 May 2009 13:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiR8YNhytl9H for ; Thu, 7 May 2009 13:42:32 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E99BE3A6801 for ; Thu, 7 May 2009 13:42:31 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n47Khug00913; Thu, 7 May 2009 20:43:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 16:42:30 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC031FEDA4@zcarhxm0.corp.nortel.com> In-reply-to: <200905072224.17190.shikhar@schmizz.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Monitoring draft / error in example Thread-Index: AcnPUeRONQ6lYcIjS4e/UxhRS4gWigAAmfYQ References: <200905072224.17190.shikhar@schmizz.net> From: "Mark Scott" To: "shikhar" , Subject: Re: [Netconf] Monitoring draft / error in example X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 20:42:33 -0000 Thanks. This will be fixed in v05. -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of shikhar Sent: Thursday, May 07, 2009 4:24 PM To: netconf@ietf.org Subject: [Netconf] Monitoring draft / error in example Mismatched element in Example 4.1: --=20 /shikhar _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Thu May 7 13:44:07 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AFA3A6801 for ; Thu, 7 May 2009 13:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZpc-TJ8sSZ0 for ; Thu, 7 May 2009 13:44:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 248ED3A6E3E for ; Thu, 7 May 2009 13:44:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06D33C01A6; Thu, 7 May 2009 22:45:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oJkSZ3rBnoTJ; Thu, 7 May 2009 22:45:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29EC7C01A3; Thu, 7 May 2009 22:45:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 44455AE2607; Thu, 7 May 2009 22:45:12 +0200 (CEST) Date: Thu, 7 May 2009 22:45:12 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20090507204512.GA25865@elstar.local> Mail-Followup-To: Mark Scott , "andy@netconfcentral.com" , Washam Fan , Martin Bjorklund , "netconf@ietf.org" References: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> <20090507184014.GB25572@elstar.local> <238C6E77EA42504DA038BAEE6D1C11EC031FED4A@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC031FED4A@zcarhxm0.corp.nortel.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Washam Fan , "netconf@ietf.org" Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 20:44:07 -0000 On Thu, May 07, 2009 at 10:23:43PM +0200, Mark Scott wrote: > I don't see how using process Id solves this problem any better. In > some implementations multiple sessions could be handled by the same > process (or group of processes) for a given protocol. I assume a process id is unique on a given device and I assume a process is able to generate session ids that are unique with the process. > So if I take session mgmt as a use case here - in our implementation > we'd return the actual unique session id for the specified protocol. > This allows us to target a specific session for mgmt operations > independent of which process(es) are servicing that session. Protocol does not work in general; I can happily run multiple SNMP agents or NETCONF server on a single Unix machine using different port numbers. > If another implementation wants to provide a process id, and is > satisfied with killing the process that can be done as well. This is not what I suggested. But then I share to some extend Andy's reservations concerning how useful or essential all this really is. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From shikhar@schmizz.net Thu May 7 17:38:51 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D853A6FC4 for ; Thu, 7 May 2009 17:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eHnCZ4Er8od for ; Thu, 7 May 2009 17:38:50 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 43AC43A6C5E for ; Thu, 7 May 2009 17:38:50 -0700 (PDT) Received: by fxm2 with SMTP id 2so1114635fxm.37 for ; Thu, 07 May 2009 17:40:16 -0700 (PDT) Received: by 10.103.233.12 with SMTP id k12mr1990466mur.108.1241743216117; Thu, 07 May 2009 17:40:16 -0700 (PDT) Received: from munch.localnet (deimos.jacobs-university.de [212.201.44.249]) by mx.google.com with ESMTPS id s10sm688189muh.57.2009.05.07.17.40.15 (version=SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 17:40:15 -0700 (PDT) From: shikhar To: netconf@ietf.org Date: Fri, 8 May 2009 02:39:59 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.29-ARCH; KDE/4.2.2; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-00=_f93AK+du7QXSBY6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905080239.59964.shikhar@schmizz.net> Subject: [Netconf] :writable-running X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 00:38:51 -0000 --Boundary-00=_f93AK+du7QXSBY6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, With regard to the :writable-running capability, under 'modifications to existing operations' only and are indicated. Shouldn't and also be mentioned here? Although; the example in the text has as target -- was it the intention to allow running datastore to be locked even without :writable- running? -- /shikhar --Boundary-00=_f93AK+du7QXSBY6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi,


With regard to the :writable-running capability, under 'modifications to existing operations' only <edit-config> and <copy-config> are indicated. Shouldn't <lock> and <unlock> also be mentioned here?


Although; the <lock> example in the text has <running/> as target -- was it the intention to allow running datastore to be locked even without :writable-running?


--
/shikhar

--Boundary-00=_f93AK+du7QXSBY6-- From Washam.Fan@huaweisymantec.com Thu May 7 20:41:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8583A6823 for ; Thu, 7 May 2009 20:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_26=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhuYaTlNVUFL for ; Thu, 7 May 2009 20:41:37 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 522CF3A6C9A for ; Thu, 7 May 2009 20:41:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJB001QX3N15O30@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 08 May 2009 11:42:41 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJB00A3H3MZMC00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 08 May 2009 11:42:37 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 08 May 2009 11:42:35 +0800 From: WashamFan To: Mark Scott Message-id: Date: Fri, 08 May 2009 11:42:35 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> References: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> Cc: Washam Fan , netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 03:41:37 -0000 Hi, Mark I am not sure if you can receive this email since your spam blocked me last time. [Please keep the sentence above if you reply this email. Thanks ;)] > It is agreed we do want to keep the ability to report non-NETCONF > sessions so a method to ensure uniqueness for non-NETCONF entries needs > to be added. It seems to me that Andy and Juergen doubts multi-protocol support. Have there been consensus on the issue? Personally, I can live with it. > > SUGGESTED RESOLUTION: Add 'nativeSessionId', quality 'netconfSessionId' > and extend key > > ------------------------------------------------------------------------ > ---------------- > > > > Per Andy's suggestion, refine ManagementSessionInfo, changing section > 2.1.4 and model: > > > > session > > |_netconfSessionId (key) > > |_associatedSession (key) > > |_transport > > |_protocol > > |_username > > |_sourceHost > > |_loginTime > > > > netconfSessionId (type: SessionId) > > NETCONF identifier for the session. > > This is the unique sessionId used for all NETCONF operations. > > This is not guaranteed to be unique for non-NETCONF sessions. I am curious about how to assign the value to non-Netconf sessions, could you elaborate? > > associatedSession (type: string) > > Identifer used within NETCONF to associate to the native session > in > non-NETCONF protocol. > > For NETCONF sessions the value MUST match netconfSessionid. > > For non-NETCONF sessions, when a native session identifier is > available this value should be the equal (string equivalent). It is > expected this value will be unique when available for each reported > particular protocol type. > > For non-NETCONF sessions, when a native session identifier is not > available (e.g. sessionless protocol) and the NETCONF implementation > chooses to report the sessions it MUST provide an associated session > Id > value. > > The key for the ManagementSessionInfo (netconfSessionId + > associatedSessionId) MUST be unique in all cases. > > xs:string is chosen to allow mapping to multiple native datatypes. As you mentioned, the purpose of multi-protocol sessions monitoring is to interact with non-Netconf sessions via Netconf. What kind of interaction do you expect? And how to do the interaction with ManagementSessionInfo? [ If is an option, we should figure out whether extending to terminate non-Netconf sessions violates 4741 or 4741bis. ] washam From phil@juniper.net Fri May 8 06:28:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED233A7177 for ; Fri, 8 May 2009 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VnxcenAULS2 for ; Fri, 8 May 2009 06:28:07 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 69FD228C172 for ; Fri, 8 May 2009 06:28:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSgQztnhq5jNJZXCaxKuER8LzjU93wfFN@postini.com; Fri, 08 May 2009 06:29:36 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 8 May 2009 06:06:25 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 06:06:25 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 06:06:24 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 May 2009 06:06:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n48D6NL49742; Fri, 8 May 2009 06:06:23 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n48CuHME003711; Fri, 8 May 2009 12:56:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905081256.n48CuHME003711@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090507.201127.62103382.mbj@tail-f.com> Date: Fri, 8 May 2009 08:56:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 May 2009 13:06:24.0038 (UTC) FILETIME=[C9FE5460:01C9CFDD] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 13:28:08 -0000 Martin Bjorklund writes: >> (And don't even get me started on the 'value' of knowing >> what notification filters other sessions have configured. >> I'm still trying to figure out what NM problem that one solves.) > >+1 +1 Can we please remove it? Thanks, Phil From Washam.Fan@huaweisymantec.com Sun May 10 20:11:57 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2CC3A6F16 for ; Sun, 10 May 2009 20:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[AWL=-1.527, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTeNTRHjBBK3 for ; Sun, 10 May 2009 20:11:57 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 42ADB3A684E for ; Sun, 10 May 2009 20:11:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJG0022IMA1GB40@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Mon, 11 May 2009 11:13:16 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJG00B3AM9YT100@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 11 May 2009 11:13:12 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 11 May 2009 11:13:10 +0800 From: WashamFan To: shikhar Message-id: Date: Mon, 11 May 2009 11:13:10 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <200905080239.59964.shikhar@schmizz.net> References: <200905080239.59964.shikhar@schmizz.net> Cc: netconf@ietf.org Subject: Re: [Netconf] :writable-running X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 03:11:57 -0000 > With regard to the :writable-running capability, under 'modifications > to > existing operations' only and are > indicated. > Shouldn't and also be mentioned here? > > Although; the example in the text has as target -- > was it > the intention to allow running datastore to be locked even without :writable- > running? To my understanding, it is allowed to lock without :writable-running as lock does not mean modifying definitely. Given session A with :candidate and session B with :writable-running, it is beneficial for session A to lock both and for consistency. washam From MARKSCOT@nortel.com Mon May 11 11:20:13 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFF03A6C75 for ; Mon, 11 May 2009 11:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo3sRpjUK0q2 for ; Mon, 11 May 2009 11:20:12 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7B17D3A68BD for ; Mon, 11 May 2009 11:20:12 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4BIKdD17311; Mon, 11 May 2009 18:20:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 May 2009 14:21:36 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D19101A8C@zcarhxm0.corp.nortel.com> In-reply-to: <200905081256.n48CuHME003711@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] sessionId issue Thread-Index: AcnP4Qw+8yl+X1vGTlmQY7rVTVIIgwCgk7rg References: <20090507.201127.62103382.mbj@tail-f.com> <200905081256.n48CuHME003711@idle.juniper.net> From: "Mark Scott" To: "Phil Shafer" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 18:20:13 -0000 Agreed. The subscriptions subtree (sec 2.1.5) will be removed. Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer Sent: Friday, May 08, 2009 8:56 AM To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue Martin Bjorklund writes: >> (And don't even get me started on the 'value' of knowing >> what notification filters other sessions have configured. >> I'm still trying to figure out what NM problem that one solves.) > >+1 +1 Can we please remove it? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From MARKSCOT@nortel.com Mon May 11 11:56:21 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127853A6D8D for ; Mon, 11 May 2009 11:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YshkJjXh2iql for ; Mon, 11 May 2009 11:56:20 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 496BA3A6957 for ; Mon, 11 May 2009 11:56:10 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4BIusu02068; Mon, 11 May 2009 18:56:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 May 2009 14:56:47 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> In-reply-to: <20090507204512.GA25865@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution Thread-Index: AcnPVMdsuXTvGrUYRnmVQ9SDFJefiwDEKB0w References: <238C6E77EA42504DA038BAEE6D1C11EC031AE5F7@zcarhxm0.corp.nortel.com> <20090507184014.GB25572@elstar.local> <238C6E77EA42504DA038BAEE6D1C11EC031FED4A@zcarhxm0.corp.nortel.com> <20090507204512.GA25865@elstar.local> From: "Mark Scott" To: "Juergen Schoenwaelder" Cc: Washam Fan , netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 18:56:21 -0000 Thank you Juergen, Agree with your assumptions. For non-NETCONF the 'netconfSessionId=3D0' is of limited value so reverting back to protocol-neutral 'sessionId' and adding 'processId' yields: session |_sessionId (key) |_processId (key) |_transport |_protocol |_username |_sourceHost |_loginTime sessionId (type: SessionId) Identifier for the session. For session oriented protocols this is assumed to be unique for the associated processId. processId (xs: unsignedInt) Unique process identifier of the management server/agent associated with the session. So this is current proposal unless someone can identify issues for their implementation with this approach. cheers, Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, May 07, 2009 4:45 PM To: Scott, Mark (CAR:2N00) Cc: andy@netconfcentral.com; Washam Fan; Martin Bjorklund; netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution On Thu, May 07, 2009 at 10:23:43PM +0200, Mark Scott wrote: =20 > I don't see how using process Id solves this problem any better. In > some implementations multiple sessions could be handled by the same > process (or group of processes) for a given protocol. I assume a process id is unique on a given device and I assume a process is able to generate session ids that are unique with the process. > So if I take session mgmt as a use case here - in our implementation > we'd return the actual unique session id for the specified protocol. > This allows us to target a specific session for mgmt operations > independent of which process(es) are servicing that session. Protocol does not work in general; I can happily run multiple SNMP agents or NETCONF server on a single Unix machine using different port numbers. > If another implementation wants to provide a process id, and is > satisfied with killing the process that can be done as well. This is not what I suggested. But then I share to some extend Andy's reservations concerning how useful or essential all this really is. /js --=20 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 Mon May 11 12:34:46 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF453A68E8 for ; Mon, 11 May 2009 12:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrQuWVVD+7yv for ; Mon, 11 May 2009 12:34:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A18D93A68D7 for ; Mon, 11 May 2009 12:34:45 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 803C476C040; Mon, 11 May 2009 21:36:13 +0200 (CEST) Date: Mon, 11 May 2009 21:36:13 +0200 (CEST) Message-Id: <20090511.213613.65760350.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> References: <238C6E77EA42504DA038BAEE6D1C11EC031FED4A@zcarhxm0.corp.nortel.com> <20090507204512.GA25865@elstar.local> <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, washam.fan@huawei.com Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 19:34:46 -0000 Hi, "Mark Scott" wrote: > Thank you Juergen, > > Agree with your assumptions. For non-NETCONF the 'netconfSessionId=0' > is of limited value so reverting back to protocol-neutral 'sessionId' > and adding 'processId' yields: > > session > |_sessionId (key) > |_processId (key) Juergen Schoenwaelder wrote: > I assume a process id is unique on a given device and I assume a > process is able to generate session ids that are unique with the > process. I do not agree with these assumptions, and I think the resulting proposal is not optimal. Some systems do not have processes, and others may implement multiple independent subapplications within one OS process. I don't think there is a real requirement that this must be a OS process identifier though - so changing this to some more generic identifier would solve that problem (and some implementations may just use the OS pid value for this field). My other issue is with having both of these fields as key. Suppose I know from the NETCONF agent that NETCONF session id 5 exists. Now I want to look it up in this table. How would I do that - I don't know the process id. So I'd have to filter the table, but even so, the design allows for multiple entries with session id 5. I think both proposals from Andy (union) and Juergen (two keys; protocol and identifier) would work better. In both cases it would be up to the other (non-netconf) protocols to figure out how to handle multiple instances running on the same device. /martin From j.schoenwaelder@jacobs-university.de Mon May 11 12:50:02 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD8C3A6D9D for ; Mon, 11 May 2009 12:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lfKEb9bKscP for ; Mon, 11 May 2009 12:50:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B4E543A6D8B for ; Mon, 11 May 2009 12:50:01 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25EBEC0054; Mon, 11 May 2009 21:51:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ogMlH1fZrCab; Mon, 11 May 2009 21:51:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 918C5C0005; Mon, 11 May 2009 21:51:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 49A14AE735D; Mon, 11 May 2009 21:51:10 +0200 (CEST) Date: Mon, 11 May 2009 21:51:10 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090511195110.GA2575@elstar.local> Mail-Followup-To: Martin Bjorklund , "markscot@nortel.com" , "andy@netconfcentral.com" , "washam.fan@huawei.com" , "netconf@ietf.org" References: <238C6E77EA42504DA038BAEE6D1C11EC031FED4A@zcarhxm0.corp.nortel.com> <20090507204512.GA25865@elstar.local> <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> <20090511.213613.65760350.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090511.213613.65760350.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "washam.fan@huawei.com" , "netconf@ietf.org" Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 19:50:02 -0000 On Mon, May 11, 2009 at 09:36:13PM +0200, Martin Bjorklund wrote: > I think both proposals from Andy (union) and Juergen (two keys; > protocol and identifier) would work better. Protocol and identifier is ambiguous once you have multiple NETCONF server on the same box. But the more important question here is for me: What is the intended usage of these objects? Perhaps once we agree which management problem we are trying to solve, we find it easier to find an appropriate solution. (I mean, even the term session means different things in different management protocols if they might not exist at all. Do we really want to work out a generic abstraction?) /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 Mon May 11 12:57:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B5F3A67E9 for ; Mon, 11 May 2009 12:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiH2tnAr7MhC for ; Mon, 11 May 2009 12:57:40 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 911943A6B16 for ; Mon, 11 May 2009 12:57:40 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0624676C040; Mon, 11 May 2009 21:59:05 +0200 (CEST) Date: Mon, 11 May 2009 21:59:04 +0200 (CEST) Message-Id: <20090511.215904.194263974.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090511195110.GA2575@elstar.local> References: <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> <20090511.213613.65760350.mbj@tail-f.com> <20090511195110.GA2575@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: washam.fan@huawei.com, netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 19:57:41 -0000 Juergen Schoenwaelder wrote: > On Mon, May 11, 2009 at 09:36:13PM +0200, Martin Bjorklund wrote: > > > I think both proposals from Andy (union) and Juergen (two keys; > > protocol and identifier) would work better. > > Protocol and identifier is ambiguous once you have multiple NETCONF > server on the same box. But the more important question here is for > me: > > What is the intended usage of these objects? > > Perhaps once we agree which management problem we are trying to solve, > we find it easier to find an appropriate solution. (I mean, even the > term session means different things in different management protocols > if they might not exist at all. Do we really want to work out a > generic abstraction?) I think one use case is trying to help the operator if he gets a 'lock-denied' error back, pointing to a (presumably) stuck session. Or in general helping the operator track down a session, given the session identifier. I think a solution which allows systems to reply with a session id != 0 also for non-netconf sessions would go a long way (while still allowing other systems to send session id 0 for "unknown" sessions - no requirement for multi protocol session management). Then the key in this table would simply be 'session-id'. /martin From j.schoenwaelder@jacobs-university.de Mon May 11 13:27:23 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1CD63A6A98 for ; Mon, 11 May 2009 13:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD2nhYoZQXex for ; Mon, 11 May 2009 13:27:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6A6D43A67E5 for ; Mon, 11 May 2009 13:27:22 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A26EC0037; Mon, 11 May 2009 22:28:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0vlmo-y8Bv61; Mon, 11 May 2009 22:28:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83587C0030; Mon, 11 May 2009 22:28:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 486C3AE74F2; Mon, 11 May 2009 22:28:31 +0200 (CEST) Date: Mon, 11 May 2009 22:28:31 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090511202831.GA2663@elstar.local> Mail-Followup-To: Martin Bjorklund , "markscot@nortel.com" , "andy@netconfcentral.com" , "washam.fan@huawei.com" , "netconf@ietf.org" References: <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> <20090511.213613.65760350.mbj@tail-f.com> <20090511195110.GA2575@elstar.local> <20090511.215904.194263974.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090511.215904.194263974.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "washam.fan@huawei.com" , "netconf@ietf.org" Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 20:27:23 -0000 On Mon, May 11, 2009 at 09:59:04PM +0200, Martin Bjorklund wrote: > I think one use case is trying to help the operator if he gets a > 'lock-denied' error back, pointing to a (presumably) stuck session. > Or in general helping the operator track down a session, given the > session identifier. So where does the lock live and who maintains it? We seem to assume that the lock is actually not maintained by the NETCONF server itself but by some backend datastore that can be accessed from other protocol engines directly, bypassing the NETCONF server (otherwise there would be a NETCONF session, no?). > I think a solution which allows systems to reply with a > session id != 0 also for non-netconf sessions would go a long way > (while still allowing other systems to send session id 0 for "unknown" > sessions - no requirement for multi protocol session management). > Then the key in this table would simply be 'session-id'. If my assumption above is correct, how does it help the operator if she can figure out there is session 42 holding a lock but there is no way to figure out what 42 actually means? And how do I figure out that 42 is a non-NETCONF session - by trying a kill-session that fails? I fear that we either have a simple table that is pretty useless or we have a pretty difficult problem to solve since the details how locking is done and how multiple protocols work together are so far implementation specific. /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 Mon May 11 14:14:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23423A6A4A for ; Mon, 11 May 2009 14:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B556Uyzoi1lm for ; Mon, 11 May 2009 14:14:16 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 3883A3A68E3 for ; Mon, 11 May 2009 14:14:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSgiVey3RTWJfBymC7B03eEopFGohLevH@postini.com; Mon, 11 May 2009 14:15:47 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 11 May 2009 14:11:11 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 14:11:11 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 14:11:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 14:11:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n4BLB9L01755; Mon, 11 May 2009 14:11:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n4BL0wtK032474; Mon, 11 May 2009 21:00:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200905112100.n4BL0wtK032474@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090511.215904.194263974.mbj@tail-f.com> Date: Mon, 11 May 2009 17:00:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2009 21:11:10.0492 (UTC) FILETIME=[021C3DC0:01C9D27D] MIME-Version: 1.0 Content-Type: text/plain Cc: washam.fan@huawei.com, netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 21:14:17 -0000 Martin Bjorklund writes: >I think a solution which allows systems to reply with a >session id != 0 also for non-netconf sessions would go a long way >(while still allowing other systems to send session id 0 for "unknown" >sessions - no requirement for multi protocol session management). >Then the key in this table would simply be 'session-id'. Would the fix be to put session-id under a container and allow other protocols to augment with their own protocol-specific content? Thanks, Phil From MARKSCOT@nortel.com Mon May 11 14:17:44 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289A83A683E for ; Mon, 11 May 2009 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcBcmxpg2r79 for ; Mon, 11 May 2009 14:17:42 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9D0E23A6821 for ; Mon, 11 May 2009 14:17:42 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4BLITu08876; Mon, 11 May 2009 21:18:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 May 2009 17:18:26 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D19101D86@zcarhxm0.corp.nortel.com> In-reply-to: <20090511202831.GA2663@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution Thread-Index: AcnSdytXrI2GeyP8Suugk9gxwqdS5AAAMinw References: <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> <20090511.213613.65760350.mbj@tail-f.com> <20090511195110.GA2575@elstar.local> <20090511.215904.194263974.mbj@tail-f.com> <20090511202831.GA2663@elstar.local> From: "Mark Scott" To: "Juergen Schoenwaelder" , "Martin Bjorklund" Cc: washam.fan@huawei.com, netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 21:17:44 -0000 Could we mandate that a NETCONF server must provide/map a unique sessionId for all sessions being monitored by it (regardless of protocol)? >From earlier chain trying to propose a way to report on multi-protocol entries: 1. each NETCONF server only reports session data for sessions it can actually manage - 'manage' in this case being defined as being able to meaningfully report on a session (i.e. uniqueness) and/or perform an operation against it (kill-session for example if permissions allow) - acknowledging that returning entries for sessions which this server can't manage is of limited utility anyway 2. each such sessionId would be guaranteed unique in context of the NETCONF server monitoring the session. So whether NETCONF or non-NETCONF each NETCONF server instance has a unique reference for all sessions it is managing. - the sessionId may or may not be unique in context of another NETCONF server or other management protocols on the same node. - of course implementations which can provide globally unique sessionIds and/or align the identifiers with other protocols' equivalents are desirable, but not all implementations can do this. 3. a sessionId=3D0 would not be needed in the table since each = underlying session is mapped to a NETCONF session I think this approach also addresses Andy's earlier concern about 4741 compatibility. =20 For NETCONF implementations which can actually manage non-NETCONF sessions the server effectively creates/associates unique NETCONF session equivalents for these other sessions (and mappings to/from native sessions as required). - An existing client could perform functions against a non-NETCONF session without knowing the underlying ProtocolType is something else. At least for operations such as , , etc which are the main uses for this. For other operations the server would at least return a meaningful error against such non-NETCONF sessions. - a newer client may want to use additional monitored information (i.e. the ProtocolType) to decide what other interface or operations are better suited to a task, but at least has the information provided in the NETCONF interface to know that those other sessions exist Admittedly this puts more effort on a server which chooses to implement this, but simplifies the client. At least we're not passing (an ever growing vendor specific?) list of non-NETCONF session info into to a client who then has to figure out what it means. The focus remains on what the NETCONF server can actually manage and reporting is limited accordingly. Would this be an appropriate assumption to put on NETCONF server implementations? If so, I think we should consider what may also need to be captured in 4741bis for this - esp. if we want to try to define some common handling for creating the associated sessionIds for non-NETCONF sessions. If not, then I think we're back to: "netconfSessionid + associatedSessionIdentifier" as the key, acknowledging that non-NETCONF will have netconfSessionId=3D0 and associatedSessionIdentifer will be implementation specific (process Id, session description, other). Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, May 11, 2009 4:29 PM To: Martin Bjorklund Cc: Scott, Mark (CAR:2N00); andy@netconfcentral.com; washam.fan@huawei.com; netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution On Mon, May 11, 2009 at 09:59:04PM +0200, Martin Bjorklund wrote: =20 > I think one use case is trying to help the operator if he gets a > 'lock-denied' error back, pointing to a (presumably) stuck session. > Or in general helping the operator track down a session, given the > session identifier. So where does the lock live and who maintains it? We seem to assume that the lock is actually not maintained by the NETCONF server itself but by some backend datastore that can be accessed from other protocol engines directly, bypassing the NETCONF server (otherwise there would be a NETCONF session, no?). =20 > I think a solution which allows systems to reply with a > session id !=3D 0 also for non-netconf sessions would go a long way > (while still allowing other systems to send session id 0 for "unknown" > sessions - no requirement for multi protocol session management). > Then the key in this table would simply be 'session-id'. If my assumption above is correct, how does it help the operator if she can figure out there is session 42 holding a lock but there is no way to figure out what 42 actually means? And how do I figure out that 42 is a non-NETCONF session - by trying a kill-session that fails? I fear that we either have a simple table that is pretty useless or we have a pretty difficult problem to solve since the details how locking is done and how multiple protocols work together are so far implementation specific. /js --=20 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.com Mon May 11 14:20:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124B33A6821 for ; Mon, 11 May 2009 14:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpEHIizIub0r for ; Mon, 11 May 2009 14:20:36 -0700 (PDT) Received: from n77.bullet.mail.sp1.yahoo.com (n77.bullet.mail.sp1.yahoo.com [98.136.44.45]) by core3.amsl.com (Postfix) with SMTP id 449643A683E for ; Mon, 11 May 2009 14:20:36 -0700 (PDT) Received: from [216.252.122.219] by n77.bullet.mail.sp1.yahoo.com with NNFMP; 11 May 2009 21:22:05 -0000 Received: from [68.142.200.227] by t4.bullet.sp1.yahoo.com with NNFMP; 11 May 2009 21:22:05 -0000 Received: from [68.142.201.66] by t8.bullet.mud.yahoo.com with NNFMP; 11 May 2009 21:22:05 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 11 May 2009 21:22:05 -0000 X-Yahoo-Newman-Id: 501740.28094.bm@omp418.mail.mud.yahoo.com Received: (qmail 85301 invoked from network); 11 May 2009 21:22:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 21:22:04 -0000 X-YMail-OSG: eBJJiEwVM1kk6s.fXvMcH.MdhCpJ3tvk8Ybg0QVPWme8_TfK8ORiKnStFbKYYWSzp8Gn0KUWfplDwe_iCC_uPj7qNBLOS9G4fkX1EutyWJZF5WvZK5NMOifbAcXibKfzDYKXSMc_iftDhathVPyC8ieBiG.ACC62VcQzYSx30tYONGcHKi2xgqAQheQRIeHFId51YGYnGEldQ1BtBKpJsPSzpGnhRFZALlj5RzN7VX3STbEGzmttsXYEdXn7dBT.YhzyzuaQY8COGfb7RJ3BxNgDa0qF85XXQSeV0_T10FcSK3AlBDY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0896FA.1010809@netconfcentral.com> Date: Mon, 11 May 2009 14:22:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200905112100.n4BL0wtK032474@idle.juniper.net> In-Reply-To: <200905112100.n4BL0wtK032474@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: washam.fan@huawei.com, netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 21:20:37 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> I think a solution which allows systems to reply with a >> session id != 0 also for non-netconf sessions would go a long way >> (while still allowing other systems to send session id 0 for "unknown" >> sessions - no requirement for multi protocol session management). >> Then the key in this table would simply be 'session-id'. > > Would the fix be to put session-id under a container and > allow other protocols to augment with their own protocol-specific > content? > no deep keys! that's a CLR I agree with now. YANG is complicated enough without it -- nothing to do with buffering. > Thanks, > Phil Andy From andy@netconfcentral.com Mon May 11 14:36:14 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117A13A683E for ; Mon, 11 May 2009 14:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWygtfrOo6l9 for ; Mon, 11 May 2009 14:36:13 -0700 (PDT) Received: from n67.bullet.mail.sp1.yahoo.com (n67.bullet.mail.sp1.yahoo.com [98.136.44.47]) by core3.amsl.com (Postfix) with SMTP id 41D7E3A6BC4 for ; Mon, 11 May 2009 14:36:13 -0700 (PDT) Received: from [216.252.122.218] by n67.bullet.mail.sp1.yahoo.com with NNFMP; 11 May 2009 21:37:42 -0000 Received: from [68.142.200.225] by t3.bullet.sp1.yahoo.com with NNFMP; 11 May 2009 21:37:42 -0000 Received: from [68.142.201.69] by t6.bullet.mud.yahoo.com with NNFMP; 11 May 2009 21:37:42 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 11 May 2009 21:37:42 -0000 X-Yahoo-Newman-Id: 419346.33015.bm@omp421.mail.mud.yahoo.com Received: (qmail 52316 invoked from network); 11 May 2009 21:37:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 21:37:41 -0000 X-YMail-OSG: SHngcNoVM1m9QYQdMCh_j7.yXcKHHn9U2vUemraGnkLd.Aw2SMyFmYMl83bubVtYe_xN1OZ3FDcnLbHAsvJYl2RlxgyppfF3MuBIU8zqIrlKPDxHvVd7ib5lp68cz_twoW5fcMMLC3e0HQmGHlSy_UfUp7OAqSAB3mU3cmx_iCJUp47ekhXbHQU9UR7Mv9.A8VO8C_ID0aJTcGKpzYP7Hnn.IyHh7nFy5a0ZVf_J6ZPuo.Z4K_k0D.FGcPP6ZgqjiFjj8I19JVrhML8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A089AA3.2050000@netconfcentral.com> Date: Mon, 11 May 2009 14:37:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund , "markscot@nortel.com" , "washam.fan@huawei.com" , "netconf@ietf.org" References: <085091CB2CA14E4B8B163FFC37C84E9D19101B4B@zcarhxm0.corp.nortel.com> <20090511.213613.65760350.mbj@tail-f.com> <20090511195110.GA2575@elstar.local> <20090511.215904.194263974.mbj@tail-f.com> <20090511202831.GA2663@elstar.local> In-Reply-To: <20090511202831.GA2663@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 21:36:14 -0000 Juergen Schoenwaelder wrote: > On Mon, May 11, 2009 at 09:59:04PM +0200, Martin Bjorklund wrote: > >> I think one use case is trying to help the operator if he gets a >> 'lock-denied' error back, pointing to a (presumably) stuck session. >> Or in general helping the operator track down a session, given the >> session identifier. > > So where does the lock live and who maintains it? We seem to assume > that the lock is actually not maintained by the NETCONF server itself > but by some backend datastore that can be accessed from other protocol > engines directly, bypassing the NETCONF server (otherwise there would > be a NETCONF session, no?). > >> I think a solution which allows systems to reply with a >> session id != 0 also for non-netconf sessions would go a long way >> (while still allowing other systems to send session id 0 for "unknown" >> sessions - no requirement for multi protocol session management). >> Then the key in this table would simply be 'session-id'. > > If my assumption above is correct, how does it help the operator if > she can figure out there is session 42 holding a lock but there is no > way to figure out what 42 actually means? And how do I figure out that > 42 is a non-NETCONF session - by trying a kill-session that fails? > By RFC 4741 rules, 42 would have to be a NETCONF session, so I think that 'orange safety cone' is already in the road. The YANG 'union' was designed for this exact use-case. We want a key leaf, and sometimes it represents one of these things, and other times it represents one of those things... Do we need to back to data modeling 101? The NETCONF agent is going to have to coordinate naming collisions between all non-NETCONF entities. There is no way around that. I do not see why the zero index is not good enough for global locks. People seem to forget that only one global lock at a time can be active. A secondary column for protocol ID can be used -- it does not need to be part of the key. As for reporting all the non-NETCONF partial locks, or global locks either -- I think vendor extensions are good enough unless/until a coherent, well-planned, and chartered multi-protocol management architecture is agreed upon first. An additional standard module can be added later for non-NETCONF database access support. > I fear that we either have a simple table that is pretty useless or we > have a pretty difficult problem to solve since the details how locking > is done and how multiple protocols work together are so far > implementation specific. > +1 > /js > Andy From mbj@tail-f.com Mon May 11 14:46:52 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073113A68E0 for ; Mon, 11 May 2009 14:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNzHhYCgDq7Q for ; Mon, 11 May 2009 14:46:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 382443A6AFC for ; Mon, 11 May 2009 14:46:51 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7B7A376C040; Mon, 11 May 2009 23:47:34 +0200 (CEST) Date: Mon, 11 May 2009 23:47:32 +0200 (CEST) Message-Id: <20090511.234732.101592886.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D19101D86@zcarhxm0.corp.nortel.com> References: <20090511.215904.194263974.mbj@tail-f.com> <20090511202831.GA2663@elstar.local> <085091CB2CA14E4B8B163FFC37C84E9D19101D86@zcarhxm0.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, washam.fan@huawei.com Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 21:46:52 -0000 "Mark Scott" wrote: > Could we mandate that a NETCONF server must provide/map a unique > sessionId for all sessions being monitored by it (regardless of > protocol)? I think what you write is very good, except I would not mandate this mapping. But maybe that's what you meant as well? Servers should report sessionId 0 in errors such as 'lock-denied' for sessions they do not manage (using you terminology). This would allow multi-protocol servers to utilize their capabilities w/o extra vendor specific info for the clients to understand, at the same time as single-protocol servers can still function. For the client, there are no difference - if it gets a valid session id, it can look it up, maybe kill it etc. If it gets session id 0, it knows that it represents some kind of "unknown" session. session id 0 would never show up in the session list. /martin From MARKSCOT@nortel.com Thu May 14 11:27:59 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53823A69E2 for ; Thu, 14 May 2009 11:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh82Uk1jPuj8 for ; Thu, 14 May 2009 11:27:59 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B70043A6800 for ; Thu, 14 May 2009 11:27:58 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4EIRgJ11933; Thu, 14 May 2009 18:27:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2009 14:28:25 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D192221B7@zcarhxm0.corp.nortel.com> In-reply-to: <20090511.234732.101592886.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution Thread-Index: AcnSgjOs48A2T12TRz6QgZzs4radngCPizZA References: <20090511.215904.194263974.mbj@tail-f.com><20090511202831.GA2663@elstar.local><085091CB2CA14E4B8B163FFC37C84E9D19101D86@zcarhxm0.corp.nortel.com> <20090511.234732.101592886.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" Cc: netconf@ietf.org, washam.fan@huawei.com Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 18:27:59 -0000 Yes that's what I meant as well. Basically: - retain sessionId=3D0 for anything 'unknown' but don't report these in the session list - since NETCONF can't do anything meaningful with the session no need to report it other than in errors - for implementations that can do something meaningful (like session mgmt, lock mgmt) then report it in the session list - NETCONF server is responsible for providing a unique sessionId for such mapped sessions - Benefits: - this retains backwards compatibility with 4741 - single unique sessionId key in the table - can work for all protocols Do we have consensus on this? Mark -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Monday, May 11, 2009 5:48 PM To: Scott, Mark (CAR:2N00) Cc: j.schoenwaelder@jacobs-university.de; andy@netconfcentral.com; washam.fan@huawei.com; netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution "Mark Scott" wrote: > Could we mandate that a NETCONF server must provide/map a unique > sessionId for all sessions being monitored by it (regardless of > protocol)? I think what you write is very good, except I would not mandate this mapping. But maybe that's what you meant as well? Servers should report sessionId 0 in errors such as 'lock-denied' for sessions they do not manage (using you terminology). This would allow multi-protocol servers to utilize their capabilities w/o extra vendor specific info for the clients to understand, at the same time as single-protocol servers can still function. For the client, there are no difference - if it gets a valid session id, it can look it up, maybe kill it etc. If it gets session id 0, it knows that it represents some kind of "unknown" session. session id 0 would never show up in the session list. /martin From Washam.Fan@huaweisymantec.com Thu May 14 19:36:43 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43E93A6840 for ; Thu, 14 May 2009 19:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLWucofQuI0z for ; Thu, 14 May 2009 19:36:42 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 019E33A686E for ; Thu, 14 May 2009 19:36:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJN00G7DZAYH720@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 15 May 2009 10:37:48 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJN0091IZAWC200@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 15 May 2009 10:37:46 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 15 May 2009 10:37:44 +0800 From: WashamFan To: netconf@ietf.org Message-id: Date: Fri, 15 May 2009 10:37:44 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <085091CB2CA14E4B8B163FFC37C84E9D192221B7@zcarhxm0.corp.nortel.com> References: <20090511.215904.194263974.mbj@tail-f.com> <20090511202831.GA2663@elstar.local> <085091CB2CA14E4B8B163FFC37C84E9D19101D86@zcarhxm0.corp.nortel.com> <20090511.234732.101592886.mbj@tail-f.com> <085091CB2CA14E4B8B163FFC37C84E9D192221B7@zcarhxm0.corp.nortel.com> Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 02:36:43 -0000 Hi, Mark Please update my email to this account. (Since your spam always blocks my emails from this account, we've lost touch for a quite while. Did you received the email Juergen forwarded for me?) > Yes that's what I meant as well. > > Basically: > - retain sessionId=0 for anything 'unknown' but don't report these in > the session list > - since NETCONF can't do anything meaningful with the session no > need to report it other than in errors I tend to agree. > - for implementations that can do something meaningful (like session > mgmt, lock mgmt) then report it in the session list > - NETCONF server is responsible for providing a unique sessionId > for such mapped sessions > > - Benefits: > - this retains backwards compatibility with 4741 > - single unique sessionId key in the table Do you mean keep the table as it is? Then, Is allowed to terminate a non-Netconf session who has a sessionId in the table? I am afraid the answer is no according to current text in 4741 or 4741bis. If so, how to interact with non-netconf sessions via Netconf? ( And what the interaction exactly are?) I am not opposing the proposal, but just trying to understand. One more thing. Although I issue the topic firstly, but I doubt if there is a consensus on mutiple protocol sessions monitoring. And I think the answers to my questions raised above could justify the issue a little ;) washam > - can work for all protocols > > Do we have consensus on this? > > Mark > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, May 11, 2009 5:48 PM > To: Scott, Mark (CAR:2N00) > Cc: j.schoenwaelder@jacobs-university.de; andy@netconfcentral.com; > washam.fan@huawei.com; netconf@ietf.org > Subject: Re: [Netconf] [NETCONF] Monitoring > draft:sessionIduniquenessproposed resolution > > "Mark Scott" wrote: > > Could we mandate that a NETCONF server must provide/map a unique > > sessionId for all sessions being monitored by it (regardless of > > protocol)? > > I think what you write is very good, except I would not mandate this > mapping. But maybe that's what you meant as well? Servers should > report sessionId 0 in errors such as 'lock-denied' for sessions they > do not manage (using you terminology). This would allow > multi-protocol servers to utilize their capabilities w/o extra vendor > specific info for the clients to understand, at the same time as > single-protocol servers can still function. For the client, there are > no difference - if it gets a valid session id, it can look it up, > maybe kill it etc. If it gets session id 0, it knows that it > represents some kind of "unknown" session. > > session id 0 would never show up in the session list. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From shikhar@schmizz.net Sun May 17 09:50:23 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A53B28C169 for ; Sun, 17 May 2009 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSZTnr7+wXvd for ; Sun, 17 May 2009 09:50:22 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0E60B28C15A for ; Sun, 17 May 2009 09:50:21 -0700 (PDT) Received: by fxm2 with SMTP id 2so2829954fxm.37 for ; Sun, 17 May 2009 09:51:53 -0700 (PDT) Received: by 10.103.6.18 with SMTP id j18mr3518364mui.33.1242579112141; Sun, 17 May 2009 09:51:52 -0700 (PDT) Received: from munch.localnet (deimos.jacobs-university.de [212.201.44.249]) by mx.google.com with ESMTPS id j2sm220459mue.42.2009.05.17.09.51.51 (version=SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 09:51:51 -0700 (PDT) From: shikhar To: netconf@ietf.org Date: Sun, 17 May 2009 18:51:46 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.29-ARCH; KDE/4.2.3; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905171851.46611.shikhar@schmizz.net> Subject: [Netconf] Python client library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 16:50:23 -0000 Dear all, I started a project for a Python library for NETCONF clients. It needs wider testing so I invite you to check out the source code and report any bugs you encounter. The project homepage is . You can find documentation at . In case you have problems please write directly to me or at . Best, Shikhar From balazs.lengyel@ericsson.com Mon May 18 08:33:35 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7293A6A8E for ; Mon, 18 May 2009 08:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9e-XEAj04LL for ; Mon, 18 May 2009 08:33:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 00C393A6BC4 for ; Mon, 18 May 2009 08:33:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-a6-4a11802ba782 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B5.47.02630.B20811A4; Mon, 18 May 2009 17:35:07 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 May 2009 17:35:06 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 May 2009 17:35:05 +0200 Message-ID: <4A118029.5050509@ericsson.com> Date: Mon, 18 May 2009 17:35:05 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <49DF9B41.6050403@netconfcentral.com> In-Reply-To: <49DF9B41.6050403@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2009 15:35:06.0000 (UTC) FILETIME=[38073100:01C9D7CE] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] comments on with-defaults-01 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:33:35 -0000 Andy Bierman wrote: > Hi, > > There was an important semantic change that was > made in this draft that needs to be corrected. > Sorry I did not catch it sooner. > > Before, if with-defaults is set to 'true' the > agent MUST return all default data. Now, there > is no requirement or even suggestion to support 'report-all'. > This is not acceptable. The whole point of creating > this capability was to get the defaults from the agent. > An agent MUST support 'report-all' in order to advertise > the :with-defaults capability. BALAZS: report-all will be made mandatory to support > > Also, I think there should be a YANG module (ietf-with-defaults.yang) > instead of an XSD in the draft. The new 4741-bis will have > a netconf.yang module which can be augmented. The NETCONF WG > decided to use only normative YANG starting when YANG is approved. > Unless the delay would be way too long, this document should > also use normative YANG. BALAZS: Basically I agree, but the time-line for the 4741bis effort is not clear for me. I will try to include both. > > > Andy > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Tue May 19 03:00:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A60B3A70A2 for ; Tue, 19 May 2009 03:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AUwN8fr+Pe1 for ; Tue, 19 May 2009 03:00:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3FFCB3A7099 for ; Tue, 19 May 2009 03:00:21 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-e3-4a128391bf49 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 48.F9.02630.193821A4; Tue, 19 May 2009 12:01:53 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 12:01:53 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 12:01:53 +0200 Message-ID: <4A128391.90705@ericsson.com> Date: Tue, 19 May 2009 12:01:53 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> <49E4FDA7.7010408@netconfcentral.com> <49E5F1CE.4010505@netconfcentral.com> <49E6A1C1.9040309@netconfcentral.com> <49EB4D9A.4000409@netconfcentral.com> In-Reply-To: <49EB4D9A.4000409@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2009 10:01:53.0700 (UTC) FILETIME=[D61A0E40:01C9D868] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 10:00:25 -0000 Hello, Some people brought it up that partial-locking without partial commit is not a good solution as it can lead to dead-locks. For one last time I try to list the reasons why we included candidate. Please state if you can accept the reasoning below or whether you think we should allow partial-locking ONLY for the running configuration? 1) As Washam pointed out just by having access control and without using any locks we face a dead-lock problems: - A only has access to /foo, and edits it in candidate - B only has access to /bar, and edits it in candidate - A terminates it's session - Now B can not issue because it can not modify /foo in the candidate - B can not issue because it can not modify /foo in the running If A and/or B uses partial-locking that will NOT make this situation WORSE, as the lock is automatically released at the end of the session. The real problem is caused by access control. 2) When partial-locking is used correctly, there is no danger of dead-lock, and locking does help to protect the individual operator's activities. (In the next sequence we presume access control will not block any of the actions.) - Operator A locks everything it needs both in candidate and running in one operation e.g. /foo - A edits the locked part in the candidate - A issues commit, if this fails due to lock conflicts, it simply releases the lock, and let's any concurrent operator (e.g. B) work on candidate; B will later commit changes done by A as well. Lock conflicts can include operator B locking /bar in the running configuration - Operator B works the same way on another area e.g. /bar - The operator that finishes editing last will successfully commit all changes to running (by this time there are no other locks) 3) Later we might introduce partial commit, in which case partial-locking would be very much needed/useful 4) Partial-locking does no evil 5) It is nice to have the feature available on all three datastores So we propose to keep partial-locking on candidate, but as this is only secondary use-case if the workgroup decides it can be removed. This question has already been raised a number of times, so we would like to establish the workgroup consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON CANDIDATE SHOULD STAY OR SHOULD BE REMOVED !!!! Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Tue May 19 03:56:14 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4163A67F7 for ; Tue, 19 May 2009 03:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj1uIJ7RVuA0 for ; Tue, 19 May 2009 03:56:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BFF233A6F5A for ; Tue, 19 May 2009 03:55:49 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-d3-4a1290940878 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 11.90.02630.490921A4; Tue, 19 May 2009 12:57:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 12:57:24 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 12:57:23 +0200 Message-ID: <4A12908E.9030204@ericsson.com> Date: Tue, 19 May 2009 12:57:18 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2009 10:57:24.0368 (UTC) FILETIME=[9755A900:01C9D870] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] with-defaults-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 10:56:14 -0000 WashamFan wrote: > Hi, > > 1) bullet 2, use cases for needing default values, sec1: > > o Some management applications might not have the capabilities to > correctly parse and interpret formal data models. > > IMO, the manager described above neither understands default values nor non-default values, does it? So how does this use case make sense? BALAZS: The manager above can still use the values supplied as defaults if report-all is used. E.g. We have applications that proxy netconf requests with some minimal checking and transformation. > > 2) para3, sec 2.3 & para2, sec2.5 > > If no 'supported' parameter is present, Does it mean the device only supports one behavior which is specified in 'basic' parameter or support all behaviors? > Since values of are restricted to the behaviors the device supports, it should be clarified what the values that a device support for are. BALAZS: Will be clarified. From balazs.lengyel@ericsson.com Tue May 19 04:28:21 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8647D3A70B5 for ; Tue, 19 May 2009 04:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY7gepo-awTx for ; Tue, 19 May 2009 04:28:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4B54B3A70AC for ; Tue, 19 May 2009 04:28:20 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-c2-4a129833be4c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1D.86.02531.338921A4; Tue, 19 May 2009 13:29:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 13:29:55 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 13:29:54 +0200 Message-ID: <4A129832.3050803@ericsson.com> Date: Tue, 19 May 2009 13:29:54 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200904291447.n3TElWkx020709@idle.juniper.net> In-Reply-To: <200904291447.n3TElWkx020709@idle.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2009 11:29:54.0691 (UTC) FILETIME=[21D15530:01C9D875] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] comments on with-defaults-01 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 11:28:21 -0000 Phil Shafer wrote: > Not a full review, but a couple of notes: > > 2.1. refers to "NETCONF messages", but I think > this is more general (like a to an ). BALAZS: Could you list what you have a mind beside rpc-replies please! I am not sure whether copy-config should be included. What does it mean if this is valid for copy-config running -> candidate ? Will it alter what is stored in candidate? It makes more sense if the target is a URL. Maybe we should say copy-config if target is URL? > > 2.1.1 lists "Report all", "Trim", and "Explicit", but should > use "report-all", "trim", and "explicit", since 2.3 and 2.4 > say "Possible method names are taken from the list in 2.1.1". BALAZS: OK, will be changed > > Use of the terms "methods" and "method names" is confusing, given > that 4741 uses this term to mean the element name under the > element. Use "modes" or some other term. BALAZS: OK, will be changed to mode > > 2.3 uses ":" to separate the members of the list. It should > use "," for this, in the same way we do in rfc4741 (8.8.3). > > 2.3 makes is sound like "supported" doesn't need to list > all supported modes, which is surprising. It should be > a complete list. BALAZS: OK, will be clarified > > 2.5 uses the phrase "added to the 'method-name' element. This > phrase is new and not meaningful. Putting it in quotes makes > it look like a string. Better to just list the specific method > names directly, as is done in the next sentence. BALAZS: the list is open ended, it potentially includes future operations. I removed the quotes. > > The example uses "" but section 2.1 says this affects > config data, not state data. BALAZS: replies to get does contain config data, but as favor I will change it to get-config. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From MARKSCOT@nortel.com Tue May 19 10:04:06 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBFD3A6857 for ; Tue, 19 May 2009 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8byl0Cx7fm1 for ; Tue, 19 May 2009 10:04:01 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D63923A6D59 for ; Tue, 19 May 2009 10:04:00 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4JH3ko15637; Tue, 19 May 2009 17:03:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D8A3.E7EAEE2C" x-cr-puzzleid: {DB60B789-6CBE-4AB4-8A0C-B0F6DA875D91} Content-class: urn:content-classes:message x-cr-hashedpuzzle: DGVu HREx I0S3 LRZF Mn4a ULXB XZC4 ef5J iUcF irpO nowY pueo rRUq sX75 tBdi tSsq; 4; YQBuAGQAeQBAAG4AZQB0AGMAbwBuAGYAYwBlAG4AdAByAGEAbAAuAGMAbwBtADsAbQBiAGoAQAB0AGEAaQBsAC0AZgAuAGMAbwBtADsAbgBlAHQAYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA7AHcAYQBzAGgAYQBtAC4AZgBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sosha1_v1; 7; {DB60B789-6CBE-4AB4-8A0C-B0F6DA875D91}; bQBhAHIAawBzAGMAbwB0AEAAbgBvAHIAdABlAGwALgBjAG8AbQA=; Tue, 19 May 2009 17:04:01 GMT; UgBFADoAIABbAE4ARQBUAEMATwBOAEYAXQAgAE0AbwBuAGkAdABvAHIAaQBuAGcAIABkAHIAYQBmAHQAOgAgACAAcwBlAHMAcwBpAG8AbgBJAGQAIAB1AG4AaQBxAHUAZQBuAGUAcwBzACAAcAByAG8AcABvAHMAZQBkACAAcgBlAHMAbwBsAHUAdABpAG8AbgA= Date: Tue, 19 May 2009 13:04:01 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1927F842@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution Thread-Index: AcnPOLzvASnCcoVERCiaCjKO2GR4ggJZ5VSA From: "Mark Scott" To: "Mark Scott" , , "Washam Fan" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:04:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D8A3.E7EAEE2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 After a series of ML discussions the following revision was reached for the sessionId uniqueness issue: =20 --- session |_sessionId (key) |_transport |_protocol |_username |_sourceHost |_loginTime =20 sessionId (type: SessionId) Unique NETCONF identifier for the session, used for all supported operations (e.g. monitoring, session kill, lock release) regardless of protocol. MUST be a unique non-0 value for all sessions reported. = SessionId=3D0 will not be reported in the session table. For purposes of NETCONF management all sessions are one of: Known session: any session which can be managed by the NETCONF server SHOULD be reported in this table and MUST map to a unique sessionId as described above Unknown session: such sessions are not managed by the NETCONF server and all map to sessionId=3D0. They MUST be excluded from the session table as a result. SessionId=3D0 will continue to be reported = in error messages with sessionId=3D0 per existing 4741 definition. =20 --- =20 This reflects consensus in the ML discussion. In particular it addresses concerns with 4741 backwards compatibility while providing the ability to uniquely manage non-NETCONF sessions if an implementation chooses to do so. =20 Thank you to all who participated in the discussion. If I missed any inputs/considerations please feel free to raise them again along with any alternatives to be considered. =20 The monitoring draft will be updated accordingly. =20 Mark =20 =20 From: Scott, Mark (CAR:2N00)=20 Sent: Thursday, May 07, 2009 1:25 PM To: andy@netconfcentral.com; 'Washam Fan'; 'Martin Bjorklund' Cc: netconf@ietf.org Subject: [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution =20 Hello, =20 In response to ML discussion for open item 'sessionID uniqueness' in the NETCONF Monitoring draft: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04 =20 Please review the issue and in particular the 'suggested resolution' below and reply with your agreement or suggestion for alternative in an attempt to reach WG consensus on this issue. =20 ISSUE: Key definition for ManagementSessionInfo ------------------------------------------------ =20 Current draft assumes sessionId will be unique for both NETCONF and non-NETCONF sessions reported via monitoring data. =20 SessionId uniqueness holds for NETCONF session. An issues arises applying same assumption to non-NETCONF sessions: =20 We have expressed opinion that sessionId uniqueness should also be mandated for all non-NETCONF entries included in the monitoring data since other protocols have similar use cases where a unique Id is required and/or a mapping scheme needs to be provided if a NETCONF implementation wants to manage non-NETCONF sessions. In particular if an implementation wants to extend support for an operation such as to non-NETCONF sessions. =20 However there is a side discussion underway on whether or not 4741 intended for sessionId=3D0 to be mandatory for non-NETCONF sessions in = all cases. Have asked for clarification in 4741bis. Until that is resolved we cannot mandate non-0 sessionId values in the monitoring data and don't want to delay monitoring on that decision. =20 Suggestions to use a tuple of existing fields were considered. In particular the use of sessionId, protocol and sourceHost but this doesn't guarantee uniqueness either. More fields (like loginTime) could be included but may lead to an increasing complex key as more protocols (and more issues of uniqueness) are monitored. =20 It is agreed we do want to keep the ability to report non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF entries needs to be added. =20 =20 SUGGESTED RESOLUTION: Add 'nativeSessionId', quality 'netconfSessionId' and extend key ------------------------------------------------------------------------ ---------------- =20 Per Andy's suggestion, refine ManagementSessionInfo, changing section 2.1.4 and model: =20 session |_netconfSessionId (key) |_associatedSession (key) |_transport |_protocol |_username |_sourceHost |_loginTime =20 netconfSessionId (type: SessionId) NETCONF identifier for the session. This is the unique sessionId used for all NETCONF operations. This is not guaranteed to be unique for non-NETCONF sessions. =20 associatedSession (type: string) Identifer used within NETCONF to associate to the native session in non-NETCONF protocol. For NETCONF sessions the value MUST match netconfSessionid. For non-NETCONF sessions, when a native session identifier is available this value should be the equal (string equivalent). It is expected this value will be unique when available for each reported particular protocol type. For non-NETCONF sessions, when a native session identifier is not available (e.g. sessionless protocol) and the NETCONF implementation chooses to report the sessions it MUST provide an associated session Id value. =20 The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be unique in all cases. xs:string is chosen to allow mapping to multiple native datatypes. =20 =20 cheers, mark ------_=_NextPart_001_01C9D8A3.E7EAEE2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

After a series of ML = discussions the following revision was reached for the sessionId uniqueness = issue:

 

---

session

       |_sessionId = (key)

       = |_transport

       = |_protocol

       = |_username

       = |_sourceHost

       = |_loginTime

 

sessionId (type: SessionId)

    Unique NETCONF = identifier for the session, used for all supported operations (e.g. monitoring, session = kill, lock release) regardless of protocol.

    MUST be a unique non-0 value = for all sessions reported.  SessionId=3D0 will not be reported in the = session table.

    For purposes of NETCONF = management all sessions are one of:

       Known = session:  any session which can be managed by the NETCONF server SHOULD be = reported in this table and MUST map to a unique sessionId as described = above

       Unknown session:  such sessions are not managed by the NETCONF server and = all map to sessionId=3D0.  They MUST be excluded from the session table as = a result.  SessionId=3D0 will continue to be reported in error messages with = sessionId=3D0 per existing 4741 definition.

 

---

 

This reflects = consensus in the ML discussion.  In particular it addresses concerns with 4741 = backwards compatibility while providing the ability to uniquely manage non-NETCONF sessions if an implementation chooses to do so.

 

Thank you to all who participated in the discussion.   If I missed any = inputs/considerations please feel free to raise them again along with any alternatives to be considered.

 

The monitoring draft = will be updated accordingly.

 

Mark

 

 

From:= Scott, = Mark (CAR:2N00)
Sent: Thursday, May 07, 2009 1:25 PM
To: andy@netconfcentral.com; 'Washam Fan'; 'Martin Bjorklund'
Cc: netconf@ietf.org
Subject: [NETCONF] Monitoring draft: sessionId uniqueness = proposed resolution

 

Hello,

 

In response to ML discussion for open item ‘sessionID uniqueness’ in the NETCONF Monitoring = draft:  http= ://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

 

Please review the issue and in particular the = 'suggested resolution' below and reply with your agreement or suggestion for = alternative in an attempt to reach WG consensus on this issue.

 

ISSUE:  Key definition for = ManagementSessionInfo

------------------------------------------------

 

Current draft assumes sessionId will be unique = for both NETCONF and non-NETCONF sessions reported via monitoring = data.

 

SessionId uniqueness holds for NETCONF = session.  An issues arises applying same assumption to non-NETCONF = sessions:

 

We have expressed opinion that sessionId = uniqueness should also be mandated for all non-NETCONF entries included in the = monitoring data since other protocols have similar use cases where a unique Id is = required and/or a mapping scheme needs to be provided if a NETCONF implementation = wants to manage non-NETCONF sessions.  In particular if an implementation = wants to extend support for an operation such as <kill-session> to = non-NETCONF sessions.

 

However there is a side discussion underway on = whether or not 4741 intended for sessionId=3D0 to be mandatory for non-NETCONF = sessions in all cases.  Have asked for clarification in 4741bis.  Until = that is resolved we cannot mandate non-0 sessionId values in the monitoring data = and don’t want to delay monitoring on that decision.

 

Suggestions to use a tuple of existing fields = were considered.  In particular the use of sessionId, protocol and = sourceHost but this doesn't guarantee uniqueness either.  More fields (like loginTime) could be included but may lead to an increasing complex key = as more protocols (and more issues of uniqueness) are monitored.

 

It is agreed we do want to keep the ability to = report non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF = entries needs to be added.

 

 

SUGGESTED RESOLUTION:  Add ‘nativeSessionId’, quality ‘netconfSessionId’ = and extend key

----------------------------------------------------= ------------------------------------

 

Per Andy’s suggestion, refine ManagementSessionInfo, changing section 2.1.4 and model:

 

session

       = |_netconfSessionId (key)

 |_associatedSession = (key)

       = |_transport

       = |_protocol

       = |_username

       = |_sourceHost

       = |_loginTime

 

netconfSessionId (type: = SessionId)

     NETCONF identifier for = the session.

     This is the unique = sessionId used for all NETCONF operations.

     This is not guaranteed = to be unique for non-NETCONF sessions.

 

associatedSession (type: string)

     Identifer used within = NETCONF to associate to the native session in non-NETCONF protocol.

     For NETCONF sessions = the value MUST match netconfSessionid.

     For non-NETCONF = sessions, when a native session identifier is available this value should be the equal = (string equivalent).  It is expected this value will be unique when = available for each reported particular protocol type.

     For non-NETCONF = sessions, when a native session identifier is not available (e.g. sessionless protocol) = and the NETCONF implementation chooses to report the sessions it MUST provide an associated session Id value.      =

     The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be = unique in all cases.

     xs:string is chosen to = allow mapping to multiple native datatypes.

 

 

cheers,

mark

------_=_NextPart_001_01C9D8A3.E7EAEE2C-- From randy_presuhn@mindspring.com Tue May 19 10:42:51 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF3F28C14B for ; Tue, 19 May 2009 10:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOJvcWERsgZl for ; Tue, 19 May 2009 10:42:50 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 82EB43A6B5D for ; Tue, 19 May 2009 10:42:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Olta3MV/E/ssWhKAfLO8abO9tiVN1L8ZA4p1njqIykD37znEcoQlNfwVdnZJdGo+; 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 [69.3.146.208] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M6TMZ-0003T4-0m for netconf@ietf.org; Tue, 19 May 2009 13:44:27 -0400 Message-ID: <006801c9d8a9$e93afe80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf mailing list" References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> <49E4FDA7.7010408@netconfcentral.com> <49E5F1CE.4010505@netconfcentral.com> <49E6A1C1.9040309@netconfcentral.com> <49EB4D9A.4000409@netconfcentral.com> <4A128391.90705@ericsson.com> Date: Tue, 19 May 2009 10:47:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69685a36d8313fec1613e81a1deed54256c3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.208 Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:42:51 -0000 Hi - > From: "Balazs Lengyel" > To: "netconf mailing list" > Sent: Tuesday, May 19, 2009 3:01 AM > Subject: [Netconf] Partial-lock issues ... > Please state if you can accept the reasoning below or whether you think we should allow > partial-locking ONLY for the running configuration? > > 1) As Washam pointed out just by having access control and without using any locks we face a > dead-lock problems: > - A only has access to /foo, and edits it in candidate > - B only has access to /bar, and edits it in candidate > - A terminates it's session > - Now B can not issue because it can not modify /foo in the candidate > - B can not issue because it can not modify /foo in the running > If A and/or B uses partial-locking that will NOT make this situation WORSE, as the lock is > automatically released at the end of the session. The real problem is caused by access control. ... This reasoning makes an unwarranted assumption about how access control works. Specifically, it assumes that the access control policy is evaluated at the time of the , rather than simply being applied to each individual edit. Buried underneath this is the question of what happens when there is a change to the access control policy between the edit and the . Randy From mbj@tail-f.com Tue May 19 11:46:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C683A6E62 for ; Tue, 19 May 2009 11:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM9Q7Y8rdLUK for ; Tue, 19 May 2009 11:46:15 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 12CEE28C1A0 for ; Tue, 19 May 2009 11:46:03 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 86CFA76C229; Tue, 19 May 2009 20:47:37 +0200 (CEST) Date: Tue, 19 May 2009 20:47:37 +0200 (CEST) Message-Id: <20090519.204737.76765801.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <006801c9d8a9$e93afe80$6801a8c0@oemcomputer> References: <49EB4D9A.4000409@netconfcentral.com> <4A128391.90705@ericsson.com> <006801c9d8a9$e93afe80$6801a8c0@oemcomputer> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 18:46:16 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Balazs Lengyel" > > To: "netconf mailing list" > > Sent: Tuesday, May 19, 2009 3:01 AM > > Subject: [Netconf] Partial-lock issues > ... > > Please state if you can accept the reasoning below or whether you think we > > should allow > > partial-locking ONLY for the running configuration? > > > > 1) As Washam pointed out just by having access control and without using any > > locks we face a > > dead-lock problems: > > - A only has access to /foo, and edits it in candidate > > - B only has access to /bar, and edits it in candidate > > - A terminates it's session > > - Now B can not issue because it can not modify /foo in the > > - candidate > > - B can not issue because it can not modify /foo in the running > > If A and/or B uses partial-locking that will NOT make this situation WORSE, > > as the lock is > > automatically released at the end of the session. The real problem is caused > > by access control. > ... > > This reasoning makes an unwarranted assumption about how access control works. > Specifically, it assumes that the access control policy is evaluated at the > time of > the , rather than simply being applied to each individual > edit. No, I don't think the example makes that assumption. The only assumption it makes is that the access control policy is *at least* evaluated as part of commit. This is a use case that is explicitly mentioned in RFC 4741, section 9: For example, if a user A is not allowed to configure an IP address on an interface but user B has configured an IP address on an interface in the configuration, user A must not be allowed to commit the configuration. /martin From bertietf@bwijnen.net Tue May 19 11:50:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1EB28C164 for ; Tue, 19 May 2009 11:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.065 X-Spam-Level: X-Spam-Status: No, score=-0.065 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxXNej9N5-gY for ; Tue, 19 May 2009 11:50:06 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 48A7D3A70C0 for ; Tue, 19 May 2009 11:50:06 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M6UPd-0002pj-Ex; Tue, 19 May 2009 20:51:41 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" , "netconf mailing list" References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> <49E4FDA7.7010408@netconfcentral.com> <49E5F1CE.4010505@netconfcentral.com> <49E6A1C1.9040309@netconfcentral.com> <49EB4D9A.4000409@netconfcentral.com> <4A128391.90705@ericsson.com> In-Reply-To: <4A128391.90705@ericsson.com> Date: Tue, 19 May 2009 20:51:31 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C3D_01C9D8C3.96E433D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 18:50:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0C3D_01C9D8C3.96E433D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Balazs for summarizing. I believe I (as a technical contributer) can accept your reasoning. Speaking as document shepherd and WG co-chair I would like to urge all WG members to state their opinion (or comments) as well. Bert ----- Original Message -----=20 From: Balazs Lengyel=20 To: netconf mailing list=20 Sent: Tuesday, May 19, 2009 12:01 PM Subject: [Netconf] Partial-lock issues Hello, Some people brought it up that partial-locking without partial commit = is not a good solution as it can lead to dead-locks. For one last time I try to list the reasons = why we included candidate. Please state if you can accept the reasoning below or whether you = think we should allow partial-locking ONLY for the running configuration? 1) As Washam pointed out just by having access control and without = using any locks we face a dead-lock problems: - A only has access to /foo, and edits it in candidate - B only has access to /bar, and edits it in candidate - A terminates it's session - Now B can not issue because it can not modify /foo = in the candidate - B can not issue because it can not modify /foo in the = running If A and/or B uses partial-locking that will NOT make this situation = WORSE, as the lock is automatically released at the end of the session. The real problem is = caused by access control. 2) When partial-locking is used correctly, there is no danger of = dead-lock, and locking does help to protect the individual operator's activities. (In the next = sequence we presume access control will not block any of the actions.) - Operator A locks everything it needs both in candidate and running = in one operation e.g. /foo - A edits the locked part in the candidate - A issues commit, if this fails due to lock conflicts, it simply = releases the lock, and let's any concurrent operator (e.g. B) work on candidate; B will later = commit changes done by A as well. Lock conflicts can include operator B locking /bar in the = running configuration - Operator B works the same way on another area e.g. /bar - The operator that finishes editing last will successfully commit all = changes to running (by this time there are no other locks) 3) Later we might introduce partial commit, in which case = partial-locking would be very much needed/useful 4) Partial-locking does no evil 5) It is nice to have the feature available on all three datastores So we propose to keep partial-locking on candidate, but as this is = only secondary use-case if the workgroup decides it can be removed. This question has already been raised a number of times, so we would = like to establish the workgroup consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON = CANDIDATE SHOULD STAY OR SHOULD BE REMOVED !!!! Balazs --=20 Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: = Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf -------------------------------------------------------------------------= ----- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.336 / Virus Database: 270.12.34/2122 - Release Date: = 05/19/09 06:21:00 ------=_NextPart_000_0C3D_01C9D8C3.96E433D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Balazs for summarizing.
 
I believe I (as a technical contributer) can accept = your=20 reasoning.
 
Speaking as document shepherd and WG co-chair I = would like=20 to
urge all WG members to state their opinion (or = comments) as=20 well.
 
Bert
----- Original Message -----
From:=20 Balazs Lengyel
Sent: Tuesday, May 19, 2009 = 12:01=20 PM
Subject: [Netconf] Partial-lock = issues

Hello,
Some people brought it up that = partial-locking=20 without partial commit is not a good solution as
it can lead to = dead-locks.=20 For one last time I try to list the reasons why we included=20 candidate.

Please state if you can accept the reasoning below = or=20 whether you think we should allow
partial-locking ONLY for the = running=20 configuration?

1) As Washam pointed out just by having access = control=20 and without using any locks we face a
dead-lock problems:
- A = only has=20 access to /foo, and edits it in candidate
- B only has access to = /bar, and=20 edits it in candidate
- A terminates it's session
- Now B can = not issue=20 <discard-changes> because it can not modify /foo in the = candidate
- B=20 can not issue <commit> because it can not modify /foo in the=20 running
If A and/or B uses partial-locking that will NOT make this=20 situation WORSE, as the lock is
automatically released at the end = of the=20 session. The real problem is caused by access control.

2) When=20 partial-locking is used correctly, there is no danger of dead-lock, = and=20 locking does
help to protect the individual operator's activities. = (In the=20 next sequence we presume access
control will not block any of the=20 actions.)

- Operator A locks everything it needs both in = candidate and=20 running in one operation e.g. /foo
- A edits the locked part in the = candidate
- A issues commit, if this fails due to lock conflicts, = it simply=20 releases the lock, and let's
any concurrent operator (e.g. B) work = on=20 candidate; B will later commit changes done by A as
well. Lock = conflicts=20 can include operator B locking /bar in the running configuration
- = Operator=20 B works the same way on another area e.g. /bar
- The operator that = finishes=20 editing last will successfully commit all changes to running = (by
this time=20 there are no other locks)

3) Later we might introduce partial = commit,=20 in which case partial-locking would be very = much
needed/useful

4)=20 Partial-locking does no evil

5) It is nice to have the feature=20 available on all three datastores

So we propose to keep = partial-locking=20 on candidate, but as this is only secondary use-case if
the = workgroup=20 decides it can be removed.

This question has already been = raised a=20 number of times, so we would like to establish = the
workgroup
consensus=20 and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON CANDIDATE = SHOULD=20 STAY OR
SHOULD BE REMOVED !!!!

Balazs


-- =
Balazs=20 = Lengyel           =            =20 Ericsson Hungary Ltd.
System Manager
ECN: 831=20 = 7320           &nb= sp;           =20 Fax: +36 1 4377792
Tel:=20 = +36-1-437-7320          = ;       =20 email: Balazs.Lengyel@ericsson.com


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


No virus found in this incoming message.
Checked by AVG = - www.avg.com
Version: 8.5.336 / = Virus=20 Database: 270.12.34/2122 - Release Date: 05/19/09=20 06:21:00
------=_NextPart_000_0C3D_01C9D8C3.96E433D0-- From mehmet.ersue@nsn.com Tue May 19 12:19:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAED43A6973 for ; Tue, 19 May 2009 12:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.225 X-Spam-Level: X-Spam-Status: No, score=-5.225 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKPhahaT70ax for ; Tue, 19 May 2009 12:19:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 772A33A6886 for ; Tue, 19 May 2009 12:19:16 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4JJKljn018676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 May 2009 21:20:47 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4JJKk3n030231; Tue, 19 May 2009 21:20:46 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 21:20:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D8B6.E7E31D8A" Date: Tue, 19 May 2009 21:20:44 +0200 Message-ID: In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1927F842@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution thread-index: AcnPOLzvASnCcoVERCiaCjKO2GR4ggJZ5VSAAAVO/xA= References: <085091CB2CA14E4B8B163FFC37C84E9D1927F842@zcarhxm0.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "Washam Fan" , X-OriginalArrivalTime: 19 May 2009 19:20:46.0603 (UTC) FILETIME=[E944FDB0:01C9D8B6] Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:19:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D8B6.E7E31D8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, =20 we assume we can see this now as a WG consensus=20 and close this issue. =20 If anybody disagrees please state it so _and_ provide=20 a better solution (for the sake of progress I hope this=20 is not the case). Cheers, Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mark Scott Sent: Tuesday, May 19, 2009 7:04 PM To: Mark Scott; andy@netconfcentral.com; Washam Fan; Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution =09 =09 Hello, =20 After a series of ML discussions the following revision was reached for the sessionId uniqueness issue: =20 --- session |_sessionId (key) |_transport |_protocol |_username |_sourceHost |_loginTime =20 sessionId (type: SessionId) Unique NETCONF identifier for the session, used for all supported operations (e.g. monitoring, session kill, lock release) regardless of protocol. MUST be a unique non-0 value for all sessions reported. SessionId=3D0 will not be reported in the session table. For purposes of NETCONF management all sessions are one of: Known session: any session which can be managed by the NETCONF server SHOULD be reported in this table and MUST map to a unique sessionId as described above Unknown session: such sessions are not managed by the NETCONF server and all map to sessionId=3D0. They MUST be excluded from the session table as a result. SessionId=3D0 will continue to be = reported in error messages with sessionId=3D0 per existing 4741 definition. =20 --- =20 This reflects consensus in the ML discussion. In particular it addresses concerns with 4741 backwards compatibility while providing the ability to uniquely manage non-NETCONF sessions if an implementation chooses to do so. =20 Thank you to all who participated in the discussion. If I missed any inputs/considerations please feel free to raise them again along with any alternatives to be considered. =20 The monitoring draft will be updated accordingly. =20 Mark =20 =20 From: Scott, Mark (CAR:2N00)=20 Sent: Thursday, May 07, 2009 1:25 PM To: andy@netconfcentral.com; 'Washam Fan'; 'Martin Bjorklund' Cc: netconf@ietf.org Subject: [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution =20 Hello, =20 In response to ML discussion for open item 'sessionID uniqueness' in the NETCONF Monitoring draft: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04 =20 Please review the issue and in particular the 'suggested resolution' below and reply with your agreement or suggestion for alternative in an attempt to reach WG consensus on this issue. =20 ISSUE: Key definition for ManagementSessionInfo ------------------------------------------------ =20 Current draft assumes sessionId will be unique for both NETCONF and non-NETCONF sessions reported via monitoring data. =20 SessionId uniqueness holds for NETCONF session. An issues arises applying same assumption to non-NETCONF sessions: =20 We have expressed opinion that sessionId uniqueness should also be mandated for all non-NETCONF entries included in the monitoring data since other protocols have similar use cases where a unique Id is required and/or a mapping scheme needs to be provided if a NETCONF implementation wants to manage non-NETCONF sessions. In particular if an implementation wants to extend support for an operation such as to non-NETCONF sessions. =20 However there is a side discussion underway on whether or not 4741 intended for sessionId=3D0 to be mandatory for non-NETCONF sessions in all cases. Have asked for clarification in 4741bis. Until that is resolved we cannot mandate non-0 sessionId values in the monitoring data and don't want to delay monitoring on that decision. =20 Suggestions to use a tuple of existing fields were considered. In particular the use of sessionId, protocol and sourceHost but this doesn't guarantee uniqueness either. More fields (like loginTime) could be included but may lead to an increasing complex key as more protocols (and more issues of uniqueness) are monitored. =20 It is agreed we do want to keep the ability to report non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF entries needs to be added. =20 =20 SUGGESTED RESOLUTION: Add 'nativeSessionId', quality 'netconfSessionId' and extend key =09 ------------------------------------------------------------------------ ---------------- =20 Per Andy's suggestion, refine ManagementSessionInfo, changing section 2.1.4 and model: =20 session |_netconfSessionId (key) |_associatedSession (key) |_transport |_protocol |_username |_sourceHost |_loginTime =20 netconfSessionId (type: SessionId) NETCONF identifier for the session. This is the unique sessionId used for all NETCONF operations. This is not guaranteed to be unique for non-NETCONF sessions. =20 associatedSession (type: string) Identifer used within NETCONF to associate to the native session in non-NETCONF protocol. For NETCONF sessions the value MUST match netconfSessionid. For non-NETCONF sessions, when a native session identifier is available this value should be the equal (string equivalent). It is expected this value will be unique when available for each reported particular protocol type. For non-NETCONF sessions, when a native session identifier is not available (e.g. sessionless protocol) and the NETCONF implementation chooses to report the sessions it MUST provide an associated session Id value. =20 The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be unique in all cases. xs:string is chosen to allow mapping to multiple native datatypes. =20 =20 cheers, mark ------_=_NextPart_001_01C9D8B6.E7E31D8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
we assume we can see this now as a WG=20 consensus
and close this issue.
 
If anybody disagrees please state it so _and_=20 provide
a better solution (for the sake=20 of progress I hope this
is not the = case).

Cheers,
Mehmet =
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mark=20 Scott
Sent: Tuesday, May 19, 2009 7:04 PM
To: Mark = Scott;=20 andy@netconfcentral.com; Washam Fan; Martin Bjorklund
Cc:=20 netconf@ietf.org
Subject: Re: [Netconf] [NETCONF] Monitoring = draft:=20 sessionId uniquenessproposed resolution

Hello,

 

After a series of = ML=20 discussions the following revision was reached for the sessionId = uniqueness=20 issue:

 

---

session

       = |_sessionId=20 (key)

      =20 |_transport

      =20 |_protocol

      =20 |_username

      =20 |_sourceHost

      =20 |_loginTime

 

sessionId (type: SessionId)

    Unique NETCONF = identifier for=20 the session, used for all supported operations (e.g. monitoring, = session kill,=20 lock release) regardless of protocol.

    MUST be a unique non-0 = value for all=20 sessions reported.  SessionId=3D0 will not be reported in the = session=20 table.

    For purposes of NETCONF = management=20 all sessions are one of:

       Known=20 session:  any session which can be managed by the NETCONF server = SHOULD=20 be reported in this table and MUST map to a unique sessionId as = described=20 above

       Unknown=20 session:  such sessions are not managed by the NETCONF server and = all map=20 to sessionId=3D0.  They MUST be excluded from the session table = as a=20 result.  SessionId=3D0 will continue to be reported in error = messages with=20 sessionId=3D0 per existing 4741 definition.

 

---

 

This reflects = consensus in the=20 ML discussion.  In particular it addresses concerns with 4741 = backwards=20 compatibility while providing the ability to uniquely manage = non-NETCONF=20 sessions if an implementation chooses to do so.

 

Thank you to all = who=20 participated in the discussion.   If I missed any=20 inputs/considerations please feel free to raise them again along with = any=20 alternatives to be considered.

 

The monitoring = draft will be=20 updated accordingly.

 

Mark

 

 

From: Scott, = Mark=20 (CAR:2N00)
Sent: Thursday, May 07, 2009 1:25 = PM
To:=20 andy@netconfcentral.com; 'Washam Fan'; 'Martin = Bjorklund'
Cc:=20 netconf@ietf.org
Subject: [NETCONF] Monitoring draft: = sessionId=20 uniqueness proposed resolution

 

Hello,

 

In response to ML discussion for open item = ‘sessionID=20 uniqueness’ in the NETCONF Monitoring draft:  http= ://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

 

Please review the issue and in particular the = 'suggested=20 resolution' below and reply with your agreement or suggestion for = alternative=20 in an attempt to reach WG consensus on this issue.

 

ISSUE:  Key definition for=20 ManagementSessionInfo

------------------------------------------------

 

Current draft assumes sessionId will be unique = for both=20 NETCONF and non-NETCONF sessions reported via monitoring = data.

 

SessionId uniqueness holds for NETCONF = session.  An=20 issues arises applying same assumption to non-NETCONF = sessions:

 

We have expressed opinion that sessionId = uniqueness=20 should also be mandated for all non-NETCONF entries included in the = monitoring=20 data since other protocols have similar use cases where a unique Id is = required and/or a mapping scheme needs to be provided if a NETCONF=20 implementation wants to manage non-NETCONF sessions.  In = particular if an=20 implementation wants to extend support for an operation such as=20 <kill-session> to non-NETCONF sessions.

 

However there is a side discussion underway on = whether=20 or not 4741 intended for sessionId=3D0 to be mandatory for non-NETCONF = sessions=20 in all cases.  Have asked for clarification in 4741bis.  = Until that=20 is resolved we cannot mandate non-0 sessionId values in the monitoring = data=20 and don’t want to delay monitoring on that = decision.

 

Suggestions to use a tuple of existing fields = were=20 considered.  In particular the use of sessionId, protocol and = sourceHost=20 but this doesn't guarantee uniqueness either.  More fields (like=20 loginTime) could be included but may lead to an increasing complex key = as more=20 protocols (and more issues of uniqueness) are = monitored.

 

It is agreed we do want to keep the ability to = report=20 non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF = entries=20 needs to be added.

 

 

SUGGESTED RESOLUTION:  Add = ‘nativeSessionId’,=20 quality ‘netconfSessionId’ and extend key

----------------------------------------------------= ------------------------------------

 

Per Andy’s suggestion, refine = ManagementSessionInfo,=20 changing section 2.1.4 and model:

 

session

       = |_netconfSessionId=20 (key)

 |_associatedSession=20 (key)

      =20 |_transport

      =20 |_protocol

      =20 |_username

      =20 |_sourceHost

      =20 |_loginTime

 

netconfSessionId (type: = SessionId)

     NETCONF identifier = for the=20 session.

     This is the unique = sessionId=20 used for all NETCONF operations.

     This is not = guaranteed to be=20 unique for non-NETCONF sessions.

 

associatedSession (type: = string)

     Identifer used within = NETCONF=20 to associate to the native session in non-NETCONF = protocol.

     For NETCONF sessions = the value=20 MUST match netconfSessionid.

     For non-NETCONF = sessions, when=20 a native session identifier is available this value should be the = equal=20 (string equivalent).  It is expected this value will be unique = when=20 available for each reported particular protocol type.

     For non-NETCONF = sessions, when=20 a native session identifier is not available (e.g. sessionless = protocol) and=20 the NETCONF implementation chooses to report the sessions it MUST = provide an=20 associated session Id value.      =

     The key for the=20 ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be = unique=20 in all cases.

     xs:string is chosen = to allow=20 mapping to multiple native datatypes.

 

 

cheers,

mark

------_=_NextPart_001_01C9D8B6.E7E31D8A-- From randy_presuhn@mindspring.com Tue May 19 13:49:08 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BE13A6972 for ; Tue, 19 May 2009 13:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPexbOGVbjdt for ; Tue, 19 May 2009 13:49:07 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id AB8443A67A7 for ; Tue, 19 May 2009 13:49:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kF9asftntrT6BLJzWOXDaJ9bjqnNaPyMxB/vyKaLOEa6pdplPQ9+GwBFVrH2IPYp; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M6W6d-0000tY-7k; Tue, 19 May 2009 16:40:11 -0400 Received: from 99.128.225.14 by webmail.earthlink.net with HTTP; Tue, 19 May 2009 16:40:11 -0400 Message-ID: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Tue, 19 May 2009 13:40:11 -0700 (GMT-07:00) From: Randy Presuhn To: Martin Bjorklund Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968995c427c7a412613b3a21e50cbe59bb1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 Cc: netconf@ietf.org Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 20:49:08 -0000 Hi - >From: Martin Bjorklund >Sent: May 19, 2009 11:47 AM >To: randy_presuhn@mindspring.com >Cc: netconf@ietf.org >Subject: Re: [Netconf] Partial-lock issues > >"Randy Presuhn" wrote: >> Hi - >> >> > From: "Balazs Lengyel" >> > To: "netconf mailing list" >> > Sent: Tuesday, May 19, 2009 3:01 AM >> > Subject: [Netconf] Partial-lock issues >> ... >> > Please state if you can accept the reasoning below or whether you think we >> > should allow >> > partial-locking ONLY for the running configuration? >> > >> > 1) As Washam pointed out just by having access control and without using any >> > locks we face a >> > dead-lock problems: >> > - A only has access to /foo, and edits it in candidate >> > - B only has access to /bar, and edits it in candidate >> > - A terminates it's session >> > - Now B can not issue because it can not modify /foo in the >> > - candidate >> > - B can not issue because it can not modify /foo in the running >> > If A and/or B uses partial-locking that will NOT make this situation WORSE, >> > as the lock is >> > automatically released at the end of the session. The real problem is caused >> > by access control. >> ... >> >> This reasoning makes an unwarranted assumption about how access control works. >> Specifically, it assumes that the access control policy is evaluated at the >> time of >> the , rather than simply being applied to each individual >> edit. > >No, I don't think the example makes that assumption. The only >assumption it makes is that the access control policy is *at least* >evaluated as part of commit. This is a use case that is explicitly >mentioned in RFC 4741, section 9: > > For > example, if a user A is not allowed to configure an IP address on an > interface but user B has configured an IP address on an interface in > the configuration, user A must not be allowed to commit > the configuration. If you read that into the example, then the access control model is hopelessly broken with respect to locking. Commit is the wrong time to evaluate the access decision function, unless each individual delta (rather than the entire configuration) is marked with the identity of the party responsible for that part of the total change-set. As long as *all* deltas happening in the course of a commit are handled as though they had been made by the party whose action caused the commit to happen, the deadlock will occur. A much simpler approach is to evaluate the access decision function at the time of each individual edit, rather than the commit. Randy Randy From Washam.Fan@huaweisymantec.com Tue May 19 18:52:42 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D659B3A680D for ; Tue, 19 May 2009 18:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eP1+19w41W4 for ; Tue, 19 May 2009 18:52:42 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id C68DB3A6972 for ; Tue, 19 May 2009 18:52:41 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJX00ACG6M5OA70@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 20 May 2009 09:54:06 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJX006B86M5QE20@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 20 May 2009 09:54:05 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 20 May 2009 09:54:05 +0800 From: WashamFan To: Balazs Lengyel Message-id: Date: Wed, 20 May 2009 09:54:05 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A128391.90705@ericsson.com> References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> <49E4FDA7.7010408@netconfcentral.com> <49E5F1CE.4010505@netconfcentral.com> <49E6A1C1.9040309@netconfcentral.com> <49EB4D9A.4000409@netconfcentral.com> <4A128391.90705@ericsson.com> Cc: netconf mailing list Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 01:52:42 -0000 Hi, According to current relevant text, the only safe way to use candidate is one-session-at-a-time as Andy said before. I.e., global lock is recommended to be used for candidate edits. Yes, the partial lock does not make the situation worse, but it encourages multiple-session-at-a-time on candidate, which leads to difficult recovery. So, I just suggest this use case removed. washam ----- Original Message ----- From: Balazs Lengyel Date: Tuesday, May 19, 2009 6:02 pm Subject: [Netconf] Partial-lock issues To: netconf mailing list > Hello, > Some people brought it up that partial-locking without partial commit > is not a good solution as > it can lead to dead-locks. For one last time I try to list the > reasons why we included candidate. > > Please state if you can accept the reasoning below or whether you > think we should allow > partial-locking ONLY for the running configuration? > > 1) As Washam pointed out just by having access control and without > using any locks we face a > dead-lock problems: > - A only has access to /foo, and edits it in candidate > - B only has access to /bar, and edits it in candidate > - A terminates it's session > - Now B can not issue because it can not modify > /foo in the candidate > - B can not issue because it can not modify /foo in the running > If A and/or B uses partial-locking that will NOT make this situation > WORSE, as the lock is > automatically released at the end of the session. The real problem is > caused by access control. > > 2) When partial-locking is used correctly, there is no danger of > dead-lock, and locking does > help to protect the individual operator's activities. (In the next > sequence we presume access > control will not block any of the actions.) > > - Operator A locks everything it needs both in candidate and running > in one operation e.g. /foo > - A edits the locked part in the candidate > - A issues commit, if this fails due to lock conflicts, it simply > releases the lock, and let's > any concurrent operator (e.g. B) work on candidate; B will later > commit changes done by A as > well. Lock conflicts can include operator B locking /bar in the > running configuration > - Operator B works the same way on another area e.g. /bar > - The operator that finishes editing last will successfully commit > all changes to running (by > this time there are no other locks) > > 3) Later we might introduce partial commit, in which case > partial-locking would be very much > needed/useful > > 4) Partial-locking does no evil > > 5) It is nice to have the feature available on all three datastores > > So we propose to keep partial-locking on candidate, but as this is > only secondary use-case if > the workgroup decides it can be removed. > > This question has already been raised a number of times, so we would > like to establish the > workgroup > consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON > CANDIDATE SHOULD STAY OR > SHOULD BE REMOVED !!!! > > Balazs > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Tue May 19 19:36:59 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887AE3A67DB for ; Tue, 19 May 2009 19:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.54 X-Spam-Level: X-Spam-Status: No, score=0.54 tagged_above=-999 required=5 tests=[AWL=-1.565, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DhpZoKz27aI for ; Tue, 19 May 2009 19:36:54 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 559983A67A4 for ; Tue, 19 May 2009 19:36:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJX00E348NW1B90@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 20 May 2009 10:38:20 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJX00L1H8NVHW00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 20 May 2009 10:38:19 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 20 May 2009 10:38:19 +0800 From: WashamFan To: Balazs Lengyel Message-id: Date: Wed, 20 May 2009 10:38:19 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A12908E.9030204@ericsson.com> References: <4A12908E.9030204@ericsson.com> Cc: netconf@ietf.org Subject: [Netconf] affected operations, with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 02:36:59 -0000 Hi, The draft defines 3 affected operations in sec 2.5, and there is a para to specify how to identify other potential affected ops: Other operations that return configuration data SHOULD also handle default data according to the rules set in this document, and explicitly state this in their documentation. If this is not specified in the document defining the respective operation, the default handling rules described herein do not affect these operations. I suggest introduce an optional parameter in capability URI to indicate what other affected opertions are supported by Netconf server, and at least I can see following benefits: (1) this dynamic discovery of affected operations can sync client with server timely. (2) If the relevant docs are unreachable for the client, the client can still discover the affected operations without document consultant. (3) maybe it is effective and efficient for the client. The capability URI would look like this: urn:ietf:params:netconf:capability:with-defaults:1.0?basic=report- all&supported=trim:explicit&ops=ns1:op1,ns2:op2 ^^^^^^^^^^^^^ Any comments? washam From andy@netconfcentral.com Tue May 19 19:56:35 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DD33A6A41 for ; Tue, 19 May 2009 19:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+5VN4m06CCc for ; Tue, 19 May 2009 19:56:34 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 6C6A43A6A3C for ; Tue, 19 May 2009 19:56:34 -0700 (PDT) Received: (qmail 66585 invoked from network); 20 May 2009 02:58:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 20 May 2009 02:58:09 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1371BF.9070308@netconfcentral.com> Date: Tue, 19 May 2009 19:58:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: <4A12908E.9030204@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] affected operations, with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 02:56:35 -0000 WashamFan wrote: > Hi, > > The draft defines 3 affected operations in sec 2.5, and there is > a para to specify how to identify other potential affected ops: > > Other operations that return configuration data SHOULD also handle > default data according to the rules set in this document, and > explicitly state this in their documentation. If this is not > specified in the document defining the respective operation, the > default handling rules described herein do not affect these > operations. > > I suggest introduce an optional parameter in capability URI to > indicate what other affected opertions are supported by > Netconf server, and at least I can see following benefits: > > (1) this dynamic discovery of affected operations can sync client > with server timely. > > (2) If the relevant docs are unreachable for the client, the client > can still discover the affected operations without document > consultant. > > (3) maybe it is effective and efficient for the client. > > The capability URI would look like this: > > urn:ietf:params:netconf:capability:with-defaults:1.0?basic=report- > all&supported=trim:explicit&ops=ns1:op1,ns2:op2 > This seems rather complicated to me. I don't know why the draft needs to say anything about operations other than the 3 mentioned explicitly. The capability is for those 3 operations only. If there are more that need to be mentioned, then what are they? They should be in the draft. > > Any comments? > > washam Andy From balazs.lengyel@ericsson.com Wed May 20 00:21:24 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A1B3A69F9 for ; Wed, 20 May 2009 00:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9CbJDz41k-N for ; Wed, 20 May 2009 00:21:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 09E853A68EA for ; Wed, 20 May 2009 00:21:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-0e-4a13afcbd3bc Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E1.1C.02630.BCFA31A4; Wed, 20 May 2009 09:22:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:22:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:22:51 +0200 Message-ID: <4A13AFCA.5070803@ericsson.com> Date: Wed, 20 May 2009 09:22:50 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: <4A12908E.9030204@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2009 07:22:51.0156 (UTC) FILETIME=[C8B72540:01C9D91B] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] affected operations, with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 07:21:24 -0000 Hello Washam, In some cases e.g. copy-config it might not be trivial how with-defaults affects the operation. So you still have to check the relevant docs. Also I feel this goes into the "too many options" directions. Balazs WashamFan wrote: > Hi, > > The draft defines 3 affected operations in sec 2.5, and there is > a para to specify how to identify other potential affected ops: > > Other operations that return configuration data SHOULD also handle > default data according to the rules set in this document, and > explicitly state this in their documentation. If this is not > specified in the document defining the respective operation, the > default handling rules described herein do not affect these > operations. > > I suggest introduce an optional parameter in capability URI to > indicate what other affected opertions are supported by > Netconf server, and at least I can see following benefits: > > (1) this dynamic discovery of affected operations can sync client > with server timely. > > (2) If the relevant docs are unreachable for the client, the client > can still discover the affected operations without document > consultant. > > (3) maybe it is effective and efficient for the client. > > The capability URI would look like this: > > urn:ietf:params:netconf:capability:with-defaults:1.0?basic=report- > all&supported=trim:explicit&ops=ns1:op1,ns2:op2 > ^^^^^^^^^^^^^ > > Any comments? > > washam > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Wed May 20 00:38:02 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B483A6BCE for ; Wed, 20 May 2009 00:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHy4Zrtt8i7M for ; Wed, 20 May 2009 00:38:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 345803A6B14 for ; Wed, 20 May 2009 00:38:00 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-63-4a13b3b88e5a Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D5.AE.02630.8B3B31A4; Wed, 20 May 2009 09:39:37 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:39:36 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:39:36 +0200 Message-ID: <4A13B3B7.6020901@ericsson.com> Date: Wed, 20 May 2009 09:39:35 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Randy Presuhn References: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> In-Reply-To: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2009 07:39:36.0148 (UTC) FILETIME=[1FBCC140:01C9D91E] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 07:38:02 -0000 Hello Randy, My statement is that based only on statements in rfc4741 partial-locking will not change the current problems around potential access-control related dead-locks. At this time I don't want to comment on the NETCONF access control model. Balazs PS. Putting aside partial-locks you could ask some other interesting questions about access control as well: - when is it enforced: at commit or at editing the candidate or both. Enforcement at commit seems mandatory today. You may propose to change that later. - will you always have the same access rights for different data stores - can you lock something if you don't have access rights to it? - what access rights do you need for kill-session? (Which effectively can remove edits from the candidate due to locking). So kill-session is strangely an editing operation as well But if you want to discuss this please change the thread ! Randy Presuhn wrote: > Hi - > >> From: Martin Bjorklund >> Sent: May 19, 2009 11:47 AM >> To: randy_presuhn@mindspring.com >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Partial-lock issues >> >> "Randy Presuhn" wrote: >>> Hi - >>> >>>> From: "Balazs Lengyel" >>>> To: "netconf mailing list" >>>> Sent: Tuesday, May 19, 2009 3:01 AM >>>> Subject: [Netconf] Partial-lock issues >>> ... >>>> Please state if you can accept the reasoning below or whether you think we >>>> should allow >>>> partial-locking ONLY for the running configuration? >>>> >>>> 1) As Washam pointed out just by having access control and without using any >>>> locks we face a >>>> dead-lock problems: >>>> - A only has access to /foo, and edits it in candidate >>>> - B only has access to /bar, and edits it in candidate >>>> - A terminates it's session >>>> - Now B can not issue because it can not modify /foo in the >>>> - candidate >>>> - B can not issue because it can not modify /foo in the running >>>> If A and/or B uses partial-locking that will NOT make this situation WORSE, >>>> as the lock is >>>> automatically released at the end of the session. The real problem is caused >>>> by access control. >>> ... >>> >>> This reasoning makes an unwarranted assumption about how access control works. >>> Specifically, it assumes that the access control policy is evaluated at the >>> time of >>> the , rather than simply being applied to each individual >>> edit. >> No, I don't think the example makes that assumption. The only >> assumption it makes is that the access control policy is *at least* >> evaluated as part of commit. This is a use case that is explicitly >> mentioned in RFC 4741, section 9: >> >> For >> example, if a user A is not allowed to configure an IP address on an >> interface but user B has configured an IP address on an interface in >> the configuration, user A must not be allowed to commit >> the configuration. > > If you read that into the example, then the access control model is > hopelessly broken with respect to locking. Commit is the wrong time > to evaluate the access decision function, unless each individual delta > (rather than the entire configuration) is marked with the identity > of the party responsible for that part of the total change-set. As > long as *all* deltas happening in the course of a commit are handled > as though they had been made by the party whose action caused the > commit to happen, the deadlock will occur. > > A much simpler approach is to evaluate the access decision function > at the time of each individual edit, rather than the commit. > > > Randy > > Randy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From MARKSCOT@nortel.com Wed May 20 10:09:54 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60A528C0DD for ; Wed, 20 May 2009 10:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S+hLJGcyvlF for ; Wed, 20 May 2009 10:09:53 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6A2323A6FA4 for ; Wed, 20 May 2009 10:09:53 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4KHB8D19635; Wed, 20 May 2009 17:11:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2009 13:10:35 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D192E3867@zcarhxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution Thread-Index: AcnVBjfc3mYGN/YTRQSP24gBV73OBAEZluKg References: <20090511.215904.194263974.mbj@tail-f.com><20090511202831.GA2663@elstar.local><085091CB2CA14E4B8B163FFC37C84E9D19101D86@zcarhxm0.corp.nortel.com><20090511.234732.101592886.mbj@tail-f.com><085091CB2CA14E4B8B163FFC37C84E9D192221B7@zcarhxm0.corp.nortel.com> From: "Mark Scott" To: "WashamFan" , Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 17:09:54 -0000 Hi Washam, My apologies on the part of our aggressive email filters. I tried to get your other account unblocked but appears it didn't help. Hopefully this address won't get blocked. To your question below: In my opinion any session which is reported SHOULD be able to be managed (incl. kill session, lock release). The only thing we are standardizing though is that if non-NETCONF sessions are monitored then they MUST be done so with a non-0 sessionId. We are not standardizing that such sessions must be monitored though nor that if reported that the NETCONF implementation must be able to perform any/specific operations on them. Since as we both note below although there is limited value in reporting the sessions NETCONF can't affect we don't want to prohibit this. There are cases where simply knowing another protocol is managing the box can still be useful. So no need to put specific list of operations which must support such sessions - this will be vendor specific. Hopefully this better explains the thinking behind this. We can ask to have this added to 4741bis as well if you think it needs to be spelled out explicitly? thx, Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of WashamFan Sent: Thursday, May 14, 2009 10:38 PM To: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft:sessionIduniquenessproposed resolution Hi, Mark Please update my email to this account. (Since your spam always blocks my emails from this account, we've lost touch=20 for a quite while. Did you received the email Juergen forwarded for me?) > Yes that's what I meant as well. > =20 > Basically: > - retain sessionId=3D0 for anything 'unknown' but don't report these = in > the session list > - since NETCONF can't do anything meaningful with the session no > need to report it other than in errors I tend to agree. > - for implementations that can do something meaningful (like session > mgmt, lock mgmt) then report it in the session list > - NETCONF server is responsible for providing a unique sessionId > for such mapped sessions > =20 > - Benefits: > - this retains backwards compatibility with 4741 > - single unique sessionId key in the table Do you mean keep the table as it is? Then, Is =20 allowed to terminate a non-Netconf session who has a sessionId=20 in the table? I am afraid the answer is no according to current=20 text in 4741 or 4741bis. If so, how to interact with non-netconf sessions via Netconf? ( And what the interaction exactly are?) I am not opposing the proposal, but just trying to understand. One more thing. Although I issue the topic firstly, but I doubt if there is a consensus on mutiple protocol sessions monitoring. And I think the answers to my questions raised above could justify the issue a little ;) washam > - can work for all protocols > =20 > Do we have consensus on this? > =20 > Mark > =20 > =20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > Sent: Monday, May 11, 2009 5:48 PM > To: Scott, Mark (CAR:2N00) > Cc: j.schoenwaelder@jacobs-university.de; andy@netconfcentral.com; > washam.fan@huawei.com; netconf@ietf.org > Subject: Re: [Netconf] [NETCONF] Monitoring > draft:sessionIduniquenessproposed resolution > =20 > "Mark Scott" wrote: > > Could we mandate that a NETCONF server must provide/map a unique > > sessionId for all sessions being monitored by it (regardless of > > protocol)? > =20 > I think what you write is very good, except I would not mandate this > mapping. But maybe that's what you meant as well? Servers should > report sessionId 0 in errors such as 'lock-denied' for sessions they > do not manage (using you terminology). This would allow > multi-protocol servers to utilize their capabilities w/o extra vendor > specific info for the clients to understand, at the same time as > single-protocol servers can still function. For the client, there are > no difference - if it gets a valid session id, it can look it up, > maybe kill it etc. If it gets session id 0, it knows that it > represents some kind of "unknown" session. > =20 > session id 0 would never show up in the session list. > =20 > =20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > =20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From randy_presuhn@mindspring.com Wed May 20 10:17:55 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4583B3A6B57 for ; Wed, 20 May 2009 10:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtTTM1+VWomD for ; Wed, 20 May 2009 10:17:54 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 518353A6A3E for ; Wed, 20 May 2009 10:17:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bRagNSbb0WzCdD5+Ln0WajcjwevFKfvJn1Z/Yt41Rj6FXHFk6Mq84ItFFMnJ7RqK; 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 [64.105.35.85] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M6pRz-0004yM-Gj for netconf@ietf.org; Wed, 20 May 2009 13:19:31 -0400 Message-ID: <000d01c9d96f$9850d000$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <4A13B3B7.6020901@ericsson.com> Date: Wed, 20 May 2009 10:22:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69683fc7d60b7551d410b349517661c5170d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.85 Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 17:17:55 -0000 Hi - > From: "Balazs Lengyel" > To: "Randy Presuhn" > Cc: "Martin Bjorklund" ; > Sent: Wednesday, May 20, 2009 12:39 AM > Subject: Re: [Netconf] Partial-lock issues ... > At this time I don't want > to comment on the NETCONF access control model. ... > But if you want to discuss this please change the thread ! ... Not really. This should have been done during the architecture and protocol design phase. I think it's really too late to properly fix, and will instead require a succession of partial fixes. This discussion is just one example of the kind of thing that will come up again and again. Have fun. Randy From andy@netconfcentral.com Wed May 20 10:40:01 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22AD28C145 for ; Wed, 20 May 2009 10:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFkty5W0Dyop for ; Wed, 20 May 2009 10:40:01 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 0DEAA3A6E7E for ; Wed, 20 May 2009 10:40:01 -0700 (PDT) Received: (qmail 44176 invoked from network); 20 May 2009 17:41:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 20 May 2009 17:41:35 -0000 X-YMail-OSG: BVSVcZUVM1lhIMpswRIMS0XajIrRN38p2oysz9ZaBEGWORC2uSzvne1uWzP4HMmdmftF.a4LWdXkbPTa7WnBkDMeMuxPQ6gcsHdT9CrCMjqu2FXQS1qzXl4sQhnr0H89PlG7alAFylIOZrWHJCylQVES4WUI2FL9ln_BD6iAEEHzmUnIZW2sc7s7blEkn6U5jXvS9tbXh_kh99uRolxufUHRMQAxAG1elUj8k3rMh2BEAkyc597i7G9k3lCn4hsHAapwB6ehlydtZRraGwfDrhzupu73cXeHWsOOm5Rzu.8qZbX2n9rG X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1440CD.1020501@netconfcentral.com> Date: Wed, 20 May 2009 10:41:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Randy Presuhn References: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <4A13B3B7.6020901@ericsson.com> <000d01c9d96f$9850d000$6801a8c0@oemcomputer> In-Reply-To: <000d01c9d96f$9850d000$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 17:40:01 -0000 Randy Presuhn wrote: > Hi - > >> From: "Balazs Lengyel" >> To: "Randy Presuhn" >> Cc: "Martin Bjorklund" ; >> Sent: Wednesday, May 20, 2009 12:39 AM >> Subject: Re: [Netconf] Partial-lock issues > ... >> At this time I don't want >> to comment on the NETCONF access control model. > ... >> But if you want to discuss this please change the thread ! > ... > > Not really. This should have been done during the architecture > and protocol design phase. I think it's really too late to properly > fix, and will instead require a succession of partial fixes. This > discussion is just one example of the kind of thing that will come > up again and again. Have fun. > I agree with Randy. How many proprietary ACMs are actually implemented? What is being done already? It never occurred to me to define a ACM that worked differently for one NETCONF database vs. another one. It is also the accepted BCP in NETCONF/YANG to report errors as soon as possible, rather than as late as possible -- if the error state cannot possibly change (e.g., invalid-value or access-denied). The $64 question is the correct RFC2119 word to use: The agent (MUST/SHOULD/MAY) apply access control policies to the candidate database (not just the running database). IMO, if you do not have permission to commit something then do not pretend it is going to work by allowing edits to the restricted data in any 'scratchpad' database. > Randy Andy From andy@netconfcentral.com Wed May 20 10:52:55 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4969A3A68A8 for ; Wed, 20 May 2009 10:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEviS2+znr+N for ; Wed, 20 May 2009 10:52:54 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 8E76A28C0CF for ; Wed, 20 May 2009 10:52:54 -0700 (PDT) Received: (qmail 8878 invoked from network); 20 May 2009 17:54:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 20 May 2009 17:54:31 -0000 X-YMail-OSG: TssLcU8VM1kSZysD985IIzmIFno9JtjTsof7fiNBWwOGvKzG3kFF50HFx5sVmg9JE2RBIka3ZjpBds5Bk6I_Y3ciCB2gpCEJOFObEoeIUUv22Z29h.ULCq8wMLYXSdFlEm04uRN8LX2MvFYFx_J6Z7T9Wsg1t1pECqNPYgHwKNaO4PAIfl_29Fgyp3LH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1443D6.2080007@netconfcentral.com> Date: Wed, 20 May 2009 10:54:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Randy Presuhn References: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <4A13B3B7.6020901@ericsson.com> <000d01c9d96f$9850d000$6801a8c0@oemcomputer> <4A1440CD.1020501@netconfcentral.com> In-Reply-To: <4A1440CD.1020501@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 17:52:55 -0000 Andy Bierman wrote: > Randy Presuhn wrote: >> Hi - >> ... > IMO, if you do not have permission to commit something > then do not pretend it is going to work by allowing > edits to the restricted data in any 'scratchpad' database. > Isn't it a security hole to allow a user to edit and/or view restricted data in the candidate (or any scratchpad) database? I'm not a security guy, but it seems better to return an access-denied error for the very highest restricted node that is referenced. Otherwise, a hacker can get the agent to disclose information that may be helpful to spread the attack to other parts of the system (e.g., determine the features and exact objects implemented on the agent). If I am not authorized to view the /foo subtree in the running config, then why would the agent allow me to view a copy of this exact data in another database? That seems like a fairly obvious security practice to avoid. > >> Randy > > Andy > Andy From Washam.Fan@huaweisymantec.com Wed May 20 19:31:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EF63A6D1F for ; Wed, 20 May 2009 19:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02jReE17bjEK for ; Wed, 20 May 2009 19:31:14 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id F0B213A6866 for ; Wed, 20 May 2009 19:31:13 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJZ00L2M32H3M10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 21 May 2009 10:32:41 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJZ000E132HGI20@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 21 May 2009 10:32:41 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 21 May 2009 10:32:41 +0800 From: WashamFan To: netconf@ietf.org Message-id: Date: Thu, 21 May 2009 10:32:41 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <085091CB2CA14E4B8B163FFC37C84E9D192E3867@zcarhxm0.corp.nortel.com> References: <20090511.215904.194263974.mbj@tail-f.com> <20090511202831.GA2663@elstar.local> <085091CB2CA14E4B8B163FFC37C84E9D19101D86@zcarhxm0.corp.nortel.com> <20090511.234732.101592886.mbj@tail-f.com> <085091CB2CA14E4B8B163FFC37C84E9D192221B7@zcarhxm0.corp.nortel.com> <085091CB2CA14E4B8B163FFC37C84E9D192E3867@zcarhxm0.corp.nortel.com> Subject: Re: [Netconf] [NETCONF] Monitorin draft:sessionIduniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 02:31:15 -0000 Hi, Thanks. I am fine with the proposal. Well, the only thing I concern is the explicit statement added to 4741bis. Currently, 4741bis explicit states is to terminate a NETCONF session by force. So I just suggest it state is to kill the session identified by the session-id parameter which is probably a non-NETCONF session as well as NETCONF session. washam > Hi Washam, > > My apologies on the part of our aggressive email filters. I tried to > get your other account unblocked but appears it didn't help. Hopefully > this address won't get blocked. > > To your question below: In my opinion any session which is reported > SHOULD be able to be managed (incl. kill session, lock release). The > only thing we are standardizing though is that if non-NETCONF sessions > are monitored then they MUST be done so with a non-0 sessionId. > > We are not standardizing that such sessions must be monitored though > nor > that if reported that the NETCONF implementation must be able to perform > any/specific operations on them. Since as we both note below although > there is limited value in reporting the sessions NETCONF can't affect > we > don't want to prohibit this. There are cases where simply knowing > another protocol is managing the box can still be useful. So no need > to > put specific list of operations which must support such sessions - this > will be vendor specific. > > Hopefully this better explains the thinking behind this. > > We can ask to have this added to 4741bis as well if you think it needs > to be spelled out explicitly? > > thx, > Mark From lhotka@cesnet.cz Thu May 21 00:07:20 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8E83A6ED8 for ; Thu, 21 May 2009 00:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.913 X-Spam-Level: X-Spam-Status: No, score=-0.913 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsDchukFA1Hg for ; Thu, 21 May 2009 00:07:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 751443A6DD9 for ; Thu, 21 May 2009 00:07:19 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 11D86D800BD for ; Thu, 21 May 2009 09:08:30 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <4A1443D6.2080007@netconfcentral.com> References: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <4A13B3B7.6020901@ericsson.com> <000d01c9d96f$9850d000$6801a8c0@oemcomputer> <4A1440CD.1020501@netconfcentral.com> <4A1443D6.2080007@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Thu, 21 May 2009 09:08:30 +0200 Message-Id: <1242889710.6931.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 07:07:20 -0000 Andy Bierman píše v St 20. 05. 2009 v 10:54 -0700: > Andy Bierman wrote: > > Randy Presuhn wrote: > >> Hi - > >> > ... > > IMO, if you do not have permission to commit something > > then do not pretend it is going to work by allowing > > edits to the restricted data in any 'scratchpad' database. > > > > Isn't it a security hole to allow a user to edit and/or view > restricted data in the candidate (or any scratchpad) database? I think it is, since the edits in "candidate" performed by an unprivileged user can be later commited inadvertently by a privileged user. Lada > > I'm not a security guy, but it seems better to return > an access-denied error for the very highest restricted > node that is referenced. > > Otherwise, a hacker can get the agent to disclose information > that may be helpful to spread the attack to other > parts of the system (e.g., determine the features and exact objects > implemented on the agent). > > If I am not authorized to view the /foo subtree > in the running config, then why would the agent > allow me to view a copy of this exact data in > another database? That seems like a fairly obvious > security practice to avoid. > > > > > > >> Randy > > > > Andy > > > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Thu May 21 05:37:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A0C3A6C74 for ; Thu, 21 May 2009 05:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIlSPQuXz8vn for ; Thu, 21 May 2009 05:37:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 240C83A68B2 for ; Thu, 21 May 2009 05:37:14 -0700 (PDT) X-AuditID: c1b4fb3c-b7b87ae000000ec5-fb-4a154b5be451 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 76.E9.03781.B5B451A4; Thu, 21 May 2009 14:38:52 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 14:38:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 14:38:51 +0200 Message-ID: <4A154B5A.1030709@ericsson.com> Date: Thu, 21 May 2009 14:38:50 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <33294472.1242765611176.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <4A13B3B7.6020901@ericsson.com> <000d01c9d96f$9850d000$6801a8c0@oemcomputer> <4A1440CD.1020501@netconfcentral.com> <4A1443D6.2080007@netconfcentral.com> <1242889710.6931.24.camel@missotis> In-Reply-To: <1242889710.6931.24.camel@missotis> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 May 2009 12:38:51.0132 (UTC) FILETIME=[1827A3C0:01C9DA11] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: [Netconf] Access Control [was partial-lock bla-bla-bla] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 12:37:16 -0000 Hello, So we seem to agree on access control principle number one: 1) Access control rights for the running and candidate configurations MUST be the same; because - more read rights on candidate leads to info leaks - more write rights on candidate might lead to inadvertent commit by a super-user - fewer read rights on the candidate are just stupid, as you can commit it and then read the same stuff from the running - fewer write rights on candidate seriously hamper candidate based work practices although they are not a security problem. It would also lead to some surprising behavior concerning discard-changes or a copy-config Should the access rights on start-up and running also be the same? Probably yes - Fewer read right on startup then running seems stupid, as after a restart the user will anyway see the stuff from startup - fewer write rights on startup then running, seems strange but maybe OK - more read rights on startup then running seems stupid, as startup may become the running anytime, in which case we will know whats there. There might be corner cases when you do some short term change in running, but that IS a corner case - more write rights on startup then running (probably using copy-config) seem stupid as you can write to startup then after restart you get your data into running Balazs Ladislav Lhotka wrote: > Andy Bierman píše v St 20. 05. 2009 v 10:54 -0700: >> Andy Bierman wrote: >>> Randy Presuhn wrote: >>>> Hi - >>>> >> ... >>> IMO, if you do not have permission to commit something >>> then do not pretend it is going to work by allowing >>> edits to the restricted data in any 'scratchpad' database. >>> >> Isn't it a security hole to allow a user to edit and/or view >> restricted data in the candidate (or any scratchpad) database? > > I think it is, since the edits in "candidate" performed by an > unprivileged user can be later commited inadvertently by a privileged > user. > > Lada > >> I'm not a security guy, but it seems better to return >> an access-denied error for the very highest restricted >> node that is referenced. >> >> Otherwise, a hacker can get the agent to disclose information >> that may be helpful to spread the attack to other >> parts of the system (e.g., determine the features and exact objects >> implemented on the agent). >> >> If I am not authorized to view the /foo subtree >> in the running config, then why would the agent >> allow me to view a copy of this exact data in >> another database? That seems like a fairly obvious >> security practice to avoid. >> >> >> >>>> Randy >>> Andy >>> >> >> Andy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From dbharrington@comcast.net Thu May 21 05:38:42 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2213C3A6C74 for ; Thu, 21 May 2009 05:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDZOfqg-Y36y for ; Thu, 21 May 2009 05:38:34 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id F3FC93A68B2 for ; Thu, 21 May 2009 05:38:33 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA04.westchester.pa.mail.comcast.net with comcast id uAR71b00U0xGWP854CgA5L; Thu, 21 May 2009 12:40:10 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id uCg81b00b0UQ6dC3YCg8TJ; Thu, 21 May 2009 12:40:10 +0000 From: "David B Harrington" To: "'Mark Scott'" , , "'Washam Fan'" , "'Martin Bjorklund'" References: <085091CB2CA14E4B8B163FFC37C84E9D1927F842@zcarhxm0.corp.nortel.com> Date: Thu, 21 May 2009 08:40:07 -0400 Message-ID: <021a01c9da11$469e04b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021B_01C9D9EF.BF8C64B0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnPOLzvASnCcoVERCiaCjKO2GR4ggJZ5VSAAFvmVgA= In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1927F842@zcarhxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 12:38:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_021B_01C9D9EF.BF8C64B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have not been able to actively follow these discussions. I have a concern about netconf actively modifying locks of other NM interfaces. Monitoring makes sense for troubleshooting purposes; monitoring could raise security issues of disclosure, but I think that risk is fairly minimal. Modifying locks across NM systems raises serious security concerns. SNMP is designed to be extensible. It can have multiple PDU types, multiple access control models, etc. Netconf does not understand SNMP access controls, such as VACM. If a new PDU type or a new access control were added to an SNMP implementation, netconf would not necesarily know about the details. That means that a person with netconf rights could modify SNMP locks, even if they were not authorized to set or release SNMP locks using SNMP. Or a person with netconf rights could modify CLI locks, even if they were not authorized to set or release CLI locks using CLI. In the same way, an SNMP user should not be allowed to set or release netconf locks. SNMP knows nothing about netconf access controls, so the SNMP user might not have the authority to set or release such locks via netconf. Allowing one NM system to ignore or alter the locks of another NM system is BAD! This could cause misconfigurations and/or security vulnerabilities. The only time this should be allowed is if an administrator realizes that a lock must be overridden, and uses "root" access (e.g., via a CLI) to forcibly remove a lock for a different NM interface. dbh _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Mark Scott Sent: Tuesday, May 19, 2009 1:04 PM To: Mark Scott; andy@netconfcentral.com; Washam Fan; Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniquenessproposed resolution Hello, After a series of ML discussions the following revision was reached for the sessionId uniqueness issue: --- session |_sessionId (key) |_transport |_protocol |_username |_sourceHost |_loginTime sessionId (type: SessionId) Unique NETCONF identifier for the session, used for all supported operations (e.g. monitoring, session kill, lock release) regardless of protocol. MUST be a unique non-0 value for all sessions reported. SessionId=0 will not be reported in the session table. For purposes of NETCONF management all sessions are one of: Known session: any session which can be managed by the NETCONF server SHOULD be reported in this table and MUST map to a unique sessionId as described above Unknown session: such sessions are not managed by the NETCONF server and all map to sessionId=0. They MUST be excluded from the session table as a result. SessionId=0 will continue to be reported in error messages with sessionId=0 per existing 4741 definition. --- This reflects consensus in the ML discussion. In particular it addresses concerns with 4741 backwards compatibility while providing the ability to uniquely manage non-NETCONF sessions if an implementation chooses to do so. Thank you to all who participated in the discussion. If I missed any inputs/considerations please feel free to raise them again along with any alternatives to be considered. The monitoring draft will be updated accordingly. Mark From: Scott, Mark (CAR:2N00) Sent: Thursday, May 07, 2009 1:25 PM To: andy@netconfcentral.com; 'Washam Fan'; 'Martin Bjorklund' Cc: netconf@ietf.org Subject: [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution Hello, In response to ML discussion for open item 'sessionID uniqueness' in the NETCONF Monitoring draft: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04 Please review the issue and in particular the 'suggested resolution' below and reply with your agreement or suggestion for alternative in an attempt to reach WG consensus on this issue. ISSUE: Key definition for ManagementSessionInfo ------------------------------------------------ Current draft assumes sessionId will be unique for both NETCONF and non-NETCONF sessions reported via monitoring data. SessionId uniqueness holds for NETCONF session. An issues arises applying same assumption to non-NETCONF sessions: We have expressed opinion that sessionId uniqueness should also be mandated for all non-NETCONF entries included in the monitoring data since other protocols have similar use cases where a unique Id is required and/or a mapping scheme needs to be provided if a NETCONF implementation wants to manage non-NETCONF sessions. In particular if an implementation wants to extend support for an operation such as to non-NETCONF sessions. However there is a side discussion underway on whether or not 4741 intended for sessionId=0 to be mandatory for non-NETCONF sessions in all cases. Have asked for clarification in 4741bis. Until that is resolved we cannot mandate non-0 sessionId values in the monitoring data and don't want to delay monitoring on that decision. Suggestions to use a tuple of existing fields were considered. In particular the use of sessionId, protocol and sourceHost but this doesn't guarantee uniqueness either. More fields (like loginTime) could be included but may lead to an increasing complex key as more protocols (and more issues of uniqueness) are monitored. It is agreed we do want to keep the ability to report non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF entries needs to be added. SUGGESTED RESOLUTION: Add 'nativeSessionId', quality 'netconfSessionId' and extend key ---------------------------------------------------------------------- ------------------ Per Andy's suggestion, refine ManagementSessionInfo, changing section 2.1.4 and model: session |_netconfSessionId (key) |_associatedSession (key) |_transport |_protocol |_username |_sourceHost |_loginTime netconfSessionId (type: SessionId) NETCONF identifier for the session. This is the unique sessionId used for all NETCONF operations. This is not guaranteed to be unique for non-NETCONF sessions. associatedSession (type: string) Identifer used within NETCONF to associate to the native session in non-NETCONF protocol. For NETCONF sessions the value MUST match netconfSessionid. For non-NETCONF sessions, when a native session identifier is available this value should be the equal (string equivalent). It is expected this value will be unique when available for each reported particular protocol type. For non-NETCONF sessions, when a native session identifier is not available (e.g. sessionless protocol) and the NETCONF implementation chooses to report the sessions it MUST provide an associated session Id value. The key for the ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be unique in all cases. xs:string is chosen to allow mapping to multiple native datatypes. cheers, mark ------=_NextPart_000_021B_01C9D9EF.BF8C64B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have not been able = to actively=20 follow these discussions. I have a concern about netconf actively = modifying=20 locks of other NM interfaces. Monitoring makes sense for troubleshooting = purposes; monitoring could raise security issues of disclosure, but I = think that=20 risk is fairly minimal. Modifying locks across NM systems raises serious = security concerns.

SNMP is = designed to be=20 extensible. It can have multiple PDU types, multiple access control = models, etc.=20 Netconf does not understand SNMP access controls,=20 such as VACM. If a new PDU type or a new access control were = added to an=20 SNMP implementation, netconf would not necesarily know about the = details. That=20 means that a person with netconf rights could modify SNMP locks, even if = they=20 were not authorized to set or release SNMP locks using SNMP. Or a person with netconf rights could modify = CLI=20 locks, even if they were not authorized to set or release CLI locks = using=20 CLI.

In the same way, an SNMP user should not be allowed to = set or=20 release netconf locks. SNMP knows = nothing about=20 netconf access controls, so the = SNMP=20 user might not have the authority to set or release such = locks via=20 netconf. Allowing one NM system to ignore or alter the locks of another = NM=20 system is BAD! This could cause misconfigurations and/or security=20 vulnerabilities.

The only time this should be allowed is if an = administrator=20 realizes that a lock must be overridden, and uses "root" access (e.g., = via a=20 CLI) to forcibly remove a lock for a different NM interface.

dbh


From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Mark=20 Scott
Sent: Tuesday, May 19, 2009 1:04 PM
To: Mark = Scott;=20 andy@netconfcentral.com; Washam Fan; Martin Bjorklund
Cc:=20 netconf@ietf.org
Subject: Re: [Netconf] [NETCONF] Monitoring = draft:=20 sessionId uniquenessproposed resolution

Hello,

 

After a series of = ML=20 discussions the following revision was reached for the sessionId = uniqueness=20 issue:

 

---

session

       = |_sessionId=20 (key)

      =20 |_transport

      =20 |_protocol

      =20 |_username

      =20 |_sourceHost

      =20 |_loginTime

 

sessionId (type: SessionId)

    Unique NETCONF = identifier for=20 the session, used for all supported operations (e.g. monitoring, = session kill,=20 lock release) regardless of protocol.

    MUST be a unique non-0 = value for all=20 sessions reported.  SessionId=3D0 will not be reported in the = session=20 table.

    For purposes of NETCONF = management=20 all sessions are one of:

       Known=20 session:  any session which can be managed by the NETCONF server = SHOULD=20 be reported in this table and MUST map to a unique sessionId as = described=20 above

       Unknown=20 session:  such sessions are not managed by the NETCONF server and = all map=20 to sessionId=3D0.  They MUST be excluded from the session table = as a=20 result.  SessionId=3D0 will continue to be reported in error = messages with=20 sessionId=3D0 per existing 4741 definition.

 

---

 

This reflects = consensus in the=20 ML discussion.  In particular it addresses concerns with 4741 = backwards=20 compatibility while providing the ability to uniquely manage = non-NETCONF=20 sessions if an implementation chooses to do so.

 

Thank you to all = who=20 participated in the discussion.   If I missed any=20 inputs/considerations please feel free to raise them again along with = any=20 alternatives to be considered.

 

The monitoring = draft will be=20 updated accordingly.

 

Mark

 

 

From: Scott, = Mark=20 (CAR:2N00)
Sent: Thursday, May 07, 2009 1:25 = PM
To:=20 andy@netconfcentral.com; 'Washam Fan'; 'Martin = Bjorklund'
Cc:=20 netconf@ietf.org
Subject: [NETCONF] Monitoring draft: = sessionId=20 uniqueness proposed resolution

 

Hello,

 

In response to ML discussion for open item = ‘sessionID=20 uniqueness’ in the NETCONF Monitoring draft:  http= ://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

 

Please review the issue and in particular the = 'suggested=20 resolution' below and reply with your agreement or suggestion for = alternative=20 in an attempt to reach WG consensus on this issue.

 

ISSUE:  Key definition for=20 ManagementSessionInfo

------------------------------------------------

 

Current draft assumes sessionId will be unique = for both=20 NETCONF and non-NETCONF sessions reported via monitoring = data.

 

SessionId uniqueness holds for NETCONF = session.  An=20 issues arises applying same assumption to non-NETCONF = sessions:

 

We have expressed opinion that sessionId = uniqueness=20 should also be mandated for all non-NETCONF entries included in the = monitoring=20 data since other protocols have similar use cases where a unique Id is = required and/or a mapping scheme needs to be provided if a NETCONF=20 implementation wants to manage non-NETCONF sessions.  In = particular if an=20 implementation wants to extend support for an operation such as=20 <kill-session> to non-NETCONF sessions.

 

However there is a side discussion underway on = whether=20 or not 4741 intended for sessionId=3D0 to be mandatory for non-NETCONF = sessions=20 in all cases.  Have asked for clarification in 4741bis.  = Until that=20 is resolved we cannot mandate non-0 sessionId values in the monitoring = data=20 and don’t want to delay monitoring on that = decision.

 

Suggestions to use a tuple of existing fields = were=20 considered.  In particular the use of sessionId, protocol and = sourceHost=20 but this doesn't guarantee uniqueness either.  More fields (like=20 loginTime) could be included but may lead to an increasing complex key = as more=20 protocols (and more issues of uniqueness) are = monitored.

 

It is agreed we do want to keep the ability to = report=20 non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF = entries=20 needs to be added.

 

 

SUGGESTED RESOLUTION:  Add = ‘nativeSessionId’,=20 quality ‘netconfSessionId’ and extend key

----------------------------------------------------= ------------------------------------

 

Per Andy’s suggestion, refine = ManagementSessionInfo,=20 changing section 2.1.4 and model:

 

session

       = |_netconfSessionId=20 (key)

 |_associatedSession=20 (key)

      =20 |_transport

      =20 |_protocol

      =20 |_username

      =20 |_sourceHost

      =20 |_loginTime

 

netconfSessionId (type: = SessionId)

     NETCONF identifier = for the=20 session.

     This is the unique = sessionId=20 used for all NETCONF operations.

     This is not = guaranteed to be=20 unique for non-NETCONF sessions.

 

associatedSession (type: = string)

     Identifer used within = NETCONF=20 to associate to the native session in non-NETCONF = protocol.

     For NETCONF sessions = the value=20 MUST match netconfSessionid.

     For non-NETCONF = sessions, when=20 a native session identifier is available this value should be the = equal=20 (string equivalent).  It is expected this value will be unique = when=20 available for each reported particular protocol type.

     For non-NETCONF = sessions, when=20 a native session identifier is not available (e.g. sessionless = protocol) and=20 the NETCONF implementation chooses to report the sessions it MUST = provide an=20 associated session Id value.      =

     The key for the=20 ManagementSessionInfo (netconfSessionId + associatedSessionId) MUST be = unique=20 in all cases.

     xs:string is chosen = to allow=20 mapping to multiple native datatypes.

 

 

cheers,

mark

------=_NextPart_000_021B_01C9D9EF.BF8C64B0-- From dbharrington@comcast.net Thu May 21 05:51:19 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8617B3A6C88 for ; Thu, 21 May 2009 05:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpNd9JaWSYHW for ; Thu, 21 May 2009 05:51:18 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id B8A583A6E6F for ; Thu, 21 May 2009 05:51:00 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id uAK31b0010SCNGk5BCsftU; Thu, 21 May 2009 12:52:39 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id uCsf1b0040UQ6dC3VCsfrn; Thu, 21 May 2009 12:52:39 +0000 From: "David B Harrington" To: "'WashamFan'" , "'Balazs Lengyel'" References: <20090414.103710.226431161.mbj@tail-f.com><49E45196.4060808@netconfcentral.com><20090414.110845.120951722.mbj@tail-f.com><49E4FDA7.7010408@netconfcentral.com><49E5F1CE.4010505@netconfcentral.com><49E6A1C1.9040309@netconfcentral.com><49EB4D9A.4000409@netconfcentral.com> <4A128391.90705@ericsson.com> Date: Thu, 21 May 2009 08:52:38 -0400 Message-ID: <022e01c9da13$055d6390$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnY7eZVTavGsjHoSO+IS5TtieGJXwBJEx1w In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'netconf mailing list' Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 12:51:19 -0000 Hi, I apparently had a different expectation about candidate configs. I assumed that each candidate would contain only the partially locked data, and that the candidate was basically globally locked. I think each candidate should be globally locked to a single editor. You should not have multiple editors simultaneously editing different portions of the same candidate. I don't have an issue with having multiple candidates, each of which can lock a different portion of the configuration (no overlapping partial locks). When an editor commits their candidate instance, only changes that occur within their partially locked data get committed. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of WashamFan > Sent: Tuesday, May 19, 2009 9:54 PM > To: Balazs Lengyel > Cc: netconf mailing list > Subject: Re: [Netconf] Partial-lock issues > > Hi, > > According to current relevant text, the only safe way to use > candidate is one-session-at-a-time as Andy said before. I.e., > global lock is recommended to be used for candidate edits. > Yes, the partial lock does not make the situation worse, but > it encourages multiple-session-at-a-time on candidate, which > leads to difficult recovery. > > So, I just suggest this use case removed. > > washam > > ----- Original Message ----- > From: Balazs Lengyel > Date: Tuesday, May 19, 2009 6:02 pm > Subject: [Netconf] Partial-lock issues > To: netconf mailing list > > > > Hello, > > Some people brought it up that partial-locking without > partial commit > > is not a good solution as > > it can lead to dead-locks. For one last time I try to list the > > reasons why we included candidate. > > > > Please state if you can accept the reasoning below or whether you > > think we should allow > > partial-locking ONLY for the running configuration? > > > > 1) As Washam pointed out just by having access control and without > > using any locks we face a > > dead-lock problems: > > - A only has access to /foo, and edits it in candidate > > - B only has access to /bar, and edits it in candidate > > - A terminates it's session > > - Now B can not issue because it can not modify > > /foo in the candidate > > - B can not issue because it can not modify /foo > in the running > > If A and/or B uses partial-locking that will NOT make this > situation > > WORSE, as the lock is > > automatically released at the end of the session. The real > problem is > > caused by access control. > > > > 2) When partial-locking is used correctly, there is no danger of > > dead-lock, and locking does > > help to protect the individual operator's activities. (In the next > > sequence we presume access > > control will not block any of the actions.) > > > > - Operator A locks everything it needs both in candidate > and running > > in one operation e.g. /foo > > - A edits the locked part in the candidate > > - A issues commit, if this fails due to lock conflicts, it simply > > releases the lock, and let's > > any concurrent operator (e.g. B) work on candidate; B will later > > commit changes done by A as > > well. Lock conflicts can include operator B locking /bar in the > > running configuration > > - Operator B works the same way on another area e.g. /bar > > - The operator that finishes editing last will successfully commit > > all changes to running (by > > this time there are no other locks) > > > > 3) Later we might introduce partial commit, in which case > > partial-locking would be very much > > needed/useful > > > > 4) Partial-locking does no evil > > > > 5) It is nice to have the feature available on all three datastores > > > > So we propose to keep partial-locking on candidate, but as this is > > only secondary use-case if > > the workgroup decides it can be removed. > > > > This question has already been raised a number of times, > so we would > > like to establish the > > workgroup > > consensus and follow it. PLEASE INDICATE WHETHER > PARTIAL-LOCKING ON > > CANDIDATE SHOULD STAY OR > > SHOULD BE REMOVED !!!! > > > > Balazs > > > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > System Manager > > ECN: 831 7320 Fax: +36 1 4377792 > > Tel: +36-1-437-7320 email: > Balazs.Lengyel@ericsson.com > > > > > > _______________________________________________ > > 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.com Thu May 21 08:17:47 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39963A69D8 for ; Thu, 21 May 2009 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU8b4jft1wmV for ; Thu, 21 May 2009 08:17:46 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 231883A6A63 for ; Thu, 21 May 2009 08:17:45 -0700 (PDT) Received: (qmail 53141 invoked from network); 21 May 2009 15:19:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.37 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 21 May 2009 15:19:21 -0000 X-YMail-OSG: tj1oJOMVM1mWDrBaqJbmh0N.xbGzO9xfBIlgzQootJeTjigvy7Pj3YBQfuW18Y7ug6fiaM1zcrBvl8rpaNVtbBtgY2wy4RdWg.fPm777XKz0CVElnlcdstEovrIdH6w05HwYym2e.2YBeSKZ49G0Uva3cNbfnJF0muBoXcqIYN1Gjh.aZZ_6OGu33H0gZ1Ct6ixB.IJmLr9A0PxhYMtVhIRnlI.4yOnGp.SsmdNSP9qBqXcc0_kIxC7F2avQyCYUgtRskH7dNqP0ARg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1570E2.2010402@netconfcentral.com> Date: Thu, 21 May 2009 08:18:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David B Harrington References: <20090414.103710.226431161.mbj@tail-f.com><49E45196.4060808@netconfcentral.com><20090414.110845.120951722.mbj@tail-f.com><49E4FDA7.7010408@netconfcentral.com><49E5F1CE.4010505@netconfcentral.com><49E6A1C1.9040309@netconfcentral.com><49EB4D9A.4000409@netconfcentral.com> <4A128391.90705@ericsson.com> <022e01c9da13$055d6390$0600a8c0@china.huawei.com> In-Reply-To: <022e01c9da13$055d6390$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'netconf mailing list' Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 15:17:47 -0000 David B Harrington wrote: > Hi, > > I apparently had a different expectation about candidate configs. > I assumed that each candidate would contain only the partially locked > data, and that the candidate was basically globally locked. > > I think each candidate should be globally locked to a single editor. > You should not have multiple editors simultaneously editing different > portions of the same candidate. There is only one global candidate config database, as defined in RFC 4741. > I don't have an issue with having multiple candidates, each of which > can lock a different portion of the configuration (no overlapping > partial locks). When an editor commits their candidate instance, only > changes that occur within their partially locked data get committed. > I have an issue with multiple candidate databases: It is not supported at all by the NETCONF standard. I think the monitoring draft is the wrong place to quasi-define NETCONF database architecture. The monitoring draft is the wrong place to introduce multi-protocol access for NETCONF databases. Just throwing non-NETCONF sessions in with the other sessions leads to all kinds of assumptions, like kill-session() for non-NETCONF sessions. The manager is likely to stuff in the session-id returned from the lock-denied error, so this is an important issue. It is a slippery slope. > dbh > Andy From balazs.lengyel@ericsson.com Thu May 21 08:47:38 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934563A6973 for ; Thu, 21 May 2009 08:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5chUa9JYFnm8 for ; Thu, 21 May 2009 08:47:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 44D8428C16A for ; Thu, 21 May 2009 08:47:36 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-4c-4a1577f8d4e4 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 81.1A.02630.8F7751A4; Thu, 21 May 2009 17:49:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 17:49:12 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 17:49:12 +0200 Message-ID: <4A1577F7.7020101@ericsson.com> Date: Thu, 21 May 2009 17:49:11 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David B Harrington References: <20090414.103710.226431161.mbj@tail-f.com><49E45196.4060808@netconfcentral.com><20090414.110845.120951722.mbj@tail-f.com><49E4FDA7.7010408@netconfcentral.com><49E5F1CE.4010505@netconfcentral.com><49E6A1C1.9040309@netconfcentral.com><49EB4D9A.4000409@netconfcentral.com> <4A128391.90705@ericsson.com> <022e01c9da13$055d6390$0600a8c0@china.huawei.com> In-Reply-To: <022e01c9da13$055d6390$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2009 15:49:12.0211 (UTC) FILETIME=[AFA5FE30:01C9DA2B] X-Brightmail-Tracker: AAAAAA== Cc: 'netconf mailing list' Subject: Re: [Netconf] Partial-lock issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 15:47:38 -0000 HelloDavid , I don't think anyone is currently proposing multiple candidates. Please reply to my previous mail from May the 19th where I tried to summarize the partial-lock versus candidate configuration issue. regards Balazs David B Harrington wrote: > Hi, > > I apparently had a different expectation about candidate configs. > I assumed that each candidate would contain only the partially locked > data, and that the candidate was basically globally locked. > > I think each candidate should be globally locked to a single editor. > You should not have multiple editors simultaneously editing different > portions of the same candidate. > I don't have an issue with having multiple candidates, each of which > can lock a different portion of the configuration (no overlapping > partial locks). When an editor commits their candidate instance, only > changes that occur within their partially locked data get committed. > > dbh > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of WashamFan >> Sent: Tuesday, May 19, 2009 9:54 PM >> To: Balazs Lengyel >> Cc: netconf mailing list >> Subject: Re: [Netconf] Partial-lock issues >> >> Hi, >> >> According to current relevant text, the only safe way to use >> candidate is one-session-at-a-time as Andy said before. I.e., >> global lock is recommended to be used for candidate edits. >> Yes, the partial lock does not make the situation worse, but >> it encourages multiple-session-at-a-time on candidate, which >> leads to difficult recovery. >> >> So, I just suggest this use case removed. >> >> washam >> >> ----- Original Message ----- >> From: Balazs Lengyel >> Date: Tuesday, May 19, 2009 6:02 pm >> Subject: [Netconf] Partial-lock issues >> To: netconf mailing list >> >> >>> Hello, >>> Some people brought it up that partial-locking without >> partial commit >>> is not a good solution as >>> it can lead to dead-locks. For one last time I try to list the >>> reasons why we included candidate. >>> >>> Please state if you can accept the reasoning below or whether you > >>> think we should allow >>> partial-locking ONLY for the running configuration? >>> >>> 1) As Washam pointed out just by having access control and > without >>> using any locks we face a >>> dead-lock problems: >>> - A only has access to /foo, and edits it in candidate >>> - B only has access to /bar, and edits it in candidate >>> - A terminates it's session >>> - Now B can not issue because it can not modify > >>> /foo in the candidate >>> - B can not issue because it can not modify /foo >> in the running >>> If A and/or B uses partial-locking that will NOT make this >> situation >>> WORSE, as the lock is >>> automatically released at the end of the session. The real >> problem is >>> caused by access control. >>> >>> 2) When partial-locking is used correctly, there is no danger of >>> dead-lock, and locking does >>> help to protect the individual operator's activities. (In the > next >>> sequence we presume access >>> control will not block any of the actions.) >>> >>> - Operator A locks everything it needs both in candidate >> and running >>> in one operation e.g. /foo >>> - A edits the locked part in the candidate >>> - A issues commit, if this fails due to lock conflicts, it simply > >>> releases the lock, and let's >>> any concurrent operator (e.g. B) work on candidate; B will later >>> commit changes done by A as >>> well. Lock conflicts can include operator B locking /bar in the >>> running configuration >>> - Operator B works the same way on another area e.g. /bar >>> - The operator that finishes editing last will successfully > commit >>> all changes to running (by >>> this time there are no other locks) >>> >>> 3) Later we might introduce partial commit, in which case >>> partial-locking would be very much >>> needed/useful >>> >>> 4) Partial-locking does no evil >>> >>> 5) It is nice to have the feature available on all three > datastores >>> >>> So we propose to keep partial-locking on candidate, but as this > is >>> only secondary use-case if >>> the workgroup decides it can be removed. >>> >>> This question has already been raised a number of times, >> so we would >>> like to establish the >>> workgroup >>> consensus and follow it. PLEASE INDICATE WHETHER >> PARTIAL-LOCKING ON >>> CANDIDATE SHOULD STAY OR >>> SHOULD BE REMOVED !!!! >>> >>> Balazs >>> >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> System Manager >>> ECN: 831 7320 Fax: +36 1 4377792 >>> Tel: +36-1-437-7320 email: >> Balazs.Lengyel@ericsson.com >>> >>> >>> _______________________________________________ >>> 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 >> > > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Sat May 23 16:16:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2753A6829 for ; Sat, 23 May 2009 16:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dZfNzMkb2YF for ; Sat, 23 May 2009 16:16:15 -0700 (PDT) Received: from n24.bullet.mail.mud.yahoo.com (n24.bullet.mail.mud.yahoo.com [68.142.206.163]) by core3.amsl.com (Postfix) with SMTP id 4FFDA3A67E5 for ; Sat, 23 May 2009 16:16:15 -0700 (PDT) Received: from [68.142.200.224] by n24.bullet.mail.mud.yahoo.com with NNFMP; 23 May 2009 23:17:51 -0000 Received: from [68.142.201.250] by t5.bullet.mud.yahoo.com with NNFMP; 23 May 2009 23:17:51 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 23 May 2009 23:17:51 -0000 X-Yahoo-Newman-Id: 733387.39613.bm@omp411.mail.mud.yahoo.com Received: (qmail 25387 invoked from network); 23 May 2009 23:17:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 23 May 2009 23:17:50 -0000 X-YMail-OSG: SqlmJKkVM1ng6ndrOkXRSoYL8mhxWEh4o06rN5_9S9QiOAwvzTjUnvtfHM9OxOd.3y2cSdyCVuE1Qfp3Qs7Pd4OCDac74HxMJeGikb2rcKoleptEq7HOZyGmwjQE0jDZSoKFLfZNf_JpDutiwtxY2bPbQyOutbVqNXQQUwUisCIjoMpYIq7LV_fTo5LC4jLa8pQJRReEsIFb_Cp55xN_G3cyK281hiI6gTn42xTQmbphDi0CxSFzUn4wmnYW7ObNZuEroanPy3McDOMF X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A188408.2030504@netconfcentral.com> Date: Sat, 23 May 2009 16:17:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] remove partial-operation error-tag from 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 23:16:16 -0000 Hi, I would like the 'partial-operation' error-tag to be removed from NETCONF. I am not sure if it has been widely implemented, but IMO it is not worth implementing. The data type of the parameters (QName) is totally wrong, as Martin has already pointed out. This error-tag is very CLI-centric and does not really make sense in a NETCONF database, potentially full of interconnected nodes. It is very possible that the XML PDUs will not be treated as a serialized list of 'commands'. Since NETCONF has no real processing model, it is not clear if any agent really has to implement this error-tag anyway. (ARCH? We don't seem to need one of those ;-) Either remove 'partial-operation' or fix it. Fixing it means changing QName to instance-identifier and clearly defining a PDU processing model for arbitrary hierarchical data, such that every compliant agent implementation can be expected to produce consistent partial-operation error reports. Andy From mbj@tail-f.com Sun May 24 07:41:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C372F3A6D4E for ; Sun, 24 May 2009 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFhOpV0GUSY8 for ; Sun, 24 May 2009 07:41:15 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 928EF3A6F56 for ; Sun, 24 May 2009 07:41:08 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 67786616004; Sun, 24 May 2009 16:42:48 +0200 (CEST) Date: Sun, 24 May 2009 16:42:48 +0200 (CEST) Message-Id: <20090524.164248.232813739.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A188408.2030504@netconfcentral.com> References: <4A188408.2030504@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] remove partial-operation error-tag from 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 14:41:15 -0000 Andy Bierman wrote: > Hi, > > I would like the 'partial-operation' error-tag > to be removed from NETCONF. +1 I can see that it could have been useful, but if noone has implemented it so far, I think it is evidence that it wasn't as useful as it was thought to be. /martin From greg.rabil@jagornet.com Tue May 26 09:56:17 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DA93A6FE9; Tue, 26 May 2009 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrkpwRpr2sXr; Tue, 26 May 2009 09:56:17 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 7B1003A6C36; Tue, 26 May 2009 09:55:56 -0700 (PDT) Received: by ewy24 with SMTP id 24so3884036ewy.37 for ; Tue, 26 May 2009 09:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.8.83 with SMTP id 61mr3233949weq.156.1243357008027; Tue, 26 May 2009 09:56:48 -0700 (PDT) Date: Tue, 26 May 2009 12:56:48 -0400 Message-ID: From: "A. Gregory Rabil" To: netconf@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary=0016364d2369cae30b046ad39cbd Subject: Re: [Netconf] draft-rabil-dhc-dhcpv6-xmlconfig-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 16:56:17 -0000 --0016364d2369cae30b046ad39cbd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello NETCONF/NETMOD gurus, I have made an individual submission of an Internet-Draft which describes an XML schema for configuration of DHCPv6 servers. http://www.ietf.org/internet-drafts/draft-rabil-dhc-dhcpv6-xmlconfig-00.txt However, you will note that the definition is in XML Schema syntax. I have read the YANG draft, as well as a related draft which describes converting from YANG *to* XML schema. In general, I have to admit that I'm having trouble understanding the need for *another* language for specifying the contents of XML. XML Schema was supposed to be the defacto standard, now RelaxNG is competing for that, and further we have YANG. I would like to receive any comments or feedback from the folks in this working group as to what mechanisms may exist for converting *from* XML Schema *to* YANG or suggestions for defining the schema just once without the need to maintain several "authoritative" sources of the schema definition. BTW, an open-source implementation of a stateless DHCPv6 server which uses the XML configuration schema defined in the above draft as its native configuration format, is available at: http://code.google.com/p/jagornet-dhcpv6 Best regards, Greg Rabil --0016364d2369cae30b046ad39cbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello NETCONF/NETMOD gurus,

I have made an individual submission of = an Internet-Draft which describes an XML schema for configuration of DHCPv6 servers.

http://www.ietf.org/internet-drafts/draf= t-rabil-dhc-dhcpv6-xmlconfig-00.txt

However, you will note that = the definition is in XML Schema syntax.=A0 I have read the YANG draft, as w= ell as a related draft which describes converting from YANG to XML schema.=A0 In general, I have to admit that I'm having trouble un= derstanding the need for another language for specifying the = contents of XML.=A0 XML Schema was supposed to be the defacto standard, now= RelaxNG is competing for that, and further we have YANG.=A0 I would like t= o receive any comments or feedback from the folks in this working group as = to what mechanisms may exist for converting from XML Schema <= i>to YANG or suggestions for defining the schema just once witho= ut the need to maintain several "authoritative" sources of the sc= hema definition.


BTW, an open-source implementation of a stateless DHCPv6 server which uses the XML configuration schema defined in the above draft as its native = configuration format, is available at:

= http://code.google.com/p/jagornet-dhcpv6

Best regards,
Greg R= abil
--0016364d2369cae30b046ad39cbd-- From mbj@tail-f.com Tue May 26 12:37:47 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2BF3A716A; Tue, 26 May 2009 12:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgWLetpPalML; Tue, 26 May 2009 12:37:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id ADB973A7166; Tue, 26 May 2009 12:37:46 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EE03D616005; Tue, 26 May 2009 21:39:04 +0200 (CEST) Date: Tue, 26 May 2009 21:39:04 +0200 (CEST) Message-Id: <20090526.213904.79416403.mbj@tail-f.com> To: greg.rabil@jagornet.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 19:37:47 -0000 Hi Greg, "A. Gregory Rabil" wrote: > In general, I have to admit that I'm having > trouble understanding the need for *another* language for specifying the > contents of XML. YANG is not a generic XML Schema language. It is not used to specify the syntax of generic XML instance documents. YANG is used to describe configuration data models that can co-exist with other data models, evolve over time, be extended by other data models, and that can be manipulated with the NETCONF protocol. YANG is also used to decribe state data, rpcs and notifications, all handled by NETCONF. Some info is available at http://www.yang-central.org/twiki/bin/view/Main/WhyYang and from other links at yang-central. > XML Schema was supposed to be the defacto standard, now > RelaxNG is competing for that, and further we have YANG. I would like to > receive any comments or feedback from the folks in this working group as to > what mechanisms may exist for converting *from* XML Schema *to* YANG This is not possible in the general case, since YANG cannot model e.g. XML attributes. > or > suggestions for defining the schema just once without the need to maintain > several "authoritative" sources of the schema definition. If you have a YANG model, you can generate XSD and RNG from that model. This is implemented in tools like pyang and yangdump. /martin From greg.rabil@jagornet.com Tue May 26 13:57:25 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D383A6DA5; Tue, 26 May 2009 13:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORvmcTahGPr3; Tue, 26 May 2009 13:57:24 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 72F883A6988; Tue, 26 May 2009 13:57:23 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so970455eyd.31 for ; Tue, 26 May 2009 13:58:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.54.72 with SMTP id h50mr3345482wec.28.1243371537216; Tue, 26 May 2009 13:58:57 -0700 (PDT) In-Reply-To: <20090526.213904.79416403.mbj@tail-f.com> References: <20090526.213904.79416403.mbj@tail-f.com> Date: Tue, 26 May 2009 16:58:57 -0400 Message-ID: From: "A. Gregory Rabil" To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001485f1d912ccb67f046ad6feef Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 20:57:25 -0000 --001485f1d912ccb67f046ad6feef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Martin, Thank you for your response. The "WhyYang" page really clears some things up for me. I would consider converting my draft to one that uses YANG, if you believe that there would be interest from the NETCONF/NETMOD community for me to do so. Regards, Greg On Tue, May 26, 2009 at 3:39 PM, Martin Bjorklund wrote: > Hi Greg, > > "A. Gregory Rabil" wrote: > > In general, I have to admit that I'm having > > trouble understanding the need for *another* language for specifying the > > contents of XML. > > YANG is not a generic XML Schema language. It is not used to specify > the syntax of generic XML instance documents. > > YANG is used to describe configuration data models that can co-exist > with other data models, evolve over time, be extended by other data > models, and that can be manipulated with the NETCONF protocol. > > YANG is also used to decribe state data, rpcs and notifications, all > handled by NETCONF. > > Some info is available at > http://www.yang-central.org/twiki/bin/view/Main/WhyYang and from other > links at yang-central. > > > XML Schema was supposed to be the defacto standard, now > > RelaxNG is competing for that, and further we have YANG. I would like to > > receive any comments or feedback from the folks in this working group as > to > > what mechanisms may exist for converting *from* XML Schema *to* YANG > > This is not possible in the general case, since YANG cannot model > e.g. XML attributes. > > > or > > suggestions for defining the schema just once without the need to > maintain > > several "authoritative" sources of the schema definition. > > If you have a YANG model, you can generate XSD and RNG from that > model. This is implemented in tools like pyang and yangdump. > > > /martin > --001485f1d912ccb67f046ad6feef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Martin,

Thank you for your response.=A0 The "WhyYang" p= age really clears some things up for me.=A0 I would consider converting my = draft to one that uses YANG, if you believe that there would be interest fr= om the NETCONF/NETMOD community for me to do so.

Regards,
Greg

On Tue, May 26, 2009= at 3:39 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi Greg,

"A. Gregory Rabil" <greg.rabil@jagornet.com> wrote:
> In general, I have to admit that I'm having
> trouble understanding the need for *another* language for specifying t= he
> contents of XML.

YANG is not a generic XML Schema language. =A0It is not used to speci= fy
the syntax of generic XML instance documents.

YANG is used to describe configuration data models that can co-exist
with other data models, evolve over time, be extended by other data
models, and that can be manipulated with the NETCONF protocol.

YANG is also used to decribe state data, rpcs and notifications, all
handled by NETCONF.

Some info is available at
http://www.yang-central.org/twiki/bin/view/Main/WhyYang and= from other
links at yang-central.

> XML Schema was supposed to be the defacto standard, now
> RelaxNG is competing for that, and further we have YANG. =A0I would li= ke to
> receive any comments or feedback from the folks in this working group = as to
> what mechanisms may exist for converting *from* XML Schema *to* YANG
This is not possible in the general case, since YANG cannot model
e.g. XML attributes.

> or
> suggestions for defining the schema just once without the need to main= tain
> several "authoritative" sources of the schema definition.
If you have a YANG model, you can generate XSD and RNG from that
model. =A0This is implemented in tools like pyang and yangdump.


/martin

--001485f1d912ccb67f046ad6feef-- From mbj@tail-f.com Wed May 27 12:14:05 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C743A69D1; Wed, 27 May 2009 12:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOQ+6NpC7IF1; Wed, 27 May 2009 12:14:05 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EDE5B3A696E; Wed, 27 May 2009 12:14:04 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EBEE6616013; Wed, 27 May 2009 21:14:39 +0200 (CEST) Date: Wed, 27 May 2009 21:14:39 +0200 (CEST) Message-Id: <20090527.211439.108634833.mbj@tail-f.com> To: greg.rabil@jagornet.com From: Martin Bjorklund In-Reply-To: References: <20090526.213904.79416403.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 19:14:05 -0000 Hi, "A. Gregory Rabil" wrote: > Hi Martin, > > Thank you for your response. The "WhyYang" page really clears some things > up for me. I would consider converting my draft to one that uses YANG, if > you believe that there would be interest from the NETCONF/NETMOD community > for me to do so. Yes I believe this would be very interesting so I would encourage you to try write your data model in YANG. We would be very interested in your feedback! /martin From simon.leinen@switch.ch Fri May 29 08:32:43 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA193A6A5D; Fri, 29 May 2009 08:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzCyOxqqM5DC; Fri, 29 May 2009 08:32:42 -0700 (PDT) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by core3.amsl.com (Postfix) with ESMTP id E78083A6906; Fri, 29 May 2009 08:32:40 -0700 (PDT) Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id n4TFYIcv000962; Fri, 29 May 2009 17:34:18 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.3+Sun/8.14.3/Submit) id n4TFYIwf000961; Fri, 29 May 2009 17:34:18 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: "A. Gregory Rabil" In-Reply-To: (A. Gregory Rabil's message of "Tue, 26 May 2009 16:58:57 -0400") References: <20090526.213904.79416403.mbj@tail-f.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (usg-unix-v) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Fri, 29 May 2009 17:34:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-rabil-dhc-dhcpv6-xmlconfig-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 15:32:43 -0000 > I would consider converting my draft to one that uses YANG, if you > believe that there would be interest from the NETCONF/NETMOD community > for me to do so. I would also be interested in this, for two reasons: As an operator who is likely to configure DHCPv6 servers in the future (we configure DHCPv4 servers, but currently use SAAC without DHCP for IPv6), and on the other hand because I'd like to hear about your experiences as a "domain expert" with YANG, e.g., learning curve & how happy you'll be with the resulting YANG formulation of your configuration model. -- Simon.