From owner-netconf@psg.com Tue May 25 10:11:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13676 for ; Tue, 25 May 2004 10:11:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSceg-00016B-34 for netconf-archive@lists.ietf.org; Tue, 25 May 2004 14:11:46 +0000 To: netconf-archive@ietf.org From: majordomo@psg.com Subject: Welcome to netconf Reply-To: majordomo@psg.com Message-Id: Date: Tue, 25 May 2004 14:11:46 +0000 -- Welcome to the netconf mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe netconf or from another account, besides netconf-archive@lists.ietf.org: unsubscribe netconf netconf-archive@lists.ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: NOTE WELL: All statements of a technical or standards-related nature addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants certain licenses and rights in such statements to the IETF and its participants. This includes verbal statements in meetings, as well as written and electronic communications made at any time or place, to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG or any member thereof, - the IAB or any member thereof, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - or as an Internet-Drafts submission The above excludes personal communications not intended to be shared with any IETF working group, the IESG, the IAB, or any subset thereof. From owner-netconf@ops.ietf.org Thu May 27 06:39:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14107 for ; Thu, 27 May 2004 06:39:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTI5j-00016T-HP for netconf-data@psg.com; Thu, 27 May 2004 10:26:27 +0000 Received: from [195.37.70.2] (helo=tokyo.ccrle.nec.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTI5i-000166-4P for netconf@ops.ietf.org; Thu, 27 May 2004 10:26:26 +0000 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i4RAQODW071334 for ; Thu, 27 May 2004 12:26:24 +0200 (CEST) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DE00CCAD3A for ; Thu, 27 May 2004 12:26:23 +0200 (CEST) From: Cristian Cadar Organization: NEC Europe Ltd. To: netconf@ops.ietf.org Subject: startup datastore Date: Thu, 27 May 2004 12:27:43 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200405271227.43190.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I'm trying to understand the use of the startup datastore when used togheth= er with the running datastore. =46rom the draft: "Running: The complete configuration currently active on = the network device..." should I understand that the device is configured at boo= t time with the content of the startup datastore and after a while is configured by the content of the running dat= astore? what happens if=20 their content differ? When and in which situations the startup datastore ma= y be used? For the time being I cannot see any win having a startup datastore. TNX Cristian -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu May 27 15:11:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17633 for ; Thu, 27 May 2004 15:11:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTQ5x-0006hs-Be for netconf-data@psg.com; Thu, 27 May 2004 18:59:13 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTQ5q-0006gE-JP for netconf@ops.ietf.org; Thu, 27 May 2004 18:59:06 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 May 2004 11:58:49 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4RIx2Xl001940; Thu, 27 May 2004 11:59:03 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-395.cisco.com [10.21.97.139]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUQ08914; Thu, 27 May 2004 11:59:01 -0700 (PDT) Message-Id: <6.0.3.0.2.20040527113507.036db080@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 27 May 2004 11:45:40 -0700 To: Cristian Cadar From: Andy Bierman Subject: Re: startup datastore Cc: netconf@ops.ietf.org In-Reply-To: <200405271227.43190.Cristian.Cadar@netlab.nec.de> References: <200405271227.43190.Cristian.Cadar@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 03:27 AM 5/27/2004, Cristian Cadar wrote: >Hi, > >I'm trying to understand the use of the startup datastore when used toghether >with the running datastore. > From the draft: "Running: The complete configuration currently active on the >network device..." should I understand that the device is configured at boot time with the content of the startup >datastore and after a while is configured by the content of the running datastore? no. The configuration datastore is simply the sum of all current configuration settings. The configuration is only visible on devices that have the #writable-running (sec. 6.4.1) capability set. This means that the active configuration and the next-reboot configuration are not kept in sync automatically by the agent. Instead, the next-reboot config (called ) is updated with the copy-config operation (copy to ). Devices without this capability do not need a config because it will always be identical to , so it's redundant. >what happens if >their content differ? When and in which situations the startup datastore may be used? For the time being I cannot >see any win having a startup datastore. The value of a separate startup config is to provide the operator some control as when it is safe to overwrite the next-reboot config. Since existing technology (as well as NETCONF) doesn't provide mechanisms for the agent to identity actual transaction boundaries for , the agent doesn't know when the running config is stable. >TNX >Cristian > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 28 11:16:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08796 for ; Fri, 28 May 2004 11:16:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTirN-0001L3-7D for netconf-data@psg.com; Fri, 28 May 2004 15:01:25 +0000 Received: from [195.37.70.2] (helo=tokyo.ccrle.nec.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTirL-0001Kl-RC for netconf@ops.ietf.org; Fri, 28 May 2004 15:01:24 +0000 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i4SF1LDW070917 for ; Fri, 28 May 2004 17:01:22 +0200 (CEST) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 96C50BE91 for ; Fri, 28 May 2004 17:01:21 +0200 (CEST) From: Cristian Cadar Organization: NEC Europe Ltd. To: netconf@ops.ietf.org Subject: security issues Date: Fri, 28 May 2004 17:01:58 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405281701.58616.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In order to have a secure communication between peers the draft mentions the usage of the Radius, TLS or SSH protocol. Why IPsec is not taken into account here? Which one of the protocols above is preferred/mandatory in NETCONF, if any? TNX Cristian -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 28 18:16:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12979 for ; Fri, 28 May 2004 18:15:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTpPd-000M9d-Bs for netconf-data@psg.com; Fri, 28 May 2004 22:01:13 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTpPb-000M9B-Cx for netconf@ops.ietf.org; Fri, 28 May 2004 22:01:11 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 May 2004 15:01:08 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4SM19ls001201 for ; Fri, 28 May 2004 15:01:09 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn4-690.cisco.com [10.21.82.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUR43087; Fri, 28 May 2004 15:01:08 -0700 (PDT) Message-Id: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 28 May 2004 14:56:05 -0700 To: netconf@ops.ietf.org From: Andy Bierman Subject: sub-tree filtering proposals Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk A) Issue 14.1: Subset specification A.1) Extensibility The and operations should be modified to allow for the utilization of different types of standard, proprietary, and experimental filter mechanisms in an extensible way. - An additional containment layer (called ) is needed above the user data model content in the get operation message. - The element can appear zero or one times - There is one attribute defined, called 'filter-type', which identifies the type of filter processing requested by the manager - The content type is 'any' (any element outside the netconf namespace) In addition, some name clarifications to the get operations are needed: - For , change the name of the parameter to . - For the associated with and operations, change the return parameter name to Old Request: New Request: New Reply: 7 B) Issue 14.1.2: Subtree Filtering ---------------------------------- B.1) Overview XML sub-tree filtering is a mechanism that allows an application to select particular XML sub-trees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited selection mechanisms. The agent does not need to utilize any data-model specific semantics during processing, allowing for simple and centralized implementation strategies. A sub-tree filter is comprised of well-formed XML. No special tags, content, or structure are imposed in any way. It is possible that a sub-tree filter expression may contain an empty leaf node, even if the XSD for the particular data model indicates some content is required (i.e., maxOccurs > 0). For this reason, it may not be possible to completely validate all filter expressions against an XSD which represents the fully populated data model. Conceptually, a sub-tree filter is comprised of zero or more element sub-trees, which represent the filter selection criteria. At each containment level within a sub-tree, the set of sibling nodes is logically processed by the agent to determine if its sub-tree (and path to the root) are included in the filter output. Element nodes have different purposes, depending on their position in the sub-tree. Most nodes in the sub-tree identify containment, in which the specified node name must exactly match a corresponding node in the agent's data model. A leaf node in the filter with simple content is used to select matching data (i.e., some or all of the set of sibling nodes which includes this leaf node). XML attributes can be present in any node in the filter. Each attribute acts as an additional term for the "AND" expression for that particular node. In addition to matching the name and position of the element, only instances matching all specified attribute values will be included in the response. XML namespaces may be specified (via 'xmlns' declarations) within the filter data model. If so, the declared namespace must first exactly match a namespace supported by the agent. Only data associated with a specified namespace will be considered in the filter operation. Response messages contains only the sub-trees selected by the filter. Any selection criteria that was present in the request, within a particular selected sub-tree, is also included in the response. Specific data instances are not duplicated in the response in the event the request contains multiple filter sub-tree expressions which select the same data. B.2) Sub-tree Filter Components A sub-tree filter is comprised of XML elements and their XML attributes. An attribute which appears in a sub-tree filter is called an "attribute match expression". All elements present in a particular sub-tree within a filter must match associated nodes present in the agent's conceptual data model. Nodes which contain only child elements are called "containment nodes". Leaf nodes which contain simple content are called "content match nodes". Empty leaf nodes are called "selection nodes". B.2.1) Attribute Match Expressions Any number of (unqualified or qualified) XML attributes may be present in any type of filter node. In addition to the selection criteria normally applicable to that node, the selected data must have matching values for every attribute specified in the node. If an element is not defined to include a specified attribute, then it is not selected in the filter output. B.2.2) Containment Nodes Each node specified in a sub-tree filter represents an inclusive filter. Only associated nodes in the specified conceptual datastore on the agent are selected by the filter. A node must exactly match the namespace and absolute path name of the filter data, except the filter absolute path name is adjusted to start from the layer below . A containment node must have one or more child nodes. B.2.3) Content Match Nodes A leaf node with simple content represents an exact-match filter on the simple content, which is combined (as an "AND" expression") with the criteria for a containment node, to select data model instances. All sibling content match nodes combine to represent a logical "AND" expression. If all specified sibling content match nodes in a sub-tree filter expression are 'true', then the agent determines the nodes to be selected in the following manner: - if the set of all sibling nodes (at a given processing level) includes only content match nodes, then all sibling sub-trees (including the content match nodes) are selected by the filter. - if the set of all sibling nodes (at a given processing level) includes any containment or selection nodes, then only the content match nodes, plus any sibling sub-trees selected by further processing, are selected by the filter. - if a containment node is present in the sibling set, then it is potentially selected. If further recursive processing of its child nodes produces any selected filter output, then the containment nodes the element hierarchy related to the particular sub-tree are included in the filter results. - if a selection node is present in the sibling set, then its sub-tree is selected in the filter output. If any of the sibling content match node tests are 'false', then no further filter processing is performed on that sibling set, and none of the sibling sub-trees are selected by the filter, including the content match node(s). B.2.4) Selection Nodes An empty leaf node represents an "explicit selection" filter. Presence of any selection nodes (within a set of sibling nodes) will cause the filter to select the specified sub-tree(s). If a particular sibling set contains content match nodes and selection or containment nodes, then automatic selection of the entire sibling sub-tree is suppressed, and only the specified selection and/or containment nodes are selected by the filter. Unless further restricted by the application of attribute match expressions or content match nodes in the entire element hierarchy containing a particular node, the presence of a selection node will cause all instances of that node (and each node's sub-tree) to be selected by the filter output. B.3 Sub-tree Filter Processing Algorithms The filter output (i.e., set of selected nodes) is initially empty. Each sub-tree filter can contain one or more data model fragments, which represent portions of the data model which should be selected (with all child nodes) in the filter output. Each sub-tree data fragment is compared by the agent to the internal data models supported by the agent. If the entire sub-tree data-fragment filter (starting from the root to the innermost element specified in the filter) exactly matches a corresponding portion of the supported data model, then that node and all its children are included in the result data. The agent processes all nodes with the same parent node (sibling set) together, starting from the root to the leaf nodes. The root elements in the filter are considered to be in the same sibling set (assuming they are in the same namespace), even though they do not have a common parent. For each sibling set, the agent determines which nodes are included (or potentially included) in the filter output, and which sibling sub-trees are excluded (pruned) from the filter output. The agent first determines which types of nodes are present in the sibling set, and processes the nodes according to the rules for their type. If any nodes in the sibling set are selected, then the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all sub-trees specified in the filter have been processed. C) Examples ----------- C.1: No filter Request: Reply: ... entire set of data models returned ... Notes: - Since the sub-tree filter is inclusive, and the start state is the empty set, the best way to get everything on the agent is to leave out the filter. Not sure the best way to fit this into and operations though. C.2: Empty filter Request: Reply: Notes: - Nothing is selected because no content match or selection nodes are present. This is not an error. C.3) Select the entire sub-tree Request: Reply: root superuser Charlie Root 1 1 fred admin Fred Flintstone 2 2 barney admin Barney Rubble 2 3 Notes: - The filter contains one selection node (), so just that sub-tree is selected by the filter - This example represents the fully-populated data model in most of the filter examples that follow. In a real data model, the 'company-info' would not likely be returned with the list of users for a particular host or network. - The following filter request would have produced the same result, but only because the container defines one child element () C.4) Select all 'name' elements within the 'users' sub-tree Request: Reply: root fred barney Notes: - This filter contains two containment nodes (users, user), and one selector node (name). - All instances of the 'name' element in the same sibling set are selected in the filter output. - The manager may need to know that 'name' is used as an instance identifier in this particular data structure, but the agent does not need to know that meta-data in order to process the request. C.5) One specific entry Request: fred Reply: fred admin Fred Flintstone 2 2 Notes: - This filter contains two containment nodes (users, user) and one content match node (name). - All instances of the sibling set containing 'name', for which the value of 'name' equals "fred", are selected in the filter output. C.6) Specific elements from a specific entry Request: fred Reply: fred admin Fred Flintstone Notes: - This filter contains two containment nodes (users, user), one content match node (name), and two selector nodes (type, full-name). - All instances of the 'type' and 'full-name' elements in the same siibling set containing 'name', for which the value of 'name' equals "fred", are selected in the filter output. The 'company-info' element is not included because the sibling set contains selection nodes. C.7) Multiple sub-trees Request: root fred barney superuser Reply: root 1 1 fred 2 Notes: - This filter contains three sub-trees (name=root, fred, barney) - The "root" sub-tree filter contains two containment nodes (users, user), one content match node (name), and one selector node (company-info). The sub-tree selection criteria is met, and just the company-info sub-tree for "root" is selected in the filter output. - The "fred" sub-tree filter contains three containment nodes (users, user, company-info), one content match node (name), and one selector node (id). The sub-tree selection criteria is met, and just the 'id' element within the company-info sub-tree for "fred" is selected in the filter output. - The "barney" sub-tree filter contains three containment nodes (users, user, company-info), two content match nodes (name, type), and one selector node (dept). The sub-tree selection criteria is not met because user "barney" is not a "superuser", and the entire sub-tree for "barney" (including its parent 'user' entry) is excluded from the filter output. C.8) Table with attribute naming Request: Reply: 45621 774344 Notes: - This filter contains one containment node (interfaces), one attribute match expression (ifName), and one selector node (interface). - All instances of the 'interface' sub-tree which have an ifName attribute equal to "eth0" are selected in the filter output. - The filter data elements and attributes must be qualified because the 'ifName' attribute will not be considered part of the 'schema-2' namespace if it is unqualified. - If 'ifName' were a child node instead of an attribute, then the following request would produce the same results: eth0 D) Open Issues -------------- D.1) "No Such Object/Instance" Is it important that an NMS know if results are empty because the filter will never match anything (noSuchObject) or the results are empty because the well-specified dynamic table is empty (noSuchInstance)? -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: