From bertietf@bwijnen.net Wed Apr 1 03:35: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 2C0113A67A7 for ; Wed, 1 Apr 2009 03:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.444 X-Spam-Level: X-Spam-Status: No, score=0.444 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, J_CHICKENPOX_66=0.6, J_CHICKENPOX_74=0.6, STOX_REPLY_TYPE=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 FVA3u1LTsFnB for ; Wed, 1 Apr 2009 03:35:15 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 4702E3A68A1 for ; Wed, 1 Apr 2009 03:35:13 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Loxnn-0005YH-SN for netconf@ietf.org; Wed, 01 Apr 2009 12:36:12 +0200 Message-ID: <5680A43739F845199F2F31D148A34E14@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 1 Apr 2009 12:35:55 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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: [Netconf] draft minutes NETCONF session at IETF74 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, 01 Apr 2009 10:35:17 -0000 First, thanks to Lada and Phil for taking notes. Below are the draft minutes that I compiled from the two sets of notes. Pls let us know asap if you see any errors or omissions. Bert and Mehmet -------------- draft minutes IETF NETCONF session at IETF74 Minutes of the Network Configuration (NETCONF) WG Session at the IETF #74, San Francisco, CA, USA TUESDAY, March 24, 2009, 1300-1500 WG Chairs: Bert Wijnen Mehmet Ersue AD: Dan Romascanu Many Thanks to the minute takers: Phil Shafer and Ladislav Lhotk jabber scribe: Dvid Partain There were approx. 30 persons in the NETCONF session. Agenda and status: WG status review has been given by Mehmet Ersue. See slides: http://www3.ietf.org/proceedings/09mar/slides/netconf-0.ppt -------------------------------------------------------------------------------------------------------- Chartered work-items 1. Partial lock RPC for NETCONF - Balazs Lengyel http://www3.ietf.org/proceedings/09mar/slides/netconf-1.ppt Status: draft-07 available Recent comments in ML: - lock-id unique for whole server, not just a session - primary use case for writable-running Bert Wijnen: Is lock-id indeed unique on the server? BL: Yes. BW: so we need to make it more clear in the document; these are editorial comments. We consider these as "last call" comments. Dan Romascanu: I'd like to see the edit to understand what the changes exactly mean. DR: Don't need a new version BL: So I can just send a few lines in email? DR: yup: BW: this document is ready for last call DR: from jabber: Washam Fan: It will help to monitor both netconf and non-netconf locks. BL: We can find a way how to distinguish these two. BW: washam should post this to the mailing list David Harrington: Source of the lock should be identified. BL: Now the monitoring draft doesn't cover foreign influences. MB: RFC4741 says for global locks that session-id=0 is returned if the lock is held by a foreign session, we could extend it to partial lock. DR: Basic question - are we monitoring other stuff? BW: Monitoring unknown functions makes little sense, but editors should send proposal. DH greed. Phil Shafer: Session-id 0 doesn't say where it comes from, but the device should know where the lock came from. BL: It's not good to encode the source in lock-id. 2. NETCONF Monitoring Schema - Martin Björklund presenting for Mark Scott http://www.ietf.org/proceedings/09mar/slides/netconf-2.pdf Some items raised require resolution in other drafts: - global lock - dynamic capabilities (can server change capability on the fly?). Lot of text in the draft is written as if it should be supported. BW: We have to agree what to do, I'd urge 4741bis to handle this ASAP. MB: we need to solve that before publishing the monitoring draft BL: the draft can be neutral PS: no, since this makes capabilities session specific PS: The server should be able to change capabilities dynamically (e.g., server upgrades its SW). Andy Bierman: The only problem is breaking the contract stated in hello; in some cases the session should be torn down. PS: Big thing that changes capabilities is SW upgrade, which hopefully needn't require reboot. AB: the issue deals with honoring the contract, so the session has to be torn down BW: do we have to describe these cases PS: triangle of terror when tearing down connection that is installing software AB: with three or four namespaces, I don't know what to do with it MB: on the (interrupted) AB: the manager reads a capability that no longer works AW: we can allow for extensibility without making the current situation worse than current situation MB: counter definitions AB: punting to fact finding trip not acceptable; make per-session and global counters the same. The current counters are useless if you have more than one user BW: we can add a thousand counters, but few will be used. New counters need justification or use case. Focus teams doesn't mean design team. ME: who will be on the team? MB: no idea BW: editors should post message to mailing list asking for suggestions Give them a chance for the next two weeks and then close the issue. Items for discussion: - One schema defines one NS, true for current schema languages, but should we be more flexible? AB: I don't know any use case from manager POV, I'd just put in a single NS. - Counter definitions: are the current counters sufficient? AB: I don't see a need for a global counter for outgoing notifications. BW: I'd like to limit the number of things we monitor, we shouldn't define new counters arbitrarily - use cases needed. MB: People interested in this should send proposals to ML. BW: But do it now, not during WGLC! - Extensibility: should enums in XSD model be raplaced with QNames? (a la identities in YANG) BW: It makes sense to me. MB: I will send a proposal covering this. Next steps: -05 in April DP: comments from jabber: washam: re: monitoring of non-netconf locks is missing from the draft; BL: we could use ranges or old/even DR: post to mailing list DH: it should identify the source of the lock BL: does monitoring cover non-netconf sessions? DH: does it cover non-netconf locks? If so, it should give details BL: use case is that something is locked, then look in the monitoring data MB: 4741 gives session-id 0 for non-netconf sessions; no indication of source BW: session-id 0 is a sufficient answer for the first draft MB: that matches 4741 use of session-id 0 DR: (lost) BW: don't know enough about other types of lock to know if "session-id" is meaningful; netconf locks are all we need. DH: agree PS: please give a clue about who (cli, web, etc) holds the lock; use a yang identity. DH: washam has written a mib to do this 3: With-defaults capability for NETCONF - Balazs Lengyel http://www3.ietf.org/proceedings/09mar/slides/netconf-3.ppt Basic behaviours for handle defaults (report all, trim, explicit, ...) - with-defaults == true: send all values (i.e., report all behaviour) - with-defaults == false: remove all values equal to default (trim) - with-defaults absent: use basic behaviour Interaction with filtering: Every operation shoud be applied on the full tree with substituted defaults and then the default values removed from the reply. MB: You don't want to force implementations to remove explicit values. BW: Where are we with this draft? PS: Four different behaviours encoded in a two-value boolean. BL: This is not correct. The four behaviours are stated in a parameter of the w-d capability. AB: If you don?'t use w-d, this is itself is a value, but an issue arises when w-d is false. PS: In the capability the agent states which behaviours it supports, so client then could directly select the one it wants. BL: We will think about this. BW: I hope you can do new revision in mid April. 4. RFC 4741bis - Martin Björklund http://www3.ietf.org/proceedings/09mar/slides/netconf-4.pdf Changes in -00: bugfixes - In validate - what is inline conf subtree - edit-config? Alt. 1. validate only full conf, 2. remove inline validation Proposal: add test-only parameter PS: Is the 4741bis intended to change what's available or just clarify? I don't want enhancements. MB: Here the clarification calls for an enhancement. AB: The intention was to do full only, test-only came in later. BL: I support test-only. BW: check the room (10 hands for ALT1; opposed 0; ALT2: 0) PS: Does test-only go to 4741bis or will be a new draft/capability? PS: concern w/ changing 4741; concern this is the first of 12-15 new capabilities BW: We have to check this. AB: You can define new capability validate 1.1 without changing 4741. BW: Go discuss this in ML - Role of XSD: must capabilities use schema extension mechanisms? BW: Let's postpone this question to the XSD discussion. - Is :startup allowed together with :candidate? MB: slide: capabiity combinations Mehmet Ersue: Is there any reason for not allowing it? AB: No, not teh intent - :startup && :confirmed-commit - probably yes, but should be clarified - MB: slide: rpc attributes should all be returned, including xmlns? Proposal: specify all except xmlns AB: why this CLR? PS: xmlns may override ones you use MB: No, you can use yours at the next level of XML hierarchy. AB: echo all; is there confusion over "all"? PS: can't echo when there's a conflict DR: JS: clash between client and device namespaces on attributes DR: JS: conflict when at the same level -------------------------------------------------- **** Non-chartered items 1. Generic solution for msg integrity slide 7 in: http://www3.ietf.org/proceedings/09mar/slides/netconf-0.ppt BW: slide: Generic solution for the message integrityy issue - Should NETCONF over TLS use now the same delimiter as in SSH? Theoretical problems, safe in practice. Lada Lhotka: there may be hidden security issues via injection. BW: This should be avoided by access control. Wes Hardaker: it's a known problem when there is no framing, if everyone fully validates, this is less of an issue. If the manager sends multiple operations, then this is an even bigger issue. multiple RPC requests shouldn't be processed sequentially AB: we have very simple proc. model, no correlation among rpcs - rely on access control DH: In my view, nothing has to be done, except admitting it in security considerations section. (... discussion about escaping and stuffing ...) WH: There is no spec that something must be escaped if it appears in the message. AB: (lost) WH: you check these at the device, don't expect the manager to do it AB: RPCs are serialized, expecting client to handle it ; do we need a batching mechanism? BW: does that mean you want us to work on framing? AB: no; rely on access control WH: you can do anything you want, as long as you document it BW: EOM can appear anywhere; access control will protect you WH: (examples) ISPs allow clients to access counters on their interfaces; are they manually processed? web form may have more access than needed. DH: JS: nothing is needed but updating the security concerns from TLS into the SSH rfc when it is updated. ME: so it's not an issue PS: can we at least escape it? BW: no not needed DH: so we just need to tell crackers to read the note in the security section WH: escaping prevents us doing something wrong BW: someone (looking at PS) needs to write a individual draft AB: Changes cannot be done w/o changing version number. PS: No version change is needed. 2. Robust conf mngmt - Bob Cole http://www3.ietf.org/proceedings/09mar/slides/netconf-5.pdf Verification = checking against set of rules Validation = measuring behaviour against expectations Proposal: enhance v&v capabilities in NETCONF, move part of tests to the agent. Tests can be specified in data modelling language. BW: Do we see value in this type of work? AB: Better justification is needed. Jürgen Schönwälder: Confusing terminology, we have NETCONF server&client, and validation has a very specific meaning in XML. BC: My background is modelling&simulation and verification and validation mean different things there. BC: Is there any interest in this? BW: how many read? ( 6 hands) who is interested? (4 hands) Will Ivancic: NASA sees this as useful BW: are you deploying netconf? WI: no, but might with a transport oriented DR: JS: confusing terminology BW: suggest you do another draft and readdress next time. 3. Use of XSD and/or YANG - Andy Bierman http://www3.ietf.org/proceedings/09mar/slides/netconf-6.pdf How do we extend the basic NETCONF schema with new capabilities? XSD is not correct and cannot cope well with the extensions. OTOH, YANG can't model XML attributes. BW: I thought the idea was to write the schema in YANG and use some extensions for the attributes. AB: can't augment for with-defaults since there's no netconf.yang; will be other issues in the future, so should we make one? issues: attributes, XSD .vs. YANG, and 4741 text appearing (cut-n-paste) in netconf.yang LL: The XSD in RFC4741 has to be fixed in any case. In draft-lhotka-netconf-relaxng-00 I demonstrated how the schema extensions could be handled in RELAX NG. If something similar isn't possible in XSD, it should be abandoned. ME: use extensions to make this happen LH: talked to xml guru who liked it and liked that we don't have attributes AB: LH draft is better MB: like it but we stick to operation layer, since yang doesn't do BL: data organization AB: central management Session closed when we ran out of time. So during the NETCONF session, there was a sense in the room for enabling YANG to define XML attributes (only the two we need) based on YANG extensions and using YANG for the definition of NETCONF base module. Additional discussion in the NETMOD session the day after lead to a consensus in this direction. Andy Bierman will bring the consensus in the NETMOD session to the NETCONF maillist for confirmation. From Washam.Fan@huaweisymantec.com Thu Apr 2 18:55: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 4AD1628C262 for ; Thu, 2 Apr 2009 18:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 MMPpNkR0XfEZ for ; Thu, 2 Apr 2009 18:55:42 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 30B0428C159 for ; Thu, 2 Apr 2009 18:55:42 -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 <0KHE00FU7ZFD0V10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 01 Apr 2009 16:54: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 <0KHE008LXZFBBQ00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 01 Apr 2009 16:54:49 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 01 Apr 2009 16:54:47 +0800 From: WashamFan To: Balazs Lengyel Message-id: Date: Wed, 01 Apr 2009 16:54:47 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49D0DF65.6080308@ericsson.com> References: <49D0DF65.6080308@ericsson.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Non-Netconf lock 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: Fri, 03 Apr 2009 01:55:43 -0000 > Hello Washam, > I agree, that the netconf monitoring draft should include both > non-netconf locks, and > non-netconf sessions. IMO, sessionId is used to locate a lock accurately, when we want to unlock by force, it is useful to relevant session. But maybe, sessionId is not suitable for every case, as you mentioned in thread "sessionId issue", for UDP, another approach may be better. > If you write such a MIB, it should have the same structure and > content as the relevant part of > the netconf-monitoring YAM. There is an effort to monitor all locks via different NM interfaces in a consistent and extensive way. Please refer to http://www.ietf.org/internet-drafts/draft-meng-fan-lock-mib-01.txt Since Netconf WG would not do mibs, I will announce it to opsawg WG expecting further development there. > Balazs > > WashamFan wrote: > > Hi, > > > > When multiple NM protocols are supported by a device, all locks > acquired via all supported protocols should be monitored in a > consistent way. > > > > We should identify each lock whatever protocol is used to control > the lock. If I understand correctly, lockId is used to differentiate > all locks including both Netconf and non-Netconf ones. That is good, > but maybe not enough. > > > > We still should provide some information which is expected to be > used for releasing a lock by force. sessionId is used to release a > Netconf lock via , but IIRC, > > sessionId=0 for all non-Netconf sessions. Please refer to another > thread discussing > > sessionId issue. > > > > I co-author a mib draft to model multiplex protocols supported > locks monitoring,, I think it > > is of value to this issue. And I want to ask if Netconf WG is a > suitable place to accommodate the draft. > > > > washam washam From root@core3.amsl.com Mon Apr 6 03:15:01 2009 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D95B93A6AB6; Mon, 6 Apr 2009 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090406101501.D95B93A6AB6@core3.amsl.com> Date: Mon, 6 Apr 2009 03:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-01.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: Mon, 06 Apr 2009 10:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-01.txt Pages : 14 Date : 2009-04-06 The NETCONF protocol defines ways to read configuration data from a NETCONF agent. Part of this data is not set by the NETCONF manager, but rather a default value is used. In many situations the NETCONF manager has a priori knowledge about default data, so the NETCONF agent does not need to send it to the manager. In other situations the NETCONF manger will need this data as part of the NETCONF messages. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF manager to control whether default values are part of NETCONF messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-with-defaults-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-06030935.I-D@ietf.org> --NextPart-- From mbj@tail-f.com Mon Apr 6 13:27: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 64A0C3A6D4A for ; Mon, 6 Apr 2009 13:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_50=0.001, 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 DYZETe8PjZO9 for ; Mon, 6 Apr 2009 13:27:30 -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 8F0B33A6D41 for ; Mon, 6 Apr 2009 13:27:30 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id F1652616028 for ; Mon, 6 Apr 2009 22:28:34 +0200 (CEST) Date: Mon, 06 Apr 2009 22:28:33 +0200 (CEST) Message-Id: <20090406.222833.252436646.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [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, 06 Apr 2009 20:27:31 -0000 Hi, This is an issue that needs to be clarified in 4741bis, and it needs to be resolved before the monitoring draft can be completed (as noted at IETF74). The question is if a server is allowed to dynamically change its capability list, as advertised in the message, during the lifetime of a session. One solution is to say that a server MUST NOT change its capability list in ongoing sessions. This makes it very clear and easy for the client. The question is what to do with existing sessions if the supported capabilities change. They could be killed by the server, or enter a state where commands related to changed capabilities would fail. An alternative is to say that servers are allowed to change its capabilities on the fly. But then the question is how a client can tell that this happened? Some people have suggested that a notification can be used, but unless the :interleave capability is supported, this would require each client to have a separate session to monitor this. Personally, I prefer the first alternative b/c it is simpler. I think it will be difficult to make the second alternative work. Comments? Other solutions? /martin From andy@netconfcentral.com Mon Apr 6 13:41: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 F34B828C0DD for ; Mon, 6 Apr 2009 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 gyLjgWBdpj+R for ; Mon, 6 Apr 2009 13:41:06 -0700 (PDT) Received: from n25.bullet.mail.mud.yahoo.com (n25.bullet.mail.mud.yahoo.com [68.142.206.220]) by core3.amsl.com (Postfix) with SMTP id E25CF28C155 for ; Mon, 6 Apr 2009 13:41:05 -0700 (PDT) Received: from [68.142.194.244] by n25.bullet.mail.mud.yahoo.com with NNFMP; 06 Apr 2009 20:42:08 -0000 Received: from [68.142.201.247] by t2.bullet.mud.yahoo.com with NNFMP; 06 Apr 2009 20:42:08 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 06 Apr 2009 20:42:08 -0000 X-Yahoo-Newman-Id: 719811.73190.bm@omp408.mail.mud.yahoo.com Received: (qmail 27486 invoked from network); 6 Apr 2009 20:42:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 6 Apr 2009 20:42:07 -0000 X-YMail-OSG: vm07Pu4VM1kksZuW8kjUCWQRAiTqsehL.8IURxIhFQTImyqxJlz2kjoXlkDhRsJ34elq_tDpYBULMJ6KAyJz60.r1kyjbD.qiD0Bcub0fsyj40RMxtt.sJQPlT9aZ_gvHkgWzwHd8j0QbjvaH74vg0ixD6zhrumZAe7.4..6orobXwDauQD8bliFNi.PGxDDf5O6Fy9lxiYhm92mEzPFwopYor5VUKlWqXwL5YUmSV0g5BUtUsBsUHudECJ2zjCQ1PRcuxCnKNjlpybX X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DA691D.2020301@netconfcentral.com> Date: Mon, 06 Apr 2009 13:42:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090406.222833.252436646.mbj@tail-f.com> In-Reply-To: <20090406.222833.252436646.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: Mon, 06 Apr 2009 20:41:13 -0000 Martin Bjorklund wrote: > Hi, > > This is an issue that needs to be clarified in 4741bis, and it needs > to be resolved before the monitoring draft can be completed (as noted > at IETF74). > > The question is if a server is allowed to dynamically change its > capability list, as advertised in the message, during the > lifetime of a session. > > One solution is to say that a server MUST NOT change its capability > list in ongoing sessions. This makes it very clear and easy for the > client. The question is what to do with existing sessions if the > supported capabilities change. They could be killed by the server, or > enter a state where commands related to changed capabilities would > fail. > > An alternative is to say that servers are allowed to change its > capabilities on the fly. But then the question is how a client can > tell that this happened? Some people have suggested that a > notification can be used, but unless the :interleave capability is > supported, this would require each client to have a separate session > to monitor this. > > Personally, I prefer the first alternative b/c it is simpler. I think > it will be difficult to make the second alternative work. > > Comments? Other solutions? > I agree with you on solution 1. Notifications may not be implemented or enabled. Another option would be to put the affected session(s) in a state where every RPC request fails with a 'capabilities-changed' error-app-tag on an 'operation-failed' error. This at least lets the manager issue the close-session knowing what happened. Blowing up the session will lead to debugging headaches for operators. > > /martin Andy From mbj@tail-f.com Mon Apr 6 14:46: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 8F74B3A697C for ; Mon, 6 Apr 2009 14:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.101, 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 R0ZUi1ayShSX for ; Mon, 6 Apr 2009 14:46:04 -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 BD9A43A6CB0 for ; Mon, 6 Apr 2009 14:46: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 96175616022; Mon, 6 Apr 2009 23:47:05 +0200 (CEST) Date: Mon, 06 Apr 2009 23:47:05 +0200 (CEST) Message-Id: <20090406.234705.124772199.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49DA691D.2020301@netconfcentral.com> References: <20090406.222833.252436646.mbj@tail-f.com> <49DA691D.2020301@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] 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, 06 Apr 2009 21:46:05 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > This is an issue that needs to be clarified in 4741bis, and it needs > > to be resolved before the monitoring draft can be completed (as noted > > at IETF74). > > The question is if a server is allowed to dynamically change its > > capability list, as advertised in the message, during the > > lifetime of a session. > > One solution is to say that a server MUST NOT change its capability > > list in ongoing sessions. This makes it very clear and easy for the > > client. The question is what to do with existing sessions if the > > supported capabilities change. They could be killed by the server, or > > enter a state where commands related to changed capabilities would > > fail. > > An alternative is to say that servers are allowed to change its > > capabilities on the fly. But then the question is how a client can > > tell that this happened? Some people have suggested that a > > notification can be used, but unless the :interleave capability is > > supported, this would require each client to have a separate session > > to monitor this. > > Personally, I prefer the first alternative b/c it is simpler. I think > > it will be difficult to make the second alternative work. > > Comments? Other solutions? > > > > I agree with you on solution 1. > Notifications may not be implemented or enabled. > Another option would be to put the affected session(s) > in a state where every RPC request fails with > a 'capabilities-changed' error-app-tag on an 'operation-failed' > error. Yes, that's what I had in mind when I wrote "enter a state". Except for 'close-session' :) The easiest is probably to do this for all active sessions when the new capabilities are installed. A more complex scheme could be to send this error only when an operation related to a modified capability is given by the client. But I don't think it is worth the complexity. /martin From mbj@tail-f.com Tue Apr 7 01:24: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 81BE73A68F2 for ; Tue, 7 Apr 2009 01:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.068, 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 6zvqXy9z0gZI for ; Tue, 7 Apr 2009 01:24: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 B2E7A3A67EC for ; Tue, 7 Apr 2009 01:24:08 -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 99AFC616006; Tue, 7 Apr 2009 10:25:13 +0200 (CEST) Date: Tue, 07 Apr 2009 10:25:13 +0200 (CEST) Message-Id: <20090407.102513.249570021.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <49DA691D.2020301@netconfcentral.com> <20090406.234705.124772199.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] 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, 07 Apr 2009 08:24:09 -0000 WashamFan wrote: > Hi, > > Capabilities DO shift during a ongoing session, right? It is clear that the capabilities of a device change over time, e.g. when a new software image is installed. The question is how this affects NETCONF sessions. > So we should react to that whatever in a > complex or simple way insteading of just ignoring it. Absolutely; this needs to be clarified in 4741bis. > Do capabilities change affect all active sessions or > a subset ones? IMO, capabilities addition does not > affect all active sessions much, but capabilities removal > do affect relevant sessions to cause relevant operations > to fail. This very much depends on the capability itself. For example, suppose :partial-lock is added dynamically. In this case it would be safe to just continue all existing sessions. But if a capability that defines a data model is added, existing session might not be able to handle this correctly. IMO, the simple solution that Andy suggested is good enough. This is not something that we expect happen "often", and when it happens, the manager just has to close and reopen the NETCONF session (which might be as simple as close the channel and open a new one). /martin From mbj@tail-f.com Tue Apr 7 01:51:45 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 99F3B3A6823 for ; Tue, 7 Apr 2009 01:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.065, 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 aQIcxhP4+BZ2 for ; Tue, 7 Apr 2009 01:51: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 3BDB43A6816 for ; Tue, 7 Apr 2009 01:51:40 -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 51DED616006; Tue, 7 Apr 2009 10:52:46 +0200 (CEST) Date: Tue, 07 Apr 2009 10:52:45 +0200 (CEST) Message-Id: <20090407.105245.64842827.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090407.102513.249570021.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] 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, 07 Apr 2009 08:51:45 -0000 WashamFan wrote: > > > Do capabilities change affect all active sessions or > > > a subset ones? IMO, capabilities addition does not > > > affect all active sessions much, but capabilities removal > > > do affect relevant sessions to cause relevant operations > > > to fail. > > > > This very much depends on the capability itself. For example, suppose > > :partial-lock is added dynamically. In this case it would be safe to > > just continue all existing sessions. But if a capability that defines > > a data model is added, existing session might not be able to handle > > this correctly. > > The added data model is not included in the "contract" agreed by manager > and agent when exchange, how does it affect the existing session? If they do a or they might get data from the new model. Or if there are references between data models they might get errors pointing out data from a data model that hasn't been advertised. Even more difficult to handle is if an existing data model has been upgraded, i.e. the new capability is a new version of an existing one. /martin From phil@juniper.net Tue Apr 7 05:18: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 6FB4D3A6DC0 for ; Tue, 7 Apr 2009 05:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8vs8KDsFKOT for ; Tue, 7 Apr 2009 05:18:43 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 8390D3A6DCE for ; Tue, 7 Apr 2009 05:18:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSdtE3lvISbPbqMDW594hj+5Nb0+qvbXI@postini.com; Tue, 07 Apr 2009 05:19:50 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; Tue, 7 Apr 2009 05:17:09 -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); Tue, 7 Apr 2009 05:17:09 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 05:17:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 05:17:08 -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 n37CH7M02197; Tue, 7 Apr 2009 05:17:07 -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 n37C9poA067443; Tue, 7 Apr 2009 12:09:51 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904071209.n37C9poA067443@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090406.234705.124772199.mbj@tail-f.com> Date: Tue, 7 Apr 2009 08:09:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2009 12:17:08.0123 (UTC) FILETIME=[C5533EB0:01C9B77A] MIME-Version: 1.0 Content-Type: text/plain 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, 07 Apr 2009 12:18:48 -0000 Martin Bjorklund writes: >Yes, that's what I had in mind when I wrote "enter a state". Except >for 'close-session' :) The easiest is probably to do this for all >active sessions when the new capabilities are installed. A more >complex scheme could be to send this error only when an operation >related to a modified capability is given by the client. But I don't >think it is worth the complexity. My concern would be that a session would be put into this "inoperable" state when something unimportant (or at least unimportant to that session) changes. If a PIC is inserted that carries new config (and its capability), my session that is simply draining notifications shouldn't be affected. Another scenario to beware of is software installation. If the act of installing sw means capabilities change, then the session I'm using to install the sw becomes inoperable. If I have a multiphase install mechanism (like a confirmation), I won't be able to finish the install because my session is now dead. I think it's simpler and more normal to allow a client to track capability change _if_ they care. Most won't. The complexity isn't worthwhile on the client side either. Thanks, Phil From phil@juniper.net Tue Apr 7 05: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 139893A689C for ; Tue, 7 Apr 2009 05:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUCYYfWIO0Q9 for ; Tue, 7 Apr 2009 05:22:01 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4D82D3A6CFD for ; Tue, 7 Apr 2009 05:22:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSdtFqBOYYorD/SQiXwOpBikwHTCnf6Hj@postini.com; Tue, 07 Apr 2009 05:23:08 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 7 Apr 2009 05:20:18 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 05:20:18 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 05:20:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 05:20:17 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n37CKGM04613; Tue, 7 Apr 2009 05:20:16 -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 n37CD0oD067498; Tue, 7 Apr 2009 12:13:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904071213.n37CD0oD067498@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090407.102513.249570021.mbj@tail-f.com> Date: Tue, 7 Apr 2009 08:13:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2009 12:20:17.0227 (UTC) FILETIME=[360A39B0:01C9B77B] MIME-Version: 1.0 Content-Type: text/plain 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, 07 Apr 2009 12:22:02 -0000 Martin Bjorklund writes: >This very much depends on the capability itself. For example, suppose >:partial-lock is added dynamically. In this case it would be safe to >just continue all existing sessions. But if a capability that defines >a data model is added, existing session might not be able to handle >this correctly. My guess is that the large and important changes (adding :candidate or :partial) won't be happening once the box is deployed, so these are less of an issue. If the issue is the data model, what will happen when "features" change? Will the session also become inoperable? Thanks, Phil From mbj@tail-f.com Tue Apr 7 06:40:26 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 807083A6886 for ; Tue, 7 Apr 2009 06:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.063, 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 lV9g7GiZmW7Y for ; Tue, 7 Apr 2009 06:40:25 -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 8CAED3A6978 for ; Tue, 7 Apr 2009 06:40:25 -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 F3CC4616006; Tue, 7 Apr 2009 15:41:30 +0200 (CEST) Date: Tue, 07 Apr 2009 15:41:30 +0200 (CEST) Message-Id: <20090407.154130.196306247.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200904071209.n37C9poA067443@idle.juniper.net> References: <20090406.234705.124772199.mbj@tail-f.com> <200904071209.n37C9poA067443@idle.juniper.net> 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, 07 Apr 2009 13:40:26 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Yes, that's what I had in mind when I wrote "enter a state". Except > >for 'close-session' :) The easiest is probably to do this for all > >active sessions when the new capabilities are installed. A more > >complex scheme could be to send this error only when an operation > >related to a modified capability is given by the client. But I don't > >think it is worth the complexity. > > My concern would be that a session would be put into this > "inoperable" state when something unimportant (or at least > unimportant to that session) changes. If a PIC is inserted > that carries new config (and its capability), my session > that is simply draining notifications shouldn't be affected. > > Another scenario to beware of is software installation. If > the act of installing sw means capabilities change, then the > session I'm using to install the sw becomes inoperable. If > I have a multiphase install mechanism (like a confirmation), > I won't be able to finish the install because my session is > now dead. It seems we have three variations on the same theme; sessions must behave as if the advertised capabilities do not change. The three variations would be: 1) kill all sessions 2) let all sessions enter a state where they get a 'capabilities-changed' error for any operation but close-session 3) let sessions continue, and "some" operations will continue to work, but some other will fail with an 'capabilities-changed' error. Can we let this be an implementation choice? I.e. the general idea must be supported, but implementations can choose to do this in any of the three ways (or other ways). > I think it's simpler and more normal to allow a client to > track capability change _if_ they care. I'm not sure I understand. Are you suggesting that some kind of change notification should be generated so that clients can track them? /martin From mbj@tail-f.com Tue Apr 7 06:42: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 1962B3A69D8 for ; Tue, 7 Apr 2009 06:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.062, 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 bdJ-SRKnydNx for ; Tue, 7 Apr 2009 06:42: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 58E993A6978 for ; Tue, 7 Apr 2009 06:42:29 -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 651CB616006; Tue, 7 Apr 2009 15:43:35 +0200 (CEST) Date: Tue, 07 Apr 2009 15:43:30 +0200 (CEST) Message-Id: <20090407.154330.09778533.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200904071213.n37CD0oD067498@idle.juniper.net> References: <20090407.102513.249570021.mbj@tail-f.com> <200904071213.n37CD0oD067498@idle.juniper.net> 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, 07 Apr 2009 13:42:30 -0000 Phil Shafer wrote: > If the issue is the data model, what will happen when "features" > change? Will the session also become inoperable? This is a capability change, and it will be treated as the other capability changes. /martin From j.schoenwaelder@jacobs-university.de Tue Apr 7 06:44:36 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 293203A6DD8 for ; Tue, 7 Apr 2009 06:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.168, 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 NBbkBy-fm8zq for ; Tue, 7 Apr 2009 06:44:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2A2593A6978 for ; Tue, 7 Apr 2009 06:44:35 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6ECD2C003B; Tue, 7 Apr 2009 15:45:41 +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 HwkK8dllBL6o; Tue, 7 Apr 2009 15:45:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DD34C000A; Tue, 7 Apr 2009 15:45:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A0EF8A650CC; Tue, 7 Apr 2009 15:45:22 +0200 (CEST) Date: Tue, 7 Apr 2009 15:45:22 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090407134522.GA29777@elstar.local> Mail-Followup-To: Martin Bjorklund , "phil@juniper.net" , "netconf@ietf.org" References: <20090406.234705.124772199.mbj@tail-f.com> <200904071209.n37C9poA067443@idle.juniper.net> <20090407.154130.196306247.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090407.154130.196306247.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] dynamic capabilities 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: Tue, 07 Apr 2009 13:44:36 -0000 On Tue, Apr 07, 2009 at 03:41:30PM +0200, Martin Bjorklund wrote: > It seems we have three variations on the same theme; sessions must > behave as if the advertised capabilities do not change. The three > variations would be: > > 1) kill all sessions > > 2) let all sessions enter a state where they get a > 'capabilities-changed' error for any operation but close-session > > 3) let sessions continue, and "some" operations will continue to > work, but some other will fail with an 'capabilities-changed' > error. A variation of 2) could be to return a 'capabilities-changed' error until the client has resynchronized the capabilites. Unfortunately, the hello message is not a normal RPC, otherwise invoking the hello rpc could simply have cleared the 'capabilities-changed' error without having to close the session... /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 Tue Apr 7 07:04:22 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 8C3033A6DE4 for ; Tue, 7 Apr 2009 07:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.041, 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 K9beJcWk+dyn for ; Tue, 7 Apr 2009 07:04:21 -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 C677E3A6DE2 for ; Tue, 7 Apr 2009 07:04:21 -0700 (PDT) Received: (qmail 64941 invoked from network); 7 Apr 2009 14:05:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 7 Apr 2009 14:05:27 -0000 X-YMail-OSG: cfqeVNEVM1kqIfy.gZJoiCsNDXDBe3aBWJNclRH0GuBAzmchb6khlX5bQDoBD6xwFr4..09VAfnb_3UaRBrrubihBX4Qr5oYb9f8s8KDEvbs6bXhoW74GisatU.WxhimdVcw8Ni8zTkclu5RVszInSyehu8a2G6Rzj28cASKcdns5aEs7IvnfxlBf.DRIW1O8.zwDPqOilwO0tJcek6XXtPavyDhIT4NXUOFtbiMTr9HIkB6ZS2QfwVkhsndjpx4N7gispHTMBpvpoLFpLwoJPPbcbxte9_DUEf3uRy.DjJOYW_QKx01 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DB5DA5.4090607@netconfcentral.com> Date: Tue, 07 Apr 2009 07:05:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090406.234705.124772199.mbj@tail-f.com> <200904071209.n37C9poA067443@idle.juniper.net> <20090407.154130.196306247.mbj@tail-f.com> In-Reply-To: <20090407.154130.196306247.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, 07 Apr 2009 14:04:22 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> Yes, that's what I had in mind when I wrote "enter a state". Except >>> for 'close-session' :) The easiest is probably to do this for all >>> active sessions when the new capabilities are installed. A more >>> complex scheme could be to send this error only when an operation >>> related to a modified capability is given by the client. But I don't >>> think it is worth the complexity. >> My concern would be that a session would be put into this >> "inoperable" state when something unimportant (or at least >> unimportant to that session) changes. If a PIC is inserted >> that carries new config (and its capability), my session >> that is simply draining notifications shouldn't be affected. >> >> Another scenario to beware of is software installation. If >> the act of installing sw means capabilities change, then the >> session I'm using to install the sw becomes inoperable. If >> I have a multiphase install mechanism (like a confirmation), >> I won't be able to finish the install because my session is >> now dead. > > It seems we have three variations on the same theme; sessions must > behave as if the advertised capabilities do not change. The three > variations would be: > > 1) kill all sessions > > 2) let all sessions enter a state where they get a > 'capabilities-changed' error for any operation but close-session > > 3) let sessions continue, and "some" operations will continue to > work, but some other will fail with an 'capabilities-changed' > error. > > Can we let this be an implementation choice? I.e. the general idea > must be supported, but implementations can choose to do this in any > of the three ways (or other ways). > >> I think it's simpler and more normal to allow a client to >> track capability change _if_ they care. > > I'm not sure I understand. Are you suggesting that some kind of > change notification should be generated so that clients can track > them? > I prefer (2). It is simple and the cost for the manager to restart a session is very low. There is no way for the agent to know what changed just because a capability URI is added/deleted/changed. Capability semantics are located in the description-stmt. The agent will not likely know which exact operations or data have changed for each open session. Another option is to do nothing and let the open sessions flail and fail, or work fine, depending on the exact changes. No special error would be returned -- just the normal errors that would occur if the manager and agent are not using the same schema. This is implementable. Switching to a special capabilities-changed error for certain operations may not be implementable by the agent. In this case, the manager will not be given a 'capability-changed' error. Is it important that this error be reliable? > > /martin > > > Andy From phil@juniper.net Tue Apr 7 07:39:28 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 5D6653A6981 for ; Tue, 7 Apr 2009 07:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LA9lyTOdMIlO for ; Tue, 7 Apr 2009 07:39:27 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 1D3AB3A698D for ; Tue, 7 Apr 2009 07:39:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSdtl3VZliJH+6NVVawD0JTCUuIEoTD+n@postini.com; Tue, 07 Apr 2009 07:40:34 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; Tue, 7 Apr 2009 07:37:57 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 07:37:57 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 07:37:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 07:37:56 -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 n37EbuM78193; Tue, 7 Apr 2009 07:37:56 -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 n37EUdLc069046; Tue, 7 Apr 2009 14:30:40 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904071430.n37EUdLc069046@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090407.154130.196306247.mbj@tail-f.com> Date: Tue, 7 Apr 2009 10:30:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2009 14:37:56.0805 (UTC) FILETIME=[7121CF50:01C9B78E] MIME-Version: 1.0 Content-Type: text/plain 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, 07 Apr 2009 14:39:28 -0000 Martin Bjorklund writes: >Can we let this be an implementation choice? I.e. the general idea >must be supported, but implementations can choose to do this in any >of the three ways (or other ways). Define the error and say that servers MAY return the error, leaving it up to the implementation to decide if it needs/wants to. >> I think it's simpler and more normal to allow a client to >> track capability change _if_ they care. >I'm not sure I understand. Are you suggesting that some kind of >change notification should be generated so that clients can track >them? My client may be brainless and uncaring about capability changes. Making it care adds complexity on the client side. For example, I have a script that does six RPCs that fetch data from the box, and I can currently build a file with the hello and those six RPCs and run "ssh -s router netconf < file" and things will work. Thanks, Phil From andy@netconfcentral.com Tue Apr 7 07:53: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 3CEF728C17D for ; Tue, 7 Apr 2009 07:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.041, 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 UfKUb2gsU3+p for ; Tue, 7 Apr 2009 07:53:08 -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 8C1FE28C16D for ; Tue, 7 Apr 2009 07:53:08 -0700 (PDT) Received: (qmail 79956 invoked from network); 7 Apr 2009 14:54:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.123 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 7 Apr 2009 14:54:14 -0000 X-YMail-OSG: IhXmPP0VM1l4.H63lt55TBkkFs7KwGztT3SDByRTw9e_QVyp0yeuSKwougIspt4_zksMVvr08mA2SqErJar1dVhjBB8NbWGIRJRhH5dIKQq4YcCF5Cf5hjrWC4emiecuZYhCMq21Z14IoqdhmTEFMipyLO4sWIJ1WcM3P2sDYSfHSItXlXhmyoszcsGnCAtxztfM69VyxgipP_57Q6APBRQy3w6a15CO1vSteIeYt4aprQ7heztlW7TaZdKDFA9.RFoRu1mef_T_lA.6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DB6913.9030301@netconfcentral.com> Date: Tue, 07 Apr 2009 07:54:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904071430.n37EUdLc069046@idle.juniper.net> In-Reply-To: <200904071430.n37EUdLc069046@idle.juniper.net> 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, 07 Apr 2009 14:53:09 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >> Can we let this be an implementation choice? I.e. the general idea >> must be supported, but implementations can choose to do this in any >> of the three ways (or other ways). > > Define the error and say that servers MAY return the error, leaving > it up to the implementation to decide if it needs/wants to. > good idea -- I was going to say, if the agent knows for sure the RPC is OK for a particular session to use, then let it run. Otherwise, return 'capabilities-changed' error-app-tag on operation-failed error. Always allow to run. >>> I think it's simpler and more normal to allow a client to >>> track capability change _if_ they care. >> I'm not sure I understand. Are you suggesting that some kind of >> change notification should be generated so that clients can track >> them? > > My client may be brainless and uncaring about capability changes. > Making it care adds complexity on the client side. For example, I > have a script that does six RPCs that fetch data from the box, and > I can currently build a file with the hello and those six RPCs and > run "ssh -s router netconf < file" and things will work. > this is fragile in any context, not just this one. Ignore the at your own risk ;-) > Thanks, > Phil > > Andy From j.schoenwaelder@jacobs-university.de Tue Apr 7 10:05: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 D589E3A69E2 for ; Tue, 7 Apr 2009 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_05=-1.11, 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 IDt4r8jjXdsi for ; Tue, 7 Apr 2009 10:05:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4E4643A68B6 for ; Tue, 7 Apr 2009 10:05:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FCD3C0019; Tue, 7 Apr 2009 19:06:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CJvWjFSZbOyb; Tue, 7 Apr 2009 19:06:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6035AC000A; Tue, 7 Apr 2009 19:06:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2E5A9A6532C; Tue, 7 Apr 2009 19:05:49 +0200 (CEST) Date: Tue, 7 Apr 2009 19:05:49 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20090407170549.GA29864@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , "netconf@ietf.org" References: <20090407.154130.196306247.mbj@tail-f.com> <200904071430.n37EUdLc069046@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904071430.n37EUdLc069046@idle.juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] dynamic capabilities 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: Tue, 07 Apr 2009 17:05:03 -0000 On Tue, Apr 07, 2009 at 04:30:39PM +0200, Phil Shafer wrote: > My client may be brainless and uncaring about capability changes. > Making it care adds complexity on the client side. For example, I > have a script that does six RPCs that fetch data from the box, and > I can currently build a file with the hello and those six RPCs and > run "ssh -s router netconf < file" and things will work. I heard you talking about robustness before and now you say we should optimizing for scripts that can fail in arbitrary ways because they assume there is never ever going to be a NETCONF processing error... 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. 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... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Tue Apr 7 10: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 704773A6B17 for ; Tue, 7 Apr 2009 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-1.145, 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 SOMruIORG6zL for ; Tue, 7 Apr 2009 10:43:07 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 5436B3A69F3 for ; Tue, 7 Apr 2009 10:43:07 -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 <0KHQ00AM62W3BA00@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 07 Apr 2009 16:43:17 +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 <0KHQ00ER32W1FD00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 07 Apr 2009 16:43:15 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 07 Apr 2009 16:43:13 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Tue, 07 Apr 2009 16:43:13 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090407.102513.249570021.mbj@tail-f.com> References: <49DA691D.2020301@netconfcentral.com> <20090406.234705.124772199.mbj@tail-f.com> <20090407.102513.249570021.mbj@tail-f.com> 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, 07 Apr 2009 17:43:08 -0000 > > Do capabilities change affect all active sessions or > > a subset ones? IMO, capabilities addition does not > > affect all active sessions much, but capabilities removal > > do affect relevant sessions to cause relevant operations > > to fail. > > This very much depends on the capability itself. For example, suppose > :partial-lock is added dynamically. In this case it would be safe to > just continue all existing sessions. But if a capability that defines > a data model is added, existing session might not be able to handle > this correctly. The added data model is not included in the "contract" agreed by manager and agent when exchange, how does it affect the existing session? washam From phil@juniper.net Tue Apr 7 12:22: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 183113A6DAE for ; Tue, 7 Apr 2009 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCiLaa-b63h9 for ; Tue, 7 Apr 2009 12:22:40 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 5FDB13A69D2 for ; Tue, 7 Apr 2009 12:22:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSduoPkK+uxVU58hbrARlSYLF1VbfdeQP@postini.com; Tue, 07 Apr 2009 12:23:47 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 7 Apr 2009 12:22:10 -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); Tue, 7 Apr 2009 12:22:10 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 12:22:10 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 12:22:09 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n37JM8M37498; Tue, 7 Apr 2009 12:22:08 -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 n37JEqqW072558; Tue, 7 Apr 2009 19:14:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904071914.n37JEqqW072558@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20090407170549.GA29864@elstar.local> Date: Tue, 7 Apr 2009 15:14:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2009 19:22:09.0446 (UTC) FILETIME=[254C5460:01C9B7B6] MIME-Version: 1.0 Content-Type: text/plain 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, 07 Apr 2009 19:22:41 -0000 Juergen Schoenwaelder writes: >I heard you talking about robustness before and now you say we should >optimizing for scripts that can fail in arbitrary ways because they >assume there is never ever going to be a NETCONF processing error... Sure, because I see a wide spectrum of potential clients. I want smart clients to be able to do smart things in a robust and breath-takingly amazing way, but I also want stupid shell script clients to be able to work. >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... That should be fine. Thanks, Phil From andy@netconfcentral.com Tue Apr 7 13:25: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 AF6113A6E07 for ; Tue, 7 Apr 2009 13:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.134, 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 Hob7GwoNB-gQ for ; Tue, 7 Apr 2009 13:25:30 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 0041D3A6A8B for ; Tue, 7 Apr 2009 13:25:29 -0700 (PDT) Received: (qmail 26753 invoked from network); 7 Apr 2009 20:26:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.61 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Apr 2009 20:26:35 -0000 X-YMail-OSG: LNtI3jgVM1k5yj2q5T9FQi1lNuEMiHZXq1vh0qwywXZor.uNBvPbtPUCCJuwOi1toAQI2TXIq_IFVBlyZ5MZOlq6TGR_1ho9xpdBWEmU7volR7_sEtXIvXqIl2HzETbHh0UE4ZAKka0eq0n8KpRRcE93sUadqvVyGMS1C5kBdIEHIW5GGrKKGbIu0hTM.Nv2NvtZnS72umkpqU0ofjCWAgdJlur11tk8x._Yf9BVNlsfLft2bIOHDf999lDVAPqybp86zsXLV_01Qg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DBB6F7.4000202@netconfcentral.com> Date: Tue, 07 Apr 2009 13:26:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904071914.n37JEqqW072558@idle.juniper.net> In-Reply-To: <200904071914.n37JEqqW072558@idle.juniper.net> 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, 07 Apr 2009 20:25:30 -0000 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> I heard you talking about robustness before and now you say we should >> optimizing for scripts that can fail in arbitrary ways because they >> assume there is never ever going to be a NETCONF processing error... > > Sure, because I see a wide spectrum of potential clients. I want > smart clients to be able to do smart things in a robust and > breath-takingly amazing way, but I also want stupid shell > script clients to be able to work. > NETCONF was never intended to be used in a way where the could be ignored by the manager. This is not a valid use-case. >> 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... > > That should be fine. > > Thanks, > Phil > _____ Andy From Washam.Fan@huaweisymantec.com Wed Apr 8 10:03: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 3825F3A6E77 for ; Wed, 8 Apr 2009 10:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 n+ow6rNk4rNR for ; Wed, 8 Apr 2009 10:03:55 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 4B1D93A68FE for ; Wed, 8 Apr 2009 10:03:55 -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 <0KHR005YBKMJLO60@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 08 Apr 2009 12:03:57 +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 <0KHR0076LKMH4Z00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 08 Apr 2009 12:03:55 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 08 Apr 2009 12:03:53 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Wed, 08 Apr 2009 12:03:53 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090407.154130.196306247.mbj@tail-f.com> References: <20090406.234705.124772199.mbj@tail-f.com> <200904071209.n37C9poA067443@idle.juniper.net> <20090407.154130.196306247.mbj@tail-f.com> 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, 08 Apr 2009 17:03:56 -0000 > It seems we have three variations on the same theme; sessions must > behave as if the advertised capabilities do not change. The three > variations would be: > > 1) kill all sessions > > 2) let all sessions enter a state where they get a > 'capabilities-changed' error for any operation but close-session > > 3) let sessions continue, and "some" operations will continue to > work, but some other will fail with an 'capabilities-changed' > error. I suggest a variant of 2) 2*) let all sessions enter a state where they get a 'capabilities-changed' warning for any operation but close-session Why block all operations even those didn't get affected? If manager can't understand the rpc-reply due to new data model added, for example, it can reference the warnig info, otherwise ignore the warning. I.e., when there are something error or I do not understand happen, I will refer to the warning info, otherwise I could ignore the warning info. washam From Washam.Fan@huaweisymantec.com Wed Apr 8 12:27: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 A6F7E3A69C2 for ; Wed, 8 Apr 2009 12:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_43=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 8R0VG1+t2QSh for ; Wed, 8 Apr 2009 12:27:53 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 90F283A6900 for ; Wed, 8 Apr 2009 12:27:53 -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 <0KHP00AOULGY4B20@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 07 Apr 2009 10:27:00 +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 <0KHP00C18LGWSG00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 07 Apr 2009 10:26:58 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 07 Apr 2009 10:26:56 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Tue, 07 Apr 2009 10:26:56 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090406.234705.124772199.mbj@tail-f.com> References: <20090406.222833.252436646.mbj@tail-f.com> <49DA691D.2020301@netconfcentral.com> <20090406.234705.124772199.mbj@tail-f.com> 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, 08 Apr 2009 19:27:54 -0000 Hi, Capabilities DO shift during a ongoing session, right? So we should react to that whatever in a complex or simple way insteading of just ignoring it. Do capabilities change affect all active sessions or a subset ones? IMO, capabilities addition does not affect all active sessions much, but capabilities removal do affect relevant sessions to cause relevant operations to fail. So, not all capabilities changes but only capabilities removal affect not all active sessions but only relevant sessions much(Yes, relevant sessions could equal to all sessions). Monitoring should reflect capabilities change. But the current text only monitors the entire set of capabilites supported in a device, maybe capabilites change per session should be specified. Notification should reflect capabilities change. And the content includes the capabilities changes in the session should be specified further. In request/response process, there are some suggestions: (1) just say a session MUST NOT do the change, is expected by server when some changes happen. (2) every rpc in affected session fails with error info indicating the change. ( is expected by client) (3) every rpc in affected session fails with error info indicating the change. ( is expected by client) (4) just affected rpcs in affected sessions fail with error info indicating the change. I prefer (4), close sessions just when it is needed. And is there any indicator to capabilities change in (1)? Comments? washam > Andy Bierman wrote: > > Martin Bjorklund wrote: > > > Hi, > > > This is an issue that needs to be clarified in 4741bis, and it needs > > > to be resolved before the monitoring draft can be completed (as noted > > > at IETF74). > > > The question is if a server is allowed to dynamically change its > > > capability list, as advertised in the message, during the > > > lifetime of a session. > > > One solution is to say that a server MUST NOT change its capability > > > list in ongoing sessions. This makes it very clear and easy for > the > > > client. The question is what to do with existing sessions if the > > > supported capabilities change. They could be killed by the > server, or > > > enter a state where commands related to changed capabilities would > > > fail. > > > An alternative is to say that servers are allowed to change its > > > capabilities on the fly. But then the question is how a client can > > > tell that this happened? Some people have suggested that a > > > notification can be used, but unless the :interleave capability is > > > supported, this would require each client to have a separate session > > > to monitor this. > > > Personally, I prefer the first alternative b/c it is simpler. I > think > > > it will be difficult to make the second alternative work. > > > Comments? Other solutions? > > > > > > > I agree with you on solution 1. > > Notifications may not be implemented or enabled. > > Another option would be to put the affected session(s) > > in a state where every RPC request fails with > > a 'capabilities-changed' error-app-tag on an 'operation-failed' > > error. > > Yes, that's what I had in mind when I wrote "enter a state". Except > for 'close-session' :) The easiest is probably to do this for all > active sessions when the new capabilities are installed. A more > complex scheme could be to send this error only when an operation > related to a modified capability is given by the client. But I don't > think it is worth the complexity. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Fri Apr 10 12:17: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 B9EE53A6924 for ; Fri, 10 Apr 2009 12:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_20=-0.74, J_CHICKENPOX_74=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 6AC3eARuUVdw for ; Fri, 10 Apr 2009 12:17:07 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 5058C3A6A16 for ; Fri, 10 Apr 2009 12:16:19 -0700 (PDT) Received: from [68.142.200.226] by n10.bullet.mail.mud.yahoo.com with NNFMP; 10 Apr 2009 19:17:28 -0000 Received: from [68.142.201.249] by t7.bullet.mud.yahoo.com with NNFMP; 10 Apr 2009 19:17:28 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 10 Apr 2009 19:17:28 -0000 X-Yahoo-Newman-Id: 195713.65761.bm@omp410.mail.mud.yahoo.com Received: (qmail 86272 invoked from network); 10 Apr 2009 19:17:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.61 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 10 Apr 2009 19:17:23 -0000 X-YMail-OSG: U6bbC6IVM1k_FaDhnV3w2PC4bPmviCHB1jznN7RlKH7Di0HSEfBHEmMAg.nSdcndoz_5CYLVDk.8xrQbpb1BxuChlw2qoxXrl8AagBM3jgUV5USJpDVsWapkDtZduA8164P9ZNSYOfevyp7_NsuCVPw8adrixTgYvpphYsqMhOnZouMKcVdRNuxJpe.SxEiR5o6R9Y0dfF36OFGIjeCzSDFrj96aGsgknOf_B4vXssw6JqQoRH2peYdOc9DbCRjuct3XcbW2CKU3Og-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DF9B41.6050403@netconfcentral.com> Date: Fri, 10 Apr 2009 12:17:21 -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] 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: Fri, 10 Apr 2009 19:17:07 -0000 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. 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. Andy From andy@netconfcentral.com Sat Apr 11 10:02: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 3505C3A68C3 for ; Sat, 11 Apr 2009 10:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=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 k5mEjkhNmc-T for ; Sat, 11 Apr 2009 10:02:57 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 7E55A3A6872 for ; Sat, 11 Apr 2009 10:02:57 -0700 (PDT) Received: (qmail 5668 invoked from network); 11 Apr 2009 17:04:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.156.14 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 11 Apr 2009 17:04:06 -0000 X-YMail-OSG: FU4grO8VM1lWNHKjgMIagnHYNRCDbTC_nA0dAZQtNluQCI8BX17iz0ph9y0Vinblut2ca.Pq_dPpFQ6I2yGAvgQIq8eZn9ChkABxPuoFg8h59GVjhPA7fHcnOFEAmE2_TlTU9jHxRW81fTetYYUscpYTjR_gz0eCIAkKVcm_QnG1LKAO5pelm.3CrtrSvIT_HUehVJbuSsRy6PUP5FXMF9HJ9qKR6T.8Ki6QTb7vmy5CmhWatcGIykXogdyRlWB7jNpfn.aN1SDkpmU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E0CD84.3000108@netconfcentral.com> Date: Sat, 11 Apr 2009 10:04:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETCONF Content-Type: multipart/mixed; boundary="------------090904030201020802070601" Subject: [Netconf] ietf-netconf.yang 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, 11 Apr 2009 17:02:59 -0000 This is a multi-part message in MIME format. --------------090904030201020802070601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is a new version of the YANG module for the NETCONF protocol. The layers other than operations and content have been removed. A real hack of an extension has been added to deal with the element. I want to check that this is in the ballpark, before attempting to integrate the module into 4741-bis. Andy --------------090904030201020802070601 Content-Type: text/plain; name="ietf-netconf.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf-netconf.yang" module ietf-netconf { namespace "urn:ietf:params:xml:ns:netconf:base:1.0"; prefix nc; // for the uri data type import ietf-inet-types { prefix inet; } description "NETCONF Protocol * Data Types * Error information groupings * RPC methods "; reference "Translated from RFC 4741."; contact "TBD: WG contact info here"; revision 2009-04-11 { description "Initial version"; } // NETCONF capabilities defined as features feature writable-running { description "NETCONF :writable-running capability"; reference "RFC 4741, section 8.2"; } feature candidate { description "NETCONF :candidate capability"; reference "RFC 4741, section 8.3"; } feature confirmed-commit { description "NETCONF :confirmed-commit capability"; reference "RFC 4741, section 8.4"; if-feature candidate; } feature rollback-on-error { description "NETCONF :rollback-on-error capability"; reference "RFC 4741, section 8.5"; } feature validate { description "NETCONF :validate capability"; reference "RFC 4741, section 8.6"; } feature startup { description "NETCONF :startup capability"; reference "RFC 4741, section 8.7"; } feature url { description "NETCONF :url capability"; reference "RFC 4741, section 8.8"; } feature xpath { description "NETCONF :xpath capability"; reference "RFC 4741, section 8.9"; } extension get-filter-element-attributes { description "If this extension is present within the an 'anyxml' statement named 'filter', which must be conceptually defined within the RPC input section for the 'get' and 'get-config' RPC operations, then the following unqualified XML attribute is supported within the 'filter' element, within a 'get' or 'get-config' protocol operation: type : optional attribute with allowed value strings 'subtree' and 'xpath'. If missing, the default value is 'subtree'. If the xpath feature is supported, then the following unqualified XML attribute is also supported: select: optional attribute containing a string representing an XPath expression. The 'type' attribute must be equal to 'xpath' if this attribute is present."; } // NETCONF Simple Types typedef SessionId { description "NETCONF Session Id"; type uint32 { range "1..max"; } } typedef SessionIdOrZero { description "NETCONF Session Id or Zero to indicate none"; type uint32; } typedef ErrorType { description "NETCONF Error Type"; type enumeration { enum transport; enum rpc; enum protocol; enum application; } } typedef ErrorTag { description "NETCONF Error Tag"; type enumeration { enum in-use; enum invalid-value; enum too-big; enum missing-attribute; enum bad-attribute; enum unknown-attribute; enum missing-element; enum bad-element; enum unknown-element; enum unknown-namespace; enum access-denied; enum lock-denied; enum resource-denied; enum rollback-failed; enum data-exists; enum data-missing; enum operation-not-supported; enum operation-failed; enum partial-operation; } } typedef ErrorSeverity { description "NETCONF Error Severity"; type enumeration { enum error; enum warning; } } typedef TestOptionType { description "NETCONF 'test-option' Element Content. This is extended with the test-only enumeration. The 'set' option has no real effect since the entire PDU is always validated before any of it is applied (always test-then-set)."; type enumeration { enum test-then-set; enum set; // enum test-only; !!!! not part of the standard yet } default "set"; } typedef ErrorOptionType { description "NETCONF 'error-option' Element Content"; type enumeration { enum stop-on-error; enum continue-on-error; enum rollback-on-error; } default "stop-on-error"; } typedef EditOperationType { description "NETCONF 'operation' Attribute Content"; type enumeration { enum merge; enum replace; enum create; enum delete; } default "merge"; } typedef DefaultOperationType { description "NETCONF 'default-operation' Element Content"; type enumeration { enum merge; enum replace; enum none; } default "merge"; } typedef ConfirmTimeoutType { description "NETCONF 'confirm-timeout' Element Content"; type uint32 { range "1..max"; } units "seconds"; default "600"; // 10 minutes } typedef ConfigURIType { type inet:uri; } grouping ErrorInfoContent { // not actually used within this module description "NETCONF standard 'error-info' Element Content;"; leaf-list bad-attribute { description "Name of the missing or invalid XSD attribute. Used with missing-attribute, bad-attribute, and unknown-attribute error-tag values."; type string; // should be xs:QName config false; } leaf-list bad-element { description "Name of the element that contains (or should contain) an invalid XSD attribute when used with missing-attribute, bad-attribute, unknown-attribute, error-tag values. Name of an invalid or missing element when used with then missing-element, bad-element, unknown-element, and unknown-namespace error-tag values."; type instance-identifier; // xs:QName is wrong config false; } leaf-list ok-element { description "Identifies an element in the data model for which the requested operation has been completed for that node and all its child nodes. This element can appear zero or more times in the 'error-info' container. Used with the partial-operation error-tag value."; type instance-identifier; // xs:QName is wrong config false; } leaf-list err-element { description "Identifies an element in the data model for which the requested operation has failed for that node and all its child nodes. This element can appear zero or more times in the 'error-info' container. Used with the partial-operation error-tag value."; type instance-identifier; // xs:QName is wrong config false; } leaf-list noop-element { description "Identifies an element in the data model for which the requested operation was not attempted for that node and all its child nodes. This element can appear zero or more times in the container. Used with the partial-operation error-tag value."; type string; // xs:QName config false; } leaf session-id { description "Session ID of session holding the requested lock, or zero to indicate a non-NETCONF entity holds the lock."; type SessionIdOrZero; config false; } } grouping RpcErrorType { // not actually used within this module description "NETCONF 'rpc-error' Element Content"; leaf error-type { description "Defines the conceptual layer that the error occurred."; type ErrorType; mandatory true; } leaf error-tag { description "Contains a string identifying the error condition."; type ErrorTag; mandatory true; } leaf error-severity { description "Contains a string identifying the error severity, as determined by the device."; type ErrorSeverity; mandatory true; } leaf error-app-tag { description "Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition."; type string; } leaf error-path { description "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, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace."; type instance-identifier; } leaf error-message { description "Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute."; type string; // really LangString 'lang' attribute allowed } anyxml error-info { description "Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in RFC 4741, Appendix A, defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information."; } } grouping CommonConfigSourceType { description "Common NETCONF config parameter contents."; choice config-source { mandatory true; leaf candidate { if-feature candidate; description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { if-feature startup; description "Only available if 'startup' capability supported."; type empty; } } } grouping GetConfigSourceType { description "NETCONF config 'source' Parameter contents."; uses CommonConfigSourceType { augment config-source { leaf url { if-feature url; description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } } grouping RpcOperationSourceType { description "NETCONF 'source' Parameter contents."; uses CommonConfigSourceType { augment config-source { leaf url { if-feature url; description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } container config { description "Inline configuration data"; } } } } grouping RpcOperationTargetType { description "NETCONF 'target' Parameter contents."; uses CommonConfigSourceType { augment config-source { leaf url { if-feature url; description "URL pointing to desired config data output. Only available if 'url' capability supported."; type ConfigURIType; } } } } // NETCONF Standard RPC Methods rpc get-config { description "Retrieve all or part of a specified configuration."; reference "RFC 4741, section 7.2"; input { container source { description "Particular configuration to retrieve."; uses GetConfigSourceType; } anyxml filter { description "Subtree or Xpath filter to use."; nc:get-filter-element-attributes; } } output { container data { description "Copy of the source database subset which matched the filter criteria (if any)."; presence "An empty data container indicates that the request did not produce any results."; } } } rpc edit-config { description "The 'edit-config' operation loads all or part of a specified configuration to the specified target configuration. This operation allows the new configuration to be expressed in several ways, such as using a local file, a remote file, or inline. If the target configuration does not exist, it will be created. If a NETCONF peer supports the :url capability (Section 8.8), the element can appear instead of the parameter and should identify a local configuration file. The device analyzes the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced, as with the message. Instead, the target configuration is changed in accordance with the source's data and requested operations."; reference "RFC 4741, section 7.2"; input { container target { description "Particular configuration to edit."; // mandatory true; uses RpcOperationTargetType; } leaf default-operation { description "Default operation to apply if not explicitly set."; type DefaultOperationType; } leaf test-option { if-feature validate; description "Test option if validate capability supported. The 'validate' capability must be present to set this object to 'test-then-set'."; type TestOptionType; } leaf error-option { description "Error recovery option."; type ErrorOptionType; } choice edit-content { mandatory true; container config { description "Inline Config content: 'config' element."; } leaf url { if-feature url; description "Pointer to Config content: 'url' element."; type ConfigURIType; } } } } rpc copy-config { description "Create or replace an entire configuration datastore with the contents of another complete configuration datastore. If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed. If a NETCONF peer supports the :url capability (Section 8.8), the 'url' element can appear as the or parameter. Even if it advertises the :writable-running capability, a device may choose not to support the configuration datastore as the parameter of a operation. A device may choose not to support remote-to-remote copy operations, where both the and parameters use the element. If the source and target parameters identify the same URL or configuration datastore, an error MUST be returned with an error- tag containing invalid-value."; reference "RFC 4741, section 7.3"; input { container target { description "Particular configuration to copy to."; // mandatory true; uses RpcOperationTargetType; } container source { description "Particular configuration to copy from."; // mandatory true; uses RpcOperationSourceType; } } } rpc delete-config { description "Delete a configuration datastore. The 'running' configuration datastore cannot be deleted. If a NETCONF peer supports the :url capability (Section 8.8), the 'url' element can appear as the parameter."; reference "RFC 4741, section 7.4"; input { container target { description "Particular configuration to delete."; uses RpcOperationTargetType; } } } rpc lock { description "The lock operation allows the client to lock the configuration system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users. ..."; reference "RFC 4741, section 7.5"; input { container target { description "Particular configuration to lock"; // mandatory true; uses RpcOperationTargetType; } } } rpc unlock { description "The unlock operation is used to release a configuration lock, previously obtained with the 'lock' operation. An unlock operation will not succeed if any of the following conditions are true: * the specified lock is not currently active * the session issuing the operation is not the same session that obtained the lock The server MUST respond with either an element or an 'rpc-error'."; reference "RFC 4741, section 7.6"; input { container target { // mandatory true; description "Particular configuration to unlock."; uses RpcOperationTargetType; } } } rpc get { description "Retrieve running configuration and device state information."; reference "RFC 4741, section 7.7"; input { anyxml filter { description "This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is empty, all the device configuration and state information is returned. The filter element may optionally contain a 'type' attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value 'subtree' explicitly identifies this type of filtering. If the NETCONF peer supports the :xpath capability (Section 8.9), the value 'xpath' may be used to indicate that the select attribute of the filter element contains an XPath expression."; nc:get-filter-element-attributes; } } output { container data { description "Copy of the 'running' database subset which matched the filter criteria (if any)."; presence "An empty data container indicates that the request did not produce any results."; } } } rpc close-session { description "Request graceful termination of a NETCONF session. When a NETCONF server receives a request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a 'close-session' request will be ignored."; reference "RFC 4741, section 7.8"; } rpc kill-session { description "Force the termination of a NETCONF session. When a NETCONF entity receives a request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. If a NETCONF server receives a request while processing a confirmed commit (Section 8.4), it must restore the configuration to its state before the confirmed commit was issued. Otherwise, the operation does not roll back configuration or other device state modifications made by the entity holding the lock."; reference "RFC 4741, section 7.9"; input { leaf session-id { description "Particular session to kill."; type SessionId; mandatory true; } } } rpc commit { if-feature candidate; description "Only available if 'candidate' capability is supported. When a candidate configuration's content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration. To commit the candidate configuration as the device's new current configuration, use the operation. The 'commit' operation instructs the device to implement the configuration data contained in the candidate configuration. If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged. If the device does succeed in committing, the running configuration MUST be updated with the contents of the candidate configuration. If the system does not have the :candidate capability, the 'commit' operation is not available."; reference "RFC 4741, section 8.3.4.1"; input { leaf confirmed { description "Request a confirmed commit. Only available if 'confirmed-commit' capability is supported."; reference "RFC 4741, section 8.4.5.1"; type empty; } leaf confirm-timeout { description "Request a specific timeout period for a confirmed commit if 'confirmed-commit' capability supported."; reference "RFC 4741, section 8.4.5.1"; type ConfirmTimeoutType; } } } rpc discard-changes { if-feature candidate; description "Only available if 'candidate' capability is supported. If the client decides that the candidate configuration should not be committed, the 'discard-changes' operation can be used to revert the candidate configuration to the current running configuration. This operation discards any uncommitted changes by resetting the candidate configuration with the content of the running configuration."; reference "RFC 4741, section 8.3.4.2"; } rpc validate { if-feature validate; description "Only available if 'validate' capability is supported. Validates the contents of the specified configuration."; reference "RFC 4741, section 8.6.4.1"; input { container source { description "Particular configuration to validate."; // mandatory true; uses RpcOperationSourceType; } } } } --------------090904030201020802070601-- From andy@netconfcentral.com Sun Apr 12 10:03: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 45A2C3A6C12 for ; Sun, 12 Apr 2009 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.166 X-Spam-Level: X-Spam-Status: No, score=-1.166 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_20=-0.74, 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 E0wo+KGTworG for ; Sun, 12 Apr 2009 10:03:49 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id A0A7C3A6BA1 for ; Sun, 12 Apr 2009 10:03:49 -0700 (PDT) Received: (qmail 21716 invoked from network); 12 Apr 2009 17:04:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.156.14 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 12 Apr 2009 17:04:59 -0000 X-YMail-OSG: DzRmjI0VM1nI5StLjdl3aSJi.1Gv_M3inqO04edkWP5FnOUlat16oJfgNB2gNREgdbyu9_EYE8WP.Y.24FdoDREQQauSt8VTjBidBogTZXDb4gyQk_2GHvuxkmPArw72ZLWZFuLkCyo02xM4ELOkbcUfNSzc.6dJCZ2wOlaVuZHUWwJU3_eHECnzmISoqOgSlhQjjZSE2XDl9oFGMn8Z8.FXcejOVieF7hxXrPoVXDk4lPoLgXbTN7Z883DWRZRUk4V9EZLne1759AY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E21F3A.9030209@netconfcentral.com> Date: Sun, 12 Apr 2009 10:04:58 -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] partial-lock, 2.1.1.3 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, 12 Apr 2009 17:03:50 -0000 Hi, I was looking over the partial-lock draft, and I was wondering if the usage scenario in this section: Multiple managers handling the candidate datastore in a semi- coordinated work mode It seems to me that partial-lock is only really useful for the database, not the global . Multiple, independent (not coordinated) write operations are far more likely to need locking at all. The global is basically a one-at-a-time mechanism, especially when access control is eventually considered. How are all the managers supposed to know when the edits are done so one of them can issue ? What if some unrelated application takes out a partial-lock and starts editing the ? What if it does this with no lock at all? I think the standard NETCONF multi-user database architecture needs more work. You get some good features if you use as a target, and some other ones if you use as a target, but not all the features at once. Andy From Washam.Fan@huaweisymantec.com Sun Apr 12 19:18: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 B9DEA3A6B62 for ; Sun, 12 Apr 2009 19:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=-1.997, 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 E9f8rPCkfw2y for ; Sun, 12 Apr 2009 19:18:51 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id AD1D13A6C77 for ; Sun, 12 Apr 2009 19:18: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 <0KI000DUBP50FV10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 13 Apr 2009 10:19:50 +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 <0KI000I0QP4YRB00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 13 Apr 2009 10:19:48 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 13 Apr 2009 10:19:46 +0800 From: WashamFan To: netconf@ietf.org Message-id: Date: Mon, 13 Apr 2009 10:19:46 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [Netconf] partial-lock, 2.1.1.2 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, 13 Apr 2009 02:18:51 -0000 Hi, para2 says: Each manager has his or her own task, which does not involve the modification of overlapping sections of the datastore. If no overlapping is involved, what partial lock is for? I think, the point is, each manager is authorized to one or more separate areas, but it might be possible that more than one managers are authorized to the same area. Then, it is where partial lock works. I think, it'd better if we clarify more. washam From andy@netconfcentral.com Sun Apr 12 19:49: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 666AB3A6CBA for ; Sun, 12 Apr 2009 19:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_50=0.001, 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 n5aFw9kO5QDB for ; Sun, 12 Apr 2009 19:49:52 -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 CE45F3A69F6 for ; Sun, 12 Apr 2009 19:49:52 -0700 (PDT) Received: (qmail 24203 invoked from network); 13 Apr 2009 02:51:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 13 Apr 2009 02:51:02 -0000 X-YMail-OSG: knpAhG8VM1lJv.4oG.tdY6j2gRDkx2wZIvqd75r1.w4Lq61v3._oF7BDJA5qB3LcFTrpTQe_zI8EuP8D31AdUJQ4z1aMgLKa_zp6iu5R9MaxmmmGzCymmE75BfHfBhJWeJdULPpuD6FPtMO6phEUzSycXH7KGkbQTIAdxDt5L0.v0G8DrGIFsTfboLNcEx8E1QHisE819gwTPM81QdlURY726I_fEhBcNhtQPddluxqo804Ysjo3NHtj9G_MV8UpIMwb7vAx_y8hvF2h X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E2A895.50502@netconfcentral.com> Date: Sun, 12 Apr 2009 19:51:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock, 2.1.1.2 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, 13 Apr 2009 02:49:53 -0000 WashamFan wrote: > Hi, > > para2 says: > > Each manager has his or her own task, which does not involve the > modification of overlapping sections of the datastore. > > If no overlapping is involved, what partial lock is for? I think, the point is, > each manager is authorized to one or more separate areas, but it might be > possible that more than one managers are authorized to the same area. Then, > it is where partial lock works. > > I think, it'd better if we clarify more. > The candidate config has no concept of a partial commit or a partial discard-changes. The only safe way to use the candidate config is one-session-at-a-time (i.e., with a global lock on the candidate). > washam Andy From Washam.Fan@huaweisymantec.com Sun Apr 12 23:10: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 C3CBD3A698B for ; Sun, 12 Apr 2009 23:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_05=-1.11, 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 xGHDsNvqbdxc for ; Sun, 12 Apr 2009 23:10:07 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id EDAF53A6885 for ; Sun, 12 Apr 2009 23:10:06 -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 <0KI0002J0ZUDZR40@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Mon, 13 Apr 2009 14:11:03 +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 <0KI000IF4ZUBV000@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 13 Apr 2009 14:11:01 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 13 Apr 2009 14:10:59 +0800 From: WashamFan To: netconf@ietf.org Message-id: Date: Mon, 13 Apr 2009 14:10:59 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [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: Mon, 13 Apr 2009 06:10:07 -0000 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? 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. washam From andy@netconfcentral.com Mon Apr 13 04:58: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 1EB483A6D47 for ; Mon, 13 Apr 2009 04:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.384, 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 GTR56-yLCCSZ for ; Mon, 13 Apr 2009 04:58:49 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id 3DF433A6822 for ; Mon, 13 Apr 2009 04:58:49 -0700 (PDT) Received: from [209.191.108.97] by n19.bullet.mail.mud.yahoo.com with NNFMP; 13 Apr 2009 11:59:59 -0000 Received: from [68.142.201.240] by t4.bullet.mud.yahoo.com with NNFMP; 13 Apr 2009 11:59:59 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 13 Apr 2009 11:59:59 -0000 X-Yahoo-Newman-Id: 890735.45676.bm@omp401.mail.mud.yahoo.com Received: (qmail 54426 invoked from network); 13 Apr 2009 11:59:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 13 Apr 2009 11:59:58 -0000 X-YMail-OSG: ai0anDQVM1lqBt8Xnp2uN1KHqFfelW0wKqw5QUIeNlPNceYyJl7KLY_LSvf5iSZ31Hv7JtZMEKFc7wYzYbPEJWGl.elxNCh9s5xIgstWqVU82gMEaqnu3zP1LmquGEEQ.t6upndXzud1GRCJUMPDomqyVTk6W6m9p6lBIbJPO5X6FhVMAUTG2C5mSiNIuEJTUGZPN8zSw9lYPQrMOeiL_jtRN.CWygUMMlJnykloU2Qdwe9UQl7he_5kfBUU0H3uR6Vi1n6kdSl7c6QQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E3293D.20306@netconfcentral.com> Date: Mon, 13 Apr 2009 04:59:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 13 Apr 2009 11:58:50 -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? > > 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. > This 'standard' is completely useless unless 'report-all' is mandatory-to-implement. > washam Andy From andy@netconfcentral.com Mon Apr 13 09:58: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 1C5DE3A6E06 for ; Mon, 13 Apr 2009 09:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_40=-0.185, 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 A9lh0SyG5oRu for ; Mon, 13 Apr 2009 09:58:08 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 6E8F33A6D66 for ; Mon, 13 Apr 2009 09:58:08 -0700 (PDT) Received: (qmail 88928 invoked from network); 13 Apr 2009 16:59:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 13 Apr 2009 16:59:18 -0000 X-YMail-OSG: AokjP40VM1lZ7Vz8TMMtPRueHPpiAdO16YbhFKie6b4bWfxBNKzOAXahOQw9G2CL6.S8Y2izkbp5XWSdokmXlF1.4mh8BC3_DlMm_6vzNgtZscF0DYB4j_0bu4BBMBcOzxCezAx6ps8_wxego6Hm0bUuXvGPi8yeFFSJCLsT1fokCh8o8iOfxCbpWeJcdbudGaLmXyc3lAuODXS_GCOxiBTJBDFQ8raIbfCh7FjdoLm1zF5.fAMrL_87fp4ZZf9ouuKh8B9HHlbmuErCcOCKbvr_r.Ys2qjEU72_Gz5fhCS_kmlZNQ4VLehYSw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E36F65.60709@netconfcentral.com> Date: Mon, 13 Apr 2009 09:59:17 -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] partial-lock and the candidate config 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, 13 Apr 2009 16:58:09 -0000 Hi, When a partial-lock is granted, it affects all the operations [2.4.1, para 2; 2.5, para 1] sec 2.1.1.3: - missing this sentence from previous section, which also applies the a shared candidate: This scenario assumes, that the global lock operation from [NETCONF] is not used. The partial-lock operation leads to a deadlock scenario that Wes has described many times wrt/ global locking. Except with partial-locking, the recovery is much more severe. If session A has access rights and a partial-lock on /foo and session B has access rights and a partial-lock on /bar, then neither one of them can issue a commit, and neither one can issue a discard-changes. The candidate config is dead-locked until one session releases all its partial-locks and one set of edits to the candidate config are 'undone'. But what if that doesn't happen? What if session A issues a kill-session on the other one instead? Or session B terminates for any reason? The partial-locks for /bar will be released OK, but the discard-changes will fail because of the active partial-lock on /foo, owned by session A. So session A is left with one option. Issue a discard-changes (which reverts /bar -- but session A has no access rights to /bar?!) It is not allowed to alter /bar, so it has to toss out its own changes to /foo, and start over. And session A has no idea what else changed in the candidate. It just knows its discard-changes and commit requests are failing. I'm not convinced this is better than just holding a global lock for the duration of an edit to the candidate config. Andy From Washam.Fan@huaweisymantec.com Mon Apr 13 20: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 234723A6BC0 for ; Mon, 13 Apr 2009 20:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_05=-1.11, 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 LuEfVMDJYACd for ; Mon, 13 Apr 2009 20:17:43 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 29FB43A6A98 for ; Mon, 13 Apr 2009 20:17:43 -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 <0KI2003MRMJ3AV30@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 11:18: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 <0KI200C4JMJ11P00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 11:18:39 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 14 Apr 2009 11:18:37 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 14 Apr 2009 11:18:37 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49E36F65.60709@netconfcentral.com> References: <49E36F65.60709@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] partial-lock and the candidate config 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, 14 Apr 2009 03:17:44 -0000 > The partial-lock operation leads to a deadlock scenario > that Wes has described many times wrt/ global locking. > Except with partial-locking, the recovery is much more severe. > > If session A has access rights and a partial-lock > on /foo and session B has access rights and a partial-lock > on /bar, then neither one of them can issue a commit, > and neither one can issue a discard-changes. Yep. That is where deadlock happens, and the reason is absence of partial-[op], IMO. candidate datastore is mostly a one-session-at-a-time basis. > The candidate config is dead-locked until one session > releases all its partial-locks and one set of edits > to the candidate config are 'undone'. > > But what if that doesn't happen? > What if session A issues a kill-session on the other > one instead? Or session B terminates for any reason? > > The partial-locks for /bar will be released OK, > but the discard-changes will fail because of the active > partial-lock on /foo, owned by session A. > > So session A is left with one option. > Issue a discard-changes (which reverts /bar -- but > session A has no access rights to /bar?!) > It is not allowed to alter /bar, so it has to toss > out its own changes to /foo, and start over. > And session A has no idea what else changed in the candidate. > It just knows its discard-changes and commit requests > are failing. With recovery, I think it is more an access control issue than partial-lock issue. Given example: 1) session B takes out a global lock, and then terminates by any reason or releases the lock without . It leads to oustanding changes on /bar. 2) session A takes out a global lock( I am not sure whether a session without a global access can acquire a global lock, but I assume it can), for the same token you mentioned, session A will fail and as no access right to /bar. So can we say anyone without access rights to the whole candidate datastore would encounter some trouble issuing and ? washam > I'm not convinced this is better than just holding a > global lock for the duration of an edit to > the candidate config. > > > Andy From mbj@tail-f.com Mon Apr 13 23:03: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 B62FE3A6DB2 for ; Mon, 13 Apr 2009 23:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2aycaSCbTg9 for ; Mon, 13 Apr 2009 23:03: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 E34D23A693E for ; Mon, 13 Apr 2009 23:03:18 -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 BC4BA76C52F; Tue, 14 Apr 2009 08:04:28 +0200 (CEST) Date: Tue, 14 Apr 2009 08:04:28 +0200 (CEST) Message-Id: <20090414.080428.175607206.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <200904071209.n37C9poA067443@idle.juniper.net> <20090407.154130.196306247.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] 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, 14 Apr 2009 06:03:19 -0000 WashamFan wrote: > > It seems we have three variations on the same theme; sessions must > > behave as if the advertised capabilities do not change. The three > > variations would be: > > > > 1) kill all sessions > > > > 2) let all sessions enter a state where they get a > > 'capabilities-changed' error for any operation but close-session > > > > 3) let sessions continue, and "some" operations will continue to > > work, but some other will fail with an 'capabilities-changed' > > error. > > I suggest a variant of 2) > > 2*) let all sessions enter a state where they get a > 'capabilities-changed' warning for any operation but close-session > > Why block all operations even those didn't get affected? That's what 3) above takes care of - the server knows which operations are affected, and accepts them. The other, affected operations, fail with the 'capabilities-changed' error code. The problem with issuing a warning is that the behaviour of warnings are a bit unclear in 4741. This is something we need to dicsuss for 4741bis. > If manager > can't understand the rpc-reply due to new data model added, for > example, it can reference the warnig info, otherwise ignore the warning. > I.e., when there are something error or I do not understand happen, I > will refer to the warning info, otherwise I could ignore the warning info. This seems fragile to me. If an operation returns an error and an 'capabilities-changed' error, how can the client tell if the error was due to the changed capability or something else? /martin From mbj@tail-f.com Mon Apr 13 23:14: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 294333A6A27 for ; Mon, 13 Apr 2009 23:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.058, 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 v0C66r4-NSAg for ; Mon, 13 Apr 2009 23:14:03 -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 4A40A3A693E for ; Mon, 13 Apr 2009 23:14:03 -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 2ACC676C52F; Tue, 14 Apr 2009 08:15:09 +0200 (CEST) Date: Tue, 14 Apr 2009 08:15:08 +0200 (CEST) Message-Id: <20090414.081508.215323178.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090407170549.GA29864@elstar.local> References: <20090407.154130.196306247.mbj@tail-f.com> <200904071430.n37EUdLc069046@idle.juniper.net> <20090407170549.GA29864@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: 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, 14 Apr 2009 06:14:04 -0000 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. Agreed. > 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. /martin From andy@netconfcentral.com Tue Apr 14 00:09:11 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 DBBD63A6991 for ; Tue, 14 Apr 2009 00:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.393, 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 2-GPKScmGxSP for ; Tue, 14 Apr 2009 00:09:11 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 167CA3A6809 for ; Tue, 14 Apr 2009 00:09:11 -0700 (PDT) Received: (qmail 29366 invoked from network); 14 Apr 2009 07:10:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 07:10:22 -0000 X-YMail-OSG: i4Hm.cYVM1mACSb1.f6z6Fr03ekHYtQYoHTvJ.arCnztjY2Ct52bXSu3Ev2RpTV_9xF6M.5CQPhrtpoGYk7PLExcDpbZvSS8ESVV5JXOH6F0JKmVaVlcR8udflIXkhdaR.9J0Lnr9uc6r1TctnufRXBWC8R3hhPH.Yhv3XZVjPpXrUB8qRKtsPEbibYpFVYdnLai5RF6VXzeYte2bPTK81vxRsxwasTiFRfQWT.UVt84sKBtOha56t5t5Xz8IyLMOS4taXXLmRGjUaTW X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E436DC.3030809@netconfcentral.com> Date: Tue, 14 Apr 2009 00:10:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: <49E36F65.60709@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] partial-lock and the candidate config 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, 14 Apr 2009 07:09:11 -0000 WashamFan wrote: >> The partial-lock operation leads to a deadlock scenario >> that Wes has described many times wrt/ global locking. >> Except with partial-locking, the recovery is much more severe. >> >> If session A has access rights and a partial-lock >> on /foo and session B has access rights and a partial-lock >> on /bar, then neither one of them can issue a commit, >> and neither one can issue a discard-changes. > > Yep. That is where deadlock happens, and the reason is > absence of partial-[op], IMO. candidate datastore is mostly > a one-session-at-a-time basis. > It is not a matter of opinion. It is simple engineering. >> The candidate config is dead-locked until one session >> releases all its partial-locks and one set of edits >> to the candidate config are 'undone'. >> >> But what if that doesn't happen? >> What if session A issues a kill-session on the other >> one instead? Or session B terminates for any reason? >> >> The partial-locks for /bar will be released OK, >> but the discard-changes will fail because of the active >> partial-lock on /foo, owned by session A. >> >> So session A is left with one option. >> Issue a discard-changes (which reverts /bar -- but >> session A has no access rights to /bar?!) >> It is not allowed to alter /bar, so it has to toss >> out its own changes to /foo, and start over. >> And session A has no idea what else changed in the candidate. >> It just knows its discard-changes and commit requests >> are failing. > > With recovery, I think it is more an access control issue than > partial-lock issue. > Given example: > > 1) session B takes out a global lock, and then terminates > by any reason or releases the lock without . It leads to > oustanding changes on /bar. > why is there any problem with global lock? If only one session has altered the candidate, then its discard-changes (triggered by the dropped session) will work fine. Please re-read all the relevant text in partial-lock and 4741. > 2) session A takes out a global lock( I am not sure whether a session > without a global access can acquire a global lock, but I assume it can), > for the same token you mentioned, session A will fail and > as no access right to /bar. > > So can we say anyone without access rights to the whole candidate > datastore would encounter some trouble issuing and -changes>? > I think analysis of the current text is quite simple. The partial-lock operation does not provide any actual protection for multi-session writes to the candidate config. This is database-201 basic stuff here. > washam > >> I'm not convinced this is better than just holding a >> global lock for the duration of an edit to >> the candidate config. >> >> >> Andy > > > Andy From Washam.Fan@huaweisymantec.com Tue Apr 14 00:13: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 4B1793A6821 for ; Tue, 14 Apr 2009 00:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=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 UZW0YSyyCdLi for ; Tue, 14 Apr 2009 00:13:20 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 437253A6A5A for ; Tue, 14 Apr 2009 00:13: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.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KI2003PRXFUAV50@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 15:14: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 <0KI200CINXFST400@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 15:14:18 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 14 Apr 2009 15:14:16 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Tue, 14 Apr 2009 15:14:16 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090414.080428.175607206.mbj@tail-f.com> References: <200904071209.n37C9poA067443@idle.juniper.net> <20090407.154130.196306247.mbj@tail-f.com> <20090414.080428.175607206.mbj@tail-f.com> 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, 14 Apr 2009 07:13:21 -0000 > WashamFan wrote: > > > It seems we have three variations on the same theme; sessions must > > > behave as if the advertised capabilities do not change. The three > > > variations would be: > > > > > > 1) kill all sessions > > > > > > 2) let all sessions enter a state where they get a > > > 'capabilities-changed' error for any operation but close-session > > > > > > 3) let sessions continue, and "some" operations will continue > to > > > work, but some other will fail with an 'capabilities-changed' > > > error. > > > > I suggest a variant of 2) > > > > 2*) let all sessions enter a state where they get a > > 'capabilities-changed' warning for any operation but close-session > > > > Why block all operations even those didn't get affected? > > That's what 3) above takes care of - the server knows which operations > are affected, and accepts them. The other, affected operations, fail > with the 'capabilities-changed' error code. > > The problem with issuing a warning is that the behaviour of warnings > are a bit unclear in 4741. This is something we need to dicsuss for > 4741bis. > > > If manager > > can't understand the rpc-reply due to new data model added, for > > example, it can reference the warnig info, otherwise ignore the warning. > > I.e., when there are something error or I do not understand happen, > I > > will refer to the warning info, otherwise I could ignore the > warning info. > > This seems fragile to me. If an operation returns an error and an > 'capabilities-changed' error, how can the client tell if the error was > due to the changed capability or something else? I don't think 'capabilities-changed' is a direct answer to why an operation failed or why agent can't understand requested data? For example: a manger issues an operation to a agent, but the capability supporting the operation has been deleted. Then 'operation-not-supported' (maybe followed by 'capabilities-changed') error should be returned. For the same token, 'data-missing' error(maybe followed by 'capabilities-changed') should be returned if relevant data model is deleted.That is why I consider 'capabilities-changed' as a warning more than an error. But as you mentiond, use of warning is unclear now. You suggest let agent decide whether 'capabilities-changed' error is returned to 1) affected operations or 2) all operations. With 1), a manager can not know capabilities changed until it issues an affected operation, with 2), unaffected operation is affected eventually. I just want to give even affected operations a *warning* to help manager determine whether continue or terminate the session. washam From Washam.Fan@huaweisymantec.com Tue Apr 14 00:51: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 CBCB23A692D for ; Tue, 14 Apr 2009 00:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_05=-1.11, 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 rXdzZ-i5gUb1 for ; Tue, 14 Apr 2009 00:51:21 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id D71CD3A68AC for ; Tue, 14 Apr 2009 00:51: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.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KI20035JZ77AV60@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 15:52:21 +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 <0KI200BJLZ75Y000@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 15:52:19 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 14 Apr 2009 15:52:17 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 14 Apr 2009 15:52:17 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49E436DC.3030809@netconfcentral.com> References: <49E36F65.60709@netconfcentral.com> <49E436DC.3030809@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] partial-lock and the candidate config 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, 14 Apr 2009 07:51:21 -0000 Hi, > >> The candidate config is dead-locked until one session > >> releases all its partial-locks and one set of edits > >> to the candidate config are 'undone'. > >> > >> But what if that doesn't happen? > >> What if session A issues a kill-session on the other > >> one instead? Or session B terminates for any reason? > >> > >> The partial-locks for /bar will be released OK, > >> but the discard-changes will fail because of the active > >> partial-lock on /foo, owned by session A. > >> > >> So session A is left with one option. > >> Issue a discard-changes (which reverts /bar -- but > >> session A has no access rights to /bar?!) > >> It is not allowed to alter /bar, so it has to toss > >> out its own changes to /foo, and start over. > >> And session A has no idea what else changed in the candidate. > >> It just knows its discard-changes and commit requests > >> are failing. > > > > With recovery, I think it is more an access control issue than > > partial-lock issue. > > Given example: > > > > 1) session B takes out a global lock, and then terminates > > by any reason or releases the lock without . It leads to > > oustanding changes on /bar. > > > > why is there any problem with global lock? > If only one session has altered the candidate, > then its discard-changes (triggered by the dropped > session) will work fine. Please re-read all the relevant > text in partial-lock and 4741. What the example is expected to express is, whatever is used, global lock or partial lock, recovery issue will raise. When only one session at a time accesses candidate, it will probably still deal with 'undone' edits left by another sessions, if it didn't have enough rights, and will fail, too. Am I misunderstand? washam > > 2) session A takes out a global lock( I am not sure whether a session > > without a global access can acquire a global lock, but I assume it > can), > > for the same token you mentioned, session A will fail and > > as no access right to /bar. > > > > So can we say anyone without access rights to the whole candidate > > datastore would encounter some trouble issuing and > -changes>? > > > > I think analysis of the current text is quite simple. > The partial-lock operation does not provide any actual > protection for multi-session writes to the candidate config. > This is database-201 basic stuff here. > > > > washam > > > >> I'm not convinced this is better than just holding a > >> global lock for the duration of an edit to > >> the candidate config. > >> > >> > >> Andy > > > > > > > > Andy > > > From balazs.lengyel@ericsson.com Tue Apr 14 01:12: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 3E6543A69A4 for ; Tue, 14 Apr 2009 01:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.143, 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 aVLsJnlTEERz for ; Tue, 14 Apr 2009 01:12:24 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5A9133A6767 for ; Tue, 14 Apr 2009 01:12:21 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E204521624 for ; Tue, 14 Apr 2009 10:13:28 +0200 (CEST) X-AuditID: c1b4fb3e-af826bb0000024d5-ec-49e445718226 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7D71F21319 for ; Tue, 14 Apr 2009 10:12:34 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 10:11:34 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 10:11:33 +0200 Message-ID: <49E44535.8000704@ericsson.com> Date: Tue, 14 Apr 2009 10:11:33 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org References: <20090407.154130.196306247.mbj@tail-f.com> <200904071430.n37EUdLc069046@idle.juniper.net> <20090407170549.GA29864@elstar.local> <20090414.081508.215323178.mbj@tail-f.com> In-Reply-To: <20090414.081508.215323178.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2009 08:11:33.0852 (UTC) FILETIME=[9FE829C0:01C9BCD8] X-Brightmail-Tracker: AAAAAA== 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, 14 Apr 2009 08:12:25 -0000 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. > > Agreed. > >> 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. > > Sound nice to me. So is the following text what we are looking for: 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. It would also be nice to define a standard 'capabilities-changed' notification, that might be used by manager SW. Balazs From mbj@tail-f.com Tue Apr 14 01:36: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 83FC83A6837 for ; Tue, 14 Apr 2009 01:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_05=-1.11, 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 VrGGULqO5LHL for ; Tue, 14 Apr 2009 01:36:00 -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 B062A3A6827 for ; Tue, 14 Apr 2009 01:36:00 -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 DBFB261600B; Tue, 14 Apr 2009 10:37:10 +0200 (CEST) Date: Tue, 14 Apr 2009 10:37:10 +0200 (CEST) Message-Id: <20090414.103710.226431161.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <49E36F65.60709@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] partial-lock and the candidate config 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, 14 Apr 2009 08:36:01 -0000 WashamFan wrote: > With recovery, I think it is more an access control issue than > partial-lock issue. > Given example: > > 1) session B takes out a global lock, and then terminates > by any reason or releases the lock without . It leads to > oustanding changes on /bar. No, b/c when B terminates with an outstanding lock, the canididate is reverted, see 8.3.5.2 of RFC 4741. > 2) session A takes out a global lock( I am not sure whether a session > without a global access can acquire a global lock, but I assume it can), > for the same token you mentioned, session A will fail and > as no access right to /bar. Also, a session cannot take a global lock if there are any outstanding, uncommitted modifications to the candidate (see 7.5 of RFC 4741). But your point can be made w/o any locks at all. Suppose session A modifies /foo in the candidate w/o a lock. Next, B modifies /bar in the candidate w/o a lock. Then B terminates. A will not be able to commit or discard-changes. The solution is to use locks. If the conclusion is that b/c of this partial-lock should not be allowed on the candidate, maybe we should also disallow edit-config of the candidate unless the global lock is set? /martin From andy@netconfcentral.com Tue Apr 14 02:03: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 E3CBA3A6A8A for ; Tue, 14 Apr 2009 02:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.339, 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 7qBsIIm887w4 for ; Tue, 14 Apr 2009 02:03:13 -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 BB75B3A6A8D for ; Tue, 14 Apr 2009 02:03:12 -0700 (PDT) Received: (qmail 96381 invoked from network); 14 Apr 2009 09:04:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 09:04:23 -0000 X-YMail-OSG: 5IllAWcVM1kv5MXuJA3uw0e7QHx9YNgilhEome_YqvCv7nL2uwTZIWqCphXgVBlUlfdOqN4bB0xLW0z92vXcK7nyzbHs5M5WpYSk99_2QjRj1qo4eZVHhL_giEFGgugpEzzt9rFraOopLqbxHAZMNk14gV6U_9peb2E4fqfHEnuYk4S5kgERYT3S968AmA4VBKxnLR0XKo0AvIwOGO8W75cGY8kJalXoqwDvJe9QOT8VqrRP3YbIfdzjdgaWQaGD85_rAXeesqHJNoBEb8uu.aqqW8lCtCHr_3FLyIFAqyNFcmbsI91Emk.IPc5OWA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E45196.4060808@netconfcentral.com> Date: Tue, 14 Apr 2009 02:04:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49E36F65.60709@netconfcentral.com> <20090414.103710.226431161.mbj@tail-f.com> In-Reply-To: <20090414.103710.226431161.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] partial-lock and the candidate config 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, 14 Apr 2009 09:03:14 -0000 Martin Bjorklund wrote: > WashamFan wrote: >> With recovery, I think it is more an access control issue than >> partial-lock issue. >> Given example: >> >> 1) session B takes out a global lock, and then terminates >> by any reason or releases the lock without . It leads to >> oustanding changes on /bar. > > No, b/c when B terminates with an outstanding lock, the canididate is > reverted, see 8.3.5.2 of RFC 4741. > >> 2) session A takes out a global lock( I am not sure whether a session >> without a global access can acquire a global lock, but I assume it can), >> for the same token you mentioned, session A will fail and >> as no access right to /bar. > > Also, a session cannot take a global lock if there are any > outstanding, uncommitted modifications to the candidate (see 7.5 of > RFC 4741). > > > But your point can be made w/o any locks at all. Suppose session A > modifies /foo in the candidate w/o a lock. Next, B modifies /bar in > the candidate w/o a lock. Then B terminates. A will not be able to > commit or discard-changes. The solution is to use locks. > > If the conclusion is that b/c of this partial-lock should not be > allowed on the candidate, maybe we should also disallow edit-config of > the candidate unless the global lock is set? > IMO, the conclusion is that partial-locking on the candidate works just as badly as no locking at all. That does not lead to any logical deduction about global locking. That works on the candidate just fine. > > /martin > > Andy From mbj@tail-f.com Tue Apr 14 02:07: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 C9FCA3A6AB4 for ; Tue, 14 Apr 2009 02:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.077, 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 x4RpgX-hxIW5 for ; Tue, 14 Apr 2009 02:07:35 -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 F33BC3A6A8D for ; Tue, 14 Apr 2009 02:07:34 -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 E281661600B; Tue, 14 Apr 2009 11:08:45 +0200 (CEST) Date: Tue, 14 Apr 2009 11:08:45 +0200 (CEST) Message-Id: <20090414.110845.120951722.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49E45196.4060808@netconfcentral.com> References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@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] partial-lock and the candidate config 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, 14 Apr 2009 09:07:35 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > WashamFan wrote: > >> With recovery, I think it is more an access control issue than > >> partial-lock issue. Given example: > >> > >> 1) session B takes out a global lock, and then terminates > >> by any reason or releases the lock without . It leads to > >> oustanding changes on /bar. > > No, b/c when B terminates with an outstanding lock, the canididate is > > reverted, see 8.3.5.2 of RFC 4741. > > > >> 2) session A takes out a global lock( I am not sure whether a session > >> without a global access can acquire a global lock, but I assume it can), > >> for the same token you mentioned, session A will fail and > >> as no access right to /bar. > > Also, a session cannot take a global lock if there are any > > outstanding, uncommitted modifications to the candidate (see 7.5 of > > RFC 4741). > > But your point can be made w/o any locks at all. Suppose session A > > modifies /foo in the candidate w/o a lock. Next, B modifies /bar in > > the candidate w/o a lock. Then B terminates. A will not be able to > > commit or discard-changes. The solution is to use locks. > > If the conclusion is that b/c of this partial-lock should not be > > allowed on the candidate, maybe we should also disallow edit-config of > > the candidate unless the global lock is set? > > > > IMO, the conclusion is that partial-locking on the candidate > works just as badly as no locking at all. Ok, so should we disallow both partial-lock and no-lock of candidate? > That does not > lead to any logical deduction about global locking. > That works on the candidate just fine. Yes, global lock on candidate works fine. /martin From Washam.Fan@huaweisymantec.com Tue Apr 14 02:53: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 A357D3A67AA for ; Tue, 14 Apr 2009 02:53:50 -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 vuJZTxWF2fuD for ; Tue, 14 Apr 2009 02:53:50 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id C5F5A3A67A1 for ; Tue, 14 Apr 2009 02:53:49 -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 <0KI3003IJ4VCAV70@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 17:54:50 +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 <0KI300CQE4VAE200@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 14 Apr 2009 17:54:48 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 14 Apr 2009 17:54:46 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Tue, 14 Apr 2009 17:54:46 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090414.110845.120951722.mbj@tail-f.com> References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock and the candidate config 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, 14 Apr 2009 09:53:50 -0000 > > IMO, the conclusion is that partial-locking on the candidate > > works just as badly as no locking at all. > > Ok, so should we disallow both partial-lock and no-lock of candidate? > Or we just state clearly how difficult recovery would be when partial-lock and no-lock apply to candidate, and recommend global lock is always used to candidate? washam > > That does not > > lead to any logical deduction about global locking. > > That works on the candidate just fine. > > Yes, global lock on candidate works fine. > > > /martin > From mbj@tail-f.com Tue Apr 14 05:08: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 C38143A6DA2 for ; Tue, 14 Apr 2009 05:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.065, 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 14a3b2cjrmEU for ; Tue, 14 Apr 2009 05:08:09 -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 01F763A6A90 for ; Tue, 14 Apr 2009 05:08:08 -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 16F6D616025; Tue, 14 Apr 2009 14:09:19 +0200 (CEST) Date: Tue, 14 Apr 2009 14:09:18 +0200 (CEST) Message-Id: <20090414.140918.104946542.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49E0CD84.3000108@netconfcentral.com> References: <49E0CD84.3000108@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] ietf-netconf.yang 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, 14 Apr 2009 12:08:09 -0000 Hi Andy, Andy Bierman wrote: > Here is a new version of the YANG module for > the NETCONF protocol. The layers other than > operations and content have been removed. > A real hack of an extension has been added > to deal with the element. > > I want to check that this is in the ballpark, > before attempting to integrate the module > into 4741-bis. I have a couple of comments: o You are using 'feature' to define capabilities. The only problem I have with this is that according to the YANG spec, a server will advertise its features as part of the capability uri: urn:ietf:params:xml:ns:netconf:base:1.0?features=candidate,xpath But that's not how it is supposed to be done in this case. So I wonder if it's really such a good idea to use 'feature' for this purpose. o You define all rpc-error stuff, but with the comment: // not actually used within this module Is the plan to remove this? (I think it should, since this is part of the RPC layer). o I suggest we remove all 'CommonConfigSourceType', 'RpcOperationSourceType' etc. and instead explicitly list each source / target for each operation. I think this will be more clear and less error-prone. For example, according to the YANG module, delete-config of running is allowed (I know the text says otherwise). I think it would be fine to define one grouping per datastore, and then use it in all operations. o Several 'mandatory true' statements are commented away - are there any problems with having them there? o In a comment, you write that 'bad-element' should not be QName, as it is in the XSD. I disagree; I think it is clear that the intention of 4741 is that bad-element is simply a QName, and if that is not enough, then 'error-path' should be used. /martin From andy@netconfcentral.com Tue Apr 14 07:02:11 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 7C1C128C119 for ; Tue, 14 Apr 2009 07:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.305, 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 qnvt4+Oibmmb for ; Tue, 14 Apr 2009 07:02:10 -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 2046628C101 for ; Tue, 14 Apr 2009 07:01:59 -0700 (PDT) Received: (qmail 90320 invoked from network); 14 Apr 2009 14:03:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 14:03:10 -0000 X-YMail-OSG: xkBx2R4VM1n2oAx7oOY5ODB1aSffiJO4ipp4zOmUtbcEVeDkvOEkkXLqtH.jfFVr.EgjD6YI9J2dkKYPrm4N5_R_IyIlRdBJRLLjUrZ0EBhX0Bf0Tj926pS1jLR0xH4w4qETJgoGzPNBEFh5s_G4h1rgaCregcpXMIenyrjCgIlj14zzNybbtV53a0_pJX2DFz4Ye3hojrKqWTb5FYZ7Hf.PWqPMIRKXqKhcwnCb4dj6R2JqoAFhCVlP8QEcDNy2wdu7luHqueMSmVaXRFzLqgKMcCLkGobGyYRZlRV1c2iU37T2Gf4bW8ChnrJ2zg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E4979C.4060005@netconfcentral.com> Date: Tue, 14 Apr 2009 07:03:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> In-Reply-To: <20090414.110845.120951722.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] partial-lock and the candidate config 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, 14 Apr 2009 14:02:11 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> WashamFan wrote: >>>> With recovery, I think it is more an access control issue than >>>> partial-lock issue. Given example: >>>> >>>> 1) session B takes out a global lock, and then terminates >>>> by any reason or releases the lock without . It leads to >>>> oustanding changes on /bar. >>> No, b/c when B terminates with an outstanding lock, the canididate is >>> reverted, see 8.3.5.2 of RFC 4741. >>> >>>> 2) session A takes out a global lock( I am not sure whether a session >>>> without a global access can acquire a global lock, but I assume it can), >>>> for the same token you mentioned, session A will fail and >>>> as no access right to /bar. >>> Also, a session cannot take a global lock if there are any >>> outstanding, uncommitted modifications to the candidate (see 7.5 of >>> RFC 4741). >>> But your point can be made w/o any locks at all. Suppose session A >>> modifies /foo in the candidate w/o a lock. Next, B modifies /bar in >>> the candidate w/o a lock. Then B terminates. A will not be able to >>> commit or discard-changes. The solution is to use locks. >>> If the conclusion is that b/c of this partial-lock should not be >>> allowed on the candidate, maybe we should also disallow edit-config of >>> the candidate unless the global lock is set? >>> >> IMO, the conclusion is that partial-locking on the candidate >> works just as badly as no locking at all. > > Ok, so should we disallow both partial-lock and no-lock of candidate? > No. We do not mandate that locking be used or how it is used. > >> That does not >> lead to any logical deduction about global locking. >> That works on the candidate just fine. > > Yes, global lock on candidate works fine. > > > /martin > > Andy From andy@netconfcentral.com Tue Apr 14 07:37: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 8EB283A6AF0 for ; Tue, 14 Apr 2009 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.254, 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 o2ON4A0wJ14q for ; Tue, 14 Apr 2009 07:37:17 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id B609F3A68AB for ; Tue, 14 Apr 2009 07:37:17 -0700 (PDT) Received: (qmail 34206 invoked from network); 14 Apr 2009 14:38:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 14:38:28 -0000 X-YMail-OSG: DvlZGUoVM1mesgI4Ox.taQFvUraLA.bDfiN1ucX6AroL11Z9kxSpIYqJxUx6UGth1PLK4.3pSvPRKqLju7QrRosPUWmfdpJGCu6xLeTo13Qzo62_3hoKukm7U4qVqBwgq5FGrG74dcHRFZE8KNULjO3Usg2aap5naO_eUOtCVNWEbidCJtyUm_4G7ro4RXPNGgbpe.GKK.SlUJEQQfHysA3cqDVl.lk9UVRpI2H_09AnZ_1xf90jHm6uciMF2kgQAQMlfIxrAucEl7fLYqgwv9xQEBn_c4OYr62vgh03fhlX5RVVIqdKtpWZ6gtqUZYPVjq7ZVZe7KUPZw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E49FE3.2020803@netconfcentral.com> Date: Tue, 14 Apr 2009 07:38:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49E0CD84.3000108@netconfcentral.com> <20090414.140918.104946542.mbj@tail-f.com> In-Reply-To: <20090414.140918.104946542.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] ietf-netconf.yang 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, 14 Apr 2009 14:37:25 -0000 Martin Bjorklund wrote: > Hi Andy, > > Andy Bierman wrote: >> Here is a new version of the YANG module for >> the NETCONF protocol. The layers other than >> operations and content have been removed. >> A real hack of an extension has been added >> to deal with the element. >> >> I want to check that this is in the ballpark, >> before attempting to integrate the module >> into 4741-bis. > > I have a couple of comments: > > o You are using 'feature' to define capabilities. The only problem > I have with this is that according to the YANG spec, a server > will advertise its features as part of the capability uri: > > urn:ietf:params:xml:ns:netconf:base:1.0?features=candidate,xpath > > But that's not how it is supposed to be done in this case. So I > wonder if it's really such a good idea to use 'feature' for > this purpose. > Why assume this would be done? We can strip out all the if-feature stuff, and then YANG becomes just as bad as XSD at describing optional features. Why can't a YANG module capability URI for module=ietf-netconf?features=... be used in addition to the NETCONF base URI? > o You define all rpc-error stuff, but with the comment: > > // not actually used within this module > > Is the plan to remove this? (I think it should, since this is > part of the RPC layer). > I will remove it. Are we sure these data structures will never get reconstructed in any standard YANG data model, and these objects will never be needed in any sort of standard or vendor-specific monitoring extension module? > o I suggest we remove all 'CommonConfigSourceType', > 'RpcOperationSourceType' etc. and instead explicitly list each > source / target for each operation. I think this will be more > clear and less error-prone. > So the same 2 or 3 leafs are cut-and-pasted about a dozen times in the module? OK, but again, this seems just as bad as SMIv2, and worse than XSD. > For example, according to the YANG module, delete-config of > running is allowed (I know the text says otherwise). > > I think it would be fine to define one grouping per datastore, > and then use it in all operations. > > o Several 'mandatory true' statements are commented away - are > there any problems with having them there? > They are on containers, which are not allowed to have the mandatory-stmt. Most people find the ripple-up aspect of NP containers to be very confusing, especially when the mandatory 'bit' comes from objects derived from a uses-stmt. I have found that most people think mandatory-stmt is more understandable than P/NP containers. The comments are there to remind people that the NP container is mandatory, but they can be removed, since the uses-stmts are going away. (The reader can dive into the subtree and spot the mandatory true; statements.) > o In a comment, you write that 'bad-element' should not be QName, > as it is in the XSD. I disagree; I think it is clear that the > intention of 4741 is that bad-element is simply a QName, and if > that is not enough, then 'error-path' should be used. > This is a bug; The comment was only supposed to apply the the other buggy error-info elements, but they are getting removed anyway, so it does not matter. > > /martin > > > Andy From andy@netconfcentral.com Tue Apr 14 09:31: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 E0DFE3A6E35 for ; Tue, 14 Apr 2009 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, J_CHICKENPOX_74=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 fLyl0LEz+0IH for ; Tue, 14 Apr 2009 09:31:29 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 02B3D28C17B for ; Tue, 14 Apr 2009 09:31:19 -0700 (PDT) Received: from [68.142.194.243] by n10.bullet.mail.mud.yahoo.com with NNFMP; 14 Apr 2009 16:32:31 -0000 Received: from [68.142.201.248] by t1.bullet.mud.yahoo.com with NNFMP; 14 Apr 2009 16:32:31 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 14 Apr 2009 16:32:31 -0000 X-Yahoo-Newman-Id: 335229.15252.bm@omp409.mail.mud.yahoo.com Received: (qmail 42272 invoked from network); 14 Apr 2009 16:32:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 16:32:29 -0000 X-YMail-OSG: _o.KrvwVM1ng6SpN2IttmDvUbS3xk4Ufe7z.._Qk93NE1892jDi6FqJ0m4tFI3bL9GQw.R6VOa.HCCrN_esQJReTsnwL2g_76u3LeeZSP75_9wPhIwacLXN3VIBXlVSha8V86BOW7t7LtsOsFy_Hkm_hrabq.XcZwQsm5u61I93dK1iP8ffDOIXIch51sS6JhoQRIglK9t.6O_UaD7BOpWz7Hhd4g_PAnsXi4kQl6FujWi0GsEW06okoknjx307iJmC_iZpAd5tG9opi X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E4BA9C.7080307@netconfcentral.com> Date: Tue, 14 Apr 2009 09:32:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETCONF Content-Type: multipart/mixed; boundary="------------050707070807030501080705" Subject: [Netconf] ietf-netconf.yang (2) 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, 14 Apr 2009 16:31:31 -0000 This is a multi-part message in MIME format. --------------050707070807030501080705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is the updated version based on Martin's comments. IMO, the total lack of support in YANG for NETCONF capabilities is a mistake. It leaves a big hole in the tool automation chain, for a very basic feature of the NETCONF architecture. It forces simple boolean logic into description statements, where it must be read by every single implementor, the English text understood correctly, and then manually implemented correctly. This is not just some corner-case, because this module happens to be netconf.yang. The ietf-partial-lock data model is designed to utilize the :xpath capability, and is only defined in description statements. The ietf-netconf-state data model contains sections which are only relevant if :notifications is supported, or if :partial-lock is supported. Again, only defined in description statements. So, out of the 4 very first 'content layer' standard data models, (not counting netconf.yang) half of them need an 'if-capability' statement. That seems like a pretty solid use-case to me. Andy --------------050707070807030501080705 Content-Type: text/plain; name="ietf-netconf.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf-netconf.yang" module ietf-netconf { namespace "urn:ietf:params:xml:ns:netconf:base:1.0"; prefix nc; // for the uri data type import ietf-inet-types { prefix inet; } description "NETCONF Protocol * Simple Data Types * RPC methods "; reference "Translated from RFC 4741."; contact "TBD: WG contact info here"; revision 2009-04-14 { description "Initial version (2)"; } extension get-filter-element-attributes { description "If this extension is present within the an 'anyxml' statement named 'filter', which must be conceptually defined within the RPC input section for the 'get' and 'get-config' RPC operations, then the following unqualified XML attribute is supported within the 'filter' element, within a 'get' or 'get-config' protocol operation: type : optional attribute with allowed value strings 'subtree' and 'xpath'. If missing, the default value is 'subtree'. If the xpath feature is supported, then the following unqualified XML attribute is also supported: select: optional attribute containing a string representing an XPath expression. The 'type' attribute must be equal to 'xpath' if this attribute is present."; } // NETCONF Simple Types typedef SessionId { description "NETCONF Session Id"; type uint32 { range "1..max"; } } typedef SessionIdOrZero { description "NETCONF Session Id or Zero to indicate none"; type uint32; } typedef ErrorType { description "NETCONF Error Type"; type enumeration { enum transport; enum rpc; enum protocol; enum application; } } typedef ErrorTag { description "NETCONF Error Tag"; type enumeration { enum in-use; enum invalid-value; enum too-big; enum missing-attribute; enum bad-attribute; enum unknown-attribute; enum missing-element; enum bad-element; enum unknown-element; enum unknown-namespace; enum access-denied; enum lock-denied; enum resource-denied; enum rollback-failed; enum data-exists; enum data-missing; enum operation-not-supported; enum operation-failed; enum partial-operation; } } typedef ErrorSeverity { description "NETCONF Error Severity"; type enumeration { enum error; enum warning; } } typedef TestOptionType { description "NETCONF 'test-option' Element Content. This is extended with the test-only enumeration. The 'set' option has no real effect since the entire PDU is always validated before any of it is applied (always test-then-set)."; type enumeration { enum test-then-set; enum set; // enum test-only; !!!! not part of the standard yet } default "set"; } typedef ErrorOptionType { description "NETCONF 'error-option' Element Content"; type enumeration { enum stop-on-error; enum continue-on-error; enum rollback-on-error; } default "stop-on-error"; } typedef EditOperationType { description "NETCONF 'operation' Attribute Content"; type enumeration { enum merge; enum replace; enum create; enum delete; } default "merge"; } typedef DefaultOperationType { description "NETCONF 'default-operation' Element Content"; type enumeration { enum merge; enum replace; enum none; } default "merge"; } typedef ConfirmTimeoutType { description "NETCONF 'confirm-timeout' Element Content"; type uint32 { range "1..max"; } units "seconds"; default "600"; // 10 minutes } typedef ConfigURIType { type inet:uri; } // NETCONF Standard RPC Methods rpc get-config { description "Retrieve all or part of a specified configuration."; reference "RFC 4741, section 7.2"; input { container source { description "Particular configuration to retrieve."; choice config-source { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } anyxml filter { description "Subtree or Xpath filter to use."; nc:get-filter-element-attributes; } } output { container data { description "Copy of the source database subset which matched the filter criteria (if any)."; presence "An empty data container indicates that the request did not produce any results."; } } } rpc edit-config { description "The 'edit-config' operation loads all or part of a specified configuration to the specified target configuration. This operation allows the new configuration to be expressed in several ways, such as using a local file, a remote file, or inline. If the target configuration does not exist, it will be created. If a NETCONF peer supports the :url capability (Section 8.8), the element can appear instead of the parameter and should identify a local configuration file. The device analyzes the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced, as with the message. Instead, the target configuration is changed in accordance with the source's data and requested operations."; reference "RFC 4741, section 7.2"; input { container target { description "Particular configuration to edit."; choice config-target { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } leaf default-operation { description "Default operation to apply if not explicitly set."; type DefaultOperationType; } leaf test-option { description "Test option if validate capability supported. The 'validate' capability must be present to set this object to 'test-then-set'."; type TestOptionType; } leaf error-option { description "Error recovery option."; type ErrorOptionType; } choice edit-content { mandatory true; container config { description "Inline Config content: 'config' element."; } leaf url { description "Pointer to Config content: 'url' element."; type ConfigURIType; } } } } rpc copy-config { description "Create or replace an entire configuration datastore with the contents of another complete configuration datastore. If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed. If a NETCONF peer supports the :url capability (Section 8.8), the 'url' element can appear as the or parameter. Even if it advertises the :writable-running capability, a device may choose not to support the configuration datastore as the parameter of a operation. A device may choose not to support remote-to-remote copy operations, where both the and parameters use the element. If the source and target parameters identify the same URL or configuration datastore, an error MUST be returned with an error- tag containing invalid-value."; reference "RFC 4741, section 7.3"; input { container target { description "Particular configuration to copy to."; choice config-target { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } container source { description "Particular configuration to copy from."; choice config-source { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } } } rpc delete-config { description "Delete a configuration datastore. The 'running' configuration datastore cannot be deleted. If a NETCONF peer supports the :url capability (Section 8.8), the 'url' element can appear as the parameter."; reference "RFC 4741, section 7.4"; input { container target { description "Particular configuration to delete."; choice config-target { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } } } rpc lock { description "The lock operation allows the client to lock the configuration system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users. ..."; reference "RFC 4741, section 7.5"; input { container target { description "Particular configuration to lock"; choice config-target { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } } } rpc unlock { description "The unlock operation is used to release a configuration lock, previously obtained with the 'lock' operation. An unlock operation will not succeed if any of the following conditions are true: * the specified lock is not currently active * the session issuing the operation is not the same session that obtained the lock The server MUST respond with either an element or an 'rpc-error'."; reference "RFC 4741, section 7.6"; input { container target { description "Particular configuration to unlock."; choice config-target { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } } } } } rpc get { description "Retrieve running configuration and device state information."; reference "RFC 4741, section 7.7"; input { anyxml filter { description "This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is empty, all the device configuration and state information is returned. The filter element may optionally contain a 'type' attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value 'subtree' explicitly identifies this type of filtering. If the NETCONF peer supports the :xpath capability (Section 8.9), the value 'xpath' may be used to indicate that the select attribute of the filter element contains an XPath expression."; nc:get-filter-element-attributes; } } output { container data { description "Copy of the 'running' database subset which matched the filter criteria (if any)."; presence "An empty data container indicates that the request did not produce any results."; } } } rpc close-session { description "Request graceful termination of a NETCONF session. When a NETCONF server receives a request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a 'close-session' request will be ignored."; reference "RFC 4741, section 7.8"; } rpc kill-session { description "Force the termination of a NETCONF session. When a NETCONF entity receives a request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. If a NETCONF server receives a request while processing a confirmed commit (Section 8.4), it must restore the configuration to its state before the confirmed commit was issued. Otherwise, the operation does not roll back configuration or other device state modifications made by the entity holding the lock."; reference "RFC 4741, section 7.9"; input { leaf session-id { description "Particular session to kill."; type SessionId; mandatory true; } } } rpc commit { description "Only available if 'candidate' capability is supported. When a candidate configuration's content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration. To commit the candidate configuration as the device's new current configuration, use the operation. The 'commit' operation instructs the device to implement the configuration data contained in the candidate configuration. If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged. If the device does succeed in committing, the running configuration MUST be updated with the contents of the candidate configuration. If the system does not have the :candidate capability, the 'commit' operation is not available."; reference "RFC 4741, section 8.3.4.1"; input { leaf confirmed { description "Request a confirmed commit. Only available if 'confirmed-commit' capability is supported."; reference "RFC 4741, section 8.4.5.1"; type empty; } leaf confirm-timeout { description "Request a specific timeout period for a confirmed commit if 'confirmed-commit' capability supported."; reference "RFC 4741, section 8.4.5.1"; type ConfirmTimeoutType; } } } rpc discard-changes { description "Only available if 'candidate' capability is supported. If the client decides that the candidate configuration should not be committed, the 'discard-changes' operation can be used to revert the candidate configuration to the current running configuration. This operation discards any uncommitted changes by resetting the candidate configuration with the content of the running configuration."; reference "RFC 4741, section 8.3.4.2"; } rpc validate { description "Only available if 'validate' capability is supported. Validates the contents of the specified configuration."; reference "RFC 4741, section 8.6.4.1"; input { container source { description "Particular configuration to validate."; choice config-source { mandatory true; leaf candidate { description "Only available if 'candidate' capability supported."; type empty; } leaf running { type empty; } leaf startup { description "Only available if 'startup' capability supported."; type empty; } leaf url { description "URL pointing to config data. Only available if 'url' capability supported."; type ConfigURIType; } container config { description "Inline Config content: 'config' element."; } } } } } } --------------050707070807030501080705-- From mbj@tail-f.com Tue Apr 14 12:26: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 3EA4328C236 for ; Tue, 14 Apr 2009 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.133, 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 5KgCp5jDtciB for ; Tue, 14 Apr 2009 12:26: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 6DAB63A68A8 for ; Tue, 14 Apr 2009 12:25:36 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B5FEC616005; Tue, 14 Apr 2009 21:26:47 +0200 (CEST) Date: Tue, 14 Apr 2009 21:26:47 +0200 (CEST) Message-Id: <20090414.212647.79869804.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49E49FE3.2020803@netconfcentral.com> References: <49E0CD84.3000108@netconfcentral.com> <20090414.140918.104946542.mbj@tail-f.com> <49E49FE3.2020803@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] ietf-netconf.yang 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, 14 Apr 2009 19:26:06 -0000 Andy Bierman wrote: > > o You are using 'feature' to define capabilities. The only problem > > I have with this is that according to the YANG spec, a server > > will advertise its features as part of the capability uri: > > urn:ietf:params:xml:ns:netconf:base:1.0?features=candidate,xpath > > But that's not how it is supposed to be done in this case. So I > > wonder if it's really such a good idea to use 'feature' for > > this purpose. > > > > Why assume this would be done? > We can strip out all the if-feature stuff, and then > YANG becomes just as bad as XSD at describing optional > features. In YANG, one module is reported as one capability. When a "large" capability has minor "subcapabilities", features are used. If we could re-design the NETCONF module in YANG, we would probably use features for most of the current capabilities. But we can't do that. > Why can't a YANG module capability URI for > module=ietf-netconf?features=... > be used in addition to the NETCONF base URI? So a server would advertise: urn:...:netconf:base:1.0 urn:...:netconf:base:1.0?features=startup ? > > o You define all rpc-error stuff, but with the comment: > > // not actually used within this module > > Is the plan to remove this? (I think it should, since this is > > part of the RPC layer). > > > > I will remove it. > Are we sure these data structures will never get > reconstructed in any standard YANG data model, > and these objects will never be needed in any > sort of standard or vendor-specific monitoring extension module? No. But should we define them in XSD for the RPC layer definition and also in YANG because some model might need them? > > o I suggest we remove all 'CommonConfigSourceType', > > 'RpcOperationSourceType' etc. and instead explicitly list each > > source / target for each operation. I think this will be more > > clear and less error-prone. > > > > So the same 2 or 3 leafs are cut-and-pasted about a dozen times > in the module? OK, but again, this seems just as bad as SMIv2, > and worse than XSD. I would have suggested to do the same change in the XSD, if we kept it. I don't think it's a good idea to define a reusable structure, and use it in several places, and then in text describe which parts of this structure is not used. We should keep these groupings only if they are really reused. /martin From andy@netconfcentral.com Tue Apr 14 13:08: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 D3E583A6920 for ; Tue, 14 Apr 2009 13:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.201, 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 iFluXr8U4zKN for ; Tue, 14 Apr 2009 13:08:31 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 0059C3A6943 for ; Tue, 14 Apr 2009 13:08:30 -0700 (PDT) Received: (qmail 68561 invoked from network); 14 Apr 2009 20:09:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 20:09:42 -0000 X-YMail-OSG: Jl6P6tAVM1mj4oV2MVNuilBxF91iKrYwVP_uq5GL8IhZt7hegbGUL.1A2BfRrxeos.6PMbuzAv557XcCTKc0x_G4cnOZnL6rOoo1MLLzvqZt5Jl1Zm5g3hXQYsb2tGcGfw.A6cSdzUXk8mNK9TOB.WqwqWyyQMOErGyZwXWhYObVt3WSomUbmAjEovb2AKGCI3coqDv_i3bTXVnF0cS37mdQphVR5J5W3DkVmdrX2GPkQEL3gNqGJ3.tzmfN9iAqQrAQd2BULdC9a.NVt7GSCS_sKcfvY5QlET0P9U_mAPgPRH1w2w1zDgIN1IYpwVdEnuk4wKkTfspnug-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E4ED84.7070007@netconfcentral.com> Date: Tue, 14 Apr 2009 13:09:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49E0CD84.3000108@netconfcentral.com> <20090414.140918.104946542.mbj@tail-f.com> <49E49FE3.2020803@netconfcentral.com> <20090414.212647.79869804.mbj@tail-f.com> In-Reply-To: <20090414.212647.79869804.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] ietf-netconf.yang 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, 14 Apr 2009 20:08:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>> o You are using 'feature' to define capabilities. The only problem >>> I have with this is that according to the YANG spec, a server >>> will advertise its features as part of the capability uri: >>> urn:ietf:params:xml:ns:netconf:base:1.0?features=candidate,xpath >>> But that's not how it is supposed to be done in this case. So I >>> wonder if it's really such a good idea to use 'feature' for >>> this purpose. >>> >> Why assume this would be done? >> We can strip out all the if-feature stuff, and then >> YANG becomes just as bad as XSD at describing optional >> features. > > In YANG, one module is reported as one capability. When a "large" > capability has minor "subcapabilities", features are used. > > If we could re-design the NETCONF module in YANG, we would probably > use features for most of the current capabilities. But we can't do > that. > Well, why wasn't the partial-lock or netconf-state data models does with features instead of capabilities? We would not need if-capability if people used if-feature correctly, and left capabilities for *protocol* features only. >> Why can't a YANG module capability URI for >> module=ietf-netconf?features=... >> be used in addition to the NETCONF base URI? > > So a server would advertise: > > urn:...:netconf:base:1.0 > urn:...:netconf:base:1.0?features=startup > > ? > No -- I think you are right. I think the 2 data models in progress should be changed to use features instead of just description statements to define the optional functionality. >>> o You define all rpc-error stuff, but with the comment: >>> // not actually used within this module >>> Is the plan to remove this? (I think it should, since this is >>> part of the RPC layer). >>> >> I will remove it. >> Are we sure these data structures will never get >> reconstructed in any standard YANG data model, >> and these objects will never be needed in any >> sort of standard or vendor-specific monitoring extension module? > > No. But should we define them in XSD for the RPC layer definition > and also in YANG because some model might need them? > >>> o I suggest we remove all 'CommonConfigSourceType', >>> 'RpcOperationSourceType' etc. and instead explicitly list each >>> source / target for each operation. I think this will be more >>> clear and less error-prone. >>> >> So the same 2 or 3 leafs are cut-and-pasted about a dozen times >> in the module? OK, but again, this seems just as bad as SMIv2, >> and worse than XSD. > > I would have suggested to do the same change in the XSD, if we kept > it. > > I don't think it's a good idea to define a reusable structure, and use > it in several places, and then in text describe which parts of this > structure is not used. > > We should keep these groupings only if they are really reused. > I agree that they should be removed. If they ever get added in a standard YANG module, we will deal with it then. Only the simple typedefs are left. > > /martin > > Andy From mbj@tail-f.com Tue Apr 14 13:14: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 B2D5228C172 for ; Tue, 14 Apr 2009 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.131, 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 JWu0XK8a+Sxj for ; Tue, 14 Apr 2009 13:14:17 -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 F326028C17A for ; Tue, 14 Apr 2009 13:14:16 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A5952616005; Tue, 14 Apr 2009 22:15:27 +0200 (CEST) Date: Tue, 14 Apr 2009 22:15:27 +0200 (CEST) Message-Id: <20090414.221527.125803819.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49E4ED84.7070007@netconfcentral.com> References: <49E49FE3.2020803@netconfcentral.com> <20090414.212647.79869804.mbj@tail-f.com> <49E4ED84.7070007@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] ietf-netconf.yang 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, 14 Apr 2009 20:14:17 -0000 Andy Bierman wrote: > Well, why wasn't the partial-lock or netconf-state data models > does with features instead of capabilities? We would not > need if-capability if people used if-feature correctly, > and left capabilities for *protocol* features only. I would be more than happy to use features in these two data models. The only problem is that we a normative XSD and there is no such concept there. Specificaly, the features=... part of the URI will have to be described in text. /martin From andy@netconfcentral.com Tue Apr 14 13:43: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 CCD263A699A for ; Tue, 14 Apr 2009 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.189, 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 MrvvnpGZgPse for ; Tue, 14 Apr 2009 13:43:56 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 27C803A6860 for ; Tue, 14 Apr 2009 13:43:56 -0700 (PDT) Received: (qmail 60013 invoked from network); 14 Apr 2009 20:45:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 20:45:07 -0000 X-YMail-OSG: 090pvmkVM1lOBLBtSq4vt1mNTnWfAL9tMHCaiQRpjogLtihfk92m8wnJN0wdTXd1uvLNhnJAwtXkspnQITfYWRwNwqwyvTU1A4DmoNQOdKUrQNPhRf6qsJ.4c3ELQD9NiA3NHIjzp6Hc7HXUArZaURgQd1Ln6Jeix3EFtj3sYq2bL446TBLSqTsFCKaDCVeiSbj6npM5aoksZ0_JrrzFUS4cnGNuouBwDPUBa4QjzdtvX.FYBmnpzkCwa61_uk9fCnocpxj.gW_T8KI0d2KRTii4P7Fn6FBcZRwQUP4MP1ILTcQx27njc9JsKCJ0Vy9PKxuH70EBpkEzKg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E4F5D1.7040400@netconfcentral.com> Date: Tue, 14 Apr 2009 13:45:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <49E49FE3.2020803@netconfcentral.com> <20090414.212647.79869804.mbj@tail-f.com> <49E4ED84.7070007@netconfcentral.com> <20090414.221527.125803819.mbj@tail-f.com> In-Reply-To: <20090414.221527.125803819.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] ietf-netconf.yang 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, 14 Apr 2009 20:43:56 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Well, why wasn't the partial-lock or netconf-state data models >> does with features instead of capabilities? We would not >> need if-capability if people used if-feature correctly, >> and left capabilities for *protocol* features only. > > I would be more than happy to use features in these two data models. > The only problem is that we a normative XSD and there is no such > concept there. Specificaly, the features=... part of the URI will > have to be described in text. > Aren't we going to have this problem for all NETCONF data models? Or only the early YANG data models will ignore if-feature, because a capability URI has to be used instead -- to support XSD. Will these data models be updated after the YANG RFC is published? > > /martin > > Andy From andy@netconfcentral.com Tue Apr 14 14:17: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 1B12A28C172 for ; Tue, 14 Apr 2009 14:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 miGutZdz+rhS for ; Tue, 14 Apr 2009 14:17:23 -0700 (PDT) Received: from n25.bullet.mail.mud.yahoo.com (n25.bullet.mail.mud.yahoo.com [68.142.206.220]) by core3.amsl.com (Postfix) with SMTP id 2B0423A6B0D for ; Tue, 14 Apr 2009 14:17:23 -0700 (PDT) Received: from [68.142.200.227] by n25.bullet.mail.mud.yahoo.com with NNFMP; 14 Apr 2009 21:18:34 -0000 Received: from [68.142.201.73] by t8.bullet.mud.yahoo.com with NNFMP; 14 Apr 2009 21:18:34 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 14 Apr 2009 21:18:34 -0000 X-Yahoo-Newman-Id: 815290.55814.bm@omp425.mail.mud.yahoo.com Received: (qmail 48574 invoked from network); 14 Apr 2009 21:18:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2009 21:18:33 -0000 X-YMail-OSG: FrEmE_AVM1k7aTNkwYjoKv0LAwHRpVzflyv22G2ZgBlLZjSiqFJ0d78Qsu3CZaVnjjGuev0GA.H22YNzK7BNrRUeWHF7WKxwcqCLTbkSookFVjlXRrAZhX36rhVqeubgOJ7ktsrC65VU8Ul9elrNASEjHpAJgpYL0h5WaM..Ldz9hZMAu2dPAxy8dhZWKbqVomYYFUyuYfinfCEWHYCoFs2X.V69.h7gilSnAOGUP5zAH0KLaWczg4Kky7_TVHCyUyV5vK6ZBBt7P8nr X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E4FDA7.7010408@netconfcentral.com> Date: Tue, 14 Apr 2009 14:18:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock and the candidate config 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, 14 Apr 2009 21:17:24 -0000 WashamFan wrote: >> > IMO, the conclusion is that partial-locking on the candidate >> > works just as badly as no locking at all. >> >> Ok, so should we disallow both partial-lock and no-lock of candidate? >> > > Or we just state clearly how difficult recovery would be when partial-lock and > no-lock apply to candidate, and recommend global lock is always used to > candidate? > I have a solution proposal, but it requires that we plan out some NETCONF architecture, build out some core infrastructure, and horrible stuff like that. Way back when I realized partial-lock and config don't get along very well, I proposed a "group lock". This of course assumes there is some /groups data structure somewhere, to assign user names to groups. That sure would be useful for access control, though. After that (there's more?!) the global operation needs to be augmented to allow a parameter. Then, any session associated with a user name that belongs to the group that owns the lock can issue edit-config, commit, discard-changes, unlock, partial-lock, and partial-unlock. The sessions can use partial-lock if they want, but the global lock is needed to keep out all the sessions that are not part of the 'co-operating managers' in this use-case. E.g., grp:admin IMO, this is a lot simpler than explicit XPath locks, and it requires hardly any YANG to implement: module groups { namespace foo; prefix grp; ... typedef NetconfGroup { description "A NETCONF group identifier."; type identityref { base netconfGroups; } } identity netconfGroups { description "NETCONF groups base"; } identity admin { description "example group definition"; base netconfGroups; } container groups { presence "If empty, then no groups are configured."; list group { description "One NETCONF group definition."; key groupId; leaf groupId { description "Identity naming this entry."; type NetconfGroup; } leaf-list userName { description "User name string belonging to this group"; type string { length "1..max"; // may want restrictions } } } } } NETCONF access control and co-operative locking could use the same data structures, assuring that alignment and simplicity are maintained. > washam > >> > That does not >> > lead to any logical deduction about global locking. >> > That works on the candidate just fine. >> >> Yes, global lock on candidate works fine. >> >> >> /martin >> > > Andy From phil@juniper.net Tue Apr 14 20:13:28 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 2AB713A6E69 for ; Tue, 14 Apr 2009 20:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkrxgFMMpF1m for ; Tue, 14 Apr 2009 20:13:27 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id AD38F3A6BA0 for ; Tue, 14 Apr 2009 20:13:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSeVRFGRwiiIV/7P4LnLN3ZNdfRb1w8qr@postini.com; Tue, 14 Apr 2009 20:14:39 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; Tue, 14 Apr 2009 20:09:43 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 20:09:43 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 20:09:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 20:09:42 -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 n3F39fM08139; Tue, 14 Apr 2009 20:09:41 -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 n3F32HZN062064; Wed, 15 Apr 2009 03:02:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904150302.n3F32HZN062064@idle.juniper.net> To: WashamFan In-Reply-To: Date: Tue, 14 Apr 2009 23:02:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Apr 2009 03:09:42.0397 (UTC) FILETIME=[9F0D32D0:01C9BD77] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] partial-lock and the candidate config 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, 15 Apr 2009 03:13:28 -0000 WashamFan writes: >Yep. That is where deadlock happens, and the reason is >absence of partial-[op], IMO. candidate datastore is mostly >a one-session-at-a-time basis. Even for writable-running, partial locks are problematic. The assumption seems to be that an application will grab a lock for the length of the application's lifetime, not a short-term more atomic lifespan. This means that simple tasks like config archival are not possible, since an archival app can't grab a lock on the entire config if a long-standing partial lock exists. Without a lock, the database can continue to change under a reader, so any archive would not be guaranteed to be consistent. The same problem exists (with more serious consequences) if two apps lock different parts of the config on a box that has distinct-startup, where either app doing a copy-config from running to startup would never be sure that the config isn't being changed. Thanks, Phil From andy@netconfcentral.com Tue Apr 14 23:26: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 0F51F3A6859 for ; Tue, 14 Apr 2009 23:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.158, 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 XQ6V55zCK2F9 for ; Tue, 14 Apr 2009 23:26:05 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id A19CA28C0D6 for ; Tue, 14 Apr 2009 23:25:58 -0700 (PDT) Received: (qmail 85980 invoked from network); 15 Apr 2009 06:27:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 15 Apr 2009 06:27:10 -0000 X-YMail-OSG: o3OGMyoVM1kD2IRuwk6dx93rU9Gwmfsy9mB9fuTSbq8v55aaCZSu3TJorqlKViDdGhK_jYl6a_jmxNwQDNwN36jCGKmVkPLASbza2kYRX2bwkPQIGyqk5Ln5RG35tl4EH9OhLxF2_c7t4Flw6jV1gjmEZ9M5WF.fa5KHUH3b1ZixXdR8___8OIe4ZTXCY4nhK3nye6n.mXTK5cfhXzWMm8LynCDTK71ebGx3OjAtrfADUMN2HB7lSklv_I.u5ZHsQV8mELIDF2dQuCBp X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E57E3B.8010409@netconfcentral.com> Date: Tue, 14 Apr 2009 23:27:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phil Shafer References: <200904150302.n3F32HZN062064@idle.juniper.net> In-Reply-To: <200904150302.n3F32HZN062064@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] partial-lock and the candidate config 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, 15 Apr 2009 06:26:06 -0000 Phil Shafer wrote: > WashamFan writes: >> Yep. That is where deadlock happens, and the reason is >> absence of partial-[op], IMO. candidate datastore is mostly >> a one-session-at-a-time basis. > > Even for writable-running, partial locks are problematic. The > assumption seems to be that an application will grab a lock for the > length of the application's lifetime, not a short-term more atomic > lifespan. > > This means that simple tasks like config archival are not possible, > since an archival app can't grab a lock on the entire config if a > long-standing partial lock exists. Without a lock, the database > can continue to change under a reader, so any archive would not be > guaranteed to be consistent. > > The same problem exists (with more serious consequences) if two > apps lock different parts of the config on a box that has > distinct-startup, where either app doing a copy-config from running > to startup would never be sure that the config isn't being changed. > But at least this partial/global lock overlap is controllable by the operator. 'lock time' is just another resource to manage, like bandwidth. My concern is 'transaction framing'. With the candidate config, there is no 'lock, edit, commit or discard' transaction-like procedure for partial-lock, like there is for global lock. It's like trying to take a photo of your family in a crowded public square. No matter how hard you try, there are all these strangers (not paying attention to you) walking through your shot. Doesn't bother them at all, but you never get to take your photo. (If not using the partial-lock at all produces the same results as if partial-locking is used correctly, then the partial lock doesn't actually work.) > Thanks, > Phil > > Andy From Washam.Fan@huaweisymantec.com Wed Apr 15 02:36: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 620023A685E for ; Wed, 15 Apr 2009 02:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 cNxPZLV1uzxa for ; Wed, 15 Apr 2009 02:36:06 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id E5F223A6A67 for ; Wed, 15 Apr 2009 02:35:46 -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 <0KI400AAPYPATZ90@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 15 Apr 2009 17:36: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 <0KI4006OJYP86D00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 15 Apr 2009 17:36:46 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 15 Apr 2009 17:36:44 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Wed, 15 Apr 2009 17:36:44 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49E4FDA7.7010408@netconfcentral.com> References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> <49E4FDA7.7010408@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock and the candidate config 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, 15 Apr 2009 09:36:07 -0000 > I have a solution proposal, but it requires that we > plan out some NETCONF architecture, build out > some core infrastructure, and horrible stuff > like that. > > Way back when I realized partial-lock and config > don't get along very well, I proposed a "group lock". > This of course assumes there is some /groups data structure > somewhere, to assign user names to groups. That sure would > be useful for access control, though. > > After that (there's more?!) the global operation > needs to be augmented to allow a parameter. > Then, any session associated with a user name that belongs to > the group that owns the lock can issue edit-config, > commit, discard-changes, unlock, partial-lock, and > partial-unlock. The sessions can use partial-lock > if they want, but the global lock is needed to keep > out all the sessions that are not part of > the 'co-operating managers' in this use-case. > > E.g., > > > > > grp:admin > > > > > > > IMO, this is a lot simpler than explicit XPath locks, > and it requires hardly any YANG to implement: > > module groups { > > namespace foo; > prefix grp; > ... > > typedef NetconfGroup { > description "A NETCONF group identifier."; > type identityref { > base netconfGroups; > } > } > > identity netconfGroups { > description "NETCONF groups base"; > } > > identity admin { > description "example group definition"; > base netconfGroups; > } > > container groups { > presence "If empty, then no groups are configured."; > > list group { > description "One NETCONF group definition."; > key groupId; > leaf groupId { > description "Identity naming this entry."; > type NetconfGroup; > } > leaf-list userName { > description > "User name string belonging to this group"; > type string { > length "1..max"; // may want restrictions > } > } > } > } > } > > > NETCONF access control and co-operative locking could use > the same data structures, assuring that alignment and > simplicity are maintained. Users in a group could share a lock, right? And all the users are expected to be cooperating with each other to achieve a final goal, right? But there is no nested lock to constraint the behavior of a single user within the group, so how to cope with edits issued by different users simultaneously, are we introducing an additional mechainsm to ensure users in a group will edit in a reasonable order? It seems not enough convincing to me. washam From mbj@tail-f.com Wed Apr 15 05:11: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 EFF403A6B12 for ; Wed, 15 Apr 2009 05:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.062, 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 5VAmY0KrIQpS for ; Wed, 15 Apr 2009 05:11:07 -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 C662A3A6B18 for ; Wed, 15 Apr 2009 05:11:06 -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 C3BDB616004; Wed, 15 Apr 2009 14:12:17 +0200 (CEST) Date: Wed, 15 Apr 2009 14:12:17 +0200 (CEST) Message-Id: <20090415.141217.59541259.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <49E44535.8000704@ericsson.com> References: <20090407170549.GA29864@elstar.local> <20090414.081508.215323178.mbj@tail-f.com> <49E44535.8000704@ericsson.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: Wed, 15 Apr 2009 12:11:08 -0000 Balazs Lengyel wrote: > > > 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. > > Agreed. > > > >> 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. > > > Sound nice to me. So is the following text what we are looking for: > > 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 From andy@netconfcentral.com Wed Apr 15 07:39: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 C6E4328C20D for ; Wed, 15 Apr 2009 07:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 di9ZniM1HfOp for ; Wed, 15 Apr 2009 07:39:05 -0700 (PDT) Received: from n11a.bullet.mail.mud.yahoo.com (n11a.bullet.mail.mud.yahoo.com [209.191.125.176]) by core3.amsl.com (Postfix) with SMTP id E4D3428C20B for ; Wed, 15 Apr 2009 07:39:04 -0700 (PDT) Received: from [68.142.194.244] by n11.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2009 14:40:17 -0000 Received: from [68.142.201.250] by t2.bullet.mud.yahoo.com with NNFMP; 15 Apr 2009 14:40:17 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 15 Apr 2009 14:40:16 -0000 X-Yahoo-Newman-Id: 980530.50380.bm@omp411.mail.mud.yahoo.com Received: (qmail 46335 invoked from network); 15 Apr 2009 14:40:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 15 Apr 2009 14:40:16 -0000 X-YMail-OSG: tujW8nEVM1kBvN_Ua.kcm44aDBvuhDeJP2CKSXllGrIeFefSFkjyNbN.hAS4oWbkMWMYz2HxW6au8f2YI.9ug7HJPG7t7M6sR5_s3vNC_88NFrptwdS9BXrAldKTZy2D1HjsP4SOfU.2OBpyzpqtUEpyENUORNSGGNPl87wa.AcmnltLNf0Cptf8Fuqlnu7Lw4shAXlhAotPc.HnzBFxb66y8DvGOim255Bbir17HeMWXUivz1o2mU6mgeqO7h66519f.Gmh72IBiXwn X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E5F1CE.4010505@netconfcentral.com> Date: Wed, 15 Apr 2009 07:40:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: <20090414.103710.226431161.mbj@tail-f.com> <49E45196.4060808@netconfcentral.com> <20090414.110845.120951722.mbj@tail-f.com> <49E4FDA7.7010408@netconfcentral.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] partial-lock and the candidate config 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, 15 Apr 2009 14:39:05 -0000 WashamFan wrote: >> I have a solution proposal, but it requires that we >> plan out some NETCONF architecture, build out >> some core infrastructure, and horrible stuff >> like that. >> >> Way back when I realized partial-lock and config >> don't get along very well, I proposed a "group lock". >> This of course assumes there is some /groups data structure >> somewhere, to assign user names to groups. That sure would >> be useful for access control, though. >> >> After that (there's more?!) the global operation >> needs to be augmented to allow a parameter. >> Then, any session associated with a user name that belongs to >> the group that owns the lock can issue edit-config, >> commit, discard-changes, unlock, partial-lock, and >> partial-unlock. The sessions can use partial-lock >> if they want, but the global lock is needed to keep >> out all the sessions that are not part of >> the 'co-operating managers' in this use-case. >> >> E.g., >> >> >> >> >> grp:admin >> >> >> >> >> >> >> IMO, this is a lot simpler than explicit XPath locks, >> and it requires hardly any YANG to implement: >> >> module groups { >> >> namespace foo; >> prefix grp; >> ... >> >> typedef NetconfGroup { >> description "A NETCONF group identifier."; >> type identityref { >> base netconfGroups; >> } >> } >> >> identity netconfGroups { >> description "NETCONF groups base"; >> } >> >> identity admin { >> description "example group definition"; >> base netconfGroups; >> } >> >> container groups { >> presence "If empty, then no groups are configured."; >> >> list group { >> description "One NETCONF group definition."; >> key groupId; >> leaf groupId { >> description "Identity naming this entry."; >> type NetconfGroup; >> } >> leaf-list userName { >> description >> "User name string belonging to this group"; >> type string { >> length "1..max"; // may want restrictions >> } >> } >> } >> } >> } >> >> >> NETCONF access control and co-operative locking could use >> the same data structures, assuring that alignment and >> simplicity are maintained. > > Users in a group could share a lock, right? And all the users are > expected to be cooperating with each other to achieve a final goal, > right? But there is no nested lock to constraint the behavior of a single > user within the group, so how to cope with edits issued by different > users simultaneously, are we introducing an additional mechainsm to > ensure users in a group will edit in a reasonable order? It seems not > enough convincing to me. > The co-operating managers using the candidate config could use partial-locking within the global group lock if they wanted. IMO, this is mostly pointless, since the entire candidate is committed at once, so if the co-operating managers step on each other, there is a bug in their code. The agent does not have to ensure anything here wrt/ order or keeping the managers from making mistakes. They are using the scratchpad database. It can be inspected, validated, and altered before the commit. Locking is available for managers to use, misuse, or ignore. Responsibility for coordinated database edits lies entirely with the application(s), not the agent. > washam > > > Andy From Washam.Fan@huaweisymantec.com Wed Apr 15 19:49: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 DD1743A6A09 for ; Wed, 15 Apr 2009 19:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.714, 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 qiuq0Sk-sWmH for ; Wed, 15 Apr 2009 19:49:08 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 891463A6BE2 for ; Wed, 15 Apr 2009 19:49:08 -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 <0KI6002X6AJSMY60@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Thu, 16 Apr 2009 10:50:18 +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 <0KI600M1HAJQYM00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 16 Apr 2009 10:50:16 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 16 Apr 2009 10:50:14 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Thu, 16 Apr 2009 10:50:14 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49E5F1CE.4010505@netconfcentral.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> Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock and the candidate config 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, 16 Apr 2009 02:49:09 -0000 Hi, > WashamFan wrote: > >> I have a solution proposal, but it requires that we > >> plan out some NETCONF architecture, build out > >> some core infrastructure, and horrible stuff > >> like that. > >> > >> Way back when I realized partial-lock and config > >> don't get along very well, I proposed a "group lock". > >> This of course assumes there is some /groups data structure > >> somewhere, to assign user names to groups. That sure would > >> be useful for access control, though. > >> > >> After that (there's more?!) the global operation > >> needs to be augmented to allow a parameter. > >> Then, any session associated with a user name that belongs to > >> the group that owns the lock can issue edit-config, > >> commit, discard-changes, unlock, partial-lock, and > >> partial-unlock. The sessions can use partial-lock > >> if they want, but the global lock is needed to keep > >> out all the sessions that are not part of > >> the 'co-operating managers' in this use-case. > >> > >> E.g., > >> > >> > >> > >> > >> grp:admin > >> > >> > >> > >> > >> > >> > >> IMO, this is a lot simpler than explicit XPath locks, > >> and it requires hardly any YANG to implement: > >> > >> module groups { > >> > >> namespace foo; > >> prefix grp; > >> ... > >> > >> typedef NetconfGroup { > >> description "A NETCONF group identifier."; > >> type identityref { > >> base netconfGroups; > >> } > >> } > >> > >> identity netconfGroups { > >> description "NETCONF groups base"; > >> } > >> > >> identity admin { > >> description "example group definition"; > >> base netconfGroups; > >> } > >> > >> container groups { > >> presence "If empty, then no groups are configured."; > >> > >> list group { > >> description "One NETCONF group definition."; > >> key groupId; > >> leaf groupId { > >> description "Identity naming this entry."; > >> type NetconfGroup; > >> } > >> leaf-list userName { > >> description > >> "User name string belonging to this group"; > >> type string { > >> length "1..max"; // may want restrictions > >> } > >> } > >> } > >> } > >> } > >> > >> > >> NETCONF access control and co-operative locking could use > >> the same data structures, assuring that alignment and > >> simplicity are maintained. > > > > Users in a group could share a lock, right? And all the users are > > expected to be cooperating with each other to achieve a final goal, > > right? But there is no nested lock to constraint the behavior of a > single > > user within the group, so how to cope with edits issued by different > > users simultaneously, are we introducing an additional mechainsm to > > ensure users in a group will edit in a reasonable order? It seems not > > enough convincing to me. > > > > The co-operating managers using the candidate config could > use partial-locking within the global group lock if they wanted. > IMO, this is mostly pointless, since the entire candidate > is committed at once, so if the co-operating managers step > on each other, there is a bug in their code. OK. A partial lock operation MUST fail if any session owns the global lock ( I assume global group lock is still a global lock). So how to use partial-locking within the global group lock according to current text? lock is to pretect one session from intervention of another one during a (short) period of time. If multiple sessions share a global group lock at the same time (even partial lock is allowed), difficult recovery is still there. Some issues are unclear about the proposal, such as, how to define a group? Are all users within a group has the same or different privilege? Are you also introduing the concept of 'role' versus 'group'? who to grab a group lock, any user or specific one within the group? Who to release a group lock, any user or the one who locked before? But, maybe, there may be a draft about it some day. so far, we see benefits from 1) applying lock to a single session. And you see benifits from applying lock to 2) multiple users with multiple sessions. Anyone see benefits from 3) applying lock to a single user with multiple sessions? Maybe 3) is a special case of 2) ;) washam > The agent does not have to ensure anything here wrt/ > order or keeping the managers from making mistakes. > They are using the scratchpad database. It can be > inspected, validated, and altered before the commit. > > Locking is available for managers to use, misuse, or ignore. > Responsibility for coordinated database edits lies entirely > with the application(s), not the agent. > > > washam > > > > > > > > Andy > > > > From andy@netconfcentral.com Wed Apr 15 20:09: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 D4E4C3A6B91 for ; Wed, 15 Apr 2009 20:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.120, 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 Z0Tbn+pAKEZ3 for ; Wed, 15 Apr 2009 20:09:50 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id EA9723A679F for ; Wed, 15 Apr 2009 20:09:49 -0700 (PDT) Received: (qmail 37524 invoked from network); 16 Apr 2009 03:11:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.137.236 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 16 Apr 2009 03:11:01 -0000 X-YMail-OSG: nFHjsWAVM1nwzW6KPe1lQ3UePmuAZLCl3kWjuJdL_5FVzjIv4SrtFT_q_xVx0KYpqmvlPHf7gu_FpGTjO9VOeGXTa865j4z90NIXz4oF_IUjdo8ZWluOl5_wa.q2zN3psXcn9J5AHzWzlDrrRHVFjWxR5gDgWE6gmCBQFfaAERwe6t.PEtuwbJ.6fzV8o11UcmHiDugWBkWbdqzMTwsmSjZqT5j2TO4I36Mf.jHIM5Mwu9dh86CrEigh9UT3RyVnFGd7f3kE3b4rUF3P X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E6A1C1.9040309@netconfcentral.com> Date: Wed, 15 Apr 2009 20:10:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock and the candidate config 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, 16 Apr 2009 03:09:50 -0000 WashamFan wrote: > Hi, > >> WashamFan wrote: >> >> I have a solution proposal, but it requires that we >> >> plan out some NETCONF architecture, build out >> >> some core infrastructure, and horrible stuff >> >> like that. >> >> >> >> Way back when I realized partial-lock and config >> >> don't get along very well, I proposed a "group lock". >> >> This of course assumes there is some /groups data structure >> >> somewhere, to assign user names to groups. That sure would >> >> be useful for access control, though. >> >> >> >> After that (there's more?!) the global operation >> >> needs to be augmented to allow a parameter. >> >> Then, any session associated with a user name that belongs to >> >> the group that owns the lock can issue edit-config, >> >> commit, discard-changes, unlock, partial-lock, and >> >> partial-unlock. The sessions can use partial-lock >> >> if they want, but the global lock is needed to keep >> >> out all the sessions that are not part of >> >> the 'co-operating managers' in this use-case. >> >> >> >> E.g., >> >> >> >> >> >> >> >> >> >> grp:admin >> >> >> >> >> >> >> >> >> >> >> >> >> >> IMO, this is a lot simpler than explicit XPath locks, >> >> and it requires hardly any YANG to implement: >> >> >> >> module groups { >> >> >> >> namespace foo; >> >> prefix grp; >> >> ... >> >> >> >> typedef NetconfGroup { >> >> description "A NETCONF group identifier."; >> >> type identityref { >> >> base netconfGroups; >> >> } >> >> } >> >> >> >> identity netconfGroups { >> >> description "NETCONF groups base"; >> >> } >> >> >> >> identity admin { >> >> description "example group definition"; >> >> base netconfGroups; >> >> } >> >> >> >> container groups { >> >> presence "If empty, then no groups are configured."; >> >> >> >> list group { >> >> description "One NETCONF group definition."; >> >> key groupId; >> >> leaf groupId { >> >> description "Identity naming this entry."; >> >> type NetconfGroup; >> >> } >> >> leaf-list userName { >> >> description >> >> "User name string belonging to this group"; >> >> type string { >> >> length "1..max"; // may want restrictions >> >> } >> >> } >> >> } >> >> } >> >> } >> >> >> >> >> >> NETCONF access control and co-operative locking could use >> >> the same data structures, assuring that alignment and >> >> simplicity are maintained. >> > >> > Users in a group could share a lock, right? And all the users are >> > expected to be cooperating with each other to achieve a final goal, >> > right? But there is no nested lock to constraint the behavior of a >> single >> > user within the group, so how to cope with edits issued by different >> > users simultaneously, are we introducing an additional mechainsm to >> > ensure users in a group will edit in a reasonable order? It seems not >> > enough convincing to me. >> > >> >> The co-operating managers using the candidate config could >> use partial-locking within the global group lock if they wanted. >> IMO, this is mostly pointless, since the entire candidate >> is committed at once, so if the co-operating managers step >> on each other, there is a bug in their code. > > OK. A partial lock operation MUST fail if any session owns the > global lock ( I assume global group lock is still a global lock). So > how to use partial-locking within the global group lock according > to current text? > OK -- then I wouldn't change that, since using a partial-lock within a shared global lock isn't very useful anyway. > lock is to pretect one session from intervention of another one > during a (short) period of time. If multiple sessions share a global > group lock at the same time (even partial lock is allowed), difficult > recovery is still there. > Why? This assumes some problems with access-control? If not, then discard-changes is the recovery mechanism, as usual. > Some issues are unclear about the proposal, such as, > how to define a group? with , using the YANG model above. e.g.: grp:admin fred barney acme:acme-admin fred wilma betty > Are all users within a group has the same or different privilege? that's an out-of-scope access control question. > Are you also introduing the concept of 'role' versus 'group'? no -- I don't actually see the word 'role' anywhere. > who to grab a group lock, any user or specific one within the group? anyone -- good point: it is an error to request a group lock if your user name is not in the specified group. It is totally out of scope how user names get discovered from the transport layer for each session. > Who to release a group lock, any user or the one who locked before? > But, maybe, there may be a draft about it some day. > anyone in the group can release the lock. maybe a draft someday. I am more interested in getting access control, a system group, an interfaces table, and content like that first. > so far, we see benefits from 1) applying lock to a single session. And > you see benifits from applying lock to 2) multiple users with multiple > sessions. Anyone see benefits from 3) applying lock to a single user > with multiple sessions? Maybe 3) is a special case of 2) ;) > > washam > Andy From Washam.Fan@huaweisymantec.com Wed Apr 15 23:17: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 3EBFF3A682A for ; Wed, 15 Apr 2009 23:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=-0.363, 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 EYNdvIkOWBbr for ; Wed, 15 Apr 2009 23:17:06 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 5BF873A67B4 for ; Wed, 15 Apr 2009 23:17:06 -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 <0KI6008BXK64WC80@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 16 Apr 2009 14:18: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 <0KI600LG0K62ZF00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 16 Apr 2009 14:18:04 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 16 Apr 2009 14:18:02 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Thu, 16 Apr 2009 14:18:02 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49E6A1C1.9040309@netconfcentral.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> Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock and the candidate config 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, 16 Apr 2009 06:17:07 -0000 > > lock is to pretect one session from intervention of another one > > during a (short) period of time. If multiple sessions share a global > > group lock at the same time (even partial lock is allowed), difficult > > recovery is still there. > > > > Why? > This assumes some problems with access-control? > If not, then discard-changes is the recovery mechanism, as usual. > > > Are all users within a group has the same or different privilege? > > that's an out-of-scope access control question. Imagine session A with only access right to /foo and session B with only access right to /bar are in the same group. session A has not enough authority to discard 'undone' changes left by session B. That is why I ask are all users within a group has the same privilege, and say difficult recovery is still there. When a single session owns a global lock, it can always discard-changes made by itself, but when a group of sessions share a global lock, difficult recovery arise again. washam From andy@netconfcentral.com Sun Apr 19 09:12: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 CEDBB3A683E for ; Sun, 19 Apr 2009 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 LG04OWKX+sgb for ; Sun, 19 Apr 2009 09:12:01 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id ED98D3A6B76 for ; Sun, 19 Apr 2009 09:12:00 -0700 (PDT) Received: from [209.191.108.97] by n14.bullet.mail.mud.yahoo.com with NNFMP; 19 Apr 2009 16:13:16 -0000 Received: from [68.142.201.251] by t4.bullet.mud.yahoo.com with NNFMP; 19 Apr 2009 16:13:16 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 19 Apr 2009 16:13:16 -0000 X-Yahoo-Newman-Id: 42249.2672.bm@omp412.mail.mud.yahoo.com Received: (qmail 46979 invoked from network); 19 Apr 2009 16:13:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.188 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 19 Apr 2009 16:13:14 -0000 X-YMail-OSG: .wfy.r8VM1n5jVpsIEJ.v1A0ySXLDdKj3nf8I2IZtvXRxfxUWYhDAjTbt_KkwIxBHdfQ4pU5ElKcuQcA.st.0gCvso4ZEjhkz9sfwUld134_jmT6Z1Y64r1vJgCFmwGmXAPQ3X21XcX7apeMwp8PRoJl2KpCxTdHgzscTK3L4mnIGc1tk34775hjffSR13613nHrcKqvaNXF_rHeWMDSse1pgDr1eV1Q97bvCwCeGZKT64GTBBlQwbO4Tan5jNoarAIzYXr8pMLWNoeEZaLT.3zpf6iYVNov7eTX6UKjC2dzxiZX2uIt X-Yahoo-Newman-Property: ymail-3 Message-ID: <49EB4D9A.4000409@netconfcentral.com> Date: Sun, 19 Apr 2009 09:13:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock and the candidate config 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, 19 Apr 2009 16:12:01 -0000 WashamFan wrote: >> > lock is to pretect one session from intervention of another one >> > during a (short) period of time. If multiple sessions share a global >> > group lock at the same time (even partial lock is allowed), difficult >> > recovery is still there. >> > >> >> Why? >> This assumes some problems with access-control? >> If not, then discard-changes is the recovery mechanism, as usual. >> > >> > Are all users within a group has the same or different privilege? >> >> that's an out-of-scope access control question. > > Imagine session A with only access right to /foo and session B with only access > right to /bar are in the same group. session A has not enough authority to > discard 'undone' changes left by session B. That is why I ask are all users > within a group has the same privilege, and say difficult recovery is still there. > When a single session owns a global lock, it can always discard-changes made > by itself, but when a group of sessions share a global lock, difficult recovery arise > again. This deadlock scenario (first described by Wes) has always been a possibility for the candidate config. The only way to prevent it is to use the global lock operation. Partial-lock does not address this problem at all. (When this work was first chartered, I strongly approved because I thought it was going to address the issues raised by Wes.) You are correct in pointing out that the group lock really depends on the access control model used in conjunction with locking. If the ACM assigns access rights to groups instead of directly to users, then this group lock will work fine. There is no standard access control. There are no valid assumptions one can make about how a compliant NETCONF agent MUST behave wrt/ access control. Within the NETCONF standard, if you get a session opened, you have access to everything and so does everybody else. This candidate config deadlock is not possible, according to the standard. > > washam > > Andy From dromasca@avaya.com Sun Apr 26 08:22: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 C57A33A6F0A; Sun, 26 Apr 2009 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Q0d6-cprLXYG; Sun, 26 Apr 2009 08:22:38 -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 561783A6B39; Sun, 26 Apr 2009 08:22:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,248,1238990400"; d="scan'208";a="144126903" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Apr 2009 11:23:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Apr 2009 11:23:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Apr 2009 17:23:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The NGO List - EOL? Thread-Index: AcnGgva03edne+kIQ1WDbI5buW0BNw== From: "Romascanu, Dan (Dan)" To: , Cc: ngo@ietf.org Subject: [Netconf] The NGO List - EOL? 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, 26 Apr 2009 15:22:38 -0000 Is there any reason to keep the NGO (NETCONF Goes On) list alive? No useful traffic seems to have been sent to that list for the last calendar year.=20 Dan From andy@netconfcentral.com Sun Apr 26 08:53: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 055FD3A6DF2 for ; Sun, 26 Apr 2009 08:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=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 Q865yanj9MqM for ; Sun, 26 Apr 2009 08:53:41 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 5940F3A6AE9 for ; Sun, 26 Apr 2009 08:53:41 -0700 (PDT) Received: (qmail 80052 invoked from network); 26 Apr 2009 15:55:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Apr 2009 15:55:01 -0000 X-YMail-OSG: 6lMLvdEVM1lI6JbdXx.TX5YDohMnXsrVtz572OWnKh8akfIIpjmTIRt2vM3ZNA7m_hxzH3L4pNUvD953NQj_bXGAi5axkKYc8gCHETbp_yy0MmCD4Riv2h1no592_3aKO1u6dMkKr0T8AgwUbqIm69yhJsTDH7j7dbVqaOur8Z8EyOSyd.9jKDe.oxhxpnGymUMaeUPVno2fiKDWiLAxzts1TQbKruQ23UXtQtr7QtEs.IO_WMdvxf_9dQG4VvAeR43cTeZKj7xVkE_tZURGWNhY3V7bA.tYdiWHSvhfieiRMAVim5OvL1hrNDFb9IwfzBGK4cb.blThR.oltv0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F483D2.10904@netconfcentral.com> Date: Sun, 26 Apr 2009 08:54:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETCONF , NETMOD Working Group References: <49E4BA9C.7080307@netconfcentral.com> In-Reply-To: <49E4BA9C.7080307@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] ietf-netconf.yang (2) 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, 26 Apr 2009 15:53:42 -0000 Andy Bierman wrote: > Hi, > > Here is the updated version based on Martin's comments. > I did not get any comments on the YANG module or the total lack of support for NETCONF capabilities. There is a disconnect between how the NETMOD WG views the data modeling world and how standard NETCONF data models already in place are using capabilities. The claim is that capabilities are not needed in YANG because they are for the protocol layer, and features are for the content layer. This assertion has proven to be false in 2 of the first 4 YANG standard data models. The result is that any YANG file that tries to describe capability-based constructs is really describing a superset of all possible versions -- just like XSD, and just as worthless. A schema that works for all possible implementations but doesn't work for any specific implementation is not that useful to real CM work. I suggest that the NETCONF and NETMOD WGs think about this problem some more. Andy > IMO, the total lack of support in YANG for NETCONF capabilities > is a mistake. It leaves a big hole in the tool automation chain, > for a very basic feature of the NETCONF architecture. It forces > simple boolean logic into description statements, where it must > be read by every single implementor, the English text understood > correctly, and then manually implemented correctly. > > This is not just some corner-case, because this module happens > to be netconf.yang. The ietf-partial-lock data model is designed > to utilize the :xpath capability, and is only defined in description > statements. The ietf-netconf-state data model contains > sections which are only relevant if :notifications is supported, > or if :partial-lock is supported. Again, only defined in > description statements. > > So, out of the 4 very first 'content layer' standard data models, > (not counting netconf.yang) half of them need an 'if-capability' > statement. That seems like a pretty solid use-case to me. > > > > Andy > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From Washam.Fan@huaweisymantec.com Sun Apr 26 21:15: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 3F7073A6D45 for ; Sun, 26 Apr 2009 21:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.374, 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 3tfdcM7oHK-X for ; Sun, 26 Apr 2009 21:15:22 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 180123A684B for ; Sun, 26 Apr 2009 21:15:22 -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 <0KIQ00BQQRVG6370@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Mon, 27 Apr 2009 12:16:30 +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 <0KIQ00L8IRVEOL00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 27 Apr 2009 12:16:28 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 27 Apr 2009 12:16:26 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 27 Apr 2009 12:16:26 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49E4BA9C.7080307@netconfcentral.com> References: <49E4BA9C.7080307@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] ietf-netconf.yang (2) 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, 27 Apr 2009 04:15:23 -0000 > module ietf-netconf { > > ... ... > > // NETCONF Simple Types > > ... ... > > typedef TestOptionType { > description > "NETCONF 'test-option' Element Content. > This is extended with the test-only enumeration. > The 'set' option has no real effect since > the entire PDU is always validated before any > of it is applied (always test-then-set)."; > type enumeration { > enum test-then-set; > enum set; > // enum test-only; !!!! not part of the standard yet > } > default "set"; > } If set option has no real effect, why not leave out this option? And the relevant text in RFC4741 says the test-option is supported by :validate capability, can we still say that again? > ... ... > > // NETCONF Standard RPC Methods > > rpc get-config { > description > "Retrieve all or part of a specified configuration."; > > reference "RFC 4741, section 7.2"; Should be 7.1 instead. > input { > container source { > description "Particular configuration to retrieve."; > > choice config-source { > mandatory true; > > leaf candidate { > description > "Only available if 'candidate' capability supported."; > type empty; > } > leaf running { > type empty; > } > leaf startup { > description > "Only available if 'startup' capability supported."; > type empty; > } > leaf url { > description > "URL pointing to config data. Only available > if 'url' capability supported."; > type ConfigURIType; > } > } > } > > anyxml filter { > description "Subtree or Xpath filter to use."; > nc:get-filter-element-attributes; > } > } > > output { > container data { > description > "Copy of the source database subset which matched > the filter criteria (if any)."; > presence > "An empty data container indicates that the > request did not produce any results."; > } > } > } Why not use 'anyxml data;' as in sec 7.10.4, yang-05? > rpc edit-config { > description > "The 'edit-config' operation loads all or part of a specified > configuration to the specified target configuration. This > operation allows the new configuration to be expressed in several > ways, such as using a local file, a remote file, or inline. > If > the target configuration does not exist, it will be created. > If a > NETCONF peer supports the :url capability (Section 8.8), the > > element can appear instead of the parameter and should > identify a local configuration file. > > The device analyzes the source and target configurations and > performs the requested changes. The target configuration is > not > necessarily replaced, as with the message. Instead, > the target configuration is changed in accordance with the > source's data and requested operations."; > > reference "RFC 4741, section 7.2"; > > input { > container target { > description "Particular configuration to edit."; > > choice config-target { > mandatory true; > > leaf candidate { > description > "Only available if 'candidate' capability supported."; > type empty; > } > leaf running { > type empty; > } > leaf startup { > description > "Only available if 'startup' capability supported."; > type empty; > } > leaf url { > description > "URL pointing to config data. Only available > if 'url' capability supported."; > type ConfigURIType; > } > } > } > > leaf default-operation { > description > "Default operation to apply if not explicitly set."; > type DefaultOperationType; > } > > leaf test-option { > description > "Test option if validate capability supported. > The 'validate' capability must be present to set > this object to 'test-then-set'."; > type TestOptionType; > } > > leaf error-option { > description "Error recovery option."; > type ErrorOptionType; > } I think we should state clearly that rollback-on-error can be used only if :rollback capability is supported. > choice edit-content { > mandatory true; > container config { > description > "Inline Config content: 'config' element."; > } > leaf url { > description > "Pointer to Config content: 'url' element."; > type ConfigURIType; > } > } I can not find any text in RFC4741 defining the use of url as above. > ... ... washam From andy@netconfcentral.com Sun Apr 26 21:42: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 11D5C3A6846 for ; Sun, 26 Apr 2009 21:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_05=-1.11, 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 Ls15Tj9tn3yi for ; Sun, 26 Apr 2009 21:42:01 -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 2A05C3A696A for ; Sun, 26 Apr 2009 21:42:01 -0700 (PDT) Received: (qmail 89412 invoked from network); 27 Apr 2009 04:43:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.97.151 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 27 Apr 2009 04:43:21 -0000 X-YMail-OSG: SzcJqbUVM1nE.yQ5wVffvBiga11xNjT5_dtL2u8Vs8SKweri9ljkrjg1B87T7EsWPA6DzCuNA5C2APgh01kugXyU_nH.i34p7UNeQK6IoqIlsUMXTfziVr80W9aJgacNOsF5DDVVuwZEZOBLtXi.TAX1e9SOyYNAvo3UJFXA6ekfqh.u3Yobc.Scs5uAZ5aWvKMfOZlMUpUzgulpImZp3EZU0KlyJsqjzf4hQdbFO_V.iFl56.oQF9SO9LpsTrkVr6eaC2qphph3IVuHJ.oHL7L2qHuzCCJQ6CIdg7FjcjDf1GPbkdQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F537E7.1080306@netconfcentral.com> Date: Sun, 26 Apr 2009 21:43:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WashamFan References: <49E4BA9C.7080307@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] ietf-netconf.yang (2) 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, 27 Apr 2009 04:42:02 -0000 WashamFan wrote: >> module ietf-netconf { >> >> ... ... >> >> // NETCONF Simple Types >> >> ... ... >> >> typedef TestOptionType { >> description >> "NETCONF 'test-option' Element Content. >> This is extended with the test-only enumeration. >> The 'set' option has no real effect since >> the entire PDU is always validated before any >> of it is applied (always test-then-set)."; >> type enumeration { >> enum test-then-set; >> enum set; >> // enum test-only; !!!! not part of the standard yet >> } >> default "set"; >> } > > If set option has no real effect, why not leave out this option? And > the relevant text in RFC4741 says the test-option is supported by :validate > capability, can we still say that again? > oops. that is my editorial text, not from RFC 4741. I'm not sure what 'set' means. If it means the manager is supposed to be capable of injecting any data into the config without the agent checking it, then no, thanks. No way, no how is my code going to knowingly inject data without validating first. IMO, database integrity is a fairly important part of NETCONF. I think there are other implementations where 'set' and 'test-then-set' do the same thing as well. >> ... ... >> >> // NETCONF Standard RPC Methods >> >> rpc get-config { >> description >> "Retrieve all or part of a specified configuration."; >> >> reference "RFC 4741, section 7.2"; > > Should be 7.1 instead. > OK >> input { >> container source { >> description "Particular configuration to retrieve."; >> >> choice config-source { >> mandatory true; >> >> leaf candidate { >> description >> "Only available if 'candidate' capability supported."; >> type empty; >> } >> leaf running { >> type empty; >> } >> leaf startup { >> description >> "Only available if 'startup' capability supported."; >> type empty; >> } >> leaf url { >> description >> "URL pointing to config data. Only available >> if 'url' capability supported."; >> type ConfigURIType; >> } >> } >> } >> >> anyxml filter { >> description "Subtree or Xpath filter to use."; >> nc:get-filter-element-attributes; >> } >> } >> >> output { >> container data { >> description >> "Copy of the source database subset which matched >> the filter criteria (if any)."; >> presence >> "An empty data container indicates that the >> request did not produce any results."; >> } >> } >> } > > Why not use 'anyxml data;' as in sec 7.10.4, yang-05? > because this RPC function will not return as a leaf. There will always be element node children of the data element. If the filter yields no results, then is the result, indicating no accessible data was found matching the filter. >> rpc edit-config { >> description >> "The 'edit-config' operation loads all or part of a specified >> configuration to the specified target configuration. This >> operation allows the new configuration to be expressed in several >> ways, such as using a local file, a remote file, or inline. >> If >> the target configuration does not exist, it will be created. >> If a >> NETCONF peer supports the :url capability (Section 8.8), the >> >> element can appear instead of the parameter and should >> identify a local configuration file. >> >> The device analyzes the source and target configurations and >> performs the requested changes. The target configuration is >> not >> necessarily replaced, as with the message. Instead, >> the target configuration is changed in accordance with the >> source's data and requested operations."; >> >> reference "RFC 4741, section 7.2"; >> >> input { >> container target { >> description "Particular configuration to edit."; >> >> choice config-target { >> mandatory true; >> >> leaf candidate { >> description >> "Only available if 'candidate' capability supported."; >> type empty; >> } >> leaf running { >> type empty; >> } >> leaf startup { >> description >> "Only available if 'startup' capability supported."; >> type empty; >> } >> leaf url { >> description >> "URL pointing to config data. Only available >> if 'url' capability supported."; >> type ConfigURIType; >> } >> } >> } >> >> leaf default-operation { >> description >> "Default operation to apply if not explicitly set."; >> type DefaultOperationType; >> } >> >> leaf test-option { >> description >> "Test option if validate capability supported. >> The 'validate' capability must be present to set >> this object to 'test-then-set'."; >> type TestOptionType; >> } >> >> leaf error-option { >> description "Error recovery option."; >> type ErrorOptionType; >> } > > I think we should state clearly that rollback-on-error can be used only if > :rollback capability is supported. > OK >> choice edit-content { >> mandatory true; >> container config { >> description >> "Inline Config content: 'config' element."; >> } >> leaf url { >> description >> "Pointer to Config content: 'url' element."; >> type ConfigURIType; >> } >> } > > I can not find any text in RFC4741 defining the use of url as above. > 8.8.5.1. The :url capability modifies the operation to accept the element as an alternative to the parameter. If the element is specified, then it should identify a local configuration file. note the lowercase 'should' instead of SHOULD or MUST. It means the agent can accept whatever it wants (as advertised in the :url capability 'schemes' parameter). >> ... ... > > washam > > Andy From phil@juniper.net Sun Apr 26 20:09: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 7C6023A6A9F for ; Sun, 26 Apr 2009 20:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 1bSkFyyyU2XN for ; Sun, 26 Apr 2009 20:09:15 -0700 (PDT) Received: from chip3og53.obsmtp.com (chip3og53.obsmtp.com [64.18.14.171]) by core3.amsl.com (Postfix) with ESMTP id 81E503A69BC for ; Sun, 26 Apr 2009 20:09:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob53.postini.com ([64.18.6.12]) with SMTP ID DSNKSfUiK6Vh2B3Ug65MaUZQlwRPXCHzenlr@postini.com; Sun, 26 Apr 2009 20:10: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; Sun, 26 Apr 2009 20:04:34 -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); Sun, 26 Apr 2009 20:04:35 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:04:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 20:04:34 -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 n3R34XM27900 for ; Sun, 26 Apr 2009 20:04:34 -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 n3R2uwTp033056 for ; Mon, 27 Apr 2009 02:56:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904270256.n3R2uwTp033056@idle.juniper.net> Date: Sun, 26 Apr 2009 22:56:58 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" X-OriginalArrivalTime: 27 Apr 2009 03:04:34.0199 (UTC) FILETIME=[E44EEA70:01C9C6E4] To: undisclosed-recipients:; X-Mailman-Approved-At: Mon, 27 Apr 2009 02:09:45 -0700 Subject: Re: [Netconf] ietf-netconf.yang (2) 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, 27 Apr 2009 03:09:16 -0000 ------- =_aaaaaaaaaa Content-Type: message/rfc822 To: Andy Bierman cc: NETMOD Working Group Subject: Re: [Netconf] ietf-netconf.yang (2) In-reply-to: <49F483D2.10904@netconfcentral.com> Date: Sun, 26 Apr 2009 22:56:58 -0400 From: Phil Shafer [moving to a single mailing list (netmod); bcc'ing netconf] Andy Bierman writes: >I did not get any comments on the YANG module >or the total lack of support for NETCONF capabilities. You've mentioned this issue several times and I believe it's been addressed, most recently by Martin, but by others before and during the interim. My quick summary would be: (1) If we'd had features during the initial netconf work, we would have used them. (2) YANG can handle multiple capabilities using multiple modules. (3) Early YANG users wanted something less heavy/ more light-weight for their models. The disliked using capabilities for this. (4) We made features, which give a simple extension mechanism for modelers to mark portions of the model as only applying when a feature is present. (5) This approach was approved at the interim and subsequently on the mailing list. If you want to use capabilities to model these bits instead of features, I think that is a valid choice. Other modelers may find features more suitable. I believe this is a closed issue. Thanks, Phil ------- =_aaaaaaaaaa-- From dromasca@avaya.com Mon Apr 27 02:31: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 445EF3A699D; Mon, 27 Apr 2009 02:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 O8recPoHWEJB; Mon, 27 Apr 2009 02:31:24 -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 C70D23A6B86; Mon, 27 Apr 2009 02:30:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,253,1238990400"; d="scan'208";a="159575679" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 27 Apr 2009 05:32:17 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Apr 2009 05:32:16 -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, 27 Apr 2009 11:32:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-thomson-beep-async-02.txt to Proposed Standard Thread-Index: AcnHFqLCVujhgKtmRBaqBathBFTbowABE7bw From: "Romascanu, Dan (Dan)" To: , , Subject: [Netconf] FW: Evaluation: draft-thomson-beep-async-02.txt to Proposed 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: Mon, 27 Apr 2009 09:31:25 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thomson-beep-async-02.txt-02.t xt Technical Summary 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. Working Group Summary This is an individual submission. Document Quality 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. Personnel Chris Newman is the document shepherd. This has been reviewed for the IESG by Alexey Melnikov. Marshall Rose and other participants of the BEEP WG mailing list reviewed this proposal. RFC Editor Note (Insert RFC Editor Note here or remove section) IANA Note (Insert IANA Note here or remove section) From phil@juniper.net Mon Apr 27 06:41: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 0732E3A6AFB for ; Mon, 27 Apr 2009 06:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 c2pPft7vNNnc for ; Mon, 27 Apr 2009 06:41:16 -0700 (PDT) Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id B2F173A6A43 for ; Mon, 27 Apr 2009 06:40:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob61.postini.com ([64.18.6.12]) with SMTP ID DSNKSfW2OcSP4MNMfP9UMBVjEFfO2Rm50bgc@postini.com; Mon, 27 Apr 2009 06:42:34 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, 27 Apr 2009 06:32:03 -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, 27 Apr 2009 06:32:03 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 06:32:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 06:32:02 -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 n3RDW1M76474; Mon, 27 Apr 2009 06:32:01 -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 n3RDOPII065561; Mon, 27 Apr 2009 13:24:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904271324.n3RDOPII065561@idle.juniper.net> To: Andy Bierman In-Reply-To: <49F537E7.1080306@netconfcentral.com> Date: Mon, 27 Apr 2009 09:24:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Apr 2009 13:32:02.0247 (UTC) FILETIME=[8C4B2570:01C9C73C] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] ietf-netconf.yang (2) 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, 27 Apr 2009 13:41:17 -0000 Andy Bierman writes: >If it means the manager is supposed to be capable >of injecting any data into the config >without the agent checking it, then no, thanks. >No way, no how is my code going to knowingly inject >data without validating first. IMO, database integrity >is a fairly important part of NETCONF. I think there >are other implementations where 'set' and 'test-then-set' >do the same thing as well. And there are implementations where "set" means the requested changes immediately affect the configuration. For candidate config, this works quite well, and for running, it may be integral to your data model. For example, if your data model maps directly into cli commands, the data may map to directly issuing those underlaying commands. One of the strengths of NETCONF is that there is flexibility to allow multiple views of configuration data to coexist under one protocol. We didn't set out to make the world fall into a single uniform view, but to allow the device to define and document how data is handled in a way that allows client applications to have sufficient insight to manipulate a configuration properly and effectively. Thanks, Phil From ietfdbh@comcast.net Tue Apr 28 05:19: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 75AAD28C208 for ; Tue, 28 Apr 2009 05:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 t2dOllsMhQ5c for ; Tue, 28 Apr 2009 05:19:42 -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 5427428C11B for ; Tue, 28 Apr 2009 05:19:42 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ky7v1b00217dt5G5B0M1MW; Tue, 28 Apr 2009 12:21:01 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id l0M11b00E0UQ6dC3Z0M1E5; Tue, 28 Apr 2009 12:21:01 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , , References: Date: Tue, 28 Apr 2009 08:21:00 -0400 Message-ID: <02bb01c9c7fb$cab184c0$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: AcnGgva03edne+kIQ1WDbI5buW0BNwBeMakA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: ngo@ietf.org Subject: Re: [Netconf] [netmod] The NGO List - EOL? 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, 28 Apr 2009 12:19:43 -0000 I do not see a good reason to keep it open. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Sunday, April 26, 2009 11:24 AM > To: netconf@ietf.org; netmod@ietf.org > Cc: ngo@ietf.org > Subject: [netmod] The NGO List - EOL? > > Is there any reason to keep the NGO (NETCONF Goes On) list alive? No > useful traffic seems to have been sent to that list for the last > calendar year. > > Dan > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From phil@juniper.net Wed Apr 29 08:08: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 7B19C3A7143 for ; Wed, 29 Apr 2009 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 j6onJ1meehIs for ; Wed, 29 Apr 2009 08:08:40 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id 007283A6CCA for ; Wed, 29 Apr 2009 08:08:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSfhtwC98TNGJctd72Q1tl3e+UQdQv0tt@postini.com; Wed, 29 Apr 2009 08:10:03 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 29 Apr 2009 07:55:17 -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); Wed, 29 Apr 2009 07:55:14 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 07:55:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 07:55: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 n3TEtAM37043; Wed, 29 Apr 2009 07:55:10 -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 n3TElWkx020709; Wed, 29 Apr 2009 14:47:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200904291447.n3TElWkx020709@idle.juniper.net> To: Andy Bierman In-Reply-To: <49DF9B41.6050403@netconfcentral.com> Date: Wed, 29 Apr 2009 10:47:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Apr 2009 14:55:10.0603 (UTC) FILETIME=[7E695DB0:01C9C8DA] MIME-Version: 1.0 Content-Type: text/plain 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: Wed, 29 Apr 2009 15:08:41 -0000 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 ). 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". 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. 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. 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. The example uses "" but section 2.1 says this affects config data, not state data. Thanks, Phil From mehmet.ersue@nsn.com Wed Apr 29 09:51: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 BB9F73A7190 for ; Wed, 29 Apr 2009 09:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=-0.956, 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 ZcFEzkqmZhQe for ; Wed, 29 Apr 2009 09:51:44 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2534E3A717D for ; Wed, 29 Apr 2009 09:51:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3TGr0k1005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 18:53:00 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3TGr011022225; Wed, 29 Apr 2009 18:53:00 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 18:53:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 18:52:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Minutes on Proceedings page thread-index: AcnI6vQW6lVkegx0TXi9hS7dvEbztA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 29 Apr 2009 16:53:00.0305 (UTC) FILETIME=[F4484810:01C9C8EA] Subject: [Netconf] Draft Minutes on Proceedings page 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, 29 Apr 2009 16:51:44 -0000 Hi All, we copied the draft minutes to the proceedings page: http://www.ietf.org/proceedings/09mar/minutes/netconf.txt Cheers,=20 Mehmet From mbj@tail-f.com Thu Apr 30 06:56: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 CE1FA3A6919 for ; Thu, 30 Apr 2009 06:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_05=-1.11, 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 kxfIluw-s8rQ for ; Thu, 30 Apr 2009 06:56:47 -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 4CBC53A6CDD for ; Thu, 30 Apr 2009 06:55: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 77E9B61603A for ; Thu, 30 Apr 2009 15:57:07 +0200 (CEST) Date: Thu, 30 Apr 2009 15:57:07 +0200 (CEST) Message-Id: <20090430.155707.34413266.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [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: Thu, 30 Apr 2009 13:56:47 -0000 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 From mbj@tail-f.com Thu Apr 30 06:57: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 090FB3A6CDD for ; Thu, 30 Apr 2009 06:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.127, 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 obHE3ZZ43KI3 for ; Thu, 30 Apr 2009 06:57: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 5033B3A6A2F for ; Thu, 30 Apr 2009 06:57: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 CCC50616010 for ; Thu, 30 Apr 2009 15:59:08 +0200 (CEST) Date: Thu, 30 Apr 2009 15:59:08 +0200 (CEST) Message-Id: <20090430.155908.05601603.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [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: Thu, 30 Apr 2009 13:57:47 -0000 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? /martin From mbj@tail-f.com Thu Apr 30 07:00: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 7A2283A6A2F for ; Thu, 30 Apr 2009 07:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.126, 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 ndDUYnwtuW+w for ; Thu, 30 Apr 2009 07:00: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 AF8433A68CC for ; Thu, 30 Apr 2009 07:00: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 3CDB0616010 for ; Thu, 30 Apr 2009 16:01:42 +0200 (CEST) Date: Thu, 30 Apr 2009 16:01:41 +0200 (CEST) Message-Id: <20090430.160141.138853286.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [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: Thu, 30 Apr 2009 14:00:20 -0000 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? /martin From mbj@tail-f.com Thu Apr 30 07:01: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 BBA163A71FC for ; Thu, 30 Apr 2009 07:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=-1.083, 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 ABoHDWkXUFqL for ; Thu, 30 Apr 2009 07:01:43 -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 9D4CC3A721E for ; Thu, 30 Apr 2009 07:01: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 53FED616010 for ; Thu, 30 Apr 2009 16:02:26 +0200 (CEST) Date: Thu, 30 Apr 2009 16:02:26 +0200 (CEST) Message-Id: <20090430.160226.69975872.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [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: Thu, 30 Apr 2009 14:01:43 -0000 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? /martin From mbj@tail-f.com Thu Apr 30 07:02: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 595F13A68CC for ; Thu, 30 Apr 2009 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=-0.792, 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 4L6i53YQyBDa for ; Thu, 30 Apr 2009 07:02: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 8E8193A6A06 for ; Thu, 30 Apr 2009 07:02: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 4550E616010 for ; Thu, 30 Apr 2009 16:03:42 +0200 (CEST) Date: Thu, 30 Apr 2009 16:03:42 +0200 (CEST) Message-Id: <20090430.160342.82409955.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [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: Thu, 30 Apr 2009 14:02:20 -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. 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 Comments? /martin From mbj@tail-f.com Thu Apr 30 07:03:11 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 EB15B3A6844 for ; Thu, 30 Apr 2009 07:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=-0.782, 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 QEMwPkc00SUA for ; Thu, 30 Apr 2009 07:03:11 -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 21BB63A6829 for ; Thu, 30 Apr 2009 07:03:11 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C7B46616010 for ; Thu, 30 Apr 2009 16:04:33 +0200 (CEST) Date: Thu, 30 Apr 2009 16:04:28 +0200 (CEST) Message-Id: <20090430.160428.110485974.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [Netconf] 4741bis - multiple namespaces 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, 30 Apr 2009 14:03:12 -0000 Hi, Section 7.1 says: If the configuration is available in multiple formats, such as XML and text, an XML namespace can be used to specify which format is desired. In the following example, the client uses a specific element () in a specific namespace to indicate to the server the desire to receive the configuration in an alternative format. The server may support any number of distinct formats or views into the configuration data, with the client using the parameter to select between them. It looks like namespaces are used for two different purposes; different data models and different formats. This leads to some questions: Can the same be achieved with XPath? If no filter is specified, what should the server return - *all* namespaces (mulitple data models, multiple formats), or all namespaces for *some* format? How would you get all data for the text format? IMO this feature looks broken. Does anyone implement this? Can we remove this paragraph? /martin From andy@netconfcentral.com Thu Apr 30 08:15: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 AC5E53A6B29 for ; Thu, 30 Apr 2009 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 KgKEOD0e35U8 for ; Thu, 30 Apr 2009 08:15:15 -0700 (PDT) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id B9D873A6A65 for ; Thu, 30 Apr 2009 08:15:15 -0700 (PDT) Received: from [68.142.200.227] by n19.bullet.mail.mud.yahoo.com with NNFMP; 30 Apr 2009 15:16:38 -0000 Received: from [68.142.201.249] by t8.bullet.mud.yahoo.com with NNFMP; 30 Apr 2009 15:16:38 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 30 Apr 2009 15:16:38 -0000 X-Yahoo-Newman-Id: 807057.36831.bm@omp410.mail.mud.yahoo.com Received: (qmail 98401 invoked from network); 30 Apr 2009 15:16:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.196 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 30 Apr 2009 15:16:37 -0000 X-YMail-OSG: EBniy5sVM1mWQO17wRGN_YPcO.mNv4TpcvJEIjlRLdv8tRNvqeje47Si.bER1v.gA_kVCw3OYD6k9OyMae0TfWdfbZNcYXlDhgAsI7kOxFwJqBaaRCTCKq6pzgFX_R3lCXdDZwUlH5x4Fqntj3WLBpt_YJuOYKR3XlOjU2sir.NlkPEjbfvJ56ieHR8daWVe6wDIC1dXRtsEohrx6c.TB_RGN5_I6MXxKvzbCdOl2WFUyzjC7oAAnh0jIlEpkvd.uh4nXRQT0XVBeMsD80pOtU7SBLon2zUfYY5iJz9nGBe4Hu6lmNm7Fl9W4QImgqjpu8IYZUaKBfyTDKqMh18P X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F9C0CC.9080808@netconfcentral.com> Date: Thu, 30 Apr 2009 08:16:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 30 Apr 2009 15:15:16 -0000 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? > I think (2) is needed so new managers can work with old agents. > > /martin Andy From andy@netconfcentral.com Thu Apr 30 08:19: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 DE73628C131 for ; Thu, 30 Apr 2009 08:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.038, 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 SI7ux6atSeXV for ; Thu, 30 Apr 2009 08:19:34 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 4D83528C119 for ; Thu, 30 Apr 2009 08:19:34 -0700 (PDT) Received: (qmail 22645 invoked from network); 30 Apr 2009 15:20:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.196 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 30 Apr 2009 15:20:56 -0000 X-YMail-OSG: eNPDwLcVM1ksWZAh6q4qU97zuW2nqPym2bAbd406vWRJXk9tsH8eABjrRFncjR_cQysKo0JwgsHqvalBfMny38MAbd9_5RBrV1GSlafpCPgL9esFOrzNW9Jr3Et9aktiEDO_0Co0YUJGIEalCvRt0Yu_5WrToIfY48LW3u0.DQ7eoDmsXu19u3LZV1r5wVjdb7fmBhIi6deBPLk1RMf.4fq_i_SCObxzELze5YLdaKfp.bRee6R900QDn9sHcXNetnDdx7ELyzd_pfL5WkjnwWHlPlwTrEZBJIh4DT6EIhc03cC3bfbY X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F9C1CF.9050106@netconfcentral.com> Date: Thu, 30 Apr 2009 08:20:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090430.155908.05601603.mbj@tail-f.com> In-Reply-To: <20090430.155908.05601603.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] 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: Thu, 30 Apr 2009 15:19:35 -0000 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. > > /martin Andy From andy@netconfcentral.com Thu Apr 30 08:21: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 C889E3A6827 for ; Thu, 30 Apr 2009 08:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.038, 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 3ZzvcLejJU4e for ; Thu, 30 Apr 2009 08:21:47 -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 E035E3A6F7D for ; Thu, 30 Apr 2009 08:21:41 -0700 (PDT) Received: (qmail 75682 invoked from network); 30 Apr 2009 15:23:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.196 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 30 Apr 2009 15:23:04 -0000 X-YMail-OSG: UxYdOggVM1lnyteHqmbEFNn9gbn22xONgO4wUVi4.kM1h6QKuEB7JzDbjT5LeN2qU37Rxq3YnGUBf6.X9rLIKZBZGH5NUOGi6pTmYPMf1GN8GBlxpTYOKs2vXVVa_zrJTCJHFKAivMVSX0p6XstqjEbztEdOBpGNVtkJ6hnLIRCSXUHlI9z0q3rR5zgpq.6gw6yZi4eVH5LrsxCUvpICmulayGA2IlBJQXiGvKYuIAwoiUwD_N9gxHjz5gqubA4nD6BT.eGnju.i8s69 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F9C24F.6090702@netconfcentral.com> Date: Thu, 30 Apr 2009 08:22:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090430.160141.138853286.mbj@tail-f.com> In-Reply-To: <20090430.160141.138853286.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] 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: Thu, 30 Apr 2009 15:21:47 -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. > /martin Andy From andy@netconfcentral.com Thu Apr 30 08:24:12 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 91BDC3A6F79 for ; Thu, 30 Apr 2009 08:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 Q5K7HuUGaANm for ; Thu, 30 Apr 2009 08:24:11 -0700 (PDT) Received: from n12.bullet.mail.mud.yahoo.com (n12.bullet.mail.mud.yahoo.com [209.191.125.209]) by core3.amsl.com (Postfix) with SMTP id C9AF13A6F66 for ; Thu, 30 Apr 2009 08:24:11 -0700 (PDT) Received: from [68.142.200.221] by n12.bullet.mail.mud.yahoo.com with NNFMP; 30 Apr 2009 15:25:34 -0000 Received: from [68.142.201.64] by t9.bullet.mud.yahoo.com with NNFMP; 30 Apr 2009 15:25:34 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 30 Apr 2009 15:25:34 -0000 X-Yahoo-Newman-Id: 877710.67257.bm@omp416.mail.mud.yahoo.com Received: (qmail 92603 invoked from network); 30 Apr 2009 15:25:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.141.196 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 30 Apr 2009 15:25:33 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F9C2E4.5000709@netconfcentral.com> Date: Thu, 30 Apr 2009 08:25:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Martin Bjorklund References: <20090430.160226.69975872.mbj@tail-f.com> In-Reply-To: <20090430.160226.69975872.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] 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: Thu, 30 Apr 2009 15:24:12 -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. > > /martin Andy