From bertietf@bwijnen.net Wed Jul 1 07:09: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 DCA6E28C534 for ; Wed, 1 Jul 2009 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVt9nF+5WltU for ; Wed, 1 Jul 2009 07:09:43 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id B84A028C560 for ; Wed, 1 Jul 2009 07:09:14 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1MM0To-0007p8-H1; Wed, 01 Jul 2009 16:08:10 +0200 Message-ID: <4D20A10EDC1B44948C1EDA4D2ECFFDC8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" , "Romascanu, Dan \(Dan\)" , "Martin Bjorklund" References: <4A30CD50.5020305@ericsson.com> In-Reply-To: <4A30CD50.5020305@ericsson.com> Date: Wed, 1 Jul 2009 16:08:01 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AA8_01C9FA66.1BAFBD00" 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 Cc: netconf mailing list Subject: Re: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:09:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0AA8_01C9FA66.1BAFBD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Diff: draft-ietf-netconf-partial-lock-08.txt - = draft-ietf-netconf-partial-lock-09.txtDan, is there any new text that = Balazs should include in the next (hopefully final) revision? I mean w.r.t. IPR related text? Bert ----- Original Message -----=20 From: Balazs Lengyel=20 To: Romascanu, Dan (Dan) ; Martin Bjorklund=20 Cc: netconf mailing list=20 Sent: Thursday, June 11, 2009 11:24 AM Subject: Re: [Netconf] AD review for = draft-ietf-netconf-partial-lock-08.txt Hello Dan, Martin, Thanks for the comments. See below. I attached a diff between the current 08 version and the future 09 = version as it stands at the=20 moment. Balazs Romascanu, Dan (Dan) wrote: > This document is ready to be sent to IETF Last Call, and I will send = it > immediately after sending this message. Please consider the comments > below together with the other IETF Last Call comments. >=20 > 1. IPR and Copyright issues >=20 > Running idnits results in the following warning:=20 >=20 > =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, = but was > first submitted before 10 November 2008. Should you add the > disclaimer? > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.).=20 >=20 > trust-12-feb-2009 Section 6.c.iii text: > "This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before = November > 10, 2008. The person(s) controlling the copyright in some of = this > material may not have granted the IETF Trust the right to = allow > modifications of such material outside the IETF Standards = Process. >=20 > Without obtaining an adequate license from the person(s) > controlling the copyright in such materials, this document may = not > be modified outside the IETF Standards Process, and derivative > works of it may not be created outside the IETF Standards = Process, > except to format it for publication as an RFC or to translate = it > into languages other than English." BALAZS: Changed IPR to pre5378Trust200902. >=20 > Also, the schema in Appendix A will need to include the full text of = the > BSD license for code or a reference to it. This issue is still = debated > with the Trust, so no action by now on this.=20 BALAZS: So I should wait for further information. When and where can = I find this, or will the=20 chairs or you supply it? >=20 > 2. last paragraph in Section 1.1=20 >=20 > s/This consist/These consist/ BALAZS: Is OK if I change the paragraph to: Protected area: the set of nodes that are protected from modification by the lock. This set consists of nodes in the scope of the lock and nodes in subtrees under them. >=20 > 3. Section 2.1.1 >=20 > s/However it can be used to lock a candidate datastore/However it = can be > used to lock parts of a candidate datastore/ BALAZS: OK >=20 > 4. The title of Section 2.1.1.1 seems to me to be more appropriately > 'Multiple managers handling the writable running datastore with > overlapping sections' BALAZS: OK >=20 > 5. same section - I am a little nervous about saying 'The lock = should be > held only a short time (seconds rather then minutes)'. What if the = lock > can be help less than seconds or minutes at minimum because of the = size > of the records to be operated? Maybe better is to say 'The lock = should > be held the shortest possible time (e.g. seconds rather then = minutes)'. BALAZS: OK >=20 > 6. Section 2.1.1.2 - better (e.g. minutes, hours) BALAZS: OK >=20 > 7. Section 2.1.1.3 - same comment as #5 for 2.1.1.1 BALAZS: OK >=20 > 8. page 6 - section 2.4.1 - 'these notes should be included in the > protected area of the lock' - it seems to me that a capitalized = SHOULD > is appropriate here.=20 BALAZS: OK >=20 > 9. Capitalization seems necessary also in 2.4.1.2 and also a change = as I > do not see in which situations if locking fails the client should = not > back-off. I realize this is client behavior, but the normative = language > still seems to apply >=20 > So:=20 >=20 > OLD:=20 >=20 > To avoid this situation, clients should lock > everything they need in one operation. If locking fails, the = client > should back-off, release any previously acquired locks, and retry = the > procedure after waiting some randomized time interval. >=20 > NEW: >=20 > To avoid this situation, clients SHOULD lock > everything they need in one operation. If locking fails, the = client > MUST back-off, release any previously acquired locks, and SHOULD > retry the > procedure after waiting some randomized time interval. >=20 BALAZS: OK > 10. Last paragraph in section 3 - why is NOT capitalized?=20 BALAZS: Just to emphasize it. I removed the capitalization. >=20 > Dan >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 --=20 Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: = Balazs.Lengyel@ericsson.com -------------------------------------------------------------------------= ----- draft-ietf-netconf-partial-lock-08.txt = draft-ietf-netconf-partial-lock-09.txt =20 =20 NETCONF B. Lengyel NETCONF B. Lengyel =20 Internet-Draft Ericsson Internet-Draft Ericsson =20 Intended status: Standards Track M. Bjorklund Intended status: = Standards Track M. Bjorklund =20 =20 Expires: December 5, 2009 Tail-f Systems Expires: December 13, = 2009 Tail-f Systems =20 June 03, 2009 June 11, 2009 =20 =20 Partial Lock RPC for NETCONF Partial Lock RPC for NETCONF =20 =20 draft-ietf-netconf-partial-lock-08 = draft-ietf-netconf-partial-lock-09 =20 =20 Status of this Memo Status of this Memo =20 =20 This Internet-Draft is submitted to IETF in full conformance with = the This Internet-Draft is submitted to IETF in full conformance with = the =20 =20 provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP = 79. This document may contain material =20 from IETF Documents or IETF Contributions published or made = publicly =20 available before November 10, 2008. The person(s) controlling = the =20 copyright in some of this material may not have granted the = IETF =20 Trust the right to allow modifications of such material outside = the =20 IETF Standards Process. Without obtaining an adequate license = from =20 the person(s) controlling the copyright in such materials, this = =20 document may not be modified outside the IETF Standards = Process, and =20 derivative works of it may not be created outside the IETF = Standards =20 Process, except to format it for publication as an RFC or to =20 translate it into languages other than English. =20 =20 Internet-Drafts are working documents of the Internet Engineering = Internet-Drafts are working documents of the Internet Engineering =20 Task Force (IETF), its areas, and its working groups. Note that = Task Force (IETF), its areas, and its working groups. Note that =20 other groups may also distribute working documents as Internet- = other groups may also distribute working documents as Internet- =20 Drafts. Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft documents valid for a maximum of six = months =20 and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, or obsoleted by other documents at = any =20 time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use Internet-Drafts as reference =20 material or to cite them other than as "work in progress." = material or to cite them other than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at The list = of current Internet-Drafts can be accessed at =20 http://www.ietf.org/ietf/1id-abstracts.txt. = http://www.ietf.org/ietf/1id-abstracts.txt. =20 =20 The list of Internet-Draft Shadow Directories can be accessed at = The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html. = http://www.ietf.org/shadow.html. =20 =20 =20 This Internet-Draft will expire on December 5, 2009. This = Internet-Draft will expire on December 13, 2009. =20 =20 Copyright Notice Copyright Notice =20 =20 Copyright (c) 2009 IETF Trust and the persons identified as the = Copyright (c) 2009 IETF Trust and the persons identified as the =20 document authors. All rights reserved. document authors. All = rights reserved. =20 =20 This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the IETF Trust's Legal =20 Provisions Relating to IETF Documents in effect on the date of = Provisions Relating to IETF Documents in effect on the date of =20 publication of this document = (http://trustee.ietf.org/license-info). publication of this document = (http://trustee.ietf.org/license-info). =20 Please review these documents carefully, as they describe your = rights Please review these documents carefully, as they describe your = rights =20 =20 skipping to change at page 2, line 10 skipping to change at page = 3, line 7 =20 Abstract Abstract =20 =20 The NETCONF protocol defines the lock and unlock RPCs, used to = lock The NETCONF protocol defines the lock and unlock RPCs, used to = lock =20 entire configuration datastores. In some situations, a way to = lock entire configuration datastores. In some situations, a way to lock = =20 only parts of a configuration datastore is required. This = document only parts of a configuration datastore is required. This = document =20 defines a capability-based extension to the NETCONF protocol for = defines a capability-based extension to the NETCONF protocol for =20 locking portions of a configuration datastore. locking portions = of a configuration datastore. =20 =20 Table of Contents Table of Contents =20 =20 =20 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 =20 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 = 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 =20 2. Partial Locking Capability . . . . . . . . . . . . . . . . . . = 3 2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 4 =20 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 = 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 =20 2.1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . 4 = 2.1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . 5 =20 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 6 = 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 7 =20 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 6 = 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 7 =20 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 6 = 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 7 =20 2.4.1. . . . . . . . . . . . . . . . . . . . . 6 = 2.4.1. . . . . . . . . . . . . . . . . . . . . 7 =20 2.4.2. . . . . . . . . . . . . . . . . . . . 11 = 2.4.2. . . . . . . . . . . . . . . . . . . . 12 =20 2.5. Modifications to Existing Operations . . . . . . . . . . . = 11 2.5. Modifications to Existing Operations . . . . . . . . . . . 13 =20 2.6. Interactions with Other Capabilities . . . . . . . . . . . = 12 2.6. Interactions with Other Capabilities . . . . . . . . . . . 14 =20 2.6.1. Candidate Configuration Capability . . . . . . . . . . 12 = 2.6.1. Candidate Configuration Capability . . . . . . . . . . 14 =20 2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 12 = 2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 14 =20 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 12 = 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 14 =20 3. Security Considerations . . . . . . . . . . . . . . . . . . . = 12 3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 = 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 = 5. Appendix A - XML Schema for Partial Locking (normative) . . 15 = 5. Appendix A - XML Schema for Partial Locking (normative) . . 16 =20 6. Appendix B - YANG Module for Partial Locking 6. Appendix B - = YANG Module for Partial Locking =20 =20 (non-normative) . . . . . . . . . . . . . . . . . . . . . . . 19 = (non-normative) . . . . . . . . . . . . . . . . . . . . . . . 20 =20 7. Appendix C - Usage Example - Reserving nodes for future 7. = Appendix C - Usage Example - Reserving nodes for future =20 =20 editing (non-normative) . . . . . . . . . . . . . . . . . . . 22 = editing (non-normative) . . . . . . . . . . . . . . . . . . . 23 =20 8. Appendix D - Change Log . . . . . . . . . . . . . . . . . . 27 = 8. Appendix D - Change Log . . . . . . . . . . . . . . . . . . 28 =20 8.1. 07-08 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 = 8.1. 08-09 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =20 8.2. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 = 8.2. 07-08 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =20 8.3. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 = 8.3. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =20 8.4. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 = 8.4. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =20 8.5. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 = 8.5. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =20 8.6. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 = 8.6. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =20 8.7. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 = 8.7. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =20 8.8. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 = 8.8. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =20 8.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 = 8.9. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 29 8.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 30 =20 10.1. Normative References . . . . . . . . . . . . . . . . . . . = 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 31 =20 10.2. Informative References . . . . . . . . . . . . . . . . . . = 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 = Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . = 31 =20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . = . . 32 =20 =20 1. Introduction 1. Introduction =20 =20 The [NETCONF] protocol describes the lock and unlock operations = that The [NETCONF] protocol describes the lock and unlock operations = that =20 operate on entire configuration datastores. Often, multiple = operate on entire configuration datastores. Often, multiple =20 management sessions need to be able to modify the configuration = of a management sessions need to be able to modify the configuration of = a =20 managed device in parallel. In these cases, locking only parts of = a managed device in parallel. In these cases, locking only parts of a =20 configuration datastore is needed. This document defines a = configuration datastore is needed. This document defines a =20 capability based extension to the NETCONF protocol to support = partial capability based extension to the NETCONF protocol to support = partial =20 locking of NETCONF datastores using a mechanism based on the = existing locking of NETCONF datastores using a mechanism based on the = existing =20 =20 skipping to change at page 3, line 36 skipping to change at page = 4, line 36 =20 node in the conceptual XML datastore. It contains an absolute = node in the conceptual XML datastore. It contains an absolute =20 path expression in abbreviated syntax, where predicates are used = path expression in abbreviated syntax, where predicates are used =20 only to specify values for nodes defined as keys to distinguish = only to specify values for nodes defined as keys to distinguish =20 multiple instances. multiple instances. =20 =20 o Scope of the lock: initially the set of nodes returned by the = o Scope of the lock: initially the set of nodes returned by the =20 XPath expressions in a successful partial-lock operation. The set = XPath expressions in a successful partial-lock operation. The set =20 might be modified if some of the nodes are deleted. might be = modified if some of the nodes are deleted. =20 =20 o Protected area: the set of nodes that are protected from o = Protected area: the set of nodes that are protected from =20 =20 modification by the lock. This consist of nodes in the scope of = modification by the lock. This set consists of nodes in the scope =20 the lock and nodes in subtrees under them. of the lock and nodes = in subtrees under them. =20 =20 2. Partial Locking Capability 2. Partial Locking Capability =20 =20 2.1. Overview 2.1. Overview =20 =20 The :partial-lock capability indicates that the device supports = the The :partial-lock capability indicates that the device supports the = =20 locking of its configuration with a more limited scope than a = locking of its configuration with a more limited scope than a =20 complete configuration datastore. The scope to be locked is = complete configuration datastore. The scope to be locked is =20 specified by using restricted or full XPath expressions. Partial = specified by using restricted or full XPath expressions. Partial =20 locking only affects configuration data. locking only affects = configuration data. =20 =20 skipping to change at page 4, line 27 skipping to change at page = 5, line 27 =20 2.1.1. Usage Scenarios 2.1.1. Usage Scenarios =20 =20 In the following we describe a few scenarios for partial locking. = In the following we describe a few scenarios for partial locking. =20 Partial locking is primarily useful towards the running Partial = locking is primarily useful towards the running =20 configuration. However it can be used to lock a candidate = datastore configuration. However it can be used to lock a candidate = datastore =20 as well. While scenarios using the running datastore are seen as = the as well. While scenarios using the running datastore are seen as = the =20 most important, as an example a scenario involving the candidate = most important, as an example a scenario involving the candidate =20 datastore is also presented. Besides the three described here, = there datastore is also presented. Besides the three described here, = there =20 are many other usage scenarios possible. are many other usage = scenarios possible. =20 =20 =20 2.1.1.1. Multiple managers handling the writable running = datastore 2.1.1.1. Multiple managers handling the writable running = datastore with =20 overlapping sections =20 =20 Multiple managers are handling the same NETCONF agent = simultaneously. Multiple managers are handling the same NETCONF agent = simultaneously. =20 The agent is handled via the writable running datastore. Each = The agent is handled via the writable running datastore. Each =20 manager has his or her own task, which might involve the = modification manager has his or her own task, which might involve the = modification =20 of overlapping sections of the datastore. of overlapping = sections of the datastore. =20 =20 After collecting and analyzing input and preparing the NETCONF = After collecting and analyzing input and preparing the NETCONF =20 operations off-line, the manager locks the areas that are = important operations off-line, the manager locks the areas that are = important =20 for his task using one single operation. The = manager for his task using one single operation. The = manager =20 executes a number of operations to modify the = executes a number of operations to modify the =20 configuration, then releases the partial-lock. The lock should be = configuration, then releases the partial-lock. The lock should be =20 =20 held for only a short time (seconds rather then minutes). The = held for the shortest possible time (e.g. seconds rather then =20 manager should collect all human input before locking anything. = As minutes). The manager should collect all human input before locking = each manager locks only a part of the data model, usually = multiple anything. As each manager locks only a part of the data model, = =20 operators can execute the operations = simultaneously. usually multiple operators can execute the = operations =20 simultaneously. =20 =20 2.1.1.2. Multiple managers handling the writable running = datastore, 2.1.1.2. Multiple managers handling the writable running = datastore, =20 distinct management areas distinct management areas =20 =20 Multiple managers are handling the same NETCONF agent = simultaneously. Multiple managers are handling the same NETCONF agent = simultaneously. =20 The agent is handled via the writable running datastore. The = agent's The agent is handled via the writable running datastore. The = agent's =20 data model contains a number of well defined separate areas that = can data model contains a number of well defined separate areas that = can =20 be configured without impacting other areas. An example can be a = be configured without impacting other areas. An example can be a =20 server with multiple applications running on it, or a number of a = server with multiple applications running on it, or a number of a =20 network elements with a common NETCONF agent for management. = network elements with a common NETCONF agent for management. =20 =20 Each manager has his or her own task, which does not involve the = Each manager has his or her own task, which does not involve the =20 modification of overlapping sections of the datastore. = modification of overlapping sections of the datastore. =20 =20 The manager locks his area with a operation, uses = a The manager locks his area with a operation, uses a =20 number of commands to modify it, later releases the = number of commands to modify it, later releases the =20 lock. As each manager has his functional area assigned to him, = and lock. As each manager has his functional area assigned to him, and = he locks only that area, multiple managers can edit the = configuration he locks only that area, multiple managers can edit the = configuration =20 =20 simultaneously. Locks can be held for extended periods (minutes, = simultaneously. Locks can be held for extended periods (e.g. =20 hours), as this will not hinder other managers. minutes, hours), = as this will not hinder other managers. =20 =20 This scenario assumes, that the global lock operation from = [NETCONF] This scenario assumes, that the global lock operation from = [NETCONF] =20 is not used. is not used. =20 =20 2.1.1.3. Multiple managers handling the candidate datastore in a = semi- 2.1.1.3. Multiple managers handling the candidate datastore in a = semi- =20 coordinated work mode coordinated work mode =20 =20 Multiple managers are handling the same NETCONF agent = simultaneously. Multiple managers are handling the same NETCONF agent = simultaneously. =20 The agent is handled via the candidate datastore. Each manager = has The agent is handled via the candidate datastore. Each manager has = his or her own task which might involve the modification of his = or her own task which might involve the modification of =20 overlapping sections of the datastore. overlapping sections of = the datastore. =20 =20 After collecting and analyzing input and preparing the NETCONF = After collecting and analyzing input and preparing the NETCONF =20 operations off-line, the manager locks the areas that are = important operations off-line, the manager locks the areas that are = important =20 for his task using one single operation in both = the for his task using one single operation in both the = candidate and the running datastore. He executes a number of = operations to modify the configuration, then releases the = config> operations to modify the configuration, then releases the =20 =20 partial-lock. The lock should be held for only a short time = (seconds partial-lock. The lock should only be held for the shortest = possible =20 rather then minutes). time (e.g. seconds rather then minutes). =20 =20 Operators coordinate with each other. When all of them finish = their Operators coordinate with each other. When all of them finish = their =20 tasks one of them orders commit. If any of the operators are = still tasks one of them orders commit. If any of the operators are = still =20 working, and holds a lock, the commit will fail, and will need to = be working, and holds a lock, the commit will fail, and will need to be = =20 repeated after all managers finish. repeated after all managers = finish. =20 =20 Warning: When multiple managers use the candidate configuration = in Warning: When multiple managers use the candidate configuration in =20 parallel, there is a risk that the interaction of access control = parallel, there is a risk that the interaction of access control =20 (which is still implementation specific at the time of this = writing) (which is still implementation specific at the time of this = writing) =20 and the commit operation might result in a dead-lock, as = illustrated and the commit operation might result in a dead-lock, as = illustrated =20 =20 skipping to change at page 8, line 15 skipping to change at page = 9, line 17 =20 The operation is designed for simplicity, so when = a The operation is designed for simplicity, so when a =20 partial lock is executed you get what you asked for: a set of = nodes partial lock is executed you get what you asked for: a set of = nodes =20 that are locked for writing. As a consequence users must observe = the that are locked for writing. As a consequence users must observe = the =20 following: following: =20 =20 o Locking does not affect read operations. o Locking does not = affect read operations. =20 =20 o If part of a datastore is locked, this has no effect on any o = If part of a datastore is locked, this has no effect on any =20 unlocked parts of the datastore. If this is a problem (e.g., = unlocked parts of the datastore. If this is a problem (e.g., =20 changes depend on data values or nodes outside the protected part = changes depend on data values or nodes outside the protected part =20 =20 of the datastore), these nodes should be included in the = protected of the datastore), these nodes SHOULD be included in the = protected =20 area of the lock. area of the lock. =20 =20 o Configuration data can be edited both inside and outside the o = Configuration data can be edited both inside and outside the =20 protected area of a lock. It is the responsibility of the NETCONF = protected area of a lock. It is the responsibility of the NETCONF =20 client application to lock all relevant parts of a datastore that = client application to lock all relevant parts of a datastore that =20 are crucial for a specific management action. are crucial for a = specific management action. =20 =20 Note: The operation does not modify the global = Note: The operation does not modify the global = =20 operation defined in the base NETCONF Protocol [NETCONF]. If part = of operation defined in the base NETCONF Protocol [NETCONF]. If part of = =20 a datastore is already locked by , then a global = lock a datastore is already locked by , then a global = lock =20 =20 skipping to change at page 10, line 46 skipping to change at = page 12, line 35 =20 not an Instance Identifier, the is 'invalid-value', = the not an Instance Identifier, the is 'invalid-value', the = =20 is 'invalid-lock-specification'. = is 'invalid-lock-specification'. =20 =20 If access control denies the partial lock, the is If = access control denies the partial lock, the is =20 'access-denied'. 'access-denied'. =20 =20 2.4.1.2. Deadlock Avoidance 2.4.1.2. Deadlock Avoidance =20 =20 As with most locking systems, it is possible that two management = As with most locking systems, it is possible that two management =20 sessions trying to lock different parts of the configuration = could sessions trying to lock different parts of the configuration = could =20 =20 become dead-locked. To avoid this situation, clients should lock = become dead-locked. To avoid this situation, clients SHOULD lock =20 everything they need in one operation. If locking fails, the = client everything they need in one operation. If locking fails, the = client =20 =20 should back-off, release any previously acquired locks, and retry = the MUST back-off, release any previously acquired locks, and SHOULD =20 procedure after waiting some randomized time interval. retry the = procedure after waiting some randomized time interval. =20 =20 2.4.2. 2.4.2. =20 =20 The operation unlocks the parts of the datastores that were The = operation unlocks the parts of the datastores that were =20 previously locked using during the same session. = previously locked using during the same session. =20 =20 Parameters: Parameters: =20 =20 lock-id: Identity of the lock to be unlocked. This lock-id MUST = lock-id: Identity of the lock to be unlocked. This lock-id MUST =20 have been received as a response to a lock request by the manager = have been received as a response to a lock request by the manager =20 =20 skipping to change at page 13, line 29 skipping to change at = page 15, line 19 =20 users's sessions. users's sessions. =20 =20 The NETCONF server may log partial lock requests in an audit The = NETCONF server may log partial lock requests in an audit =20 trail. trail. =20 =20 A lock that is hung for some reason (e.g., a broken TCP = connection A lock that is hung for some reason (e.g., a broken TCP = connection =20 that the server has not yet recognised) can be released using = another that the server has not yet recognised) can be released using = another =20 NETCONF session by explicitly killing the session owning that = lock NETCONF session by explicitly killing the session owning that lock = =20 using the operation. using the = operation. =20 =20 =20 Partial locking is NOT an authorization mechanism; it SHOULD NOT = be Partial locking is not an authorization mechanism; it SHOULD NOT be = used to provide security or access control. Partial locking = SHOULD used to provide security or access control. Partial locking = SHOULD =20 only be used as a mechanism for providing consistency when = multiple only be used as a mechanism for providing consistency when = multiple =20 managers are trying to configure the node. It is vital that users = managers are trying to configure the node. It is vital that users =20 easily understand the exact scope of a lock. This is why the = scope easily understand the exact scope of a lock. This is why the = scope =20 is determined when granting a lock and is not modified = thereafter. is determined when granting a lock and is not modified = thereafter. =20 =20 4. IANA Considerations 4. IANA Considerations =20 =20 This document registers two URIs for the NETCONF XML namespace in = the This document registers two URIs for the NETCONF XML namespace in = the =20 IETF XML registry [RFC3688]. Note that the capability URN is = IETF XML registry [RFC3688]. Note that the capability URN is =20 =20 skipping to change at page 27, line 7 skipping to change at page = 28, line 7 =20 message-id=3D"105"> =20 =20 1 1 =20 =20 =20 =20 8. Appendix D - Change Log 8. Appendix D - Change Log =20 =20 =20 8.1. 07-08 8.1. 08-09 =20 =20 Clarifications Clarifications =20 =20 =20 8.2. 06-07 8.2. 07-08 =20 =20 Clarifications =20 =20 8.3. 06-07 =20 =20 Changed XSD and YANG to allow additional proprietary datastores = to be Changed XSD and YANG to allow additional proprietary datastores = to be =20 locked. locked. =20 =20 =20 8.3. 05-06 8.4. 05-06 =20 =20 Added usage example Added usage example =20 =20 Clarified error messages Clarified error messages =20 =20 Clarified interaction with edit-config continue-on-error = Clarified interaction with edit-config continue-on-error =20 =20 Improved YANG: indentation, canonical order, contact info = Improved YANG: indentation, canonical order, contact info =20 =20 Added usage example in appendix C Added usage example in = appendix C =20 =20 Synchronized YANG and XSD Synchronized YANG and XSD =20 =20 =20 8.4. 04-05 8.5. 04-05 =20 =20 Language and editorial updates Language and editorial updates =20 =20 all app-tags are with dashes without spaces all app-tags are = with dashes without spaces =20 =20 Added usage scenarios Added usage scenarios =20 =20 Changed encoding Changed encoding =20 =20 Clarified definitions, separated scope of lock and protected area = Clarified definitions, separated scope of lock and protected area =20 =20 =20 8.5. 03-04 8.6. 03-04 =20 =20 Minor clarifications Minor clarifications =20 =20 Added list of locked-nodes to the output of partial-lock. Added = list of locked-nodes to the output of partial-lock. =20 =20 Added wrapper around datastore names. Added = wrapper around datastore names. =20 =20 Allowed atomic/one operation locking of datastore parts in = multiple Allowed atomic/one operation locking of datastore parts in = multiple =20 datastores. datastores. =20 =20 Improved English (hopefully) Improved English (hopefully) =20 =20 Removed the element from rpc-reply following the text of = Removed the element from rpc-reply following the text of =20 rfc4741. rfc4741. =20 =20 =20 8.6. 02-03 8.7. 02-03 =20 =20 Minor clarifications Minor clarifications =20 =20 Same descriptions in XSD and YANG. Same descriptions in XSD and = YANG. =20 =20 =20 8.7. 01-02 8.8. 01-02 =20 =20 Made XSD normative Made XSD normative =20 =20 Clarified that no specific access control is assumed. Clarified = that no specific access control is assumed. =20 =20 Clarified that non-existing nodes are NOT covered by the lock, = even Clarified that non-existing nodes are NOT covered by the lock, = even =20 if they where existing and covered by the lock when it was = originally if they where existing and covered by the lock when it was = originally =20 granted. granted. =20 =20 Some rewording Some rewording =20 =20 Added app-tags for two of the error cases. Added app-tags for = two of the error cases. =20 =20 Made YANG an informative reference Made YANG an informative = reference =20 =20 Enhanced security considerations. Enhanced security = considerations. =20 =20 =20 8.8. 00-01 8.9. 00-01 =20 =20 Added YANG module. Added YANG module. =20 =20 =20 8.9. -00 8.10. -00 =20 =20 Created from draft-lengyel-ngo-partial-lock-01.txt Created from = draft-lengyel-ngo-partial-lock-01.txt =20 =20 9. Acknowledgements 9. Acknowledgements =20 =20 Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David = Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David =20 Harrington, Mehmet Ersue, Wes Hardaker, Juergen Schoenwaelder, = Washam Harrington, Mehmet Ersue, Wes Hardaker, Juergen Schoenwaelder, = Washam =20 Fan and many other members of the NETCONF WG for providing = important Fan and many other members of the NETCONF WG for providing = important =20 input to this document. input to this document. =20 =20 =20 End of changes. 25 change blocks. =20 65 lines changed or deleted 82 lines changed or added =20 This html diff was produced by rfcdiff 1.35. The latest version = is available from http://tools.ietf.org/tools/rfcdiff/ =20 -------------------------------------------------------------------------= ----- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf -------------------------------------------------------------------------= ----- Internal Virus Database is out of date. Checked by AVG - www.avg.com=20 Version: 8.5.339 / Virus Database: 270.12.58/2164 - Release Date: = 06/08/09 17:59:00 ------=_NextPart_000_0AA8_01C9FA66.1BAFBD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Diff: draft-ietf-netconf-partial-lock-08.txt - = draft-ietf-netconf-partial-lock-09.txt
Dan, is there any new text that Balazs should = include in the=20 next (hopefully final)
revision? I mean w.r.t. IPR related = text?
 
Bert
 
----- Original Message -----
From:=20 Balazs Lengyel
To: Romascanu, Dan (Dan) ; Martin = Bjorklund
Sent: Thursday, June 11, 2009 = 11:24=20 AM
Subject: Re: [Netconf] AD = review for=20 draft-ietf-netconf-partial-lock-08.txt

Hello Dan, Martin,
Thanks for the comments.  = See=20 below.

I attached a diff between the current 08 version and the = future=20 09 version as it stands at the
moment.
Balazs

Romascanu, = Dan=20 (Dan) wrote:
> This document is ready to be sent to IETF Last = Call, and=20 I will send it
> immediately after sending this message. Please = consider=20 the comments
> below together with the other IETF Last Call=20 comments.
>
> 1. IPR and Copyright issues
> =
>=20 Running idnits results in the following warning:
>
> = =3D=3D The=20 document seems to lack a disclaimer for pre-RFC5378 work, but=20 was
>      first submitted before 10 = November=20 2008.  Should you add the
>=20 disclaimer?
>      (See the Legal = Provisions=20 document at
>      http://trustee.ietf.org/lic= ense-info=20 for more information.).
> =
>     =20 trust-12-feb-2009 Section 6.c.iii = text:
>     =20 "This document may contain material from IETF Documents or=20 IETF
>       Contributions = published or=20 made publicly available before=20 November
>       10, 2008.  = The=20 person(s) controlling the copyright in some of=20 this
>       material may not have = granted=20 the IETF Trust the right to = allow
>      =20 modifications of such material outside the IETF Standards = Process.
>=20
>       Without obtaining an = adequate=20 license from the person(s)
>       = controlling the copyright in such materials, this document may=20 not
>       be modified outside = the IETF=20 Standards Process, and = derivative
>      =20 works of it may not be created outside the IETF Standards=20 Process,
>       except to format = it for=20 publication as an RFC or to translate=20 it
>       into languages other = than=20 English."

BALAZS: Changed IPR to = pre5378Trust200902.

>=20
> Also, the schema in Appendix A will need to include the full = text of=20 the
> BSD license for code or a reference to it. This issue is = still=20 debated
> with the Trust, so no action by now on this. =

BALAZS:=20 So  I should wait for further information. When and where can I = find=20 this, or will the
chairs or you supply it?

>
> 2. = last=20 paragraph in Section 1.1
>
> s/This consist/These=20 consist/

BALAZS: Is OK if I change the paragraph = to:
Protected area:=20 the set of nodes that are protected from
modification by the = lock. =20 This set consists of nodes in the scope of
the lock and nodes in = subtrees=20 under them.

>
> 3. Section 2.1.1
>
> = s/However=20 it can be used to lock a candidate datastore/However it can be
> = used to=20 lock parts of a candidate datastore/

BALAZS: OK

> =
> 4.=20 The title of Section 2.1.1.1 seems to me to be more = appropriately
>=20 'Multiple managers handling the writable running datastore = with
>=20 overlapping sections'

BALAZS: OK

>
> 5. same = section -=20 I am a little nervous about saying 'The lock should be
> held = only a=20 short time (seconds rather then minutes)'. What if the lock
> = can be=20 help less than seconds or minutes at minimum because of the = size
> of=20 the records to be operated? Maybe better is to say 'The lock = should
> be=20 held the shortest possible time (e.g. seconds rather then=20 minutes)'.

BALAZS: OK

>
> 6. Section 2.1.1.2 - = better=20 (e.g. minutes, hours)

BALAZS: OK

>
> 7. = Section=20 2.1.1.3 - same comment as #5 for 2.1.1.1

BALAZS: OK

> =
> 8. page 6 - section 2.4.1 - 'these notes should be included = in=20 the
> protected area of the lock' - it seems to me that a = capitalized=20 SHOULD
> is appropriate here.

BALAZS: OK

> =
> 9.=20 Capitalization seems necessary also in 2.4.1.2 and also a change as = I
>=20 do not see in which situations if locking fails the client should = not
>=20 back-off. I realize this is client behavior, but the normative=20 language
> still seems to apply
>
> So:
> =
>=20 OLD:
>
>    To avoid this situation, = clients=20 should lock
>    everything they need in one=20 operation.  If locking fails, the = client
>    should=20 back-off, release any previously acquired locks, and retry=20 the
>    procedure after waiting some randomized = time=20 interval.
>
> NEW:
>
>    To = avoid=20 this situation, clients SHOULD lock
>    = everything they=20 need in one operation.  If locking fails, the=20 client
>    MUST back-off, release any previously = acquired locks, and SHOULD
> retry the
>    = procedure after waiting some randomized time interval.
> =

BALAZS:=20 OK

> 10. Last paragraph in section 3 - why is NOT = capitalized?=20

BALAZS: Just to emphasize it. I removed the=20 capitalization.

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

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

 draft-ietf-netconf-partial-lock-08.txt   draft-ietf-netconf-partial-lock-09.txt 
NETCONF B. Lengyel NETCONF B. Lengyel
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. = Bjorklund Intended status: Standards Track M. = Bjorklund
Expires: December 5, 2009=20 Tail-f Systems Expires: December 13, 2009=20 Tail-f Systems
June 03, 2009 June 11, 2009
Partial Lock RPC for NETCONF Partial Lock RPC for NETCONF
draft-ietf-netconf-partial-lock-08 draft-ietf-netconf-partial-lock-09
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full=20 conformance with the This Internet-Draft is submitted to IETF in full = conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or = IETF=20 Contributions published or made publicly
available before November = 10, 2008.=20 The person(s) controlling the
copyright in some of this = material=20 may not have granted the IETF
Trust the right to allow=20 modifications of such material outside the
IETF Standards Process. = Without=20 obtaining an adequate license from
the person(s) controlling = the=20 copyright in such materials, this
document may not be = modified outside=20 the IETF Standards Process, and
derivative works of it may = not be=20 created outside the IETF Standards
Process, except to format = it for=20 publication as an RFC or to
translate it into = languages other=20 than English.
Internet-Drafts are working documents of the = Internet=20 Engineering Internet-Drafts are working documents of the = Internet=20 Engineering
Task Force (IETF), its areas, and its working = groups.=20 Note that Task Force (IETF), its areas, and its working = groups.=20 Note that
other groups may also distribute working = documents as=20 Internet- other groups may also distribute working = documents as=20 Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a = maximum=20 of six months Internet-Drafts are draft documents valid for a = maximum=20 of six months
and may be updated, replaced, or obsoleted by = other=20 documents at any and may be updated, replaced, or obsoleted by = other=20 documents at any
time. It is inappropriate to use Internet-Drafts = as=20 reference time. It is inappropriate to use Internet-Drafts = as=20 reference
material or to cite them other than as "work in=20 progress." material or to cite them other than as "work in=20 progress."
The list of current Internet-Drafts can be = accessed at The list of current Internet-Drafts can be = accessed=20 at
http://www.ietf.org/i= etf/1id-abstracts.txt. http://www.ietf.org/i= etf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can = be=20 accessed at The list of Internet-Draft Shadow Directories = can be=20 accessed at
http://www.ietf.org/shadow.html<= /A>. http://www.ietf.org/shadow.html<= /A>.
This Internet-Draft will expire on December = 5, 2009. This Internet-Draft will expire on December = 13, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons = identified=20 as the Copyright (c) 2009 IETF Trust and the persons = identified=20 as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF = Trust's=20 Legal This document is subject to BCP 78 and the IETF = Trust's=20 Legal
Provisions Relating to IETF Documents in effect = on the=20 date of Provisions Relating to IETF Documents in effect = on the=20 date of
publication of this document (http://trustee.ietf.org/lic= ense-info). publication of this document (http://trustee.ietf.org/lic= ense-info).
Please review these documents carefully, as they = describe=20 your rights Please review these documents carefully, as they = describe your rights
skipping to change at = page 2,=20 line 10 skipping to change at = page 3,=20 line 7
Abstract Abstract
The NETCONF protocol defines the lock and unlock = RPCs,=20 used to lock The NETCONF protocol defines the lock and unlock = RPCs,=20 used to lock
entire configuration datastores. In some = situations, a=20 way to lock entire configuration datastores. In some = situations, a=20 way to lock
only parts of a configuration datastore is = required. This=20 document only parts of a configuration datastore is = required.=20 This document
defines a capability-based extension to the = NETCONF=20 protocol for defines a capability-based extension to the = NETCONF=20 protocol for
locking portions of a configuration = datastore. locking portions of a configuration = datastore.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . = . . . .=20 . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . = . . . .=20 . . . . . 4
1.1. Definition of Terms . . . . . . . . . . . = . . . .=20 . . . . 3 1.1. Definition of Terms . . . . . . . . . . . = . . . .=20 . . . . 4
2. Partial Locking Capability . . . . . . . . . = . . . .=20 . . . . . 3 2. Partial Locking Capability . . . . . . . . . = . . . .=20 . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . = . . . .=20 . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . = . . . .=20 . . . . 4
2.1.1. Usage Scenarios . . . . . . . . . . . . = . . . .=20 . . . 4 2.1.1. Usage Scenarios . . . . . . . . . . . . = . . . .=20 . . . 5
2.2. Dependencies . . . . . . . . . . . . . . . = . . . .=20 . . . . 6 2.2. Dependencies . . . . . . . . . . . . . . . = . . . .=20 . . . . 7
2.3. Capability Identifier . . . . . . . . . . = . . . .=20 . . . . 6 2.3. Capability Identifier . . . . . . . . . . = . . . .=20 . . . . 7
2.4. New Operations . . . . . . . . . . . . . . = . . . .=20 . . . . 6 2.4. New Operations . . . . . . . . . . . . . . = . . . .=20 . . . . 7
2.4.1. <partial-lock> . . . . . . . . . . = . . . .=20 . . . . . . 6 2.4.1. <partial-lock> . . . . . . . . . . = . . . .=20 . . . . . . 7
2.4.2. <partial-unlock> . . . . . . . . . = . . . .=20 . . . . . . 11 2.4.2. <partial-unlock> . . . . . . . . . = . . . .=20 . . . . . . 12
2.5. Modifications to Existing Operations . . . = . . . .=20 . . . . 11 2.5. Modifications to Existing Operations . . . = . . . .=20 . . . . 13
2.6. Interactions with Other Capabilities . . . = . . . .=20 . . . . 12 2.6. Interactions with Other Capabilities . . . = . . . .=20 . . . . 14
2.6.1. Candidate Configuration Capability . . . = . . . .=20 . . . 12 2.6.1. Candidate Configuration Capability . . . = . . . .=20 . . . 14
2.6.2. Confirmed Commit Capability . . . . . . = . . . .=20 . . . 12 2.6.2. Confirmed Commit Capability . . . . . . = . . . .=20 . . . 14
2.6.3. Distinct Startup Capability . . . . . . = . . . .=20 . . . 12 2.6.3. Distinct Startup Capability . . . . . . = . . . .=20 . . . 14
3. Security Considerations . . . . . . . . . . = . . . .=20 . . . . . 12 3. Security Considerations . . . . . . . . . . = . . . .=20 . . . . . 14
4. IANA Considerations . . . . . . . . . . . . = . . . .=20 . . . . . 13 4. IANA Considerations . . . . . . . . . . . . = . . . .=20 . . . . . 15
5. Appendix A - XML Schema for Partial Locking=20 (normative) . . 15 5. Appendix A - XML Schema for Partial Locking=20 (normative) . . 16
6. Appendix B - YANG Module for Partial = Locking 6. Appendix B - YANG Module for Partial = Locking
(non-normative) . . . . . . . . . . . . . . . . = . . . .=20 . . . 19 (non-normative) . . . . . . . . . . . . . . . . = . . . .=20 . . . 20
7. Appendix C - Usage Example - Reserving nodes = for=20 future 7. Appendix C - Usage Example - Reserving nodes = for=20 future
editing (non-normative) . . . . . . . . . . . . = . . . .=20 . . . 22 editing (non-normative) . . . . . . . . . . . . = . . . .=20 . . . 23
8. Appendix D - Change Log . . . . . . . . . . = . . . .=20 . . . . 27 8. Appendix D - Change Log . . . . . . . . . . = . . . .=20 . . . . 28
8.1. 07-08 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 27 8.1. 08-09 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28
8.2. 06-07 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 27 8.2. 07-08 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28
8.3. 05-06 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 27 8.3. 06-07 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28
8.4. 04-05 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 27 8.4. 05-06 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28
8.5. 03-04 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 27 8.5. 04-05 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28
8.6. 02-03 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28 8.6. 03-04 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28
8.7. 01-02 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28 8.7. 02-03 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 29
8.8. 00-01 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 28 8.8. 01-02 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 29
8.9. -00 . . . . . . . . . . . . . . . . . . . = . . . .=20 . . . . 28 8.9. 00-01 . . . . . . . . = . . . . .=20 . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . = . . . .=20 . . . . . 29 8.10. -00 . . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . = . . . .=20 . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . = . . . .=20 . . . . . 30
10.1. Normative References . . . . . . . . . . = . . . .=20 . . . . . 30 10. References . . . . . . . . . . . . . . . . = . . . .=20 . . . . . . 31
10.2. Informative References . . . . . . . . . = . . . .=20 . . . . . 30 10.1. Normative References . . . . . . . . . . = . . . .=20 . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . = . . . .=20 . . . . . . 31 10.2. Informative References . . . . . . . . . = . . . .=20 . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . = . . . .=20 . . . . . . 32
1. Introduction 1. Introduction
The [NETCONF] protocol describes the lock and = unlock=20 operations that The [NETCONF] protocol describes the lock and = unlock=20 operations that
operate on entire configuration datastores. = Often,=20 multiple operate on entire configuration datastores. = Often,=20 multiple
management sessions need to be able to modify the = configuration of a management sessions need to be able to modify = the=20 configuration of a
managed device in parallel. In these cases, = locking only=20 parts of a managed device in parallel. In these cases, = locking only=20 parts of a
configuration datastore is needed. This document = defines=20 a configuration datastore is needed. This document = defines=20 a
capability based extension to the NETCONF = protocol to=20 support partial capability based extension to the NETCONF = protocol to=20 support partial
locking of NETCONF datastores using a mechanism = based on=20 the existing locking of NETCONF datastores using a mechanism = based on=20 the existing
skipping to change at = page 3,=20 line 36 skipping to change at = page 4,=20 line 36
node in the conceptual XML datastore. It contains = an=20 absolute node in the conceptual XML datastore. It = contains an=20 absolute
path expression in abbreviated syntax, where = predicates=20 are used path expression in abbreviated syntax, where = predicates=20 are used
only to specify values for nodes defined as keys = to=20 distinguish only to specify values for nodes defined as keys = to=20 distinguish
multiple instances. multiple instances.
o Scope of the lock: initially the set of nodes = returned=20 by the o Scope of the lock: initially the set of nodes = returned=20 by the
XPath expressions in a successful partial-lock = operation.=20 The set XPath expressions in a successful partial-lock=20 operation. The set
might be modified if some of the nodes are = deleted. might be modified if some of the nodes are = deleted.
o Protected area: the set of nodes that are = protected=20 from o Protected area: the set of nodes that are = protected=20 from
modification by the lock. This consist of nodes in the scope of modification by the lock. This set=20 consists of nodes in the scope
the lock and nodes in subtrees under them. of the lock and nodes in subtrees under = them.
2. Partial Locking Capability 2. Partial Locking Capability
2.1. Overview 2.1. Overview
The :partial-lock capability indicates that the = device=20 supports the The :partial-lock capability indicates that the = device=20 supports the
locking of its configuration with a more limited = scope=20 than a locking of its configuration with a more limited = scope=20 than a
complete configuration datastore. The scope to be = locked=20 is complete configuration datastore. The scope to = be locked=20 is
specified by using restricted or full XPath = expressions.=20 Partial specified by using restricted or full XPath = expressions.=20 Partial
locking only affects configuration data. locking only affects configuration data.
skipping to change at = page 4,=20 line 27 skipping to change at = page 5,=20 line 27
2.1.1. Usage Scenarios 2.1.1. Usage Scenarios
In the following we describe a few scenarios for = partial=20 locking. In the following we describe a few scenarios for = partial=20 locking.
Partial locking is primarily useful towards the=20 running Partial locking is primarily useful towards the=20 running
configuration. However it can be used to lock a = candidate=20 datastore configuration. However it can be used to lock a=20 candidate datastore
as well. While scenarios using the running = datastore are=20 seen as the as well. While scenarios using the running = datastore are=20 seen as the
most important, as an example a scenario = involving the=20 candidate most important, as an example a scenario = involving the=20 candidate
datastore is also presented. Besides the three = described=20 here, there datastore is also presented. Besides the three = described=20 here, there
are many other usage scenarios possible. are many other usage scenarios possible.
2.1.1.1. Multiple managers handling the = writable=20 running datastore 2.1.1.1. Multiple managers handling the = writable=20 running datastore with
overlapping = sections
Multiple managers are handling the same NETCONF = agent=20 simultaneously. Multiple managers are handling the same NETCONF = agent=20 simultaneously.
The agent is handled via the writable running = datastore.=20 Each The agent is handled via the writable running = datastore.=20 Each
manager has his or her own task, which might = involve the=20 modification manager has his or her own task, which might = involve the=20 modification
of overlapping sections of the datastore. of overlapping sections of the datastore.
After collecting and analyzing input and = preparing the=20 NETCONF After collecting and analyzing input and = preparing the=20 NETCONF
operations off-line, the manager locks the areas = that are=20 important operations off-line, the manager locks the areas = that=20 are important
for his task using one single = <partial-lock>=20 operation. The manager for his task using one single = <partial-lock>=20 operation. The manager
executes a number of <edit-config> = operations to=20 modify the executes a number of <edit-config> = operations to=20 modify the
configuration, then releases the partial-lock. = The lock=20 should be configuration, then releases the partial-lock. = The lock=20 should be
held for only a = short time=20 (seconds rather then minutes). = The held for the shortest=20 possible time (e.g. seconds = rather=20 then
manager should collect all human input before = locking=20 anything. As minutes). The manager should collect all human = input=20 before locking
each manager locks only a part of the data = model,=20 usually multiple anything. As each manager locks only a part of = the data=20 model,
operators can execute the <edit-config>=20 operations simultaneously. usually multiple operators can execute the=20 <edit-config> operations
simultaneously.
2.1.1.2. Multiple managers handling the writable = running=20 datastore, 2.1.1.2. Multiple managers handling the writable = running=20 datastore,
distinct management areas distinct management areas
Multiple managers are handling the same NETCONF = agent=20 simultaneously. Multiple managers are handling the same NETCONF = agent=20 simultaneously.
The agent is handled via the writable running = datastore.=20 The agent's The agent is handled via the writable running = datastore.=20 The agent's
data model contains a number of well defined = separate=20 areas that can data model contains a number of well defined = separate=20 areas that can
be configured without impacting other areas. An = example=20 can be a be configured without impacting other areas. An = example=20 can be a
server with multiple applications running on it, = or a=20 number of a server with multiple applications running on it, = or a=20 number of a
network elements with a common NETCONF agent for=20 management. network elements with a common NETCONF agent for = management.
Each manager has his or her own task, which does = not=20 involve the Each manager has his or her own task, which does = not=20 involve the
modification of overlapping sections of the = datastore. modification of overlapping sections of the=20 datastore.
The manager locks his area with a = <partial-lock>=20 operation, uses a The manager locks his area with a = <partial-lock>=20 operation, uses a
number of <edit-config> commands to modify = it,=20 later releases the number of <edit-config> commands to modify = it,=20 later releases the
lock. As each manager has his functional area = assigned to=20 him, and lock. As each manager has his functional area = assigned=20 to him, and
he locks only that area, multiple managers can = edit the=20 configuration he locks only that area, multiple managers can = edit the=20 configuration
simultaneously. Locks can be held for extended = periods=20 (minutes, simultaneously. Locks can be held for extended = periods=20 (e.g.
hours), as this will not hinder other = managers. minutes, hours), as = this will=20 not hinder other managers.
This scenario assumes, that the global lock = operation=20 from [NETCONF] This scenario assumes, that the global lock = operation=20 from [NETCONF]
is not used. is not used.
2.1.1.3. Multiple managers handling the candidate = datastore in a semi- 2.1.1.3. Multiple managers handling the = candidate=20 datastore in a semi-
coordinated work mode coordinated work mode
Multiple managers are handling the same NETCONF = agent=20 simultaneously. Multiple managers are handling the same NETCONF = agent=20 simultaneously.
The agent is handled via the candidate datastore. = Each=20 manager has The agent is handled via the candidate = datastore. Each=20 manager has
his or her own task which might involve the = modification=20 of his or her own task which might involve the = modification=20 of
overlapping sections of the datastore. overlapping sections of the datastore.
After collecting and analyzing input and = preparing the=20 NETCONF After collecting and analyzing input and = preparing the=20 NETCONF
operations off-line, the manager locks the areas = that are=20 important operations off-line, the manager locks the areas = that=20 are important
for his task using one single = <partial-lock>=20 operation in both the for his task using one single = <partial-lock>=20 operation in both the
candidate and the running datastore. He executes = a number=20 of <edit- candidate and the running datastore. He executes = a=20 number of <edit-
config> operations to modify the = configuration, then=20 releases the config> operations to modify the = configuration, then=20 releases the
partial-lock. The lock should be held for only a short time (seconds partial-lock. The lock should only be held for the = shortest=20 possible
rather then minutes). time (e.g. seconds = rather=20 then minutes).
Operators coordinate with each other. When all of = them=20 finish their Operators coordinate with each other. When all = of them=20 finish their
tasks one of them orders commit. If any of the = operators=20 are still tasks one of them orders commit. If any of the = operators=20 are still
working, and holds a lock, the commit will fail, = and will=20 need to be working, and holds a lock, the commit will fail, = and=20 will need to be
repeated after all managers finish. repeated after all managers finish.
Warning: When multiple managers use the candidate = configuration in Warning: When multiple managers use the = candidate=20 configuration in
parallel, there is a risk that the interaction of = access=20 control parallel, there is a risk that the interaction = of access=20 control
(which is still implementation specific at the = time of=20 this writing) (which is still implementation specific at the = time of=20 this writing)
and the commit operation might result in a = dead-lock, as=20 illustrated and the commit operation might result in a = dead-lock, as=20 illustrated
skipping to change at = page 8,=20 line 15 skipping to change at = page 9,=20 line 17
The <partial-lock> operation is designed = for=20 simplicity, so when a The <partial-lock> operation is designed = for=20 simplicity, so when a
partial lock is executed you get what you asked = for: a=20 set of nodes partial lock is executed you get what you asked = for: a=20 set of nodes
that are locked for writing. As a consequence = users must=20 observe the that are locked for writing. As a consequence = users must=20 observe the
following: following:
o Locking does not affect read operations. o Locking does not affect read operations.
o If part of a datastore is locked, this has no = effect on=20 any o If part of a datastore is locked, this has no = effect=20 on any
unlocked parts of the datastore. If this is a = problem=20 (e.g., unlocked parts of the datastore. If this is a = problem=20 (e.g.,
changes depend on data values or nodes outside = the=20 protected part changes depend on data values or nodes outside = the=20 protected part
of the datastore), these nodes should be included in the protected of the datastore), these nodes SHOULD be included in the protected
area of the lock. area of the lock.
o Configuration data can be edited both inside = and=20 outside the o Configuration data can be edited both inside = and=20 outside the
protected area of a lock. It is the = responsibility of the=20 NETCONF protected area of a lock. It is the = responsibility of=20 the NETCONF
client application to lock all relevant parts of = a=20 datastore that client application to lock all relevant parts of = a=20 datastore that
are crucial for a specific management = action. are crucial for a specific management = action.
Note: The <partial-lock> operation does not = modify=20 the global <lock> Note: The <partial-lock> operation does = not modify=20 the global <lock>
operation defined in the base NETCONF Protocol = [NETCONF].=20 If part of operation defined in the base NETCONF Protocol=20 [NETCONF]. If part of
a datastore is already locked by = <partial-lock>,=20 then a global lock a datastore is already locked by = <partial-lock>,=20 then a global lock
skipping to change at = page 10,=20 line 46 skipping to change at = page 12,=20 line 35
not an Instance Identifier, the <error-tag> = is=20 'invalid-value', the not an Instance Identifier, the = <error-tag> is=20 'invalid-value', the
<error-app-tag> is = 'invalid-lock-specification'. <error-app-tag> is=20 'invalid-lock-specification'.
If access control denies the partial lock, the=20 <error-tag> is If access control denies the partial lock, the=20 <error-tag> is
'access-denied'. 'access-denied'.
2.4.1.2. Deadlock Avoidance 2.4.1.2. Deadlock Avoidance
As with most locking systems, it is possible that = two=20 management As with most locking systems, it is possible = that two=20 management
sessions trying to lock different parts of the=20 configuration could sessions trying to lock different parts of the=20 configuration could
become dead-locked. To avoid this situation, = clients=20 should lock become dead-locked. To avoid this situation, = clients=20 SHOULD lock
everything they need in one operation. If locking = fails,=20 the client everything they need in one operation. If = locking fails,=20 the client
should back-off, = release any=20 previously acquired locks, and retry the MUST back-off, = release any=20 previously acquired locks, and SHOULD
procedure after waiting some randomized time=20 interval. retry the procedure after waiting some = randomized time=20 interval.
2.4.2. <partial-unlock> 2.4.2. <partial-unlock>
The operation unlocks the parts of the datastores = that=20 were The operation unlocks the parts of the = datastores that=20 were
previously locked using <partial-lock> = during the=20 same session. previously locked using <partial-lock> = during the=20 same session.
Parameters: Parameters:
lock-id: Identity of the lock to be unlocked. = This=20 lock-id MUST lock-id: Identity of the lock to be unlocked. = This=20 lock-id MUST
have been received as a response to a lock = request by the=20 manager have been received as a response to a lock = request by=20 the manager
skipping to change at = page 13,=20 line 29 skipping to change at = page 15,=20 line 19
users's sessions. users's sessions.
The NETCONF server may log partial lock requests = in an=20 audit The NETCONF server may log partial lock requests = in an=20 audit
trail. trail.
A lock that is hung for some reason (e.g., a = broken TCP=20 connection A lock that is hung for some reason (e.g., a = broken TCP=20 connection
that the server has not yet recognised) can be = released=20 using another that the server has not yet recognised) can be = released=20 using another
NETCONF session by explicitly killing the session = owning=20 that lock NETCONF session by explicitly killing the = session owning=20 that lock
using the <kill-session> operation. using the <kill-session> operation.
Partial locking is NOT an=20 authorization mechanism; it SHOULD NOT be Partial locking is not an=20 authorization mechanism; it SHOULD NOT be
used to provide security or access control. = Partial=20 locking SHOULD used to provide security or access control. = Partial=20 locking SHOULD
only be used as a mechanism for providing = consistency=20 when multiple only be used as a mechanism for providing = consistency=20 when multiple
managers are trying to configure the node. It is = vital=20 that users managers are trying to configure the node. It is = vital=20 that users
easily understand the exact scope of a lock. This = is why=20 the scope easily understand the exact scope of a lock. = This is why=20 the scope
is determined when granting a lock and is not = modified=20 thereafter. is determined when granting a lock and is not = modified=20 thereafter.
4. IANA Considerations 4. IANA Considerations
This document registers two URIs for the NETCONF = XML=20 namespace in the This document registers two URIs for the NETCONF = XML=20 namespace in the
IETF XML registry [RFC3688]. Note that the = capability URN=20 is IETF XML registry [RFC3688]. Note that the = capability=20 URN is
skipping to change at = page 27,=20 line 7 skipping to change at = page 28,=20 line 7
<nc:rpc=20 xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0" <nc:rpc=20 xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
message-id=3D"105"> message-id=3D"105">
<partial-unlock> <partial-unlock>
<lock-id>1</lock-id> <lock-id>1</lock-id>
</partial-unlock> </partial-unlock>
</nc:rpc> </nc:rpc>
8. Appendix D - Change Log 8. Appendix D - Change Log
8.1. 07-08 8.1. 08-09
Clarifications Clarifications
8.2. 06-07 8.2. 07-08
Clarifications
8.3. 06-07
Changed XSD and YANG to allow additional = proprietary=20 datastores to be Changed XSD and YANG to allow additional = proprietary=20 datastores to be
locked. locked.
8.3. 05-06 8.4. 05-06
Added usage example Added usage example
Clarified error messages Clarified error messages
Clarified interaction with edit-config=20 continue-on-error Clarified interaction with edit-config=20 continue-on-error
Improved YANG: indentation, canonical order, = contact=20 info Improved YANG: indentation, canonical order, = contact=20 info
Added usage example in appendix C Added usage example in appendix C
Synchronized YANG and XSD Synchronized YANG and XSD
8.4. 04-05 8.5. 04-05
Language and editorial updates Language and editorial updates
all app-tags are with dashes without spaces all app-tags are with dashes without spaces
Added usage scenarios Added usage scenarios
Changed encoding Changed encoding
Clarified definitions, separated scope of lock = and=20 protected area Clarified definitions, separated scope of lock = and=20 protected area
8.5. 03-04 8.6. 03-04
Minor clarifications Minor clarifications
Added list of locked-nodes to the output of=20 partial-lock. Added list of locked-nodes to the output of=20 partial-lock.
Added <target> wrapper around datastore = names. Added <target> wrapper around datastore = names.
Allowed atomic/one operation locking of datastore = parts=20 in multiple Allowed atomic/one operation locking of = datastore parts=20 in multiple
datastores. datastores.
Improved English (hopefully) Improved English (hopefully)
Removed the <data> element from rpc-reply = following=20 the text of Removed the <data> element from rpc-reply=20 following the text of
rfc4741. rfc4741.
8.6. 02-03 8.7. 02-03
Minor clarifications Minor clarifications
Same descriptions in XSD and YANG. Same descriptions in XSD and YANG.
8.7. 01-02 8.8. 01-02
Made XSD normative Made XSD normative
Clarified that no specific access control is = assumed. Clarified that no specific access control is = assumed.
Clarified that non-existing nodes are NOT covered = by the=20 lock, even Clarified that non-existing nodes are NOT = covered by the=20 lock, even
if they where existing and covered by the lock = when it=20 was originally if they where existing and covered by the lock = when it=20 was originally
granted. granted.
Some rewording Some rewording
Added app-tags for two of the error cases. Added app-tags for two of the error cases.
Made YANG an informative reference Made YANG an informative reference
Enhanced security considerations. Enhanced security considerations.
8.8. 00-01 8.9. 00-01
Added YANG module. Added YANG module.
8.9. -00 8.10. -00
Created from = draft-lengyel-ngo-partial-lock-01.txt Created from = draft-lengyel-ngo-partial-lock-01.txt
9. Acknowledgements 9. Acknowledgements
Thanks to Andy Bierman, Sharon Chisholm, Phil = Shafer ,=20 David Thanks to Andy Bierman, Sharon Chisholm, Phil = Shafer ,=20 David
Harrington, Mehmet Ersue, Wes Hardaker, Juergen=20 Schoenwaelder, Washam Harrington, Mehmet Ersue, Wes Hardaker, Juergen=20 Schoenwaelder, Washam
Fan and many other members of the NETCONF WG for=20 providing important Fan and many other members of the NETCONF WG for = providing important
input to this document. input to this document.
 End of changes. = 25 change=20 blocks. 
65 lines changed or deleted 82 lines changed or added

This html diff = was produced=20 by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools= /rfcdiff/=20

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


Internal Virus Database is out of date.
Checked by AVG - = www.avg.com
Version: 8.5.339 / = Virus=20 Database: 270.12.58/2164 - Release Date: 06/08/09=20 17:59:00
------=_NextPart_000_0AA8_01C9FA66.1BAFBD00-- From dromasca@avaya.com Wed Jul 1 07:15: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 5FDE128C54D for ; Wed, 1 Jul 2009 07:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6DazH1+u3IQ for ; Wed, 1 Jul 2009 07:15:48 -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 6D0DF28C531 for ; Wed, 1 Jul 2009 07:15:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,323,1243828800"; d="scan'208,217";a="165989283" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Jul 2009 10:15:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Jul 2009 10:15:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9FA56.54BB5523" Date: Wed, 1 Jul 2009 16:15:01 +0200 Message-ID: In-Reply-To: <4D20A10EDC1B44948C1EDA4D2ECFFDC8@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt thread-index: Acn6VWOkrQGQtPKkTWqpYp9Alqn9OgAANRyw References: <4A30CD50.5020305@ericsson.com> <4D20A10EDC1B44948C1EDA4D2ECFFDC8@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Balazs Lengyel" , "Martin Bjorklund" Cc: netconf mailing list Subject: Re: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:15:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FA56.54BB5523 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The February text for the disclaimer for pre-RFC5378 should be OK. =20 Dan =20 ________________________________ From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=20 Sent: Wednesday, July 01, 2009 5:08 PM To: Balazs Lengyel; Romascanu, Dan (Dan); Martin Bjorklund Cc: netconf mailing list Subject: Re: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt =09 =09 Dan, is there any new text that Balazs should include in the next (hopefully final) revision? I mean w.r.t. IPR related text? =20 Bert =20 ----- Original Message -----=20 From: Balazs Lengyel =20 To: Romascanu, Dan (Dan) ; Martin Bjorklund =20 Cc: netconf mailing list =20 Sent: Thursday, June 11, 2009 11:24 AM Subject: Re: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt Hello Dan, Martin, Thanks for the comments. See below. =09 I attached a diff between the current 08 version and the future 09 version as it stands at the=20 moment. Balazs =09 Romascanu, Dan (Dan) wrote: > This document is ready to be sent to IETF Last Call, and I will send it > immediately after sending this message. Please consider the comments > below together with the other IETF Last Call comments. >=20 > 1. IPR and Copyright issues >=20 > Running idnits results in the following warning:=20 >=20 > =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, but was > first submitted before 10 November 2008. Should you add the > disclaimer? > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.).=20 >=20 > trust-12-feb-2009 Section 6.c.iii text: > "This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. >=20 > Without obtaining an adequate license from the person(s) > controlling the copyright in such materials, this document may not > be modified outside the IETF Standards Process, and derivative > works of it may not be created outside the IETF Standards Process, > except to format it for publication as an RFC or to translate it > into languages other than English." =09 BALAZS: Changed IPR to pre5378Trust200902. =09 >=20 > Also, the schema in Appendix A will need to include the full text of the > BSD license for code or a reference to it. This issue is still debated > with the Trust, so no action by now on this.=20 =09 BALAZS: So I should wait for further information. When and where can I find this, or will the=20 chairs or you supply it? =09 >=20 > 2. last paragraph in Section 1.1=20 >=20 > s/This consist/These consist/ =09 BALAZS: Is OK if I change the paragraph to: Protected area: the set of nodes that are protected from modification by the lock. This set consists of nodes in the scope of the lock and nodes in subtrees under them. =09 >=20 > 3. Section 2.1.1 >=20 > s/However it can be used to lock a candidate datastore/However it can be > used to lock parts of a candidate datastore/ =09 BALAZS: OK =09 >=20 > 4. The title of Section 2.1.1.1 seems to me to be more appropriately > 'Multiple managers handling the writable running datastore with > overlapping sections' =09 BALAZS: OK =09 >=20 > 5. same section - I am a little nervous about saying 'The lock should be > held only a short time (seconds rather then minutes)'. What if the lock > can be help less than seconds or minutes at minimum because of the size > of the records to be operated? Maybe better is to say 'The lock should > be held the shortest possible time (e.g. seconds rather then minutes)'. =09 BALAZS: OK =09 >=20 > 6. Section 2.1.1.2 - better (e.g. minutes, hours) =09 BALAZS: OK =09 >=20 > 7. Section 2.1.1.3 - same comment as #5 for 2.1.1.1 =09 BALAZS: OK =09 >=20 > 8. page 6 - section 2.4.1 - 'these notes should be included in the > protected area of the lock' - it seems to me that a capitalized SHOULD > is appropriate here.=20 =09 BALAZS: OK =09 >=20 > 9. Capitalization seems necessary also in 2.4.1.2 and also a change as I > do not see in which situations if locking fails the client should not > back-off. I realize this is client behavior, but the normative language > still seems to apply >=20 > So:=20 >=20 > OLD:=20 >=20 > To avoid this situation, clients should lock > everything they need in one operation. If locking fails, the client > should back-off, release any previously acquired locks, and retry the > procedure after waiting some randomized time interval. >=20 > NEW: >=20 > To avoid this situation, clients SHOULD lock > everything they need in one operation. If locking fails, the client > MUST back-off, release any previously acquired locks, and SHOULD > retry the > procedure after waiting some randomized time interval. >=20 =09 BALAZS: OK =09 > 10. Last paragraph in section 3 - why is NOT capitalized?=20 =09 BALAZS: Just to emphasize it. I removed the capitalization. =09 >=20 > Dan >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 =09 --=20 Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com =09 =09 ________________________________ =09 draft-ietf-netconf-partial-lock-08.txt draft-ietf-netconf-partial-lock-09.txt =09 =09 NETCONF B. Lengyel NETCONF B. Lengyel =09 Internet-Draft Ericsson Internet-Draft Ericsson =09 Intended status: Standards Track M. Bjorklund Intended status: Standards Track M. Bjorklund =09 =09 Expires: December 5, 2009 Tail-f Systems Expires: December 13, 2009 Tail-f Systems =09 June 03, 2009 June 11, 2009 =09 =09 Partial Lock RPC for NETCONF Partial Lock RPC for NETCONF =09 =09 draft-ietf-netconf-partial-lock-08 draft-ietf-netconf-partial-lock-09 =09 =09 Status of this Memo Status of this Memo =09 =09 This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the =09 =09 provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material =09 from IETF Documents or IETF Contributions published or made publicly =09 available before November 10, 2008. The person(s) controlling the =09 copyright in some of this material may not have granted the IETF =09 Trust the right to allow modifications of such material outside the =09 IETF Standards Process. Without obtaining an adequate license from =09 the person(s) controlling the copyright in such materials, this =09 document may not be modified outside the IETF Standards Process, and =09 derivative works of it may not be created outside the IETF Standards =09 Process, except to format it for publication as an RFC or to =09 translate it into languages other than English. =09 Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering =09 Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that =09 other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet- =09 Drafts. Drafts. =09 =09 Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months =09 and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any =09 time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference =09 material or to cite them other than as "work in progress." material or to cite them other than as "work in progress." =09 =09 The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at =09 http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt. =09 =09 The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html. =09 =09 =09 This Internet-Draft will expire on December 5, 2009. This Internet-Draft will expire on December 13, 2009. =09 =09 Copyright Notice Copyright Notice =09 =09 Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the =09 document authors. All rights reserved. document authors. All rights reserved. =09 =09 This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal =09 Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of =09 publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info). =09 Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights =09 =09 skipping to change at page 2, line 10 skipping to change at page 3, line 7 =09 Abstract Abstract =09 =09 The NETCONF protocol defines the lock and unlock RPCs, used to lock The NETCONF protocol defines the lock and unlock RPCs, used to lock =09 entire configuration datastores. In some situations, a way to lock entire configuration datastores. In some situations, a way to lock =09 only parts of a configuration datastore is required. This document only parts of a configuration datastore is required. This document =09 defines a capability-based extension to the NETCONF protocol for defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. locking portions of a configuration datastore. =09 =09 Table of Contents Table of Contents =09 =09 =09 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 =09 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 3 2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 4 =09 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 =09 2.1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . 4 2.1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . 5 =09 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 7 =09 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 6 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 7 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 6 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 7 =09 2.4.1. . . . . . . . . . . . . . . . . . . . . 6 2.4.1. . . . . . . . . . . . . . . . . . . . . 7 =09 2.4.2. . . . . . . . . . . . . . . . . . . . 11 2.4.2. . . . . . . . . . . . . . . . . . . . 12 2.5. Modifications to Existing Operations . . . . . . . . . . . 11 2.5. Modifications to Existing Operations . . . . . . . . . . . 13 =09 2.6. Interactions with Other Capabilities . . . . . . . . . . . 12 2.6. Interactions with Other Capabilities . . . . . . . . . . . 14 =09 2.6.1. Candidate Configuration Capability . . . . . . . . . . 12 2.6.1. Candidate Configuration Capability . . . . . . . . . . 14 2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 12 2.6.2. Confirmed Commit Capability . . . . . . . . . . . . . 14 =09 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 12 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 14 =09 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 =09 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 =09 5. Appendix A - XML Schema for Partial Locking (normative) . . 15 5. Appendix A - XML Schema for Partial Locking (normative) . . 16 =09 6. Appendix B - YANG Module for Partial Locking 6. Appendix B - YANG Module for Partial Locking =09 =09 (non-normative) . . . . . . . . . . . . . . . . . . . . . . . 19 (non-normative) . . . . . . . . . . . . . . . . . . . . . . . 20 7. Appendix C - Usage Example - Reserving nodes for future 7. Appendix C - Usage Example - Reserving nodes for future =09 =09 editing (non-normative) . . . . . . . . . . . . . . . . . . . 22 editing (non-normative) . . . . . . . . . . . . . . . . . . . 23 8. Appendix D - Change Log . . . . . . . . . . . . . . . . . . 27 8. Appendix D - Change Log . . . . . . . . . . . . . . . . . . 28 =09 8.1. 07-08 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. 08-09 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =09 8.2. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. 07-08 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =09 8.3. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =09 8.4. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.4. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =09 8.5. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.5. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =09 8.6. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.6. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 =09 8.7. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.7. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =09 8.8. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.8. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =09 8.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.9. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =09 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 8.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 =09 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 =09 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 =09 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 =09 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 =09 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 =09 =09 1. Introduction 1. Introduction =09 =09 The [NETCONF] protocol describes the lock and unlock operations that The [NETCONF] protocol describes the lock and unlock operations that =09 operate on entire configuration datastores. Often, multiple operate on entire configuration datastores. Often, multiple =09 management sessions need to be able to modify the configuration of a management sessions need to be able to modify the configuration of a =09 managed device in parallel. In these cases, locking only parts of a managed device in parallel. In these cases, locking only parts of a =09 configuration datastore is needed. This document defines a configuration datastore is needed. This document defines a =09 capability based extension to the NETCONF protocol to support partial capability based extension to the NETCONF protocol to support partial =09 locking of NETCONF datastores using a mechanism based on the existing locking of NETCONF datastores using a mechanism based on the existing =09 =09 skipping to change at page 3, line 36 skipping to change at page 4, line 36 =09 node in the conceptual XML datastore. It contains an absolute node in the conceptual XML datastore. It contains an absolute =09 path expression in abbreviated syntax, where predicates are used path expression in abbreviated syntax, where predicates are used only to specify values for nodes defined as keys to distinguish only to specify values for nodes defined as keys to distinguish =09 multiple instances. multiple instances. =09 =09 o Scope of the lock: initially the set of nodes returned by the o Scope of the lock: initially the set of nodes returned by the =09 XPath expressions in a successful partial-lock operation. The set XPath expressions in a successful partial-lock operation. The set =09 might be modified if some of the nodes are deleted. might be modified if some of the nodes are deleted. =09 =09 o Protected area: the set of nodes that are protected from o Protected area: the set of nodes that are protected from =09 =09 modification by the lock. This consist of nodes in the scope of modification by the lock. This set consists of nodes in the scope the lock and nodes in subtrees under them. of the lock and nodes in subtrees under them. =09 =09 2. Partial Locking Capability 2. Partial Locking Capability =09 =09 2.1. Overview 2.1. Overview =09 =09 The :partial-lock capability indicates that the device supports the The :partial-lock capability indicates that the device supports the =09 locking of its configuration with a more limited scope than a locking of its configuration with a more limited scope than a =09 complete configuration datastore. The scope to be locked is complete configuration datastore. The scope to be locked is =09 specified by using restricted or full XPath expressions. Partial specified by using restricted or full XPath expressions. Partial locking only affects configuration data. locking only affects configuration data. =09 =09 skipping to change at page 4, line 27 skipping to change at page 5, line 27 =09 2.1.1. Usage Scenarios 2.1.1. Usage Scenarios =09 =09 In the following we describe a few scenarios for partial locking. In the following we describe a few scenarios for partial locking. =09 Partial locking is primarily useful towards the running Partial locking is primarily useful towards the running =09 configuration. However it can be used to lock a candidate datastore configuration. However it can be used to lock a candidate datastore =09 as well. While scenarios using the running datastore are seen as the as well. While scenarios using the running datastore are seen as the =09 most important, as an example a scenario involving the candidate most important, as an example a scenario involving the candidate datastore is also presented. Besides the three described here, there datastore is also presented. Besides the three described here, there =09 are many other usage scenarios possible. are many other usage scenarios possible. =09 =09 =09 2.1.1.1. Multiple managers handling the writable running datastore 2.1.1.1. Multiple managers handling the writable running datastore with =09 overlapping sections =09 =09 Multiple managers are handling the same NETCONF agent simultaneously. Multiple managers are handling the same NETCONF agent simultaneously. =09 The agent is handled via the writable running datastore. Each The agent is handled via the writable running datastore. Each =09 manager has his or her own task, which might involve the modification manager has his or her own task, which might involve the modification =09 of overlapping sections of the datastore. of overlapping sections of the datastore. =09 =09 After collecting and analyzing input and preparing the NETCONF After collecting and analyzing input and preparing the NETCONF =09 operations off-line, the manager locks the areas that are important operations off-line, the manager locks the areas that are important =09 for his task using one single operation. The manager for his task using one single operation. The manager =09 executes a number of operations to modify the executes a number of operations to modify the =09 configuration, then releases the partial-lock. The lock should be configuration, then releases the partial-lock. The lock should be =09 =09 held for only a short time (seconds rather then minutes). The held for the shortest possible time (e.g. seconds rather then =09 manager should collect all human input before locking anything. As minutes). The manager should collect all human input before locking =09 each manager locks only a part of the data model, usually multiple anything. As each manager locks only a part of the data model, =09 operators can execute the operations simultaneously. usually multiple operators can execute the operations =09 simultaneously. =09 =09 2.1.1.2. Multiple managers handling the writable running datastore, 2.1.1.2. Multiple managers handling the writable running datastore, =09 distinct management areas distinct management areas =09 =09 Multiple managers are handling the same NETCONF agent simultaneously. Multiple managers are handling the same NETCONF agent simultaneously. =09 The agent is handled via the writable running datastore. The agent's The agent is handled via the writable running datastore. The agent's =09 data model contains a number of well defined separate areas that can data model contains a number of well defined separate areas that can =09 be configured without impacting other areas. An example can be a be configured without impacting other areas. An example can be a server with multiple applications running on it, or a number of a server with multiple applications running on it, or a number of a =09 network elements with a common NETCONF agent for management. network elements with a common NETCONF agent for management. =09 =09 Each manager has his or her own task, which does not involve the Each manager has his or her own task, which does not involve the modification of overlapping sections of the datastore. modification of overlapping sections of the datastore. =09 =09 The manager locks his area with a operation, uses a The manager locks his area with a operation, uses a =09 number of commands to modify it, later releases the number of commands to modify it, later releases the =09 lock. As each manager has his functional area assigned to him, and lock. As each manager has his functional area assigned to him, and =09 he locks only that area, multiple managers can edit the configuration he locks only that area, multiple managers can edit the configuration =09 =09 simultaneously. Locks can be held for extended periods (minutes, simultaneously. Locks can be held for extended periods (e.g. =09 hours), as this will not hinder other managers. minutes, hours), as this will not hinder other managers. =09 =09 This scenario assumes, that the global lock operation from [NETCONF] This scenario assumes, that the global lock operation from [NETCONF] =09 is not used. is not used. =09 =09 2.1.1.3. Multiple managers handling the candidate datastore in a semi- 2.1.1.3. Multiple managers handling the candidate datastore in a semi- =09 coordinated work mode coordinated work mode =09 =09 Multiple managers are handling the same NETCONF agent simultaneously. Multiple managers are handling the same NETCONF agent simultaneously. =09 The agent is handled via the candidate datastore. Each manager has The agent is handled via the candidate datastore. Each manager has =09 his or her own task which might involve the modification of his or her own task which might involve the modification of =09 overlapping sections of the datastore. overlapping sections of the datastore. =09 =09 After collecting and analyzing input and preparing the NETCONF After collecting and analyzing input and preparing the NETCONF =09 operations off-line, the manager locks the areas that are important operations off-line, the manager locks the areas that are important =09 for his task using one single operation in both the for his task using one single operation in both the =09 candidate and the running datastore. He executes a number of operations to modify the configuration, then releases the config> operations to modify the configuration, then releases the =09 =09 partial-lock. The lock should be held for only a short time (seconds partial-lock. The lock should only be held for the shortest possible =09 rather then minutes). time (e.g. seconds rather then minutes). =09 =09 Operators coordinate with each other. When all of them finish their Operators coordinate with each other. When all of them finish their =09 tasks one of them orders commit. If any of the operators are still tasks one of them orders commit. If any of the operators are still =09 working, and holds a lock, the commit will fail, and will need to be working, and holds a lock, the commit will fail, and will need to be =09 repeated after all managers finish. repeated after all managers finish. =09 =09 Warning: When multiple managers use the candidate configuration in Warning: When multiple managers use the candidate configuration in =09 parallel, there is a risk that the interaction of access control parallel, there is a risk that the interaction of access control (which is still implementation specific at the time of this writing) (which is still implementation specific at the time of this writing) =09 and the commit operation might result in a dead-lock, as illustrated and the commit operation might result in a dead-lock, as illustrated =09 =09 skipping to change at page 8, line 15 skipping to change at page 9, line 17 =09 The operation is designed for simplicity, so when a The operation is designed for simplicity, so when a =09 partial lock is executed you get what you asked for: a set of nodes partial lock is executed you get what you asked for: a set of nodes =09 that are locked for writing. As a consequence users must observe the that are locked for writing. As a consequence users must observe the =09 following: following: =09 =09 o Locking does not affect read operations. o Locking does not affect read operations. =09 =09 o If part of a datastore is locked, this has no effect on any o If part of a datastore is locked, this has no effect on any =09 unlocked parts of the datastore. If this is a problem (e.g., unlocked parts of the datastore. If this is a problem (e.g., =09 changes depend on data values or nodes outside the protected part changes depend on data values or nodes outside the protected part =09 =09 of the datastore), these nodes should be included in the protected of the datastore), these nodes SHOULD be included in the protected =09 area of the lock. area of the lock. =09 =09 o Configuration data can be edited both inside and outside the o Configuration data can be edited both inside and outside the =09 protected area of a lock. It is the responsibility of the NETCONF protected area of a lock. It is the responsibility of the NETCONF =09 client application to lock all relevant parts of a datastore that client application to lock all relevant parts of a datastore that =09 are crucial for a specific management action. are crucial for a specific management action. =09 =09 Note: The operation does not modify the global Note: The operation does not modify the global =09 operation defined in the base NETCONF Protocol [NETCONF]. If part of operation defined in the base NETCONF Protocol [NETCONF]. If part of =09 a datastore is already locked by , then a global lock a datastore is already locked by , then a global lock =09 =09 skipping to change at page 10, line 46 skipping to change at page 12, line 35 =09 not an Instance Identifier, the is 'invalid-value', the not an Instance Identifier, the is 'invalid-value', the =09 is 'invalid-lock-specification'. is 'invalid-lock-specification'. =09 =09 If access control denies the partial lock, the is If access control denies the partial lock, the is =09 'access-denied'. 'access-denied'. =09 =09 2.4.1.2. Deadlock Avoidance 2.4.1.2. Deadlock Avoidance =09 =09 As with most locking systems, it is possible that two management As with most locking systems, it is possible that two management sessions trying to lock different parts of the configuration could sessions trying to lock different parts of the configuration could =09 =09 become dead-locked. To avoid this situation, clients should lock become dead-locked. To avoid this situation, clients SHOULD lock everything they need in one operation. If locking fails, the client everything they need in one operation. If locking fails, the client =09 =09 should back-off, release any previously acquired locks, and retry the MUST back-off, release any previously acquired locks, and SHOULD =09 procedure after waiting some randomized time interval. retry the procedure after waiting some randomized time interval. =09 2.4.2. 2.4.2. =09 =09 The operation unlocks the parts of the datastores that were The operation unlocks the parts of the datastores that were =09 previously locked using during the same session. previously locked using during the same session. =09 =09 Parameters: Parameters: =09 =09 lock-id: Identity of the lock to be unlocked. This lock-id MUST lock-id: Identity of the lock to be unlocked. This lock-id MUST =09 have been received as a response to a lock request by the manager have been received as a response to a lock request by the manager =09 =09 skipping to change at page 13, line 29 skipping to change at page 15, line 19 =09 users's sessions. users's sessions. =09 =09 The NETCONF server may log partial lock requests in an audit The NETCONF server may log partial lock requests in an audit =09 trail. trail. =09 =09 A lock that is hung for some reason (e.g., a broken TCP connection A lock that is hung for some reason (e.g., a broken TCP connection =09 that the server has not yet recognised) can be released using another that the server has not yet recognised) can be released using another =09 NETCONF session by explicitly killing the session owning that lock NETCONF session by explicitly killing the session owning that lock =09 using the operation. using the operation. =09 =09 =09 Partial locking is NOT an authorization mechanism; it SHOULD NOT be Partial locking is not an authorization mechanism; it SHOULD NOT be =09 used to provide security or access control. Partial locking SHOULD used to provide security or access control. Partial locking SHOULD =09 only be used as a mechanism for providing consistency when multiple only be used as a mechanism for providing consistency when multiple =09 managers are trying to configure the node. It is vital that users managers are trying to configure the node. It is vital that users =09 easily understand the exact scope of a lock. This is why the scope easily understand the exact scope of a lock. This is why the scope =09 is determined when granting a lock and is not modified thereafter. is determined when granting a lock and is not modified thereafter. =09 =09 4. IANA Considerations 4. IANA Considerations =09 =09 This document registers two URIs for the NETCONF XML namespace in the This document registers two URIs for the NETCONF XML namespace in the =09 IETF XML registry [RFC3688]. Note that the capability URN is IETF XML registry [RFC3688]. Note that the capability URN is =09 =09 skipping to change at page 27, line 7 skipping to change at page 28, line 7 =09 message-id=3D"105"> =09 =09 1 1 =09 =09 =09 =09 8. Appendix D - Change Log 8. Appendix D - Change Log =09 =09 =09 8.1. 07-08 8.1. 08-09 =09 =09 Clarifications Clarifications =09 =09 =09 8.2. 06-07 8.2. 07-08 =09 =09 Clarifications =09 =09 8.3. 06-07 =09 =09 Changed XSD and YANG to allow additional proprietary datastores to be Changed XSD and YANG to allow additional proprietary datastores to be =09 locked. locked. =09 =09 =09 8.3. 05-06 8.4. 05-06 =09 =09 Added usage example Added usage example =09 =09 Clarified error messages Clarified error messages =09 Clarified interaction with edit-config continue-on-error Clarified interaction with edit-config continue-on-error =09 =09 Improved YANG: indentation, canonical order, contact info Improved YANG: indentation, canonical order, contact info =09 =09 Added usage example in appendix C Added usage example in appendix C =09 =09 Synchronized YANG and XSD Synchronized YANG and XSD =09 =09 =09 8.4. 04-05 8.5. 04-05 =09 =09 Language and editorial updates Language and editorial updates =09 =09 all app-tags are with dashes without spaces all app-tags are with dashes without spaces =09 =09 Added usage scenarios Added usage scenarios =09 =09 Changed encoding Changed encoding =09 =09 Clarified definitions, separated scope of lock and protected area Clarified definitions, separated scope of lock and protected area =09 =09 =09 8.5. 03-04 8.6. 03-04 =09 =09 Minor clarifications Minor clarifications =09 =09 Added list of locked-nodes to the output of partial-lock. Added list of locked-nodes to the output of partial-lock. =09 =09 Added wrapper around datastore names. Added wrapper around datastore names. =09 =09 Allowed atomic/one operation locking of datastore parts in multiple Allowed atomic/one operation locking of datastore parts in multiple =09 datastores. datastores. =09 =09 Improved English (hopefully) Improved English (hopefully) =09 =09 Removed the element from rpc-reply following the text of Removed the element from rpc-reply following the text of =09 rfc4741. rfc4741. =09 =09 =09 8.6. 02-03 8.7. 02-03 =09 =09 Minor clarifications Minor clarifications =09 =09 Same descriptions in XSD and YANG. Same descriptions in XSD and YANG. =09 =09 =09 8.7. 01-02 8.8. 01-02 =09 =09 Made XSD normative Made XSD normative =09 =09 Clarified that no specific access control is assumed. Clarified that no specific access control is assumed. =09 =09 Clarified that non-existing nodes are NOT covered by the lock, even Clarified that non-existing nodes are NOT covered by the lock, even =09 if they where existing and covered by the lock when it was originally if they where existing and covered by the lock when it was originally =09 granted. granted. =09 =09 Some rewording Some rewording =09 =09 Added app-tags for two of the error cases. Added app-tags for two of the error cases. =09 =09 Made YANG an informative reference Made YANG an informative reference =09 =09 Enhanced security considerations. Enhanced security considerations. =09 =09 =09 8.8. 00-01 8.9. 00-01 =09 =09 Added YANG module. Added YANG module. =09 =09 =09 8.9. -00 8.10. -00 =09 =09 Created from draft-lengyel-ngo-partial-lock-01.txt Created from draft-lengyel-ngo-partial-lock-01.txt =09 =09 9. Acknowledgements 9. Acknowledgements =09 =09 Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David =09 Harrington, Mehmet Ersue, Wes Hardaker, Juergen Schoenwaelder, Washam Harrington, Mehmet Ersue, Wes Hardaker, Juergen Schoenwaelder, Washam =09 Fan and many other members of the NETCONF WG for providing important Fan and many other members of the NETCONF WG for providing important =09 input to this document. input to this document. =09 =09 =09 End of changes. 25 change blocks. =09 65 lines changed or deleted 82 lines changed or added =09 This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ =09 =09 ________________________________ =09 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf =09 =09 ________________________________ =09 Internal Virus Database is out of date. Checked by AVG - www.avg.com=20 Version: 8.5.339 / Virus Database: 270.12.58/2164 - Release Date: 06/08/09 17:59:00 =09 ------_=_NextPart_001_01C9FA56.54BB5523 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Diff: draft-ietf-netconf-partial-lock-08.txt - = draft-ietf-netconf-partial-lock-09.txt
The February text for the disclaimer for pre-RFC5378 should be=20 OK.
 
Dan
 

From: Bert Wijnen (IETF)=20 [mailto:bertietf@bwijnen.net]
Sent: Wednesday, July 01, = 2009 5:08=20 PM
To: Balazs Lengyel; Romascanu, Dan (Dan); Martin=20 Bjorklund
Cc: netconf mailing list
Subject: Re: = [Netconf]=20 AD review for = draft-ietf-netconf-partial-lock-08.txt

Dan, is there any new text that Balazs should = include in the=20 next (hopefully final)
revision? I mean w.r.t. IPR related = text?
 
Bert
 
----- Original Message -----
From:=20 Balazs Lengyel =
To: Romascanu, Dan (Dan) ; Martin = Bjorklund=20
Sent: Thursday, June 11, 2009 = 11:24=20 AM
Subject: Re: [Netconf] AD = review for=20 draft-ietf-netconf-partial-lock-08.txt

Hello Dan, Martin,
Thanks for the comments.  = See=20 below.

I attached a diff between the current 08 version and = the=20 future 09 version as it stands at the=20
moment.
Balazs

Romascanu, Dan (Dan) wrote:
> = This=20 document is ready to be sent to IETF Last Call, and I will send = it
>=20 immediately after sending this message. Please consider the = comments
>=20 below together with the other IETF Last Call comments.
> =
> 1.=20 IPR and Copyright issues
>
> Running idnits results in = the=20 following warning:
>
> =3D=3D The document seems to = lack a=20 disclaimer for pre-RFC5378 work, but=20 was
>      first submitted before 10 = November=20 2008.  Should you add the
>=20 disclaimer?
>      (See the Legal = Provisions=20 document at
>      http://trustee.ietf.org/lic= ense-info=20 for more information.).
> =
>     =20 trust-12-feb-2009 Section 6.c.iii=20 text:
>      "This document may = contain=20 material from IETF Documents or=20 IETF
>       Contributions = published or=20 made publicly available before=20 November
>       10, 2008.  = The=20 person(s) controlling the copyright in some of=20 this
>       material may not = have=20 granted the IETF Trust the right to=20 allow
>       modifications of = such=20 material outside the IETF Standards Process.
>=20
>       Without obtaining an = adequate=20 license from the = person(s)
>      =20 controlling the copyright in such materials, this document may=20 not
>       be modified outside = the IETF=20 Standards Process, and=20 derivative
>       works of it = may not=20 be created outside the IETF Standards=20 Process,
>       except to = format it for=20 publication as an RFC or to translate=20 it
>       into languages other = than=20 English."

BALAZS: Changed IPR to = pre5378Trust200902.

>=20
> Also, the schema in Appendix A will need to include the = full text=20 of the
> BSD license for code or a reference to it. This issue = is=20 still debated
> with the Trust, so no action by now on this.=20

BALAZS: So  I should wait for further information. When = and=20 where can I find this, or will the
chairs or you supply = it?

>=20
> 2. last paragraph in Section 1.1
>
> s/This=20 consist/These consist/

BALAZS: Is OK if I change the = paragraph=20 to:
Protected area: the set of nodes that are protected=20 from
modification by the lock.  This set consists of nodes = in the=20 scope of
the lock and nodes in subtrees under them.

> =
>=20 3. Section 2.1.1
>
> s/However it can be used to lock a = candidate datastore/However it can be
> used to lock parts of = a=20 candidate datastore/

BALAZS: OK

>
> 4. The = title of=20 Section 2.1.1.1 seems to me to be more appropriately
> = 'Multiple=20 managers handling the writable running datastore with
> = overlapping=20 sections'

BALAZS: OK

>
> 5. same section - I = am a=20 little nervous about saying 'The lock should be
> held only a = short=20 time (seconds rather then minutes)'. What if the lock
> can be = help=20 less than seconds or minutes at minimum because of the size
> = of the=20 records to be operated? Maybe better is to say 'The lock = should
> be=20 held the shortest possible time (e.g. seconds rather then=20 minutes)'.

BALAZS: OK

>
> 6. Section 2.1.1.2 = -=20 better (e.g. minutes, hours)

BALAZS: OK

>
> = 7.=20 Section 2.1.1.3 - same comment as #5 for 2.1.1.1

BALAZS:=20 OK

>
> 8. page 6 - section 2.4.1 - 'these notes = should be=20 included in the
> protected area of the lock' - it seems to me = that a=20 capitalized SHOULD
> is appropriate here.

BALAZS:=20 OK

>
> 9. Capitalization seems necessary also in = 2.4.1.2=20 and also a change as I
> do not see in which situations if = locking=20 fails the client should not
> back-off. I realize this is = client=20 behavior, but the normative language
> still seems to = apply
>=20
> So:
>
> OLD:
> =
>    To=20 avoid this situation, clients should lock
>   =20 everything they need in one operation.  If locking fails, the=20 client
>    should back-off, release any = previously=20 acquired locks, and retry the
>    procedure = after=20 waiting some randomized time interval.
>
> NEW:
> =
>    To avoid this situation, clients SHOULD=20 lock
>    everything they need in one = operation. =20 If locking fails, the client
>    MUST = back-off,=20 release any previously acquired locks, and SHOULD
> retry=20 the
>    procedure after waiting some = randomized time=20 interval.
>

BALAZS: OK

> 10. Last paragraph = in=20 section 3 - why is NOT capitalized?

BALAZS: Just to = emphasize it. I=20 removed the capitalization.

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

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

 draft-ietf-netconf-partial-lock-08.txt   draft-ietf-netconf-partial-lock-09.txt 
NETCONF B. Lengyel NETCONF B. Lengyel
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. = Bjorklund Intended status: Standards Track M. = Bjorklund
Expires: December 5, 2009=20 Tail-f Systems Expires: December 13, 2009=20 Tail-f Systems
June 03, = 2009 June 11, = 2009
Partial Lock RPC for NETCONF Partial Lock RPC for NETCONF
draft-ietf-netconf-partial-lock-08 draft-ietf-netconf-partial-lock-09
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in = full=20 conformance with the This Internet-Draft is submitted to IETF in = full=20 conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or = IETF=20 Contributions published or made publicly
available before = November 10,=20 2008. The person(s) controlling the
copyright in some of = this material=20 may not have granted the IETF
Trust the right to allow = modifications of such material outside the
IETF Standards Process. = Without=20 obtaining an adequate license from
the person(s) = controlling the=20 copyright in such materials, this
document may not be = modified=20 outside the IETF Standards Process, and
derivative works of it = may not be=20 created outside the IETF Standards
Process, except to = format it for=20 publication as an RFC or to
translate it into = languages other=20 than English.
Internet-Drafts are working documents of the = Internet=20 Engineering Internet-Drafts are working documents of the = Internet=20 Engineering
Task Force (IETF), its areas, and its working = groups.=20 Note that Task Force (IETF), its areas, and its working = groups.=20 Note that
other groups may also distribute working = documents as=20 Internet- other groups may also distribute working = documents as=20 Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a = maximum=20 of six months Internet-Drafts are draft documents valid for = a=20 maximum of six months
and may be updated, replaced, or obsoleted by = other=20 documents at any and may be updated, replaced, or obsoleted by = other=20 documents at any
time. It is inappropriate to use = Internet-Drafts as=20 reference time. It is inappropriate to use = Internet-Drafts as=20 reference
material or to cite them other than as "work in = progress." material or to cite them other than as "work = in=20 progress."
The list of current Internet-Drafts can be = accessed=20 at The list of current Internet-Drafts can be = accessed=20 at
http://www.ietf.org/i= etf/1id-abstracts.txt. http://www.ietf.org/i= etf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories = can be=20 accessed at The list of Internet-Draft Shadow Directories = can be=20 accessed at
http://www.ietf.org/shadow.html<= /A>. http://www.ietf.org/shadow.html<= /A>.
This Internet-Draft will expire on December = 5, 2009. This Internet-Draft will expire on December = 13, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons=20 identified as the Copyright (c) 2009 IETF Trust and the persons=20 identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF = Trust's=20 Legal This document is subject to BCP 78 and the = IETF=20 Trust's Legal
Provisions Relating to IETF Documents in effect = on the=20 date of Provisions Relating to IETF Documents in = effect on the=20 date of
publication of this document (http://trustee.ietf.org/lic= ense-info). publication of this document (http://trustee.ietf.org/lic= ense-info).
Please review these documents carefully, as = they=20 describe your rights Please review these documents carefully, as = they=20 describe your rights
skipping to change at = page 2,=20 line 10 skipping to change at = page 3,=20 line 7
Abstract Abstract
The NETCONF protocol defines the lock and = unlock RPCs,=20 used to lock The NETCONF protocol defines the lock and = unlock RPCs,=20 used to lock
entire configuration datastores. In some = situations, a=20 way to lock entire configuration datastores. In some = situations, a=20 way to lock
only parts of a configuration datastore is = required.=20 This document only parts of a configuration datastore is = required.=20 This document
defines a capability-based extension to the = NETCONF=20 protocol for defines a capability-based extension to the = NETCONF=20 protocol for
locking portions of a configuration = datastore. locking portions of a configuration = datastore.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . = . . . .=20 . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . = . . . .=20 . . . . . . 4
1.1. Definition of Terms . . . . . . . . . . = . . . .=20 . . . . . 3 1.1. Definition of Terms . . . . . . . . . . = . . . .=20 . . . . . 4
2. Partial Locking Capability . . . . . . . . = . . . .=20 . . . . . . 3 2. Partial Locking Capability . . . . . . . . = . . . .=20 . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . = . . . .=20 . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . = . . . .=20 . . . . . 4
2.1.1. Usage Scenarios . . . . . . . . . . . = . . . .=20 . . . . 4 2.1.1. Usage Scenarios . . . . . . . . . . . = . . . .=20 . . . . 5
2.2. Dependencies . . . . . . . . . . . . . . = . . . .=20 . . . . . 6 2.2. Dependencies . . . . . . . . . . . . . . = . . . .=20 . . . . . 7
2.3. Capability Identifier . . . . . . . . . = . . . .=20 . . . . . 6 2.3. Capability Identifier . . . . . . . . . = . . . .=20 . . . . . 7
2.4. New Operations . . . . . . . . . . . . . = . . . .=20 . . . . . 6 2.4. New Operations . . . . . . . . . . . . . = . . . .=20 . . . . . 7
2.4.1. <partial-lock> . . . . . . . . . = . . . .=20 . . . . . . . 6 2.4.1. <partial-lock> . . . . . . . . . = . . . .=20 . . . . . . . 7
2.4.2. <partial-unlock> . . . . . . . . = . . . .=20 . . . . . . . 11 2.4.2. <partial-unlock> . . . . . . . . = . . . .=20 . . . . . . . 12
2.5. Modifications to Existing Operations . . = . . . .=20 . . . . . 11 2.5. Modifications to Existing Operations . . = . . . .=20 . . . . . 13
2.6. Interactions with Other Capabilities . . = . . . .=20 . . . . . 12 2.6. Interactions with Other Capabilities . . = . . . .=20 . . . . . 14
2.6.1. Candidate Configuration Capability . . = . . . .=20 . . . . 12 2.6.1. Candidate Configuration Capability . . = . . . .=20 . . . . 14
2.6.2. Confirmed Commit Capability . . . . . = . . . .=20 . . . . 12 2.6.2. Confirmed Commit Capability . . . . . = . . . .=20 . . . . 14
2.6.3. Distinct Startup Capability . . . . . = . . . .=20 . . . . 12 2.6.3. Distinct Startup Capability . . . . . = . . . .=20 . . . . 14
3. Security Considerations . . . . . . . . . = . . . .=20 . . . . . . 12 3. Security Considerations . . . . . . . . . = . . . .=20 . . . . . . 14
4. IANA Considerations . . . . . . . . . . . = . . . .=20 . . . . . . 13 4. IANA Considerations . . . . . . . . . . . = . . . .=20 . . . . . . 15
5. Appendix A - XML Schema for Partial = Locking=20 (normative) . . 15 5. Appendix A - XML Schema for Partial = Locking=20 (normative) . . 16
6. Appendix B - YANG Module for Partial = Locking 6. Appendix B - YANG Module for Partial = Locking
(non-normative) . . . . . . . . . . . . . . . = . . . .=20 . . . . 19 (non-normative) . . . . . . . . . . . . . . . = . . . .=20 . . . . 20
7. Appendix C - Usage Example - Reserving nodes = for=20 future 7. Appendix C - Usage Example - Reserving = nodes for=20 future
editing (non-normative) . . . . . . . . . . . = . . . .=20 . . . . 22 editing (non-normative) . . . . . . . . . . . = . . . .=20 . . . . 23
8. Appendix D - Change Log . . . . . . . . . = . . . .=20 . . . . . 27 8. Appendix D - Change Log . . . . . . . . . = . . . .=20 . . . . . 28
8.1. 07-08 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 27 8.1. 08-09 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28
8.2. 06-07 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 27 8.2. 07-08 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28
8.3. 05-06 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 27 8.3. 06-07 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28
8.4. 04-05 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 27 8.4. 05-06 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28
8.5. 03-04 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 27 8.5. 04-05 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28
8.6. 02-03 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28 8.6. 03-04 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28
8.7. 01-02 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28 8.7. 02-03 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 29
8.8. 00-01 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 28 8.8. 01-02 . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 29
8.9. -00 . . . . . . . . . . . . . . . . . . = . . . .=20 . . . . . 28 8.9. 00-01 . . . . . . . = . . . . .=20 . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . = . . . .=20 . . . . . . 29 8.10. -00 . . . . = . . . . .=20 . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . = . . . .=20 . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . = . . . .=20 . . . . . . 30
10.1. Normative References . . . . . . . . . = . . . .=20 . . . . . . 30 10. References . . . . . . . . . . . . . . . = . . . .=20 . . . . . . . 31
10.2. Informative References . . . . . . . . = . . . .=20 . . . . . . 30 10.1. Normative References . . . . . . . . . = . . . .=20 . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . = . . . .=20 . . . . . . . 31 10.2. Informative References . . . . . . . . = . . . .=20 . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . = . . . .=20 . . . . . . . 32
1. Introduction 1. Introduction
The [NETCONF] protocol describes the lock and = unlock=20 operations that The [NETCONF] protocol describes the lock and = unlock=20 operations that
operate on entire configuration datastores. = Often,=20 multiple operate on entire configuration datastores. = Often,=20 multiple
management sessions need to be able to modify = the=20 configuration of a management sessions need to be able to modify = the=20 configuration of a
managed device in parallel. In these cases, = locking=20 only parts of a managed device in parallel. In these cases, = locking=20 only parts of a
configuration datastore is needed. This = document=20 defines a configuration datastore is needed. This = document=20 defines a
capability based extension to the NETCONF = protocol to=20 support partial capability based extension to the NETCONF = protocol to=20 support partial
locking of NETCONF datastores using a mechanism = based=20 on the existing locking of NETCONF datastores using a = mechanism based=20 on the existing
skipping to change at = page 3,=20 line 36 skipping to change at = page 4,=20 line 36
node in the conceptual XML datastore. It = contains an=20 absolute node in the conceptual XML datastore. It = contains an=20 absolute
path expression in abbreviated syntax, where = predicates=20 are used path expression in abbreviated syntax, where=20 predicates are used
only to specify values for nodes defined as = keys to=20 distinguish only to specify values for nodes defined as = keys to=20 distinguish
multiple instances. multiple instances.
o Scope of the lock: initially the set of nodes = returned by the o Scope of the lock: initially the set of = nodes=20 returned by the
XPath expressions in a successful partial-lock=20 operation. The set XPath expressions in a successful partial-lock = operation. The set
might be modified if some of the nodes are = deleted. might be modified if some of the nodes are = deleted.
o Protected area: the set of nodes that are = protected=20 from o Protected area: the set of nodes that are = protected=20 from
modification by the lock. This consist of nodes in the scope of modification by the lock. This set=20 consists of nodes in the scope
the lock and nodes in subtrees under = them. of the lock and nodes in subtrees under = them.
2. Partial Locking Capability 2. Partial Locking Capability
2.1. Overview 2.1. Overview
The :partial-lock capability indicates that the = device=20 supports the The :partial-lock capability indicates that = the device=20 supports the
locking of its configuration with a more = limited scope=20 than a locking of its configuration with a more = limited scope=20 than a
complete configuration datastore. The scope to = be=20 locked is complete configuration datastore. The scope to = be=20 locked is
specified by using restricted or full XPath=20 expressions. Partial specified by using restricted or full XPath=20 expressions. Partial
locking only affects configuration data. locking only affects configuration data.
skipping to change at = page 4,=20 line 27 skipping to change at = page 5,=20 line 27
2.1.1. Usage Scenarios 2.1.1. Usage Scenarios
In the following we describe a few scenarios = for=20 partial locking. In the following we describe a few scenarios = for=20 partial locking.
Partial locking is primarily useful towards the = running Partial locking is primarily useful towards = the=20 running
configuration. However it can be used to lock a = candidate datastore configuration. However it can be used to lock = a=20 candidate datastore
as well. While scenarios using the running = datastore=20 are seen as the as well. While scenarios using the running = datastore=20 are seen as the
most important, as an example a scenario = involving the=20 candidate most important, as an example a scenario = involving the=20 candidate
datastore is also presented. Besides the three=20 described here, there datastore is also presented. Besides the three = described here, there
are many other usage scenarios possible. are many other usage scenarios possible.
2.1.1.1. Multiple managers handling the = writable=20 running datastore 2.1.1.1. Multiple managers handling the = writable=20 running datastore with
overlapping = sections
Multiple managers are handling the same NETCONF = agent=20 simultaneously. Multiple managers are handling the same = NETCONF agent=20 simultaneously.
The agent is handled via the writable running=20 datastore. Each The agent is handled via the writable running=20 datastore. Each
manager has his or her own task, which might = involve=20 the modification manager has his or her own task, which might = involve=20 the modification
of overlapping sections of the datastore. of overlapping sections of the datastore.
After collecting and analyzing input and = preparing the=20 NETCONF After collecting and analyzing input and = preparing the=20 NETCONF
operations off-line, the manager locks the = areas that=20 are important operations off-line, the manager locks the = areas that=20 are important
for his task using one single = <partial-lock>=20 operation. The manager for his task using one single = <partial-lock>=20 operation. The manager
executes a number of <edit-config> = operations to=20 modify the executes a number of <edit-config> = operations to=20 modify the
configuration, then releases the partial-lock. = The lock=20 should be configuration, then releases the partial-lock. = The=20 lock should be
held for only a = short time=20 (seconds rather then minutes). = The held for the shortest=20 possible time (e.g. seconds = rather=20 then
manager should collect all human input before = locking=20 anything. As minutes). The manager should collect all = human input=20 before locking
each manager locks only a part of the data = model,=20 usually multiple anything. As each manager locks only a part = of the=20 data model,
operators can execute the <edit-config> = operations simultaneously. usually multiple operators can execute the=20 <edit-config> operations
simultaneously.
2.1.1.2. Multiple managers handling the = writable=20 running datastore, 2.1.1.2. Multiple managers handling the = writable=20 running datastore,
distinct management areas distinct management areas
Multiple managers are handling the same NETCONF = agent=20 simultaneously. Multiple managers are handling the same = NETCONF agent=20 simultaneously.
The agent is handled via the writable running=20 datastore. The agent's The agent is handled via the writable running=20 datastore. The agent's
data model contains a number of well defined = separate=20 areas that can data model contains a number of well defined = separate=20 areas that can
be configured without impacting other areas. An = example=20 can be a be configured without impacting other areas. = An=20 example can be a
server with multiple applications running on = it, or a=20 number of a server with multiple applications running on = it, or a=20 number of a
network elements with a common NETCONF agent = for=20 management. network elements with a common NETCONF agent = for=20 management.
Each manager has his or her own task, which = does not=20 involve the Each manager has his or her own task, which = does not=20 involve the
modification of overlapping sections of the=20 datastore. modification of overlapping sections of the=20 datastore.
The manager locks his area with a = <partial-lock>=20 operation, uses a The manager locks his area with a = <partial-lock>=20 operation, uses a
number of <edit-config> commands to = modify it,=20 later releases the number of <edit-config> commands to = modify it,=20 later releases the
lock. As each manager has his functional area = assigned=20 to him, and lock. As each manager has his functional area = assigned=20 to him, and
he locks only that area, multiple managers can = edit the=20 configuration he locks only that area, multiple managers can = edit=20 the configuration
simultaneously. Locks can be held for = extended=20 periods (minutes, simultaneously. Locks can be held for = extended=20 periods (e.g.
hours), as this will not hinder other = managers. minutes, hours), = as this=20 will not hinder other managers.
This scenario assumes, that the global lock = operation=20 from [NETCONF] This scenario assumes, that the global lock = operation=20 from [NETCONF]
is not used. is not used.
2.1.1.3. Multiple managers handling the = candidate=20 datastore in a semi- 2.1.1.3. Multiple managers handling the = candidate=20 datastore in a semi-
coordinated work mode coordinated work mode
Multiple managers are handling the same NETCONF = agent=20 simultaneously. Multiple managers are handling the same = NETCONF agent=20 simultaneously.
The agent is handled via the candidate = datastore. Each=20 manager has The agent is handled via the candidate = datastore. Each=20 manager has
his or her own task which might involve the=20 modification of his or her own task which might involve the=20 modification of
overlapping sections of the datastore. overlapping sections of the datastore.
After collecting and analyzing input and = preparing the=20 NETCONF After collecting and analyzing input and = preparing the=20 NETCONF
operations off-line, the manager locks the = areas that=20 are important operations off-line, the manager locks the = areas that=20 are important
for his task using one single = <partial-lock>=20 operation in both the for his task using one single = <partial-lock>=20 operation in both the
candidate and the running datastore. He = executes a=20 number of <edit- candidate and the running datastore. He = executes a=20 number of <edit-
config> operations to modify the = configuration, then=20 releases the config> operations to modify the = configuration,=20 then releases the
partial-lock. The lock should be held for = only a short time (seconds partial-lock. The lock should only be held for the shortest=20 possible
rather then minutes). time (e.g. = seconds rather=20 then minutes).
Operators coordinate with each other. When all = of them=20 finish their Operators coordinate with each other. When all = of them=20 finish their
tasks one of them orders commit. If any of the=20 operators are still tasks one of them orders commit. If any of the = operators are still
working, and holds a lock, the commit will = fail, and=20 will need to be working, and holds a lock, the commit will = fail, and=20 will need to be
repeated after all managers finish. repeated after all managers finish.
Warning: When multiple managers use the = candidate=20 configuration in Warning: When multiple managers use the = candidate=20 configuration in
parallel, there is a risk that the interaction = of=20 access control parallel, there is a risk that the interaction = of=20 access control
(which is still implementation specific at the = time of=20 this writing) (which is still implementation specific at the = time of=20 this writing)
and the commit operation might result in a = dead-lock,=20 as illustrated and the commit operation might result in a = dead-lock,=20 as illustrated
skipping to change at = page 8,=20 line 15 skipping to change at = page 9,=20 line 17
The <partial-lock> operation is designed = for=20 simplicity, so when a The <partial-lock> operation is designed = for=20 simplicity, so when a
partial lock is executed you get what you asked = for: a=20 set of nodes partial lock is executed you get what you = asked for: a=20 set of nodes
that are locked for writing. As a consequence = users=20 must observe the that are locked for writing. As a consequence = users=20 must observe the
following: following:
o Locking does not affect read operations. o Locking does not affect read = operations.
o If part of a datastore is locked, this has no = effect=20 on any o If part of a datastore is locked, this has = no effect=20 on any
unlocked parts of the datastore. If this is a = problem=20 (e.g., unlocked parts of the datastore. If this is a = problem=20 (e.g.,
changes depend on data values or nodes outside = the=20 protected part changes depend on data values or nodes outside = the=20 protected part
of the datastore), these nodes should be included in the protected of the datastore), these nodes SHOULD be included in the protected
area of the lock. area of the lock.
o Configuration data can be edited both inside = and=20 outside the o Configuration data can be edited both inside = and=20 outside the
protected area of a lock. It is the = responsibility of=20 the NETCONF protected area of a lock. It is the = responsibility of=20 the NETCONF
client application to lock all relevant parts = of a=20 datastore that client application to lock all relevant parts = of a=20 datastore that
are crucial for a specific management = action. are crucial for a specific management = action.
Note: The <partial-lock> operation does = not=20 modify the global <lock> Note: The <partial-lock> operation does = not=20 modify the global <lock>
operation defined in the base NETCONF Protocol=20 [NETCONF]. If part of operation defined in the base NETCONF Protocol = [NETCONF]. If part of
a datastore is already locked by = <partial-lock>,=20 then a global lock a datastore is already locked by = <partial-lock>,=20 then a global lock
skipping to change at = page 10,=20 line 46 skipping to change at = page 12,=20 line 35
not an Instance Identifier, the = <error-tag> is=20 'invalid-value', the not an Instance Identifier, the = <error-tag> is=20 'invalid-value', the
<error-app-tag> is=20 'invalid-lock-specification'. <error-app-tag> is=20 'invalid-lock-specification'.
If access control denies the partial lock, the=20 <error-tag> is If access control denies the partial lock, the = <error-tag> is
'access-denied'. 'access-denied'.
2.4.1.2. Deadlock Avoidance 2.4.1.2. Deadlock Avoidance
As with most locking systems, it is possible = that two=20 management As with most locking systems, it is possible = that two=20 management
sessions trying to lock different parts of the=20 configuration could sessions trying to lock different parts of the = configuration could
become dead-locked. To avoid this situation, = clients=20 should lock become dead-locked. To avoid this situation, = clients=20 SHOULD lock
everything they need in one operation. If = locking=20 fails, the client everything they need in one operation. If = locking=20 fails, the client
should back-off, = release=20 any previously acquired locks, and retry the MUST back-off, = release any=20 previously acquired locks, and SHOULD
procedure after waiting some randomized time=20 interval. retry the procedure after waiting some = randomized=20 time interval.
2.4.2. <partial-unlock> 2.4.2. <partial-unlock>
The operation unlocks the parts of the = datastores that=20 were The operation unlocks the parts of the = datastores that=20 were
previously locked using <partial-lock> = during the=20 same session. previously locked using <partial-lock> = during=20 the same session.
Parameters: Parameters:
lock-id: Identity of the lock to be unlocked. = This=20 lock-id MUST lock-id: Identity of the lock to be unlocked. = This=20 lock-id MUST
have been received as a response to a lock = request by=20 the manager have been received as a response to a lock = request by=20 the manager
skipping to change at = page 13,=20 line 29 skipping to change at = page 15,=20 line 19
users's sessions. users's sessions.
The NETCONF server may log partial lock = requests in an=20 audit The NETCONF server may log partial lock = requests in an=20 audit
trail. trail.
A lock that is hung for some reason (e.g., a = broken TCP=20 connection A lock that is hung for some reason (e.g., a = broken=20 TCP connection
that the server has not yet recognised) can be = released=20 using another that the server has not yet recognised) can be = released using another
NETCONF session by explicitly killing the = session=20 owning that lock NETCONF session by explicitly killing the = session=20 owning that lock
using the <kill-session> operation. using the <kill-session> operation.
Partial locking is NOT an=20 authorization mechanism; it SHOULD NOT be Partial locking is not an=20 authorization mechanism; it SHOULD NOT be
used to provide security or access control. = Partial=20 locking SHOULD used to provide security or access control. = Partial=20 locking SHOULD
only be used as a mechanism for providing = consistency=20 when multiple only be used as a mechanism for providing = consistency=20 when multiple
managers are trying to configure the node. It = is vital=20 that users managers are trying to configure the node. It = is vital=20 that users
easily understand the exact scope of a lock. = This is=20 why the scope easily understand the exact scope of a lock. = This is=20 why the scope
is determined when granting a lock and is not = modified=20 thereafter. is determined when granting a lock and is not = modified=20 thereafter.
4. IANA Considerations 4. IANA Considerations
This document registers two URIs for the = NETCONF XML=20 namespace in the This document registers two URIs for the = NETCONF XML=20 namespace in the
IETF XML registry [RFC3688]. Note that the = capability=20 URN is IETF XML registry [RFC3688]. Note that the = capability=20 URN is
skipping to change at = page 27,=20 line 7 skipping to change at = page 28,=20 line 7
<nc:rpc=20 xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0" <nc:rpc=20 xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
message-id=3D"105"> message-id=3D"105">
<partial-unlock> <partial-unlock>
<lock-id>1</lock-id> <lock-id>1</lock-id>
</partial-unlock> </partial-unlock>
</nc:rpc> </nc:rpc>
8. Appendix D - Change Log 8. Appendix D - Change Log
8.1. 07-08 8.1. 08-09
Clarifications Clarifications
8.2. 06-07 8.2. 07-08
Clarifications
8.3. 06-07
Changed XSD and YANG to allow additional = proprietary=20 datastores to be Changed XSD and YANG to allow additional = proprietary=20 datastores to be
locked. locked.
8.3. 05-06 8.4. 05-06
Added usage example Added usage example
Clarified error messages Clarified error messages
Clarified interaction with edit-config=20 continue-on-error Clarified interaction with edit-config=20 continue-on-error
Improved YANG: indentation, canonical order, = contact=20 info Improved YANG: indentation, canonical order, = contact=20 info
Added usage example in appendix C Added usage example in appendix C
Synchronized YANG and XSD Synchronized YANG and XSD
8.4. 04-05 8.5. 04-05
Language and editorial updates Language and editorial updates
all app-tags are with dashes without = spaces all app-tags are with dashes without = spaces
Added usage scenarios Added usage scenarios
Changed encoding Changed encoding
Clarified definitions, separated scope of lock = and=20 protected area Clarified definitions, separated scope of lock = and=20 protected area
8.5. 03-04 8.6. 03-04
Minor clarifications Minor clarifications
Added list of locked-nodes to the output of=20 partial-lock. Added list of locked-nodes to the output of=20 partial-lock.
Added <target> wrapper around datastore = names. Added <target> wrapper around datastore=20 names.
Allowed atomic/one operation locking of = datastore parts=20 in multiple Allowed atomic/one operation locking of = datastore=20 parts in multiple
datastores. datastores.
Improved English (hopefully) Improved English (hopefully)
Removed the <data> element from rpc-reply = following the text of Removed the <data> element from = rpc-reply=20 following the text of
rfc4741. rfc4741.
8.6. 02-03 8.7. 02-03
Minor clarifications Minor clarifications
Same descriptions in XSD and YANG. Same descriptions in XSD and YANG.
8.7. 01-02 8.8. 01-02
Made XSD normative Made XSD normative
Clarified that no specific access control is=20 assumed. Clarified that no specific access control is=20 assumed.
Clarified that non-existing nodes are NOT = covered by=20 the lock, even Clarified that non-existing nodes are NOT = covered by=20 the lock, even
if they where existing and covered by the lock = when it=20 was originally if they where existing and covered by the lock = when it=20 was originally
granted. granted.
Some rewording Some rewording
Added app-tags for two of the error cases. Added app-tags for two of the error = cases.
Made YANG an informative reference Made YANG an informative reference
Enhanced security considerations. Enhanced security considerations.
8.8. 00-01 8.9. 00-01
Added YANG module. Added YANG module.
8.9. -00 8.10. -00
Created from = draft-lengyel-ngo-partial-lock-01.txt Created from = draft-lengyel-ngo-partial-lock-01.txt
9. Acknowledgements 9. Acknowledgements
Thanks to Andy Bierman, Sharon Chisholm, Phil = Shafer ,=20 David Thanks to Andy Bierman, Sharon Chisholm, Phil = Shafer ,=20 David
Harrington, Mehmet Ersue, Wes Hardaker, Juergen = Schoenwaelder, Washam Harrington, Mehmet Ersue, Wes Hardaker, = Juergen=20 Schoenwaelder, Washam
Fan and many other members of the NETCONF WG = for=20 providing important Fan and many other members of the NETCONF WG = for=20 providing important
input to this document. input to this document.
 End of = changes. 25 change=20 blocks. 
65 lines changed or deleted 82 lines changed or added

This html diff = was produced=20 by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools= /rfcdiff/=20

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


Internal Virus Database is out of date.
Checked by AVG = - www.avg.com
Version: 8.5.339 / = Virus=20 Database: 270.12.58/2164 - Release Date: 06/08/09=20 17:59:00
------_=_NextPart_001_01C9FA56.54BB5523-- From robert.cole@jhuapl.edu Thu Jul 2 05:51:27 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 2D57D3A6D88 for ; Thu, 2 Jul 2009 05:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=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 QdYgvY6qlzHG for ; Thu, 2 Jul 2009 05:51:26 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 345003A6910 for ; Thu, 2 Jul 2009 05:51:25 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.12297824; Thu, 02 Jul 2009 08:51:44 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 2 Jul 2009 08:51:45 -0400 From: "Cole, Robert G." To: "netconf@ietf.org" Date: Thu, 2 Jul 2009 08:51:44 -0400 Thread-Topic: new version of the Robust Netconf draft Thread-Index: AQHJ+xPaDxNnoVULcUGbf4+XwxRl0A== Message-ID: <0A8F66C42F49E448A40E99946404EE5B708D98EFC9@aplesstar.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] new version of the Robust Netconf 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: Thu, 02 Jul 2009 12:51:27 -0000 To All: Although I am late to announce this, we have submitted a revision to our Ro= bust Netconf draft. The link follows: https://datatracker.ietf.org/drafts/draft-cole-netconf-robust-config/ Many corrections, changes and improvement were made based upon feedback fro= m the San Fran meeting. These include: + cleaned up terminology + developed and documented an approach to running configuration Verificatio= n by proposing a new NETCONF capability with Yang model, verify-commit.yang + developed an example test method through a ping.yang module + added use cases to appendix + moved background material to appendix for improved reading + cleaned up Introduction to clarify draft and proposal We hope to discuss this in Stockholm at the NETCONF WG meeting. Thanks, Bob, Dan and Andy= From mbj@tail-f.com Thu Jul 2 12:44:52 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CFF3A693F for ; Thu, 2 Jul 2009 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067, 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 o2opzxNdQV6t for ; Thu, 2 Jul 2009 12:44:51 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D27603A6DE7 for ; Thu, 2 Jul 2009 12:44:13 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 91D9276C52D; Thu, 2 Jul 2009 21:44:35 +0200 (CEST) Date: Thu, 02 Jul 2009 21:44:35 +0200 (CEST) Message-Id: <20090702.214435.127382627.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A47CC3C.3030307@netconfcentral.com> References: <4A47CC3C.3030307@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] idea for new commit operation 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, 02 Jul 2009 19:44:52 -0000 Hi, Andy Bierman wrote: > A :new-commit capability can add output parameters, not just > input parameters. It can persist across sessions, and > fix the broken parts of confirmed-commit.1.0. It can support > the verified commit procedure defined in a separate document. I agree with this in general, except for the verified part. I think we get a cleaner model if one rpc does one thing. In this case, the confirmed commit operation will work just fine with a new 'start-test' rpc. (see my email http://www.ietf.org/mail-archive/web/netconf/current/msg04717.html) I think this 'better confirmed commit' capability can be specified as :confirmed-commit:1.1 in 4741bis. The :confirmed-commit:1.0 capability lacks a 'cancel-commit' operation. The text actually vaguely refers to something like that in section 8.4.1: Thus to cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the manager can explicitly restore the configuration to its state before the confirmed commit was issued. Except that this "explicit restore" operation does not exist... So I think it makes sense to add such an operation. The other issue is if the confirming commit MUST be done from the same session that did the confirmed commit or not. 4741 doesn't say, so I think it needs to be clarified in 4741bis. The reason it can be useful to do this from some other session is if you change some parameter that affects the session, e.g. if you change the ip address. But it seems pretty dangerous to *always* allow this, since it means that any user could come in and confirm my commit. Thus, I think the idea of adding an excplicit 'persist' parameter is great. I would prefer if confirmed-commit:1.0 was clarified in 4741bis to NOT allow this gratuitous commit from other sessions, and confirmed-commit:1.1 should add the 'persist' parameter (etc) to handle the use case. /martin > E.g.: > > feature new-commit { > if-feature confirmed-commit; > description > "Supports the new confirmed commit procedure and the > verified commit procedure."; > } > > typedef commit-id-type { > description > "Contains the agent-assigned identifier for this commit request. > This value is returned by a new operation, and > must be used with the subsequent or > operations, or the agent will not accept the request. > This commit identifier is only valid while a confirmed or verified > commit operation is in effect. The agent should use a string value > which is not predictable, and cannot be easily guessed."; > type string { > length { "8 .. 1024"; } > } > } > > rpc commit { > if-feature candidate; > description > "If the :new-commit capability is supported, and the > 'verified' or 'persist' parameter is entered, then the new > commit procedure is in effect. The or > operations will be used, not the operation again. > > If the :new-commit capability is not supported, or these > parameters are not present, then the old commit procedure > is in effect, and a 2nd operation is expected > by any session, before the current session terminates or > the timeout expires."; > input { > leaf timeout { > if-feature confirmed-commit; > description "unchanged"; > type timeout-type; > } > leaf confirmed { > if-feature confirmed-commit; > description "unchanged"; > type empty; > } > leaf-list test-template { > if-feature new-commit; > description > "Optional list of verification control entries to > use during the verified commit procedure."; > type instance-identifier; > } > leaf persist { > if-feature new-commit; > description > "If present, then this commit procedure is allowed > to persist across a single session. If the current session > is terminated, the running database will not be automatically > reverted. Only a timeout or the operation > will cause the commit procedure to be terminated, if this > parameter is present."; > type empty; > } > } > output { > leaf commit-id { > if-feature new-commit; > type commit-id-type; > } > } > } > > rpc complete-commit { > if-feature new-commit; > description > "The 2nd commit to finalize a confirmed or verified commit operation."; > input { > leaf commit-id { > type commit-id-type; > } > } > } > > rpc cancel-commit { > if-feature new-commit; > description > "Cancel a confirmed or verified commit operation in progress."; > input { > leaf commit-id { > type commit-id-type; > } > } > } > > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mbj@tail-f.com Thu Jul 2 13:28: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 89D213A6BA4 for ; Thu, 2 Jul 2009 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.064, 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 EKZY4IWb-4jp for ; Thu, 2 Jul 2009 13:28: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 393A23A6906 for ; Thu, 2 Jul 2009 13:28:35 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 71CF176C52D; Thu, 2 Jul 2009 22:28:47 +0200 (CEST) Date: Thu, 02 Jul 2009 22:28:47 +0200 (CEST) Message-Id: <20090702.222847.128867282.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A44F70A.2050006@ericsson.com> References: <085091CB2CA14E4B8B163FFC37C84E9D198F35EB@zcarhxm0.corp.nortel.com> <4A44F70A.2050006@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] FW: New Version Notification for draft-ietf-netconf-monitoring-05 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, 02 Jul 2009 20:28:36 -0000 Hi Balazs, Balazs Lengyel wrote: > Hello Mark, > Some comments: > General) > I think we should not exclude the possibility of monitoring non-netconf > sessions in this schema. I don't think we do. The intention was that *if* the NETCONF server can manage other sessions, it MAY include them in the session list. > 2.1.2) "The /netconf-state/datastores subtree contains configuration data" > This seems to indicate it contains writable data. I know that was not your > intention, so please reword. Ok. > Some changes to the paragraph starting with "For partial locks the list": > For partial locks the list of locked nodes and the select expressions > originally used to request the lock are returned. The scope of the partial lock > is defined by the list of locked nodes. This list might change during the > lifetime of the lock. > The select expressions indicate the original intended scope of the lock. Ok. > Ch 2.1.3) > YIN should be added as a format. Originally we had text that said that the format 'yang' also covered the yin syntax form. So either we add that back, or we add 'yin'. Should we also add 'rnc' (in addition to 'rng')? > s/One of more locations/Zero one of more locations/ > > 2.1.4) in several places you use "a message was expected" > Who expects it? Does the device know that an should be arriving > at 7:00 PM? :-) Rather remove the expected part. The server waits for (and thus expects) messages. If it gets something else, the counter is incremented. > 2.1.5) Please indicate if droppedSessions includes session closed due to > parseErrors. There is nothing in 4741 that says that a parse error MUST terminate the session. So droppedSessions says that if the session is abnormally terminated the counter is incremented. A server that terminates a session due to a parse error should increment this counter. > 3.1) > - One XML error, search for >< Actually, there are 3 similar errors in this example... and the text Positive Response is mixed with the example. > - negative response missing > 3.2) > - s/schema may be supported in multiple locations/schema may be available in > - multiple locations/ > - first paragraph last sentence is trivial, remove it. > - Why do you have a negative response section here? Does this belong to 3.1? Yes. > 5) didn't check XSD. How about generating it automatically from YANG? That > would more or less remove the need to review it. It is not trivial, since the YANG module uses types from ietf-inet-types and ietf-yang-types. We would need them as XSDs as well... > 9) Include non-normative references for yang and yang-types Ok. > Appendix) > - location should be a leaf-list not a leaf Yes. > - get-schema output: if we have a YANG schema will it will be a string not any > XML A string can be sent in anyxml. > - the level of descriptions is uneven in this YAM I don't understand what you mean? /martin From balazs.lengyel@ericsson.com Fri Jul 3 07:50: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 DE8A43A690A for ; Fri, 3 Jul 2009 07:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 lL6P8ktYHPRJ for ; Fri, 3 Jul 2009 07:50:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5312328C2AC for ; Fri, 3 Jul 2009 07:49:26 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-5e-4a4e1a8b121d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A7.C0.13985.B8A1E4A4; Fri, 3 Jul 2009 16:49:48 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 16:49:47 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jul 2009 16:49:47 +0200 Message-ID: <4A4E1A8B.8050503@ericsson.com> Date: Fri, 03 Jul 2009 16:49:47 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <085091CB2CA14E4B8B163FFC37C84E9D198F35EB@zcarhxm0.corp.nortel.com> <4A44F70A.2050006@ericsson.com> <20090702.222847.128867282.mbj@tail-f.com> In-Reply-To: <20090702.222847.128867282.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2009 14:49:47.0358 (UTC) FILETIME=[8297D7E0:01C9FBED] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-05 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 Jul 2009 14:50:17 -0000 Hello, See below! Balazs Martin Bjorklund wrote: >> General) >> I think we should not exclude the possibility of monitoring non-netconf >> sessions in this schema. > > I don't think we do. The intention was that *if* the NETCONF server > can manage other sessions, it MAY include them in the session list. BALAZS: The sentence "Includes session specific data for NETCONF management session." at the start of 2.1.4. seems to indicate that CLI sessions are strictly excluded. While you can understand this to include CLI sessions, if they are visible to the NETCONF server, this is far from trivial. > >> Ch 2.1.3) >> YIN should be added as a format. > > Originally we had text that said that the format 'yang' also covered > the yin syntax form. So either we add that back, or we add 'yin'. > Should we also add 'rnc' (in addition to 'rng')? BALAZS: IMO add rnc as well >> 2.1.4) in several places you use "a message was expected" >> Who expects it? Does the device know that an should be arriving >> at 7:00 PM? :-) Rather remove the expected part. > > The server waits for (and thus expects) messages. If it gets > something else, the counter is incremented. BALAZS: I still don't like the wording, but don't care. > >> 2.1.5) Please indicate if droppedSessions includes session closed due to >> parseErrors. > > There is nothing in 4741 that says that a parse error MUST terminate the > session. BALAZS: Maybe there should be a mention of this in the 4741bis. We have talked about the situation a lot when discussing the ]]>]]> sequence and security consideration. >> - get-schema output: if we have a YANG schema will it will be a string not any >> XML > > A string can be sent in anyxml. BALAZS: Why do you want to force non-XML descriptions like yang or rnc into an XML container? It can be done, but its kind of strange. What would be the starting XML element? That should be defined. From root@core3.amsl.com Fri Jul 3 08: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 83E413A6A2E; Fri, 3 Jul 2009 08: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: <20090703151501.83E413A6A2E@core3.amsl.com> Date: Fri, 3 Jul 2009 08:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15: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-02.txt Pages : 15 Date : 2009-07-03 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-03080545.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Jul 3 08:30: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 6F11828C1EF; Fri, 3 Jul 2009 08:30: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: <20090703153001.6F11828C1EF@core3.amsl.com> Date: Fri, 3 Jul 2009 08:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15:30: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 : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-09.txt Pages : 32 Date : 2009-07-03 The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-09.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-partial-lock-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-03081942.I-D@ietf.org> --NextPart-- From andy@netconfcentral.com Sun Jul 5 22:07: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 718593A6C56 for ; Sun, 5 Jul 2009 22:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 o6mFr8lxXekR for ; Sun, 5 Jul 2009 22:07:29 -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 41ACA3A6C5B for ; Sun, 5 Jul 2009 22:07:29 -0700 (PDT) Received: (qmail 92481 invoked from network); 6 Jul 2009 05:07:51 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 6 Jul 2009 05:07:51 -0000 X-YMail-OSG: rWXbgZYVM1ng13mpPIDKUd.vM0PhUTr19SohzNeGD_CaLXYMOYa8SN7CvTTmJoT.F856spqqOhkY4WInxkaZDIlzExylr.DZEfzNFLtglIMrsuExEnzE5e0GdkFfLfhx4wXbXeXGEfY6csdx.ACu.OCygCleRpPsz17P605EpSXVSPbTmeddIuoPhbp0SUddM7TvMF01sG_7cJPoKySMuFoVC9ZWP4Q5MH4Fi1BCVz274P8_8ucP16DUHeFqQA5v1zeSAr.f4tYhavoy X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A518642.3050009@netconfcentral.com> Date: Sun, 05 Jul 2009 22:06:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] test-option default 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 Jul 2009 05:07:30 -0000 Hi, The parameter to the operation has 2 different defaults: test: if :validate not supported test-then-set: if :validate is supported Not only is this confusing, but it is actually wasteful and may cause false errors, if the default used is 'test-then-set'. There is no point in validating the config. This should always be valid. The agent uses 'test-then-set' all the time if :writable-running is supported. If the target is , then incremental edits are to be expected, so validating the entire database by default may lead to false errors and scripts that normally work will break if :validate is supported by the agent. This is unacceptable. I propose that the default for always be 'test' in the new :validate.1.1 capability (will be in next 4741bis draft). I would like to alter the :validate.1.0 behavior to match, if that is OK. Hopefully, no managers rely on, or want, an automatic validate of the each time it is written. Andy From andy@netconfcentral.com Mon Jul 6 10:05: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 465973A67DF for ; Mon, 6 Jul 2009 10:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jonlugVxU9cA for ; Mon, 6 Jul 2009 10:05:35 -0700 (PDT) Received: from n9.bullet.mail.mud.yahoo.com (n9.bullet.mail.mud.yahoo.com [209.191.86.157]) by core3.amsl.com (Postfix) with SMTP id 724803A6936 for ; Mon, 6 Jul 2009 10:05:35 -0700 (PDT) Received: from [68.142.200.224] by n9.bullet.mail.mud.yahoo.com with NNFMP; 06 Jul 2009 17:03:27 -0000 Received: from [68.142.201.249] by t5.bullet.mud.yahoo.com with NNFMP; 06 Jul 2009 17:03:27 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 06 Jul 2009 17:03:27 -0000 X-Yahoo-Newman-Id: 962736.84580.bm@omp410.mail.mud.yahoo.com Received: (qmail 27571 invoked from network); 6 Jul 2009 17:03:27 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 6 Jul 2009 17:03:27 -0000 X-YMail-OSG: Y5K3zsAVM1loPmCg4Q.uAFhvjBd4y_.sAxXNmzLpXqHpAUp0jHrsCQLVzenR5Wy5_8hPECNJSGjpWcX3yjuXoPHWXtxsLhsAdlw2MuLk6IFWGtXLG2D3zLA1J1wOeX97JAx_avX6D5cF01BO1H6sjhj_wjLGv4pdvUvER6eoTzgSLrdkd0p0455iYssXO0iPhYO8sKARswSjBr2Omre7SRQnU5ulhDUzHip63U.5lwbD3Ybj28m741j56msa3t0FtG71UBnJA6xSPp20 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A522E79.70900@netconfcentral.com> Date: Mon, 06 Jul 2009 10:03:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] strict XML? 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 Jul 2009 17:05:36 -0000 Hi, how strict should the agent be when parsing 'select' attribute XPath expressions? Specifically, what if prefixes are used that do not have a matching xmlns attribute? 1) 2) Are all the XML prefixes used in the XPath expression supposed to be declared (IMO, yes), so (1) is an error? Or is (1) just another no-match condition? Or should the agent check the YANG default prefixes to see if any of those match? (IMO, no) Andy From mbj@tail-f.com Mon Jul 6 10:20:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAE93A6809 for ; Mon, 6 Jul 2009 10:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrVvLKdWx5nh for ; Mon, 6 Jul 2009 10:20: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 396213A6D46 for ; Mon, 6 Jul 2009 10:20:30 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 25DB261603A; Mon, 6 Jul 2009 19:19:43 +0200 (CEST) Date: Mon, 06 Jul 2009 19:19:42 +0200 (CEST) Message-Id: <20090706.191942.194501304.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A522E79.70900@netconfcentral.com> References: <4A522E79.70900@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] strict XML? 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 Jul 2009 17:20:32 -0000 Andy Bierman wrote: > Hi, > > how strict should the agent be when parsing 'select' attribute > XPath expressions? Specifically, what if prefixes are used > that do not have a matching xmlns attribute? > > 1) > > > > > 2) > > > > > > Are all the XML prefixes used in the XPath expression > supposed to be declared (IMO, yes), so (1) is an error? Yes. We need to properly define the XPath context for the XPath expression. 4741 actually has this: the set of namespace declarations are those in scope on the filter element which is correct (even if the text about default namespace is wrong and needs to be fixed). Then it follows from XPath 1.0 that (1) is an error. /martin From mbj@tail-f.com Mon Jul 6 10:25: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 10ECD28C2E0 for ; Mon, 6 Jul 2009 10:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 c2SeatBpLP30 for ; Mon, 6 Jul 2009 10:25: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 2E3823A6D2A for ; Mon, 6 Jul 2009 10:25:40 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 37CE661603C; Mon, 6 Jul 2009 19:14:48 +0200 (CEST) Date: Mon, 06 Jul 2009 19:14:47 +0200 (CEST) Message-Id: <20090706.191447.95257172.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A518642.3050009@netconfcentral.com> References: <4A518642.3050009@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] test-option default 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 Jul 2009 17:25:41 -0000 Andy Bierman wrote: > Hi, > > The parameter to the operation > has 2 different defaults: > > test: if :validate not supported This should be 'set'. > test-then-set: if :validate is supported > I propose that the default for always be 'test' > in the new :validate.1.1 capability (will be in next 4741bis draft). > I would like to alter the :validate.1.0 behavior to match, if that > is OK. Hopefully, no managers rely on, or want, an automatic > validate of the each time it is written. I understand your reasoning but I think this falls in the "nice to have enhancement" category - yes it would be better to always have 'test' as default, but it is not backwards compatible. It is not unreasonable to assume that a client that *wants* test-then-set on the candidate leaves it out, since it is the default. /martin From andy@netconfcentral.com Mon Jul 6 11:39:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0383A6BE0 for ; Mon, 6 Jul 2009 11:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 nfhpM0t55R6F for ; Mon, 6 Jul 2009 11:39:31 -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 572E63A6A84 for ; Mon, 6 Jul 2009 11:39:31 -0700 (PDT) Received: (qmail 13156 invoked from network); 6 Jul 2009 18:38:03 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 6 Jul 2009 18:38:03 -0000 X-YMail-OSG: Pl.p3KMVM1mFTOzt7ZmpeoCtsknzAlg_wDr9MeVmGZahpg.qFvVN6RtaJYhBkJqIxe16WzWqPpl8nArhPC.MiOxvD6Y8wPeylS.D0_Cym7cHloh4nHcrapiBj8Lo1ADite6TjmWMPOpwzrtB7_CD9gZ2paahlgLxAtvMPG07S.1jmHOKsNYl.8r7tXbQPeRf8sT.tF37JxRGdlgyZ3HnrJ0TBm0dQYfDfYSpoUOBLUEcC8HQCcsBThh8ArVc8psQLuc_W.SELMP3Wm1uKOt_O3blsZVmq_K6ju4c3IPCFcQIMgZODmknUbxtIe6humW1yroKhEYATf6wDw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5244A6.9030301@netconfcentral.com> Date: Mon, 06 Jul 2009 11:38:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A518642.3050009@netconfcentral.com> <20090706.191447.95257172.mbj@tail-f.com> In-Reply-To: <20090706.191447.95257172.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] test-option default 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 Jul 2009 18:39:32 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The parameter to the operation >> has 2 different defaults: >> >> test: if :validate not supported > > This should be 'set'. > >> test-then-set: if :validate is supported > >> I propose that the default for always be 'test' >> in the new :validate.1.1 capability (will be in next 4741bis draft). >> I would like to alter the :validate.1.0 behavior to match, if that >> is OK. Hopefully, no managers rely on, or want, an automatic >> validate of the each time it is written. > > I understand your reasoning but I think this falls in the > "nice to have enhancement" category - yes it would be better to always > have 'test' as default, but it is not backwards compatible. It is not > unreasonable to assume that a client that *wants* test-then-set on the > candidate leaves it out, since it is the default. > I think it's in the "currently broken" category. test-option: The test-option element may be specified only if the device advertises the :validate capability (Section 8.6). The test-option element has one of the following values: test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the operation. This is the default test-option. set: Perform a set without a validation test first. If :validate is not supported, setting this parameter to any value will yield a 'unknown-element' error. So a manager has to make sure the capability is supported before turning off this behavior. So a manager has to write scripts for the database that check the :validate capability, so normal incremental edits do not cause errors. Way too fragile! I think this has to be changed in :validate.1.1. The normal use-case for breaks by default. IMO, that is a bad default. The default should be for to always work the same, unless the manager takes explicit action to do something differently. BTW, it is OK to advertise validate.1.1 and not validate.1.0, right? Let vendors deprecate broken features if they want. > > /martin > > Andy From lhotka@cesnet.cz Tue Jul 7 00: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 1186728C305 for ; Tue, 7 Jul 2009 00:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAPkMuhAl+Lv for ; Tue, 7 Jul 2009 00:51:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4150528C2AF for ; Tue, 7 Jul 2009 00:51:43 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id EAD4AD800C7; Tue, 7 Jul 2009 09:51:39 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4A522E79.70900@netconfcentral.com> References: <4A522E79.70900@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 07 Jul 2009 09:51:38 +0200 Message-Id: <1246953098.7121.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETCONF Subject: Re: [Netconf] strict XML? 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 Jul 2009 07:51:45 -0000 Andy Bierman píše v Po 06. 07. 2009 v 10:03 -0700: > Hi, > > how strict should the agent be when parsing 'select' attribute > XPath expressions? Specifically, what if prefixes are used > that do not have a matching xmlns attribute? > > 1) > > > > > 2) > > > > > > Are all the XML prefixes used in the XPath expression > supposed to be declared (IMO, yes), so (1) is an error? Yes, it should be an error. Lada > > Or is (1) just another no-match condition? > > Or should the agent check the YANG default prefixes > to see if any of those match? (IMO, no) > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Jul 7 08:20: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 552E33A6CA8 for ; Tue, 7 Jul 2009 08:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 cUmAZE9X8VbI for ; Tue, 7 Jul 2009 08:20:43 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 44B723A6E66 for ; Tue, 7 Jul 2009 08:20:43 -0700 (PDT) Received: (qmail 53850 invoked from network); 7 Jul 2009 15:19:56 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 7 Jul 2009 15:19:56 -0000 X-YMail-OSG: 2aCXoGgVM1lJi7U.wNuDC00jrX.rrLG8KTVVnxNRrTl1r9H1pAR1odoVG7GVVD0OhInND7kDkOsf44h4iFFW88fCG94W1JZcnrGkR8s_MLQMjWDe0EHPVhABHAby_iinjRLHr_gKuiVRpIMfaiq3ABftXBBW58FimQKcTx24P3rXDn7oZy9VQVVhuwfNt6YYfSH4cfctBIP0DZQSnlMIvtIM05f4vzqR0NjCGSlCZhd5ROmfByXHra649w3WDcZf2RKss33BpLHaf7v6PAsHsU2swQZMsCnibutzosEORZ2uE7QKDxdqDy4TC6eRjpA5stjfNC6EEChUKLa0ITak X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5367BC.1020201@netconfcentral.com> Date: Tue, 07 Jul 2009 08:20:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: WashamFan References: <4A518642.3050009@netconfcentral.com> <20090706.191447.95257172.mbj@tail-f.com> <4A5244A6.9030301@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] test-option default 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 Jul 2009 15:20:44 -0000 WashamFan wrote: > Hi, > > ----- Original Message ----- > From: Andy Bierman > Date: Tuesday, July 7, 2009 2:40 am > Subject: Re: [Netconf] test-option default > To: Martin Bjorklund > Cc: netconf@ietf.org > > >> Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> Hi, >> >> >> >> The parameter to the operation >> >> has 2 different defaults: >> >> >> >> test: if :validate not supported >> > >> > This should be 'set'. >> > >> >> test-then-set: if :validate is supported >> > >> >> I propose that the default for always be 'test' >> >> in the new :validate.1.1 capability (will be in next 4741bis draft). >> >> I would like to alter the :validate.1.0 behavior to match, if that >> >> is OK. Hopefully, no managers rely on, or want, an automatic >> >> validate of the each time it is written. >> > >> > I understand your reasoning but I think this falls in the >> > "nice to have enhancement" category - yes it would be better to always >> > have 'test' as default, but it is not backwards compatible. It is >> not >> > unreasonable to assume that a client that *wants* test-then-set on >> the >> > candidate leaves it out, since it is the default. >> > >> >> I think it's in the "currently broken" category. >> >> test-option: >> >> The test-option element may be specified only if the device >> advertises the :validate capability (Section 8.6). >> >> The test-option element has one of the following values: >> >> test-then-set: Perform a validation test before attempting to >> set. If validation errors occur, do not perform the >> operation. This is the default test-option. >> >> set: Perform a set without a validation test first. >> >> If :validate is not supported, setting this parameter to >> any value will yield a 'unknown-element' error. >> >> So a manager has to make sure the capability is supported >> before turning off this behavior. >> >> So a manager has to write scripts for the database >> that check the :validate capability, so normal incremental >> edits do not cause errors. >> >> Way too fragile! >> >> I think this has to be changed in :validate.1.1. >> The normal use-case for breaks by default. >> IMO, that is a bad default. The default should be >> for to always work the same, unless >> the manager takes explicit action to do something >> differently. >> >> BTW, it is OK to advertise validate.1.1 and not validate.1.0, right? >> Let vendors deprecate broken features if they want. > > So extra effort is needed to check the version of the :validate if > they are not compatible. But 1.1 as you described is more reasonable > to me. Maybe from a long-term perspective, we should do 1.1 > We already are doing a :validate.1.1 to add the 'test-only' enumeration. This is an example of implementors doing what works, rather than what the standard says. It turns out that the big complicated :validate capability that was thought to be so clever when it was written, is actually mostly useless. It turns out that a simple 'test-only' enum that took 20 minutes to implement is much more useful. Backwards compatibility is extremely important when it is real -- based on real operators solving real problems with running code. That's not what we have with :validate.1.0. And if :confirmed-commit.1.0 is considered too lame to preserve, that's a good thing. If version 1.1 is way better, then 1.0 will go away anyway because nobody will want to use it. > washam Andy From Washam.Fan@huaweisymantec.com Tue Jul 7 10:11:49 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 6EBDD28C4D3 for ; Tue, 7 Jul 2009 10:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 ZkTmtYRLkyvY for ; Tue, 7 Jul 2009 10:11:48 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 2CEEC28C1A0 for ; Tue, 7 Jul 2009 10:11:48 -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-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KME00JBIU0GC000@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 07 Jul 2009 19:45:53 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KME00AWPU0GC010@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 07 Jul 2009 19:45:52 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 07 Jul 2009 19:45:52 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 07 Jul 2009 19:45:52 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A5244A6.9030301@netconfcentral.com> References: <4A518642.3050009@netconfcentral.com> <20090706.191447.95257172.mbj@tail-f.com> <4A5244A6.9030301@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] test-option default 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 Jul 2009 17:11:49 -0000 Hi, ----- Original Message ----- From: Andy Bierman Date: Tuesday, July 7, 2009 2:40 am Subject: Re: [Netconf] test-option default To: Martin Bjorklund Cc: netconf@ietf.org > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> The parameter to the operation > >> has 2 different defaults: > >> > >> test: if :validate not supported > > > > This should be 'set'. > > > >> test-then-set: if :validate is supported > > > >> I propose that the default for always be 'test' > >> in the new :validate.1.1 capability (will be in next 4741bis draft). > >> I would like to alter the :validate.1.0 behavior to match, if that > >> is OK. Hopefully, no managers rely on, or want, an automatic > >> validate of the each time it is written. > > > > I understand your reasoning but I think this falls in the > > "nice to have enhancement" category - yes it would be better to always > > have 'test' as default, but it is not backwards compatible. It is > not > > unreasonable to assume that a client that *wants* test-then-set on > the > > candidate leaves it out, since it is the default. > > > > I think it's in the "currently broken" category. > > test-option: > > The test-option element may be specified only if the device > advertises the :validate capability (Section 8.6). > > The test-option element has one of the following values: > > test-then-set: Perform a validation test before attempting to > set. If validation errors occur, do not perform the > operation. This is the default test-option. > > set: Perform a set without a validation test first. > > If :validate is not supported, setting this parameter to > any value will yield a 'unknown-element' error. > > So a manager has to make sure the capability is supported > before turning off this behavior. > > So a manager has to write scripts for the database > that check the :validate capability, so normal incremental > edits do not cause errors. > > Way too fragile! > > I think this has to be changed in :validate.1.1. > The normal use-case for breaks by default. > IMO, that is a bad default. The default should be > for to always work the same, unless > the manager takes explicit action to do something > differently. > > BTW, it is OK to advertise validate.1.1 and not validate.1.0, right? > Let vendors deprecate broken features if they want. So extra effort is needed to check the version of the :validate if they are not compatible. But 1.1 as you described is more reasonable to me. Maybe from a long-term perspective, we should do 1.1 washam > > > > > /martin > > > > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From root@core3.amsl.com Mon Jul 13 07: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 63BB83A6D7E; Mon, 13 Jul 2009 07: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: <20090713141501.63BB83A6D7E@core3.amsl.com> Date: Mon, 13 Jul 2009 07:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 14: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 : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-06.txt Pages : 42 Date : 2009-07-13 This document defines a NETCONF data model (in XML Schema) to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-06.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-monitoring-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13070555.I-D@ietf.org> --NextPart-- From MARKSCOT@nortel.com Mon Jul 13 07:22: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 AEEAC28C2B5 for ; Mon, 13 Jul 2009 07:22:35 -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 pu0wZox0Inbe for ; Mon, 13 Jul 2009 07:22:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9A93028C10B for ; Mon, 13 Jul 2009 07:22:34 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DEMfI16763; Mon, 13 Jul 2009 14:22:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA03C5.60FCA42A" Date: Mon, 13 Jul 2009 10:22:39 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D19BA0E43@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-monitoring-06.txt Thread-Index: AcoDxNhuwrMLyhAiQlKlMFHHIM1TMwAAC9XQ From: "Mark Scott" To: , Cc: netconf@ietf.org Subject: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 14:22:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA03C5.60FCA42A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, A new version (v6) of the NETCONF Monitoring Schema draft has been posted. Changes include: - replaced references to 'schema-retrieval capability' with ' operation'=09 - upper/lowercase alignment on references to 'format' in text and models - changed negative response for to 'data-missing' - ML comments on v05 which required changes in the draft: o 2.1.2: reworded to avoid suggestion that configurable data was contained in the sub-tree (per Balazs' request) o 2.1.2: reworded paragraph partial lock and select statements (per Balazs' suggested text) o Fixed examples in 3.1 and added negative response (per Balazs' comment) o YANG: location changed to leaf-list (per Balazs' comment) o added non-normative references to yang and yang-types (per Balazs' comment) o 2.1.3: added YIN and RNC to format 'enums' text and models - other comments discussed/answered on ML Thank you to all who provided comments. Please direct comments on this version to the ML for further consideration. cheers, Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 13, 2009 10:15 AM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-06.txt Pages : 42 Date : 2009-07-13 This document defines a NETCONF data model (in XML Schema) to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-06.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_001_01CA03C5.60FCA42A Content-Type: application/octet-stream; name="draft-ietf-netconf-monitoring-06.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-netconf-monitoring-06.URL Content-Disposition: attachment; filename="draft-ietf-netconf-monitoring-06.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW5ldGNvbmYtbW9uaXRvcmluZy0wNi50eHQNCg== ------_=_NextPart_001_01CA03C5.60FCA42A Content-Type: text/plain; name="ATT1736944.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1736944.txt Content-Disposition: attachment; filename="ATT1736944.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== ------_=_NextPart_001_01CA03C5.60FCA42A-- From balazs.lengyel@ericsson.com Mon Jul 13 10:41: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 11E8D28C495 for ; Mon, 13 Jul 2009 10:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 F-auFurSqMUH for ; Mon, 13 Jul 2009 10:41:02 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4635528C269 for ; Mon, 13 Jul 2009 10:38:53 -0700 (PDT) X-AuditID: c1b4fb3c-b7bcbae0000053ea-b4-4a5b714a5f32 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 41.8B.21482.A417B5A4; Mon, 13 Jul 2009 19:39:22 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 19:39:21 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 19:39:21 +0200 Message-ID: <4A5B7149.2060208@ericsson.com> Date: Mon, 13 Jul 2009 19:39:21 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4A518642.3050009@netconfcentral.com> <20090706.191447.95257172.mbj@tail-f.com> <4A5244A6.9030301@netconfcentral.com> In-Reply-To: <4A5244A6.9030301@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 17:39:21.0947 (UTC) FILETIME=[DB406AB0:01CA03E0] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] test-option default 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 Jul 2009 17:41:03 -0000 Andy Bierman wrote: > I think it's in the "currently broken" category. > > test-option: > > The test-option element may be specified only if the device > advertises the :validate capability (Section 8.6). > > The test-option element has one of the following values: > > test-then-set: Perform a validation test before attempting to > set. If validation errors occur, do not perform the > operation. This is the default test-option. > > set: Perform a set without a validation test first. > > If :validate is not supported, setting this parameter to > any value will yield a 'unknown-element' error. > Also it is not stated what happens if you omit the option. The normal thing would be to use its default value, but that is not possible if :validate is not supported. So this is clearly broken. Balazs From balazs.lengyel@ericsson.com Mon Jul 13 11:21:49 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 CF2A728C36F for ; Mon, 13 Jul 2009 11:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.93 X-Spam-Level: X-Spam-Status: No, score=-3.93 tagged_above=-999 required=5 tests=[AWL=-2.281, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEjxlxDf1DCs for ; Mon, 13 Jul 2009 11:21:49 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8E0EE28C578 for ; Mon, 13 Jul 2009 11:20:05 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-ad-4a5b7af2c155 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 2C.62.02747.2FA7B5A4; Mon, 13 Jul 2009 20:20:35 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 20:20:34 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 20:20:33 +0200 Message-ID: <4A5B7AF1.2070709@ericsson.com> Date: Mon, 13 Jul 2009 20:20:33 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Mark Scott , Martin Bjorklund References: <085091CB2CA14E4B8B163FFC37C84E9D19BA0E43@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D19BA0E43@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 18:20:33.0950 (UTC) FILETIME=[9CAE23E0:01CA03E6] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 18:21:49 -0000 Hello Mark, Martin, 4.2.) This is invalid XML as the prefix xs is not defined. I also strongly think that "xs:schema" is a very misleading container for a YANG module, or anything other then a true XML Schema. So please remove the xs:schema tags. The yang module should be placed immediately inside Balazs From andy@netconfcentral.com Mon Jul 13 11:41: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 1153C3A6EC5 for ; Mon, 13 Jul 2009 11:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VVOFyaDdDA3 for ; Mon, 13 Jul 2009 11:41:21 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 5002728C4FC for ; Mon, 13 Jul 2009 11:40:30 -0700 (PDT) Received: (qmail 4482 invoked from network); 13 Jul 2009 18:40:55 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2009 18:40:54 -0000 X-YMail-OSG: US1uq18VM1mptKRBr._pmwgGLrXbvLmoVtb3BOFFkH8zVf2UngnexH5fbt8JF0vH3FJCxtYN6ziWQXdqlR2cLAUh1ifitBhJOEg1DJViVWypVacDsUTumeISjp5o_0Y92L7xFYCy1w0coa9nYV9LnIljNRTMxuK.Wn7AZgy77pAg2ijKuYnWNa0XmODU5ouBoeBFHjamzynFKT_ZNgxQWtmHwr0ThB6St2sg2AC5jM71lMYy38jcVMQ0e9s346z_hpzudjkjL4hXt8ar X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5B7FB6.1090500@netconfcentral.com> Date: Mon, 13 Jul 2009 11:40:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <085091CB2CA14E4B8B163FFC37C84E9D19BA0E43@zcarhxm0.corp.nortel.com> <4A5B7AF1.2070709@ericsson.com> In-Reply-To: <4A5B7AF1.2070709@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 18:41:22 -0000 Balazs Lengyel wrote: > Hello Mark, Martin, > > 4.2.) > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > This is also incorrect wrt/ YANG encoding. There is no node inside the node. module bar { } The node would be the top-level node of the content if the format was XSD, not YANG. > This is invalid XML as the prefix xs is not defined. > I also strongly think that "xs:schema" is a very misleading container > for a YANG module, or anything other then a true XML Schema. So please > remove the xs:schema tags. The yang module should be placed immediately > inside > > > Balazs Andy From MARKSCOT@nortel.com Mon Jul 13 11:48:00 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34023A69E9 for ; Mon, 13 Jul 2009 11:48:00 -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_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcBPehr6FGUQ for ; Mon, 13 Jul 2009 11:48:00 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BA9333A685F for ; Mon, 13 Jul 2009 11:47:59 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6DIkEq25358; Mon, 13 Jul 2009 18:46:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 14:47:48 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D19BA12D8@zcarhxm0.corp.nortel.com> In-Reply-To: <4A5B7FB6.1090500@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.txt Thread-Index: AcoD6XVIzlw9JTt1RHWoOUgliuNgrAAAOnxg References: <085091CB2CA14E4B8B163FFC37C84E9D19BA0E43@zcarhxm0.corp.nortel.com> <4A5B7AF1.2070709@ericsson.com> <4A5B7FB6.1090500@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" , "Balazs Lengyel" Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 18:48:00 -0000 Agreed - the YANG example will be corrected. Suggest we remove the top-level node completely and rely on the contents of solely. I.e. XML Schema will include the anyway, YANG will include module, etc. Unless anyone can articulate the need for a generic top-level (minus xs:) node for all formats. Comments? Mark -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com]=20 Sent: Monday, July 13, 2009 2:41 PM To: Balazs Lengyel Cc: Scott, Mark (CAR:2N00); Martin Bjorklund; netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.txt Balazs Lengyel wrote: > Hello Mark, Martin, >=20 > 4.2.) > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > >=20 This is also incorrect wrt/ YANG encoding. There is no node inside the node. module bar { } The node would be the top-level node of the content if the format was XSD, not YANG. > This is invalid XML as the prefix xs is not defined. > I also strongly think that "xs:schema" is a very misleading container > for a YANG module, or anything other then a true XML Schema. So please > remove the xs:schema tags. The yang module should be placed immediately > inside >=20 >=20 > Balazs Andy From balazs.lengyel@ericsson.com Mon Jul 13 12:21: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 782B428C29E for ; Mon, 13 Jul 2009 12:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.153, 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 PQRYrxOlfCAu for ; Mon, 13 Jul 2009 12:21:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 448EE3A6EFC for ; Mon, 13 Jul 2009 12:20:14 -0700 (PDT) X-AuditID: c1b4fb3e-b7be7ae000001a87-39-4a5b8907404b Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id BD.19.06791.7098B5A4; Mon, 13 Jul 2009 21:20:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 21:20:38 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 21:20:38 +0200 Message-ID: <4A5B8906.2070508@ericsson.com> Date: Mon, 13 Jul 2009 21:20:38 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 19:20:38.0627 (UTC) FILETIME=[013C3330:01CA03EF] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] 4741bis: stop-on-error / continue-on-error 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 Jul 2009 19:21:36 -0000 Hello, Did we agree what happens with these options in the 4741bis? As the running datastore is always valid what do these mean? Especially stop-on-error needs some explanation. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From root@core3.amsl.com Mon Jul 13 12:45: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 36FFC3A6ED5; Mon, 13 Jul 2009 12:45:00 -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: <20090713194501.36FFC3A6ED5@core3.amsl.com> Date: Mon, 13 Jul 2009 12:45:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-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, 13 Jul 2009 19:45: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 : NETCONF Configuration Protocol Author(s) : R. Enns, et al. Filename : draft-ietf-netconf-4741bis-01.txt Pages : 113 Date : 2009-07-13 The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-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-4741bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13124035.I-D@ietf.org> --NextPart-- From mbj@tail-f.com Mon Jul 13 12:53: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 776CB28C4B4 for ; Mon, 13 Jul 2009 12:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo-2sRqsq6A3 for ; Mon, 13 Jul 2009 12:53: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 B011128C54B for ; Mon, 13 Jul 2009 12:53:04 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 95C3961600A; Mon, 13 Jul 2009 21:53:34 +0200 (CEST) Date: Mon, 13 Jul 2009 21:53:34 +0200 (CEST) Message-Id: <20090713.215334.93738652.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D19BA12D8@zcarhxm0.corp.nortel.com> References: <4A5B7AF1.2070709@ericsson.com> <4A5B7FB6.1090500@netconfcentral.com> <085091CB2CA14E4B8B163FFC37C84E9D19BA12D8@zcarhxm0.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 19:53:05 -0000 "Mark Scott" wrote: > Agreed - the YANG example will be corrected. There are two faulty examples in 4.2; 2.b and 3.a. > Suggest we remove the top-level node completely and rely on the contents > of solely. I.e. XML Schema will include the anyway, > YANG will include module, etc. Yes, that is what the XSD and YANG module specifies today, it is just the YANG examples that are wrong. /martin From mbj@tail-f.com Mon Jul 13 12:58:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744A428C523 for ; Mon, 13 Jul 2009 12:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=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 DYyFExoS9vpp for ; Mon, 13 Jul 2009 12:58: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 57DEB28C3AA for ; Mon, 13 Jul 2009 12:58:17 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B7631616014; Mon, 13 Jul 2009 21:58:47 +0200 (CEST) Date: Mon, 13 Jul 2009 21:58:47 +0200 (CEST) Message-Id: <20090713.215847.228506627.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <20090713.215334.93738652.mbj@tail-f.com> References: <4A5B7FB6.1090500@netconfcentral.com> <085091CB2CA14E4B8B163FFC37C84E9D19BA12D8@zcarhxm0.corp.nortel.com> <20090713.215334.93738652.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] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 19:58:18 -0000 Martin Bjorklund wrote: > "Mark Scott" wrote: > > Suggest we remove the top-level node completely and rely on the contents > > of solely. I.e. XML Schema will include the anyway, > > YANG will include module, etc. > > Yes, that is what the XSD and YANG module specifies today, it is just > the YANG examples that are wrong. Aha, ok, the XSD should use xs:any, not xs:anytype as it does today. /martin From mbj@tail-f.com Mon Jul 13 14:16: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 E4BD828C64E for ; Mon, 13 Jul 2009 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=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 ZOvoZrVuVo7d for ; Mon, 13 Jul 2009 14:16:24 -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 26A5328C642 for ; Mon, 13 Jul 2009 14:16:24 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 60A9361600A; Mon, 13 Jul 2009 23:16:29 +0200 (CEST) Date: Mon, 13 Jul 2009 23:16:28 +0200 (CEST) Message-Id: <20090713.231628.170795463.mbj@tail-f.com> To: markscot@nortel.com From: Martin Bjorklund In-Reply-To: <20090713.215847.228506627.mbj@tail-f.com> References: <085091CB2CA14E4B8B163FFC37C84E9D19BA12D8@zcarhxm0.corp.nortel.com> <20090713.215334.93738652.mbj@tail-f.com> <20090713.215847.228506627.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] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 21:16:25 -0000 Martin Bjorklund wrote: > Martin Bjorklund wrote: > > "Mark Scott" wrote: > > > Suggest we remove the top-level node completely and rely on the contents > > > of solely. I.e. XML Schema will include the anyway, > > > YANG will include module, etc. > > > > Yes, that is what the XSD and YANG module specifies today, it is just > > the YANG examples that are wrong. > > Aha, ok, the XSD should use xs:any, not xs:anytype as it does > today. Maybe I am confused. When I use the current definition, xmllint accepts both: ... and module foo { ... } So, either the current XSD is fine, or xmllint is wrong. /martin From MARKSCOT@nortel.com Mon Jul 13 14:39:49 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 7E34928C210 for ; Mon, 13 Jul 2009 14:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=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 3IWJLFvdnV0L for ; Mon, 13 Jul 2009 14:39:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7D6F13A6A27 for ; Mon, 13 Jul 2009 14:39:48 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DLdUI07993; Mon, 13 Jul 2009 21:39:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 17:39:26 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D19BA154B@zcarhxm0.corp.nortel.com> In-Reply-To: <20090713.231628.170795463.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.txt Thread-Index: AcoD/zj/dp6IJyYaRH+CQipOzlvIIwAAFlAw References: <085091CB2CA14E4B8B163FFC37C84E9D19BA12D8@zcarhxm0.corp.nortel.com><20090713.215334.93738652.mbj@tail-f.com><20090713.215847.228506627.mbj@tail-f.com> <20090713.231628.170795463.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.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, 13 Jul 2009 21:39:49 -0000 I've seen conflicting information stating xs:AnyType restricts to known W3C types and other suggesting that any freeform XML/text is allowed. So honestly I don't know which is most correct here but my preference is to stick with xs:anyType (current definition). I'm updating v7 accordingly with new YANG examples but leaving the XSD as is. Mark -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Monday, July 13, 2009 5:16 PM To: Scott, Mark (CAR:2N00) Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-06.txt Martin Bjorklund wrote: > Martin Bjorklund wrote: > > "Mark Scott" wrote: > > > Suggest we remove the top-level node completely and rely on the contents > > > of solely. I.e. XML Schema will include the anyway, > > > YANG will include module, etc. > >=20 > > Yes, that is what the XSD and YANG module specifies today, it is just > > the YANG examples that are wrong. >=20 > Aha, ok, the XSD should use xs:any, not xs:anytype as it does > today. Maybe I am confused. When I use the current definition, xmllint accepts both: ... and module foo { ... } So, either the current XSD is fine, or xmllint is wrong. /martin =20 From root@core3.amsl.com Mon Jul 13 15:00: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 DAAFD3A69B4; Mon, 13 Jul 2009 15:00: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: <20090713220001.DAAFD3A69B4@core3.amsl.com> Date: Mon, 13 Jul 2009 15:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-07.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, 13 Jul 2009 22:00: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 : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-07.txt Pages : 42 Date : 2009-07-13 This document defines a NETCONF data model (in XML Schema) to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-07.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-monitoring-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13144917.I-D@ietf.org> --NextPart-- From MARKSCOT@nortel.com Mon Jul 13 15:03:31 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BD828C6EC; Mon, 13 Jul 2009 15:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 YJmRHu+07moe; Mon, 13 Jul 2009 15:03:30 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 38FEC28C6CD; Mon, 13 Jul 2009 15:03:22 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6DM28q26364; Mon, 13 Jul 2009 22:02:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 18:03:46 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D19BA157B@zcarhxm0.corp.nortel.com> In-Reply-To: <20090713220001.DAAFD3A69B4@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-monitoring-07.txt Thread-Index: AcoEBVztHIwE7iOXRRGZ6QU2H7TWPgAADDIQ References: <20090713220001.DAAFD3A69B4@core3.amsl.com> From: "Mark Scott" To: , Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-monitoring-07.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, 13 Jul 2009 22:03:31 -0000 This version updates the examples in sec 4.2 per ML discussion today. Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 13, 2009 6:00 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-07.txt Pages : 42 Date : 2009-07-13 This document defines a NETCONF data model (in XML Schema) to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-07.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. From shikhar@schmizz.net Tue Jul 14 10:06: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 B32483A6E7F for ; Tue, 14 Jul 2009 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 YG-yDkL+45xy for ; Tue, 14 Jul 2009 10:06:48 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id DD1BF3A6D03 for ; Tue, 14 Jul 2009 10:06:47 -0700 (PDT) Received: by gxk9 with SMTP id 9so1138396gxk.13 for ; Tue, 14 Jul 2009 10:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.33.16 with SMTP id g16mr3401244agg.65.1247591160239; Tue, 14 Jul 2009 10:06:00 -0700 (PDT) In-Reply-To: <200906251812.OAA17955@adminfs.snmp.com> References: <200906251812.OAA17955@adminfs.snmp.com> Date: Tue, 14 Jul 2009 22:36:00 +0530 Message-ID: <309bec650907141006j70463cc4o77cb0846cec97d82@mail.gmail.com> From: Shikhar To: David Reid Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh 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 Jul 2009 17:06:48 -0000 On Thu, Jun 25, 2009 at 11:42 PM, David Reid wrote: > From rfc4742 page 3: > > =A0 Once the SSH session has been established, the user (or application) > =A0 will invoke NETCONF as an SSH subsystem called "netconf". =A0Subsyste= m > =A0 support is a feature of SSH version 2 (SSHv2) and is not included in > =A0 SSHv1. =A0Running NETCONF as an SSH subsystem avoids the need for the > =A0 script to recognize shell prompts or skip over extraneous > =A0 information, such as a system message that is sent at shell start-up. > =A0 However, even when a subsystem is used, some extraneous messages may > =A0 be printed by the user's start-up scripts. =A0Implementations MUST sk= ip > =A0 over these messages by searching for an 'xml' start directive, which > =A0 MUST be followed by a element in the 'NETCONF' namespace. > > > I want to make sure I understand this correctly. Does this mean: > > Both the netconf client and server MUST send an xml start directive befor= e > the message and MAY send an xml start directive before any other > message when running over SSH. > > When not running over SSH, the xml start directive is always optional. > > Anything sent by either the client or server before the xml start directi= ve > MUST be ignored when running over SSH. > > When not running over SSH, any extraneous data results in a parse error. I think the below text from section 6.5 of [1] offers a clue as to the motivation of the requirement: "[..] As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish it from arbitrary output generated by shell initialization scripts, etc." Shikhar [1] RFC 4254, SSH Connection Protocol > -David Reid > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From shikhar@schmizz.net Tue Jul 14 10:33:29 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B1B28C16D for ; Tue, 14 Jul 2009 10:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 oRCevE-twG5Z for ; Tue, 14 Jul 2009 10:33:28 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 5C5813A682F for ; Tue, 14 Jul 2009 10:33:28 -0700 (PDT) Received: by yxe34 with SMTP id 34so3261878yxe.29 for ; Tue, 14 Jul 2009 10:32:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.33.16 with SMTP id g16mr3415999agg.65.1247592395303; Tue, 14 Jul 2009 10:26:35 -0700 (PDT) In-Reply-To: <309bec650907141006j70463cc4o77cb0846cec97d82@mail.gmail.com> References: <200906251812.OAA17955@adminfs.snmp.com> <309bec650907141006j70463cc4o77cb0846cec97d82@mail.gmail.com> Date: Tue, 14 Jul 2009 22:56:35 +0530 Message-ID: <309bec650907141026m4e9c81b2s11f122cb79bd9ed4@mail.gmail.com> From: Shikhar To: David Reid Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh 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 Jul 2009 17:33:29 -0000 On Tue, Jul 14, 2009 at 10:36 PM, Shikhar wrote: > > I think the below text from section 6.5 of [1] offers a clue as to the > motivation of the requirement: > > "[..] As the user's shell is usually used to execute the subsystem, it > is advisable for the subsystem protocol to have a "magic cookie" at > the beginning of the protocol transaction to distinguish it from > arbitrary output generated by shell initialization scripts, etc." More context in this thread [1] where some SECSH WG members were in favor of dropping above requirement. Shikhar [1] http://osdir.com/ml/ietf.secsh/2001-01/msg00062.html > Shikhar > > [1] RFC 4254, SSH Connection Protocol From phil@juniper.net Tue Jul 14 12:35: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 559073A69A5 for ; Tue, 14 Jul 2009 12:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 LHs2ApG6HfuJ for ; Tue, 14 Jul 2009 12:35:03 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 171853A635F for ; Tue, 14 Jul 2009 12:35:01 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSlzdyeJoxY5A+Y/r9IBarh/fDM1bnf1W@postini.com; Tue, 14 Jul 2009 12:35:33 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.375.2; Tue, 14 Jul 2009 12:16:30 -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, 14 Jul 2009 12:16:30 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 12:16:30 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Jul 2009 12:16:29 -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 n6EJGSd01150; Tue, 14 Jul 2009 12:16:28 -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 n6EJ5EZh083554; Tue, 14 Jul 2009 19:05:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907141905.n6EJ5EZh083554@idle.juniper.net> To: Shikhar In-Reply-To: <309bec650907141006j70463cc4o77cb0846cec97d82@mail.gmail.com> Date: Tue, 14 Jul 2009 15:05:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Jul 2009 19:16:29.0667 (UTC) FILETIME=[9741AB30:01CA04B7] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh 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 Jul 2009 19:35:04 -0000 Shikhar writes: >"[..] As the user's shell is usually used to execute the subsystem, it >is advisable for the subsystem protocol to have a "magic cookie" at >the beginning of the protocol transaction to distinguish it from >arbitrary output generated by shell initialization scripts, etc." This is not correct. The user's shell is not used to execute the subsystem. It is exec'd directly. Thanks, Phil From andy@netconfcentral.com Tue Jul 14 13:35: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 2C7BE3A69E4 for ; Tue, 14 Jul 2009 13:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.067, 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 14FCMTNe2eeC for ; Tue, 14 Jul 2009 13:35:27 -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 E3D1F3A69EB for ; Tue, 14 Jul 2009 13:35:26 -0700 (PDT) Received: (qmail 8027 invoked from network); 14 Jul 2009 20:35:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 14 Jul 2009 20:35:13 -0000 X-YMail-OSG: qE0mr5YVM1lkc5v473ifJFwchmb7qQufMesy.NQGVCtHYboABbhsEpRAwOJb9wJ.SbhsyGEFloyLAESbmZxFEbT7ynv1CMd.7ixryoUSPH1G5KBejiPy4fsuU7WvmtaomHSPjfpEoUXkTtexvPw9nw_y5reSeMpsVYbbcqt_KZ0484ofZNezPPNuZfZs.V_7LpLwJG68ZYxycgCSwfl0WY2hKvB7qDLP13PWhmaz054EeXfIFa.hVb5QQ2dSBYK2NDmBfJU9iRC312Yfi.KM_HJ_v8Ff1T0w2.JcR7_GvcygmkBnOVrq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5CEB84.5080602@netconfcentral.com> Date: Tue, 14 Jul 2009 13:33:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907141905.n6EJ5EZh083554@idle.juniper.net> In-Reply-To: <200907141905.n6EJ5EZh083554@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh 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 Jul 2009 20:35:28 -0000 Phil Shafer wrote: > Shikhar writes: >> "[..] As the user's shell is usually used to execute the subsystem, it >> is advisable for the subsystem protocol to have a "magic cookie" at >> the beginning of the protocol transaction to distinguish it from >> arbitrary output generated by shell initialization scripts, etc." > > This is not correct. The user's shell is not used to execute > the subsystem. It is exec'd directly. > Yes. Here is an incomplete code snippet for the libssh2 library: /* Request a shell */ mscb->channel = libssh2_channel_open_session(mscb->session); if (!mscb->channel) { if (LOGINFO) { log_info("\nmgr_ses: SSH2 channel open failed"); } return ERR_NCX_SESSION_FAILED; } /* Connect to the NETCONF subsystem */ ret = libssh2_channel_subsystem(mscb->channel, "netconf"); if (ret) { if (LOGINFO) { log_info("\nmgr_ses: Unable to request netconf subsystem"); } return ERR_NCX_SESSION_FAILED; } Notice how there is no reason to send garbage, or magic cookies, or anything other than a proper message at this point? I sort of remember all that text going into the RFC at the time, but it was mostly ignored at the time. Now I think it is all wrong, and should be changed. > Thanks, > Phil Andy From mehmet.ersue@nsn.com Tue Jul 14 14:27: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 787A33A6783 for ; Tue, 14 Jul 2009 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bGT3SEHrXWJP for ; Tue, 14 Jul 2009 14:27:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A6E843A67E1 for ; Tue, 14 Jul 2009 14:27:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6ELQo8c019241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jul 2009 23:26:50 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6ELQovw028050 for ; Tue, 14 Jul 2009 23:26:50 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 23:26:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA04C9.C07A10F7" Date: Tue, 14 Jul 2009 23:26:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft NETCONF Session Agenda Thread-Index: AcoEycAjPsEcyQ2lT4yl1XwWFR+x3w== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 14 Jul 2009 21:26:30.0403 (UTC) FILETIME=[C0DB8530:01CA04C9] Subject: [Netconf] Draft NETCONF Session Agenda 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 Jul 2009 21:27:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA04C9.C07A10F7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find below the draft agenda for the NETCONF session=20 in IETF 75. As usual we will focus mainly on issue discussion.=20 Please send a note to the co-chairs if you have additional=20 ideas for the open mic discussion. Since new version of the drafts are available I would like to=20 ask the draft editors to initiate the issue discussion on the=20 maillist.=20 All NETCONF members, please review the documents and=20 send your comments to the maillist. PS: We need to organize the scribes and 2 minute takers=20 _before_ the meeting. Please help us to start the session=20 on time and send us a note if you volunteer.=20 Bert & Mehmet=20 __________________________________________________ NETCONF WG=20 IETF 75, Stockholm, Sweden TUESDAY, July 28, 2009, 1300-1500=20 WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. Partial Lock RPC for NETCONF - Balazs Lengyel (10 minutes)=20 draft-ietf-netconf-partial-lock=20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20 draft-ietf-netconf-monitoring 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes) draft-ietf-netconf-4741bis 4. With-defaults capability for NETCONF - B. Lengyel/A. Bierman = (20 minutes) draft-ietf-netconf-with-defaults Non-Chartered items: 1. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00 Open mike (15 minutes) New commit operation Are we ready to start Access Control work? Any other topics to discuss?=20 AOB Cheers, Mehmet ------_=_NextPart_001_01CA04C9.C07A10F7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft NETCONF Session Agenda

Dear NETCONF WG,

please find below the draft agenda = for the NETCONF session
in IETF 75. As usual we will focus = mainly on issue discussion.

Please send a note to the co-chairs = if you have additional
ideas for the open mic = discussion.

Since new version of the drafts are = available I would like to
ask the draft editors to initiate = the issue discussion on the
maillist.
All NETCONF members, please review = the documents and
send your comments to the = maillist.

PS: We need to organize the scribes = and 2 minute takers
_before_ the meeting. Please help us = to start the session
on time and send us a note if you = volunteer.

Bert & Mehmet=20

__________________________________________________

NETCONF WG
IETF 75, Stockholm, Sweden

TUESDAY, July 28, 2009, 1300-1500 =

   WG Chairs:
   Bert Wijnen = <bertietf@bwijnen.net>
   Mehmet Ersue = <mehmet.ersue@nsn.com>

   Scribes (IF = no_volunteers THEN wait_forever)
   Agenda bashing (2 = minutes)
   WG status review (5 = minutes)

   Chartered items:

      1. = Partial Lock RPC for NETCONF - Balazs Lengyel (10 minutes)
         = draft-ietf-netconf-partial-lock
      2. = NETCONF Monitoring Schema - Mark Scott (15 minutes) 
          = draft-ietf-netconf-monitoring
      3. = 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes)
          = draft-ietf-netconf-4741bis
      4. = With-defaults capability for NETCONF - B. Lengyel/A. Bierman (20 = minutes)
          = draft-ietf-netconf-with-defaults

   Non-Chartered = items:

      1. = Robust Configuration Management within NETCONF - R. Cole/D. Romascanu = (15 minutes) 
          = draft-cole-netconf-robust-config-00

   Open mike (15 = minutes)
      New = commit operation
      Are = we ready to start Access Control work?
      Any = other topics to discuss?

   AOB
Cheers,
Mehmet

------_=_NextPart_001_01CA04C9.C07A10F7-- From mehmet.ersue@nsn.com Tue Jul 14 14:38: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 446CF3A6A41 for ; Tue, 14 Jul 2009 14:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo4TaD+Db7Qo for ; Tue, 14 Jul 2009 14:38:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3A00C3A635F for ; Tue, 14 Jul 2009 14:38:42 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6ELcJ8c028610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jul 2009 23:38:19 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6ELcICV017544 for ; Tue, 14 Jul 2009 23:38:19 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 23:38:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA04CB.66A735AF" Date: Tue, 14 Jul 2009 23:38:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: draft-ietf-netconf-monitoring-07 Thread-Index: AcoEy2ZeUsCKE7YzTnaYTNTxe7vk/A== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 14 Jul 2009 21:38:18.0617 (UTC) FILETIME=[66FC6690:01CA04CB] Subject: [Netconf] WGLC: draft-ietf-netconf-monitoring-07 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 Jul 2009 21:38:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA04CB.66A735AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG,=20 we had sufficient discussion on the NETCONF monitoring=20 draft since the last WGLC in Febraury. We think the v07 draft Mark submitted addresses now all=20 issues raised on the maillist and the draft appears to be=20 stable for a final WGLC before we go one step further. With this mail we start a WGLC for the NETCONF monitoring draft, which is planned to publish as a Proposed Standard RFC.=20 The WGLC will run until July 24, 2009 so that we can discuss=20 and solve possible issues at IETF 75.=20 Everybody on the NETCONF WG PLEASE REVIEW the draft=20 again and send your comments to the NETCONF maillist.=20 (http://tools.ietf.org/html/draft-ietf-netconf-monitoring-07) Thank you and looking forward for your comments.=20 Cheers, Mehmet ------_=_NextPart_001_01CA04CB.66A735AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC: draft-ietf-netconf-monitoring-07

Dear NETCONF WG,

we had sufficient discussion on the = NETCONF monitoring
draft since the last WGLC in = Febraury.

We think the v07 draft Mark submitted = addresses now all
issues raised on the maillist and = the draft appears to be
stable for a final WGLC before we go = one step further.

With this mail we start a WGLC for = the NETCONF monitoring
draft, which is planned to publish = as a Proposed Standard RFC.

The WGLC will run until July 24, 2009 = so that we can discuss
and solve possible issues at IETF = 75.

Everybody on the NETCONF WG PLEASE = REVIEW the draft
again and send your comments to the = NETCONF maillist.
(<= FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Verdana">http://tools.ietf.org/html/draft-ietf-netconf-monitoring= -07)

Thank you and looking forward for = your comments.

Cheers,
Mehmet

------_=_NextPart_001_01CA04CB.66A735AF-- From dromasca@avaya.com Wed Jul 15 04:27: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 19EF83A685D for ; Wed, 15 Jul 2009 04:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bcHyj1jiTZd for ; Wed, 15 Jul 2009 04:27:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C503F3A67F7 for ; Wed, 15 Jul 2009 04:27:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,404,1243828800"; d="scan'208,217";a="176982358" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jul 2009 07:20:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jul 2009 07:20:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA053E.34F74722" Date: Wed, 15 Jul 2009 13:20:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft NETCONF Session Agenda thread-index: AcoEycAjPsEcyQ2lT4yl1XwWFR+x3wAdFLPA References: From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , Subject: Re: [Netconf] Draft NETCONF Session Agenda 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 Jul 2009 11:27:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA053E.34F74722 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) =09 1. Robust Configuration Management within NETCONF - R. Cole/D. Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00=20 =09 [[DR]] Andy is now a co-author, and the I-D is now at draft-01. Dan =20 ------_=_NextPart_001_01CA053E.34F74722 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft NETCONF Session Agenda
 

From: = netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Munich)

      1. = Robust=20 Configuration Management within NETCONF - R. Cole/D. Romascanu (15=20 minutes) 
         =20 draft-cole-netconf-robust-config-00


[[DR]]  Andy is now a co-author, and the I-D is now = at=20 draft-01.

Dan

 

------_=_NextPart_001_01CA053E.34F74722-- From andy@netconfcentral.com Wed Jul 15 09:29: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 A13B13A6B0E for ; Wed, 15 Jul 2009 09:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=-0.533, 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 WU+KtNW4llCC for ; Wed, 15 Jul 2009 09:29:23 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id A07093A684E for ; Wed, 15 Jul 2009 09:28:44 -0700 (PDT) Received: (qmail 68824 invoked from network); 15 Jul 2009 16:27:46 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 15 Jul 2009 16:27:45 -0000 X-YMail-OSG: qr18TJ4VM1kkizAMUHMrb781_3P.IQCV72ZHBLJltVjRiATHEnSAFzShm7oFmkK8J01VNvqsbrQUkXZk8uKi7vG3si6f1OYsgV_pxXr4QxtWBSDVbdqJdrp0ByTrI97TS591crP8yNIONKllCL7UVxTTOVgf68hE9Bxy3Q5p1EfEwWFmRvHmc3yBcLRVc7KmeBnOpizVwitpV1sv_QtNu8OgfltMhysba.eIlh1A7Vsz7vRU.xfAnXVyFzKzydO5QwHzqvDYMgY7fPKgKIEE_eH771PmwltgDIuGdlwfvWIUJKFe9n14 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5E0300.7030402@netconfcentral.com> Date: Wed, 15 Jul 2009 09:25:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] :confirmed-commit and :startup 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 Jul 2009 16:29:24 -0000 Hi, It seems to me that the requirements for :confirmed-commit preclude any possible concurrent support for the :startup capability. Am I understanding 4741bis, 8.4.1 correctly? It is not clear at all how the agent MUST or SHOULD deal with non-volatile storage of the confirmed commit, especially when :startup is also supported (or if :startup should even allowed together with :candidate). Andy From balazs.lengyel@ericsson.com Wed Jul 15 09:50: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 246B73A6F06 for ; Wed, 15 Jul 2009 09:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 fWSB6nTKHU-U for ; Wed, 15 Jul 2009 09:50:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DC3F53A6BAD for ; Wed, 15 Jul 2009 09:50:34 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-55-4a5e08b51a44 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7E.49.00514.4B80E5A4; Wed, 15 Jul 2009 18:49:57 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:49:13 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:49:13 +0200 Message-ID: <4A5E0888.9070806@ericsson.com> Date: Wed, 15 Jul 2009 18:49:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090626.142918.117864005.mbj@tail-f.com> In-Reply-To: <20090626.142918.117864005.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 16:49:13.0766 (UTC) FILETIME=[2F0FEC60:01CA056C] X-Brightmail-Tracker: AAAAAA== Cc: rgcole01@comcast.net, netconf@ietf.org Subject: Re: [Netconf] draft-cole-netconf-robust-config-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: Wed, 15 Jul 2009 16:50:36 -0000 Hello, A trivial way to invoke tests would be to define them as an rpc in yang and specify the relevant rpc (with inputs and expected outputs) in the test-template. I think the idea of scripts is definitely needed. Maybe we should restrict the scripts to local (to the netconf server scripts) Balazs From balazs.lengyel@ericsson.com Wed Jul 15 09: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 39D9B3A6EB9 for ; Wed, 15 Jul 2009 09:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.112 X-Spam-Level: X-Spam-Status: No, score=-4.112 tagged_above=-999 required=5 tests=[AWL=-1.863, BAYES_00=-2.599, HELO_EQ_SE=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 1PB6Z0ER4bzK for ; Wed, 15 Jul 2009 09:53:08 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5620F3A6BFF for ; Wed, 15 Jul 2009 09:53:08 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-fc-4a5e0937a916 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 80.5D.18827.7390E5A4; Wed, 15 Jul 2009 18:52:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:51:01 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:51:00 +0200 Message-ID: <4A5E08F4.6080004@ericsson.com> Date: Wed, 15 Jul 2009 18:51:00 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090626.142918.117864005.mbj@tail-f.com> In-Reply-To: <20090626.142918.117864005.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 16:51:00.0974 (UTC) FILETIME=[6EF690E0:01CA056C] X-Brightmail-Tracker: AAAAAA== Cc: rgcole01@comcast.net, netconf@ietf.org Subject: [Netconf] robust-config not so clear-cut test-results 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 Jul 2009 16:53:09 -0000 Hello, For tests you describe just 2 results: OK or Failed, the latter leading to rollback. IMO warning type results would be very important. If after a config change I don't have any traffic on an interface, that might be because I lost connectivity or because its the middle of the night and that specific office is closed. In such cases better warn the operator, but not roll-back. When configuring multiple nodes if the 5th of 10 nodes fails in some case you will want to roll-back the first 4 in some other cases not. Both needs to be handled. Balazs From balazs.lengyel@ericsson.com Wed Jul 15 09:53:10 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 0AD6E3A6BFF for ; Wed, 15 Jul 2009 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.019 X-Spam-Level: X-Spam-Status: No, score=-4.019 tagged_above=-999 required=5 tests=[AWL=-1.770, BAYES_00=-2.599, HELO_EQ_SE=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 X-oO7r8GgESL for ; Wed, 15 Jul 2009 09:53:09 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0B4C13A6CB8 for ; Wed, 15 Jul 2009 09:53:08 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-4d-4a5e09887898 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 07.5D.18827.8890E5A4; Wed, 15 Jul 2009 18:53:28 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:53:28 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:53:28 +0200 Message-ID: <4A5E0987.3090108@ericsson.com> Date: Wed, 15 Jul 2009 18:53:27 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090626.142918.117864005.mbj@tail-f.com> In-Reply-To: <20090626.142918.117864005.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 16:53:28.0058 (UTC) FILETIME=[C6A1CDA0:01CA056C] X-Brightmail-Tracker: AAAAAA== Cc: rgcole01@comcast.net, netconf@ietf.org Subject: [Netconf] Changing the candidate during commit [was: draft-cole-netconf-robust-config-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: Wed, 15 Jul 2009 16:53:10 -0000 Hello, Are you allowed to modify the candidate datastore between start-verified-commit and complete-verified-commit? (AFAIK you can modify it between commit and the confirming commit.) This would mean that the Netconf server will need a temporary datastore, that can be used for rollback. Balazs From balazs.lengyel@ericsson.com Wed Jul 15 09:55: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 AAC213A6F2D for ; Wed, 15 Jul 2009 09:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.635 X-Spam-Level: X-Spam-Status: No, score=-5.635 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=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 D1mBnT+lfDpD for ; Wed, 15 Jul 2009 09:55:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 827153A6F20 for ; Wed, 15 Jul 2009 09:55:44 -0700 (PDT) X-AuditID: c1b4fb3c-b7b62ae000003c27-02-4a5e09dabc86 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8F.39.15399.AD90E5A4; Wed, 15 Jul 2009 18:54:50 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:53:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 18:53:46 +0200 Message-ID: <4A5E0999.3070000@ericsson.com> Date: Wed, 15 Jul 2009 18:53:45 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <20090626.142918.117864005.mbj@tail-f.com> <4A44E2DE.2060509@netconfcentral.com> <20090626.212507.126802307.mbj@tail-f.com> <4A4529C1.6020407@netconfcentral.com> In-Reply-To: <4A4529C1.6020407@netconfcentral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 16:53:46.0843 (UTC) FILETIME=[D1D42AB0:01CA056C] X-Brightmail-Tracker: AAAAAA== Cc: rgcole01@comcast.net, netconf@ietf.org Subject: Re: [Netconf] draft-cole-netconf-robust-config-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: Wed, 15 Jul 2009 16:55:45 -0000 Hello, Very interesting draft. Some comments, questions: General: If we introduce some new testing/verification mechanisms, I would like to see how it can be used for to make sure it will be available for writable-running based nodes as well. About this version of the draft: 1) I think your examples are not the best. Today confirmed commit only checks whether OAM connectivity is still available. For any config-change, that is not related to this connectivity, you need extra checks. Examples could be: - configuring an License server. OAM is OK, but the License server does not serve half of the License-client nodes. It is possible to confirm, but obviously extra tests between the License server and its License clients are needed. - Configuring a SIP server. While the config looks nice and it can be committed, will it still serve all the SIP user agents - In telecoms often the OAM connection and the "traffic" connections are on completely different networks for security reasons. So even though OAM is up and running, the configured node might have lost some or all of the traffic links 2) The easiest way to start checks would be to define in the specific YAMs rpcs or relevant state data that the manager can check. We already have these possibilities. Why not let the manager invoke these test. (Could be one big generic-health-check rpc or many small specific tests) Maybe this should go into the YANG usage guide. 3) I asked earlier,but again: What does test-then-set mean for the running config? According to YANG the running is always valid. Which set of checks are run for test-then-set against a candidate? Balazs About the existing commit: I) As Andy pointed out today the commit operation is overloaded (original commit, confirming commit). This can lead to the mistake when two operators both want to send just an original-commit but and up confirming the commit. Broken-> fix it! At least provide a separate confirm-commit operation (compatible change), or maybe also remove the possibility to use a second commit operation for confirming the commit (incompatible change). II) The cancel-commit operation is missing. Add it! III) Netconf should allow the Netconf server itself to rollback a commit, when it detects problems (and issue a corresponding notification). Add the possibility! Balazs From dromasca@avaya.com Wed Jul 15 10:00: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 5CD333A6954 for ; Wed, 15 Jul 2009 10:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 sujqGaHLAwKu for ; Wed, 15 Jul 2009 10:00:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 724333A689A for ; Wed, 15 Jul 2009 10:00:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,405,1243828800"; d="scan'208";a="177026092" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jul 2009 13:00:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jul 2009 13:00:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 19:00:29 +0200 Message-ID: In-Reply-To: <4A5E08F4.6080004@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: robust-config not so clear-cut test-results thread-index: AcoFbJhQf1VG2hnFSyGIsudbCTbZqQAAEUGA References: <20090626.142918.117864005.mbj@tail-f.com> <4A5E08F4.6080004@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Martin Bjorklund" Cc: rgcole01@comcast.net, netconf@ietf.org Subject: Re: [Netconf] robust-config not so clear-cut test-results 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 Jul 2009 17:00:31 -0000 I would not argue that a warning result may be a useful thing, but in the example that you are providing a rollback would not result from just a measurement of traffic on interfaces, but the some more complete tests (like loopbacks, or OAM continuity messages) would be activated before deciding on a rollback. This is where scripts on the server can play a role.=20 Dan =20 > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 > Sent: Wednesday, July 15, 2009 7:51 PM > To: Martin Bjorklund > Cc: rgcole01@comcast.net; andy@netconfcentral.com; Romascanu,=20 > Dan (Dan); netconf@ietf.org > Subject: robust-config not so clear-cut test-results >=20 > Hello, > For tests you describe just 2 results: OK or Failed, the=20 > latter leading to rollback. IMO warning type results would be=20 > very important. If after a config change I don't have any=20 > traffic on an interface, that might be because I lost=20 > connectivity or because its the middle of the night and that=20 > specific office is closed. In such cases better warn the=20 > operator, but not roll-back. >=20 > When configuring multiple nodes if the 5th of 10 nodes fails=20 > in some case you will want to roll-back the first 4 in some=20 > other cases not. Both needs to be handled. >=20 >=20 > Balazs >=20 From dromasca@avaya.com Wed Jul 15 10:12: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 930853A6CE9 for ; Wed, 15 Jul 2009 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, J_CHICKENPOX_73=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 ffGZTBUhCbhv for ; Wed, 15 Jul 2009 10:12:33 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B367C3A683A for ; Wed, 15 Jul 2009 10:12:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,405,1243828800"; d="scan'208";a="177027484" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jul 2009 13:10:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jul 2009 13:10:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 19:10:20 +0200 Message-ID: In-Reply-To: <4A5E0999.3070000@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] draft-cole-netconf-robust-config-01 thread-index: AcoFbS+eHEwV6vRiTxu9IbSBB1uZVAAAeZ1w References: <20090626.142918.117864005.mbj@tail-f.com> <4A44E2DE.2060509@netconfcentral.com> <20090626.212507.126802307.mbj@tail-f.com><4A4529C1.6020407@netconfcentral.com> <4A5E0999.3070000@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Andy Bierman" Cc: rgcole01@comcast.net, netconf@ietf.org Subject: Re: [Netconf] draft-cole-netconf-robust-config-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: Wed, 15 Jul 2009 17:12:34 -0000 Good points concerning the examples.=20 Dan =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel > Sent: Wednesday, July 15, 2009 7:54 PM > To: Andy Bierman > Cc: rgcole01@comcast.net; netconf@ietf.org > Subject: Re: [Netconf] draft-cole-netconf-robust-config-01 >=20 > Hello, > Very interesting draft. Some comments, questions: >=20 > General: > If we introduce some new testing/verification mechanisms, I=20 > would like to see how it can be used for to make sure it will=20 > be available for writable-running based nodes as well. >=20 >=20 > About this version of the draft: > 1) I think your examples are not the best. Today confirmed=20 > commit only checks whether OAM=20 > connectivity is still available. For any config-change, that=20 > is not related to this=20 > connectivity, you need extra checks. Examples could be: > - configuring an License server. OAM is OK, but the License=20 > server does not serve half of the=20 > License-client nodes. It is possible to confirm, but=20 > obviously extra tests between the License=20 > server and its License clients are needed. > - Configuring a SIP server. While the config looks nice and=20 > it can be committed, will it still=20 > serve all the SIP user agents > - In telecoms often the OAM connection and the "traffic"=20 > connections are on completely=20 > different networks for security reasons. So even though OAM=20 > is up and running, the configured=20 > node might have lost some or all of the traffic links >=20 > 2) The easiest way to start checks would be to define in the=20 > specific YAMs rpcs or relevant=20 > state data that the manager can check. We already have these=20 > possibilities. Why not let the=20 > manager invoke these test. (Could be one big=20 > generic-health-check rpc or many small specific=20 > tests) Maybe this should go into the YANG usage guide. >=20 > 3) I asked earlier,but again: What does test-then-set mean=20 > for the running config? According to=20 > YANG the running is always valid. Which set of checks are run=20 > for test-then-set against a=20 > candidate? >=20 > Balazs >=20 >=20 >=20 > About the existing commit: > I) As Andy pointed out today the commit operation is=20 > overloaded (original commit, confirming=20 > commit). This can lead to the mistake when two operators both=20 > want to send just an=20 > original-commit but and up confirming the commit. Broken->=20 > fix it! At least provide a separate=20 > confirm-commit operation (compatible change), or maybe also=20 > remove the possibility to use a=20 > second commit operation for confirming the commit=20 > (incompatible change). >=20 > II) The cancel-commit operation is missing. Add it! >=20 > III) Netconf should allow the Netconf server itself to=20 > rollback a commit, when it detects=20 > problems (and issue a corresponding notification). Add the=20 > possibility! >=20 > Balazs > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From phil@juniper.net Wed Jul 15 11:17: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 724B43A6B86 for ; Wed, 15 Jul 2009 11:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 1QHMABwby4NF for ; Wed, 15 Jul 2009 11:17:01 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id D618A3A67A3 for ; Wed, 15 Jul 2009 11:17:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSl4cu0DDjDh9uEVNMm4DkzyCJvUvNxsH@postini.com; Wed, 15 Jul 2009 11:17: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.375.2; Wed, 15 Jul 2009 11:09:33 -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, 15 Jul 2009 11:09:33 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 11:09:33 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 11:09:32 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6FI9Vd56259; Wed, 15 Jul 2009 11:09:31 -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 n6FHwGOG005788; Wed, 15 Jul 2009 17:58:17 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907151758.n6FHwGOG005788@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A5E0300.7030402@netconfcentral.com> Date: Wed, 15 Jul 2009 13:58:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Jul 2009 18:09:32.0201 (UTC) FILETIME=[6712C190:01CA0577] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] :confirmed-commit and :startup 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 Jul 2009 18:17:02 -0000 Andy Bierman writes: >It seems to me that the requirements for :confirmed-commit >preclude any possible concurrent support for the :startup >capability. They are orthogonal. The only thing that affects is , so your commit confirmed operation should only be affecting . Thanks, Phil From andy@netconfcentral.com Wed Jul 15 11:35: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 0439028C152 for ; Wed, 15 Jul 2009 11:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 dtZbYMTn6zDm for ; Wed, 15 Jul 2009 11:35:43 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 0920D28C11B for ; Wed, 15 Jul 2009 11:35:42 -0700 (PDT) Received: (qmail 65061 invoked from network); 15 Jul 2009 18:28:49 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 15 Jul 2009 18:28:48 -0000 X-YMail-OSG: OOJ.f.AVM1nQq9f5GwuHUsH4xjM2cDjtnz1xJQiMSnOOnc2Nacb8zWaCKGorTff2jt5IIrc71_HhEr0e121IryjoGW06.GXQsZgyG1jdgmwznwSU9mmkRKfmQgFMkoOhZLOBu8M3LhoLTKcBBYjomvcG2CU.8OGol8BKmhx2QPBmWg3lG6aWZRNUK44F3GTpa2.yvILOo60aRg7yvUbOeXOAppSkn4yxU3uDZRu1Zs.phFDG6pT41dWrBa5l_nFgzZZNEm4WKpMOxe2k X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5E1FD6.9010500@netconfcentral.com> Date: Wed, 15 Jul 2009 11:28:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907151758.n6FHwGOG005788@idle.juniper.net> In-Reply-To: <200907151758.n6FHwGOG005788@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] :confirmed-commit and :startup 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 Jul 2009 18:35:44 -0000 Phil Shafer wrote: > Andy Bierman writes: >> It seems to me that the requirements for :confirmed-commit >> preclude any possible concurrent support for the :startup >> capability. > > They are orthogonal. The only thing that affects is > , so your commit confirmed operation should only be > affecting . > Does the draft clearly state this somewhere? I don't think it does. Another issue that came up in conf-calls: Is the agent required to support with filters on the config? I remember the details as you do -- that the only thing the agent was required to support if it advertised :startup was from to . The :url capability is just as unclear as :startup, on this issue. > Thanks, > Phil > Andy From phil@juniper.net Wed Jul 15 12:54: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 8E2A53A6809 for ; Wed, 15 Jul 2009 12:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 Kc26LiZJp-oK for ; Wed, 15 Jul 2009 12:54:37 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id C94AE28C14D for ; Wed, 15 Jul 2009 12:54:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSl4zuvyM6B296iCTrw60hqrtFSdBWEP9@postini.com; Wed, 15 Jul 2009 12:54:42 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.375.2; Wed, 15 Jul 2009 12:48:24 -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); Wed, 15 Jul 2009 12:48:24 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 12:48:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 12:48:23 -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 n6FJmMd10539; Wed, 15 Jul 2009 12:48:22 -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 n6FJb7jA007750; Wed, 15 Jul 2009 19:37:07 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907151937.n6FJb7jA007750@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A5E1FD6.9010500@netconfcentral.com> Date: Wed, 15 Jul 2009 15:37:07 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Jul 2009 19:48:23.0353 (UTC) FILETIME=[3650BA90:01CA0585] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] :confirmed-commit and :startup 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 Jul 2009 19:54:38 -0000 Andy Bierman writes: >Is the agent required to support with filters >on the config? I remember the details as you do -- >that the only thing the agent was required to support if >it advertised :startup was from >to . Somehow ended up in 8.7.5.1 as a modified RPC, but that's a bug in 4741 imho. The distinct startup folks didn't want to support anything fancy on it. But that's not what we ended up with. Thanks, Phil From mehmet.ersue@nsn.com Thu Jul 16 15:01: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 CD99D28C24F for ; Thu, 16 Jul 2009 15:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 n5VNo5U4g3mt for ; Thu, 16 Jul 2009 15:01:37 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4F93028C208 for ; Thu, 16 Jul 2009 15:01:36 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6GM28WL015076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Jul 2009 00:02:08 +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 n6GM28wb031797 for ; Fri, 17 Jul 2009 00:02:08 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 00:02:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0661.0F6B567B" Date: Fri, 17 Jul 2009 00:02:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF Session Agenda Thread-Index: AcoEycAjPsEcyQ2lT4yl1XwWFR+x3wBljQPg References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 16 Jul 2009 22:02:07.0824 (UTC) FILETIME=[0FAF9500:01CA0661] Subject: [Netconf] NETCONF Session Agenda 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 Jul 2009 22:01:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0661.0F6B567B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All,=20 please find below an update for the agenda of the NETCONF=20 session at IETF 75.=20 All NETCONF members, please review the documents and=20 send your comments to the maillist.=20 PS: Please help us to organize 1 scribe and 2 minute takers=20 _before_ the meeting. Thanks. Bert & Mehmet=20 ___________________________________________________ NETCONF WG=20 IETF 75, Stockholm, Sweden =20 TUESDAY, July 28, 2009, 1300-1500=20 =20 WG Chairs: Bert Wijnen > Mehmet Ersue > =20 Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 =20 Chartered items: =20 1. NETCONF Monitoring Schema - Mark Scott/M. Bjorklund/S. Chisholm = (15 minutes) =20 draft-ietf-netconf-monitoring 2. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder/A. Bierman (20 = minutes) draft-ietf-netconf-4741bis 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel = (20 minutes) draft-ietf-netconf-with-defaults Non-Chartered items: =20 1. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu/A. Bierman (15 minutes) =20 draft-cole-netconf-robust-config =20 Open mike (15 minutes) Clarifications for 4742? New commit operation Are we ready to start Access Control work? Any other topics to discuss?=20 =20 AOB =20 ------_=_NextPart_001_01CA0661.0F6B567B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft NETCONF Session Agenda
Hi=20 All,

please find below an update for the agenda of the NETCONF
session at IETF 75.

All NETCONF members, please review the = documents=20 and
send your comments to the=20 maillist.

PS: Please help us to = organize 1 scribe=20 and 2 minute takers
_before_ the meeting. Thanks.

Bert & Mehmet

_______________________________________________= ____

NETCONF WG
IETF 75, = Stockholm,=20 Sweden
 
TUESDAY, July 28, = 2009, 1300-1500=20
 
   WG=20 Chairs:
   Bert Wijnen <bertietf@bwijnen.net>
   Mehmet Ersue <mehmet.ersue@nsn.com>
 
   Scribes = (IF=20 no_volunteers THEN wait_forever)
   Agenda bashing (2 = minutes)=20
   WG status review (5 minutes)
 
   = Chartered=20 items:
 
      1.=20 NETCONF Monitoring Schema - Mark Scott/M. Bjorklund/S. Chisholm (15=20 minutes)  =
         =20 draft-ietf-netconf-monitoring
      2. 4741bis-draft - M. Bjorklund/J.=20 Sch=F6nw=E4lder/A. Bierman (20=20 minutes)
         =20 draft-ietf-netconf-4741bis
      3. With-defaults capability for = NETCONF - A.=20 Bierman/B. Lengyel (20=20 minutes)
         =20 draft-ietf-netconf-with-defaults
   = Non-Chartered=20 items:
 
      1.=20 Robust Configuration Management within NETCONF - R. Cole/D. Romascanu/A. = Bierman=20 (15 minutes)  =
         =20 draft-cole-netconf-robust-config
 
   Open = mike (15=20 minutes)
      Clarifications for=20 4742?
      New commit=20 operation
      Are we ready to start Access = Control=20 work?
      Any other topics to discuss?=20
 
   = AOB

 

------_=_NextPart_001_01CA0661.0F6B567B-- From robert.cole@jhuapl.edu Thu Jul 16 21:44:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D913A6A92 for ; Thu, 16 Jul 2009 21:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=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 77ODTEAOfFXY for ; Thu, 16 Jul 2009 21:44:36 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 38C983A68C6 for ; Thu, 16 Jul 2009 21:44:35 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.14857530; Fri, 17 Jul 2009 00:45:00 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 17 Jul 2009 00:45:00 -0400 From: "Cole, Robert G." To: Balazs Lengyel , Martin Bjorklund Date: Fri, 17 Jul 2009 00:42:58 -0400 Thread-Topic: [Netconf] draft-cole-netconf-robust-config-01 Thread-Index: AcoFbHdMQRnDN25ATuaeV/wZuPK26QBLJeb6 Message-ID: <0A8F66C42F49E448A40E99946404EE5B70A48BB1B3@aplesstar.dom1.jhuapl.edu> References: <20090626.142918.117864005.mbj@tail-f.com>, <4A5E0888.9070806@ericsson.com> In-Reply-To: <4A5E0888.9070806@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rgcole01@comcast.net" , "netconf@ietf.org" Subject: Re: [Netconf] draft-cole-netconf-robust-config-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: Fri, 17 Jul 2009 04:44:37 -0000 Balazs, How is this different from our example of defining a ping.yang test which i= s executed locally from the server? Bob ________________________________________ From: netconf-bounces@ietf.org [netconf-bounces@ietf.org] On Behalf Of Bala= zs Lengyel [balazs.lengyel@ericsson.com] Sent: Wednesday, July 15, 2009 12:49 PM To: Martin Bjorklund Cc: rgcole01@comcast.net; netconf@ietf.org Subject: Re: [Netconf] draft-cole-netconf-robust-config-01 Hello, A trivial way to invoke tests would be to define them as an rpc in yang and= specify the relevant rpc (with inputs and expected outputs) in the test-template. I think the idea of scripts is definitely needed. Maybe we should restrict = the scripts to local (to the netconf server scripts) Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From robert.cole@jhuapl.edu Thu Jul 16 21:47: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 EDF0B3A6A8A for ; Thu, 16 Jul 2009 21:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 7UxuoNWZWM0q for ; Thu, 16 Jul 2009 21:47:47 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id CB0F73A68C6 for ; Thu, 16 Jul 2009 21:47:46 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.14857746; Fri, 17 Jul 2009 00:48:17 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 17 Jul 2009 00:48:17 -0400 From: "Cole, Robert G." To: Balazs Lengyel , Martin Bjorklund Date: Fri, 17 Jul 2009 00:45:46 -0400 Thread-Topic: [Netconf] robust-config not so clear-cut test-results Thread-Index: AcoFbNKVngZEJ2RDTiC30aJUbXaMZwBLKCJR Message-ID: <0A8F66C42F49E448A40E99946404EE5B70A48BB1B4@aplesstar.dom1.jhuapl.edu> References: <20090626.142918.117864005.mbj@tail-f.com>, <4A5E08F4.6080004@ericsson.com> In-Reply-To: <4A5E08F4.6080004@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rgcole01@comcast.net" , "netconf@ietf.org" Subject: Re: [Netconf] robust-config not so clear-cut test-results 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, 17 Jul 2009 04:47:48 -0000 Balazs, Our original intent was to define the Verification tests as a set of active= tests generated from the server. In this case, the traffic will exist. H= owever, I think you raise some interesting points; passive tests could be u= seful, as are warning notifications. Bob ________________________________________ From: netconf-bounces@ietf.org [netconf-bounces@ietf.org] On Behalf Of Bala= zs Lengyel [balazs.lengyel@ericsson.com] Sent: Wednesday, July 15, 2009 12:51 PM To: Martin Bjorklund Cc: rgcole01@comcast.net; netconf@ietf.org Subject: [Netconf] robust-config not so clear-cut test-results Hello, For tests you describe just 2 results: OK or Failed, the latter leading to = rollback. IMO warning type results would be very important. If after a config change I do= n't have any traffic on an interface, that might be because I lost connectivity or because its t= he middle of the night and that specific office is closed. In such cases better warn the ope= rator, but not roll-back. When configuring multiple nodes if the 5th of 10 nodes fails in some case y= ou will want to roll-back the first 4 in some other cases not. Both needs to be handled. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From robert.cole@jhuapl.edu Thu Jul 16 21:57:41 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BB53A6A5B for ; Thu, 16 Jul 2009 21:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 IpJoFki0svcN for ; Thu, 16 Jul 2009 21:57:40 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id D94AB3A6AA7 for ; Thu, 16 Jul 2009 21:57:39 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.14858383; Fri, 17 Jul 2009 00:58:07 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 17 Jul 2009 00:58:07 -0400 From: "Cole, Robert G." To: Balazs Lengyel , Martin Bjorklund Date: Fri, 17 Jul 2009 00:58:07 -0400 Thread-Topic: [Netconf] Changing the candidate during commit [was: draft-cole-netconf-robust-config-01] Thread-Index: AcoFbNK40+Uek33wTaKCEqnxbo4XGgBLRdGW Message-ID: <0A8F66C42F49E448A40E99946404EE5B70A48BB1B5@aplesstar.dom1.jhuapl.edu> References: <20090626.142918.117864005.mbj@tail-f.com>, <4A5E0987.3090108@ericsson.com> In-Reply-To: <4A5E0987.3090108@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rgcole01@comcast.net" , "netconf@ietf.org" Subject: Re: [Netconf] Changing the candidate during commit [was: draft-cole-netconf-robust-config-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: Fri, 17 Jul 2009 04:57:42 -0000 Balazs, I have not given this much thought. But the intent of the Verification tes= ts is to check the candidate configuration once it has been moved to runnin= g. If the tests succeed then the device commits to the current running. I= f fails, it should backout to the previous running. Changing the candidate= between the start-verified-commit and complete-verified-commit should have= no affect on the previous procedure. Bob=20 ________________________________________ From: netconf-bounces@ietf.org [netconf-bounces@ietf.org] On Behalf Of Bala= zs Lengyel [balazs.lengyel@ericsson.com] Sent: Wednesday, July 15, 2009 12:53 PM To: Martin Bjorklund Cc: rgcole01@comcast.net; netconf@ietf.org Subject: [Netconf] Changing the candidate during commit [was: draft-cole-= netconf-robust-config-01] Hello, Are you allowed to modify the candidate datastore between start-verified-co= mmit and complete-verified-commit? (AFAIK you can modify it between commit and the c= onfirming commit.) This would mean that the Netconf server will need a temporary datastore, th= at can be used for rollback. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From balazs.lengyel@ericsson.com Fri Jul 17 06:56:00 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64213A68B0 for ; Fri, 17 Jul 2009 06:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-1.986, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_44=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 c17OCLtS4-ip for ; Fri, 17 Jul 2009 06:56:00 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9DDF53A67EF for ; Fri, 17 Jul 2009 06:55:59 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-3c-4a6078471c1c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id B3.AE.18827.748706A4; Fri, 17 Jul 2009 15:10:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Jul 2009 15:09:59 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Jul 2009 15:09:59 +0200 Message-ID: <4A607826.7070402@ericsson.com> Date: Fri, 17 Jul 2009 15:09:58 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Cole, Robert G." References: <20090626.142918.117864005.mbj@tail-f.com>, <4A5E0888.9070806@ericsson.com> <0A8F66C42F49E448A40E99946404EE5B70A48BB1B3@aplesstar.dom1.jhuapl.edu> In-Reply-To: <0A8F66C42F49E448A40E99946404EE5B70A48BB1B3@aplesstar.dom1.jhuapl.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 13:09:59.0100 (UTC) FILETIME=[E318AFC0:01CA06DF] X-Brightmail-Tracker: AAAAAA== Cc: "rgcole01@comcast.net" , "netconf@ietf.org" Subject: Re: [Netconf] draft-cole-netconf-robust-config-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: Fri, 17 Jul 2009 13:56:00 -0000 You are right it is similar, but there is a slight difference. We should allow the modeler to define his own rpcs to be used for verification, not just standard ones. I think this aspect is missing from the text. But maybe this was your original intent, and we want the same thing. Balazs Cole, Robert G. wrote: > Balazs, > > How is this different from our example of defining a ping.yang test which is executed locally from the server? > > Bob > ________________________________________ > From: netconf-bounces@ietf.org [netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel [balazs.lengyel@ericsson.com] > Sent: Wednesday, July 15, 2009 12:49 PM > To: Martin Bjorklund > Cc: rgcole01@comcast.net; netconf@ietf.org > Subject: Re: [Netconf] draft-cole-netconf-robust-config-01 > > Hello, > A trivial way to invoke tests would be to define them as an rpc in yang and specify the > relevant rpc (with inputs and expected outputs) in the test-template. > > I think the idea of scripts is definitely needed. Maybe we should restrict the scripts to local > (to the netconf server scripts) > > Balazs > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From robert.cole@jhuapl.edu Fri Jul 17 11:55:39 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F1E3A680A for ; Fri, 17 Jul 2009 11:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_44=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 Gl-SYndF1WtO for ; Fri, 17 Jul 2009 11:55:39 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id EEAC73A690C for ; Fri, 17 Jul 2009 11:55:38 -0700 (PDT) Received: from ([128.244.198.90]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.14979159; Fri, 17 Jul 2009 14:56:04 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Fri, 17 Jul 2009 14:56:04 -0400 From: "Cole, Robert G." To: Balazs Lengyel Date: Fri, 17 Jul 2009 14:52:42 -0400 Thread-Topic: [Netconf] draft-cole-netconf-robust-config-01 Thread-Index: AcoG3/lR76snTIzdSoS/YibICJ7XDgAL8p4V Message-ID: <0A8F66C42F49E448A40E99946404EE5B70A48BB1B8@aplesstar.dom1.jhuapl.edu> References: <20090626.142918.117864005.mbj@tail-f.com>, <4A5E0888.9070806@ericsson.com> <0A8F66C42F49E448A40E99946404EE5B70A48BB1B3@aplesstar.dom1.jhuapl.edu>, <4A607826.7070402@ericsson.com> In-Reply-To: <4A607826.7070402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rgcole01@comcast.net" , "netconf@ietf.org" Subject: Re: [Netconf] draft-cole-netconf-robust-config-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: Fri, 17 Jul 2009 18:55:40 -0000 Balazs, We did have some text in the draft outlining various options for test defin= itions, one of which was to have the modeler embed tests with configuration= objects in the device model. I believe this to be a very attractive optio= n. However, to move things along in the draft we choose to work out the de= tails of a simpler, more straightforward option of passing reference to a t= est module test instance. Bob ________________________________________ From: Balazs Lengyel [balazs.lengyel@ericsson.com] Sent: Friday, July 17, 2009 9:09 AM To: Cole, Robert G. Cc: Martin Bjorklund; rgcole01@comcast.net; netconf@ietf.org Subject: Re: [Netconf] draft-cole-netconf-robust-config-01 You are right it is similar, but there is a slight difference. We should allow the modeler to define his own rpcs to be used for verificat= ion, not just standard ones. I think this aspect is missing from the text. But maybe this= was your original intent, and we want the same thing. Balazs Cole, Robert G. wrote: > Balazs, > > How is this different from our example of defining a ping.yang test which= is executed locally from the server? > > Bob > ________________________________________ > From: netconf-bounces@ietf.org [netconf-bounces@ietf.org] On Behalf Of Ba= lazs Lengyel [balazs.lengyel@ericsson.com] > Sent: Wednesday, July 15, 2009 12:49 PM > To: Martin Bjorklund > Cc: rgcole01@comcast.net; netconf@ietf.org > Subject: Re: [Netconf] draft-cole-netconf-robust-config-01 > > Hello, > A trivial way to invoke tests would be to define them as an rpc in yang a= nd specify the > relevant rpc (with inputs and expected outputs) in the test-template. > > I think the idea of scripts is definitely needed. Maybe we should restric= t the scripts to local > (to the netconf server scripts) > > Balazs > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From andy@netconfcentral.com Sun Jul 19 12:33: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 EEF643A6AC7 for ; Sun, 19 Jul 2009 12:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82EYuygvjysQ for ; Sun, 19 Jul 2009 12:33:53 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 2233D3A68A7 for ; Sun, 19 Jul 2009 12:33:52 -0700 (PDT) Received: (qmail 46286 invoked from network); 19 Jul 2009 19:33:49 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@67.126.130.211 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 19 Jul 2009 19:33:49 -0000 X-YMail-OSG: gs9ySakVM1nwdSPvuTAViCWe6DooAGNAByAQ8e.0G_OzccBKIZ2b8WK2A9aitqi65kui06uW3TOArLazJT.R1HN_dT22XaTKI12LzRj2D.kPJcA83_XOFHBRWK3pBS4cYfPDWnq.B4qGbx0fS31UgkFcO_LJNlUIb6lDgJmQ05SVFDvKgbMtMqzy6Akkq.3P6uWa8S3d7MNED4Ie7HQKz337tZzMxG6MW9FfmTqt4R3VWMNrII9F7Ao_nvVJ4N70J5DObr0w5aN6B22rK640IL0CwqgToWv7miELR8064ougncma.BXy X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6374AA.8000202@netconfcentral.com> Date: Sun, 19 Jul 2009 12:31:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907151937.n6FJb7jA007750@idle.juniper.net> In-Reply-To: <200907151937.n6FJb7jA007750@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] :confirmed-commit and :startup 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 Jul 2009 19:33:54 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Is the agent required to support with filters >> on the config? I remember the details as you do -- >> that the only thing the agent was required to support if >> it advertised :startup was from >> to . > > Somehow ended up in 8.7.5.1 as a modified > RPC, but that's a bug in 4741 imho. The distinct > startup folks didn't want to support anything fancy > on it. But that's not what we ended up with. > I don't implement the other (unintended) required aspects of :startup, not only because it's too hard, but because it's not secure. The startup config is an external file and not a real database. There is no filtering or access control implemented for it, like the real databases. There was never any original intent to treat as just another database, especially with the slow NVRAM devices at the time. It was expected that copy-config from running to NV-storage might even be expensive on the agent, let alone filtering, editing, and access control enforcement. > Thanks, > Phil > Andy From mbj@tail-f.com Mon Jul 20 01:27: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 4E7773A6D1F for ; Mon, 20 Jul 2009 01:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvnEclG6S6b3 for ; Mon, 20 Jul 2009 01:27:21 -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 5201F3A6D1D for ; Mon, 20 Jul 2009 01:27:21 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 83F21616001; Mon, 20 Jul 2009 10:25:54 +0200 (CEST) Date: Mon, 20 Jul 2009 10:25:54 +0200 (CEST) Message-Id: <20090720.102554.43439315.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A5E0300.7030402@netconfcentral.com> References: <4A5E0300.7030402@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] :confirmed-commit and :startup 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, 20 Jul 2009 08:27:22 -0000 Hi, Andy Bierman wrote: > Hi, > > It seems to me that the requirements for :confirmed-commit > preclude any possible concurrent support for the :startup > capability. > > Am I understanding 4741bis, 8.4.1 correctly? > It is not clear at all how the agent MUST or SHOULD > deal with non-volatile storage of the confirmed commit, > especially when :startup is also supported (or if :startup > should even allowed together with :candidate). Is this a different issue than what I wrote in http://www.ietf.org/mail-archive/web/netconf/current/msg04532.html? /martin From balazs.lengyel@ericsson.com Mon Jul 20 08:15:49 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 3E71C3A6A09 for ; Mon, 20 Jul 2009 08:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 qNnReEMghcd1 for ; Mon, 20 Jul 2009 08:15:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F27F03A6A0C for ; Mon, 20 Jul 2009 08:15:44 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-fc-4a648a1ac6fe Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 91.15.00514.A1A846A4; Mon, 20 Jul 2009 17:15:38 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 17:15:37 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 17:15:37 +0200 Message-ID: <4A648A18.1010801@ericsson.com> Date: Mon, 20 Jul 2009 17:15:36 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org References: <20090713194501.36FFC3A6ED5@core3.amsl.com> In-Reply-To: <20090713194501.36FFC3A6ED5@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 15:15:37.0447 (UTC) FILETIME=[EF8A6770:01CA094C] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Tracking 4741bis issues - draft-ietf-netconf-4741bis-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, 20 Jul 2009 15:15:49 -0000 Hello, Where is the list of outstanding issue stored? It would be nice to have a list on a tracker or in the document itself. Keeping it only in private lists leads to the same comments popping up again and again. It also makes tracking issue for non-authors more difficult. Balazs From balazs.lengyel@ericsson.com Tue Jul 21 02:32: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 6C0D73A6CFD for ; Tue, 21 Jul 2009 02:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.043 X-Spam-Level: X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 NjbXsQp-mmKn for ; Tue, 21 Jul 2009 02:32:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 242923A694F for ; Tue, 21 Jul 2009 02:32:29 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-fd-4a65873b967d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E1.8F.14528.B37856A4; Tue, 21 Jul 2009 11:15:39 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 11:14:39 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 11:14:39 +0200 Message-ID: <4A6586FF.9070501@ericsson.com> Date: Tue, 21 Jul 2009 11:14:39 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list References: <20090713194501.36FFC3A6ED5@core3.amsl.com> In-Reply-To: <20090713194501.36FFC3A6ED5@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 09:14:39.0582 (UTC) FILETIME=[ACDC37E0:01CA09E3] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Tue, 21 Jul 2009 09:32:31 -0000 Hello, Some comments: - The role of warnings is still unclear. - What does stop-on-error and continue-on-error mean if running is always valid? - page 94) if a system does not support filtering of startup it could still support get-config without filters. So the description "This is optional-to-implement on the agent because not all agents will support filtering for this database." Should be changed to "Even if an agent supports the startup feature it MAY ignore filters for the startup datastore." - the test option should not be allowed for the running configuration, as it always has to be valid. See also discussion about the default value of the test option - what happens if we delete the startup configuration and then the device boots. Describe! - The candidate datastore is missing for delete-config in the YAM. Balazs From balazs.lengyel@ericsson.com Tue Jul 21 09:54: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 90A3D3A6E54 for ; Tue, 21 Jul 2009 09:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.728 X-Spam-Level: X-Spam-Status: No, score=-4.728 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 v6+hjQD+XexH for ; Tue, 21 Jul 2009 09:54:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 01FCA3A6813 for ; Tue, 21 Jul 2009 09:54:12 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-ff-4a65f2b31fdb Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 60.AD.14528.3B2F56A4; Tue, 21 Jul 2009 18:54:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:54:10 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:54:10 +0200 Message-ID: <4A65F2B2.4000506@ericsson.com> Date: Tue, 21 Jul 2009 18:54:10 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list References: <20090713194501.36FFC3A6ED5@core3.amsl.com> In-Reply-To: <20090713194501.36FFC3A6ED5@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 16:54:10.0908 (UTC) FILETIME=[DEA6B1C0:01CA0A23] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Tue, 21 Jul 2009 16:54:16 -0000 Hello, Normative references to YANG and yang-types are missing. Balazs From mbj@tail-f.com Tue Jul 21 14:59: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 160CF3A6B7B for ; Tue, 21 Jul 2009 14:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=0.424, 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 evWiqvQucIMg for ; Tue, 21 Jul 2009 14:59:20 -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 3A65D3A683A for ; Tue, 21 Jul 2009 14:59:20 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C40176C4E4; Tue, 21 Jul 2009 23:59:20 +0200 (CEST) Date: Tue, 21 Jul 2009 23:59:19 +0200 (CEST) Message-Id: <20090721.235919.227500522.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A6586FF.9070501@ericsson.com> References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A6586FF.9070501@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] Comments :draft-ietf-netconf-4741bis-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: Tue, 21 Jul 2009 21:59:21 -0000 Balazs Lengyel wrote: > Hello, > Some comments: > > - The role of warnings is still unclear. Yes, still an open issue. Maybe we should disuss it in Stockholm. > - What does stop-on-error and continue-on-error mean if running is always > - valid? stop-on-error means that as soon as a node is modified which would result in an invalid config, the node and the rest of the edit-config is ignored. I don't really like this idea, since you get "some" valid result, but you don't know what it is. continue-on-error means that the node which would result in an invalid config is skipped, and the rest of the edit-config is applied. > - page 94) if a system does not support filtering of startup it could still > - support get-config without filters. So the description > "This is optional-to-implement on the agent because not all > agents will support filtering for this database." > Should be changed to > "Even if an agent supports the startup feature it MAY ignore filters for the > startup datastore." In an earlier msg Phil argued that get-config on startup shouldn't be supported at all. > - the test option should not be allowed for the running configuration, > - as it always has to be valid. See also discussion about the default value of > - the test option Do you mean 'set'? > - what happens if we delete the startup configuration and then the device > - boots. Describe! The text says: Resets the device to its factory defaults Do we need more text? > - The candidate datastore is missing for delete-config in the YAM. It is consistent with the text. Should it be allowed? /martin From mbj@tail-f.com Tue Jul 21 15:10: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 1CE153A6EC9 for ; Tue, 21 Jul 2009 15:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.282, 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 501qLYAgWW5C for ; Tue, 21 Jul 2009 15:10:52 -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 463893A6EB5 for ; Tue, 21 Jul 2009 15:10:47 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2837376C4E4; Wed, 22 Jul 2009 00:10:47 +0200 (CEST) Date: Wed, 22 Jul 2009 00:10:46 +0200 (CEST) Message-Id: <20090722.001046.81118613.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4A65F2B2.4000506@ericsson.com> References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A65F2B2.4000506@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] Comments :draft-ietf-netconf-4741bis-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: Tue, 21 Jul 2009 22:10:53 -0000 Balazs Lengyel wrote: > Hello, > Normative references to YANG and yang-types are missing. Thanks, I will add them. /martin From balazs.lengyel@ericsson.com Wed Jul 22 05:35:46 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D0B3A6821 for ; Wed, 22 Jul 2009 05:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.314 X-Spam-Level: X-Spam-Status: No, score=-5.314 tagged_above=-999 required=5 tests=[AWL=0.935, 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 Rf4y7m325HgS for ; Wed, 22 Jul 2009 05:35:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 023853A685E for ; Wed, 22 Jul 2009 05:35:44 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-db-4a67073d4399 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A4.D1.14528.D37076A4; Wed, 22 Jul 2009 14:34:05 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 14:33:50 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 14:33:50 +0200 Message-ID: <4A67072D.1020009@ericsson.com> Date: Wed, 22 Jul 2009 14:33:49 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A6586FF.9070501@ericsson.com> <20090721.235919.227500522.mbj@tail-f.com> In-Reply-To: <20090721.235919.227500522.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 12:33:50.0321 (UTC) FILETIME=[AA780610:01CA0AC8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 12:35:46 -0000 Hello, Martin Bjorklund wrote: >> - What does stop-on-error and continue-on-error mean if running is always >> - valid? > > stop-on-error means that as soon as a node is modified which would > result in an invalid config, the node and the rest of the edit-config > is ignored. I don't really like this idea, since you get "some" valid > result, but you don't know what it is. > > continue-on-error means that the node which would result in an invalid > config is skipped, and the rest of the edit-config is applied. BALAZS: I understand the basic concept, but skipping one-or-more nodes might make some already configured nodes invalid as well, so it is a hell of a task to check. E.g. there is a "must a == b;" statement on a step 1) You set a to 100 : it is OK step 2) You set a dozen other leafs somewhere in the model step 3) You set b to 100 (whose previous value was 80): this fails because e.g., b has some strict restriction on it, or b depends on some external resource. Lets assume b was the last thing to modify, so stop-on-error and continue-on-error mean the same thing in this case. Unless you roll back step 1 you have got an invalid datastore. But first you have to find step 1, then check any other changes that depend on step 1. Also rolling back step 2 is NOT mentioned in NETCONF. Balazs From balazs.lengyel@ericsson.com Wed Jul 22 06:46: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 1BB073A68E1 for ; Wed, 22 Jul 2009 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[AWL=0.872, 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 7A-ycg53xhhD for ; Wed, 22 Jul 2009 06:46:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C07F13A6A3D for ; Wed, 22 Jul 2009 06:46:45 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-63-4a670c12da55 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7D.04.14528.21C076A4; Wed, 22 Jul 2009 14:54:43 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 14:54:42 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 14:54:42 +0200 Message-ID: <4A670C11.7070308@ericsson.com> Date: Wed, 22 Jul 2009 14:54:41 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A6586FF.9070501@ericsson.com> <20090721.235919.227500522.mbj@tail-f.com> In-Reply-To: <20090721.235919.227500522.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 12:54:42.0576 (UTC) FILETIME=[94DEF900:01CA0ACB] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 13:46:47 -0000 Martin Bjorklund wrote: >> - page 94) if a system does not support filtering of startup it could still >> - support get-config without filters. So the description >> "This is optional-to-implement on the agent because not all >> agents will support filtering for this database." >> Should be changed to >> "Even if an agent supports the startup feature it MAY ignore filters for the >> startup datastore." > > In an earlier msg Phil argued that get-config on startup shouldn't be > supported at all. > BALAZS: That could be done, but my guess(!) is, that to return the complete startup inline should not be so difficult. Anyway the current sentence is wrong. If the filters are the problem, it should be the filters that are made optional. >> - the test option should not be allowed for the running configuration, >> - as it always has to be valid. See also discussion about the default value of >> - the test option > > Do you mean 'set'? BALAZS: yes, sorry. > >> - what happens if we delete the startup configuration and then the device >> - boots. Describe! > > The text says: > > Resets the device to its factory defaults BALAZS: You are right. This is mentioned in chapter 8.7.5.1. but not in 7.4. Delete-config is a nice operation, it means different things for every datastore - running: not allowed (could have been reset to factory default) - startup: reset to factory default which is not the same as delete - they might return different things for a subsequent get-config - candidate: make the datastore completely empty (or maybe not allowed?) > > Do we need more text? > >> - The candidate datastore is missing for delete-config in the YAM. > > It is consistent with the text. Should it be allowed? BALAZS: In the XSD it was allowed. I think we do need to state explicitly in the text whether delete-config on candidate is allowed or not. It would be strange to have a delete-config operation that only works on the startup config, and there it does not delete a config, but rather resets it. (I also don't understand why we want to allow delete on URL. This is not a file-manager, but forget this for now.) Balazs From andy@netconfcentral.com Wed Jul 22 08:31: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 D6C163A6B40 for ; Wed, 22 Jul 2009 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Riz833AjpWT9 for ; Wed, 22 Jul 2009 08:31:26 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id C21393A67EA for ; Wed, 22 Jul 2009 08:31:26 -0700 (PDT) Received: from [68.142.200.225] by n18.bullet.mail.mud.yahoo.com with NNFMP; 22 Jul 2009 15:25:48 -0000 Received: from [68.142.201.250] by t6.bullet.mud.yahoo.com with NNFMP; 22 Jul 2009 15:25:48 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 22 Jul 2009 15:25:48 -0000 X-Yahoo-Newman-Id: 804166.30614.bm@omp411.mail.mud.yahoo.com Received: (qmail 18848 invoked from network); 22 Jul 2009 15:25:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 22 Jul 2009 15:25:48 -0000 X-YMail-OSG: TUlH3q8VM1nQZ2pfyI8hRtEZ3M4Fu3ztwU6tBxuLw_vNjTzO899_vTqbn_cy1tSAfOX27.wGsz6dIxXWgAJc0C55SfP7t.HnB5gxDulw_9Xn07pmDMe4BI23UHA3H_10ea59HEN0dcapUU1jrZi0nw6eQPk296to4i62zzb0wpU4evgt4LQ9vdPG1BERYmmwlCGPsv7NeAme8R9ad93UzofOLclFKRPkO.qBmfRsokTbdORQ3Bs2BHPBtBtCT0fyD4o68rf2sFx2TMvXhVhYjLtmZsYkYFlGdjiCUBgBmIV8yzXqOsm6jXkXO4F.VTlFTbU8Good X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A672F82.60303@netconfcentral.com> Date: Wed, 22 Jul 2009 08:25:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A6586FF.9070501@ericsson.com> <20090721.235919.227500522.mbj@tail-f.com> <4A670C11.7070308@ericsson.com> In-Reply-To: <4A670C11.7070308@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 15:31:29 -0000 Balazs Lengyel wrote: > > > Martin Bjorklund wrote: .... >>> - The candidate datastore is missing for delete-config in the YAM. >> >> It is consistent with the text. Should it be allowed? > > BALAZS: In the XSD it was allowed. I think we do need to state > explicitly in the text whether delete-config on candidate is allowed or > not. I do not allow it. The is an internal data structure. What does it mean to delete the candidate? Isn't that just , so there is no point in using ? > > It would be strange to have a delete-config operation that only works on > the startup config, and there it does not delete a config, but rather > resets it. no -- it deletes it. a 'reset' would be like a 'restore' operation? > (I also don't understand why we want to allow delete on URL. This is not > a file-manager, but forget this for now.) It is a file manager, when is used. If you allow the user to build up a bunch of local files with copy-config to a URL, then allowing the user to delete them makes sense. There is no way to list which files exist, which is a big hole, but... Back to an issue to resolve on : What if I can support a on without any filters, but that's all? Can I reject any request with a filter as an 'operation-failed' error? (IMO, yes) I agree with Phil that there was never any intent to require anything but a manual 'save' operation. The rest was supposed to be optional to implement. > > Balazs > Andy From balazs.lengyel@ericsson.com Wed Jul 22 09:49: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 A61533A6929 for ; Wed, 22 Jul 2009 09:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.431 X-Spam-Level: X-Spam-Status: No, score=-5.431 tagged_above=-999 required=5 tests=[AWL=0.818, 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 aMRWW0Nw5jmA for ; Wed, 22 Jul 2009 09:49:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 209C63A6B6B for ; Wed, 22 Jul 2009 09:49:12 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-79-4a6742cea170 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D6.03.14528.EC2476A4; Wed, 22 Jul 2009 18:48:15 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:48:09 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:48:09 +0200 Message-ID: <4A6742C8.70504@ericsson.com> Date: Wed, 22 Jul 2009 18:48:08 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A6586FF.9070501@ericsson.com> <20090721.235919.227500522.mbj@tail-f.com> <4A670C11.7070308@ericsson.com> <4A672F82.60303@netconfcentral.com> In-Reply-To: <4A672F82.60303@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 16:48:09.0204 (UTC) FILETIME=[3178CB40:01CA0AEC] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 16:49:41 -0000 Andy Bierman wrote: > > Back to an issue to resolve on : > > What if I can support a on without any filters, > but that's all? Can I reject any request with a filter as > an 'operation-failed' error? (IMO, yes) > > I agree with Phil that there was never any intent to require > anything but a manual 'save' operation. The rest was supposed to be > optional to implement. > Options 1) Just ignore the filters as if they were absent 2) Reject the get-config with filters 3) State that it is not supported for startup. I see here a use case: I want to know what is the delta between startup and running. Anyway we must choose between the 3 options and document it properly. Balazs From balazs.lengyel@ericsson.com Wed Jul 22 10:09: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 BE6BD3A6897 for ; Wed, 22 Jul 2009 10:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_00=-2.599, HELO_EQ_SE=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 bsdYrvrAiwqu for ; Wed, 22 Jul 2009 10:09:26 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EEA463A6BAB for ; Wed, 22 Jul 2009 10:08:54 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-c5-4a6743c27667 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 2E.6F.18827.2C3476A4; Wed, 22 Jul 2009 18:52:19 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:52:18 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:52:18 +0200 Message-ID: <4A6743C2.8000909@ericsson.com> Date: Wed, 22 Jul 2009 18:52:18 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A6586FF.9070501@ericsson.com> <20090721.235919.227500522.mbj@tail-f.com> <4A670C11.7070308@ericsson.com> <4A672F82.60303@netconfcentral.com> In-Reply-To: <4A672F82.60303@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 16:52:18.0703 (UTC) FILETIME=[C62F51F0:01CA0AEC] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 17:09:26 -0000 Andy Bierman wrote: > Balazs Lengyel wrote: >> >> Martin Bjorklund wrote: > .... >>>> - The candidate datastore is missing for delete-config in the YAM. >>> It is consistent with the text. Should it be allowed? >> BALAZS: In the XSD it was allowed. I think we do need to state >> explicitly in the text whether delete-config on candidate is allowed or >> not. > > I do not allow it. > The is an internal data structure. > What does it mean to delete the candidate? > Isn't that just , so there is no point in > using ? > > >> It would be strange to have a delete-config operation that only works on >> the startup config, and there it does not delete a config, but rather >> resets it. > > no -- it deletes it. > a 'reset' would be like a 'restore' operation? > The draft says: "Resets the device to its factory defaults" (chapter 8.7.5.1) I thought delete a datastore means to delete all it's content, so if you call get-config subsequently it will return an empty reply. It seems we better define delete-config more precisely. Please Martin add it to the open issues. Balazs From andy@netconfcentral.com Wed Jul 22 10:11: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 0253F3A6A3E for ; Wed, 22 Jul 2009 10:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh4dPwNj2JrT for ; Wed, 22 Jul 2009 10:11:47 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 197D63A6827 for ; Wed, 22 Jul 2009 10:11:46 -0700 (PDT) Received: (qmail 48461 invoked from network); 22 Jul 2009 17:10:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2009 17:10:59 -0000 X-YMail-OSG: puL0ryMVM1l0BRY.iXf0wPQyAWQgp_VJ7A1_X6pJb0ro1hbEYIve0IMz38qEfh8CRhcwZOqeiEAELKHjW4ZvIhaSqWe0ZigOc4SUh_.NXMNFxG1lzYpqagTKNsUabOQq7MWNXFkLayqzPp9y5uxFVWWaVW8EGlglAI5m5uxBpMdghY7OP4ZLKn7AsHlsbnQwLQdpFLG6RO7L0j.rb5j2DktOwD_rIRT4J61EZ7wvKV00os3NSBGGPihhEUqBgJ3gYHXYmnlnV8mrSBL8eVWWnGxKJi3CQG77_5zGsPXw9YI_raiSIoLr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A674825.4080106@netconfcentral.com> Date: Wed, 22 Jul 2009 10:11:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Balazs Lengyel References: <20090713194501.36FFC3A6ED5@core3.amsl.com> <4A6586FF.9070501@ericsson.com> <20090721.235919.227500522.mbj@tail-f.com> <4A670C11.7070308@ericsson.com> <4A672F82.60303@netconfcentral.com> <4A6743C2.8000909@ericsson.com> In-Reply-To: <4A6743C2.8000909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 17:11:48 -0000 Balazs Lengyel wrote: > > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> >>> Martin Bjorklund wrote: >> .... >>>>> - The candidate datastore is missing for delete-config in the YAM. >>>> It is consistent with the text. Should it be allowed? >>> BALAZS: In the XSD it was allowed. I think we do need to state >>> explicitly in the text whether delete-config on candidate is allowed or >>> not. >> >> I do not allow it. >> The is an internal data structure. >> What does it mean to delete the candidate? >> Isn't that just , so there is no point in >> using ? >> >> >>> It would be strange to have a delete-config operation that only works on >>> the startup config, and there it does not delete a config, but rather >>> resets it. >> >> no -- it deletes it. >> a 'reset' would be like a 'restore' operation? >> > The draft says: > "Resets the device to its factory defaults" (chapter 8.7.5.1) > > I thought delete a datastore means to delete all it's content, so if you > call get-config subsequently it will return an empty reply. > > It seems we better define delete-config more precisely. Please Martin > add it to the open issues. > I see what you mean. I think Martin already provided the answer, which is that the config will be re-populated with the factory defaults (according to possibly new boot-time config). The is gone until it some session does a copy-config from to again. What if the startup file is configurable on the agent? So deletes the current startup file, but if the agent reboots and the operator selects a different stored startup file, then the config will reappear. > Balazs > Andy From phil@juniper.net Wed Jul 22 11:09: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 1BB963A699A for ; Wed, 22 Jul 2009 11:09:51 -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 KESsKGADmrrp for ; Wed, 22 Jul 2009 11:09:50 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 580293A6897 for ; Wed, 22 Jul 2009 11:09:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSmdVVl0pHiE1o6YwOHluRz1jll4m1Jx5@postini.com; Wed, 22 Jul 2009 11:09: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.375.2; Wed, 22 Jul 2009 10:55:50 -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, 22 Jul 2009 10:55:50 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:55:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:55:49 -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 n6MHtmd19733; Wed, 22 Jul 2009 10:55:48 -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 n6MHiQak060406; Wed, 22 Jul 2009 17:44:26 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907221744.n6MHiQak060406@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A674825.4080106@netconfcentral.com> Date: Wed, 22 Jul 2009 13:44:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2009 17:55:49.0316 (UTC) FILETIME=[A57CB840:01CA0AF5] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 18:09:51 -0000 Andy Bierman writes: >I think Martin already provided the answer, >which is that the config will be re-populated with >the factory defaults (according to possibly new boot-time config). Is this really what we want? Shouldn't delete delete it and a "restore-factory-defaults" operations restore the factory defaults? We don't need no stinking magic. Note that delete deletes the contents of the database, not the database itself. So you don't lose your candidate database, but it should be empty after a delete. Thanks, Phil From andy@netconfcentral.com Wed Jul 22 11:27: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 D18B23A6A31 for ; Wed, 22 Jul 2009 11:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHE-gBXC7L3F for ; Wed, 22 Jul 2009 11:27:28 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 09C4C3A685B for ; Wed, 22 Jul 2009 11:27:27 -0700 (PDT) Received: (qmail 39973 invoked from network); 22 Jul 2009 18:25:44 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2009 18:25:43 -0000 X-YMail-OSG: MdLEnyQVM1kTOk8S9QgGWM1neQFXj6v7mCNGnL6DmTs8EORkpBR960MnYmRW8AjOzSL9.pQJ_NwlHRgLyPQDJLqQY1zPVkuFrfOCrB3nZVTVfg5QGe.fYgbQp5K7fMvHq2z6rWD6fUf9RLkpC5L8tUcLPOb2CNjWkOfiav4_GE9.hoDmV6d5GzFkmJc.cWNJIRQ66TrWzR9av3RWJzxLdGvyoCxrdm0TOo640Q22BNcNZ4V1N6yQFJT1ZNW91xhQrLrE.so6Rh_o9Qo6wqO_0JF8BINFwZmi7bP6HKkmkoEeYu4lrNJ7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6759AE.6050806@netconfcentral.com> Date: Wed, 22 Jul 2009 11:25:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907221744.n6MHiQak060406@idle.juniper.net> In-Reply-To: <200907221744.n6MHiQak060406@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 18:27:28 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I think Martin already provided the answer, >> which is that the config will be re-populated with >> the factory defaults (according to possibly new boot-time config). > > Is this really what we want? Shouldn't delete delete it > and a "restore-factory-defaults" operations restore the > factory defaults? > > We don't need no stinking magic. > I meant to say restored on the next reboot. Not right away. Good point. The agent will auto-populate whatever it deems appropriate. An empty config and a partial config are no different here. I agree with you that calling this reset to factory defaults is misleading. > Note that delete deletes the contents of the database, not > the database itself. So you don't lose your candidate > database, but it should be empty after a delete. > How is this different than ? If 'none', then why bother? But I don't really care, as long as the spec is clear and everybody has to support the same thing. > Thanks, > Phil > Andy From andy@netconfcentral.com Wed Jul 22 11:34: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 F23163A6900 for ; Wed, 22 Jul 2009 11:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 8U0Qqamy7uhK for ; Wed, 22 Jul 2009 11:34:45 -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 1A4433A685B for ; Wed, 22 Jul 2009 11:33:31 -0700 (PDT) Received: (qmail 86578 invoked from network); 22 Jul 2009 18:30:42 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 22 Jul 2009 18:30:42 -0000 X-YMail-OSG: YJpdE7QVM1nQ04mNZI7VGtfz.fWhhhxKVsEGY4_S5UbP4IlktjHdoQHABjJpNc8rgfl6YwLCdq1SfrcQ3zAIvO4GbbYzgadfFDxdgWX3_dMc_5CsQ6BWCrN3d5ASVO022g_8u8CXCf6S0AlLIaw1wVM_2pGzdAyLm5ThuakEM9JXpsapumACL3TgmRc82LHrFIT0wYPjZx3j9VZ1oueWUDFrCajcLkVb6kCvh_hbPr2sFnthafi3dUKi6wMaV5q91AKNmEaB26S.VUUc7bzNtrDPYL1iQrItgxZszIUYYhRQWhVA X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A675AD9.9050902@netconfcentral.com> Date: Wed, 22 Jul 2009 11:30:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A5E0300.7030402@netconfcentral.com> <20090720.102554.43439315.mbj@tail-f.com> In-Reply-To: <20090720.102554.43439315.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] :confirmed-commit and :startup 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, 22 Jul 2009 18:34:46 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> It seems to me that the requirements for :confirmed-commit >> preclude any possible concurrent support for the :startup >> capability. >> >> Am I understanding 4741bis, 8.4.1 correctly? >> It is not clear at all how the agent MUST or SHOULD >> deal with non-volatile storage of the confirmed commit, >> especially when :startup is also supported (or if :startup >> should even allowed together with :candidate). > > Is this a different issue than what I wrote in > http://www.ietf.org/mail-archive/web/netconf/current/msg04532.html? > no -- this is the same issue. I like your idea. I agree that :startup could be an independent variable, and should not hard-wired to 'not(:candidate)'. That would mean that if :startup is advertised, the NV-storage will never get updated automatically, no matter what else the agent advertises. The failed confirmed-commit procedure just refers to restoring the config. > > /martin > Andy From phil@juniper.net Wed Jul 22 11:40:33 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 C7F483A685B for ; Wed, 22 Jul 2009 11:40:32 -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 T75FeBEwWCgr for ; Wed, 22 Jul 2009 11:40:31 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 0F94F3A699A for ; Wed, 22 Jul 2009 11:40:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSmdc0/iJMAN3C8KViT80YGfSDzkfSfL+@postini.com; Wed, 22 Jul 2009 11:40:32 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.375.2; Wed, 22 Jul 2009 11:30:38 -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, 22 Jul 2009 11:30:38 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 11:30:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 11:30:37 -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 n6MIUad39412; Wed, 22 Jul 2009 11:30:36 -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 n6MIJEf9060728; Wed, 22 Jul 2009 18:19:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907221819.n6MIJEf9060728@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6759AE.6050806@netconfcentral.com> Date: Wed, 22 Jul 2009 14:19:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2009 18:30:37.0506 (UTC) FILETIME=[82253A20:01CA0AFA] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 18:40:33 -0000 Andy Bierman writes: >How is this different than ? Discard changes reverts to the last committed version of the configuration (equivalent to loading the committed config into the candidate config database). Thanks, Phil From andy@netconfcentral.com Wed Jul 22 12:37: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 7A73F3A681D for ; Wed, 22 Jul 2009 12:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_64=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 x4Bi9JZySzVr for ; Wed, 22 Jul 2009 12:37:29 -0700 (PDT) Received: from n73.bullet.mail.sp1.yahoo.com (n73.bullet.mail.sp1.yahoo.com [98.136.44.191]) by core3.amsl.com (Postfix) with SMTP id AD5E83A68A6 for ; Wed, 22 Jul 2009 12:37:29 -0700 (PDT) Received: from [216.252.122.219] by n73.bullet.mail.sp1.yahoo.com with NNFMP; 22 Jul 2009 19:36:26 -0000 Received: from [68.142.200.224] by t4.bullet.sp1.yahoo.com with NNFMP; 22 Jul 2009 19:36:26 -0000 Received: from [68.142.201.73] by t5.bullet.mud.yahoo.com with NNFMP; 22 Jul 2009 19:36:26 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 22 Jul 2009 19:36:26 -0000 X-Yahoo-Newman-Id: 239229.32204.bm@omp425.mail.mud.yahoo.com Received: (qmail 59058 invoked from network); 22 Jul 2009 19:36:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 22 Jul 2009 19:36:25 -0000 X-YMail-OSG: PXk4bk4VM1lM7kznOAJn.QGvM1CNxzYMdg7IvEEangM4HaBipO5t4kWluUAmW8Z.detnNqEIq9AdPUzkrtVrP8pq5ftQC71axX8wVSY9P3spqwZIOiG3KB4zTFtfR2emYFzHE5xMXrupFPbn7L0Z7yeY4urFx5Uv0KgBnlqcTX7TVNQbYXfshm6ifySEHDySIotp_3So.YF2ewA53omViZkPeOlVprQMzeUReQ1qqoM2C1deeSubJjMjsSaSD0HpBfRsJwifdkeo3oG8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A676A41.1060100@netconfcentral.com> Date: Wed, 22 Jul 2009 12:36:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907221819.n6MIJEf9060728@idle.juniper.net> In-Reply-To: <200907221819.n6MIJEf9060728@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 19:37:30 -0000 Phil Shafer wrote: > Andy Bierman writes: >> How is this different than ? > > Discard changes reverts to the last committed version of the > configuration (equivalent to loading the committed config into > the candidate config database). > Let me ask another way. If I do a on the right afterwards, what is returned? discard-changes: // all config=true nodes currently in delete-config: OR // all config=true nodes currently in OR something else? if so, where do these contents magically appear from? > Thanks, > Phil > Andy From mbj@tail-f.com Wed Jul 22 15:02: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 77A4C3A6B58 for ; Wed, 22 Jul 2009 15:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDuuoivhQjEt for ; Wed, 22 Jul 2009 15:02: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 AFC673A68B0 for ; Wed, 22 Jul 2009 15:02: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 8E0D776C4CA; Wed, 22 Jul 2009 23:59:41 +0200 (CEST) Date: Wed, 22 Jul 2009 23:59:41 +0200 (CEST) Message-Id: <20090722.235941.67264633.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200907221744.n6MHiQak060406@idle.juniper.net> References: <4A674825.4080106@netconfcentral.com> <200907221744.n6MHiQak060406@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] Comments :draft-ietf-netconf-4741bis-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: Wed, 22 Jul 2009 22:02:31 -0000 Phil Shafer wrote: > Note that delete deletes the contents of the database, not > the database itself. So you don't lose your candidate > database, but it should be empty after a delete. RFC 4741 says: Delete a configuration datastore. And if the target is a local file, shouldn't the file be removed (not truncated to size 0)? Further, the candidate cannot be deleted according to 4741 (delete-config is not listed in 8.3.5). /martin From Washam.Fan@huaweisymantec.com Wed Jul 22 19:47: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 497A43A6823 for ; Wed, 22 Jul 2009 19:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 S4RKkCrbAT1i for ; Wed, 22 Jul 2009 19:47:15 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id E1FF53A6CA7 for ; Wed, 22 Jul 2009 19:47:10 -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-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KN7000EGRP39W90@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 23 Jul 2009 10:46:15 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KN700C2KRP3GH10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 23 Jul 2009 10:46:15 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 23 Jul 2009 10:46:15 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Thu, 23 Jul 2009 10:46:15 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4A675AD9.9050902@netconfcentral.com> References: <4A5E0300.7030402@netconfcentral.com> <20090720.102554.43439315.mbj@tail-f.com> <4A675AD9.9050902@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] :confirmed-commit and :startup 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, 23 Jul 2009 02:47:16 -0000 Hi, Should we explicitly specify how to handle :confirmed-commit and :startup co-existence in the doc? washam ----- Original Message ----- From: Andy Bierman Date: Thursday, July 23, 2009 2:35 am Subject: Re: [Netconf] :confirmed-commit and :startup To: Martin Bjorklund Cc: netconf@ietf.org > Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > >> Hi, > >> > >> It seems to me that the requirements for :confirmed-commit > >> preclude any possible concurrent support for the :startup > >> capability. > >> > >> Am I understanding 4741bis, 8.4.1 correctly? > >> It is not clear at all how the agent MUST or SHOULD > >> deal with non-volatile storage of the confirmed commit, > >> especially when :startup is also supported (or if :startup > >> should even allowed together with :candidate). > > > > Is this a different issue than what I wrote in > > http://www.ietf.org/mail-archive/web/netconf/current/msg04532.html? > > > > no -- this is the same issue. > > I like your idea. > I agree that :startup could be an independent variable, > and should not hard-wired to 'not(:candidate)'. > > That would mean that if :startup is advertised, > the NV-storage will never get updated automatically, > no matter what else the agent advertises. > The failed confirmed-commit procedure just refers to > restoring the config. > > > > > /martin > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Wed Jul 22 20:17:58 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 E1DE63A6B34 for ; Wed, 22 Jul 2009 20:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 4fHyfMYK6YA6 for ; Wed, 22 Jul 2009 20:17:58 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 79D693A690A for ; Wed, 22 Jul 2009 20:17: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-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KN7000XRPVG9W80@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 23 Jul 2009 10:06:52 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KN700B0NPVGUA10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 23 Jul 2009 10:06:52 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 23 Jul 2009 10:06:52 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Thu, 23 Jul 2009 10:06:52 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090722.235941.67264633.mbj@tail-f.com> References: <4A674825.4080106@netconfcentral.com> <200907221744.n6MHiQak060406@idle.juniper.net> <20090722.235941.67264633.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Thu, 23 Jul 2009 03:17:59 -0000 Hi, After reading all relevant comments, it seems to me that there exists different semantics of to different I think, we should definitely spell out which datastores should apply to. When applies to a , what does it imply? reset/sync? empty the content? Or remove the datastore? (And what should be done if expected datastore is lacking?) washam ----- Original Message ----- From: Martin Bjorklund Date: Thursday, July 23, 2009 6:02 am Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt To: phil@juniper.net Cc: netconf@ietf.org > Phil Shafer wrote: > > Note that delete deletes the contents of the database, not > > the database itself. So you don't lose your candidate > > database, but it should be empty after a delete. > > RFC 4741 says: > > Delete a configuration datastore. > > And if the target is a local file, shouldn't the file be removed (not > truncated to size 0)? > > Further, the candidate cannot be deleted according to 4741 > (delete-config is not listed in 8.3.5). > > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From phil@juniper.net Wed Jul 22 21:55: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 1C4883A6CE4 for ; Wed, 22 Jul 2009 21:55:26 -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 npMyx3qoL-fm for ; Wed, 22 Jul 2009 21:55:25 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 4823D3A6961 for ; Wed, 22 Jul 2009 21:55:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSmftDIQVWK9+uH/Kx3Lddr40r3w6ReBd@postini.com; Wed, 22 Jul 2009 21:55:26 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.375.2; Wed, 22 Jul 2009 21:44:53 -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); Wed, 22 Jul 2009 21:44:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 21:44:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jul 2009 21:44: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 n6N4igd23764; Wed, 22 Jul 2009 21:44:42 -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 n6N4XJ6G064490; Thu, 23 Jul 2009 04:33:19 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907230433.n6N4XJ6G064490@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20090722.235941.67264633.mbj@tail-f.com> Date: Thu, 23 Jul 2009 00:33:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2009 04:44:42.0867 (UTC) FILETIME=[4BB12430:01CA0B50] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Thu, 23 Jul 2009 04:55:26 -0000 Martin Bjorklund writes: >RFC 4741 says: > Delete a configuration datastore. This makes little sense. What does it mean to delete ? >And if the target is a local file, shouldn't the file be removed (not >truncated to size 0)? > >Further, the candidate cannot be deleted according to 4741 >(delete-config is not listed in 8.3.5). So should all this be called out explicitly in -bis? Thanks, Phil From phil@juniper.net Wed Jul 22 21:57: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 CF7F63A6CEA for ; Wed, 22 Jul 2009 21:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 BXqCTCXlM1OS for ; Wed, 22 Jul 2009 21:57:09 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id E6FBD3A68F4 for ; Wed, 22 Jul 2009 21:57:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSmftXAQBI9rAfQ9cuZcagdvLz6Gakyq7@postini.com; Wed, 22 Jul 2009 21:57:09 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.375.2; Wed, 22 Jul 2009 21:41:01 -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, 22 Jul 2009 21:41:01 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 21:41:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jul 2009 21:41:00 -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 n6N4exd22829; Wed, 22 Jul 2009 21:41:00 -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 n6N4TbdA064455; Thu, 23 Jul 2009 04:29:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907230429.n6N4TbdA064455@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A676A41.1060100@netconfcentral.com> Date: Thu, 23 Jul 2009 00:29:37 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Jul 2009 04:41:00.0573 (UTC) FILETIME=[C731C4D0:01CA0B4F] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Thu, 23 Jul 2009 04:57:09 -0000 Andy Bierman writes: >If I do a on the right afterwards, >what is returned? > >discard-changes: > > > // all config=true nodes currently in > There are no config=false nodes in running. >delete-config: > > Yes, it should be empty. Thanks, Phil From andy@netconfcentral.com Thu Jul 23 04:45: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 B185D3A688C for ; Thu, 23 Jul 2009 04:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 uy2QSkqsNK6o for ; Thu, 23 Jul 2009 04:45:09 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id E6F443A63EB for ; Thu, 23 Jul 2009 04:45:08 -0700 (PDT) Received: (qmail 70895 invoked from network); 23 Jul 2009 11:43:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 23 Jul 2009 11:43:43 -0000 X-YMail-OSG: 6R_07AoVM1noIRXp1TmvQIeQhBBo9axJdPvGBV2rYsaUGGMDRxyG718ANDEnP8Km7FNkMGaQ4mvlRMdu5UqEiUPVO6X7vR2ruZCZSS7A_AkEwIwSm3bufEBE9yphAKGmFgjzBj7X3BRQnAd3PI1K_Svu9HVkAf1xApqYdobIa3L0XAyKhoHTP95VDNwQpt2m47a289d78dufMJ4L7cZlzyLi.xDpMzZYDyR2z8PuA1aFLQxhnIvurtNsF_Gau8mB0UjNPrWI7njZfwEXq23Hw0e1h3yAjyK3yl9NXKbMZzH7Efvhmbs2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A684CFD.9060408@netconfcentral.com> Date: Thu, 23 Jul 2009 04:43:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907230429.n6N4TbdA064455@idle.juniper.net> In-Reply-To: <200907230429.n6N4TbdA064455@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Thu, 23 Jul 2009 11:45:10 -0000 Phil Shafer wrote: > Andy Bierman writes: >> If I do a on the right afterwards, >> what is returned? >> >> discard-changes: >> >> >> // all config=true nodes currently in >> > > There are no config=false nodes in running. > >> delete-config: >> >> > > Yes, it should be empty. I see your point. A delete-config could be seen as a shortcut way to do an edit-config (operation=delete) on every single top-level node in the candidate. All implementations certainly allow that, or they are supposed to. (Not sure if deleting a node that the agent insists on creating again right away fits into this picture, though). Is this something that comes up often? No, but delete-config is rarely used anyway, because it is such an extreme action. > > Thanks, > Phil > Andy From mbj@tail-f.com Thu Jul 23 12:51:32 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD253A68CC for ; Thu, 23 Jul 2009 12:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqOgWlRTbcBZ for ; Thu, 23 Jul 2009 12:51:32 -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 08ADB3A676A for ; Thu, 23 Jul 2009 12:51:32 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5729B76C54E; Thu, 23 Jul 2009 21:50:05 +0200 (CEST) Date: Thu, 23 Jul 2009 21:50:05 +0200 (CEST) Message-Id: <20090723.215005.222579354.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200907230433.n6N4XJ6G064490@idle.juniper.net> References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@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] Comments :draft-ietf-netconf-4741bis-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: Thu, 23 Jul 2009 19:51:32 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >RFC 4741 says: > > Delete a configuration datastore. > > This makes little sense. What does it mean to delete ? According to 4741, running cannot be deleted. /martin From mehmet.ersue@nsn.com Fri Jul 24 05:46:16 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41ACE28C1B1 for ; Fri, 24 Jul 2009 05:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.957 X-Spam-Level: X-Spam-Status: No, score=-4.957 tagged_above=-999 required=5 tests=[AWL=1.642, 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 ifsfetM60WTT for ; Fri, 24 Jul 2009 05:46:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id D4A6828C194 for ; Fri, 24 Jul 2009 05:46:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6OCk4mQ025838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2009 14:46:04 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6OCk3XT004136; Fri, 24 Jul 2009 14:46:04 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 14:46:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jul 2009 14:46:02 +0200 Message-ID: In-Reply-To: <4A68B359.9040802@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt Thread-Index: AcoLx9cJNsogs+qwRd2T5H3A+n5GvgAD/nAQ References: <2E23AE0E4AED07418C26486630C852A02D8931@FIESEXC030.nsn-intra.net> <4A649038.70303@netconfcentral.com><4A66F259.7090002@ericsson.com> <4A673764.7070804@s3group.com><1248331496.4674.25.camel@missotis> <4A6817AE.8000906@ericsson.com> <4A68B359.9040802@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , X-OriginalArrivalTime: 24 Jul 2009 12:46:03.0571 (UTC) FILETIME=[B4589830:01CA0C5C] Subject: Re: [Netconf] [netmod] FW: I-DAction:draft-linowski-netmod-yang-abstract-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 12:46:16 -0000 Hi Andy, From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 > Ersue, Mehmet (NSN - DE/Munich) wrote: > >=20 > > Hi Balazs, > >=20 > > thank you for pointing this out. > >=20 > > We indeed have a lot to do and the -00 draft is for sure > > not complete. > >=20 > > Actions/rpcs in groupings/lists and type information on > > groupings are features we definitely need. > > We would be happy to have your suggestions and input. > >=20 >=20 >=20 > Hi, >=20 > Didn't we do a requirements gathering phase of some sort, > in order to get to the point where charter decisions > were made, so that the NETMOD WG could proceed and > finish in finite time? Yes, we had long discussions on this and decided to start the work based on the WG items listed in the NETMOD charter. At the same time, IIRC based on the request of not-negligible amount of persons we wrote following text into the charter: "Language abstractions that facilitate model extensibility=20 and reuse have been identified as a work area and will be=20 considered as a work item or may be integrated into the=20 YANG document based on WG consensus." This was the consensus we had after the requirements and=20 NETMOD charter discussion. BTW: We had similar discussions also later. E.g. we discussed in the interim meeting on "rpc statement in list". http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00221 The consensus was not to add it to YANG 1.0 with=20 the hope that it'll be considered later.=20 =20 > I believe the consensus at the time was that we did > not want an OO data modeling language and we choose YANG over several > other proposals, including the OO proposal from your co-author. Actually I don't like the term "OO". It does not explain what we would like to have. I also don't want YANG to be=20 an "object oriented programming language". But OTOH I want language abstractions and modeling language=20 features which support extensibility and top-down modeling. I don't think it is a contradiction to have both groupings and=20 complex types as YANG features. Both have their specialities and are worth to use for specific purposes. It is the feature richness which makes a language successful. Different people will model their YAM on different abstraction=20 levels. Some will use only groupings because they aim to model=20 structured data tables. Others will use complex types _and_ groupings because they have a bigger amount of modeling work=20 to do. Their system and the huge amount of data models ask=20 for top-down design and a hierarchical modeling. =20 > It is rather subjective to start comparing comfort-levels > with 1 variant of the IPFIX model or another. I doubt we > could reach agreement in the IETF on a data modeling language > that had enough OO programming language features to make a > real difference. I prefer to get a stable YANG 1.0 deployed, > and start defining some standard content. =20 As I wrote in another mail I fully support the targets of the WG developing YANG 1.0 with the decided set of features. What we are discussing is relevant for YANG 1.x. > IMO, the DML used > would not make much difference at all if I were deciding whether to > implement the IPFIX model or not. >=20 >=20 > > Cheers, > > Mehmet > > Cheers, Mehmet >=20 >=20 >=20 > Andy >=20 >=20 From andy@netconfcentral.com Fri Jul 24 18:28: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 02A083A688A for ; Fri, 24 Jul 2009 18:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, 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 MPT5BcVQFVxM for ; Fri, 24 Jul 2009 18:28:58 -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 B3DA23A63CB for ; Fri, 24 Jul 2009 18:28:47 -0700 (PDT) Received: (qmail 78357 invoked from network); 25 Jul 2009 01:28:45 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 25 Jul 2009 01:28:45 -0000 X-YMail-OSG: kzBjo.IVM1nviRmtARvd4NmkvThcykEuM9aSzXoFQfXBTy.096_.3x9tzWhtPq94vGGGV8GqKQIzFF7ge1g_5IfaaNtHNTwLIAwn0yCxYqpz096MyctITQhl7AF4y_0EpWHnVWu3JFudyBHMYNHtsRGCA5rGGYs27R24yWqagp3_G7TjrnLmVQJW3VOigN1_H5DlyUWFcMh6SrKtzkxFDGhFdAmB61f.QUpOD6qZO7lwxBxO00Ba_E15H_5coekayrNhRE_sZWy7uziZ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6A5FEA.50803@netconfcentral.com> Date: Fri, 24 Jul 2009 18:29:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] is non-destructive on as well as ? 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, 25 Jul 2009 01:28:59 -0000 Hi, If the operation fails, then the config is supposed to be left as-it-was, but what about the ? One example: pruning empty NP containers. Or the might change by implementation choice, if it is unspecified in the standard. So is it specified, and I just missed it (again)? Andy From phil@juniper.net Fri Jul 24 20:07:00 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDE33A677C for ; Fri, 24 Jul 2009 20:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 PUsuEY1rDgmS for ; Fri, 24 Jul 2009 20:07:00 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id A5A5D3A67C2 for ; Fri, 24 Jul 2009 20:06:52 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSmp2zeVWxx9JyeLhtJOLZlWMM2g4E/sh@postini.com; Fri, 24 Jul 2009 20:06:54 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.375.2; Fri, 24 Jul 2009 20:03:14 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 20:03:14 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 20:03:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Jul 2009 20:03:13 -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 n6P33Cd76116; Fri, 24 Jul 2009 20:03:12 -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 n6P2pmRh083441; Sat, 25 Jul 2009 02:51:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907250251.n6P2pmRh083441@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6A5FEA.50803@netconfcentral.com> Date: Fri, 24 Jul 2009 22:51:48 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2009 03:03:13.0091 (UTC) FILETIME=[72BA9130:01CA0CD4] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] is non-destructive on as well as ? 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, 25 Jul 2009 03:07:00 -0000 Andy Bierman writes: >If the operation fails, then the config >is supposed to be left as-it-was, but what about the ? Candidate is untouched. >One example: pruning empty NP containers. These can be pruned at any time. Thanks, Phil From andy@netconfcentral.com Sat Jul 25 07:26:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3723A6810 for ; Sat, 25 Jul 2009 07:26:37 -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 altm0P13uiWA for ; Sat, 25 Jul 2009 07:26:36 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 181813A6768 for ; Sat, 25 Jul 2009 07:26:36 -0700 (PDT) Received: (qmail 71810 invoked from network); 25 Jul 2009 14:17:46 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2009 14:17:45 -0000 X-YMail-OSG: BRDEoMEVM1m8QDS687KWBXM97DmpDSU32m5OjwTjuBVB6._SB4FJ.YI30JRqNxpb6_xyshLMVlckuTzK4wUDdhPcsTicqbeRNTlrj2dc51g3eK.ExhShSyTZLpO.m9Chht9MEK2O_ZCO58icwN5Kh_4DFqFaI.j1EapZRv.l8Xu8zkqmoEKqgwn1NTr2MIp8mgw5sK6eGf9IF_GKD6brMAwbOJC0emRFr1EikDiSjU2_Fgdw4Zhd0osXZoQwmy8ROsevVoOHN1CxQC8bJOoTjaqULyhbFkJxTHtLDyPKhQEXLSVgmtzf X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6B142C.4070104@netconfcentral.com> Date: Sat, 25 Jul 2009 07:18:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907250251.n6P2pmRh083441@idle.juniper.net> In-Reply-To: <200907250251.n6P2pmRh083441@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] is non-destructive on as well as ? 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, 25 Jul 2009 14:26:37 -0000 Phil Shafer wrote: > Andy Bierman writes: >> If the operation fails, then the config >> is supposed to be left as-it-was, but what about the ? > > Candidate is untouched. > where does it say this in the draft? I don't think it does. >> One example: pruning empty NP containers. > > These can be pruned at any time. > not in the . what if the operator for some dumb reason decides to create an NP container, and then fill it with leafs one at a time: ... none 7 This needs to work, even if it is not the best way to use . That's why I wait until the to delete empty NP containers. > Thanks, > Phil > Andy From andy@netconfcentral.com Sat Jul 25 08:59: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 408823A6807 for ; Sat, 25 Jul 2009 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 UfR9ZVOpPFd4 for ; Sat, 25 Jul 2009 08:59:08 -0700 (PDT) Received: from n9.bullet.mail.mud.yahoo.com (n9.bullet.mail.mud.yahoo.com [209.191.86.157]) by core3.amsl.com (Postfix) with SMTP id 4DBA53A68A9 for ; Sat, 25 Jul 2009 08:59:08 -0700 (PDT) Received: from [68.142.194.244] by n9.bullet.mail.mud.yahoo.com with NNFMP; 25 Jul 2009 15:59:03 -0000 Received: from [68.142.201.247] by t2.bullet.mud.yahoo.com with NNFMP; 25 Jul 2009 15:59:03 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 25 Jul 2009 15:59:03 -0000 X-Yahoo-Newman-Id: 937757.34482.bm@omp408.mail.mud.yahoo.com Received: (qmail 65522 invoked from network); 25 Jul 2009 15:59:03 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 25 Jul 2009 15:59:03 -0000 X-YMail-OSG: NmPRFn4VM1m2A7UPXe3oWrzQ86JQg5w.dL4_w3tQFvL3uERrVpM2miev0qiD6cW3w8pTM3H_S0Lr4OZg1PmXupRZKcVdOxFaS5xabvevu.g.FAULbHhA3r1rRPvvrk2MYh4AJRORe19pnGgub3YYLYI.Ekf1gRNCidlVOGG3oTx3JCh19PXMbgB6ScdXzNJ2vBOkM52UPi6veMpPjxu7NmUS4iIr9GpyexyFRbjqo1o7mpPkkJUoPBe0VZuoMFkwR3Sk4oM.NQoT4SnH0sWpZopUoPCcHz5eN8rGpL5s1GwFVruRwqNH3bCN5oDFomN2GEZ0cvMEfud9SNG7HJnZI8cL X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6B2BEA.9010002@netconfcentral.com> Date: Sat, 25 Jul 2009 08:59:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> In-Reply-To: <20090723.215005.222579354.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sat, 25 Jul 2009 15:59:09 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> RFC 4741 says: >>> Delete a configuration datastore. >> This makes little sense. What does it mean to delete ? > > According to 4741, running cannot be deleted. > good! I find the and operations to be the absolute worst part of NETCONF. It is obvious from studying the protocol that there was no clear or shared understanding of the database architecture. Now with partial-locking, it is even worse. * every agent MUST have a database * every agent MUST have exactly 1 database that can be the target of an operation. (Writing to both and does not work!) * therefore the agent MUST support the :candidate OR :writable-running capabilities, but not both) * the :candidate and :startup capabilities are independent, not mutually exclusive. (Is there any agreement on these points?) I changed my mind on 'minimal operations'. I think and on the "NV version" are too useful for operators to leave as optional. So the table in 4741bis, 8.7.5.1 is OK I do not like all the combinations for that occur when :candidate and :startup are both supported. Or for that matter, just :candidate. 8.3.5.1. , , , and The candidate configuration can be used as a source or target of any , , , or operation as a or parameter. The element is used to indicate the candidate configuration: This first sentence is clearly wrong. You cannot copy from candidate to running. You can only use for that. (Not sure about copy from candidate to startup.) You should not be able to copy from running to candidate either. We have for that. I wish we had time to work on the NETCONF database architecture, because it isn't very good. > > /martin > Andy From phil@juniper.net Sat Jul 25 09:29:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFF53A694E for ; Sat, 25 Jul 2009 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Rt0ZialFol-J for ; Sat, 25 Jul 2009 09:29:18 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 2DF4F3A6821 for ; Sat, 25 Jul 2009 09:29:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSmsy2y4MYETVQOV+6ZRQ8IPHb6A3cWUt@postini.com; Sat, 25 Jul 2009 09:29:19 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.375.2; Sat, 25 Jul 2009 09:26:57 -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); Sat, 25 Jul 2009 09:26:57 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 09:26:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 09:26:55 -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 n6PGQtd61421; Sat, 25 Jul 2009 09:26:55 -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 n6PGFUCF003787; Sat, 25 Jul 2009 16:15:30 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907251615.n6PGFUCF003787@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6B2BEA.9010002@netconfcentral.com> Date: Sat, 25 Jul 2009 12:15:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2009 16:26:55.0845 (UTC) FILETIME=[B9BAE150:01CA0D44] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sat, 25 Jul 2009 16:29:19 -0000 Andy Bierman writes: > * every agent MUST have a database > * every agent MUST have exactly 1 database that can > be the target of an operation. > (Writing to both and does not work!) > * therefore the agent MUST support the :candidate OR > :writable-running capabilities, but not both) I think Martin's code suport this (both). >8.3.5.1. , , , and > > The candidate configuration can be used as a source or target of any > , , , or operation > as a or parameter. The element is used > to indicate the candidate configuration: > >This first sentence is clearly wrong. >You cannot copy from candidate to running. >You can only use for that. >(Not sure about copy from candidate to startup.) >You should not be able to copy from running to candidate either. >We have for that. Are you really wanting CLRs for these? I guess it's not "L" either, since you'd need a matrix. Thanks, Phil From phil@juniper.net Sat Jul 25 09:41:10 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 4FE633A6967 for ; Sat, 25 Jul 2009 09:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 jCc2hLnQgOt5 for ; Sat, 25 Jul 2009 09:41:09 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 6040B3A686D for ; Sat, 25 Jul 2009 09:41:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSms1pIJ0LnOsu0xcNcU3C6L2NQ27DZEM@postini.com; Sat, 25 Jul 2009 09:41:10 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.375.2; Sat, 25 Jul 2009 09:37:58 -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); Sat, 25 Jul 2009 09:37:59 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 09:37:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 09:37:58 -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 n6PGbvd64759; Sat, 25 Jul 2009 09:37:57 -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 n6PGQWeT003856; Sat, 25 Jul 2009 16:26:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907251626.n6PGQWeT003856@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A6B142C.4070104@netconfcentral.com> Date: Sat, 25 Jul 2009 12:26:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Jul 2009 16:37:58.0000 (UTC) FILETIME=[4467B700:01CA0D46] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] is non-destructive on as well as ? 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, 25 Jul 2009 16:41:10 -0000 Andy Bierman writes: >where does it say this in the draft? >I don't think it does. No, but it doesn't say that commit changes startup. Or that discard-changes can format your disk. It just says what the operation does. >not in the . Sure you can: A NETCONF server that replies to a or request MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist. Thus, a client that receives an for a or request, must be prepared to handle the case that a container node without a presence statement is not present in the XML. >That's why I wait until the to delete empty NP containers. This is an implementation detail. Thanks, Phil From andy@netconfcentral.com Sat Jul 25 10:02:52 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE66A3A6928 for ; Sat, 25 Jul 2009 10:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_29=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 taUDLZepd4+E for ; Sat, 25 Jul 2009 10:02:52 -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 CFCD33A68F6 for ; Sat, 25 Jul 2009 10:02:51 -0700 (PDT) Received: from [68.142.200.225] by n25.bullet.mail.mud.yahoo.com with NNFMP; 25 Jul 2009 17:02:49 -0000 Received: from [68.142.201.73] by t6.bullet.mud.yahoo.com with NNFMP; 25 Jul 2009 17:02:49 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 25 Jul 2009 17:02:49 -0000 X-Yahoo-Newman-Id: 403673.91219.bm@omp425.mail.mud.yahoo.com Received: (qmail 91856 invoked from network); 25 Jul 2009 17:02:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 25 Jul 2009 17:02:48 -0000 X-YMail-OSG: Go4RzXUVM1ma2Hyo8XGXfpByTa39sdnyD1.VTznL05TgTnrjrEFgp3XKphJHFB3CRM7jDBFxWI_pM7FpWQuZoqJj6bzzxKPMo7rTXT.5YFP0eZbV4Heh0stjADZmXu8V6OA257rnykuw6wLpy4NqjAbZ7w6Am0y3CRxIBHRQID9x5LwXUe62.9pZirHeHsPe9PHhC4e69Z4Qc9vgsHpbxSCl8jarKpmuxAmajscC4RKrSOyv8puCWcLmFzTfyeE8EDhZYh48opJ4t54dkvotyXr1gzRAZsJxAztsbV81nw.9xipGFjM9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6B3A64.6050703@netconfcentral.com> Date: Sat, 25 Jul 2009 10:01:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907251615.n6PGFUCF003787@idle.juniper.net> In-Reply-To: <200907251615.n6PGFUCF003787@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sat, 25 Jul 2009 17:02:52 -0000 Phil Shafer wrote: > Andy Bierman writes: >> * every agent MUST have a database >> * every agent MUST have exactly 1 database that can >> be the target of an operation. >> (Writing to both and does not work!) >> * therefore the agent MUST support the :candidate OR >> :writable-running capabilities, but not both) > > I think Martin's code suport this (both). > >> 8.3.5.1. , , , and >> >> The candidate configuration can be used as a source or target of any >> , , , or operation >> as a or parameter. The element is used >> to indicate the candidate configuration: >> >> This first sentence is clearly wrong. >> You cannot copy from candidate to running. >> You can only use for that. >> (Not sure about copy from candidate to startup.) >> You should not be able to copy from running to candidate either. >> We have for that. > > Are you really wanting CLRs for these? I guess it's not "L" either, > since you'd need a matrix. > You need a matrix and a week to figure it all out. I actually want there to be just one simple way to do what needs to be done on every agent. I want the standard to clearly specify what every agent MUST, SHOULD, or MAY do, for each of the 'one simple ways' of doing each task. It is not clear if an agent will do the exact same thing every time for each of these duplicate operations. It only confuses people who might be trying to learn NETCONF: e.g., * when should I use and when should I use ? * I thought was used to reset the candidate? * There is no test that says how interacts with locking and :confirmed-commit, so how does that work? * Can I inline config right into the or ? Really? Then when do I use What is the difference? * What about this nc:operation thing? What if they are present in a operation? Does they get ignored or cause an error or what? What you see as 'convenient', I see an reduced interoperability and higher cost of training and adoption. > Thanks, > Phil > Andy From mbj@tail-f.com Sat Jul 25 12:54: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 1DEFB28C0FC for ; Sat, 25 Jul 2009 12:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_29=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 rNQDzNnwvzDk for ; Sat, 25 Jul 2009 12:54: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 EF8A03A69A2 for ; Sat, 25 Jul 2009 12:53:34 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B95576C4E4; Sat, 25 Jul 2009 21:53:34 +0200 (CEST) Date: Sat, 25 Jul 2009 21:53:34 +0200 (CEST) Message-Id: <20090725.215334.191378476.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6B3A64.6050703@netconfcentral.com> References: <200907251615.n6PGFUCF003787@idle.juniper.net> <4A6B3A64.6050703@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] Comments :draft-ietf-netconf-4741bis-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: Sat, 25 Jul 2009 19:54:04 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> * every agent MUST have a database > >> * every agent MUST have exactly 1 database that can > >> be the target of an operation. > >> (Writing to both and does not work!) > >> * therefore the agent MUST support the :candidate OR > >> :writable-running capabilities, but not both) > > > > I think Martin's code suport this (both). Yes it does. I agree that other combinations are more useful, but also this combination works. > >> 8.3.5.1. , , , and > >> > >> The candidate configuration can be used as a source or target of any > >> , , , or operation > >> as a or parameter. The element is used > >> to indicate the candidate configuration: > >> > >> This first sentence is clearly wrong. > >> You cannot copy from candidate to running. > >> You can only use for that. If you can copy from candidate to url X, and from url X to running, why not copy from candidate to running directly? (and IMO it means just that). It only works if you have a candidate AND :writable-running of course. > >> (Not sure about copy from candidate to startup.) Same reasoning as above, but it depends how primitive we want the startup to (minimally) be. > >> You should not be able to copy from running to candidate either. > >> We have for that. In my code I have a special case for copy from running to candidate - it invokes the internal discard_changes() function. It is a bit unclear why we have two ways of doing this, but if we just wanted one way, I'd remove discard-changes. > * There is no test that says how interacts with > locking and :confirmed-commit, so how does that work? The text says that when a lock is set, other sessions cannot modify the locked db. So if another session tries to copy-config, it will fail. Do we need more text? If you're doing a confirmed commit w/o a lock, and the box supports :writable-running, well, then you really should have taken a lock ;) copy-config works just like edit-config in this case. > * Can I inline config right into the > or ? Really? Then when do I use Sure. > What is the difference? copy-config replaces the *entire* datastore. edit-config can replace only the pieces you have in the PDU. So use copy-config to save / restore backups. > * What about this nc:operation thing? > What if they are present in a operation? > Does they get ignored or cause an error or what? They will be treated as any other unknown attribute present in the data. I.e. generate an error. Do we have to specify that unknown elements and unknown attributes in the data are errors? If so, does it belong in yang or 4741bis? /martin From mbj@tail-f.com Sat Jul 25 13:05:27 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 EEA113A69C2 for ; Sat, 25 Jul 2009 13:05:27 -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.120, 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 QORLpAA-lzYH for ; Sat, 25 Jul 2009 13:05:27 -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 2C9E43A68B3 for ; Sat, 25 Jul 2009 13:05:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CDA3276C4E4; Sat, 25 Jul 2009 22:05:27 +0200 (CEST) Date: Sat, 25 Jul 2009 22:05:27 +0200 (CEST) Message-Id: <20090725.220527.56004651.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6B2BEA.9010002@netconfcentral.com> References: <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@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] Comments :draft-ietf-netconf-4741bis-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: Sat, 25 Jul 2009 20:05:28 -0000 Andy Bierman wrote: > I changed my mind on 'minimal operations'. > I think and on the "NV version" > are too useful for operators to leave as optional. > So the table in 4741bis, 8.7.5.1 is OK What about filtering on the startup, do you think that should be optional or not? /martin From andy@netconfcentral.com Sat Jul 25 15:56:15 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EFF3A69DD for ; Sat, 25 Jul 2009 15:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_29=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 XwwwFnLz96BE for ; Sat, 25 Jul 2009 15:56:14 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 8514C3A696C for ; Sat, 25 Jul 2009 15:56:14 -0700 (PDT) Received: (qmail 8383 invoked from network); 25 Jul 2009 22:56:12 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2009 22:56:12 -0000 X-YMail-OSG: zUyyJHcVM1mZzI4dvXsFimk1ICUPxma7mxkUF_JVyBBNX6e2sd9hPx.FKIMLYlkktrCB7lvwQ2bFapcLwgEQM38H4P3jeRfELu9XivAZyZvcRKrl5IBOfTFo2JRNTZO_gc7MIVxKCBCHPOaR9OFZ.cjDjG5WuDvg04E0JZ1QMdlZG71cRHJk9BkCdB.x__4O0wUCDcBi38d07deq6_RvxsFP6XgsbT0DG5SiMSsZ9SZ0JNVuF28Ay3Yk8fbloNAW3PTYLSjWz9mkx8R.wIuv4ijM1svRzEMgKNOHkNjFgk1KovtFrx8oPP4sF0MOcOZQHCIb0hs5.eSYrw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6B8DB2.4050605@netconfcentral.com> Date: Sat, 25 Jul 2009 15:56:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <200907251615.n6PGFUCF003787@idle.juniper.net> <4A6B3A64.6050703@netconfcentral.com> <20090725.215334.191378476.mbj@tail-f.com> In-Reply-To: <20090725.215334.191378476.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sat, 25 Jul 2009 22:56:15 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> * every agent MUST have a database >>>> * every agent MUST have exactly 1 database that can >>>> be the target of an operation. >>>> (Writing to both and does not work!) >>>> * therefore the agent MUST support the :candidate OR >>>> :writable-running capabilities, but not both) >>> I think Martin's code suport this (both). > > Yes it does. I agree that other combinations are more useful, but > also this combination works. > I think the standard is poorly specified in this entire area. So let's say User A locks the candidate and starts adding edits. Then user B adds a new leaf direct to running. How do you update the leaf in the candidate without violating the lock? And if candidate is not updated in this case, then aren't you 'lying' to user A when you say a on the candidate is OK? Andy >>>> 8.3.5.1. , , , and >>>> >>>> The candidate configuration can be used as a source or target of any >>>> , , , or operation >>>> as a or parameter. The element is used >>>> to indicate the candidate configuration: >>>> >>>> This first sentence is clearly wrong. >>>> You cannot copy from candidate to running. >>>> You can only use for that. > > If you can copy from candidate to url X, and from url X to running, > why not copy from candidate to running directly? (and IMO it means > just that). It only works if you have a candidate AND > :writable-running of course. > >>>> (Not sure about copy from candidate to startup.) > > Same reasoning as above, but it depends how primitive we want the > startup to (minimally) be. > >>>> You should not be able to copy from running to candidate either. >>>> We have for that. > > In my code I have a special case for copy from running to candidate - > it invokes the internal discard_changes() function. It is a bit > unclear why we have two ways of doing this, but if we just wanted one > way, I'd remove discard-changes. > >> * There is no test that says how interacts with >> locking and :confirmed-commit, so how does that work? > > The text says that when a lock is set, other sessions cannot modify > the locked db. So if another session tries to copy-config, it will > fail. Do we need more text? > > If you're doing a confirmed commit w/o a lock, and the box supports > :writable-running, well, then you really should have taken a lock ;) > copy-config works just like edit-config in this case. > >> * Can I inline config right into the >> or ? Really? Then when do I use > > Sure. > >> What is the difference? > > copy-config replaces the *entire* datastore. edit-config can replace > only the pieces you have in the PDU. So use copy-config to save / > restore backups. > >> * What about this nc:operation thing? >> What if they are present in a operation? >> Does they get ignored or cause an error or what? > > They will be treated as any other unknown attribute present in the > data. I.e. generate an error. Do we have to specify that unknown > elements and unknown attributes in the data are errors? If so, does > it belong in yang or 4741bis? > > > /martin > From andy@netconfcentral.com Sat Jul 25 17:17: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 0053F3A68B0 for ; Sat, 25 Jul 2009 17:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.028, 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 bjvbbn5wq6+J for ; Sat, 25 Jul 2009 17:17:27 -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 50D0C3A6774 for ; Sat, 25 Jul 2009 17:17:27 -0700 (PDT) Received: (qmail 59907 invoked from network); 26 Jul 2009 00:17:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 26 Jul 2009 00:17:24 -0000 X-YMail-OSG: fqcu55wVM1n1DRXK0ytGfVMsQLKPUcuqPL56T0305Au6MN1I4zK1wMBwHo6zYgikg1UrqOAr5lHON._6DuB2sKNTt6n1fdkRfjCXAgZsa4xsu4_C71L0RBFzuJtVooyYQJGKXU240SpLNf6ZxFK7Q9mImaN.qFmfDid8Hm3ogAtpvzoKsE9UchdISgMKZooKaEPhUO8J1cx2plBbM4OkTY8.4z1XJ8RNdIvjoudHkwBn8r4n8NafSZRy2i0bU6i10xo90Ld1ePQ8iUX1 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6BA0BB.5000804@netconfcentral.com> Date: Sat, 25 Jul 2009 17:18:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <200907251615.n6PGFUCF003787@idle.juniper.net> <4A6B3A64.6050703@netconfcentral.com> <20090725.215334.191378476.mbj@tail-f.com> In-Reply-To: <20090725.215334.191378476.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sun, 26 Jul 2009 00:17:28 -0000 Martin Bjorklund wrote: ... >>>> You should not be able to copy from running to candidate either. >>>> We have for that. > > In my code I have a special case for copy from running to candidate - > it invokes the internal discard_changes() function. It is a bit > unclear why we have two ways of doing this, but if we just wanted one > way, I'd remove discard-changes. > At the time 4741 was written, the proponents of the candidate config insisted we needed separate commands like and because they were so different from the running config. "A commit can fail, but a copy-config cannot", was the logic I think. If the database architecture was clear, there would not be so many interpretations of it that contradict this much. We should deprecate and , and just use and for all databases. Andy From andy@netconfcentral.com Sat Jul 25 17:25: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 6492F3A6908 for ; Sat, 25 Jul 2009 17:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 UHJUQBsAIhLv for ; Sat, 25 Jul 2009 17:25:24 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 9FB8E3A6774 for ; Sat, 25 Jul 2009 17:25:24 -0700 (PDT) Received: from [68.142.200.225] by n18.bullet.mail.mud.yahoo.com with NNFMP; 26 Jul 2009 00:25:23 -0000 Received: from [68.142.201.64] by t6.bullet.mud.yahoo.com with NNFMP; 26 Jul 2009 00:25:23 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 26 Jul 2009 00:25:23 -0000 X-Yahoo-Newman-Id: 958874.81737.bm@omp416.mail.mud.yahoo.com Received: (qmail 84992 invoked from network); 26 Jul 2009 00:25:23 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 26 Jul 2009 00:25:23 -0000 X-YMail-OSG: 2KH8ug0VM1kxvWkIzhHKTmrcZ.ILVf_AvPwk4209qsLOEJnThIPnC7E3KbTd5DMmckf9RGEWy9qcO4OlwX7imZ_TmX0wZsmzNUbnWeUeGUjbMo3NOg_5dmXJrPca.92VPymz9j4GiWFLAcpeIXUsqh.6M_wWrAX1zB_A1yYWwHLjAz0IB6pmA3ZlX7NG.rnlbkyky1quA2dRM98VgNOQ6WfL2YfpkLRHKeZiy_JOpkVu2f0kzlSUGokyV4HmpAm8DZnEBqEB.pZu2MRfmx.4ymbEeGyKq5FPqfaaaqtbLrm38yvx.cRqAIuRZaFnXAxQUAfWO9nhwopjoGy.Qod9QPe8PDdr5E.fBEAIIgnPDQpWSGEX_w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6BA220.9010703@netconfcentral.com> Date: Sat, 25 Jul 2009 17:24:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@netconfcentral.com> <20090725.220527.56004651.mbj@tail-f.com> In-Reply-To: <20090725.220527.56004651.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sun, 26 Jul 2009 00:25:25 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> I changed my mind on 'minimal operations'. >> I think and on the "NV version" >> are too useful for operators to leave as optional. >> So the table in 4741bis, 8.7.5.1 is OK > > What about filtering on the startup, do you think that should be > optional or not? > > no -- full filtering must be supported. this protocol already has more optional bells, whistles and flags than a battleship. > /martin > Andy From andy@netconfcentral.com Sat Jul 25 18:40: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 EC1063A6900 for ; Sat, 25 Jul 2009 18:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 jpAaP-qpuxb4 for ; Sat, 25 Jul 2009 18:40:48 -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 E66273A6858 for ; Sat, 25 Jul 2009 18:40:47 -0700 (PDT) Received: from [68.142.200.226] by n25.bullet.mail.mud.yahoo.com with NNFMP; 26 Jul 2009 01:40:46 -0000 Received: from [68.142.201.73] by t7.bullet.mud.yahoo.com with NNFMP; 26 Jul 2009 01:40:46 -0000 Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 26 Jul 2009 01:40:46 -0000 X-Yahoo-Newman-Id: 894072.46275.bm@omp425.mail.mud.yahoo.com Received: (qmail 78481 invoked from network); 26 Jul 2009 01:40:46 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 26 Jul 2009 01:40:45 -0000 X-YMail-OSG: O1NPntwVM1lyeX4jQzDDbneSpxa6sV1X5FUO4CL3Dw8ZwVCurVVHh6bE4q00v_1rDZRd3DRDtoDLi0mJnsGMqJC24dV_w9LGaj3QdGDLvfgjFFMFuKlOgBNXZd5gt5RfRuyEJQf1cJJKFQ1UcTw4ADRp7iA5Ff8EQQkpi.5EU5pyfryGW8uPpv8qNtN7VTgEUMIH6qk460s5ChNcxyZT4oiB.r8K.UIQOdC9IOyrk.0zNa95_j5HGJG4UTfzRUwzdNtOnYra.IK5GYXa1MWqVyMa4G60w8BKmMrG7u.OdGceSa8TkrPr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6BB445.6030301@netconfcentral.com> Date: Sat, 25 Jul 2009 18:41:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <200907251615.n6PGFUCF003787@idle.juniper.net> <4A6B3A64.6050703@netconfcentral.com> <20090725.215334.191378476.mbj@tail-f.com> <4A6BA0BB.5000804@netconfcentral.com> In-Reply-To: <4A6BA0BB.5000804@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sun, 26 Jul 2009 01:40:49 -0000 .... > We should deprecate and , > and just use and for all databases. > but then again, allows the leaf to be used, so the matrix is 3d, not 2d (source, target, with-defaults). > > Andy Andy From mbj@tail-f.com Sun Jul 26 03:15: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 B968D3A6833 for ; Sun, 26 Jul 2009 03:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdrvs7DO20ha for ; Sun, 26 Jul 2009 03:15:38 -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 DE9403A62C1 for ; Sun, 26 Jul 2009 03:15:37 -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 B3BB7616006; Sun, 26 Jul 2009 12:15:37 +0200 (CEST) Date: Sun, 26 Jul 2009 12:15:37 +0200 (CEST) Message-Id: <20090726.121537.253190084.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6BA0BB.5000804@netconfcentral.com> References: <4A6B3A64.6050703@netconfcentral.com> <20090725.215334.191378476.mbj@tail-f.com> <4A6BA0BB.5000804@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] Comments :draft-ietf-netconf-4741bis-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: Sun, 26 Jul 2009 10:15:38 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > ... > >>>> You should not be able to copy from running to candidate either. > >>>> We have for that. > > > > In my code I have a special case for copy from running to candidate - > > it invokes the internal discard_changes() function. It is a bit > > unclear why we have two ways of doing this, but if we just wanted one > > way, I'd remove discard-changes. > > > > At the time 4741 was written, the proponents of the candidate config > insisted we needed separate commands like > and because they were so different from > the running config. "A commit can fail, but a copy-config cannot", > was the logic I think. > > If the database architecture was clear, > there would not be so many interpretations > of it that contradict this much. > > We should deprecate and , > and just use and for all databases. has more parameters than , so I think it must be kept. Also, you cannot copy-config to running unless :writable-running is advertised, so is needed. /martin From bertietf@bwijnen.net Sun Jul 26 06:00: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 349B93A6BD0 for ; Sun, 26 Jul 2009 06:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=4.565, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 UQzKdYTuiVQ5 for ; Sun, 26 Jul 2009 06:00:41 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 63BA33A69D6 for ; Sun, 26 Jul 2009 06:00:41 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MV3L9-0003DL-QR; Sun, 26 Jul 2009 15:00:40 +0200 Received: from host-78-64-88-210.homerun.telia.com (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id A4A3A2F583; Sun, 26 Jul 2009 15:00:35 +0200 (CEST) Message-ID: <4A6C5373.9040501@bwijnen.net> Date: Sun, 26 Jul 2009 15:00:35 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andy Bierman References: <20090722.235941.67264633.mbj@tail-f.com> <200907230433.n6N4XJ6G064490@idle.juniper.net> <20090723.215005.222579354.mbj@tail-f.com> <4A6B2BEA.9010002@netconfcentral.com> In-Reply-To: <4A6B2BEA.9010002@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48a6b05c51fdab3c1fa85d763b5935595 Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sun, 26 Jul 2009 13:00:42 -0000 Andy wrote: > I wish we had time to work on the NETCONF database architecture, > because it isn't very good. > > Andy > I wonder if others (many) feel the same? Because if we do believe that the db architecture is not good enough, then we better think about a possible better architecture now.... before we start adding all sorts of new/other things. apeaking as a contributer Bert From andy@netconfcentral.com Sun Jul 26 08:22: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 A1C4E3A69DD for ; Sun, 26 Jul 2009 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 DUa1QFO6Y54Q for ; Sun, 26 Jul 2009 08:22:35 -0700 (PDT) Received: from n11b.bullet.mail.mud.yahoo.com (n11b.bullet.mail.mud.yahoo.com [209.191.125.178]) by core3.amsl.com (Postfix) with SMTP id DED123A69AB for ; Sun, 26 Jul 2009 08:22:34 -0700 (PDT) Received: from [68.142.194.244] by n11.bullet.mail.mud.yahoo.com with NNFMP; 26 Jul 2009 15:22:34 -0000 Received: from [68.142.201.248] by t2.bullet.mud.yahoo.com with NNFMP; 26 Jul 2009 15:22:34 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 26 Jul 2009 15:22:34 -0000 X-Yahoo-Newman-Id: 317432.86823.bm@omp409.mail.mud.yahoo.com Received: (qmail 27646 invoked from network); 26 Jul 2009 15:22:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.157.255 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 26 Jul 2009 15:22:33 -0000 X-YMail-OSG: YW9hdNAVM1nCojXx7.kqxomDEzJ6tFuos8CJOhfqbZBrX3qevT1UoDv0RIt28UCDt.c8H_nU9zg792TKLtNGpeynYRGgusYz8mFYD0sjeGQbaIP7PZHowBQ9xEgGM1C3tXjDAHNZVXQkOaxU9BV4G3nP8lGOwG21HFdorUI1Ei.mJrPa9IrduAGDYfTkPu5ZRHfLcHxTSfADVTHn1tQxcAEd.Cc4Qw08K5dJYGvpNQ2B5fic3kvWMHxe9ByftyWV2jWrV6n3BDr84wbTw9.QwFZGWUSPZlvWbQOIqVr2oBq2qZ7NOP.nCtNwB3aWjW5aty1jJ2h9QwYN_iDP75tq4WHeY7kXMK2PcIzGc68V816JpBabgQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6C746D.4090508@netconfcentral.com> Date: Sun, 26 Jul 2009 08:21:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A6B3A64.6050703@netconfcentral.com> <20090725.215334.191378476.mbj@tail-f.com> <4A6BA0BB.5000804@netconfcentral.com> <20090726.121537.253190084.mbj@tail-f.com> In-Reply-To: <20090726.121537.253190084.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-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: Sun, 26 Jul 2009 15:22:35 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >> ... >>>>>> You should not be able to copy from running to candidate either. >>>>>> We have for that. >>> In my code I have a special case for copy from running to candidate - >>> it invokes the internal discard_changes() function. It is a bit >>> unclear why we have two ways of doing this, but if we just wanted one >>> way, I'd remove discard-changes. >>> >> At the time 4741 was written, the proponents of the candidate config >> insisted we needed separate commands like >> and because they were so different from >> the running config. "A commit can fail, but a copy-config cannot", >> was the logic I think. >> >> If the database architecture was clear, >> there would not be so many interpretations >> of it that contradict this much. >> >> We should deprecate and , >> and just use and for all databases. > > has more parameters than , so I think it must > be kept. Also, you cannot copy-config to running unless > :writable-running is advertised, so is needed. > So is a copy-config from candidate to running the same as a commit? What if user A starts a confirmed commit, then issues a copy-config as the 2nd commit? What happens? When is copy-config from candidate to running supposed to be used? If copy-config from running to candidate is used instead of discard-changes, then what happens if is set to 'explicit'? How is the candidate config supposed to function without any agent-created nodes in it? What does it even mean to trim the defaults from the candidate? Unintended consequences are just sloppy design. If these are intended, then it's just poor design. > > /martin > Andy From mbj@tail-f.com Sun Jul 26 08:31:18 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935733A68E5 for ; Sun, 26 Jul 2009 08:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yZqsGl5koDD for ; Sun, 26 Jul 2009 08:31: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 8702C3A6843 for ; Sun, 26 Jul 2009 08:31:17 -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 9D992616006; Sun, 26 Jul 2009 17:31:17 +0200 (CEST) Date: Sun, 26 Jul 2009 17:31:17 +0200 (CEST) Message-Id: <20090726.173117.249989305.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6C746D.4090508@netconfcentral.com> References: <4A6BA0BB.5000804@netconfcentral.com> <20090726.121537.253190084.mbj@tail-f.com> <4A6C746D.4090508@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] Comments :draft-ietf-netconf-4741bis-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: Sun, 26 Jul 2009 15:31:18 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >> ... > >>>>>> You should not be able to copy from running to candidate either. > >>>>>> We have for that. > >>> In my code I have a special case for copy from running to candidate - > >>> it invokes the internal discard_changes() function. It is a bit > >>> unclear why we have two ways of doing this, but if we just wanted one > >>> way, I'd remove discard-changes. > >>> > >> At the time 4741 was written, the proponents of the candidate config > >> insisted we needed separate commands like > >> and because they were so different from > >> the running config. "A commit can fail, but a copy-config cannot", > >> was the logic I think. > >> > >> If the database architecture was clear, > >> there would not be so many interpretations > >> of it that contradict this much. > >> > >> We should deprecate and , > >> and just use and for all databases. > > > > has more parameters than , so I think it must > > be kept. Also, you cannot copy-config to running unless > > :writable-running is advertised, so is needed. > > > > So is a copy-config from candidate to running > the same as a commit? No. > What if user A starts > a confirmed commit, then issues a copy-config > as the 2nd commit? What happens? Same as if A copies from candidate to X, and from X to running. > When is copy-config > from candidate to running supposed to be used? I cannot see a use case. > If copy-config from running to candidate is used instead > of discard-changes, then what happens if > is set to 'explicit'? How is the candidate config > supposed to function without any agent-created nodes in it? > What does it even mean to trim the defaults from the candidate? I think with-defaults for copy-config makes sense only when the target is an URL. And it makes sense only if the source is a data store! > Unintended consequences are just sloppy design. > If these are intended, then it's just poor design. Shouldn't this be specified in the with-defaults draft? /martin From andy@netconfcentral.com Tue Jul 28 16:47: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 111F73A6D4B for ; Tue, 28 Jul 2009 16:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 Nlou+hVtkU7p for ; Tue, 28 Jul 2009 16:47:41 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 2B8BC3A6D3B for ; Tue, 28 Jul 2009 16:47:41 -0700 (PDT) Received: from [68.142.200.226] by n18.bullet.mail.mud.yahoo.com with NNFMP; 28 Jul 2009 23:47:40 -0000 Received: from [68.142.201.249] by t7.bullet.mud.yahoo.com with NNFMP; 28 Jul 2009 23:47:40 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 28 Jul 2009 23:47:40 -0000 X-Yahoo-Newman-Id: 833610.32300.bm@omp410.mail.mud.yahoo.com Received: (qmail 39803 invoked from network); 28 Jul 2009 23:47:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 28 Jul 2009 23:47:40 -0000 X-YMail-OSG: gKMG4UsVM1mobirPwabjWO16HuX_utLDnLq_WwxdJQdg.AxWl84FntUzvmuSUfQ7HvpVjPi5XQmFan4MQJh90mZw1vVkNJ4YqrZdPoxw9DwlMqyHcN7nt4aS6Ii5UgYUEzvzT5_gE8qWs_kGgZYT_RfbyfjWXtNYYSeMquJ1fzcTB96h20pDAkwqN7W0cXwJOH_zZPntGySV365npUqYe9pdLMDnjo2F7mqe4K7_Kc3NpIW2QKlpwDoobbICwf_8VzttbrQqPhX81Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6F8DE7.4010008@netconfcentral.com> Date: Tue, 28 Jul 2009 16:46:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] 4741bis: replace operation 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 Jul 2009 23:47:42 -0000 Hi, The differences between the replace and merge operations within are not 100% clear. 1) the example on pg 19 for /top/interface seems unrealistic. Is anybody using this way? If not, them the example should be updated so it is less confusing 2) error handling Does replace require the nodes-to-be-replaced to already exist, like 'delete'? (IMO, no) 7.2, para 3 is clear that only the nodes present in the inline or url are going to be affected in the target: 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. The 'replace' text does not say anything about requiring the node to exist in the target: replace: The configuration data identified by the element containing this attribute replaces any related configuration in the configuration datastore identified by the target parameter. Unlike a operation, which replaces the entire target configuration, only the configuration actually present in the config parameter is affected. The confusion comes from the description for the 'data-missing' error-tag on page 83: Description: Request could not be completed because the relevant data model content does not exist. For example, a 'replace' or 'delete' operation was attempted on data that does not exist. *** I think this text on pg. 83 is wrong. *** s/a 'replace' or 'delete'/a 'delete'/ The intent of replace is to zap the sub-trees that are not in the source, but are in the target: source: 1 this is OK, right? existing target: 7 11 resulting target: 1 this is OK, right? 3) default-operation='replace' replace: The configuration data in the parameter completely replaces the configuration in the target datastore. This is useful for loading previously saved configuration data. It is not clear what default-operation='replace' means. Does the default start at , so this will make edit-config (op=replace) just like copy-config? Or does it mean just zap nodes that are present in the source config, as usual? In the example above, will be present in the result if the default operation is set to 'replace'? thanks, Andy From mbj@tail-f.com Wed Jul 29 00:49:55 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7323A6B99 for ; Wed, 29 Jul 2009 00:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnATb6Y-UNCU for ; Wed, 29 Jul 2009 00:49:55 -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 DE1773A6452 for ; Wed, 29 Jul 2009 00:49:54 -0700 (PDT) Received: from localhost (dhcp-16eb.meeting.ietf.org [130.129.22.235]) by mail.tail-f.com (Postfix) with ESMTPSA id 19D2F76C4F1; Wed, 29 Jul 2009 09:49:55 +0200 (CEST) Date: Wed, 29 Jul 2009 09:49:54 +0200 (CEST) Message-Id: <20090729.094954.106834885.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A6F8DE7.4010008@netconfcentral.com> References: <4A6F8DE7.4010008@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: replace operation 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 Jul 2009 07:49:56 -0000 Andy Bierman wrote: > Hi, > > The differences between the replace and merge operations > within are not 100% clear. > > > 1) the example on pg 19 for /top/interface > seems unrealistic. Is anybody using > this way? If not, them the example should be updated > so it is less confusing I agree. > 2) error handling > Does replace require the nodes-to-be-replaced > to already exist, like 'delete'? (IMO, no) No it doesn't have to exist, and I agree that this should be clarified. > 7.2, para 3 is clear that only the nodes present in > the inline or url are going to be affected > in the target: > > 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. > > The 'replace' text does not say anything about requiring > the node to exist in the target: > > replace: The configuration data identified by the element > containing this attribute replaces any related configuration > in the configuration datastore identified by the target > parameter. Unlike a operation, which replaces > the entire target configuration, only the configuration > actually present in the config parameter is affected. > > The confusion comes from the description for the 'data-missing' error-tag > on page 83: > > Description: Request could not be completed because the relevant > data model content does not exist. For example, > a 'replace' or 'delete' operation was attempted on > data that does not exist. > > *** I think this text on pg. 83 is wrong. *** > > s/a 'replace' or 'delete'/a 'delete'/ I agree. > 3) default-operation='replace' > > replace: The configuration data in the parameter > completely replaces the configuration in the target > datastore. This is useful for loading previously saved > configuration data. > > It is not clear what default-operation='replace' means. > Does the default start at , so this will make > edit-config (op=replace) just like copy-config? No. > Or does it mean just zap nodes that are present in > the source config, as usual? Yes. The element is not part of the data, so you cannot have the "nc:operation" attribute on this element, and thus default-operation does not apply to the element itself. > In the example above, will be present in the result if > the default operation is set to 'replace'? Yes. /martin From phil@juniper.net Thu Jul 30 04:47:10 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 77B0F28C1A0 for ; Thu, 30 Jul 2009 04:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 nha6xUiAlXEy for ; Thu, 30 Jul 2009 04:47:09 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 99C0528C15B for ; Thu, 30 Jul 2009 04:47:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSnGIPq1TJogq7eJqSb4fu/BV8k64bB5r@postini.com; Thu, 30 Jul 2009 04:47:11 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.375.2; Thu, 30 Jul 2009 04:41:53 -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); Thu, 30 Jul 2009 04:41:53 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 04:41:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 04:41:53 -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 n6UBfqd90693 for ; Thu, 30 Jul 2009 04:41:52 -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 n6UBUM4L042849 for ; Thu, 30 Jul 2009 11:30:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907301130.n6UBUM4L042849@idle.juniper.net> To: NETCONF Date: Thu, 30 Jul 2009 07:30:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 11:41:53.0017 (UTC) FILETIME=[BBB72E90:01CA110A] MIME-Version: 1.0 Content-Type: text/plain Subject: [Netconf] Comments on draft-ietf-netconf-with-defaults-02 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 Jul 2009 11:47:10 -0000 Two comments, mentioned in the meeting Monday. (a) Please change the terms "agent" and "manager" to "client" and "server". "a/m" are SNMP terms. "c/s" are widely used and well known, and are the terms we've tried to use thru netconf and yang docs. (b) The example on page 7 does not include a namespace. belongs in the "urn:...:with-defaults" namespace. One other comment: It would be more readable if most of the contents of 2.1.1 were in the introduction. Describe the behaviors after covering the problem space/motivation. Thanks, Phil From phil@juniper.net Thu Jul 30 05:50: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 B4E1C3A6B8B for ; Thu, 30 Jul 2009 05:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.947 X-Spam-Level: X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 mF-cgHm1Ygov for ; Thu, 30 Jul 2009 05:50:03 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 74CFB3A6982 for ; Thu, 30 Jul 2009 05:50:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSnGW/R5a0hg+JwK/+BzJqDvQyoDhAxnI@postini.com; Thu, 30 Jul 2009 05:50:05 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.375.2; Thu, 30 Jul 2009 05:44:50 -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); Thu, 30 Jul 2009 05:43:54 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 05:43:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 05:43:53 -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 n6UChrd26737 for ; Thu, 30 Jul 2009 05:43:53 -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 n6UCWNC7043144 for ; Thu, 30 Jul 2009 12:32:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907301232.n6UCWNC7043144@idle.juniper.net> To: NETCONF Date: Thu, 30 Jul 2009 08:32:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 12:43:53.0540 (UTC) FILETIME=[6551F040:01CA1113] MIME-Version: 1.0 Content-Type: text/plain Subject: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Thu, 30 Jul 2009 12:50:04 -0000 Here are my comments on the monitoring draft: 1. Introduction s/content/data and operation definitions/ s/via XMLSchema// s/protocol. It provides/protocol and provide/ s/adjust their capabilities/adjust their understanding of the server's capabilities/ Do you want to say something about the operational model here? Should the client re-fetch the data every five minutes? On notifications? On failure? How will I know that I need to use this capability? 2. XML Schema to Monitor NETCONF s/XML Schema to Monitor NETCONF/Information Model/ Or is "Data Model"? Ask Juergen. The URI ends on ":state". If this is the "NETCONF Monitoring Schema", this should be ":monitor". It also should include a version number: urn:ietf:params:xml:ns:netconf:monitor:1.0 2.1 The /netconf-state Subtree There are two "big picture" questions here: (a) should ietf models be under a top-level "/ietf/" container? We should have some hierarchy in our hierarchical data models. If fact should this be under "/ietf/management/netconf"? (b) Why is there a "-state" suffix? Most of this isn't state data, per se (schemas are not state data). It seems like you need to separate this. But there is also some question about who we will organize data. There are many advocates of intermixing state data without the same tree as configuration data, so config=false nodes will intermix with config=true ones. I'm not convinced that this works well, but it's something we need to think about for this draft. So should the subtree in 2.1 be under "/ietf/management/netconf/monitor"? 2.1.1. The /netconf-state/capabilities Subtree Change: The /netconf-state/capabilibiles subtree contains the capabilities supported by the NETCONF server. The list MUST include all capabilities exchanged during session setup still applicable at the time of the request. This ensures consistency with the initial capabilities exchanged while allowing for potential modifications during a session. to: The /netconf-state/capabilibiles subtree contains the capabilities supported by the NETCONF server. The list MUST include all capabilities applicable at the time of the request, and MUST be identical to the list provided in the message if a new session were opened at the time of the request. Or something like that. The key is that these aren't related to start of this session as much as related to what a new session would get. 2.1.2. The /netconf-state/datastores Subtree - |_name + |_name (key) Add reference for partial-lock. You have "the original intended scope of the lock". This is a confusing term. I know there are subtleties and it's a rat hole, but you should have some words about why "intended" is there. You mix camel and low-with-dashes style. I thought I recalled (from Dublin) that we talked about moving away from camel. This would be a-good-thing. 2.1.3. The /netconf-state/schemas Subtree Why isn't "namespace" the key, instead of identifier? YANG module names are not unique (only SHOULD be), so they are not suitable for keys. More importantly, if I want to grab a schema for a chunk of data I don't grok, I'm _much_ more likely to have the namespace, not the YANG module name, especially since I don't have the YANG module. Shouldn't "version" be "revision"? This is the right name for YANG. What does "version" mean for XSD? The version has typically been part of the namespace. Are there other terms that need harmonized with YANG? The organization here is flat, not hierarchical. It should be: schema |_namespace (key) |_revision (key) |_identifier |_format |_ name (key) |_location |- value That is: list schema { key "namespace revision"; leaf namespace { ... } leaf revision { .... } list format { key name; leaf name { ... } leaf-list location { ... } } } You use upper case for netconf: "(xs:string value 'NETCONF')". We should stick with lower case. 2.1.4. The /netconf-state/sessions Subtree sessionId (type: SessionId) Unique NETCONF identifier for the session, used for all supported operations (e.g. monitoring, session kill, lock release) regardless of protocol. Does "protocol" mean "transport protocol" (the underlaying transport protocol for NETCONF) or "management protocol" (NETCONF, SNMP, etc)? So you want sentences that start with "MUST" ("MUST be a unique non-0 value")? Does "username" needs some qualification to support TAC+ worlds, where the login name and user name are not identical? What's the value of the rpc counts? Why are they worth the code? Can we use YANG features to break the most important parts of the netconf/monitor tree from these unimportant parts? 2.1.5. The /netconf-state/statistics Subtree "Statistical data pertaining to the NETCONF server" implies that there is only one server. Given that most of us will be using the openssh code and the sshd_conf subsystem hook, there's not one single server. In particular, start-time makes no sense. 3.1. The Operation s/When/If/ s/this new operation/the operation/ The namespace should be the key here. Also s/version/revision/ The 'data-missing' error code sounds misleading. If the client asks for something that we don't have, it's a problem with the client. We should return invalid-value or something like that. Thanks, Phil From andy@netconfcentral.com Thu Jul 30 08:38: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 7DB2428C2D3 for ; Thu, 30 Jul 2009 08:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 K0LiNz2razQv for ; Thu, 30 Jul 2009 08:38:22 -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 6633428C25F for ; Thu, 30 Jul 2009 08:38:22 -0700 (PDT) Received: (qmail 96031 invoked from network); 30 Jul 2009 15:38:21 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 15:38:20 -0000 X-YMail-OSG: EpPh4DgVM1lA.AxjG4l.6RBCSs1wML5nsiprV4MCn54ro8dNxENO7WmZAA77aP5ilN1k0V6Q3nGUuQYrw0DUhqgozDUaBIBnXXfmt0Y8UxOWzagZFxXpZ6NoNnnC9Cm2d13_zkV_ABJpjnbrdnzABYs.vYHU3LQCtO7x4eLg.ThKC.kvtzpnmBBi79AnBbd9vWU2o1UXyf_wxsnIED55TSg_xQmjF26hY_FR2DgtJgyWwckYHRd4r_HcQumncxQc6A6vqqqLDWvQSw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71BE72.2080704@netconfcentral.com> Date: Thu, 30 Jul 2009 08:38:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907301232.n6UCWNC7043144@idle.juniper.net> In-Reply-To: <200907301232.n6UCWNC7043144@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-06.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: Thu, 30 Jul 2009 15:38:23 -0000 Phil Shafer wrote: > Here are my comments on the monitoring draft: > > 1. Introduction > > s/content/data and operation definitions/ > > s/via XMLSchema// > > s/protocol. It provides/protocol and provide/ > > s/adjust their capabilities/adjust their understanding of > the server's capabilities/ > > Do you want to say something about the operational model here? Should > the client re-fetch the data every five minutes? On notifications? > On failure? How will I know that I need to use this capability? > > 2. XML Schema to Monitor NETCONF > > s/XML Schema to Monitor NETCONF/Information Model/ > > Or is "Data Model"? Ask Juergen. > > The URI ends on ":state". If this is the "NETCONF Monitoring Schema", > this should be ":monitor". It also should include a version number: > > urn:ietf:params:xml:ns:netconf:monitor:1.0 > > 2.1 The /netconf-state Subtree > > There are two "big picture" questions here: > > (a) should ietf models be under a top-level "/ietf/" container? > We should have some hierarchy in our hierarchical data models. > If fact should this be under "/ietf/management/netconf"? > > (b) Why is there a "-state" suffix? Most of this isn't state data, > per se (schemas are not state data). It seems like you need to > separate this. But there is also some question about who we will > organize data. There are many advocates of intermixing state data > without the same tree as configuration data, so config=false nodes > will intermix with config=true ones. I'm not convinced that this > works well, but it's something we need to think about for this draft. > > So should the subtree in 2.1 be under > "/ietf/management/netconf/monitor"? > I think these issues were already discussed and resolved. I do not wnt to move them, or to have all IETF standard modules under one container. > 2.1.1. The /netconf-state/capabilities Subtree > > Change: > > The /netconf-state/capabilibiles subtree contains the capabilities > supported by the NETCONF server. The list MUST include all > capabilities exchanged during session setup still applicable at the > time of the request. This ensures consistency with the initial > capabilities exchanged while allowing for potential modifications > during a session. > > to: > > The /netconf-state/capabilibiles subtree contains the capabilities > supported by the NETCONF server. The list MUST include all > capabilities applicable at the time of the request, and MUST be > identical to the list provided in the message if a new > session were opened at the time of the request. > > Or something like that. The key is that these aren't related to start > of this session as much as related to what a new session would get. > I disagree. It should be up to the agent to decide which capabilities to offer to a session. There is no rule in NETCONF that says every session MUST be given every available capability. > 2.1.2. The /netconf-state/datastores Subtree > > - |_name > + |_name (key) > > Add reference for partial-lock. > > You have "the original intended scope of the lock". This is a > confusing term. I know there are subtleties and it's a rat hole, but > you should have some words about why "intended" is there. > > You mix camel and low-with-dashes style. I thought I recalled (from > Dublin) that we talked about moving away from camel. This would be > a-good-thing. > > 2.1.3. The /netconf-state/schemas Subtree > > Why isn't "namespace" the key, instead of identifier? YANG module > names are not unique (only SHOULD be), so they are not suitable > for keys. More importantly, if I want to grab a schema for a chunk > of data I don't grok, I'm _much_ more likely to have the namespace, > not the YANG module name, especially since I don't have the YANG > module. > The module names are unique within a single agent. I think the indexing is fine. > Shouldn't "version" be "revision"? This is the right name for > YANG. What does "version" mean for XSD? The version has typically > been part of the namespace. > The data model is not YANG-only, so the terminology does not have to align with YANG. I would like this leaf to be optional. If the manager does not know or care which version it gets, then it should be able to leave this parameter out. Instead, an empty string has to be passed for this parameter to say "don't care which version". > Are there other terms that need harmonized with YANG? > > The organization here is flat, not hierarchical. It should be: > > schema > |_namespace (key) > |_revision (key) > |_identifier > |_format > |_ name (key) > |_location > |- value > > That is: > > list schema { > key "namespace revision"; > leaf namespace { ... } > leaf revision { .... } > list format { > key name; > leaf name { ... } > leaf-list location { ... } > } > } > I object to this change. The current indexing is fine and does not require nested lists. The current [identifier, version, format] tuple is better because it is simpler to understand and implement. > You use upper case for netconf: "(xs:string value 'NETCONF')". We > should stick with lower case. > > 2.1.4. The /netconf-state/sessions Subtree > > sessionId (type: SessionId) > Unique NETCONF identifier for the session, used for all > supported operations (e.g. monitoring, session kill, lock > release) regardless of protocol. > > Does "protocol" mean "transport protocol" (the underlaying transport > protocol for NETCONF) or "management protocol" (NETCONF, SNMP, etc)? > > So you want sentences that start with "MUST" ("MUST be a unique non-0 > value")? > > Does "username" needs some qualification to support TAC+ worlds, where > the login name and user name are not identical? > > What's the value of the rpc counts? Why are they worth the code? > > Can we use YANG features to break the most important parts of the > netconf/monitor tree from these unimportant parts? > I do not think there is enough cost with a few counters to justify making them optional. There should not be any optional objects in this module, other than the capability. > 2.1.5. The /netconf-state/statistics Subtree > > "Statistical data pertaining to the NETCONF server" implies that there > is only one server. Given that most of us will be using the openssh > code and the sshd_conf subsystem hook, there's not one single server. > > In particular, start-time makes no sense. > > 3.1. The Operation > > s/When/If/ > s/this new operation/the operation/ > > The namespace should be the key here. Also s/version/revision/ > I disagree. The current indexing is fine. Module names are easier to remember than namespace URIs. The manager can look up the module name and revision quite easily, since module capability URI strings end with "?module=foo&revision=2009-01-01". > The 'data-missing' error code sounds misleading. If the client asks > for something that we don't have, it's a problem with the client. We > should return invalid-value or something like that. > > Thanks, > Phil > ________________ Andy From andy@netconfcentral.com Thu Jul 30 09:43: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 6F4FF28C2A1 for ; Thu, 30 Jul 2009 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 NCJVYFxXL1OQ for ; Thu, 30 Jul 2009 09:43:05 -0700 (PDT) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id 8A0DE3A6BC1 for ; Thu, 30 Jul 2009 09:43:05 -0700 (PDT) Received: from [68.142.200.227] by n20.bullet.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 16:43:04 -0000 Received: from [68.142.201.240] by t8.bullet.mud.yahoo.com with NNFMP; 30 Jul 2009 16:43:04 -0000 Received: from [127.0.0.1] by omp401.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 16:43:04 -0000 X-Yahoo-Newman-Id: 334000.65860.bm@omp401.mail.mud.yahoo.com Received: (qmail 39018 invoked from network); 30 Jul 2009 16:43:03 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 16:43:03 -0000 X-YMail-OSG: 6Osxb3YVM1mDIER6wx8AZ1eJzUtyqAwm8qGrTZr2MUxW2Wb0erec.p9gVjDHNlFqjS5EGA8V9xCFPlNbHoA.NnCxbGPoOekVaFC99LgPBm7JxlR4sFJ9cmVw9x1szITdFyJPXnazDuwn3_pLG4r.P8iIkP7xhtHynKqqojoz55wrlvqXco9QnyygG8VNcEelLEd4iDampvHWuN1GbF39rY2arF_fmETgt8ZU.x.5.WfbJnvdv.T2hkzuRI76jXjlMSvBLkR2OcAtGg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71CD21.6040909@netconfcentral.com> Date: Thu, 30 Jul 2009 09:41:05 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] lock and commit operations 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 Jul 2009 16:43:06 -0000 Hi, A careful reading of 4741bis, sec. 7.5, para 4 reveals that the the "candidate" portion of the database architecture is seriously broken. The operation does not affect the operation at all. Martin already pointed this out. Even if I lock every database on the box, anybody can just login at anytime and issue , and ruin the 'database transaction' I am trying to complete. (Note the quotes, as to not offend any database experts out there who know NETCONF does not support real transactions.) If I am doing a confirmed-commit, anybody who logs in and invokes will confirm my commit, instead of letting me decide to keep or cancel the recent changes to running. Even though I have every database globally locked. Since does not work on the candidate database at all, there is no need to worry about how works with partial locking. I don't think a :confirmed-commit.1.1 capability can fix all these problems. Andy From andy@netconfcentral.com Thu Jul 30 10:07:37 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8443A6A17 for ; Thu, 30 Jul 2009 10:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 GM5kT+d5lk9Z for ; Thu, 30 Jul 2009 10:07:37 -0700 (PDT) Received: from n26.bullet.mail.mud.yahoo.com (n26.bullet.mail.mud.yahoo.com [68.142.206.221]) by core3.amsl.com (Postfix) with SMTP id 1DB533A67F5 for ; Thu, 30 Jul 2009 10:07:37 -0700 (PDT) Received: from [209.191.108.96] by n26.bullet.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 17:07:39 -0000 Received: from [68.142.201.242] by t3.bullet.mud.yahoo.com with NNFMP; 30 Jul 2009 17:07:39 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 17:07:39 -0000 X-Yahoo-Newman-Id: 76547.76954.bm@omp403.mail.mud.yahoo.com Received: (qmail 15987 invoked from network); 30 Jul 2009 17:07:38 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 17:07:38 -0000 X-YMail-OSG: LpB_bDgVM1m.stVP5gQKHdrf79C1NrupovyAu0HTdjqh5j4rloW_fiyMWXVWeuU3zBW2r41KD5AliEIpxHrlF5v67MjiKJNbNC8rR_WmwlxvwrZmejWqFFX2kwrRHtFqpiKvoUABUGjb4c99AZ5Fv5HJVY3fgBuU.3Sd0m1xfPIkX5aBPP.ZLv6qPH2Wdcn5uhT3p1U2bEL9JJ4DK0aTFvW1yndS5KGg7nPoQTwyR8dn3ykjj5ZNDpjKE2xk1YAH542yUUDu5QBdcvnWJ_N715vI4QnXcZOSf0lMoI6DHjTDqgJn X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71D2E9.4080004@netconfcentral.com> Date: Thu, 30 Jul 2009 10:05:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] with-defaults clarification 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 Jul 2009 17:07:37 -0000 Hi, I think the with-defaults draft should be clarified to indicate that the parameter is ignored for if the target of the copy operation is the candidate or running databases. Andy From phil@juniper.net Thu Jul 30 10:14: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 33C593A6C1E for ; Thu, 30 Jul 2009 10:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 y84sHHSR5AOj for ; Thu, 30 Jul 2009 10:14:18 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id D20FB3A68E8 for ; Thu, 30 Jul 2009 10:13:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSnHU0cCxa73JIEyYDDgEnf4hhP0Axa8q@postini.com; Thu, 30 Jul 2009 10:13:54 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.375.2; Thu, 30 Jul 2009 10:04:48 -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); Thu, 30 Jul 2009 10:04:48 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 10:04:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 10:04:47 -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 n6UH4kd49453; Thu, 30 Jul 2009 10:04:47 -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 n6UGrGIh045300; Thu, 30 Jul 2009 16:53:17 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907301653.n6UGrGIh045300@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A71CD21.6040909@netconfcentral.com> Date: Thu, 30 Jul 2009 12:53:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 17:04:47.0348 (UTC) FILETIME=[D7B77B40:01CA1137] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] lock and commit operations 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 Jul 2009 17:14:20 -0000 Andy Bierman writes: >The operation does not affect the operation at all. >Martin already pointed this out. This is a mistake that needs to be repaired in -bis. The intent was that commit would fail if the candidate is locked by another session. This is definitely what we do in JUNOS. Thanks, Phil From phil@juniper.net Thu Jul 30 10:21: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 65E4B28C100 for ; Thu, 30 Jul 2009 10:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 FF085p8qDOdW for ; Thu, 30 Jul 2009 10:21:16 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id F36C428C125 for ; Thu, 30 Jul 2009 10:21:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSnHWjW8c48V6nPde1daOqtrQmXziBV+x@postini.com; Thu, 30 Jul 2009 10:21:18 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.375.2; Thu, 30 Jul 2009 10:12:31 -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); Thu, 30 Jul 2009 10:12:31 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 10:12:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 10:12:30 -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 n6UHCTd53144; Thu, 30 Jul 2009 10:12:30 -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 n6UH0x5j045473; Thu, 30 Jul 2009 17:01:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907301701.n6UH0x5j045473@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A71D2E9.4080004@netconfcentral.com> Date: Thu, 30 Jul 2009 13:00:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 17:12:30.0417 (UTC) FILETIME=[EBBA3410:01CA1138] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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 Jul 2009 17:21:17 -0000 Andy Bierman writes: >I think the with-defaults draft should be clarified to >indicate that the parameter is ignored >for if the target of the copy operation >is the candidate or running databases. Doesn't it say the opposite, that it's only legal for files/urls? Thanks, Phil From andy@netconfcentral.com Thu Jul 30 10:26: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 C29493A6CBC for ; Thu, 30 Jul 2009 10:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 MWweT9bIAgSw for ; Thu, 30 Jul 2009 10:26:50 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 2F5CD3A6C05 for ; Thu, 30 Jul 2009 10:26:50 -0700 (PDT) Received: (qmail 41627 invoked from network); 30 Jul 2009 17:26:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 17:26:49 -0000 X-YMail-OSG: g9h6S.QVM1nr_N59HU1s_pJJ3IZZyJbnqeCXR1E5v1.LFNK9Jyb74GfEyS_Obkh_JRMDlw6Xa_76teeGoz5talru5nKvnhDouekBXIc69Yb5BSVsa4IktOCTzChbKQVtXfK9Mh7j6c3WsQI5xIg_Tp_ScJwQ2LSJNZykecUXS2HsUWcAoykFLLZTTTf08hX.r2DjBeR_jh6H74pc9fZokNCLucv_NL7VRkBYn6l6_89XRMdqVw3M_bXC1GbthNUZPu0ouX_6KYyLds5CkXxy5sFtTifX4YRFCJ4O6jB6NvSl8uxQNg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71D761.2060200@netconfcentral.com> Date: Thu, 30 Jul 2009 10:24:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907301653.n6UGrGIh045300@idle.juniper.net> In-Reply-To: <200907301653.n6UGrGIh045300@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] lock and commit operations 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 Jul 2009 17:26:50 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The operation does not affect the operation at all. >> Martin already pointed this out. > > This is a mistake that needs to be repaired in -bis. The > intent was that commit would fail if the candidate is locked > by another session. This is definitely what we do in JUNOS. > Good. Let's just declare it a bug in 4741 and not worry about backward compatibility. The new text needs to go in 8.3.4.1 or 7.5. I do not remember any intent at the time 4741 was written to allow to bypass all locking. > Thanks, > Phil > Andy From andy@netconfcentral.com Thu Jul 30 10:35: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 6CB7F28C302 for ; Thu, 30 Jul 2009 10:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 QqQXsqe1YqQ8 for ; Thu, 30 Jul 2009 10:35:42 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id B2E2E28C300 for ; Thu, 30 Jul 2009 10:35:42 -0700 (PDT) Received: (qmail 74462 invoked from network); 30 Jul 2009 17:35:42 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2009 17:35:42 -0000 X-YMail-OSG: oxDHUk0VM1leOocTpskSVtMCG8VvACqQN0trkrBBXs1FDw_WWsrN.GkoIjTEBatET0Tnn2laWvIp7xr8L3Y4h2BgsPwQXlx3uh9UySylIjD.Yy5VhoYnYV1JClkggauzebIZMjEldwxCBZQkxgrAkHF57feqwkAEUL810Ki0ZSFVEr4HH7GshRqBkx1UTP2rMgJIzjea8R_89XJxDHeZmrQCQ0P6_sTmuefZcSJOiaF_WewCdSeDorixEPZ8dqAlH0N6zLiSjCTyng-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71D976.5020803@netconfcentral.com> Date: Thu, 30 Jul 2009 10:33:42 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907301701.n6UH0x5j045473@idle.juniper.net> In-Reply-To: <200907301701.n6UH0x5j045473@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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 Jul 2009 17:35:43 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I think the with-defaults draft should be clarified to >> indicate that the parameter is ignored >> for if the target of the copy operation >> is the candidate or running databases. > > Doesn't it say the opposite, that it's only legal for files/urls? > oops is only affected if the target of the operation is a URL. If the target is a NETCONF datastore (running, candidate or startup) the capability has no effect. I allow for copy-config from running to startup. It has a real impact. If the operator really wants the 'explicit' filtered view, then saving running to startup will affect that. Everything that gets saved in startup its tagged as 'explicitly-set' the next time the agent boots. So the operator may want to control how defaults are saved to NV-storage. > Thanks, > Phil > Andy From andy@netconfcentral.com Thu Jul 30 10:46: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 949E63A71DE for ; Thu, 30 Jul 2009 10:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 POUSXGs7IFbo for ; Thu, 30 Jul 2009 10:46:53 -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 BD3B53A71DB for ; Thu, 30 Jul 2009 10:46:53 -0700 (PDT) Received: from [68.142.200.225] by n14.bullet.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 17:46:54 -0000 Received: from [68.142.201.252] by t6.bullet.mud.yahoo.com with NNFMP; 30 Jul 2009 17:46:54 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 17:46:54 -0000 X-Yahoo-Newman-Id: 52309.42750.bm@omp413.mail.mud.yahoo.com Received: (qmail 48583 invoked from network); 30 Jul 2009 17:46:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 17:46:53 -0000 X-YMail-OSG: jwXXowwVM1lGLy8GCnNQQbJIRiv6Xi6Ep3bjAHMGESMBlyyX3mgTBCzKWCJ7mGq4ghRsCb8IWztXOcOaQXKQR1SyCrSgYUGRiUsNPu2taWmulf8tLcD8RYaRb8vVI9UbgQlemZAOQ1cp.So8CakbNAVPSxGpCwo3KuSUDNVIVzzi.5jyOHNgD3e4JPHQMnGFkuSPlS.XU9oPHOqYU_E2nTGNm1Q_wx.7CjI3X1vAssbhxRpYJFX9.GDYkdsYmknrGUD2Ln4EQJiZHw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71DC1A.4070400@netconfcentral.com> Date: Thu, 30 Jul 2009 10:44:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] copy-config and access control 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 Jul 2009 17:46:54 -0000 Hi, The operation is not all-or-nothing, right? That is, if I copy some inline config into candidate, running, or startup, what if the 10th existing node I delete causes an access-denied error? (as I am replacing existing config with my inline config) Sec. 7.3 is not entirely clear on this point. Is the agent required to do a complete validation, or is it allowed to do stop-on-error instead? This is one reason I do not like copy-config. The database architecture would be much cleaner without these imprecise overlapping operations. (Same issue applies to delete-config in sec. 7.4) Andy From andy@netconfcentral.com Thu Jul 30 11:24: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 B3E8628C192 for ; Thu, 30 Jul 2009 11:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 ZnSBSmQ5qCjL for ; Thu, 30 Jul 2009 11:24:56 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 003693A6C7F for ; Thu, 30 Jul 2009 11:24:55 -0700 (PDT) Received: from [209.191.108.96] by n18.bullet.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 18:24:56 -0000 Received: from [68.142.201.244] by t3.bullet.mud.yahoo.com with NNFMP; 30 Jul 2009 18:24:56 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 30 Jul 2009 18:24:56 -0000 X-Yahoo-Newman-Id: 271459.73706.bm@omp405.mail.mud.yahoo.com Received: (qmail 71065 invoked from network); 30 Jul 2009 18:24:55 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 30 Jul 2009 18:24:55 -0000 X-YMail-OSG: geqM.wcVM1lQCcIYipaPV9zw30vUIb4PzNuf4EQGFRl7Zt.T96DqxiucsuqenERwWLl559zVTQitl4RPkHBVu4OyJEjWj._pNeFeva2iE.ytgGU0ONJl2hzJxof9mYShgf8.naIKVi2Ooy9S5rvbGyq62hrZp5ja7p97_Qke081RBbnSMXFzCPsU4.lH74TCE8UbfJ8ZAjRmnsEDkpN8XNUN5xUmdGkZWPQfwLBDXWqq262FoaVlyvrqDxeP_Na6_yoZNFLHdj5ULg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A71E502.8020107@netconfcentral.com> Date: Thu, 30 Jul 2009 11:22:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907301653.n6UGrGIh045300@idle.juniper.net> In-Reply-To: <200907301653.n6UGrGIh045300@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] lock and commit operations 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 Jul 2009 18:24:56 -0000 Phil Shafer wrote: > Andy Bierman writes: >> The operation does not affect the operation at all. >> Martin already pointed this out. > > This is a mistake that needs to be repaired in -bis. The > intent was that commit would fail if the candidate is locked > by another session. This is definitely what we do in JUNOS. > I just looked my code, and it checks to see if either candidate or running is locked before allowing . Part of the commit operation involves re-synching the candidate with running. I suppose, in theory, the candidate should be the same as running at this point, but the code that refreshes the candidate runs anyway. So add another issue: Does the lock on candidate have any affect on ? > Thanks, > Phil > Andy From mbj@tail-f.com Thu Jul 30 12:15: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 7031A3A7224 for ; Thu, 30 Jul 2009 12:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwU5trLArxZy for ; Thu, 30 Jul 2009 12:15: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 A6C733A7223 for ; Thu, 30 Jul 2009 12:15:40 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 258AA76C54A; Thu, 30 Jul 2009 21:15:42 +0200 (CEST) Date: Thu, 30 Jul 2009 21:15:41 +0200 (CEST) Message-Id: <20090730.211541.211147280.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4A71E502.8020107@netconfcentral.com> References: <200907301653.n6UGrGIh045300@idle.juniper.net> <4A71E502.8020107@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] lock and commit operations 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 Jul 2009 19:15:41 -0000 Andy Bierman wrote: > I just looked my code, and it checks to see if > either candidate or running is locked before allowing . I checked my code and it did the same. > So add another issue: > Does the lock on candidate have any affect on ? Yes, this needs to be spelled out. I don't remember, but since both of us do this check (even though it is not clearly specified), maybe this has been discussed on the ML earlier? /martin From phil@juniper.net Thu Jul 30 16:31: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 78D833A6A1F for ; Thu, 30 Jul 2009 16:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 QzelPvqnp4Ew for ; Thu, 30 Jul 2009 16:31:16 -0700 (PDT) Received: from chip3og51.obsmtp.com (chip3og51.obsmtp.com [64.18.14.167]) by core3.amsl.com (Postfix) with ESMTP id A96CC3A67FD for ; Thu, 30 Jul 2009 16:31:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob51.postini.com ([64.18.6.12]) with SMTP ID DSNKSnItRYZ4kJXa4em3OYSDHJgDtpSoNEDY@postini.com; Thu, 30 Jul 2009 16:31:18 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.375.2; Thu, 30 Jul 2009 16:28:48 -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); Thu, 30 Jul 2009 16:28:48 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:28:48 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:28:47 -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 n6UNSkd39052; Thu, 30 Jul 2009 16:28:46 -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 n6UNHG4e047796; Thu, 30 Jul 2009 23:17:16 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907302317.n6UNHG4e047796@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A71E502.8020107@netconfcentral.com> Date: Thu, 30 Jul 2009 19:17:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 23:28:47.0324 (UTC) FILETIME=[7C9CD1C0:01CA116D] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] lock and commit operations 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 Jul 2009 23:31:17 -0000 Andy Bierman writes: >Does the lock on candidate have any affect on ? Absolutely. The lock on config controls the commit. Thanks, Phil From phil@juniper.net Thu Jul 30 16:52: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 65C923A6A85 for ; Thu, 30 Jul 2009 16:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 RSieSras63ae for ; Thu, 30 Jul 2009 16:52:46 -0700 (PDT) Received: from chip3mo2-old.postini.com (chip3mo2-old.postini.com [64.18.14.205]) by core3.amsl.com (Postfix) with ESMTP id 7B1F83A6AD2 for ; Thu, 30 Jul 2009 16:52:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob64.postini.com ([64.18.6.12]) with SMTP ID DSNKSnIyQVkgtmFcPLawSexuwgRIVVtR1OEw@postini.com; Thu, 30 Jul 2009 16:52: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.375.2; Thu, 30 Jul 2009 16:48:32 -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); Thu, 30 Jul 2009 16:48:32 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:48:32 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:48:31 -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 n6UNmSd50737; Thu, 30 Jul 2009 16:48:30 -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 n6UNavsL047993; Thu, 30 Jul 2009 23:36:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200907302336.n6UNavsL047993@idle.juniper.net> To: Andy Bierman In-Reply-To: <4A71D976.5020803@netconfcentral.com> Date: Thu, 30 Jul 2009 19:36:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Jul 2009 23:48:31.0419 (UTC) FILETIME=[3E6360B0:01CA1170] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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 Jul 2009 23:52:47 -0000 Andy Bierman writes: >So the operator may want to control how defaults are saved to NV-storage. I view it as an unlikely scenario that an operator will want to waste precious nv ram on default values. Also since readability in config scales with the volume, a large config is more problematic to understand, maintain, and debug. It's a lose/lose scenario. Thanks, Phil From andy@netconfcentral.com Fri Jul 31 07: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 F310D3A6C82 for ; Fri, 31 Jul 2009 07:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 ekin28RZdm5F for ; Fri, 31 Jul 2009 07:41:11 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 5EDC53A686D for ; Fri, 31 Jul 2009 07:41:11 -0700 (PDT) Received: (qmail 99640 invoked from network); 31 Jul 2009 14:41:11 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 31 Jul 2009 14:41:11 -0000 X-YMail-OSG: tchw0NMVM1l9UR5byEdFRrNsdydA4iQa3leBEgv_0akakgIHCweMjjNKyCzQWwXRO_6TxFd53GVV9qB3pWTpFl2OaCajcjgs5b7..Wl3jjBpQr_ijSsWpRLxtvlwkOePm3fHrwswxNhgtS6coFcjzubBp662rb3rryvCLwEkLN3ZuYinDpRy0CXJcVZbrN89k.SJHzBDfjjd7NHfdhZ4nejpOg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A730293.2000406@netconfcentral.com> Date: Fri, 31 Jul 2009 07:41:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Phil Shafer References: <200907302336.n6UNavsL047993@idle.juniper.net> In-Reply-To: <200907302336.n6UNavsL047993@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults clarification 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, 31 Jul 2009 14:41:13 -0000 Phil Shafer wrote: > Andy Bierman writes: >> So the operator may want to control how defaults are saved to NV-storage. > > I view it as an unlikely scenario that an operator will want to > waste precious nv ram on default values. Also since readability > in config scales with the volume, a large config is more problematic > to understand, maintain, and debug. It's a lose/lose scenario. > I think 10 years ago, in a really router-centric world, the "precious NVRAM" argument would be good enough. But NV-storage is not expensive on every device, and it should be up to the operator to decide how to use resources anyway. If the manager wants the agent to use 'explicit' instead or 'trim', and the agent supports both, then the parameter is the only way for the operator to make the NV-store consistent with the preferred view of defaults. Another issue is the "new image reboot" scenario. Router vendors like to claim that when they change the default value for some parameter from 1 SW release to the next, that it is always OK, nothing to worry about. But an operator may want to insure that no defaults change by not using any defaults. This would be a debugging mode. What if the new image doesn't work right when the box boots with the trimmed NV-store? Does it work better when it boots with with the full set of values, and not the new defaults? > Thanks, > Phil > Andy From mbj@tail-f.com Fri Jul 31 07:54: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 14C0C28C319 for ; Fri, 31 Jul 2009 07:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_26=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 LuOScEq4EGz9 for ; Fri, 31 Jul 2009 07:54:52 -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 DCCA43A6B6E for ; Fri, 31 Jul 2009 07:54:51 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 730AA76C5A0; Fri, 31 Jul 2009 16:54:52 +0200 (CEST) Date: Fri, 31 Jul 2009 16:54:52 +0200 (CEST) Message-Id: <20090731.165452.179797677.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200907301232.n6UCWNC7043144@idle.juniper.net> References: <200907301232.n6UCWNC7043144@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] Comments on draft-ietf-netconf-monitoring-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 14:54:53 -0000 Phil Shafer wrote: > 2. XML Schema to Monitor NETCONF > > s/XML Schema to Monitor NETCONF/Information Model/ > > Or is "Data Model"? Ask Juergen. Data Model. > The URI ends on ":state". If this is the "NETCONF Monitoring Schema", > this should be ":monitor". It also should include a version number: > > urn:ietf:params:xml:ns:netconf:monitor:1.0 s/state/monitor is fine with me, but I don't agree we should add a version number. We have the revision statement in YANG modules to handle versioning. > 2.1 The /netconf-state Subtree > > There are two "big picture" questions here: > > (a) should ietf models be under a top-level "/ietf/" container? > We should have some hierarchy in our hierarchical data models. > If fact should this be under "/ietf/management/netconf"? As Andy said this has been discussed and resolved before. Adding this hierarchy would just add unnecessay containers. The namespace URI provides the context for the top-level node. > (b) Why is there a "-state" suffix? Most of this isn't state data, > per se (schemas are not state data). It seems like you need to > separate this. But there is also some question about who we will > organize data. There are many advocates of intermixing state data > without the same tree as configuration data, so config=false nodes > will intermix with config=true ones. I'm not convinced that this > works well, but it's something we need to think about for this draft. The model in this draft does not mix config and state, so I am not sure what we need to think about? > 2.1.3. The /netconf-state/schemas Subtree > > Why isn't "namespace" the key, instead of identifier? The current indexing allows you to list (and fetch) YANG submodules (and equivalent for XSD and RNG). > Shouldn't "version" be "revision"? This is the right name for > YANG. What does "version" mean for XSD? The version has typically > been part of the namespace. In XSD, there is a 'version' attribute on the xs:schema element. Some XML schemas use that, and some encode the version in the URI. This leaf needs a data model mapping. We should add text that says that for YANG modules and submodules, this leaf contains the (sub)module's revision. > 2.1.5. The /netconf-state/statistics Subtree > > "Statistical data pertaining to the NETCONF server" implies that there > is only one server. Given that most of us will be using the openssh > code and the sshd_conf subsystem hook, there's not one single server. > > In particular, start-time makes no sense. Maybe it should say "network management subsystem" or something, like sysUpTime. > 3.1. The Operation > > s/When/If/ > s/this new operation/the operation/ > > The namespace should be the key here. Also s/version/revision/ > > The 'data-missing' error code sounds misleading. If the client asks > for something that we don't have, it's a problem with the client. We > should return invalid-value or something like that. 'invalid-value' is fine, assuming that 'data-missing' MUST only be used for errors coupled to data store content. /martin From mbj@tail-f.com Fri Jul 31 08:09: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 78CEE3A68A8 for ; Fri, 31 Jul 2009 08:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.252, 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 VDa+b07FSdxl for ; Fri, 31 Jul 2009 08:09: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 09A773A6E2E for ; Fri, 31 Jul 2009 08:09:23 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9664676C5A0; Fri, 31 Jul 2009 17:09:24 +0200 (CEST) Date: Fri, 31 Jul 2009 17:09:24 +0200 (CEST) Message-Id: <20090731.170924.62921357.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200907302317.n6UNHG4e047796@idle.juniper.net> References: <4A71E502.8020107@netconfcentral.com> <200907302317.n6UNHG4e047796@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] lock and commit operations 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, 31 Jul 2009 15:09:36 -0000 [resend] Phil Shafer wrote: > Andy Bierman writes: > >Does the lock on candidate have any affect on ? > > Absolutely. The lock on config controls the commit. This is not obvious so it needs clarification. does not modify the candidate, so why does a lock on candidate prevent me from committing? If running is locked it is obvious since running will be modified by the commit. /martin From mbj@tail-f.com Fri Jul 31 08:14:40 2009 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0314D3A6DE6 for ; Fri, 31 Jul 2009 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.238, 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 PuCFyK+gnEA1 for ; Fri, 31 Jul 2009 08:14:39 -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 95DB728C342 for ; Fri, 31 Jul 2009 08:14:18 -0700 (PDT) Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C435E76C5F1; Fri, 31 Jul 2009 16:55:27 +0200 (CEST) Date: Fri, 31 Jul 2009 16:55:27 +0200 (CEST) Message-Id: <20090731.165527.156056701.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200907302317.n6UNHG4e047796@idle.juniper.net> References: <4A71E502.8020107@netconfcentral.com> <200907302317.n6UNHG4e047796@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] lock and commit operations 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, 31 Jul 2009 15:14:40 -0000 Phil Shafer wrote: > Andy Bierman writes: > >Does the lock on candidate have any affect on ? > > Absolutely. The lock on config controls the commit. This is not obvious so it needs clarification. does not modify the candidate, so why does a lock on candidate prevent me from committing? If running is locked it is obvious since running will be modified by the commit. /martin From andy@netconfcentral.com Fri Jul 31 09:50:27 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 EDFA53A6E0A for ; Fri, 31 Jul 2009 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 Nifgc1Uu6k7b for ; Fri, 31 Jul 2009 09:50:27 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 531A63A6D56 for ; Fri, 31 Jul 2009 09:50:27 -0700 (PDT) Received: (qmail 5071 invoked from network); 31 Jul 2009 16:50:26 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.85.49 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 31 Jul 2009 16:50:26 -0000 X-YMail-OSG: S0vwCrYVM1lCbnc2Mzxt4Nvo5gbkSmldfG9R0SRENnrqGyfEZnOdbocAazQuBe2CZaDfVjay6hMlVg3MvlNoz6HRR2eZXvpPJxWJ6hYcrASTIgn_nHVy4slLoeCeAMEro5MszAay.HG.f0ONQ8gjLb.u0VLzdYcWBbR24GV8M3t2Y7TsVVhFgzyuHpA7.uLrWKZRaumJmylmY8yCYIJbhF7uoWDFSUngCQLKIYKewMjc7YABXiZFdaAefqq9N5OTYkw9ZkN_YTtxVO9ewnFLXo3W1tGp37SJ07Dk14_JdeZfZ2Dn5Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A732066.5060204@netconfcentral.com> Date: Fri, 31 Jul 2009 09:48:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Martin Bjorklund References: <4A71E502.8020107@netconfcentral.com> <200907302317.n6UNHG4e047796@idle.juniper.net> <20090731.170924.62921357.mbj@tail-f.com> In-Reply-To: <20090731.170924.62921357.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] lock and commit operations 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, 31 Jul 2009 16:50:28 -0000 Martin Bjorklund wrote: > [resend] > > Phil Shafer wrote: >> Andy Bierman writes: >>> Does the lock on candidate have any affect on ? >> Absolutely. The lock on config controls the commit. > > This is not obvious so it needs clarification. does not > modify the candidate, so why does a lock on candidate prevent me from > committing? If running is locked it is obvious since running will be > modified by the commit. > Agreed. It is obvious a lock on the running config should stop a commit. Candidate is not obvious at all because it should never change (OK or error) because of commit. I am wondering if 'running' is the only lock that should prevent a commit. The lock on candidate should prevent edit-config, delete-config, copy-config, and discard-changes. > > /martin > Andy