From owner-netconf@ops.ietf.org Wed Oct 12 16:00:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmlj-0006es-KS for netconf-archive@megatron.ietf.org; Wed, 12 Oct 2005 16:00:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17129 for ; Wed, 12 Oct 2005 16:00:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPmcA-0007fO-UP for netconf-data@psg.com; Wed, 12 Oct 2005 19:50:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EPmcA-0007f2-7F for netconf@ops.ietf.org; Wed, 12 Oct 2005 19:50:14 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPmbx-0000Vv-Gd; Wed, 12 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-prot-09.txt Message-Id: Date: Wed, 12 Oct 2005 15:50:01 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk --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 Filename : draft-ietf-netconf-prot-09.txt Pages : 98 Date : 2005-10-12 The NETCONF configuration protocol 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. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-prot-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-prot-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-12110205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-prot-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-prot-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-12110205.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Oct 13 03:07:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxBn-0005MM-DK for netconf-archive@megatron.ietf.org; Thu, 13 Oct 2005 03:07:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27954 for ; Thu, 13 Oct 2005 03:07:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPx4V-000AyV-Dz for netconf-data@psg.com; Thu, 13 Oct 2005 07:00:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPx4S-000Ay8-TP for netconf@ops.ietf.org; Thu, 13 Oct 2005 07:00:08 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 13 Oct 2005 00:00:08 -0700 X-IronPort-AV: i="3.97,209,1125903600"; d="scan'208"; a="351556450:sNHT36957902" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9D70594009569 for ; Thu, 13 Oct 2005 00:00:06 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp362.cisco.com [10.61.65.106]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9D7ArkS026924 for ; Thu, 13 Oct 2005 00:10:54 -0700 Message-ID: <434E05F3.6090508@cisco.com> Date: Thu, 13 Oct 2005 09:00:03 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: netconf Subject: Re: I-D ACTION:draft-ietf-netconf-prot-09.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=123; t=1129187454; x=1129619654; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20I-D=20ACTION=3Adraft-ietf-netconf-prot-09.txt| From:Eliot=20Lear=20| Date:Thu,=2013=20Oct=202005=2009=3A00=3A03=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=MDEvuDT/aO2S+rcyEDXkyDCJ4HcJC0P8kCVDtS8+6+1tSyKvDkEaK0lKQtTLOyJiiq2u6049 sG/v9NBlCqN+bMo6MDy1nAgoz2taqLpt4WIKxqkHS4vPpZ+HcTv+ijgewQPtOCAequvdq69WWLO 1Yh35grgwlHYTXN8/8gWDyYk= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I see no need to rev the beep draft based on these changes, and I would imagine the same is true for SOAP. I believe we're still owed an SSH update. Eliot -- 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 Oct 14 15:56:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVfn-000743-2V for netconf-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:56:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07855 for ; Fri, 14 Oct 2005 15:56:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQVZ6-000GMe-K7 for netconf-data@psg.com; Fri, 14 Oct 2005 19:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQVZ5-000GMA-Gv for netconf@ops.ietf.org; Fri, 14 Oct 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQVZ3-0000lY-Od; Fri, 14 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-ssh-05.txt Message-Id: Date: Fri, 14 Oct 2005 15:50:01 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk --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 : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-ssh-05.txt Pages : 11 Date : 2005-10-14 This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-ssh-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-ssh-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-14110359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-ssh-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-ssh-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14110359.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Sun Oct 16 04:06:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER3Wr-0001v1-6V for netconf-archive@megatron.ietf.org; Sun, 16 Oct 2005 04:06:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17175 for ; Sun, 16 Oct 2005 04:05:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ER3Pe-0001wV-0c for netconf-data@psg.com; Sun, 16 Oct 2005 07:58:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.163.179.136] (helo=web35512.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EQAYR-000HcC-Hk for netconf@ops.ietf.org; Thu, 13 Oct 2005 21:23:59 +0000 Received: (qmail 29922 invoked by uid 60001); 13 Oct 2005 21:23:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6Vy8Xk5IpRpBFGZdnSgCWShWBzJEmdAzeVpARBpREfAhVccznap8pT8aPV0FCM82JnJsVMG2RrYN14PwJ9CkSnYOZcHsOeV3BeKXoTmy3YWFe7XNZrng8+GbWsdYfpYu+4n9J05ST+uX1elqy+ovjWQVIDxHI5P77HEyG0ZiGdg= ; Message-ID: <20051013212357.29920.qmail@web35512.mail.mud.yahoo.com> Received: from [192.147.142.23] by web35512.mail.mud.yahoo.com via HTTP; Thu, 13 Oct 2005 14:23:57 PDT Date: Thu, 13 Oct 2005 14:23:57 -0700 (PDT) From: Andrew Davis Subject: authorization To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Using the ssh mapping, if I want to issue an rcp request on behalf of user fred and then issue another request on behalf of user mike, do I have to establish 2 separate ssh connections? Is the answer different if I use beep? What about soap? --Andrew __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ -- 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 Sun Oct 16 04:06:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER3Ws-0001vE-Os for netconf-archive@megatron.ietf.org; Sun, 16 Oct 2005 04:06:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17174 for ; Sun, 16 Oct 2005 04:05:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ER3PR-0001w3-10 for netconf-data@psg.com; Sun, 16 Oct 2005 07:58:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.163.179.125] (helo=web35501.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EQAWo-000HO2-Fg for netconf@ops.ietf.org; Thu, 13 Oct 2005 21:22:18 +0000 Received: (qmail 66966 invoked by uid 60001); 13 Oct 2005 21:22:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lh5VRz9VKANzH9QdrTar218mX6tXoNm8mduu8ivG1SGOrhcQi5rw9FMo/xKmRVCgNq52yQy4KgHF8pzujqod56RL6JZy9z5UyS/1CAR5Qh/cB0jQAJ8kFDQboBLMWsihjDn6AEeAiyq3bpG8Chaogw3Km0zNkQfD89aXVyQ0LDI= ; Message-ID: <20051013212217.66960.qmail@web35501.mail.mud.yahoo.com> Received: from [192.147.142.23] by web35501.mail.mud.yahoo.com via HTTP; Thu, 13 Oct 2005 14:22:17 PDT Date: Thu, 13 Oct 2005 14:22:17 -0700 (PDT) From: Andrew Davis Subject: access control To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Does netconf define any kind of access control? Or is it all or nothing? A user can read and write everything or else have no access at all? --Andrew __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- 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 Sun Oct 16 04:57:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER4Kq-0008VI-3n for netconf-archive@megatron.ietf.org; Sun, 16 Oct 2005 04:57:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18875 for ; Sun, 16 Oct 2005 04:57:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ER4Gm-0004Iz-SA for netconf-data@psg.com; Sun, 16 Oct 2005 08:53:28 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ER4Gj-0004If-LR for netconf@ops.ietf.org; Sun, 16 Oct 2005 08:53:25 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2005 01:53:25 -0700 X-IronPort-AV: i="3.97,218,1125903600"; d="scan'208"; a="220568170:sNHT25216988" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9G8rNJh025185; Sun, 16 Oct 2005 01:53:23 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4343.cisco.com [10.61.80.246]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9G93wK4017454; Sun, 16 Oct 2005 02:03:59 -0700 Message-ID: <43521500.3050703@cisco.com> Date: Sun, 16 Oct 2005 10:53:20 +0200 From: Eliot Lear User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: Andrew Davis CC: netconf@ops.ietf.org Subject: Re: authorization References: <20051013212357.29920.qmail@web35512.mail.mud.yahoo.com> In-Reply-To: <20051013212357.29920.qmail@web35512.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=603; t=1129453440; x=1129885640; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20authorization| From:Eliot=20Lear=20| Date:Sun,=2016=20Oct=202005=2010=3A53=3A20=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=F0GAn+4K5IivZkMWvbm39mI9fU4IEiMDh0zypxcrS26NAHSfiJJXj6vyn//59gFs9wzZ6NBy 3uI1avK5aqZ9NfIexy1hmVWC84sSahyhmrHSItya96f+LBCF6W+kG+tT28XikttjZg3edGDS+8x GTJAmNXIHIgBL1XBJBMhtqFQ= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In answer to both of your questions, access control is beyond the scope of netconf at this time. This is not to say that implementations should have no access control. Indeed user mike might have very different access than user fred. As to below, Andrew Davis wrote: > Using the ssh mapping, if I want to issue an rcp > request on behalf of user fred and then issue another > request on behalf of user mike, do I have to establish > 2 separate ssh connections? Is the answer different if > I use beep? What about soap? netconf is a session-based protocol, and authentication occurs once per session. Therefore, if you want to issue requests on behalf of another user, using their credentials, you would require another session. Eliot -- 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 Mon Oct 17 08:53:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUUP-00076e-Iw for netconf-archive@megatron.ietf.org; Mon, 17 Oct 2005 08:53:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10202 for ; Mon, 17 Oct 2005 08:53:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERUN9-000JEQ-O4 for netconf-data@psg.com; Mon, 17 Oct 2005 12:45:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERUN8-000JE5-Uk for netconf@ops.ietf.org; Mon, 17 Oct 2005 12:45:47 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9HCh7426660 for ; Mon, 17 Oct 2005 08:43:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: access control Date: Mon, 17 Oct 2005 08:45:41 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4054792CF@zcarhxm2.corp.nortel.com> Thread-Topic: access control Thread-Index: AcXSKNSEi+gDQwo/RQakzL7tSmI8aQA7zVRg From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi As Eliot indicated, currently it is out of scope. We have started to look at this in the Framework for Netconf Content work, but so far have really only made it as far as discussing requirements. Eventually, there should likely be a separate specification that discusses access control in a manner to enable interoperable implementations, or rather consistent access control end-to-end, in the network. This an other work is not officially being worked on by the working group, but you can expect updates to this and the other drafts showing up within the next week or so. We are also discussing the possibility of informal editing sessions on the various topics during the Vancouver meeting. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andrew Davis Sent: Thursday, October 13, 2005 5:22 PM To: netconf@ops.ietf.org Subject: access control Does netconf define any kind of access control? Or is it all or nothing? A user can read and write everything or else have no access at all? --Andrew =09 =09 __________________________________=20 Yahoo! Mail - PC Magazine Editors' Choice 2005=20 http://mail.yahoo.com -- 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 Mon Oct 17 11:47:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXCs-0007rl-V6 for netconf-archive@megatron.ietf.org; Mon, 17 Oct 2005 11:47:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20220 for ; Mon, 17 Oct 2005 11:47:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERX4l-0003AH-2I for netconf-data@psg.com; Mon, 17 Oct 2005 15:38:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERX4k-0003A1-F9 for netconf@ops.ietf.org; Mon, 17 Oct 2005 15:38:58 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Oct 2005 08:38:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9HFcfVC021528; Mon, 17 Oct 2005 08:38:56 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 08:38:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: authorization Date: Mon, 17 Oct 2005 08:38:54 -0700 Message-ID: Thread-Topic: authorization Thread-Index: AcXSJ6yefDubhmt1SW+iKbuRdxGWyQBCH2rQ From: "Steven Berl \(sberl\)" To: "Andrew Davis" , X-OriginalArrivalTime: 17 Oct 2005 15:38:55.0643 (UTC) FILETIME=[E22D2EB0:01C5D330] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable You would need to establish a new connection. For SSH and BEEP, authentication of who is fred and who is mike is established by the transport session level. Notice that there is no place to specify the name fred or mike in the rpc message itself. Potentially this info could be specified in a SOAP header, but that has not made it into any of the documents as far as I can remember. -steve=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andrew Davis > Sent: Thursday, October 13, 2005 2:24 PM > To: netconf@ops.ietf.org > Subject: authorization >=20 > Using the ssh mapping, if I want to issue an rcp request on=20 > behalf of user fred and then issue another request on behalf=20 > of user mike, do I have to establish > 2 separate ssh connections? Is the answer different if I use=20 > beep? What about soap? >=20 > --Andrew >=20 >=20 >=20 >=20 > =09 > __________________________________ > Yahoo! Music Unlimited > Access over 1 million songs. Try it free. > http://music.yahoo.com/unlimited/ >=20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- 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 Wed Oct 19 15:08:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJIq-0008P7-9g for netconf-archive@megatron.ietf.org; Wed, 19 Oct 2005 15:08:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07291 for ; Wed, 19 Oct 2005 15:08:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESJAm-000MHO-Hl for netconf-data@psg.com; Wed, 19 Oct 2005 19:00:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESJAl-000MH7-Er for netconf@ops.ietf.org; Wed, 19 Oct 2005 19:00:23 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9JJ0I511994 for ; Wed, 19 Oct 2005 15:00:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Netconf 'Phase 2' Editing Sessions in Vancouver Date: Wed, 19 Oct 2005 15:00:14 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40556E541@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf 'Phase 2' Editing Sessions in Vancouver Thread-Index: AcXU31ZeREYY9Pp7TSqaN6/SBb4HmA== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I'm currently scanning the Vancouver IETF schedule for promising slots to hold a number of offline editing sessions for the Netconf Event and Netconf Content internet drafts. I am thinking we could hold quite a few sessions. The documents can be seen under 'id exists' at =09 https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= s earch_job_owner=3D0&search_group_acronym=3D&search_status_id=3D&search_cu= r_sta te=3D&sub_state_id=3D6&search_filename=3Dnetconf&search_rfcnumber=3D&sear= ch_area _acronym=3D&search_button=3DSEARCH Expect updates within the next week or so. I will also post them http://standards.nortel.com/netconf/docs/IETF%2064/ Potential Timeslots (other than evenings, lunches and cookie breaks) ------------------- 1) Monday morning 2) Monday Afternoon Session II 3) Tuesday Afternoon Session II & III 4) Wednesday morning 5) Thursday morning =09 Please let me know if you are interested and what your preferred times are, as well as which documents you are interested in discussing.=20 Note that this does not preclude people sending comments on the mailing lists. Netconf content feedback can be sent to the Netconf Model list http://standards.nortel.com/netconf/index.html Netconf Event comments can perhaps be sent to this list, or if Andy and Simon object then they instead can be sent to the above list. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- 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 Wed Oct 19 16:44:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKn0-0003Uq-8p for netconf-archive@megatron.ietf.org; Wed, 19 Oct 2005 16:44:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00997 for ; Wed, 19 Oct 2005 16:43:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESKgO-0000fx-Af for netconf-data@psg.com; Wed, 19 Oct 2005 20:37:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESKgN-0000fj-Dn for netconf@ops.ietf.org; Wed, 19 Oct 2005 20:37:07 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2005 13:37:07 -0700 X-IronPort-AV: i="3.97,231,1125903600"; d="scan'208"; a="221756869:sNHT59124006" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9JKad9S013815; Wed, 19 Oct 2005 13:37:04 -0700 (PDT) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 13:37:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Netconf 'Phase 2' Editing Sessions in Vancouver Date: Wed, 19 Oct 2005 13:37:00 -0700 Message-ID: <6E21698722408147BEA594E073E2B0ABDC441F@xmb-sjc-223.amer.cisco.com> Thread-Topic: Netconf 'Phase 2' Editing Sessions in Vancouver Thread-Index: AcXU31ZeREYY9Pp7TSqaN6/SBb4HmAADUs8g From: "Hector Trevino \(htrevino\)" To: "Sharon Chisholm" , X-OriginalArrivalTime: 19 Oct 2005 20:37:01.0592 (UTC) FILETIME=[DBDBE980:01C5D4EC] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Sharon, Alex Clemm and myself are interested on both topics. Preferred slots are 2,3, and 4. Hector =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm Sent: Wednesday, October 19, 2005 1:00 PM To: netconf@ops.ietf.org Subject: Netconf 'Phase 2' Editing Sessions in Vancouver hi I'm currently scanning the Vancouver IETF schedule for promising slots to hold a number of offline editing sessions for the Netconf Event and Netconf Content internet drafts. I am thinking we could hold quite a few sessions. The documents can be seen under 'id exists' at =09 https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= s earch_job_owner=3D0&search_group_acronym=3D&search_status_id=3D&search_cu= r_sta te=3D&sub_state_id=3D6&search_filename=3Dnetconf&search_rfcnumber=3D&sear= ch_area _acronym=3D&search_button=3DSEARCH Expect updates within the next week or so. I will also post them http://standards.nortel.com/netconf/docs/IETF%2064/ Potential Timeslots (other than evenings, lunches and cookie breaks) ------------------- 1) Monday morning 2) Monday Afternoon Session II 3) Tuesday Afternoon Session II & III 4) Wednesday morning 5) Thursday morning =09 Please let me know if you are interested and what your preferred times are, as well as which documents you are interested in discussing.=20 Note that this does not preclude people sending comments on the mailing lists. Netconf content feedback can be sent to the Netconf Model list http://standards.nortel.com/netconf/index.html Netconf Event comments can perhaps be sent to this list, or if Andy and Simon object then they instead can be sent to the above list. Sharon Chisholm Nortel Ottawa, Ontario Canada -- 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 Mon Oct 24 20:39:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCqJ-0003kU-3t for netconf-archive@megatron.ietf.org; Mon, 24 Oct 2005 20:39:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07889 for ; Mon, 24 Oct 2005 20:38:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUCfH-000HPT-8n for netconf-data@psg.com; Tue, 25 Oct 2005 00:27:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.155.1] (helo=swip.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUCfG-000HPC-8V for netconf@ops.ietf.org; Tue, 25 Oct 2005 00:27:42 +0000 X-T2-Posting-ID: P5HZhTV1iTSvFccgWTR5dA== Received: from [213.100.166.180] (HELO localhost) by mailfe09.swip.net (CommuniGate Pro SMTP 4.3.8) with ESMTP id 11433126 for netconf@ops.ietf.org; Mon, 24 Oct 2005 23:34:21 +0200 Date: Mon, 24 Oct 2005 23:34:19 +0200 (CEST) Message-Id: <20051024.233419.45505395.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: comments on draft-ietf-netconf-prot-09 From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We have implemented the netconf draft, and have some comments / questions. 1. In general, it would be helpful with precise "elements of procedure" instructions ala SNMP rfcs. As it is now, it's a bit unclear how errors should be handled in many cases. (see e.g. item 2 below). I suspect different implementations in many cases will generate different error messages for the same input, making it more difficult to write a good manager application. 2. How is a peer supposed to handle mal-formed XML in the processing of the message? Since section 8.1. says that the transport should be (silently?) closed if the session-id element is wrong, is it correct to assume that the same applies to any similar error? What about a mal-formed message? Should an be generated if the XML is bad? Even if the element is missing? 3. How is different versions of the netconf protocol supposed to be handled? Since the message is sent asynchronously by both peers, and the namespace includes a version number, I assume that the intention is to keep the hello message fixed, and then add a new namespace and a new capability for new rpc operations? 4. I understand the separation between the protocol and the underlying application data model. But wouldn't it make sense to state when the result of an operation depends on the data model? It's not trivial to understand how the edit-config operation is supposed to be used without knowledge of the data model. For example, the first example in 7.2 is Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration: Ethernet0/0 1500 In this example, the manager has to know that the of an interface is used as a key (or index) by the agent. If the same command was issued to an agent which had the as key (not very realistic of course), the result had been quite different! In fact, does the 'merge' operation make sense at all unless the manager knows which element(s) are used as key/index? And if there are no keys, does 'merge' mean anything? Again, I understand that the draft defines the protocol and not the model, but I think it would be helpful to at least make a note of the problem, and that this has to be solved by implementations (and/or the netconf modelling effort). /martin -- 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 Tue Oct 25 04:39:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUKKx-0005hm-Th for netconf-archive@megatron.ietf.org; Tue, 25 Oct 2005 04:39:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00292 for ; Tue, 25 Oct 2005 04:39:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUKCK-000MUr-E5 for netconf-data@psg.com; Tue, 25 Oct 2005 08:30:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUKCJ-000MTY-9j for netconf@ops.ietf.org; Tue, 25 Oct 2005 08:30:19 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 886C253328 for ; Tue, 25 Oct 2005 10:30:17 +0200 (CEST) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from webloria.loria.fr (webloria.loria.fr [152.81.144.22]) by macker.loria.fr (Postfix) with ESMTP id BC8B753069 for ; Tue, 25 Oct 2005 10:30:16 +0200 (CEST) Received: from xsftbnupc02.upc.es (xsftbnupc02.upc.es [147.83.181.16]) by www.loria.fr (IMP) with HTTP for ; Tue, 25 Oct 2005 10:21:03 +0200 Message-ID: <1130228463.435deaef30402@www.loria.fr> Date: Tue, 25 Oct 2005 10:21:03 +0200 From: Vincent.Cridlig@loria.fr To: Martin Bjorklund Subject: Re: comments on draft-ietf-netconf-prot-09 References: <20051024.233419.45505395.mbj@tail-f.com> In-Reply-To: <20051024.233419.45505395.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.4 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Concerning item 4, we met exactly the same problem in our implementation of Netconf (YencaP). Up to now, we assumed that the first element is the key. But we also think it would be much better to clearly state what is the key and what value is to be updated in an edit-config operation. Sincerly, Vincent CRIDLIG Selon Martin Bjorklund : > Hi, > > We have implemented the netconf draft, and have some comments / > questions. > > 1. In general, it would be helpful with precise "elements of > procedure" instructions ala SNMP rfcs. As it is now, it's a bit > unclear how errors should be handled in many cases. (see > e.g. item 2 below). I suspect different implementations in many > cases will generate different error messages for the same input, > making it more difficult to write a good manager application. > > 2. How is a peer supposed to handle mal-formed XML in the > processing of the message? Since section 8.1. says that > the transport should be (silently?) closed if the session-id > element is wrong, is it correct to assume that the same > applies to any similar error? What about a mal-formed > message? Should an be generated if the XML is bad? > Even if the element is missing? > > 3. How is different versions of the netconf protocol supposed to be > handled? Since the message is sent asynchronously by > both peers, and the namespace includes a version number, I > assume that the intention is to keep the hello message fixed, > and then add a new namespace and a new capability for new rpc > operations? > > 4. I understand the separation between the protocol and the > underlying application data model. But wouldn't it make sense > to state when the result of an operation depends on the data > model? It's not trivial to understand how the edit-config > operation is supposed to be used without knowledge of the data > model. For example, the first example in 7.2 is > > Set the MTU to 1500 on an interface named "Ethernet0/0" in > the running configuration: > > > Ethernet0/0 > 1500 > > > In this example, the manager has to know that the of an > interface is used as a key (or index) by the agent. If the same > command was issued to an agent which had the as key (not > very realistic of course), the result had been quite different! > > In fact, does the 'merge' operation make sense at all unless the > manager knows which element(s) are used as key/index? And if > there are no keys, does 'merge' mean anything? > > Again, I understand that the draft defines the protocol and not > the model, but I think it would be helpful to at least make a > note of the problem, and that this has to be solved by > implementations (and/or the netconf modelling effort). > > > /martin > > -- > 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 Tue Oct 25 12:44:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURuT-0004wq-E0 for netconf-archive@megatron.ietf.org; Tue, 25 Oct 2005 12:44:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04291 for ; Tue, 25 Oct 2005 12:44:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EURli-000580-2o for netconf-data@psg.com; Tue, 25 Oct 2005 16:35:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EURlg-00056f-OU for netconf@ops.ietf.org; Tue, 25 Oct 2005 16:35:21 +0000 Received: (qmail 1851 invoked by uid 78); 25 Oct 2005 16:33:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.60 with SMTP; 25 Oct 2005 16:33:09 -0000 Message-ID: <435E5E44.3090300@andybierman.com> Date: Tue, 25 Oct 2005 09:33:08 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: comments on draft-ietf-netconf-prot-09 References: <20051024.233419.45505395.mbj@tail-f.com> In-Reply-To: <20051024.233419.45505395.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >Hi, > >We have implemented the netconf draft, and have some comments / >questions. > > 1. In general, it would be helpful with precise "elements of > procedure" instructions ala SNMP rfcs. As it is now, it's a bit > unclear how errors should be handled in many cases. (see > e.g. item 2 below). I suspect different implementations in many > cases will generate different error messages for the same input, > making it more difficult to write a good manager application. > > IMO we can't write a super-detailed elements of procedure without knowing many or all the problems areas, i.e., same input on 2 boxes that supposedly support the same data model produce different sets of elements. We need real data from real implementations, indicating interoperability problems. You have to characterize exactly what differences are allowed (e.g., error order) vs. not allowed, which errors depend on the particular operations supported in a given data model, etc. This is not an easy problem. > 2. How is a peer supposed to handle mal-formed XML in the > processing of the message? Since section 8.1. says that > the transport should be (silently?) closed if the session-id > element is wrong, is it correct to assume that the same > applies to any similar error? What about a mal-formed > message? Should an be generated if the XML is bad? > Even if the element is missing? > > If the peer never gets a complete message, the transport layer has to shut down the session. I don't think malformed XML is any different than a malformed binary PDU. It can't be processed. You didn't really get an request if it was malformed XML or missing, so you can't send an . Side bar: We need a monitoring module for NETCONF, especially in the early days, to debug the protocol. I'm working on a set of counters (rpcs-rcvd, rpc-replies-sent, rpc-parse-errors, bad-hello-msgs-received, etc.). I would really appreciate your input (and all fellow implementors) on this initial set of counters. > 3. How is different versions of the netconf protocol supposed to be > handled? Since the message is sent asynchronously by > both peers, and the namespace includes a version number, I > assume that the intention is to keep the hello message fixed, > and then add a new namespace and a new capability for new rpc > operations? > > Yes -- the base protocol URN would be different in a new version. We will probably add minor features as capabilities instead of obsoleting version 1 of the protocol. > 4. I understand the separation between the protocol and the > underlying application data model. But wouldn't it make sense > to state when the result of an operation depends on the data > model? It's not trivial to understand how the edit-config > operation is supposed to be used without knowledge of the data > model. For example, the first example in 7.2 is > > Set the MTU to 1500 on an interface named "Ethernet0/0" in > the running configuration: > > > Ethernet0/0 > 1500 > > > In this example, the manager has to know that the of an > interface is used as a key (or index) by the agent. If the same > command was issued to an agent which had the as key (not > very realistic of course), the result had been quite different! > > In fact, does the 'merge' operation make sense at all unless the > manager knows which element(s) are used as key/index? And if > there are no keys, does 'merge' mean anything? > > Again, I understand that the draft defines the protocol and not > the model, but I think it would be helpful to at least make a > note of the problem, and that this has to be solved by > implementations (and/or the netconf modelling effort). > > How much should a manager application be able to do without knowledge of the underlying networking technology being managed? How much can it do without even loading the domain-specific schema? The human operator sure knows that 'name' is the key, not 'mtu', so what's the best way to document that in the schema? Should there be any PDU tagging to help applications process PDUs without needing to load a schema? (I think OASIS has made good progress in this area, so we may want to look closely at their work.) In your example, it seems the manager has no schema loaded, or you have a schema but you want a standard way to identify instances. I think netconfmodel is supposed to address this issue. > >/martin > > > Andy -- 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 Tue Oct 25 14:15:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTKy-0002b4-IY for netconf-archive@megatron.ietf.org; Tue, 25 Oct 2005 14:15:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10147 for ; Tue, 25 Oct 2005 14:15:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUTCc-000Ad7-OR for netconf-data@psg.com; Tue, 25 Oct 2005 18:07:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.161] (helo=swip.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUTCZ-000Act-Ce for netconf@ops.ietf.org; Tue, 25 Oct 2005 18:07:12 +0000 X-T2-Posting-ID: P5HZhTV1iTSvFccgWTR5dA== Received: from [213.100.166.180] (HELO localhost) by mailfe06.swip.net (CommuniGate Pro SMTP 4.3.8) with ESMTP id 10493183; Tue, 25 Oct 2005 20:06:46 +0200 Date: Tue, 25 Oct 2005 20:06:40 +0200 (CEST) Message-Id: <20051025.200640.11636521.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: comments on draft-ietf-netconf-prot-09 From: Martin Bjorklund In-Reply-To: <435E5E44.3090300@andybierman.com> References: <20051024.233419.45505395.mbj@tail-f.com> <435E5E44.3090300@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > IMO we can't write a super-detailed elements of procedure without knowing > many or all the problems areas, i.e., same input on 2 boxes that supposedly > support the same data model produce different sets of elements. > We need real data from real implementations, indicating interoperability > problems. I was more thinking of errors in the protocol, not data-model related errors. As an example, I have to produce some error message if someone tries to get-config the candidate configuration, if my implementation does not support it. Maybe operation-not-supported? Maybe unknown-element? Maybe your intention is that it doesn't really matter and that it's up to the implementation. I'm just saying that some guidelines would help. > Side bar: We need a monitoring module for NETCONF, especially in > the early days, to debug the protocol. I'm working on a set of counters > (rpcs-rcvd, rpc-replies-sent, rpc-parse-errors, bad-hello-msgs-received, > etc.). > I would really appreciate your input (and all fellow implementors) on this > initial set of counters. Are these supposed to be readable through netconf, i.e. like a SNMPv2-MIB for SNMP? How will you specify these objects? Using netconfmodel's guidelines? > > 4. I understand the separation between the protocol and the > > underlying application data model. But wouldn't it make sense > > to state when the result of an operation depends on the data > > model? It's not trivial to understand how the edit-config > > operation is supposed to be used without knowledge of the data > > model. For example, the first example in 7.2 is > > > > Set the MTU to 1500 on an interface named "Ethernet0/0" in > > the running configuration: > > > > > > Ethernet0/0 > > 1500 > > > > > > In this example, the manager has to know that the of an > > interface is used as a key (or index) by the agent. If the same > > command was issued to an agent which had the as key (not > > very realistic of course), the result had been quite different! > > > > In fact, does the 'merge' operation make sense at all unless the > > manager knows which element(s) are used as key/index? And if > > there are no keys, does 'merge' mean anything? > > > > Again, I understand that the draft defines the protocol and not > > the model, but I think it would be helpful to at least make a > > note of the problem, and that this has to be solved by > > implementations (and/or the netconf modelling effort). > > > > > > How much should a manager application be able to do without knowledge > of the underlying networking technology being managed? How much can > it do without even loading the domain-specific schema? I think it's reasonable that the manager loads the domain-specific schema in order to do useful work. > In your example, it seems the manager has no schema loaded, > or you have a schema but you want a standard way to identify instances. Well, yes I would like that, but that wasn't my point - I just think it would be helpful if the document mentioned that the semantics of the edit-config operation is dependant on the data model. Unlike the other operations. I have another comment which I forgot yesterday. I think the text about the startup and running configurations could be improved. I did not understand what a startup configuration was until I searched the archives and found a good explanation. /martin -- 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 Tue Oct 25 20:33:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZEg-0003qx-G6 for netconf-archive@megatron.ietf.org; Tue, 25 Oct 2005 20:33:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09563 for ; Tue, 25 Oct 2005 20:33:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUZ86-000Dqj-6z for netconf-data@psg.com; Wed, 26 Oct 2005 00:26:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EUZ84-000DqY-V0 for netconf@ops.ietf.org; Wed, 26 Oct 2005 00:26:57 +0000 Received: (qmail 9438 invoked by uid 78); 26 Oct 2005 00:26:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.51 with SMTP; 26 Oct 2005 00:26:56 -0000 Message-ID: <435ECD4D.1060103@andybierman.com> Date: Tue, 25 Oct 2005 17:26:53 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: comments on draft-ietf-netconf-prot-09 References: <20051024.233419.45505395.mbj@tail-f.com> <435E5E44.3090300@andybierman.com> <20051025.200640.11636521.mbj@tail-f.com> In-Reply-To: <20051025.200640.11636521.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >Andy Bierman wrote: > > >>IMO we can't write a super-detailed elements of procedure without knowing >>many or all the problems areas, i.e., same input on 2 boxes that supposedly >>support the same data model produce different sets of elements. >>We need real data from real implementations, indicating interoperability >>problems. >> >> > >I was more thinking of errors in the protocol, not data-model related >errors. As an example, I have to produce some error message if >someone tries to get-config the candidate configuration, if my >implementation does not support it. Maybe operation-not-supported? >Maybe unknown-element? Maybe your intention is that it doesn't really >matter and that it's up to the implementation. I'm just saying that >some guidelines would help. > > In this case, there are plenty of standard error codes to choose from. and that's the problem. There are 3 error-tags that apply: Tag: invalid-value Error-type: protocol, application Severity: error Error-info: none Description: The request specifies an unacceptable value for one or more parameters. Tag: operation-not-supported Error-type: rpc, protocol, application Severity: error Error-info: none Description: Request could not be completed because the requested operation is not supported by this implementation. Tag: bad-element Error-type: rpc, protocol, application Severity: error Error-info: : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch IMO, 'invalid-value' is most correct, by process of elimination. Operation-not-supported is meant to apply to protocol operations, data-specific RPCs, etc. so that's not it. Bad element applies to schema errors, value-range errors, etc. Since 'candidate' is a valid value, this can't be it either. I agree with you that we would benefit from from developer documentation that made it easy to decide which error to use in every possible case. > > >>Side bar: We need a monitoring module for NETCONF, especially in >>the early days, to debug the protocol. I'm working on a set of counters >>(rpcs-rcvd, rpc-replies-sent, rpc-parse-errors, bad-hello-msgs-received, >>etc.). >>I would really appreciate your input (and all fellow implementors) on this >>initial set of counters. >> >> > >Are these supposed to be readable through netconf, i.e. like a >SNMPv2-MIB for SNMP? How will you specify these objects? Using >netconfmodel's guidelines? > > Yes, readable through the operation. I don't know about the documentation format -- I suppose XSD because I already kind of know that. > > > >>> 4. I understand the separation between the protocol and the >>> underlying application data model. But wouldn't it make sense >>> to state when the result of an operation depends on the data >>> model? It's not trivial to understand how the edit-config >>> operation is supposed to be used without knowledge of the data >>> model. For example, the first example in 7.2 is >>> >>> Set the MTU to 1500 on an interface named "Ethernet0/0" in >>> the running configuration: >>> >>> >>> Ethernet0/0 >>> 1500 >>> >>> >>> In this example, the manager has to know that the of an >>> interface is used as a key (or index) by the agent. If the same >>> command was issued to an agent which had the as key (not >>> very realistic of course), the result had been quite different! >>> >>> In fact, does the 'merge' operation make sense at all unless the >>> manager knows which element(s) are used as key/index? And if >>> there are no keys, does 'merge' mean anything? >>> >>> Again, I understand that the draft defines the protocol and not >>> the model, but I think it would be helpful to at least make a >>> note of the problem, and that this has to be solved by >>> implementations (and/or the netconf modelling effort). >>> >>> >>> >>> >>How much should a manager application be able to do without knowledge >>of the underlying networking technology being managed? How much can >>it do without even loading the domain-specific schema? >> >> > >I think it's reasonable that the manager loads the domain-specific >schema in order to do useful work. > > > >>In your example, it seems the manager has no schema loaded, >>or you have a schema but you want a standard way to identify instances. >> >> > >Well, yes I would like that, but that wasn't my point - I just think >it would be helpful if the document mentioned that the semantics of >the edit-config operation is dependant on the data model. Unlike the >other operations. > > I think it does in the discussion of the 'operation' attribute, but it's probably not that clear. I KNOW it's not apparent from the text that implementing edit-config and the operation attribute in a nested, modular, yet completely automated fashion is non-trivial. :-) :-) >I have another comment which I forgot yesterday. I think the text >about the startup and running configurations could be improved. I did >not understand what a startup configuration was until I searched the >archives and found a good explanation. > > okay -- here is the text in question: 5.1: Running Config o Running: The complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present. NETCONF protocol operations refer to this datastore using the element. 8.7.1: Distinct Startup The device supports separate running and startup configuration datastores. Operations which affect the running configuration will not be automatically copied to the startup configuration. An explicit operation from the to the must be invoked to update the startup configuration to the current contents of the running configuration. NETCONF protocol operations refer to the startup datastore using the element. How can we make this more clear? I guess it doesn't actually say in 8.7.1 that is the configuration that will be used upon the next startup of the device. I guess it shows that the authors were pretty familiar with router CLI configuration and may assume too often that these are well-understood terms and concepts. > >/martin > > Andy > >-- >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 Thu Oct 27 11:10:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9OJ-0002KA-9Y for netconf-archive@megatron.ietf.org; Thu, 27 Oct 2005 11:10:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08639 for ; Thu, 27 Oct 2005 11:09:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV9Ft-000MP7-D3 for netconf-data@psg.com; Thu, 27 Oct 2005 15:01:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV9Fp-000MOq-2c for netconf@ops.ietf.org; Thu, 27 Oct 2005 15:01:21 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9RF1H016243 for ; Thu, 27 Oct 2005 11:01:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5DB07.43D220EC" Subject: FW: I-D ACTION:draft-chisholm-netconf-event-01.txt Date: Thu, 27 Oct 2005 11:01:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405731FC8@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-chisholm-netconf-event-01.txt Thread-Index: AcXbBjmoS9IcfvCPQumDkoJbzXrsYAAABcOA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DB07.43D220EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi This updates contains some general cleanup and correction: capabilities, the named profile attribute, discussion about querying subscription properties and more. Also added are some non-normative appendices - Specific discussion on configuration events - discussion on potential event message content - interworking with syslog - design alternatives (call-home; persistence) Sharon -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, October 27, 2005 10:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-chisholm-netconf-event-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Netconf Event Messages Author(s) : S. Chisholm, et al. Filename : draft-chisholm-netconf-event-01.txt Pages : 41 Date : 2005-10-27 =09 This memo defines a framework for sending asynchronous messages, or event messages in Netconf. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to application protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chisholm-netconf-event-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chisholm-netconf-event-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-chisholm-netconf-event-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 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_01C5DB07.43D220EC Content-Type: application/octet-stream; name="ATT638746.TXT" Content-Description: ATT638746.TXT Content-Disposition: attachment; filename="ATT638746.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS0xMC0yNzEwMDU0MC5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGlzaG9sbS1uZXRjb25m LWV2ZW50LTAxLnR4dA0K ------_=_NextPart_001_01C5DB07.43D220EC Content-Type: application/octet-stream; name="draft-chisholm-netconf-event-01.URL" Content-Description: draft-chisholm-netconf-event-01.URL Content-Disposition: attachment; filename="draft-chisholm-netconf-event-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1jaGlzaG9sbS1uZXRjb25mLWV2ZW50LTAxLnR4dA0K ------_=_NextPart_001_01C5DB07.43D220EC Content-Type: text/plain; name="ATT638747.txt" Content-Description: ATT638747.txt Content-Disposition: attachment; filename="ATT638747.txt" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C5DB07.43D220EC-- -- 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 Mon Oct 31 05:34:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWWzY-0004M2-3y for netconf-archive@megatron.ietf.org; Mon, 31 Oct 2005 05:34:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27853 for ; Mon, 31 Oct 2005 05:33:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWWrf-000GmP-UZ for netconf-data@psg.com; Mon, 31 Oct 2005 10:26:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWWre-000GmC-Hs for netconf@ops.ietf.org; Mon, 31 Oct 2005 10:26:06 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2574553952 for ; Mon, 31 Oct 2005 11:26:05 +0100 (CET) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id 627CF5394C for ; Mon, 31 Oct 2005 11:26:04 +0100 (CET) Message-ID: <4365F185.6040302@loria.fr> Date: Mon, 31 Oct 2005 11:27:17 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Subtree filtering question Content-Type: multipart/mixed; boundary="------------090802080803050801000708" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------090802080803050801000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have some questions about subtree filtering process in Netconf. How do I select with subtree filtering only users (with all their information) which belong to dept 3 ? In Xpath, it will be /top/users/user[company-info/dept='3']. I was thinking of the following request but I feel like it will select all users and will simply discard the company-info node when dept is not 3. 3 Is it right to say that a node (like for example user) can only be discarded by a content match node which is a direct child of it (but not by a child which is two levels or more under the considered node) ? Another comment is that, in xpath capability, it would be great to specify how namespaces and context prefix are handled, as it has been done for subtree filtering. Thanks, Vincent --------------090802080803050801000708 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Disposition: attachment; filename="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------090802080803050801000708-- -- 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: