From owner-netconf@ops.ietf.org Fri Jul 01 03:24:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoFsY-0002Z4-Lf for netconf-archive@megatron.ietf.org; Fri, 01 Jul 2005 03:24: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 DAA01841 for ; Fri, 1 Jul 2005 03:23:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoFgl-000Naj-IY for netconf-data@psg.com; Fri, 01 Jul 2005 07:11:51 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Do7r9-0009K1-LF for netconf@ops.ietf.org; Thu, 30 Jun 2005 22:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Do7r8-0002Q8-M5; Thu, 30 Jun 2005 18:50:02 -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-07.txt Message-Id: Date: Thu, 30 Jun 2005 18:50:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 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-07.txt Pages : 96 Date : 2005-6-30 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-07.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-07.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-07.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-6-30170855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-prot-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-prot-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-30170855.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 Fri Jul 01 14:24:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQC4-00006F-AO for netconf-archive@megatron.ietf.org; Fri, 01 Jul 2005 14:24: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 OAA25547 for ; Fri, 1 Jul 2005 14:24:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoQ13-0001ip-B4 for netconf-data@psg.com; Fri, 01 Jul 2005 18:13:29 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoQ11-0001ia-R7 for netconf@ops.ietf.org; Fri, 01 Jul 2005 18:13:27 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 01 Jul 2005 11:13:26 -0700 X-IronPort-AV: i="3.93,251,1115017200"; d="scan'208"; a="195905234:sNHT3165058070" Received: from [171.69.35.31] (dhcp-171-69-35-31.cisco.com [171.69.35.31]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61IDMvM025253 for ; Fri, 1 Jul 2005 11:13:23 -0700 (PDT) Message-ID: <42C587C0.1080201@cisco.com> Date: Fri, 01 Jul 2005 11:13:20 -0700 From: "Kenneth V. Crozier" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: netconf@ops.ietf.org Subject: Scalability of Netconf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I was thinking about the scalability of Netconf, i know we talked about=20 this a long time ago. And i dont remember what the outcome of it was.=20 The draft talks about netconf sessions being long lived, but that's=20 about it. What i'm concerned with is how many connections a NM station would have=20 to maintain, and by this are we raising the bar for storage and=20 processor requirements of the NM station. My immediate thoughts are that = this would be a netconf over x issue and not something for the netconf=20 protocol. Is, this something we should be talking about for a 2.0 phase=20 of the WG Sl=E1inte Ken -- 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 Jul 01 14:47:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQXt-00048V-T7 for netconf-archive@megatron.ietf.org; Fri, 01 Jul 2005 14:47: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 OAA27815 for ; Fri, 1 Jul 2005 14:47:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoQT5-0003n4-3s for netconf-data@psg.com; Fri, 01 Jul 2005 18:42:27 +0000 Received: from [207.69.195.104] (helo=fall-pradero.atl.sa.earthlink.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DoQSz-0003mE-BA for netconf@ops.ietf.org; Fri, 01 Jul 2005 18:42:21 +0000 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by fall-pradero.atl.sa.earthlink.net with esmtp (Exim 3.36 #4) id 1DnjUl-0000pW-00 for netconf@ops.ietf.org; Wed, 29 Jun 2005 16:49:19 -0400 Received: from h-68-165-4-178.snvacaid.dynamic.covad.net ([68.165.4.178] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DnjUi-0001cx-00 for netconf@ops.ietf.org; Wed, 29 Jun 2005 16:49:16 -0400 Message-ID: <002101c57cec$904fc480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B403F714C3@zcarhxm2.corp.nortel.com> Subject: Re: NETCONF interop event in Paris Date: Wed, 29 Jun 2005 13:53:11 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - The event seems a good idea, but its timing, in the absence of a netwconf WG session, seems at odds with the spirit of http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt Shouldn't there be a scheduled WG session in Paris to discuss the oucome of the interop event? Randy > From: Cristian Cadar > Sent: Fri 6/3/2005 5:46 PM > To: netconf@ops.ietf.org > Subject: NETCONF interop event in Paris > > Dear all, > > The WG last call on our documents will be closed soon. The documents are > mature enough for a first interoperability testing. On the three days before > the IETF meeting in Paris there will be a first NETCONF interoperability > testing event at the same location as the IETF meeting. It is hosted by two > European research projects and by ETSI. Participation is free of charge. > > The event will give us valuable feedback on ambiguities and missing > clarifications in our NETCONF documents. > > Everybody who already has an implementation of NETCONF is very welcome. > Let's see how many independent implementations are already out there. > > Please find a preliminary announcement at > http://www.ist-mome.org/events/interop/. > > Relevant draft documents include: > > - "draft-ietf-netconf-prot-06" > - "draft-ietf-netconf-beep-05" > - "draft-ietf-netconf-soap-05" > - "draft-ietf-netconf-ssh-04" > > Also there are no description of test cases available, yet. These will be > provided until mid of June on the same web page. > > > Best Regards, > > Cristian Cadar > NEC Europe Ltd ... -- 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 Jul 01 15:13:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQwp-0002fa-Uu for netconf-archive@megatron.ietf.org; Fri, 01 Jul 2005 15:13:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00950 for ; Fri, 1 Jul 2005 15:13:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoQsD-0006D3-1L for netconf-data@psg.com; Fri, 01 Jul 2005 19:08:25 +0000 Received: from [207.69.195.103] (helo=fall-lakeland.atl.sa.earthlink.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DoQsA-0006Bl-4T for netconf@ops.ietf.org; Fri, 01 Jul 2005 19:08:22 +0000 Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by fall-lakeland.atl.sa.earthlink.net with esmtp (Exim 3.36 #4) id 1Do4tW-00088U-00 for netconf@ops.ietf.org; Thu, 30 Jun 2005 15:40:18 -0400 Received: from h-64-105-136-215.snvacaid.dynamic.covad.net ([64.105.136.215] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Do4tV-0007aW-00 for netconf@ops.ietf.org; Thu, 30 Jun 2005 15:40:18 -0400 Message-ID: <000801c57dac$1771ad60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: Proposed Update to Netconf Charter Date: Thu, 30 Jun 2005 12:44:11 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Romascanu, Dan (Dan)" > To: ; "Sharon Chisholm" > Cc: > Sent: Thursday, June 30, 2005 9:27 AM > Subject: RE: Proposed Update to Netconf Charter ... > I agree with Juergen on this. In an ideal world I would see the issue of > access control being dealt with in a common framework with isms, but I > am quite uncertain right now about where isms is - even with respect to > its initial goals. ... The only bits to worry about from isms are whether the identification of principals and security levels will be compatible with existing SNMP security models, along with whatever configuration data is needed to support the use of the new security model(s). I'm increasingly doubtful that we'll ever see vendor-neutral mappings between SNMP contexts and OID regions to things in netconf-land, much less a way of ensuring that netconf security policies and, for example, VACM policies are logically consistent. To make this practical, we'd need an an algorithmic way to relate arbitrary vendor-specific chunks of XML to constellations of SMI objects. Even if fancy XSLTs might do the job, who would actually write these things? However, those aren't specifically isms issues. The current isms charter makes a point of not addressing access control. Short of starting a new WG, the place to do the netconf access control work is here in netconf, unless we just leave it to the vendors as a means of product differentiation. Randy -- 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 Jul 01 21:09:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoWVH-0002EH-UN for netconf-archive@megatron.ietf.org; Fri, 01 Jul 2005 21:09:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14903 for ; Fri, 1 Jul 2005 21:09:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoWK0-000EY6-Di for netconf-data@psg.com; Sat, 02 Jul 2005 00:57:28 +0000 Received: from [207.69.195.105] (helo=fall-curlleaf.atl.sa.earthlink.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DoWJx-000EXG-EH for netconf@ops.ietf.org; Sat, 02 Jul 2005 00:57:25 +0000 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by fall-curlleaf.atl.sa.earthlink.net with esmtp (Exim 3.36 #4) id 1DnjOY-0002QQ-00 for netconf@ops.ietf.org; Wed, 29 Jun 2005 16:42:54 -0400 Received: from h-68-165-4-178.snvacaid.dynamic.covad.net ([68.165.4.178] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DnjOX-0007Ej-00 for netconf@ops.ietf.org; Wed, 29 Jun 2005 16:42:53 -0400 Message-ID: <001c01c57ceb$abc37780$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B403F714AF@zcarhxm2.corp.nortel.com> Subject: Re: Proposed Update to Netconf Charter Date: Wed, 29 Jun 2005 13:46:47 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Sharon Chisholm" > To: > Sent: Wednesday, June 29, 2005 1:33 PM > Subject: Proposed Update to Netconf Charter ... > As promised, here are the proposed updates to the Netconf charter to cover > the work coming down the pipe: > > "Additional phase 2 work including: > > - Requirements and Guidelines for defining Netconf content to enable > interoperable, high-quality and usable netconf implementations. Requirements > will be defined around specification language, access control, compliance, > backwards compatibility, depicting relationships, event specification, and > application error message specification. > > - An initial set of application-level re-usable data types such as IP > Addresses, MAC addresses, etc. This definition would be compliant to the > above defined requirements and guidelines for Netconf content. > > - An XML Schema for reporting information about the Netconf system. This > definition would be compliant to the above defined requirements and > guidelines for Netconf content. > > - A netconf protocol specification for asynchronous messaging to enable the > sending of events. This must preserve the netconf layers." ... I'm glad to see access control mentioned. Is the intent to define an interoperable access control policy representation? Randy -- 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 Jul 01 23:58:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoZ9L-0006OL-BM for netconf-archive@megatron.ietf.org; Fri, 01 Jul 2005 23:58:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05981 for ; Fri, 1 Jul 2005 23:58:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoZ3P-0001HO-T9 for netconf-data@psg.com; Sat, 02 Jul 2005 03:52:31 +0000 Received: from [85.73.187.100] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoZ3M-0001Gv-Ud for netconf@ops.ietf.org; Sat, 02 Jul 2005 03:52:29 +0000 Received: by boskop.local (Postfix, from userid 501) id 00F3435457C; Sat, 2 Jul 2005 05:52:27 +0200 (CEST) Date: Sat, 2 Jul 2005 05:52:27 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Cc: netconf@ops.ietf.org Subject: Re: NETCONF interop event in Paris Message-ID: <20050702035227.GA816@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Randy Presuhn , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B403F714C3@zcarhxm2.corp.nortel.com> <002101c57cec$904fc480$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101c57cec$904fc480$7f1afea9@oemcomputer> User-Agent: Mutt/1.5.8i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jun 29, 2005 at 01:53:11PM -0700, Randy Presuhn wrote: > Shouldn't there be a scheduled WG session in Paris to discuss > the oucome of the interop event? A session to discuss the outcome of an interop event?? The details will be under non-disclosure anyway. A simple email summarizing the event and any insights gained posted to the WG list is IMHO sufficient to keep the WG informed. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Sat Jul 02 00:09:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoZJm-00049f-J7 for netconf-archive@megatron.ietf.org; Sat, 02 Jul 2005 00:09:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06540 for ; Sat, 2 Jul 2005 00:09:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoZG5-0002a7-9f for netconf-data@psg.com; Sat, 02 Jul 2005 04:05:37 +0000 Received: from [85.73.187.100] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoZG4-0002Zt-JF for netconf@ops.ietf.org; Sat, 02 Jul 2005 04:05:36 +0000 Received: by boskop.local (Postfix, from userid 501) id 068BD3545EC; Sat, 2 Jul 2005 06:05:35 +0200 (CEST) Date: Sat, 2 Jul 2005 06:05:35 +0200 From: Juergen Schoenwaelder To: "Kenneth V. Crozier" Cc: netconf@ops.ietf.org Subject: Re: Scalability of Netconf Message-ID: <20050702040535.GC816@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Kenneth V. Crozier" , netconf@ops.ietf.org References: <42C587C0.1080201@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C587C0.1080201@cisco.com> User-Agent: Mutt/1.5.8i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jul 01, 2005 at 11:13:20AM -0700, Kenneth V. Crozier wrote: > What i'm concerned with is how many connections a NM station would have > to maintain, and by this are we raising the bar for storage and > processor requirements of the NM station. If I buy a machine for say 1.000 Euros and put Linux or BSD on it. What do you think how many TCP connections I can maintain with such a box? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Sat Jul 02 00:31:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoZfU-0007Qn-5U for netconf-archive@megatron.ietf.org; Sat, 02 Jul 2005 00:31: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 AAA07910 for ; Sat, 2 Jul 2005 00:31:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoZb2-00043K-1e for netconf-data@psg.com; Sat, 02 Jul 2005 04:27:16 +0000 Received: from [85.73.187.100] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoZb0-000432-9B for netconf@ops.ietf.org; Sat, 02 Jul 2005 04:27:14 +0000 Received: by boskop.local (Postfix, from userid 501) id 453743546DB; Sat, 2 Jul 2005 06:27:12 +0200 (CEST) Date: Sat, 2 Jul 2005 06:27:11 +0200 From: Juergen Schoenwaelder To: "Kenneth V. Crozier" , netconf@ops.ietf.org Subject: Re: Scalability of Netconf Message-ID: <20050702042711.GD816@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Kenneth V. Crozier" , netconf@ops.ietf.org References: <42C587C0.1080201@cisco.com> <20050702040535.GC816@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050702040535.GC816@boskop.local> User-Agent: Mutt/1.5.8i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Sat, Jul 02, 2005 at 06:05:35AM +0200, Juergen Schoenwaelder wrote: > On Fri, Jul 01, 2005 at 11:13:20AM -0700, Kenneth V. Crozier wrote: > > > What i'm concerned with is how many connections a NM station would have > > to maintain, and by this are we raising the bar for storage and > > processor requirements of the NM station. > > If I buy a machine for say 1.000 Euros and put Linux or BSD on it. What > do you think how many TCP connections I can maintain with such a box? Actually, I should have said ssh connections. BTW, this is not a terrible difficult experiment to do so I might even do this excercise next week if anyone really cares about numbers. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 04 13:28:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpUkP-0001tN-AX for netconf-archive@megatron.ietf.org; Mon, 04 Jul 2005 13:28: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 NAA15762 for ; Mon, 4 Jul 2005 13:28:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpUc3-000Ixu-0L for netconf-data@psg.com; Mon, 04 Jul 2005 17:20:07 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DpUby-000Ivy-Si for netconf@ops.ietf.org; Mon, 04 Jul 2005 17:20:03 +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 j64HIjX21692 for ; Mon, 4 Jul 2005 13:18:45 -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: Scalability of Netconf Date: Mon, 4 Jul 2005 13:19:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> Thread-Topic: Scalability of Netconf Thread-Index: AcV+vxIW+gb44F+HTRC6YMjc1GQK2QB+7Cjw From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi These would be interesting numbers to get. I've heard related (but opposite?) concerns around being able to get the most out of each netconf connection to ensure that more complex deployments don't max out on connections. This might eventually require us to continue the channelization discussions which was mainly deferred, but I think that can wait a bit. First step would be to determine if this is really an issue in practice. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Saturday, July 02, 2005 12:27 AM To: Kenneth V. Crozier; netconf@ops.ietf.org Subject: Re: Scalability of Netconf On Sat, Jul 02, 2005 at 06:05:35AM +0200, Juergen Schoenwaelder wrote: > On Fri, Jul 01, 2005 at 11:13:20AM -0700, Kenneth V. Crozier wrote: >=20 > > What i'm concerned with is how many connections a NM station would=20 > > have > > to maintain, and by this are we raising the bar for storage and=20 > > processor requirements of the NM station. >=20 > If I buy a machine for say 1.000 Euros and put Linux or BSD on it.=20 > What do you think how many TCP connections I can maintain with such a=20 > box? Actually, I should have said ssh connections. BTW, this is not a=20 terrible difficult experiment to do so I might even do this excercise next week if anyone really cares about numbers. /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 05 10:09:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpo6v-0004IF-Ho for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 10:09: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 KAA26371 for ; Tue, 5 Jul 2005 10:09:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dpo11-000Hbm-Ps for netconf-data@psg.com; Tue, 05 Jul 2005 14:03:11 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dpo10-000HbS-N1 for netconf@ops.ietf.org; Tue, 05 Jul 2005 14:03:11 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4C55639A3F; Tue, 5 Jul 2005 16:03:10 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13114-06; Tue, 5 Jul 2005 16:03:08 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3E736399CA; Tue, 5 Jul 2005 16:03:09 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 963CC358050; Tue, 5 Jul 2005 16:03:08 +0200 (CEST) Date: Tue, 5 Jul 2005 16:03:08 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: Scalability of Netconf Message-ID: <20050705140308.GB4704@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de References: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> <20050705140117.GA4704@boskop.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20050705140117.GA4704@boskop.local> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 05, 2005 at 04:01:17PM +0200, Juergen Schoenwaelder wrote: > P.S. Attached is the ugly quick and dirty script - I am sorry for > using Tcl and not Perl - I am sure Perl will make this faster. :-) Sorry, as usual I forgot to attach... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --/9DWx/yDrRhgMJTb Content-Type: application/x-tcl Content-Disposition: attachment; filename="ssh-test.tcl" Content-Transfer-Encoding: quoted-printable #! /usr/bin/tclsh=0A=0Aset host $argv=0Aset msg "hello world"=0A=0Aproc deb= ug {msg} {=0A puts stderr $msg=0A}=0A=0Aproc test {f} {=0A global msg= =0A debug "testing $f"=0A puts $f $msg=0A flush $f=0A debug "+-= > write ok"=0A gets $f reply=0A if {[eof $f]} {=0A error "$f: unexpec= ted EOF - remote end gone away?"=0A }=0A debug "+-> gets ok"=0A if= {[string compare $msg $reply] !=3D 0} {=0A error "$f: comparison failed: $= msg !=3D $reply"=0A }=0A debug "+-> cmp ok"=0A return 1=0A}=0A=0Af= or {set i 1} {$i <=3D 50} {incr i} {=0A set f($i) [open "| ssh -s $host = cat" r+]=0A debug "opened $f($i)"=0A after 50=0A test $f($i)=0A}= =0A=0Afor {set l 0} {$l < 1000} {incr l} {=0A debug "sleeping"=0A aft= er 2000=0A foreach i [array names f] {=0A after 10=0A test $f($i)=0A = }=0A}=0A=0Aforeach i [array names f] {=0A debug "closing $f($i)"=0A c= atch {close $f($i)}=0A}=0A=0Aexit=0A --/9DWx/yDrRhgMJTb-- -- 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 Jul 05 10:09:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpo6x-0004KO-US for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 10:09:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26397 for ; Tue, 5 Jul 2005 10:09:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpnzK-000HPT-Sv for netconf-data@psg.com; Tue, 05 Jul 2005 14:01:26 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpnzH-000HOv-Ge for netconf@ops.ietf.org; Tue, 05 Jul 2005 14:01:24 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 790C739A47; Tue, 5 Jul 2005 16:01:21 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12790-09; Tue, 5 Jul 2005 16:01:19 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4703A39A3F; Tue, 5 Jul 2005 16:01:20 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 959E435802E; Tue, 5 Jul 2005 16:01:18 +0200 (CEST) Date: Tue, 5 Jul 2005 16:01:17 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: Scalability of Netconf Message-ID: <20050705140117.GA4704@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de References: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Jul 04, 2005 at 01:19:57PM -0400, Sharon Chisholm wrote: > These would be interesting numbers to get. I've heard related (but > opposite?) concerns around being able to get the most out of each > netconf connection to ensure that more complex deployments don't max out > on connections. This might eventually require us to continue the > channelization discussions which was mainly deferred, but I think that > can wait a bit. First step would be to determine if this is really an > issue in practice. I am not yet done with my experiments. So far, I have writen a script which connects to ssh subsystems I called cat: Subsystem cat /bin/cat The script kicks off a standard ssh client to connect to a remote cat subsystem and then starts a loop where it periodically sends a message and checks whether that is echoed back correctly. Nothing fancy. (Note that this script is rather heavy weight since it requires a new ssh process for each connection - a more serious implementation would require some C code so that you can keep multiple connections in one process.) I am running this script on a 3GHz Pentium with 512 MB Ram (so really nothing high end for a management system) running Linux 2.6.10. I keep 300 connections open and the funny thing is that this box does not at really get stressed by this. The load never went above 0.1% and was most of the time significantly below. The memory used excluding buffers was ~235 MB. Given that the script is really a crude resource hog, the box performed much better than expected. The next step is probably to shoot for 1000 ssh connections with this crude script. I just have to setup more cat subsystems to talk to... /js P.S. I admit that my Mac OS X notebook does not behave that friendly since I was simply running out of slots in the process table. ;-) P.S. Attached is the ugly quick and dirty script - I am sorry for using Tcl and not Perl - I am sure Perl will make this faster. :-) -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 05 12:24:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqDz-0005PA-Qu for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 12:24: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 MAA17247 for ; Tue, 5 Jul 2005 12:24:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dpq6w-0004dd-NN for netconf-data@psg.com; Tue, 05 Jul 2005 16:17:26 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dppuy-0003Yl-UR for netconf@ops.ietf.org; Tue, 05 Jul 2005 16:05:05 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 8F56B11DE30; Tue, 5 Jul 2005 09:05:00 -0700 (PDT) From: Wes Hardaker To: Sharon Chisholm Cc: netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: nmrgScalability of Netconf Organization: Sparta References: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> <20050705140117.GA4704@boskop.local> Date: Tue, 05 Jul 2005 09:04:58 -0700 In-Reply-To: <20050705140117.GA4704@boskop.local> (Juergen Schoenwaelder's message of "Tue, 5 Jul 2005 16:01:17 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Tue, 5 Jul 2005 16:01:17 +0200, Juergen Schoenwaelder said: Juergen> I am running this script on a 3GHz Pentium with 512 MB Ram Juergen> (so really nothing high end for a management system) running Juergen> Linux 2.6.10. I keep 300 connections open and the funny thing Juergen> is that this box does not at really get stressed by this. The Juergen> load never went above 0.1% and was most of the time Juergen> significantly below. The memory used excluding buffers was Juergen> ~235 MB. I'd expect the limiting fact in that to be the memory not the CPU speed. Machines of that caliber can handle huge numbers of web connections without blinking much. The number of TCP connections won't be the limiting factor at all, I don't think. The CPU speed will certainly be affected by the continuous stream of cryptographic connections, but unless you're doing something like using multiple clients connecting at once you have no way to be sure that the server is not the limiting factor there and not your client. -- Wes Hardaker Sparta, Inc. -- 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 Jul 05 12:34:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqNa-0001J7-2S for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 12:34: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 MAA18971 for ; Tue, 5 Jul 2005 12:34:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpqFs-0005Q1-B8 for netconf-data@psg.com; Tue, 05 Jul 2005 16:26:40 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DpqFr-0005Pj-5K for netconf@ops.ietf.org; Tue, 05 Jul 2005 16:26:39 +0000 Received: (qmail 4918 invoked by uid 78); 5 Jul 2005 16:26:38 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail7.netsol.inquent.com with SMTP; 5 Jul 2005 16:26:38 -0000 Message-ID: <42CAB4BD.4000608@andybierman.com> Date: Tue, 05 Jul 2005 09:26:37 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <713043CE8B8E1348AF3C546DBE02C1B403F714AF@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B403F714AF@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: I have some real concerns with the wording of this charter text, but rather than focus on that, let's just try to agree on a bullet list form of the charter. I would much rather see agreement on specific features first, (and then let people propose solutions, from which the WG may select starting points for 1 or more standard documents), rather than have the WG deal with an ad-hoc array of individual submissions, as they come in. [In the interest of transparency, I am posting my personal preferences for charter extensions] Clearly, the addition of notifications is important to many people, and its already in the charter, so that seems like a no-brainer. However, a clean solution across all application mappings was not achieved in the first attempt, so let's see what new ideas come in this time around.. I also think that core data types are critical. There is actually no reason whatsoever this document couldn't have been published years ago -- it has no coupling to NETCONF at all -- it is just more XSD types to NETCONF. Access control is also critical to get in place early on. I prefer to start simple and evolve the complexity over time. IMO, a mapping to ISMS should be a separate work effort, and probably in that WG. NETCONF AC is unique because it is both "RPC method" and document oriented. IMO, old approaches like VACM will be clumsy and/or bloated if applied to NETCONF. Some new innovation is required here. I am also interested in the "SW image load" channel that has been discussed in the past. Often config reloads are coupled with image reloads, and it would be nice if NETCONF could integrate some SW image management features to support this requirement. Andy >hi > >As promised, here are the proposed updates to the Netconf charter to cover >the work coming down the pipe: > >"Additional phase 2 work including: > >- Requirements and Guidelines for defining Netconf content to enable >interoperable, high-quality and usable netconf implementations. Requirements >will be defined around specification language, access control, compliance, >backwards compatibility, depicting relationships, event specification, and >application error message specification. > >- An initial set of application-level re-usable data types such as IP >Addresses, MAC addresses, etc. This definition would be compliant to the >above defined requirements and guidelines for Netconf content. > >- An XML Schema for reporting information about the Netconf system. This >definition would be compliant to the above defined requirements and >guidelines for Netconf content. > >- A netconf protocol specification for asynchronous messaging to enable the >sending of events. This must preserve the netconf layers." > > >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 Tue Jul 05 13:15:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpr1T-0002uK-10 for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 13:15:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25073 for ; Tue, 5 Jul 2005 13:15:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dpqmk-0009vN-3s for netconf-data@psg.com; Tue, 05 Jul 2005 17:00:38 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dpqmi-0009v0-0T for netconf@ops.ietf.org; Tue, 05 Jul 2005 17:00:36 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E5B3A39A44; Tue, 5 Jul 2005 19:00:34 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23577-06; Tue, 5 Jul 2005 19:00:34 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id C84B539A3B; Tue, 5 Jul 2005 19:00:33 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id D5D07358336; Tue, 5 Jul 2005 19:00:32 +0200 (CEST) Date: Tue, 5 Jul 2005 19:00:32 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Cc: Sharon Chisholm , nmrg@ibr.cs.tu-bs.de, netconf@ops.ietf.org Subject: Re: [nmrg] Re: nmrgScalability of Netconf Message-ID: <20050705170032.GD5516@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Wes Hardaker , Sharon Chisholm , nmrg@ibr.cs.tu-bs.de, netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> <20050705140117.GA4704@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jul 05, 2005 at 09:04:58AM -0700, Wes Hardaker wrote: > I'd expect the limiting fact in that to be the memory not the CPU > speed. Machines of that caliber can handle huge numbers of web > connections without blinking much. The number of TCP connections > won't be the limiting factor at all, I don't think. The CPU speed > will certainly be affected by the continuous stream of cryptographic > connections, but unless you're doing something like using multiple > clients connecting at once you have no way to be sure that the server > is not the limiting factor there and not your client. I totally agree - but we continue to hear stories of boxes dying with slightly more than a dozen IPsec associations. And I do know from experience that some OSes are not as scalable as some other OSes. Some OSes are rather good these days in dynamically allocating TCP control blocks and process table entries when needed. In the not so good old days, these things often had static limits you could run into. But this is mostly history now. I am actually not even sure memory is the issue - filling 512 MB (or you can easily and cheaply get 1GB or more these days) with ssh state data also requires rather poor implementations (like my stupid script for example). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 05 15:02:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpsgj-0001po-8z for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 15:02:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07729 for ; Tue, 5 Jul 2005 15:02:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpsWP-000KXU-Em for netconf-data@psg.com; Tue, 05 Jul 2005 18:51:53 +0000 Received: from [204.127.202.59] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpsWO-000KXD-MM for netconf@ops.ietf.org; Tue, 05 Jul 2005 18:51:52 +0000 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <20050705185151014004gef4e>; Tue, 5 Jul 2005 18:51:51 +0000 Reply-To: From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" Cc: Subject: RE: Proposed Update to Netconf Charter Date: Tue, 5 Jul 2005 14:51:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <42CAB4BD.4000608@andybierman.com> Thread-Index: AcWBf3JlXTZ/aAD/SZCHhM53VI2tGAAC/LBA X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Hi Andy, > Access control is also critical to get in place early on. > I prefer to start simple and evolve the complexity over time. > IMO, a mapping to ISMS should be a separate work effort, > and probably in that WG. > > NETCONF AC is unique because it is both "RPC method" and > document oriented. > IMO, old approaches like VACM will be clumsy and/or bloated if applied > to NETCONF. Some new innovation is required here. > I'm interested in your views about the uniqueness of netconf AC. In SNMPv3, as you know, we found that all operations could be abstracted into read/write/notify types of operations for purposes of AC. There was not a real need to distinguish between GET, GETBULK, and other proposed GET-XXXX operations. Do you see a real need to distinguish between the various RPC methods, etc., that would be initiated by an operator? In the SNMPv3 isAccessAllowed() ASI, variableName names the instance of the managed object. Would netconf use a similar (XML-based) variablename to identify the instance of the managed object? Do you expect that "documents" will be aggregations of objects that are not necessarily from the same XML subtree? I can see this if the document is an HTML web page; but if it is built from data elements defined as an XML instance, then would AC based on the underlying XML suffice? Cf: a varbind list with an aggregation of various managed objects. Do you have something different in mind for documents? In SNMPv3, we have contexts to differentiate MIB instances. I assume such a concept would also be needed for netconf. Do you agree? Is "running" and "candidate" about as deep as you need to go for netconf contexts, or do you need the greater depth found in the SNMP contexts? Do you anticipate a future need to be able to configure, for example, the XML instance for a specific blade in a server? I'm interested in your thoughts on this because VACM has not gained very wide acceptance, and a simpler AC model that could be used with both netconf's XML hierarchical naming scheme and SNMP's OID hierarchical naming scheme (or an XML-based SNMP naming scheme) could help both protocols. I'm also interested in probing how the requirements for netconf AC and SNMP AC might differ, since this could also have an impact on whether ISMS design should even try to be future-compatible with netconf. David Harrington dbharrington@comcast.net -- 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 Jul 05 15:19:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpsxL-0005NY-Td for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 15:19:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10847 for ; Tue, 5 Jul 2005 15:19:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dpssw-000N3A-EJ for netconf-data@psg.com; Tue, 05 Jul 2005 19:15:10 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Dpsst-000N2q-P1 for netconf@ops.ietf.org; Tue, 05 Jul 2005 19:15:07 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j65JEc934622; Tue, 5 Jul 2005 12:14:38 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j65JEWj64702; Tue, 5 Jul 2005 12:14:32 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id j65JK0YE053393; Tue, 5 Jul 2005 15:20:00 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200507051920.j65JK0YE053393@idle.juniper.net> To: j.schoenwaelder@iu-bremen.de cc: Wes Hardaker , Sharon Chisholm , nmrg@ibr.cs.tu-bs.de, netconf@ops.ietf.org Subject: Re: [nmrg] Re: nmrgScalability of Netconf In-Reply-To: Your message of "Tue, 05 Jul 2005 19:00:32 +0200." <20050705170032.GD5516@boskop.local> Date: Tue, 05 Jul 2005 15:20:00 -0400 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Juergen Schoenwaelder writes: >filling 512 MB (or >you can easily and cheaply get 1GB or more these days) with ssh state >data also requires rather poor implementations (like my stupid script >for example). Or the use of java ;^)/2 Thanks, Phil -- 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 Jul 05 16:59:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpuVy-0007cL-Ou for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 16:59:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26008 for ; Tue, 5 Jul 2005 16:59:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpuQd-0005kp-9o for netconf-data@psg.com; Tue, 05 Jul 2005 20:54:03 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DpuQc-0005kb-Er for netconf@ops.ietf.org; Tue, 05 Jul 2005 20:54:02 +0000 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j65KrxLb016934; Tue, 5 Jul 2005 13:53:59 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j65Krstt027416; Tue, 5 Jul 2005 13:53:54 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j65Krs7k027412; Tue, 5 Jul 2005 13:53:54 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 5 Jul 2005 13:53:54 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington cc: "'Andy Bierman'" , "'Sharon Chisholm'" , netconf@ops.ietf.org Subject: RE: Proposed Update to Netconf Charter In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, Two specific items... 1) I don't see the need for contexts in NETCONF data modeling, since contexts are simply "a mechanism to add extra indexing when the MIB designer failed to predict the future evolution of technology" (or bandaid for poor MIB design). With XML, I don't really believe this limitation is present, and, thus, a "context" will not be needed. 2) SNMP VACM access control is based on 1) the identication of the management information (the variable name) 2) the operation type (read/write/notify) 3) the security model 4) the security level 5) the context 6) the group It doesn't depend on the value of object instance. This has resulted in MIB design patterns where objects are made (unnaturally) into index object(s). The usual case is where the security name (or group name) is made into an index. Many other systems, especially data base systems have access control based on data values. In the work that I have done explaining VACM, the concept that what security level is used can affect what can be accessed is always a very big surprise. So far, there is a single security model. If several were present, then the number of entries in the VACM table could increase by a factor of the number. In general, the SNMP acess model is unlike anything that most users are use to. Thus, they can not understand it, and its richness is typically never used. It is also typically not used because the objects used by management apps are not typically characterized. Thus, most systems that I've seen provide no restriction to management platforms, and any restriction is done by a management platform as to which management applications any specific user can run. Thus, I would characterize VACM as completely missing the target. It is too complex for typical usage, and not rich enough for realworld usage. Regards, /david t. perkins On Tue, 5 Jul 2005, David B Harrington wrote: > Hi Andy, > > > Access control is also critical to get in place early on. > > I prefer to start simple and evolve the complexity over time. > > IMO, a mapping to ISMS should be a separate work effort, > > and probably in that WG. > > > > NETCONF AC is unique because it is both "RPC method" and > > document oriented. > > IMO, old approaches like VACM will be clumsy and/or bloated if > applied > > to NETCONF. Some new innovation is required here. > > > > I'm interested in your views about the uniqueness of netconf AC. > > In SNMPv3, as you know, we found that all operations could be > abstracted into read/write/notify types of operations for purposes of > AC. There was not a real need to distinguish between GET, GETBULK, and > other proposed GET-XXXX operations. Do you see a real need to > distinguish between the various RPC methods, etc., that > would be initiated by an operator? > > In the SNMPv3 isAccessAllowed() ASI, variableName names the instance > of the managed object. Would netconf use a similar (XML-based) > variablename to identify the instance of the managed object? > > Do you expect that "documents" will be aggregations of objects that > are not necessarily from the same XML subtree? I can see this if the > document is an HTML web page; but if it is built from data elements > defined as an XML instance, then would AC based on the underlying XML > suffice? Cf: a varbind list with an aggregation of various managed > objects. Do you have something different in mind for documents? > > In SNMPv3, we have contexts to differentiate MIB instances. I assume > such a concept would also be needed for netconf. Do you agree? Is > "running" and "candidate" about as deep as you need to go for netconf > contexts, or do you need the greater depth found in the SNMP contexts? > Do you anticipate a future need to be able to configure, for example, > the XML instance for a specific blade in a server? > > I'm interested in your thoughts on this because VACM has not gained > very wide acceptance, and a simpler AC model that could be used with > both netconf's XML hierarchical naming scheme and SNMP's OID > hierarchical naming scheme (or an XML-based SNMP naming scheme) could > help both protocols. I'm also interested in probing how the > requirements for netconf AC and SNMP AC might differ, since this could > also have an impact on whether ISMS design should even try to be > future-compatible with netconf. > > David Harrington > dbharrington@comcast.net > > > > > > > > -- > 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 Jul 05 18:00:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpvTN-0003Os-8p for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 18:00:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05258 for ; Tue, 5 Jul 2005 18:00:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpvLd-000AsY-OH for netconf-data@psg.com; Tue, 05 Jul 2005 21:52:57 +0000 Received: from [85.73.149.137] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpvLa-000As7-Is for netconf@ops.ietf.org; Tue, 05 Jul 2005 21:52:54 +0000 Received: by boskop.local (Postfix, from userid 501) id 6755C3587A2; Tue, 5 Jul 2005 23:52:50 +0200 (CEST) Date: Tue, 5 Jul 2005 23:52:50 +0200 From: Juergen Schoenwaelder To: "David T. Perkins" Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050705215250.GA6068@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "David T. Perkins" , netconf@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jul 05, 2005 at 01:53:54PM -0700, David T. Perkins wrote: > Two specific items... > 1) I don't see the need for contexts in NETCONF data modeling, > since contexts are simply "a mechanism to add extra > indexing when the MIB designer failed to predict the future > evolution of technology" (or bandaid for poor MIB design). > With XML, I don't really believe this limitation is > present, and, thus, a "context" will not be needed. Using XML does not prevent MIB designers from failing to "predict the future evolution of technology". Once you cast an XML schema into stone, you can screw up as well. The hope, however, is that we do not need to introduce an extra mechanism like contexts to fix such problems. > In the work that I have done explaining VACM, the > concept that what security level is used can affect > what can be accessed is always a very big surprise. A story from real life here. I was trying to setup a subversion server (subversion is basically a better cvs version control system) using apache and the webdav/deltav modules. I wanted to make the configuration such that users who have authenticated using a cleartext channel will be treated differently from users who have authenticated over an encrypted channel. So far, I have not managed to do this in a nice way because the authorization decision only knows whether someone has been authenticated but not how this was carried out. I then realized that SNMP actually got this right and I am still surprised that I have not found someone to explain me how this can be done nicely in the above mentioned scenario. > Thus, I would characterize VACM as completely missing > the target. It is too complex for typical usage, > and not rich enough for realworld usage. This may be true. The main problem with VACM is that the burden of defining suitable security profiles is left to the operators who really have other things to worry about. So what is left are in most cases the "default" read-only and read-write profiles. If we do netconf access control, we should investigate how command line interfaces typically deal with access control. We should not constrain ourself by the VACM design since the number of non-default VACM tables I have seen on production systems is close to zero. If someone has different experiences with deployed VACM configurations, please speak up. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 05 18:00:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpvTN-0003QH-U9 for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 18:00:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05262 for ; Tue, 5 Jul 2005 18:00:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpvGM-000AMT-96 for netconf-data@psg.com; Tue, 05 Jul 2005 21:47:30 +0000 Received: from [207.69.195.66] (helo=pop-canoe.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpvGK-000AMD-Az for netconf@ops.ietf.org; Tue, 05 Jul 2005 21:47:28 +0000 Received: from h-64-105-137-251.snvacaid.dynamic.covad.net ([64.105.137.251] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DpvGI-0004WS-00 for netconf@ops.ietf.org; Tue, 05 Jul 2005 17:47:26 -0400 Message-ID: <001d01c581ab$b35c79a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: Proposed Update to Netconf Charter Date: Tue, 5 Jul 2005 14:51:28 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "David T. Perkins" > To: "David B Harrington" > Cc: "'Andy Bierman'" ; "'Sharon Chisholm'" ; > Sent: Tuesday, July 05, 2005 1:53 PM > Subject: RE: Proposed Update to Netconf Charter > > HI, > > Two specific items... > 1) I don't see the need for contexts in NETCONF data modeling, > since contexts are simply "a mechanism to add extra > indexing when the MIB designer failed to predict the future > evolution of technology" (or bandaid for poor MIB design). > With XML, I don't really believe this limitation is > present, and, thus, a "context" will not be needed. However, netconf adds the notion of configuration datastores. If there is ever any reason to treat different configuration datastores differently, they'll need to be accounted for in the access control model. To me they resemble the SNMPv2p temporal domains, which were part of what eventually morphed into contexts. > 2) SNMP VACM access control is based on > 1) the identication of the management information > (the variable name) > 2) the operation type (read/write/notify) > 3) the security model > 4) the security level > 5) the context > 6) the group > It doesn't depend on the value of object instance. This > has resulted in MIB design patterns where objects are > made (unnaturally) into index object(s). The usual > case is where the security name (or group name) > is made into an index. Many other systems, especially > data base systems have access control based on > data values. All the cases I have seen of using indexing information in conjunction with VACM have been driven by the need to conveniently represent ownership, rather than any requirement for the access control policy to be sensitive to either the value of the object being set or the value being proposed. > In the work that I have done explaining VACM, the > concept that what security level is used can affect > what can be accessed is always a very big surprise. I believe this is more a comment on the level of awareness of what goes into forming a security policy, than it is on VACM. If access control policies for netconf cannot distinguish whether, for example, the communication channel is encrypted or not, then there's a serious defect. > So far, there is a single security model. If several > were present, then the number of entries in the VACM > table could increase by a factor of the number. Only the vacmSecurityToGroupTable and vacmAccessTable would be affected, though I think twisting VACM into securing netconf data would be, well, twisted. :-) > In general, the SNMP acess model is unlike anything > that most users are use to. Agreed. > Thus, they can not > understand it, and its richness is typically never > used. It is also typically not used because the > objects used by management apps are not typically > characterized. Thus, most systems that I've seen > provide no restriction to management platforms, and > any restriction is done by a management platform > as to which management applications any specific > user can run. I don't think these conclusions flow solely from the fact that VACM is "different". I think *any* non-trivial access control model will be at risk of these same problems. > Thus, I would characterize VACM as completely missing > the target. It is too complex for typical usage, > and not rich enough for realworld usage. I don't think anyone has suggested using VACM for netconf. The heart of DavidH's question is how would access control for netconf need to be different from VACM. For example, if there is a need to control access to different portions of the configuration based on a notion of ownership, then if one used something like xpath to represent that aspect of the policy, one might end up putting "owner strings" in, and end up with something uncomfortably (from your perspective) similar to VACM's way of coping with the ownership concept. All this leads to the fundamental question of how much expressive power netconf access control policies will need. Randy -- 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 Jul 05 18:25:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpvrT-0003gv-UL for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 18:25: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 SAA09351 for ; Tue, 5 Jul 2005 18:25:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpvnQ-000DWn-E2 for netconf-data@psg.com; Tue, 05 Jul 2005 22:21:40 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DpvnO-000DWa-Hn for netconf@ops.ietf.org; Tue, 05 Jul 2005 22:21:38 +0000 Received: (qmail 10481 invoked by uid 78); 5 Jul 2005 22:14:57 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 5 Jul 2005 22:14:57 -0000 Message-ID: <42CB065C.6050306@andybierman.com> Date: Tue, 05 Jul 2005 15:14:52 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dbharrington@comcast.net CC: "'Sharon Chisholm'" , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> In-Reply-To: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David B Harrington wrote: >Hi Andy, > > > >>Access control is also critical to get in place early on. >>I prefer to start simple and evolve the complexity over time. >>IMO, a mapping to ISMS should be a separate work effort, >>and probably in that WG. >> >>NETCONF AC is unique because it is both "RPC method" and >>document oriented. >>IMO, old approaches like VACM will be clumsy and/or bloated if >> >> >applied > > >>to NETCONF. Some new innovation is required here. >> >> >> > >I'm interested in your views about the uniqueness of netconf AC. > >In SNMPv3, as you know, we found that all operations could be >abstracted into read/write/notify types of operations for purposes of >AC. There was not a real need to distinguish between GET, GETBULK, and >other proposed GET-XXXX operations. Do you see a real need to >distinguish between the various RPC methods, etc., that >would be initiated by an operator? > >In the SNMPv3 isAccessAllowed() ASI, variableName names the instance >of the managed object. Would netconf use a similar (XML-based) >variablename to identify the instance of the managed object? > >Do you expect that "documents" will be aggregations of objects that >are not necessarily from the same XML subtree? I can see this if the >document is an HTML web page; but if it is built from data elements >defined as an XML instance, then would AC based on the underlying XML >suffice? Cf: a varbind list with an aggregation of various managed >objects. Do you have something different in mind for documents? > >In SNMPv3, we have contexts to differentiate MIB instances. I assume >such a concept would also be needed for netconf. Do you agree? Is >"running" and "candidate" about as deep as you need to go for netconf >contexts, or do you need the greater depth found in the SNMP contexts? >Do you anticipate a future need to be able to configure, for example, >the XML instance for a specific blade in a server? > >I'm interested in your thoughts on this because VACM has not gained >very wide acceptance, and a simpler AC model that could be used with >both netconf's XML hierarchical naming scheme and SNMP's OID >hierarchical naming scheme (or an XML-based SNMP naming scheme) could >help both protocols. I'm also interested in probing how the >requirements for netconf AC and SNMP AC might differ, since this could >also have an impact on whether ISMS design should even try to be >future-compatible with netconf. > > Since you asked... IMO, we need a simple 2-tier access control model that is independent of higher layer abstractions. 1) access is by group-name, and a group contains a list of user names. A user can be included in any number of groups. 2) tier 1 is RPC method access, which is defined by the tuple: { namespace-uri, method-name } and access is granted by configuring via the tuple { namespace-uri, method-name, group-list } Example 1: access to the groups 'staff' and 'root' are granted for the edit-config method via the following configlet: urn:ietf:params:xml:ns:netconf:base:1.0 edit-config root, staff Example 2: access to everybody given to 'my-own-method': http://example.net/me/my-own/1.0 my-own-method all 3) tier 2 is data model access, and defined by the tuple: { operation-list, data-namespace, data-path, group-list } where: operation-list is zero or more of the following strings: { notify, read, create, merge, replace, delete } [Shorthand: the term 'write' == create, merge, replace, delete] data-namespace is the URI identifying the data model namespace data-path is an absolute XPATH expression identifying the top-level data model node that this access applies group-list is a list of group names granted access For example, root is given all access to the path 'users/user': all http://example.com/1.0 /top/users/user root Multiple overlapping entries need to be handled and a sequential processing model needs to be defined, but IMO this type of simple approach could be good enough to start with. >David Harrington >dbharrington@comcast.net > > 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 Jul 05 18:48:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpwD6-0004Xc-3X for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 18:48:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11595 for ; Tue, 5 Jul 2005 18:48:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dpw93-000F5y-8R for netconf-data@psg.com; Tue, 05 Jul 2005 22:44:01 +0000 Received: from [85.73.149.137] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dpw91-000F5g-Bk for netconf@ops.ietf.org; Tue, 05 Jul 2005 22:43:59 +0000 Received: by boskop.local (Postfix, from userid 501) id 07E04358887; Wed, 6 Jul 2005 00:43:56 +0200 (CEST) Date: Wed, 6 Jul 2005 00:43:56 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050705224356.GA6147@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CB065C.6050306@andybierman.com> User-Agent: Mutt/1.5.8i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jul 05, 2005 at 03:14:52PM -0700, Andy Bierman wrote: > 3) tier 2 is data model access, and defined by the tuple: > > { operation-list, data-namespace, data-path, group-list } > > where: > > operation-list is zero or more of the following strings: > { notify, read, create, merge, replace, delete } > [Shorthand: the term 'write' == create, merge, replace, delete] > data-namespace is the URI identifying the data model namespace > data-path is an absolute XPATH expression identifying the > top-level data model node that this access applies > group-list is a list of group names granted access While all this sounds reasonable, I am really surprised that you propose XPATH expressions given the lengthy discussion in the past that XPATH expressions are too expensive for filtering. Or is it because you expect access control on the 2nd tier not to be mandatory to implement and an optional feature like XPATH filtering? Sorry, I could not resist to ask this question. But despite this somewhat polemic question, I do like the 2 tier approach that you have outlined. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 05 19: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 1Dpx8N-0006oz-DU for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 19: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 TAA20775 for ; Tue, 5 Jul 2005 19:47:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dpx1k-000JRx-Ck for netconf-data@psg.com; Tue, 05 Jul 2005 23:40:32 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dpx1j-000JRk-Ln for netconf@ops.ietf.org; Tue, 05 Jul 2005 23:40:31 +0000 Received: (qmail 4068 invoked by uid 78); 5 Jul 2005 23:40:30 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail6.netsol.inquent.com with SMTP; 5 Jul 2005 23:40:30 -0000 Message-ID: <42CB1A6E.3080801@andybierman.com> Date: Tue, 05 Jul 2005 16:40:30 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> In-Reply-To: <20050705224356.GA6147@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Tue, Jul 05, 2005 at 03:14:52PM -0700, Andy Bierman wrote: > > > >>3) tier 2 is data model access, and defined by the tuple: >> >> { operation-list, data-namespace, data-path, group-list } >> >>where: >> >> operation-list is zero or more of the following strings: >> { notify, read, create, merge, replace, delete } >> [Shorthand: the term 'write' == create, merge, replace, delete] >> data-namespace is the URI identifying the data model namespace >> data-path is an absolute XPATH expression identifying the >> top-level data model node that this access applies >> group-list is a list of group names granted access >> >> > >While all this sounds reasonable, I am really surprised that you >propose XPATH expressions given the lengthy discussion in the past >that XPATH expressions are too expensive for filtering. Or is it >because you expect access control on the 2nd tier not to be >mandatory to implement and an optional feature like XPATH >filtering? > > I am envisioning that a simple absolute path expression be the mandatory requirement and full XPATH expressions would be optional. This restricted XPATH is what we have within the 'rpc-error' structure, and the WG already agreed on this simple string format which happens to be a particular subset of XPATH. >Sorry, I could not resist to ask this question. But despite this >somewhat polemic question, I do like the 2 tier approach that you >have outlined. > > I didn't really clarify the XPATH usage, but since you brought it up, it would be a powerful way to specify access control filters. I think this 2-tier approach makes sense because NETCONF is extensible, and we can't hard-wire the tier-1 configuration. Even though the document seems to make a special case out of NETCONF operations, all the protocol really has are RPC methods defined within specific namespaces. We need to deal with vendor (and maybe later standard) RPC extensions anyway. >/js > > > 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 Jul 05 20:04:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpxOu-0002LP-D0 for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 20:04:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22304 for ; Tue, 5 Jul 2005 20:04:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpxKn-000L6D-7h for netconf-data@psg.com; Wed, 06 Jul 2005 00:00:13 +0000 Received: from [85.73.149.137] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpxKj-000L5C-B8 for netconf@ops.ietf.org; Wed, 06 Jul 2005 00:00:09 +0000 Received: by boskop.local (Postfix, from userid 501) id 3D7D63589A9; Wed, 6 Jul 2005 02:00:07 +0200 (CEST) Date: Wed, 6 Jul 2005 02:00:06 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050706000006.GB6281@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> <42CB1A6E.3080801@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CB1A6E.3080801@andybierman.com> User-Agent: Mutt/1.5.8i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jul 05, 2005 at 04:40:30PM -0700, Andy Bierman wrote: > >While all this sounds reasonable, I am really surprised that you > >propose XPATH expressions given the lengthy discussion in the past > >that XPATH expressions are too expensive for filtering. Or is it > >because you expect access control on the 2nd tier not to be > >mandatory to implement and an optional feature like XPATH > >filtering? > > I am envisioning that a simple absolute path expression be the mandatory > requirement and full XPATH expressions would be optional. This restricted > XPATH is what we have within the 'rpc-error' structure, and the WG > already agreed on this simple string format which happens to be a > particular subset of XPATH. I must have missed that. Makes it even more interesting since subsetting XPATH for filtering was also rejected in favour of a home-grown filtering mechanism. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 05 22:19:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpzVf-0005mR-Q3 for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 22:19:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07683 for ; Tue, 5 Jul 2005 22:19:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpzNl-0005Ph-1C for netconf-data@psg.com; Wed, 06 Jul 2005 02:11:25 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DpzNk-0005PJ-2I for netconf@ops.ietf.org; Wed, 06 Jul 2005 02:11:24 +0000 Received: (qmail 25873 invoked by uid 78); 6 Jul 2005 02:11:20 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail4.netsol.inquent.com with SMTP; 6 Jul 2005 02:11:20 -0000 Message-ID: <42CB3DC7.50908@andybierman.com> Date: Tue, 05 Jul 2005 19:11:19 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> <42CB1A6E.3080801@andybierman.com> <20050706000006.GB6281@boskop.local> In-Reply-To: <20050706000006.GB6281@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Tue, Jul 05, 2005 at 04:40:30PM -0700, Andy Bierman wrote: > > > >>>While all this sounds reasonable, I am really surprised that you >>>propose XPATH expressions given the lengthy discussion in the past >>>that XPATH expressions are too expensive for filtering. Or is it >>>because you expect access control on the 2nd tier not to be >>>mandatory to implement and an optional feature like XPATH >>>filtering? >>> >>> >>I am envisioning that a simple absolute path expression be the mandatory >>requirement and full XPATH expressions would be optional. This restricted >>XPATH is what we have within the 'rpc-error' structure, and the WG >>already agreed on this simple string format which happens to be a >>particular subset of XPATH. >> >> > >I must have missed that. Makes it even more interesting since subsetting >XPATH for filtering was also rejected in favour of a home-grown filtering >mechanism. > > Actually this is totally consistent with the rpc-error design. The user should be able to specify a qualified name (QName) like 'error-info/bad-element', or specify a node via simple XPATH, like the 'error-path' element. The error-path element is optional so even this trivial XPATH usage can be avoided, if desired. IMO this is not inconsistent with the WG's choice to use subtree filtering. This is an extremely restricted subset of XPATH, much easier to define than a subset to do some real filtering. >/js > > > 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 Jul 05 23:22:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq0UP-0003HQ-Re for netconf-archive@megatron.ietf.org; Tue, 05 Jul 2005 23:22:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14664 for ; Tue, 5 Jul 2005 23:22:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dq0PO-000ABT-E2 for netconf-data@psg.com; Wed, 06 Jul 2005 03:17:10 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dq0PJ-000ABB-Ft for netconf@ops.ietf.org; Wed, 06 Jul 2005 03:17:05 +0000 Received: (eyou send program); Wed, 06 Jul 2005 11:18:14 +0800 Message-ID: <320663094.05671@njupt.edu.cn> X-EYOUMAIL-SMTPAUTH: y030737@njupt.edu.cn Received: from unknown (HELO nupt-d83898b16f) (10.10.136.120) by 202.119.230.11 with SMTP; Wed, 06 Jul 2005 11:18:14 +0800 Date: Wed, 6 Jul 2005 11:20:30 +0800 From: "=?gb2312?B?zfW6sQ==?=" To: "netconf" Subject: how long should the manager maintain the connection with his device? X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_BLANKS,MIME_BASE64_TEXT,MSGID_FROM_MTA_HEADER,RCVD_BY_IP autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 aGkgYWxsOg0KDQogICBJIGhhdmUgcmVhZCB0aGUgbmV0Y29uZi1wcm8wNiBhbmQgInNjYWxhYmls aXR5IG9mIG5ldGNvbmYiIHRvcGljIG9uIHRoZSBsaXN0LCBJIHNhdyANCkp1ZXJnZW4gU2Nob2Vu d2FlbGRlciBzYWlkIGhlIGZpbmQgdGhhdCBob2xkaW5nIDMwMCBUQ1AgY29ubmVjdGlvbnMgaXMg bm90IGEgaGFyZCB0aGluZy4NCg0KICAgYnV0IEkgd2FudCB0byBrbm93IGluIHRoZSByZWFsIHdv cmxkICwgZG9lcyB0aGUgbWFuYWdlciBqdXN0IGhvbGQgdGhlIGNvbm5lY3Rpb24gd2hlbiB0aGVy ZSBhcmUgc3RpbGwgc29tZSBjb25maWcgb3BlcmF0aW9uIG5lZWQgdG8gYmUgcGVyZm9ybWVkIGFu ZCB0aGUgY29ubmVjdGlvbiB3aWxsIGJlIGtpbGwgYXMgc29vbiBhcyB0aGVzZSBvcGVyYXRpb25z IGNvbXBsZXRlZD8gIE9yIGl0IHdpbGwgaG9sZCB0aGUgY29ubmVjdGlvbiB3aXRoIGhpcyAiYWdl bnQiIGFsbCB0aGUgdGltZSB1bnRpbCBzb21lIGFjY2lkZW50IGhhcHBlbnM/IA0KDQoNCnRoYW5r cyBmb3IgY29taW5nIGluIQ0KDQpCZXN0IFJlZ2FyZHMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpXYW5nIEhhbg0KDQp5MDMwNzM3QG5qdXB0 LmVkdS5jbg0KUmVzZWFyY2ggQ2VudGVyIG9mIE5ldHdvcmsgVGVjaG5vbG9neQ0KTmFuamluZyBV bml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCi0tLaGqoaqhqqGqoaqh qqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaoNCg0KDQoNCg== -- 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 Jul 06 04:12:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq51X-0008KV-KZ for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 04:12:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12388 for ; Wed, 6 Jul 2005 04:12:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dq4pM-000651-Ks for netconf-data@psg.com; Wed, 06 Jul 2005 08:00:16 +0000 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dq4pL-00064a-Fk for netconf@ops.ietf.org; Wed, 06 Jul 2005 08:00:15 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0FE2D51929; Wed, 6 Jul 2005 10:00:14 +0200 (CEST) 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 5F11951922; Wed, 6 Jul 2005 10:00:13 +0200 (CEST) Message-ID: <42CB8F67.1080709@loria.fr> Date: Wed, 06 Jul 2005 09:59:35 +0200 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Cc: Andy Bierman , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> In-Reply-To: <20050705224356.GA6147@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The tests made on our Netconf implementation shown us that XPath filtering is as fast as subtree filtering except in the following situation: a XPath expression that is not an absolute path like '//user' In that case, it is hard to predict what part of the data model is concerned. Two solutions were possible for us: - parse the XML Schemas from our database and try to find the ones which have a "user" element - build the whole configuration document and apply the XPath expression on it The first approach is difficult to perform and suppose that all data models are defined with XML Schema (not DTD or other). The second approach is time consuming. We chose the second one since it's easier in our environment even if not satisfying. To improve this, what I suggest is to modify XPath filtering a little bit. Most programming languages allow to define a namespace context before applying an XPath expression to a document. It would be nice to allow namespaces contexts definition in the Netconf requests: //net:network/if:interfaces/if:iface/if:name net urn:network:data:model if urn:network:interfaces:data:model Currently, a way to do something equivalent is the following: //*[namespace-uri()='urn:network:data:model' and local-name()='network']/*[namespace-uri()='urn:network:interfaces:data:model' and local-name()=interfaces]/*[namespace-uri()='urn:network:interfaces:data:model' and local-name()='iface'/*[namespace-uri()='urn:network:interfaces:data:model' and local-name()='name'] While the first one is easy to read and write for a human, the second is more difficult. In both cases, it allows to bind easily the XPath expression to the right part of the data model. I think the problem is similar in the case of access control which is somewhat the same process as XPath or subtree filtering (in the case of a read operation). To illustrate this, our implementation expresses the access control policy with XPath and uses the same methods to filter the document for access control or filtering operations. Vincent CRIDLIG Juergen Schoenwaelder wrote: >On Tue, Jul 05, 2005 at 03:14:52PM -0700, Andy Bierman wrote: > > > >>3) tier 2 is data model access, and defined by the tuple: >> >> { operation-list, data-namespace, data-path, group-list } >> >>where: >> >> operation-list is zero or more of the following strings: >> { notify, read, create, merge, replace, delete } >> [Shorthand: the term 'write' == create, merge, replace, delete] >> data-namespace is the URI identifying the data model namespace >> data-path is an absolute XPATH expression identifying the >> top-level data model node that this access applies >> group-list is a list of group names granted access >> >> > >While all this sounds reasonable, I am really surprised that you >propose XPATH expressions given the lengthy discussion in the past >that XPATH expressions are too expensive for filtering. Or is it >because you expect access control on the 2nd tier not to be >mandatory to implement and an optional feature like XPATH >filtering? > >Sorry, I could not resist to ask this question. But despite this >somewhat polemic question, I do like the 2 tier approach that you >have outlined. > >/js > > > -- 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 Jul 06 05:05:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq5q2-0008R3-Py for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 05:05: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 FAA26178 for ; Wed, 6 Jul 2005 05:05:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dq5l0-000BLU-Bq for netconf-data@psg.com; Wed, 06 Jul 2005 08:59:50 +0000 Received: from [85.73.133.97] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dq5kx-000BKv-2j for netconf@ops.ietf.org; Wed, 06 Jul 2005 08:59:47 +0000 Received: by boskop.local (Postfix, from userid 501) id AD6A6358CFE; Wed, 6 Jul 2005 10:59:43 +0200 (CEST) Date: Wed, 6 Jul 2005 10:59:43 +0200 From: Juergen Schoenwaelder To: Vincent Cridlig Cc: Andy Bierman , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050706085943.GA6979@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Vincent Cridlig , Andy Bierman , netconf@ops.ietf.org References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> <42CB8F67.1080709@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CB8F67.1080709@loria.fr> User-Agent: Mutt/1.5.8i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jul 06, 2005 at 09:59:35AM +0200, Vincent Cridlig wrote: > To improve this, what I suggest is to modify XPath filtering a little bit. > Most programming languages allow to define a namespace context before > applying an XPath expression to a document. > It would be nice to allow namespaces contexts definition in the Netconf > requests: > > > //net:network/if:interfaces/if:iface/if:name > > > net > urn:network:data:model > > > if > urn:network:interfaces:data:model > > > I think this WG is not the right place to change XPath. Some of us have quite some experience with adapted subsets and I prefer not to do this again. Subsetting for conformance might be OK, adapting is IMHO a poor choice. If relative paths are a real issue, why can a device not use a hash table lookup to find out where potential starting points in its schemas are? Yes, this might require some more coding but at the end there is the benefit that you do not have to invent something special which might bite you when XPath gets revised. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 06 05:42:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq6Q6-0006AS-L6 for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 05:42:18 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07490 for ; Wed, 6 Jul 2005 05:42:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dq6Kt-000EcQ-9X for netconf-data@psg.com; Wed, 06 Jul 2005 09:36:55 +0000 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dq6Ks-000Ec8-7h for netconf@ops.ietf.org; Wed, 06 Jul 2005 09:36:54 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 10B1A51928; Wed, 6 Jul 2005 11:36:53 +0200 (CEST) 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 1CAE5518D2; Wed, 6 Jul 2005 11:36:51 +0200 (CEST) Message-ID: <42CBA60D.1060209@loria.fr> Date: Wed, 06 Jul 2005 11:36:13 +0200 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org, ietf@andybierman.com, Radu State Subject: Re: Proposed Update to Netconf Charter References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> <42CB8F67.1080709@loria.fr> <20050706085943.GA6979@boskop.local> In-Reply-To: <20050706085943.GA6979@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let me give more details about what I proposed. The prefix concept is well defined in the XPath recommendation. I didn't invent this concept and I don't want to change XPath. Using XPath prefix needs a namespace declaration. This is why I suggested to add some namespace declaration along with the Netconf request. In fact, I might be wrong but I think it is not possible to fully support XPath without making it possible to send these declarations. These declarations are needed to build the expression context as described in the XPath recommendation. If a manager sends an XPath request which contains prefixes, I don't know how an agent could guess the related (real) namespace URI. Best regards, Vincent CRIDLIG Juergen Schoenwaelder wrote: >On Wed, Jul 06, 2005 at 09:59:35AM +0200, Vincent Cridlig wrote: > > > >>To improve this, what I suggest is to modify XPath filtering a little bit. >>Most programming languages allow to define a namespace context before >>applying an XPath expression to a document. >>It would be nice to allow namespaces contexts definition in the Netconf >>requests: >> >> >> //net:network/if:interfaces/if:iface/if:name >> >> >> net >> urn:network:data:model >> >> >> if >> urn:network:interfaces:data:model >> >> >> >> >> > >I think this WG is not the right place to change XPath. Some of us have >quite some experience with adapted subsets and I prefer not to do this >again. Subsetting for conformance might be OK, adapting is IMHO a poor >choice. > >If relative paths are a real issue, why can a device not use a hash table >lookup to find out where potential starting points in its schemas are? >Yes, this might require some more coding but at the end there is the >benefit that you do not have to invent something special which might >bite you when XPath gets revised. > >/js > > > -- 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 Jul 06 06:01:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq6iw-0005HV-4Y for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 06:01: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 GAA13811 for ; Wed, 6 Jul 2005 06:01:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dq6cc-000GGU-5J for netconf-data@psg.com; Wed, 06 Jul 2005 09:55:14 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dq6cZ-000GG7-Uu for netconf@ops.ietf.org; Wed, 06 Jul 2005 09:55:12 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id F2E5A39647; Wed, 6 Jul 2005 11:55:10 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00378-10; Wed, 6 Jul 2005 11:55:09 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 25D293998B; Wed, 6 Jul 2005 11:55:09 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 5A637358DF5; Wed, 6 Jul 2005 11:55:09 +0200 (CEST) Date: Wed, 6 Jul 2005 11:55:09 +0200 From: Juergen Schoenwaelder To: Vincent Cridlig Cc: netconf@ops.ietf.org, ietf@andybierman.com, Radu State Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050706095509.GA7258@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Vincent Cridlig , netconf@ops.ietf.org, ietf@andybierman.com, Radu State References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> <42CB8F67.1080709@loria.fr> <20050706085943.GA6979@boskop.local> <42CBA60D.1060209@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CBA60D.1060209@loria.fr> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jul 06, 2005 at 11:36:13AM +0200, Vincent Cridlig wrote: > Let me give more details about what I proposed. > > The prefix concept is well defined in the XPath recommendation. I didn't > invent this concept and I don't want to change XPath. > > Using XPath prefix needs a namespace declaration. This is why I > suggested to add some namespace declaration along with the Netconf request. > In fact, I might be wrong but I think it is not possible to fully > support XPath without making it possible to send these declarations. > These declarations are needed to build the expression context as > described in the XPath recommendation. > If a manager sends an XPath request which contains prefixes, I don't > know how an agent could guess the related (real) namespace URI. Thanks for this clarification. This now sounds much more reasonable. I guess I have to go back to the XPath specs. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 06 08:42:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq9E9-0007je-St for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 08:42:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13925 for ; Wed, 6 Jul 2005 08:42:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dq95v-0003Ac-Bz for netconf-data@psg.com; Wed, 06 Jul 2005 12:33:39 +0000 Received: from [198.152.13.100] (helo=tierw.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Dq95t-0003AL-DI for netconf@ops.ietf.org; Wed, 06 Jul 2005 12:33:37 +0000 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j66CLNVi027984 for ; Wed, 6 Jul 2005 08:21:23 -0400 (EDT) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j66CLKVi027901 for ; Wed, 6 Jul 2005 08:21:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Update to Netconf Charter Date: Wed, 6 Jul 2005 08:33:32 -0400 Message-ID: <8CA1128D59AD27429985B397118CEDDF01E59548@nj7460avexu1.global.avaya.com> Thread-Topic: Proposed Update to Netconf Charter Thread-Index: AcWCEP47RYUlgByuS+eKtBy4nJ9WigAFQezQ From: "Mazumdar, Subrata \(Subrata\)" To: , X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi!, I think that Andy's proposal for two tier security is very much similar=20 to Deployment Descriptor based (read XML) J2EE (declarative) security = model=20 for Web and EJB container.=20 J2EE security model is role-based and defined in XML. =20 (For more info, see Chapter 32 in J2EE = http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) The Web-container security model allows patterns in URLs as target = resources=20 and permission can be customized for individual operation (GET/POST = etc).=20 The EJB security model allows method (getter/setter for attribute) based = target definition for access control and it is completely meta-data = driven. I believe that the J2EE declarative=20 security model really fits your need for simple model to start with.=20 I believe that it is not going to be very difficult to map the SNMP VACM = to RBAC=20 so that netconf AC is compatible with SNMP v3 VACM.=20 -- Subrata=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On Behalf Of Juergen Schoenwaelder Sent: Wednesday, July 06, 2005 5:55 AM To: Vincent Cridlig Cc: netconf@ops.ietf.org; ietf@andybierman.com; Radu State Subject: Re: Proposed Update to Netconf Charter On Wed, Jul 06, 2005 at 11:36:13AM +0200, Vincent Cridlig wrote: > Let me give more details about what I proposed. >=20 > The prefix concept is well defined in the XPath recommendation. I = didn't=20 > invent this concept and I don't want to change XPath. >=20 > Using XPath prefix needs a namespace declaration. This is why I=20 > suggested to add some namespace declaration along with the Netconf = request. > In fact, I might be wrong but I think it is not possible to fully=20 > support XPath without making it possible to send these declarations.=20 > These declarations are needed to build the expression context as=20 > described in the XPath recommendation. > If a manager sends an XPath request which contains prefixes, I don't=20 > know how an agent could guess the related (real) namespace URI. Thanks for this clarification. This now sounds much more reasonable. I guess I have to go back to the XPath specs. /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, = Germany -- 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 Wed Jul 06 09:36:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqA4N-0008JR-0u for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 09:36: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 JAA21669 for ; Wed, 6 Jul 2005 09:36:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dq9zh-00089r-Gy for netconf-data@psg.com; Wed, 06 Jul 2005 13:31:17 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dq9zf-00089Z-Pq for netconf@ops.ietf.org; Wed, 06 Jul 2005 13:31:15 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DE29039A26; Wed, 6 Jul 2005 15:31:14 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12737-09; Wed, 6 Jul 2005 15:31:13 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id DEE1F39A1B; Wed, 6 Jul 2005 15:31:13 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 8060D358FDF; Wed, 6 Jul 2005 15:31:14 +0200 (CEST) Date: Wed, 6 Jul 2005 15:31:14 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050706133114.GB7544@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> <42CB1A6E.3080801@andybierman.com> <20050706000006.GB6281@boskop.local> <42CB3DC7.50908@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CB3DC7.50908@andybierman.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jul 05, 2005 at 07:11:19PM -0700, Andy Bierman wrote: > Actually this is totally consistent with the rpc-error design. > The user should be able to specify a qualified name (QName) > like 'error-info/bad-element', or specify a node via simple XPATH, like > the 'error-path' element. > > The error-path element is optional so even this trivial XPATH usage > can be avoided, if desired. > > IMO this is not inconsistent with the WG's choice to use subtree filtering. > This is an extremely restricted subset of XPATH, much easier to > define than a subset to do some real filtering. The future will tell us whether the mixture of some XPath here, a bit less XPath there and some required other mechanism with optional XPath over there will be loved or seen as a curiosity. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 06 09:48:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqAG8-0000fU-GT for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 09:48:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22790 for ; Wed, 6 Jul 2005 09:48:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqAB8-000967-5M for netconf-data@psg.com; Wed, 06 Jul 2005 13:43:06 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqAB6-00095o-BR for netconf@ops.ietf.org; Wed, 06 Jul 2005 13:43:04 +0000 Received: (qmail 26393 invoked by uid 78); 6 Jul 2005 13:43:03 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 6 Jul 2005 13:43:03 -0000 Message-ID: <42CBDFE2.3070100@andybierman.com> Date: Wed, 06 Jul 2005 06:42:58 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> <20050705224356.GA6147@boskop.local> <42CB1A6E.3080801@andybierman.com> <20050706000006.GB6281@boskop.local> <42CB3DC7.50908@andybierman.com> <20050706133114.GB7544@boskop.local> In-Reply-To: <20050706133114.GB7544@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Tue, Jul 05, 2005 at 07:11:19PM -0700, Andy Bierman wrote: > > > >>Actually this is totally consistent with the rpc-error design. >>The user should be able to specify a qualified name (QName) >>like 'error-info/bad-element', or specify a node via simple XPATH, like >>the 'error-path' element. >> >>The error-path element is optional so even this trivial XPATH usage >>can be avoided, if desired. >> >>IMO this is not inconsistent with the WG's choice to use subtree filtering. >>This is an extremely restricted subset of XPATH, much easier to >>define than a subset to do some real filtering. >> >> > >The future will tell us whether the mixture of some XPath here, a bit >less XPath there and some required other mechanism with optional XPath >over there will be loved or seen as a curiosity. > > I think (hope) that over time, it will be common for NETCONF devices to support the xpath capability, and perhaps subtree filtering will fade away. As for QName vs. absolute XPATH expression, I think QName will be used whenever possible (just as intended in rpc-error) since it is simpler. >/js > > 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 Wed Jul 06 11:32:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBsx-0007TS-20 for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 11:32:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11063 for ; Wed, 6 Jul 2005 11:32:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqBmU-000I7Y-2i for netconf-data@psg.com; Wed, 06 Jul 2005 15:25:46 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqBmP-000I6g-9h for netconf@ops.ietf.org; Wed, 06 Jul 2005 15:25:41 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 59F5F39A1F; Wed, 6 Jul 2005 17:25:39 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20904-01; Wed, 6 Jul 2005 17:25:38 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 41A4D3959F; Wed, 6 Jul 2005 17:25:38 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 355FD35938C; Wed, 6 Jul 2005 17:25:39 +0200 (CEST) Date: Wed, 6 Jul 2005 17:25:38 +0200 From: Juergen Schoenwaelder To: netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: Scalability of Netconf Message-ID: <20050706152538.GA7841@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de References: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> <20050705140117.GA4704@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050705140117.GA4704@boskop.local> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jul 05, 2005 at 04:01:17PM +0200, Juergen Schoenwaelder wrote: > I am running this script on a 3GHz Pentium with 512 MB Ram (so really > nothing high end for a management system) running Linux 2.6.10. I > keep 300 connections open and the funny thing is that this box does > not at really get stressed by this. The load never went above 0.1% > and was most of the time significantly below. The memory used excluding > buffers was ~235 MB. Today I was running 1200 ssh connections using the same basic script on the same box. The load again never went above 0.1 while the memory usage went up to ~494 MB. Shall I try 10.000 tomorrow? With 2GB of memory this should be possible. The two Linux XEON servers that play the remote end for 600 connections each do not seem to bother much about all this. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 06 12:21:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCen-0007tX-SH for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 12:21:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17335 for ; Wed, 6 Jul 2005 12:21:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqCYc-000MXv-39 for netconf-data@psg.com; Wed, 06 Jul 2005 16:15:30 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqCYZ-000MXV-EU for netconf@ops.ietf.org; Wed, 06 Jul 2005 16:15:27 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2005 09:15:26 -0700 X-IronPort-AV: i="3.93,265,1115017200"; d="scan'208"; a="196662575:sNHT28074446" 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 j66GFLod027864; Wed, 6 Jul 2005 09:15:21 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4436.cisco.com [10.61.81.83]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j66GEUMD009243; Wed, 6 Jul 2005 09:14:31 -0700 Message-ID: <42CC039C.8060705@cisco.com> Date: Wed, 06 Jul 2005 18:15:24 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: netconf@ops.ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: Scalability of Netconf References: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> <20050705140117.GA4704@boskop.local> <20050706152538.GA7841@boskop.local> In-Reply-To: <20050706152538.GA7841@boskop.local> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120666471.885867"; x:"432200"; a:"rsa-sha1"; b:"nofws:832"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ffKYDfa9slkjVJMFm2ZDtUS99Uc7y0OMfXySNrgnL7iDUBx45h7hoaKakCWeh2rVfaRanx3S" "u6IRIWDqQ/G0W+/UYl+aRQm926F23i8Ny7z+AVkyqn3baNpxOlbarg7LGqApXhXi+Des29qz75v" "Yto2jFAPTfBDhckDLQun/zI0="; c:"Date: Wed, 06 Jul 2005 18:15:24 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: Scalability of Netconf" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yeah, I just had this funny thought of 1200 NMSes trying to configure a router. That's the sort of locking contention we certainly did NOT optimize for! Eliot Juergen Schoenwaelder wrote: > On Tue, Jul 05, 2005 at 04:01:17PM +0200, Juergen Schoenwaelder wrote: > > >>I am running this script on a 3GHz Pentium with 512 MB Ram (so really >>nothing high end for a management system) running Linux 2.6.10. I >>keep 300 connections open and the funny thing is that this box does >>not at really get stressed by this. The load never went above 0.1% >>and was most of the time significantly below. The memory used excluding >>buffers was ~235 MB. > > > Today I was running 1200 ssh connections using the same basic script > on the same box. The load again never went above 0.1 while the memory > usage went up to ~494 MB. Shall I try 10.000 tomorrow? With 2GB of > memory this should be possible. The two Linux XEON servers that play > the remote end for 600 connections each do not seem to bother much > about all this. > > /js > -- 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 Jul 06 13:26:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDf6-0003pw-8l for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 13:26: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 NAA26473 for ; Wed, 6 Jul 2005 13:26:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqDXk-0001i2-EH for netconf-data@psg.com; Wed, 06 Jul 2005 17:18:40 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqDXi-0001hm-Ho for netconf@ops.ietf.org; Wed, 06 Jul 2005 17:18:38 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 3BFD311DBB2; Wed, 6 Jul 2005 10:18:36 -0700 (PDT) From: Wes Hardaker To: "David T. Perkins" Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Organization: Sparta References: <20050705215250.GA6068@boskop.local> Date: Wed, 06 Jul 2005 10:18:33 -0700 In-Reply-To: <20050705215250.GA6068@boskop.local> (Juergen Schoenwaelder's message of "Tue, 5 Jul 2005 23:52:50 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Tue, 5 Jul 2005 23:52:50 +0200, Juergen Schoenwaelder said: Juergen> I wanted to make the configuration such that users who have Juergen> authenticated using a cleartext channel will be treated Juergen> differently from users who have authenticated over an Juergen> encrypted channel. I agree this is actually a nice thing about SNMP. Users of mine actually do just this because they have different avenues of security coming in. Most system administrators would probably even like to do something like this for telnet vs ssh, but can't, so they do the only other acceptable thing which is to turn off telnet instead because doing anything else would be completely insecure. Juergen> If we do netconf access control, we should investigate how Juergen> command line interfaces typically deal with access Juergen> control. We should not constrain ourself by the VACM design Juergen> since the number of non-default VACM tables I have seen on Juergen> production systems is close to zero. If someone has different Juergen> experiences with deployed VACM configurations, please speak Juergen> up. I have described before in front of microphones that I think in an ideal world we need some sort of pseudo-API in our RFCs that describe *how* you need to use the data. IE, setup_new_user(username, securitylevel, ...) would be described to perform these particular SETs in SNMP to the mib objects. This is totally independent of the protocol. Netconf needs something as well, IMHO, because if you think just having the data in XML will let you magically stuff it in with one command you're missing the very big light on the front of the train that is about to run you over. Unfortunately, it's not that easy, because you need to worry about testing for existence of user names that already exist, do an replace if they do and you actually wanted this, or abort if you didn't. Then ... Anyway, high level "to do this frequent task, follow these steps" would be a great boon to application writers and would potentially convince them to design decent infrastructure in their agents and managers. I normally try to shy away from talking about a particular project of mine, but sometimes it serves as an example so I'm going to break my personal rule this time. In Net-SNMP we had issues with the complexity of the VACM for a long time as well. Having said that, we have users that are using probably every aspect of its complexity in their environments. The problem wasn't that it isn't useful, it was that it's hard to understand and more importantly isn't needed for the 95% case. So, to fix this we added a ton of documentation about how to set it up and added a few very simple configuration wrappers for the 95% case that are easy to understand. The majority of our users probably have lines similar to this in their snmp agent configuration files: rocommunity public rwuser wes And they're done. In 2 lines they've added like 8 rows to the VACM tables without knowing anything about it. It's this sort of simple, common-case API that the RFCs need to offer readers. With the advent of the above "wrapping" configuration items and with the documentation we get very few questions now, and if we do its frequently from people trying to understand the more complex scenarios because they actually need it. (as an aside the above configuration tokens actually have additional parameters that add a single oid-tree restriction, add minimum security level (default is authNoPriv, etc)). Visualizing how the whole ball of wax works is hard. Unfortunately, in any system where you have a high degree of variation in how something needs to work you're not going to get away from that. The best you can do is to try and offer *both* a simple case and a hard case. The problem with our RFCs is that 99% of the time because we need the hard cases to exist, that's all we offer rather than offering both. (ok, as long as I'm breaking rules... pet project 2 for the day is visualizing SNMPv3 VACM configuration from live data pulled from the network: http://net-policy.sourceforge.net/screenshots-2004-07-28/viz_snmpv3.png ) -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- 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 Jul 06 13:49:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqE1l-00071T-DP for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 13:49: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 NAA28915 for ; Wed, 6 Jul 2005 13:49:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqDwC-0003iH-Lx for netconf-data@psg.com; Wed, 06 Jul 2005 17:43:56 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqD7E-000PBB-FV for netconf@ops.ietf.org; Wed, 06 Jul 2005 16:51:16 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id D411A11DBB2; Wed, 6 Jul 2005 09:51:14 -0700 (PDT) From: Wes Hardaker To: Sharon Chisholm Cc: nmrg@ibr.cs.tu-bs.de, netconf@ops.ietf.org Subject: Re: nmrgScalability of Netconf Organization: Sparta References: <713043CE8B8E1348AF3C546DBE02C1B403FE42CF@zcarhxm2.corp.nortel.com> <20050705140117.GA4704@boskop.local> <20050705170032.GD5516@boskop.local> Date: Wed, 06 Jul 2005 09:51:13 -0700 In-Reply-To: <20050705170032.GD5516@boskop.local> (Juergen Schoenwaelder's message of "Tue, 5 Jul 2005 19:00:32 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Tue, 5 Jul 2005 19:00:32 +0200, Juergen Schoenwaelder said: Juergen> I totally agree - but we continue to hear stories of boxes Juergen> dying with slightly more than a dozen IPsec associations. FYI, these are figures showing the number of IPsec SAs that a linux box handled a number of years ago (I forget the CPU speed of the laptop, but it had about 512Mb of memory). The IPsec stack was NISTs running on a 2.4 kernel. http://sbsm.hardakers.net/sadb-insert.png http://sbsm.hardakers.net/sadb-speed.png In short, just the creation of SAs (and these were manually created, not via IKE) didn't affect much till you got out into the >10000 range. (sorry about the fuzzy pictures... converted quickly from postscript) -- Wes Hardaker Sparta, Inc. -- 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 Jul 06 14:19:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEUb-0006wi-Al for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 14:19:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02008 for ; Wed, 6 Jul 2005 14:19:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqEPM-0006dI-6C for netconf-data@psg.com; Wed, 06 Jul 2005 18:14:04 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqEPL-0006cx-C1 for netconf@ops.ietf.org; Wed, 06 Jul 2005 18:14:03 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 06 Jul 2005 11:14:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,265,1115017200"; d="scan'208"; a="431276058:sNHT31768380" Received: from gluon.jnpr.net ([172.24.15.23]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 11:14:02 -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: Proposed Update to Netconf Charter Date: Wed, 6 Jul 2005 11:14:01 -0700 Message-ID: Thread-Topic: Proposed Update to Netconf Charter thread-index: AcWBfoTUU61Ob4YdS5W85U//G83DhQA1sfeA From: "Faye Ly" To: "Andy Bierman" , "Sharon Chisholm" Cc: X-OriginalArrivalTime: 06 Jul 2005 18:14:02.0413 (UTC) FILETIME=[7CE555D0:01C58256] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Andy, I agree with 'defining common authentication scheme for access control' and also would like to see 'define a way to multiplex channels over a single secured connection between manager and agent'. The latter is needed to support multiple management channels like notification, syslog, image/file management and/or regular netconf. =20 This is to help lower the cost of configuring many secured connections between manager and agent. =20 -faye -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, July 05, 2005 9:27 AM To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Sharon Chisholm wrote: I have some real concerns with the wording of this charter text, but rather than focus on that, let's just try to agree on a bullet list form of the charter. I would much rather see agreement on specific features first, (and then let people propose solutions, from which the WG may select starting points for 1 or more standard documents), rather than have the WG deal with an ad-hoc array of individual submissions, as they come in. [In the interest of transparency, I am posting my personal preferences for charter extensions] Clearly, the addition of notifications is important to many people, and its already in the charter, so that seems like a no-brainer. However, a clean solution across all application mappings was not achieved in the first attempt, so let's see what new ideas come in this time around.. I also think that core data types are critical. There is actually no reason whatsoever this document couldn't have been published years ago -- it has no coupling to NETCONF at all -- it is just more XSD types to NETCONF. Access control is also critical to get in place early on. I prefer to start simple and evolve the complexity over time. IMO, a mapping to ISMS should be a separate work effort, and probably in that WG. NETCONF AC is unique because it is both "RPC method" and document oriented. IMO, old approaches like VACM will be clumsy and/or bloated if applied to NETCONF. Some new innovation is required here. I am also interested in the "SW image load" channel that has been discussed in the past. Often config reloads are coupled with image reloads, and it would be nice if NETCONF could integrate some SW image management features to support this requirement. Andy >hi > >As promised, here are the proposed updates to the Netconf charter to cover >the work coming down the pipe: > >"Additional phase 2 work including: > >- Requirements and Guidelines for defining Netconf content to enable >interoperable, high-quality and usable netconf implementations. Requirements >will be defined around specification language, access control, compliance, >backwards compatibility, depicting relationships, event specification, and >application error message specification. > >- An initial set of application-level re-usable data types such as IP >Addresses, MAC addresses, etc. This definition would be compliant to the >above defined requirements and guidelines for Netconf content. > >- An XML Schema for reporting information about the Netconf system. This >definition would be compliant to the above defined requirements and >guidelines for Netconf content. > >- A netconf protocol specification for asynchronous messaging to enable the >sending of events. This must preserve the netconf layers." > > >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: > > > =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: -- 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 Jul 06 21:08:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqKso-0003MW-2r for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 21:08:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21076 for ; Wed, 6 Jul 2005 21:08:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqKlV-000E63-Sp for netconf-data@psg.com; Thu, 07 Jul 2005 01:01:21 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqKlR-000E5H-Mh for netconf@ops.ietf.org; Thu, 07 Jul 2005 01:01:17 +0000 Received: (qmail 12032 invoked by uid 78); 7 Jul 2005 00:59:08 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 7 Jul 2005 00:59:08 -0000 Message-ID: <42CC7E5B.2060908@andybierman.com> Date: Wed, 06 Jul 2005 17:59:07 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker CC: "David T. Perkins" , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <20050705215250.GA6068@boskop.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Wes Hardaker wrote: >>>>>>On Tue, 5 Jul 2005 23:52:50 +0200, Juergen Schoenwaelder said: >>>>>> >>>>>> > >Juergen> I wanted to make the configuration such that users who have >Juergen> authenticated using a cleartext channel will be treated >Juergen> differently from users who have authenticated over an >Juergen> encrypted channel. > >I agree this is actually a nice thing about SNMP. Users of mine >actually do just this because they have different avenues of security >coming in. Most system administrators would probably even like to do >something like this for telnet vs ssh, but can't, so they do the only >other acceptable thing which is to turn off telnet instead because >doing anything else would be completely insecure. > > We've discussed this in many forums before and many people claim this is an administrative issue, solved (for example) by disabling telnet support on devices and enabling ssh instead. There's no reason you can't have an element in the 'sessions' data model that describes the security-level in use. The agent can access the data as well (implementation-specific). >Juergen> If we do netconf access control, we should investigate how >Juergen> command line interfaces typically deal with access >Juergen> control. We should not constrain ourself by the VACM design >Juergen> since the number of non-default VACM tables I have seen on >Juergen> production systems is close to zero. If someone has different >Juergen> experiences with deployed VACM configurations, please speak >Juergen> up. > >I have described before in front of microphones that I think in an >ideal world we need some sort of pseudo-API in our RFCs that describe >*how* you need to use the data. IE, setup_new_user(username, >securitylevel, ...) would be described to perform these particular >SETs in SNMP to the mib objects. This is totally independent of the >protocol. Netconf needs something as well, IMHO, because if you think >just having the data in XML will let you magically stuff it in with >one command you're missing the very big light on the front of the >train that is about to run you over. Unfortunately, it's not that >easy, because you need to worry about testing for existence of user >names that already exist, do an replace if they do and you actually >wanted this, or abort if you didn't. Then ... Anyway, high level "to >do this frequent task, follow these steps" would be a great boon to >application writers and would potentially convince them to design >decent infrastructure in their agents and managers. > > I have been spending some cycles recently, trying to optimize some code design for NETCONF's strengths, and this is a critical area. The relationship between the data-driven approach (e.g., MIBs) and the object-level RPC method approach does not need to be understood by the NETCONF agent engine. IMO, there does not always have to be a mapping between them either, and that's why the 2 tier AC model I suggested is decoupled -- RPC method access and data model access are separate. This is probably not the mailing list to debate API design, but the protocol supports individual RPC methods for a procedural approach, and it also supports a core operation set on a configuration datastore represented as an XML instance document. IMO, there is no intention in the document to constrain RPC usage in any way, and any coupling between static data models and particular RPC methods is outside the scope of the protocol. For example, in SNMP we would define a "resetDevice" OBJECT-TYPE macro with a MAX-ACCESS or read-write, to reset the device. But this isn't data. There are no semantics in the value range, only semantics in the reset action itself. These "exec commands" do not need a data-oriented access mechanism. It can also be argued that high-level RPC methods that provide a procedural interface to some configuration tasks (e.g., add_bgp_peer) can stand on their own without being coupled to a static data model that can be accessed with edit-config. Andy >I normally try to shy away from talking about a particular project of >mine, but sometimes it serves as an example so I'm going to break my >personal rule this time. In Net-SNMP we had issues with the >complexity of the VACM for a long time as well. Having said that, we >have users that are using probably every aspect of its complexity in >their environments. The problem wasn't that it isn't useful, it was >that it's hard to understand and more importantly isn't needed for the >95% case. So, to fix this we added a ton of documentation about how >to set it up and added a few very simple configuration wrappers for >the 95% case that are easy to understand. The majority of our users >probably have lines similar to this in their snmp agent configuration >files: > > rocommunity public > rwuser wes > >And they're done. In 2 lines they've added like 8 rows to the VACM >tables without knowing anything about it. It's this sort of simple, >common-case API that the RFCs need to offer readers. With the advent >of the above "wrapping" configuration items and with the documentation >we get very few questions now, and if we do its frequently from people >trying to understand the more complex scenarios because they actually >need it. (as an aside the above configuration tokens actually have >additional parameters that add a single oid-tree restriction, add >minimum security level (default is authNoPriv, etc)). > >Visualizing how the whole ball of wax works is hard. Unfortunately, >in any system where you have a high degree of variation in how >something needs to work you're not going to get away from that. The >best you can do is to try and offer *both* a simple case and a hard >case. The problem with our RFCs is that 99% of the time because we >need the hard cases to exist, that's all we offer rather than offering >both. > > >(ok, as long as I'm breaking rules... pet project 2 for the day is >visualizing SNMPv3 VACM configuration from live data pulled from the network: > > http://net-policy.sourceforge.net/screenshots-2004-07-28/viz_snmpv3.png >) > > -- 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 Jul 06 21:44:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLR5-0001Wh-6D for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 21:44:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23804 for ; Wed, 6 Jul 2005 21:44:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqLMD-000IP4-9e for netconf-data@psg.com; Thu, 07 Jul 2005 01:39:17 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqLMA-000IOd-T7 for netconf@ops.ietf.org; Thu, 07 Jul 2005 01:39:15 +0000 Received: (eyou send program); Thu, 07 Jul 2005 09:40:35 +0800 Message-ID: <320743635.22612@njupt.edu.cn> X-EYOUMAIL-SMTPAUTH: y030737@njupt.edu.cn Received: from unknown (HELO nupt-d83898b16f) (10.10.136.120) by 202.119.230.11 with SMTP; Thu, 07 Jul 2005 09:40:35 +0800 Date: Thu, 7 Jul 2005 09:42:36 +0800 From: "=?gb2312?B?zfW6sQ==?=" To: "netconf" , "kwatsen" Subject: Re: how long should the manager maintain the connection with his device? X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon715833183554_=====" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_FONT_FACE_BAD,HTML_MESSAGE,HTML_TAG_EXIST_TBODY,MIME_BASE64_TEXT, MSGID_FROM_MTA_HEADER,RCVD_BY_IP autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --=====003_Dragon715833183554_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBLZW50IFdhdHNlbqOsIA0KICB0aGFua3MgZm9yIHlvdXIgcmVwbHkuIA0KICAgIA0KICAg ICAgYnV0IEkgcmVhbGx5IGNhbid0IGltYWdlIGEgc2luZ2xlIG1hY2hpbmUgaGFzIHRoZSBjYXBh YmlsaXR5IHRoYXQgbWFpbnRhaW5zICBwZXJzaXN0ZW5jZSBjb25uZWN0aW9ucw0Kd2l0aCAqNjAw MCogIGRldmljZS4gIA0KIFNvICBjb3VsZCB5b3UgcGxlYXNlIHRlbGwgbWUgdGhlIG1hY2hpbmUn cyB0eXBlLCBhbmQgaG93IGRvIHlvdSBnZXQgdGhlIG51bWJlciAiNjAwMCIgPz8NCqGhoaENCg0K PT09PT09PT0gMjAwNS0wNy0wNyAwNjo0MTo1NiAgS2VudCBXYXRzZW4gc2FpZKO6ID09PT09DQoN Cg0KVGhlIGR1cmF0aW9uIG9mIHRoZSBjb25uZWN0aW9uIGlzIGNsb3NlbHkgcmVsYXRlZCB0byBo b3cgb2Z0ZW4gdGhlIG5vbi1pbml0aWF0aW5nIHNpZGUgbmVlZHMgdG8gZmx1c2ggaXRzIGJ1ZmZl cnMgKGkuZS4gZXZlbnQgbm90aWZpY2F0aW9ucykuICBXZSBmaW5kIHRoYXQgcGVyc2lzdGVudCBj b25uZWN0aW9ucyB3b3JrIGZpbmUgZm9yIHVwIHRvIDYwMDAgZGV2aWNlcyAtIHRoaXMgaXMgdGhl IHByYWN0aWNhbCBjb25uZWN0aW9uIGxpbWl0IGZvciBhIHNpbmdsZSBtYWNoaW5lLiAgRm9yIG1v cmUgdGhhbiA2MDAwIGRldmljZXMsIGVpdGhlciBhIHNlcnZlci1jbHVzdGVyIG9yIGEgcGVyaW9k aWMtcG9sbCBhcmNoaXRlY3R1cmUgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCAtIHRoZSBjaG9pY2Ug cGVuZGluZyBvbiB0aGUgaW50ZXJhY3Rpb24gcmVxdWlyZW1lbnRzIG9mIHlvdXIgc3lzdGVtDQoN CldoZW4gTmV0Q29uZiBwdXJzdWVzIGV2ZW50IG5vdGlmaWNhdGlvbnMsIGluIGFkZGl0aW9uIHRv IGZvbGxvd2luZyB0aGUgcHVibGlzaC9zdWJzY3JpYmUgbWVzc2FnaW5nIHBhdHRlcm4gaXQgd291 bGQgYmUgZ29vZCB0byBhbHNvIGNvbnNpZGVyIHRoZSBkdXJhYmxlLXN1YnNjcmliZXIgYW5kIHBy aW9yaXR5LXF1ZXVpbmcgcGF0dGVybnMgZm9yIE5NU3Mgd2lzaGluZyB0byBoYXZlIG5vbi1wZXJz aXN0ZW50IGNvbm5lY3Rpb25zDQoNCktlbnQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogb3duZXItbmV0Y29uZkBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1uZXRjb25m QG9wcy5pZXRmLm9yZ10gT24gQmVoYWxmIE9mIHkwMzA3MzdAbmp1cHQuZWR1LmNuDQpTZW50OiBU dWVzZGF5LCBKdWx5IDA1LCAyMDA1IDg6MjEgUE0NClRvOiBuZXRjb25mDQpTdWJqZWN0OiBob3cg bG9uZyBzaG91bGQgdGhlIG1hbmFnZXIgbWFpbnRhaW4gdGhlIGNvbm5lY3Rpb24gd2l0aCBoaXMg ZGV2aWNlPw0KDQpoaSBhbGw6DQoNCiAgIEkgaGF2ZSByZWFkIHRoZSBuZXRjb25mLXBybzA2IGFu ZCAic2NhbGFiaWxpdHkgb2YgbmV0Y29uZiIgdG9waWMgb24gdGhlIGxpc3QsIEkgc2F3IA0KSnVl cmdlbiBTY2hvZW53YWVsZGVyIHNhaWQgaGUgZmluZCB0aGF0IGhvbGRpbmcgMzAwIFRDUCBjb25u ZWN0aW9ucyBpcyBub3QgYSBoYXJkIHRoaW5nLg0KDQogICBidXQgSSB3YW50IHRvIGtub3cgaW4g dGhlIHJlYWwgd29ybGQgLCBkb2VzIHRoZSBtYW5hZ2VyIGp1c3QgaG9sZCB0aGUgY29ubmVjdGlv biB3aGVuIHRoZXJlIGFyZSBzdGlsbCBzb21lIGNvbmZpZyBvcGVyYXRpb24gbmVlZCB0byBiZSBw ZXJmb3JtZWQgYW5kIHRoZSBjb25uZWN0aW9uIHdpbGwgYmUga2lsbCBhcyBzb29uIGFzIHRoZXNl IG9wZXJhdGlvbnMgY29tcGxldGVkPyAgT3IgaXQgd2lsbCBob2xkIHRoZSBjb25uZWN0aW9uIHdp dGggaGlzICJhZ2VudCIgYWxsIHRoZSB0aW1lIHVudGlsIHNvbWUgYWNjaWRlbnQgaGFwcGVucz8g DQoNCg0KdGhhbmtzIGZvciBjb21pbmcgaW4hDQoNCkJlc3QgUmVnYXJkcw0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCldhbmcgSGFuDQoNCnkw MzA3MzdAbmp1cHQuZWR1LmNuDQpSZXNlYXJjaCBDZW50ZXIgb2YgTmV0d29yayBUZWNobm9sb2d5 DQpOYW5qaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KLS0t oaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqg0KDQoN Cg0KtrJyenWyenqdqraJooqFrbJyerKVnbZ6gcZ3cnqnprWDsp0NCg0KDQoNClJlZ2FyZHMNCg0K V2FuZyBIYW4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KV2FuZyBIYW4NCg0KeTAzMDczN0BuanVwdC5lZHUuY24NClJlc2VhcmNo IENlbnRlciBvZiBOZXR3b3JrIFRlY2hub2xvZ3kNCk5hbmppbmcgVW5pdmVyc2l0eSBvZiBQb3N0 cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqh qqGqoaqhqqGqoaqhqqGqoaqhqqGqDQo= --=====003_Dragon715833183554_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjEyNjQiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2VhZWFl YT48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT3LzszlPkRlYXIgS2VudCBXYXRzZW6jrDwvRk9OVD4g DQo8L0ZPTlQ+DQo8RElWPiZuYnNwOyB0aGFua3MgZm9yIHlvdXIgcmVwbHkuIDwvRElWPg0KPERJ Vj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBidXQgSSByZWFsbHkgY2FuJ3QmbmJzcDtpbWFnZSBhIHNpbmdsZSANCm1hY2hpbmUg aGFzIHRoZSBjYXBhYmlsaXR5IHRoYXQgbWFpbnRhaW5zJm5ic3A7IHBlcnNpc3RlbmNlIGNvbm5l Y3Rpb25zPC9ESVY+DQo8RElWPndpdGggKjYwMDAqJm5ic3A7IGRldmljZS4mbmJzcDsgPC9ESVY+ DQo8RElWPiZuYnNwO1NvJm5ic3A7IGNvdWxkIHlvdSBwbGVhc2UgdGVsbCBtZSB0aGUgbWFjaGlu ZSdzIHR5cGUsIGFuZCBob3cgZG8geW91IA0KZ2V0IHRoZSBudW1iZXIgIjYwMDAiID8/PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+oaGhoTwvRk9OVD48L0RJVj4NCjxESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPjwvRElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+PT09PT09PT0gDQoyMDA1 LTA3LTA3Jm5ic3A7MDY6NDE6NTYmbmJzcDsgS2VudCBXYXRzZW4mbmJzcDtzYWlko7ogPT09PT08 L0ZPTlQ+PC9ESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ DQo8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICA8VEJPRFk+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9 IjEwMCUiPg0KICAgICAgPEJMT0NLUVVPVEUgDQogICAgICBzdHlsZT0iUEFERElORy1SSUdIVDog MHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMw MDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgICAgIDxESVY+VGhlJm5ic3A7ZHVyYXRpb24mbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2Nvbm5lY3Rpb24mbmJzcDtpcyZuYnNwO2Nsb3NlbHkmbmJzcDtyZWxhdGVkJm5ic3A7dG8m bmJzcDtob3cmbmJzcDtvZnRlbiZuYnNwO3RoZSZuYnNwO25vbi1pbml0aWF0aW5nJm5ic3A7c2lk ZSZuYnNwO25lZWRzJm5ic3A7dG8mbmJzcDtmbHVzaCZuYnNwO2l0cyZuYnNwO2J1ZmZlcnMmbmJz cDsoaS5lLiZuYnNwO2V2ZW50Jm5ic3A7bm90aWZpY2F0aW9ucykuJm5ic3A7Jm5ic3A7V2UmbmJz cDtmaW5kJm5ic3A7dGhhdCZuYnNwO3BlcnNpc3RlbnQmbmJzcDtjb25uZWN0aW9ucyZuYnNwO3dv cmsmbmJzcDtmaW5lJm5ic3A7Zm9yJm5ic3A7dXAmbmJzcDt0byZuYnNwOzYwMDAmbmJzcDtkZXZp Y2VzJm5ic3A7LSZuYnNwO3RoaXMmbmJzcDtpcyZuYnNwO3RoZSZuYnNwO3ByYWN0aWNhbCZuYnNw O2Nvbm5lY3Rpb24mbmJzcDtsaW1pdCZuYnNwO2ZvciZuYnNwO2EmbmJzcDtzaW5nbGUmbmJzcDtt YWNoaW5lLiZuYnNwOyZuYnNwO0ZvciZuYnNwO21vcmUmbmJzcDt0aGFuJm5ic3A7NjAwMCZuYnNw O2RldmljZXMsJm5ic3A7ZWl0aGVyJm5ic3A7YSZuYnNwO3NlcnZlci1jbHVzdGVyJm5ic3A7b3Im bmJzcDthJm5ic3A7cGVyaW9kaWMtcG9sbCZuYnNwO2FyY2hpdGVjdHVyZSZuYnNwO25lZWRzJm5i c3A7dG8mbmJzcDtiZSZuYnNwO2NvbnNpZGVyZWQmbmJzcDstJm5ic3A7dGhlJm5ic3A7Y2hvaWNl Jm5ic3A7cGVuZGluZyZuYnNwO29uJm5ic3A7dGhlJm5ic3A7aW50ZXJhY3Rpb24mbmJzcDtyZXF1 aXJlbWVudHMmbmJzcDtvZiZuYnNwO3lvdXImbmJzcDtzeXN0ZW08L0RJVj4NCiAgICAgICAgPERJ Vj4mbmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj5XaGVuJm5ic3A7TmV0Q29uZiZuYnNwO3B1cnN1 ZXMmbmJzcDtldmVudCZuYnNwO25vdGlmaWNhdGlvbnMsJm5ic3A7aW4mbmJzcDthZGRpdGlvbiZu YnNwO3RvJm5ic3A7Zm9sbG93aW5nJm5ic3A7dGhlJm5ic3A7cHVibGlzaC9zdWJzY3JpYmUmbmJz cDttZXNzYWdpbmcmbmJzcDtwYXR0ZXJuJm5ic3A7aXQmbmJzcDt3b3VsZCZuYnNwO2JlJm5ic3A7 Z29vZCZuYnNwO3RvJm5ic3A7YWxzbyZuYnNwO2NvbnNpZGVyJm5ic3A7dGhlJm5ic3A7ZHVyYWJs ZS1zdWJzY3JpYmVyJm5ic3A7YW5kJm5ic3A7cHJpb3JpdHktcXVldWluZyZuYnNwO3BhdHRlcm5z Jm5ic3A7Zm9yJm5ic3A7Tk1TcyZuYnNwO3dpc2hpbmcmbmJzcDt0byZuYnNwO2hhdmUmbmJzcDtu b24tcGVyc2lzdGVudCZuYnNwO2Nvbm5lY3Rpb25zPC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgICAgIDxESVY+S2VudDwvRElWPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElW Pg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgICA8RElWPi0tLS0tT3JpZ2luYWwm bmJzcDtNZXNzYWdlLS0tLS08L0RJVj4NCiAgICAgICAgPERJVj5Gcm9tOiZuYnNwO293bmVyLW5l dGNvbmZAb3BzLmlldGYub3JnJm5ic3A7W21haWx0bzpvd25lci1uZXRjb25mQG9wcy5pZXRmLm9y Z10mbmJzcDtPbiZuYnNwO0JlaGFsZiZuYnNwO09mJm5ic3A7eTAzMDczN0BuanVwdC5lZHUuY248 L0RJVj4NCiAgICAgICAgPERJVj5TZW50OiZuYnNwO1R1ZXNkYXksJm5ic3A7SnVseSZuYnNwOzA1 LCZuYnNwOzIwMDUmbmJzcDs4OjIxJm5ic3A7UE08L0RJVj4NCiAgICAgICAgPERJVj5UbzombmJz cDtuZXRjb25mPC9ESVY+DQogICAgICAgIDxESVY+U3ViamVjdDombmJzcDtob3cmbmJzcDtsb25n Jm5ic3A7c2hvdWxkJm5ic3A7dGhlJm5ic3A7bWFuYWdlciZuYnNwO21haW50YWluJm5ic3A7dGhl Jm5ic3A7Y29ubmVjdGlvbiZuYnNwO3dpdGgmbmJzcDtoaXMmbmJzcDtkZXZpY2U/PC9ESVY+DQog ICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+aGkmbmJzcDthbGw6PC9ESVY+ DQogICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7Jm5ic3A7Jm5i c3A7SSZuYnNwO2hhdmUmbmJzcDtyZWFkJm5ic3A7dGhlJm5ic3A7bmV0Y29uZi1wcm8wNiZuYnNw O2FuZCZuYnNwOyJzY2FsYWJpbGl0eSZuYnNwO29mJm5ic3A7bmV0Y29uZiImbmJzcDt0b3BpYyZu YnNwO29uJm5ic3A7dGhlJm5ic3A7bGlzdCwmbmJzcDtJJm5ic3A7c2F3Jm5ic3A7PC9ESVY+DQog ICAgICAgIDxESVY+SnVlcmdlbiZuYnNwO1NjaG9lbndhZWxkZXImbmJzcDtzYWlkJm5ic3A7aGUm bmJzcDtmaW5kJm5ic3A7dGhhdCZuYnNwO2hvbGRpbmcmbmJzcDszMDAmbmJzcDtUQ1AmbmJzcDtj b25uZWN0aW9ucyZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7YSZuYnNwO2hhcmQmbmJzcDt0aGluZy48 L0RJVj4NCiAgICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj4mbmJzcDsmbmJz cDsmbmJzcDtidXQmbmJzcDtJJm5ic3A7d2FudCZuYnNwO3RvJm5ic3A7a25vdyZuYnNwO2luJm5i c3A7dGhlJm5ic3A7cmVhbCZuYnNwO3dvcmxkJm5ic3A7LCZuYnNwO2RvZXMmbmJzcDt0aGUmbmJz cDttYW5hZ2VyJm5ic3A7anVzdCZuYnNwO2hvbGQmbmJzcDt0aGUmbmJzcDtjb25uZWN0aW9uJm5i c3A7d2hlbiZuYnNwO3RoZXJlJm5ic3A7YXJlJm5ic3A7c3RpbGwmbmJzcDtzb21lJm5ic3A7Y29u ZmlnJm5ic3A7b3BlcmF0aW9uJm5ic3A7bmVlZCZuYnNwO3RvJm5ic3A7YmUmbmJzcDtwZXJmb3Jt ZWQmbmJzcDthbmQmbmJzcDt0aGUmbmJzcDtjb25uZWN0aW9uJm5ic3A7d2lsbCZuYnNwO2JlJm5i c3A7a2lsbCZuYnNwO2FzJm5ic3A7c29vbiZuYnNwO2FzJm5ic3A7dGhlc2UmbmJzcDtvcGVyYXRp b25zJm5ic3A7Y29tcGxldGVkPyZuYnNwOyZuYnNwO09yJm5ic3A7aXQmbmJzcDt3aWxsJm5ic3A7 aG9sZCZuYnNwO3RoZSZuYnNwO2Nvbm5lY3Rpb24mbmJzcDt3aXRoJm5ic3A7aGlzJm5ic3A7ImFn ZW50IiZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDt1bnRpbCZuYnNwO3NvbWUmbmJz cDthY2NpZGVudCZuYnNwO2hhcHBlbnM/Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+dGhhbmtzJm5i c3A7Zm9yJm5ic3A7Y29taW5nJm5ic3A7aW4hPC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7PC9E SVY+DQogICAgICAgIDxESVY+QmVzdCZuYnNwO1JlZ2FyZHM8L0RJVj4NCiAgICAgICAgPERJVj4m bmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCiAgICAgICAgPERJVj5XYW5nJm5ic3A7SGFuPC9E SVY+DQogICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+eTAzMDczN0BuanVw dC5lZHUuY248L0RJVj4NCiAgICAgICAgPERJVj5SZXNlYXJjaCZuYnNwO0NlbnRlciZuYnNwO29m Jm5ic3A7TmV0d29yayZuYnNwO1RlY2hub2xvZ3k8L0RJVj4NCiAgICAgICAgPERJVj5OYW5qaW5n Jm5ic3A7VW5pdmVyc2l0eSZuYnNwO29mJm5ic3A7UG9zdHMmbmJzcDthbmQmbmJzcDtUZWxlY29t bXVuaWNhdGlvbnM8L0RJVj4NCiAgICAgICAgPERJVj4tLS2hqqGqoaqhqqGqoaqhqqGqoaqhqqGq oaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqPC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7PC9E SVY+DQogICAgICAgIDxESVY+trJyenWyenqdqraJooqFrbJyerKVnbZ6gcZ3cnqnprWDsp08L0RJ Vj48L0JMT0NLUVVPVEU+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJlZ2FyZHM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5XYW5nIEhhbjwv Rk9OVD48L0RJVj48L0RJVj4NCjxESVY+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgDQpz aXplPTI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPC9GT05UPjwvRElWPg0KPERJVj5XYW5nIEhhbjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+eTAzMDczN0A8QSBocmVmPSJtYWlsdG86eTAzMDczN0BuanVwdC5lZHUuY24i Pm5qdXB0LmVkdS5jbjwvQT48L0RJVj4NCjxESVY+UmVzZWFyY2ggQ2VudGVyIG9mIE5ldHdvcmsg VGVjaG5vbG9neTxCUj5OYW5qaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIA0KVGVsZWNvbW11 bmljYXRpb25zPEJSPqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGq oaqhqqGqoao8L0RJVj48L0RJVj48L0RJVj4NCjxESVY+DQo8UD4mbmJzcDs8L1A+PC9ESVY+PC9C T0RZPjwvSFRNTD4NCg== --=====003_Dragon715833183554_=====-- -- 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 Jul 06 23:06:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqMix-0006yM-6v for netconf-archive@megatron.ietf.org; Wed, 06 Jul 2005 23:06:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28467 for ; Wed, 6 Jul 2005 23:06:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqMc3-0000SB-K2 for netconf-data@psg.com; Thu, 07 Jul 2005 02:59:43 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqMc1-0000Re-Lt for netconf@ops.ietf.org; Thu, 07 Jul 2005 02:59:42 +0000 Received: (eyou send program); Thu, 07 Jul 2005 11:01:05 +0800 Message-ID: <320748465.23165@njupt.edu.cn> X-EYOUMAIL-SMTPAUTH: y030737@njupt.edu.cn Received: from unknown (HELO nupt-d83898b16f) (10.10.136.120) by 202.119.230.11 with SMTP; Thu, 07 Jul 2005 11:01:05 +0800 Date: Thu, 7 Jul 2005 11:03:05 +0800 From: "=?gb2312?B?zfW6sQ==?=" To: "netconf" Subject: why we need ? is enough. X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_HEADER,RCVD_BY_IP autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: I find the can support all function of the operation, so why do we still need the copy-config operation? Best Regards Wang Han -- 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 Jul 07 02:45:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQ8H-0005Z1-Mu for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 02:45:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03844 for ; Thu, 7 Jul 2005 02:45:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqQ28-000PwB-2H for netconf-data@psg.com; Thu, 07 Jul 2005 06:38:52 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqIab-0002Lc-U2 for netconf@ops.ietf.org; Wed, 06 Jul 2005 22:41:57 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by borg.juniper.net with ESMTP; 06 Jul 2005 15:41:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,266,1115017200"; d="scan'208"; a="431874708:sNHT26598200" Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 15:41:56 -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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: how long should the manager maintain the connection with his device? Date: Wed, 6 Jul 2005 15:41:56 -0700 Message-ID: Thread-Topic: how long should the manager maintain the connection with his device? Thread-Index: AcWB2Wd8sea90zGaTX2P0vSD6Dz7+AAlaosg From: "Kent Watsen" To: "??" , "netconf" X-OriginalArrivalTime: 06 Jul 2005 22:41:56.0813 (UTC) FILETIME=[E9FC1FD0:01C5827B] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 DQpUaGUgZHVyYXRpb24gb2YgdGhlIGNvbm5lY3Rpb24gaXMgY2xvc2VseSByZWxhdGVkIHRvIGhv dyBvZnRlbiB0aGUgbm9uLWluaXRpYXRpbmcgc2lkZSBuZWVkcyB0byBmbHVzaCBpdHMgYnVmZmVy cyAoaS5lLiBldmVudCBub3RpZmljYXRpb25zKS4gIFdlIGZpbmQgdGhhdCBwZXJzaXN0ZW50IGNv bm5lY3Rpb25zIHdvcmsgZmluZSBmb3IgdXAgdG8gNjAwMCBkZXZpY2VzIC0gdGhpcyBpcyB0aGUg cHJhY3RpY2FsIGNvbm5lY3Rpb24gbGltaXQgZm9yIGEgc2luZ2xlIG1hY2hpbmUuICBGb3IgbW9y ZSB0aGFuIDYwMDAgZGV2aWNlcywgZWl0aGVyIGEgc2VydmVyLWNsdXN0ZXIgb3IgYSBwZXJpb2Rp Yy1wb2xsIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBiZSBjb25zaWRlcmVkIC0gdGhlIGNob2ljZSBw ZW5kaW5nIG9uIHRoZSBpbnRlcmFjdGlvbiByZXF1aXJlbWVudHMgb2YgeW91ciBzeXN0ZW0NCg0K V2hlbiBOZXRDb25mIHB1cnN1ZXMgZXZlbnQgbm90aWZpY2F0aW9ucywgaW4gYWRkaXRpb24gdG8g Zm9sbG93aW5nIHRoZSBwdWJsaXNoL3N1YnNjcmliZSBtZXNzYWdpbmcgcGF0dGVybiBpdCB3b3Vs ZCBiZSBnb29kIHRvIGFsc28gY29uc2lkZXIgdGhlIGR1cmFibGUtc3Vic2NyaWJlciBhbmQgcHJp b3JpdHktcXVldWluZyBwYXR0ZXJucyBmb3IgTk1TcyB3aXNoaW5nIHRvIGhhdmUgbm9uLXBlcnNp c3RlbnQgY29ubmVjdGlvbnMNCg0KS2VudA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBvd25lci1uZXRjb25mQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLW5ldGNvbmZA b3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgeTAzMDczN0BuanVwdC5lZHUuY24NClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMDUsIDIwMDUgODoyMSBQTQ0KVG86IG5ldGNvbmYNClN1YmplY3Q6IGhvdyBs b25nIHNob3VsZCB0aGUgbWFuYWdlciBtYWludGFpbiB0aGUgY29ubmVjdGlvbiB3aXRoIGhpcyBk ZXZpY2U/DQoNCmhpIGFsbDoNCg0KICAgSSBoYXZlIHJlYWQgdGhlIG5ldGNvbmYtcHJvMDYgYW5k ICJzY2FsYWJpbGl0eSBvZiBuZXRjb25mIiB0b3BpYyBvbiB0aGUgbGlzdCwgSSBzYXcgDQpKdWVy Z2VuIFNjaG9lbndhZWxkZXIgc2FpZCBoZSBmaW5kIHRoYXQgaG9sZGluZyAzMDAgVENQIGNvbm5l Y3Rpb25zIGlzIG5vdCBhIGhhcmQgdGhpbmcuDQoNCiAgIGJ1dCBJIHdhbnQgdG8ga25vdyBpbiB0 aGUgcmVhbCB3b3JsZCAsIGRvZXMgdGhlIG1hbmFnZXIganVzdCBob2xkIHRoZSBjb25uZWN0aW9u IHdoZW4gdGhlcmUgYXJlIHN0aWxsIHNvbWUgY29uZmlnIG9wZXJhdGlvbiBuZWVkIHRvIGJlIHBl cmZvcm1lZCBhbmQgdGhlIGNvbm5lY3Rpb24gd2lsbCBiZSBraWxsIGFzIHNvb24gYXMgdGhlc2Ug b3BlcmF0aW9ucyBjb21wbGV0ZWQ/ICBPciBpdCB3aWxsIGhvbGQgdGhlIGNvbm5lY3Rpb24gd2l0 aCBoaXMgImFnZW50IiBhbGwgdGhlIHRpbWUgdW50aWwgc29tZSBhY2NpZGVudCBoYXBwZW5zPyAN Cg0KDQp0aGFua3MgZm9yIGNvbWluZyBpbiENCg0KQmVzdCBSZWdhcmRzDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV2FuZyBIYW4NCg0KeTAz MDczN0BuanVwdC5lZHUuY24NClJlc2VhcmNoIENlbnRlciBvZiBOZXR3b3JrIFRlY2hub2xvZ3kN Ck5hbmppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQotLS3i gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJQNCg0KDQoNCuaBq3J6deeetnrmvb3np7nula/lj5rnnqh655+U 5r6PeuS8t3dyetCV56Wq55+fDQo= -- 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 Jul 07 07:54:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqUxc-0001VH-Ms for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 07:54:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27443 for ; Thu, 7 Jul 2005 07:54:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqUpJ-000BKr-Hd for netconf-data@psg.com; Thu, 07 Jul 2005 11:45:57 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqUpA-000BJK-QE for netconf@ops.ietf.org; Thu, 07 Jul 2005 11:45:48 +0000 Received: from pc6 (1Cust240.tnt103.lnd4.gbr.da.uu.net [213.116.54.240]) by astro.systems.pipex.net (Postfix) with SMTP id 97E75E0000EF; Thu, 7 Jul 2005 12:45:37 +0100 (BST) Message-ID: <03d201c582e0$f4f04780$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Andy Bierman" Cc: References: <200507051851.j65Ipqi7027356@ns-mr6.netsolmail.com> <42CB065C.6050306@andybierman.com> Subject: Re: Proposed Update to Netconf Charter Date: Thu, 7 Jul 2005 12:35:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Andy Bierman" To: Cc: "'Sharon Chisholm'" ; Sent: Wednesday, July 06, 2005 12:14 AM Subject: Re: Proposed Update to Netconf Charter > > Since you asked... > > IMO, we need a simple 2-tier access control model > that is independent of higher layer abstractions. > > 1) access is by group-name, and a group contains a list of user names. > A user can be included in any number of groups. I would like to see groups permitted to contain group-names as well as users, at least in a simple tree structure (ie recursive membership not allowed). This has been a feature of Windows-style access control for many years and I would not want to be without it, particularly when there are predefined groups (eg from the provider of the software, not necessarily specified in a standard) to help get the system up and running quickly. > > 2) tier 1 is RPC method access, which is defined by the tuple: > { namespace-uri, method-name } > and access is granted by configuring via the tuple > { namespace-uri, method-name, group-list } -- 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 Jul 07 07:54:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqUxa-0001Up-UY for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 07:54:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27438 for ; Thu, 7 Jul 2005 07:54:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqUpH-000BKQ-73 for netconf-data@psg.com; Thu, 07 Jul 2005 11:45:55 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqUpE-000BJv-63 for netconf@ops.ietf.org; Thu, 07 Jul 2005 11:45:52 +0000 Received: from pc6 (1Cust240.tnt103.lnd4.gbr.da.uu.net [213.116.54.240]) by astro.systems.pipex.net (Postfix) with SMTP id 60E7FE000050; Thu, 7 Jul 2005 12:45:47 +0100 (BST) Message-ID: <03d301c582e0$f5d9bd20$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Faye Ly" , "Andy Bierman" Cc: References: Subject: Re: Proposed Update to Netconf Charter Date: Thu, 7 Jul 2005 12:43:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Faye Ly" To: "Andy Bierman" ; "Sharon Chisholm" Cc: Sent: Wednesday, July 06, 2005 8:14 PM Subject: RE: Proposed Update to Netconf Charter Andy, I agree with 'defining common authentication scheme for access control' and also would like to see 'define a way to multiplex channels over a single secured connection between manager and agent'. The latter is needed to support multiple management channels like notification, syslog, image/file management and/or regular netconf. This is to help lower the cost of configuring many secured connections between manager and agent. -faye Common authentication implies that you are authenticating the same thing. SNMP, because the operators wanted it, authenticates a 'principal' which may or may not correspond to a human user, but is distinct from the platform which is providing the other end of the connection. I think it easy, and at times too simplistic, to think in terms of setting up a secure channel with, and authenticating, a 'client' (or server) without realising that one should be authenticating at a finer level of detail. The 'principals' for syslog, netconf etc may be different even though they share a secure channel and platform. -- 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 Jul 07 09:05:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqW4F-0001oz-ID for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 09:05:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03748 for ; Thu, 7 Jul 2005 09:05:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqVzn-000KQ5-GB for netconf-data@psg.com; Thu, 07 Jul 2005 13:00:51 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqVzj-000KPQ-GJ for netconf@ops.ietf.org; Thu, 07 Jul 2005 13:00:47 +0000 Received: (qmail 31966 invoked by uid 78); 7 Jul 2005 13:00:46 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail7.netsol.inquent.com with SMTP; 7 Jul 2005 13:00:46 -0000 Message-ID: <42CD2719.603@andybierman.com> Date: Thu, 07 Jul 2005 05:59:05 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch CC: Faye Ly , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <03d301c582e0$f5d9bd20$0601a8c0@pc6> In-Reply-To: <03d301c582e0$f5d9bd20$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tom Petch wrote: > >Tom Petch > >----- Original Message ----- >From: "Faye Ly" >To: "Andy Bierman" ; "Sharon Chisholm" > >Cc: >Sent: Wednesday, July 06, 2005 8:14 PM >Subject: RE: Proposed Update to Netconf Charter > > >Andy, > >I agree with 'defining common authentication scheme for access control' >and also would like to see 'define a way to multiplex channels over a >single secured connection between manager and agent'. The latter is >needed to support multiple management channels like notification, >syslog, image/file management and/or regular netconf. > >This is to help lower the cost of configuring many secured connections >between manager and agent. > >-faye > >Common authentication implies that you are authenticating the same thing. SNMP, >because the operators wanted it, authenticates a 'principal' which may or may >not correspond to a human user, but is distinct from the platform which is >providing the other end of the connection. I think it easy, and at times too >simplistic, to think in terms of setting up a secure channel with, and >authenticating, a 'client' (or server) without realising that one should be >authenticating at a finer level of detail. The 'principals' for syslog, netconf >etc may be different even though they share a secure channel and platform. > > Good points. I'll raise an even stronger concern... SNMP has its own security model, which (IMO) is bloated and over-engineered. I am strongly opposed to any integration between SNMP and NETCONF security models because NETCONF is new and we should try not to ruin it so soon. NETCONF is not SNMPv4 and never will be if I can help it, and its security mechanisms should not be compromised to work well for SNMP (or SYSLOG or anything else, other than NETCONF). 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 Jul 07 09:21:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWJc-00018P-1U for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 09:21:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05224 for ; Thu, 7 Jul 2005 09:21:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqWEF-000MJ2-4l for netconf-data@psg.com; Thu, 07 Jul 2005 13:15:47 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqWED-000MIm-KO for netconf@ops.ietf.org; Thu, 07 Jul 2005 13:15:45 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2005 06:15:45 -0700 X-IronPort-AV: i="3.93,269,1115017200"; d="scan'208"; a="647493803:sNHT28124054" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j67DFdvM010018; Thu, 7 Jul 2005 06:15:39 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4148.cisco.com [10.61.80.51]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j67DEiV1016684; Thu, 7 Jul 2005 06:14:45 -0700 Message-ID: <42CD2AFD.5040202@cisco.com> Date: Thu, 07 Jul 2005 15:15:41 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman CC: Tom Petch , Faye Ly , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <03d301c582e0$f5d9bd20$0601a8c0@pc6> <42CD2719.603@andybierman.com> In-Reply-To: <42CD2719.603@andybierman.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120742086.498700"; x:"432200"; a:"rsa-sha1"; b:"nofws:205"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"iyVaK7o2dvRAWNEBzGPQkagqe2EPl8QphHsSwAf48t7UVgl531j6x/T7E/DZQbsLgkq7oon9" "Nfa6oZWUkQl7tYGlMV/GxpwzULhwwD9KucGGy0VxY840WVa1CkvQYiEdlNicQFXvycdIQLWcEHy" "owXGMp9R2ebXMBlRTFcgK0ss="; c:"Date: Thu, 07 Jul 2005 15:15:41 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: Proposed Update to Netconf Charter" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy, At this point, the only thing contemplated would be to make use of the same authentication mechanisms - not authorization mechanisms. And the way that it is contemplated is through the use of BEEP, perhaps even sharing a BEEP 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 Thu Jul 07 13:07:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZqu-0000Ym-Io for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 13:07:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26259 for ; Thu, 7 Jul 2005 13:07:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqZh6-000PXU-7u for netconf-data@psg.com; Thu, 07 Jul 2005 16:57:48 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqZh3-000PWw-E8 for netconf@ops.ietf.org; Thu, 07 Jul 2005 16:57:45 +0000 Received: (qmail 5703 invoked by uid 78); 7 Jul 2005 16:23:53 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail7.netsol.inquent.com with SMTP; 7 Jul 2005 16:23:53 -0000 Message-ID: <42CD569D.7020405@andybierman.com> Date: Thu, 07 Jul 2005 09:21:49 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: Tom Petch , Faye Ly , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <03d301c582e0$f5d9bd20$0601a8c0@pc6> <42CD2719.603@andybierman.com> <42CD2AFD.5040202@cisco.com> In-Reply-To: <42CD2AFD.5040202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: >Andy, > >At this point, the only thing contemplated would be to make use of the >same authentication mechanisms - not authorization mechanisms. And the >way that it is contemplated is through the use of BEEP, perhaps even >sharing a BEEP session. > > I understand that -- the thought of making VACM or something like it work for NETCONF is what concerns me. Integrated authentication sounds great until you get into the details, or until you read our charter. It is going to be a tough sell to convince those of us in the WG that don't care about integrating SNMP and NETCONF to compromise or otherwise over-engineer a solution that accommodates other protocols beyond NETCONF. If somebody posted a draft containing a brilliant solution to the problem I would probably change my mind. But I don't see any drafts (clueless or brilliant), so until then I don't think integrated authentication is something this WG should do. Andy >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: > > > > -- 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 Jul 07 13:17:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqa04-0006Ws-Po for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 13:17:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26932 for ; Thu, 7 Jul 2005 13:17:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqZs1-0000vp-MK for netconf-data@psg.com; Thu, 07 Jul 2005 17:09:05 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqZs0-0000vX-6E for netconf@ops.ietf.org; Thu, 07 Jul 2005 17:09:04 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2005 10:09:04 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j67H8wvM012784; Thu, 7 Jul 2005 10:08:58 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4416.cisco.com [10.61.81.63]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j67H823G018567; Thu, 7 Jul 2005 10:08:03 -0700 Message-ID: <42CD61AC.8050301@cisco.com> Date: Thu, 07 Jul 2005 19:09:00 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman CC: Tom Petch , Faye Ly , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter References: <03d301c582e0$f5d9bd20$0601a8c0@pc6> <42CD2719.603@andybierman.com> <42CD2AFD.5040202@cisco.com> <42CD569D.7020405@andybierman.com> In-Reply-To: <42CD569D.7020405@andybierman.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120756084.936397"; x:"432200"; a:"rsa-sha1"; b:"nofws:97"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"D5QvRteqp+GoIAuBUHQ39IkbJCAbf5JMHlG3IfY6Mj5lJmUfUrlHEX9T0943hYAtGrYMwiRL" "IayozoKKdm+Z5rRMj7dLMGeOxGc9VOt3k57KrPvD+kpvBSSrvyaa/NUIGP8XUCQX+rzdniomXm0" "KLN+wpY0ijBJI+0BoT1nMXZU="; c:"Date: Thu, 07 Jul 2005 19:09:00 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: Proposed Update to Netconf Charter" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy, We will post a draft. We're not asking anything of the NETCONF working group. This is all going on in ISMS. 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 Thu Jul 07 22:31:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqieI-0003Er-Vi for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 22:31:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27156 for ; Thu, 7 Jul 2005 22:31:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqiWK-000Izi-1Z for netconf-data@psg.com; Fri, 08 Jul 2005 02:23:16 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqiWJ-000IzS-0v for netconf@ops.ietf.org; Fri, 08 Jul 2005 02:23:15 +0000 Received: (qmail 28885 invoked by uid 78); 8 Jul 2005 02:23:14 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail6.netsol.inquent.com with SMTP; 8 Jul 2005 02:23:14 -0000 Message-ID: <42CDE316.9070804@andybierman.com> Date: Thu, 07 Jul 2005 19:21:10 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bert Wijnen CC: Simon Leinen , David Kessens , netconf , iesg-secretary@ietf.org Subject: I-D Publication Request: draft-ietf-netconf-ssh-04.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Area] OPS-NM [WG] NETCONF [I-D] draft-ietf-netconf-ssh-04.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt [Shep] Andy Bierman 1.a) Yes, the WG Chairs have reviewed this version of the document, and believe it is ready for publication. 1.b) Yes the document has had adequate review. Several WG members have reviewed this document. It has also been reviewed by non-WG members very familiar with SSH. 1.c) There are no open issues, and no further review is required, for this document. 1.d) There are no concerns with this document at this time. It is possible that clarifications will be identified as implementation and interoperability experience is reported to the WG. 1.e) There is overwhelming WG consensus for this document. This is the mandatory-to-implement application mapping for the NETCONF protocol. It is expected that script developers that currently use SSH to access the CLI interface of a network device will be most likely to choose this application mapping. 1.f) No appeals have been threatened against this document. 1.g) There are some minor ID-nits that will be fixed before RFC publication. (See ID-nit log below). 1.h) Yes, references are split. Yes, there is a reference to an unpublished document, namely the NETCONF Configuration Protocol document (draft-ietf-netconf-prot-07.txt), but this is also ready for publication. 1.j) I-D Submission Summary Technical Summary This document describes a method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. ---------------- [ID-nit log] idnits 1.74 tmp/draft-ietf-netconf-ssh-04.txt: tmp/draft-ietf-netconf-ssh-04.txt(4): Line is too long: the offending characters are '.' tmp/draft-ietf-netconf-ssh-04.txt(5): Line is too long: the offending characters are '5' tmp/draft-ietf-netconf-ssh-04.txt(25): Line is too long: the offending characters are 's' tmp/draft-ietf-netconf-ssh-04.txt(44): Line is too long: the offending characters are 'F' tmp/draft-ietf-netconf-ssh-04.txt(59): Line is too long: the offending characters are '3' tmp/draft-ietf-netconf-ssh-04.txt(60): Line is too long: the offending characters are '3' tmp/draft-ietf-netconf-ssh-04.txt(61): Line is too long: the offending characters are '4' tmp/draft-ietf-netconf-ssh-04.txt(62): Line is too long: the offending characters are '5' tmp/draft-ietf-netconf-ssh-04.txt(63): Line is too long: the offending characters are '6' tmp/draft-ietf-netconf-ssh-04.txt(64): Line is too long: the offending characters are '6' tmp/draft-ietf-netconf-ssh-04.txt(65): Line is too long: the offending characters are '7' tmp/draft-ietf-netconf-ssh-04.txt(66): Line is too long: the offending characters are '7' tmp/draft-ietf-netconf-ssh-04.txt(67): Line is too long: the offending characters are '8' tmp/draft-ietf-netconf-ssh-04.txt(68): Line is too long: the offending characters are '8' tmp/draft-ietf-netconf-ssh-04.txt(69): Line is too long: the offending characters are '8' tmp/draft-ietf-netconf-ssh-04.txt(70): Line is too long: the offending characters are '8' tmp/draft-ietf-netconf-ssh-04.txt(71): Line is too long: the offending characters are '0' tmp/draft-ietf-netconf-ssh-04.txt(115): Line is too long: the offending characters are 'l' tmp/draft-ietf-netconf-ssh-04.txt(116): Line is too long: the offending characters are 's' tmp/draft-ietf-netconf-ssh-04.txt(125): Line is too long: the offending characters are 'o' tmp/draft-ietf-netconf-ssh-04.txt(128): Line is too long: the offending characters are 'e' tmp/draft-ietf-netconf-ssh-04.txt(138): Line is too long: the offending characters are 't' tmp/draft-ietf-netconf-ssh-04.txt(146): Line is too long: the offending characters are 'n' tmp/draft-ietf-netconf-ssh-04.txt(156): Line is too long: the offending characters are 'T' tmp/draft-ietf-netconf-ssh-04.txt(159): Line is too long: the offending characters are 'f' tmp/draft-ietf-netconf-ssh-04.txt(226): Line is too long: the offending characters are 's' tmp/draft-ietf-netconf-ssh-04.txt(227): Line is too long: the offending characters are '.' tmp/draft-ietf-netconf-ssh-04.txt(239): Line is too long: the offending characters are 'L' tmp/draft-ietf-netconf-ssh-04.txt(241): Line is too long: the offending characters are 'o' tmp/draft-ietf-netconf-ssh-04.txt(251): Line is too long: the offending characters are '1.0">' tmp/draft-ietf-netconf-ssh-04.txt(297): Line is too long: the offending characters are '1.0">' tmp/draft-ietf-netconf-ssh-04.txt(303): Line is too long: the offending characters are '0">' tmp/draft-ietf-netconf-ssh-04.txt(312): Line is too long: the offending characters are 'd' tmp/draft-ietf-netconf-ssh-04.txt(317): Line is too long: the offending characters are 'n' tmp/draft-ietf-netconf-ssh-04.txt(321): Line is too long: the offending characters are 'r' tmp/draft-ietf-netconf-ssh-04.txt(347): Line is too long: the offending characters are 'e' tmp/draft-ietf-netconf-ssh-04.txt(352): Line is too long: the offending characters are 'e' tmp/draft-ietf-netconf-ssh-04.txt(533): Line is too long: the offending characters are 'n' Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (Expected a match on the following text: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.") (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. -- 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 Jul 07 22:31:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqieN-0003F4-Kb for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 22:31:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27176 for ; Thu, 7 Jul 2005 22:31:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqiVh-000Ivf-1D for netconf-data@psg.com; Fri, 08 Jul 2005 02:22:37 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqiVf-000IvM-3c for netconf@ops.ietf.org; Fri, 08 Jul 2005 02:22:35 +0000 Received: (qmail 19739 invoked by uid 78); 8 Jul 2005 02:22:23 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail7.netsol.inquent.com with SMTP; 8 Jul 2005 02:22:23 -0000 Message-ID: <42CDE2E3.7060902@andybierman.com> Date: Thu, 07 Jul 2005 19:20:19 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bert Wijnen CC: Simon Leinen , David Kessens , netconf , iesg-secretary@ietf.org Subject: I-D Publication Request: draft-ietf-netconf-prot-07.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Area] OPS-NM [WG] NETCONF [I-D] draft-ietf-netconf-prot-07.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt [Shep] Simon Leinen 1.a) Yes, the WG Chairs have reviewed this version of the document, and believe it is ready for publication. 1.b) Yes the document has had adequate review. Several WG members have reviewed this document. It has also been reviewed by non-WG members very familiar with XML, security, and network operations. 1.c) There are no open issues, and no further review is required, for this document. 1.d) There are no concerns with this document at this time. It is possible that clarifications will be identified as implementation and interoperability experience is reported to the WG. 1.e) There is overwhelming WG consensus for this document. 1.f) No appeals have been threatened against this document. 1.g) There are no ID-nit issues in the document identified at this time. (See ID-nit log below). 1.h) Yes, references are split. No, there are no references to any unpublished documents. 1.j) I-D Submission Summary Technical Summary 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. Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. ---------------- [ID-nit log] idnits 1.74 tmp/draft-ietf-netconf-prot-07.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found. -- 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 Jul 07 22:31:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqieV-0003FM-2J for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 22:31: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 WAA27200 for ; Thu, 7 Jul 2005 22:31:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqiWh-000J0k-Ta for netconf-data@psg.com; Fri, 08 Jul 2005 02:23:39 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqiWh-000J0Y-1X for netconf@ops.ietf.org; Fri, 08 Jul 2005 02:23:39 +0000 Received: (qmail 30835 invoked by uid 78); 8 Jul 2005 02:23:38 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 8 Jul 2005 02:23:38 -0000 Message-ID: <42CDE32A.2040405@andybierman.com> Date: Thu, 07 Jul 2005 19:21:30 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bert Wijnen CC: Simon Leinen , David Kessens , netconf , iesg-secretary@ietf.org Subject: I-D Publication Request: draft-ietf-netconf-soap-05.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Area] OPS-NM [WG] NETCONF [I-D] draft-ietf-netconf-soap-05.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt [Shep] Andy Bierman 1.a) Yes, the WG Chairs have reviewed this version of the document, and believe it is ready for publication. 1.b) Yes the document has had adequate review. Several WG members have reviewed this document. 1.c) There are no open issues, and no further review is required, for this document. 1.d) There are no concerns with this document at this time. It is possible that clarifications will be identified as implementation and interoperability experience is reported to the WG. 1.e) There is strong WG consensus for this document. It is expected that more complex network applications (e.g., 1st or 3rd party commercial applications) will use this application mapping for NETCONF. 1.f) No appeals have been threatened against this document. 1.g) There are some minor ID-nits that will be fixed before RFC publication. (See ID-nit log below). 1.h) Yes, references are split. Yes, there is a reference to an unpublished document, namely the NETCONF Configuration Protocol document (draft-ietf-netconf-prot-07.txt), but this is also ready for publication. 1.j) I-D Submission Summary Technical Summary The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over BEEP bindings for NETCONF. Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. ---------------- [ID-nit log] idnits 1.74 tmp/draft-ietf-netconf-soap-05.txt: tmp/draft-ietf-netconf-soap-05.txt(452): Line is too long: the offending characters are 'elope"' tmp/draft-ietf-netconf-soap-05.txt(464): Line is too long: the offending characters are 's:netconf:base:1.0">' Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (Expected a match on the following text: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.") (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. -- 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 Jul 07 22:32:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqifc-0003ju-VB for netconf-archive@megatron.ietf.org; Thu, 07 Jul 2005 22:32:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27267 for ; Thu, 7 Jul 2005 22:32:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqiVy-000Iwc-Hy for netconf-data@psg.com; Fri, 08 Jul 2005 02:22:54 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DqiVv-000IwN-IE for netconf@ops.ietf.org; Fri, 08 Jul 2005 02:22:51 +0000 Received: (qmail 28716 invoked by uid 78); 8 Jul 2005 02:22:50 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 8 Jul 2005 02:22:50 -0000 Message-ID: <42CDE2FE.7010100@andybierman.com> Date: Thu, 07 Jul 2005 19:20:46 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bert Wijnen CC: Simon Leinen , David Kessens , netconf , iesg-secretary@ietf.org Subject: I-D Publication Request: draft-ietf-netconf-beep-05.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Area] OPS-NM [WG] NETCONF [I-D] draft-ietf-netconf-beep-05.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt [Shep] Andy Bierman 1.a) Yes, the WG Chairs have reviewed this version of the document, and believe it is ready for publication. 1.b) Yes the document has had adequate review. Several WG members have reviewed this document. It has also been reviewed by non-WG members very familiar with BEEP. 1.c) There are no open issues, and no further review is required, for this document. 1.d) There are no concerns with this document at this time. It is possible that clarifications will be identified as implementation and interoperability experience is reported to the WG. 1.e) There is overwhelming WG consensus for this document. It is expected that more complex network applications (e.g., 1st or 3rd party commercial applications) will use this application mapping for NETCONF. 1.f) No appeals have been threatened against this document. 1.g) There are some minor ID-nits that will be fixed before RFC publication. (See ID-nit log below). 1.h) Yes, references are split. Yes, there is a reference to an unpublished document, namely the NETCONF Configuration Protocol document (draft-ietf-netconf-prot-07.txt), but this is also ready for publication. 1.j) I-D Submission Summary Technical Summary This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. The WG would like to thank Marshall Rose for his assistance with portions of this document. ---------------- [ID-nit log] idnits 1.74 tmp/draft-ietf-netconf-beep-05.txt: tmp/draft-ietf-netconf-beep-05.txt(5): Line is too long: the offending characters are '5' tmp/draft-ietf-netconf-beep-05.txt(24): Line is too long: the offending characters are 's' tmp/draft-ietf-netconf-beep-05.txt(44): Line is too long: the offending characters are '.' tmp/draft-ietf-netconf-beep-05.txt(61): Line is too long: the offending characters are '3' tmp/draft-ietf-netconf-beep-05.txt(62): Line is too long: the offending characters are '3' tmp/draft-ietf-netconf-beep-05.txt(63): Line is too long: the offending characters are '4' tmp/draft-ietf-netconf-beep-05.txt(64): Line is too long: the offending characters are '4' tmp/draft-ietf-netconf-beep-05.txt(65): Line is too long: the offending characters are '4' tmp/draft-ietf-netconf-beep-05.txt(66): Line is too long: the offending characters are '6' tmp/draft-ietf-netconf-beep-05.txt(67): Line is too long: the offending characters are '6' tmp/draft-ietf-netconf-beep-05.txt(68): Line is too long: the offending characters are '6' tmp/draft-ietf-netconf-beep-05.txt(69): Line is too long: the offending characters are '8' tmp/draft-ietf-netconf-beep-05.txt(70): Line is too long: the offending characters are '9' tmp/draft-ietf-netconf-beep-05.txt(71): Line is too long: the offending characters are '0' tmp/draft-ietf-netconf-beep-05.txt(72): Line is too long: the offending characters are '1' tmp/draft-ietf-netconf-beep-05.txt(73): Line is too long: the offending characters are '1' tmp/draft-ietf-netconf-beep-05.txt(74): Line is too long: the offending characters are '1' tmp/draft-ietf-netconf-beep-05.txt(75): Line is too long: the offending characters are '2' tmp/draft-ietf-netconf-beep-05.txt(76): Line is too long: the offending characters are '3' tmp/draft-ietf-netconf-beep-05.txt(77): Line is too long: the offending characters are '4' tmp/draft-ietf-netconf-beep-05.txt(119) : Line is too long: the offending characters are 'r' tmp/draft-ietf-netconf-beep-05.txt(125) : Line is too long: the offending characters are 's' tmp/draft-ietf-netconf-beep-05.txt(136) : Line is too long: the offending characters are 'e' tmp/draft-ietf-netconf-beep-05.txt(182) : Line is too long: the offending characters are 't' tmp/draft-ietf-netconf-beep-05.txt(277) : Line is too long: the offending characters are 's' tmp/draft-ietf-netconf-beep-05.txt(294) : Line is too long: the offending characters are 'o' tmp/draft-ietf-netconf-beep-05.txt(295) : Line is too long: the offending characters are 'P' tmp/draft-ietf-netconf-beep-05.txt(297) : Line is too long: the offending characters are '.' tmp/draft-ietf-netconf-beep-05.txt(299) : Line is too long: the offending characters are 'e' tmp/draft-ietf-netconf-beep-05.txt(311) : Line is too long: the offending characters are 'd' tmp/draft-ietf-netconf-beep-05.txt(312) : Line is too long: the offending characters are ',' tmp/draft-ietf-netconf-beep-05.txt(406) : Line is too long: the offending characters are ',' tmp/draft-ietf-netconf-beep-05.txt(408) : Line is too long: the offending characters are 'y' tmp/draft-ietf-netconf-beep-05.txt(414) : Line is too long: the offending characters are 'r' tmp/draft-ietf-netconf-beep-05.txt(415) : Line is too long: the offending characters are '.' tmp/draft-ietf-netconf-beep-05.txt(422) : Line is too long: the offending characters are 't' tmp/draft-ietf-netconf-beep-05.txt(441) : Line is too long: the offending characters are 'e' tmp/draft-ietf-netconf-beep-05.txt(518) : Line is too long: the offending characters are 'b' tmp/draft-ietf-netconf-beep-05.txt(608) : Line is too long: the offending characters are ',' tmp/draft-ietf-netconf-beep-05.txt(697) : Line is too long: the offending characters are 'd' tmp/draft-ietf-netconf-beep-05.txt(770) : Line is too long: the offending characters are 'n' Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Miscellaneous warnings: None. No nits found. -- 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 Jul 08 18:41:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1Ws-0005gS-5q for netconf-archive@megatron.ietf.org; Fri, 08 Jul 2005 18:41: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 SAA11590 for ; Fri, 8 Jul 2005 18:41:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dr1KF-000JHC-SE for netconf-data@psg.com; Fri, 08 Jul 2005 22:28:03 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dr1KB-000JGt-Ov for netconf@ops.ietf.org; Fri, 08 Jul 2005 22:27:59 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 08 Jul 2005 15:28:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,275,1115017200"; d="scan'208,217"; a="433447637:sNHT68054436" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 15:27:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5840C.4ADF69F9" Subject: RE: how long should the manager maintain the connection with his device? Date: Fri, 8 Jul 2005 15:27:58 -0700 Message-ID: Thread-Topic: how long should the manager maintain the connection with his device? Thread-Index: AcWClL1p1xoBO0mbT7mPZynHTr0zkABc/qww From: "Kent Watsen" To: "??" , "netconf" X-OriginalArrivalTime: 08 Jul 2005 22:27:58.0796 (UTC) FILETIME=[4B5060C0:01C5840C] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5840C.4ADF69F9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2FuZywNCg0KIA0KDQpPdXIgcHJvZHVjdCBhY2hpZXZlcyA2MDAwIGNvbm5lY3Rpb25zIHdp dGggYm90aCBzdG9jayBTb2xhcmlzLTkgYW5kIFJlZEhhdC1FUyBiYXNlZCBzeXN0ZW1zLiAgQXMg Zm9yIHRoZSBoYXJkd2FyZSwgb3VyIHNpemluZyBndWlkZXMgc3VnZ2VzdCBjdXN0b21lcnMgaGF2 ZSBhYm91dCA0IGdpZ3Mgb2YgbWVtb3J5LCBidXQgdGhlIG1ham9yaXR5IG9mIHRoaXMgbWVtb3J5 IGlzIG5vdCBmb3IgVENQLiAgSG9uZXN0bHksIHdlIGRpZCB0aGlzIHdpdGhvdXQgbXVjaCBjb25z aWRlcmF0aW9uIGZvciBpZiBpdCBjb3VsZCBiZSBkb25lIOKAkyBpbiBmYWN0LCB3ZSBoYXZlIGFu b3RoZXIgcHJvZHVjdCB0aGF0IGRvZXMgb3ZlciAxMCwwMDAgY29ubmVjdGlvbnMgb24gYSBzaW5n bGUgbWFjaGluZeKApiAgTWF5YmUgaXQgaXMgYmVjYXVzZSB3ZSBhcmUgdXNpbmcgdGhlIEMgcHJv Z3JhbW1pbmcgbGFuZ3VhZ2Ugd2l0aCBhIHNpbmdsZSBzZWxlY3QoKS1kcml2ZW4gdGhyZWFkPw0K DQogDQoNCkJ1dCB0aGUgcG9pbnQgSSB3YXMgdHJ5aW5nIHRvIG1ha2UsIGluIGFuc3dlcmluZyB5 b3VyIG9yaWdpbmFsIHF1ZXN0aW9uLCBpcyB0aGF0IG1hbmFnZXJzIGRvIGxpa2UgdG8gaG9sZCBw ZXJzaXN0ZW50IGNvbm5lY3Rpb25zIOKAkyBJIHNheSDigJxsaWtl4oCdIGFzIGl0IGlzIGVhc3kg dG8gaW1wbGVtZW50IHdpdGhvdXQgZ3JlYXQgaW1wYWN0IHRvIGVpdGhlciB0aGUgZW5kcG9pbnRz IG9yIHRoZSBuZXR3b3JrIGluLWJldHdlZW4uDQoNCiANCg0KS2VudA0KDQogDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IHkwMzA3MzdAbmp1cHQuZWR1LmNuIFtt YWlsdG86eTAzMDczN0BuanVwdC5lZHUuY25dIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDA2LCAy MDA1IDY6NDMgUE0NClRvOiBuZXRjb25mOyBLZW50IFdhdHNlbg0KU3ViamVjdDogUmU6IGhvdyBs b25nIHNob3VsZCB0aGUgbWFuYWdlciBtYWludGFpbiB0aGUgY29ubmVjdGlvbiB3aXRoIGhpcyBk ZXZpY2U/DQoNCiANCg0KRGVhciBLZW50IFdhdHNlbu+8jCANCg0KICB0aGFua3MgZm9yIHlvdXIg cmVwbHkuIA0KDQogICAgDQoNCiAgICAgIGJ1dCBJIHJlYWxseSBjYW4ndCBpbWFnZSBhIHNpbmds ZSBtYWNoaW5lIGhhcyB0aGUgY2FwYWJpbGl0eSB0aGF0IG1haW50YWlucyAgcGVyc2lzdGVuY2Ug Y29ubmVjdGlvbnMNCg0Kd2l0aCAqNjAwMCogIGRldmljZS4gIA0KDQogU28gIGNvdWxkIHlvdSBw bGVhc2UgdGVsbCBtZSB0aGUgbWFjaGluZSdzIHR5cGUsIGFuZCBob3cgZG8geW91IGdldCB0aGUg bnVtYmVyICI2MDAwIiA/Pw0KDQrjgIDjgIANCg0KIA0KDQo9PT09PT09PSAyMDA1LTA3LTA3IDA2 OjQxOjU2ICBLZW50IFdhdHNlbiBzYWlk77yaID09PT09DQoNCiANCg0KCSANCg0KCVRoZSBkdXJh dGlvbiBvZiB0aGUgY29ubmVjdGlvbiBpcyBjbG9zZWx5IHJlbGF0ZWQgdG8gaG93IG9mdGVuIHRo ZSBub24taW5pdGlhdGluZyBzaWRlIG5lZWRzIHRvIGZsdXNoIGl0cyBidWZmZXJzIChpLmUuIGV2 ZW50IG5vdGlmaWNhdGlvbnMpLiAgV2UgZmluZCB0aGF0IHBlcnNpc3RlbnQgY29ubmVjdGlvbnMg d29yayBmaW5lIGZvciB1cCB0byA2MDAwIGRldmljZXMgLSB0aGlzIGlzIHRoZSBwcmFjdGljYWwg Y29ubmVjdGlvbiBsaW1pdCBmb3IgYSBzaW5nbGUgbWFjaGluZS4gIEZvciBtb3JlIHRoYW4gNjAw MCBkZXZpY2VzLCBlaXRoZXIgYSBzZXJ2ZXItY2x1c3RlciBvciBhIHBlcmlvZGljLXBvbGwgYXJj aGl0ZWN0dXJlIG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgLSB0aGUgY2hvaWNlIHBlbmRpbmcgb24g dGhlIGludGVyYWN0aW9uIHJlcXVpcmVtZW50cyBvZiB5b3VyIHN5c3RlbQ0KDQoJIA0KDQoJV2hl biBOZXRDb25mIHB1cnN1ZXMgZXZlbnQgbm90aWZpY2F0aW9ucywgaW4gYWRkaXRpb24gdG8gZm9s bG93aW5nIHRoZSBwdWJsaXNoL3N1YnNjcmliZSBtZXNzYWdpbmcgcGF0dGVybiBpdCB3b3VsZCBi ZSBnb29kIHRvIGFsc28gY29uc2lkZXIgdGhlIGR1cmFibGUtc3Vic2NyaWJlciBhbmQgcHJpb3Jp dHktcXVldWluZyBwYXR0ZXJucyBmb3IgTk1TcyB3aXNoaW5nIHRvIGhhdmUgbm9uLXBlcnNpc3Rl bnQgY29ubmVjdGlvbnMNCg0KCSANCg0KCUtlbnQNCg0KCSANCg0KCSANCg0KCS0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoNCglGcm9tOiBvd25lci1uZXRjb25mQG9wcy5pZXRmLm9yZyBbbWFp bHRvOm93bmVyLW5ldGNvbmZAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgeTAzMDczN0BuanVw dC5lZHUuY24NCg0KCVNlbnQ6IFR1ZXNkYXksIEp1bHkgMDUsIDIwMDUgODoyMSBQTQ0KDQoJVG86 IG5ldGNvbmYNCg0KCVN1YmplY3Q6IGhvdyBsb25nIHNob3VsZCB0aGUgbWFuYWdlciBtYWludGFp biB0aGUgY29ubmVjdGlvbiB3aXRoIGhpcyBkZXZpY2U/DQoNCgkgDQoNCgloaSBhbGw6DQoNCgkg DQoNCgkgICBJIGhhdmUgcmVhZCB0aGUgbmV0Y29uZi1wcm8wNiBhbmQgInNjYWxhYmlsaXR5IG9m IG5ldGNvbmYiIHRvcGljIG9uIHRoZSBsaXN0LCBJIHNhdyANCg0KCUp1ZXJnZW4gU2Nob2Vud2Fl bGRlciBzYWlkIGhlIGZpbmQgdGhhdCBob2xkaW5nIDMwMCBUQ1AgY29ubmVjdGlvbnMgaXMgbm90 IGEgaGFyZCB0aGluZy4NCg0KCSANCg0KCSAgIGJ1dCBJIHdhbnQgdG8ga25vdyBpbiB0aGUgcmVh bCB3b3JsZCAsIGRvZXMgdGhlIG1hbmFnZXIganVzdCBob2xkIHRoZSBjb25uZWN0aW9uIHdoZW4g dGhlcmUgYXJlIHN0aWxsIHNvbWUgY29uZmlnIG9wZXJhdGlvbiBuZWVkIHRvIGJlIHBlcmZvcm1l ZCBhbmQgdGhlIGNvbm5lY3Rpb24gd2lsbCBiZSBraWxsIGFzIHNvb24gYXMgdGhlc2Ugb3BlcmF0 aW9ucyBjb21wbGV0ZWQ/ICBPciBpdCB3aWxsIGhvbGQgdGhlIGNvbm5lY3Rpb24gd2l0aCBoaXMg ImFnZW50IiBhbGwgdGhlIHRpbWUgdW50aWwgc29tZSBhY2NpZGVudCBoYXBwZW5zPyANCg0KCSAN Cg0KCSANCg0KCXRoYW5rcyBmb3IgY29taW5nIGluIQ0KDQoJIA0KDQoJQmVzdCBSZWdhcmRzDQoN CgkgDQoNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KCVdhbmcgSGFuDQoNCgkgDQoNCgl5MDMwNzM3QG5qdXB0LmVkdS5jbg0KDQoJUmVzZWFy Y2ggQ2VudGVyIG9mIE5ldHdvcmsgVGVjaG5vbG9neQ0KDQoJTmFuamluZyBVbml2ZXJzaXR5IG9m IFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCg0KCS0tLeKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lA0KDQoJIA0KDQoJIA0KDQoJIA0KDQoJ5oGrcnp15562eua9veenue6Vr+WPmueeqHrnn5Tmvo96 5Ly3d3J60JXnparnn58NCg0KIA0KDQogDQoNClJlZ2FyZHMNCg0KIA0KDQpXYW5nIEhhbg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KV2FuZyBIYW4NCg0KIA0KDQp5MDMwNzM3QG5qdXB0LmVkdS5jbiA8bWFpbHRvOnkwMzA3 MzdAbmp1cHQuZWR1LmNuPiANCg0KUmVzZWFyY2ggQ2VudGVyIG9mIE5ldHdvcmsgVGVjaG5vbG9n eQ0KTmFuamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCuKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlA0KDQogDQoNCg== ------_=_NextPart_001_01C5840C.4ADF69F9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNv XT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZQ0KIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJQbGFjZVR5cGUiLz4NCjxvOlNtYXJ0 VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt YXJ0dGFncyINCiBuYW1lPSJQbGFjZU5hbWUiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJj b3VudHJ5LXJlZ2lvbiIvPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9InBsYWNlIiBkb3dubG9h ZHVybD0iaHR0cDovL3d3dy41aWFudGxhdmFsYW1wLmNvbS8iLz4NCjwhLS1baWYgIW1zb10+DQo8 c3R5bGU+DQpzdDFcOip7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I2llb291aSkgfQ0KPC9zdHlsZT4N CjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxAQXJpYWwgVW5pY29kZSBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBh bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQog cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpA cGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWlu IDEuMGluIDEuMjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwv c3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9IiNFQUVBRUEiIGxhbmc9RU4tVVMgbGluaz1i bHVlIHZsaW5rPWJsdWU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SGkgV2FuZyw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6bmF2eSc+T3VyIHByb2R1Y3QgYWNoaWV2ZXMgNjAwMCBjb25uZWN0aW9ucyB3aXRo DQpib3RoIHN0b2NrIFNvbGFyaXMtOSBhbmQgUmVkSGF0LUVTIGJhc2VkIHN5c3RlbXMuIMKgQXMg Zm9yIHRoZSBoYXJkd2FyZSwgb3VyDQpzaXppbmcgZ3VpZGVzIHN1Z2dlc3QgY3VzdG9tZXJzIGhh dmUgYWJvdXQgNCBnaWdzIG9mIG1lbW9yeSwgYnV0IHRoZSBtYWpvcml0eQ0Kb2YgdGhpcyBtZW1v cnkgaXMgbm90IGZvciBUQ1AuIMKgSG9uZXN0bHksIHdlIGRpZCB0aGlzIHdpdGhvdXQgbXVjaA0K Y29uc2lkZXJhdGlvbiBmb3IgaWYgaXQgY291bGQgYmUgZG9uZSDigJMgaW4gZmFjdCwgd2UgaGF2 ZSBhbm90aGVyIHByb2R1Y3QgdGhhdA0KZG9lcyBvdmVyIDEwLDAwMCBjb25uZWN0aW9ucyBvbiBh IHNpbmdsZSBtYWNoaW5l4oCmwqAgTWF5YmUgaXQgaXMgYmVjYXVzZSB3ZSBhcmUNCnVzaW5nIHRo ZSBDIHByb2dyYW1taW5nIGxhbmd1YWdlIHdpdGggYSBzaW5nbGUgc2VsZWN0KCktZHJpdmVuIHRo cmVhZD88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29s b3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+QnV0IHRoZSBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFr ZSwgaW4NCmFuc3dlcmluZyB5b3VyIG9yaWdpbmFsIHF1ZXN0aW9uLCBpcyB0aGF0IG1hbmFnZXJz IGRvIGxpa2UgdG8gaG9sZCBwZXJzaXN0ZW50IGNvbm5lY3Rpb25zDQrigJMgSSBzYXkg4oCcbGlr ZeKAnSBhcyBpdCBpcyBlYXN5IHRvIGltcGxlbWVudCB3aXRob3V0IGdyZWF0IGltcGFjdCB0byBl aXRoZXIgdGhlDQplbmRwb2ludHMgb3IgdGhlIG5ldHdvcmsgaW4tYmV0d2Vlbi48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3QxOmNvdW50cnktcmVnaW9uIHc6c3Q9Im9uIj48 c3QxOnBsYWNlIHc6c3Q9Im9uIj48Zm9udA0KICBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsOw0KICBjb2xv cjpuYXZ5Jz5LZW50PC9zcGFuPjwvZm9udD48L3N0MTpwbGFjZT48L3N0MTpjb3VudHJ5LXJlZ2lv bj48Zm9udCBzaXplPTINCmNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5hdnknPjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9 bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0 LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEyLjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0 YWJpbmRleD0tMT4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2Zv bnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4NCnkwMzA3MzdAbmp1cHQuZWR1LmNuIFttYWlsdG86 eTAzMDczN0BuanVwdC5lZHUuY25dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpi b2xkJz5TZW50Ojwvc3Bhbj48L2I+IFdlZG5lc2RheSwgSnVseSAwNiwgMjAwNQ0KNjo0MyBQTTxi cj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBuZXRj b25mOyBLZW50IFdhdHNlbjxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5T dWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBob3cgbG9uZyBzaG91bGQgdGhlDQptYW5hZ2VyIG1haW50 YWluIHRoZSBjb25uZWN0aW9uIHdpdGggaGlzIGRldmljZT88L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNl PVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RGVhcg0KS2VudCBXYXRzZW48 c3BhbiBsYW5nPVpILUNOPu+8jCA8L3NwYW4+PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQ7Zm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+IHRoYW5rcyBmb3IgeW91ciByZXBs eS4NCjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNw OyZuYnNwOzwvc3Bhbj48L2ZvbnQ+IDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+DQpidXQg SSByZWFsbHkgY2FuJ3Q8Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5pbWFnZQ0K YSBzaW5nbGUgbWFjaGluZSBoYXMgdGhlIGNhcGFiaWxpdHkgdGhhdCBtYWludGFpbnM8Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+IHBlcnNpc3RlbmNlDQpjb25uZWN0aW9uczxv OnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+d2l0 aA0KKjYwMDAqPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD4NCmRldmljZS48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD4NCjxvOnA+PC9v OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+U288 Zm9udA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+DQpjb3VsZCB5b3UgcGxlYXNlIHRl bGwgbWUgdGhlIG1hY2hpbmUncyB0eXBlLCBhbmQgaG93IGRvIHlvdSBnZXQgdGhlIG51bWJlcg0K JnF1b3Q7NjAwMCZxdW90OyA/PzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPVNpbVN1bj48c3BhbiBsYW5nPVpI LUNOIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPuOAgOOAgDwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1TaW1TdW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPj09PT09PT09DQoyMDA1LTA3LTA3PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9 Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+MDY6NDE6NTY8L3NwYW4+PC9mb250Pjxm b250IHNpemU9Mg0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gS2VudCBXYXRz ZW48L3NwYW4+PC9mb250Pjxmb250IHNpemU9Mg0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz5zYWlkPHNwYW4gbGFuZz1aSC1DTj7vvJo8L3NwYW4+ID09PT09PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjx0 YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxscGFkZGluZz0wIHdpZHRoPSIx MDAlIg0KIHN0eWxlPSd3aWR0aDoxMDAuMCUnPg0KIDx0cj4NCiAgPHRkIHdpZHRoPSIxMDAlIiBz dHlsZT0nd2lkdGg6MTAwLjAlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPg0KICA8 YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmxhY2sgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDsNCiAgbWFyZ2luLWxlZnQ6My43NXB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Jz4NCiAgPGRp dj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4N CiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPVNpbVN1bj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlPC9zcGFuPjwvZm9udD48Zm9udA0KICBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5kdXJhdGlvbjxmb250DQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250Pm9mPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+dGhlPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+Y29ubmVjdGlvbjxm b250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmlzPGZvbnQNCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+Y2xvc2VseTxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3Nw YW4+PC9mb250PnJlbGF0ZWQ8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD50 bzxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pmhvdzxmb250DQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pm9mdGVuPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+dGhlPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+bm9u LWluaXRpYXRpbmc8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5zaWRlPGZv bnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+bmVlZHM8Zm9udA0KICBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7PC9zcGFuPjwvZm9udD50bzxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+ PC9mb250PmZsdXNoPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+aXRzPGZv bnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+YnVmZmVyczxmb250DQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PihpLmUuPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+ZXZlbnQ8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5u b3RpZmljYXRpb25zKS48Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9u dD5XZTxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmZpbmQ8Zm9udA0KICBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD50aGF0PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+cGVyc2lzdGVudDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+ PC9mb250PmNvbm5lY3Rpb25zPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ d29yazxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmZpbmU8Zm9udA0KICBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5mb3I8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD51cDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnRv PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+NjAwMDxmb250DQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmRldmljZXM8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD4tPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+dGhp czxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmlzPGZvbnQNCiAgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+dGhlPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+cHJhY3RpY2FsPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ Y29ubmVjdGlvbjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmxpbWl0PGZv bnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+Zm9yPGZvbnQNCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+YTxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9m b250PnNpbmdsZTxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pm1hY2hpbmUu PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+Rm9yPGZvbnQNCiAg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+bW9yZTxmb250DQogIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250PnRoYW48Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD42MDAwPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ZGV2aWNlcyw8Zm9u dA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5laXRoZXI8Zm9udA0KICBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7PC9zcGFuPjwvZm9udD5hPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+c2VydmVyLWNsdXN0ZXI8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD5vcjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmE8Zm9udA0KICBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5wZXJpb2RpYy1wb2xsPGZvbnQNCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+YXJjaGl0ZWN0dXJlPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+bmVlZHM8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD50bzxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmJlPGZvbnQNCiAgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+Y29uc2lkZXJlZDxmb250DQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250Pi08Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD50aGU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5jaG9pY2U8Zm9udA0K ICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5wZW5kaW5nPGZvbnQNCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+b248Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwv Zm9udD50aGU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5pbnRlcmFjdGlv bjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnJlcXVpcmVtZW50czxmb250 DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pm9mPGZvbnQNCiAgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+eW91cjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9m b250PnN5c3RlbTxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQogIHN0 eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEyLjBwdCc+V2hlbjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+TmV0Q29uZjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9m b250PnB1cnN1ZXM8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5ldmVudDxm b250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pm5vdGlmaWNhdGlvbnMsPGZvbnQN CiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+aW48Zm9udA0KICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7PC9zcGFuPjwvZm9udD5hZGRpdGlvbjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+ PC9mb250PnRvPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+Zm9sbG93aW5n PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+dGhlPGZvbnQNCiAgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+cHVibGlzaC9zdWJzY3JpYmU8Zm9udA0KICBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7PC9zcGFuPjwvZm9udD5tZXNzYWdpbmc8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD5wYXR0ZXJuPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+aXQ8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD53b3VsZDxmb250DQog IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmJlPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+Z29vZDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250 PnRvPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+YWxzbzxmb250DQogIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmNvbnNpZGVyPGZvbnQNCiAgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+dGhlPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+ZHVyYWJsZS1zdWJzY3JpYmVyPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+YW5kPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+cHJpb3JpdHktcXVl dWluZzxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnBhdHRlcm5zPGZvbnQN CiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+Zm9yPGZvbnQNCiAgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+Tk1Tczxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9m b250Pndpc2hpbmc8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD50bzxmb250 DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmhhdmU8Zm9udA0KICBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7PC9zcGFuPjwvZm9udD5ub24tcGVyc2lzdGVudDxmb250DQogIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250PmNvbm5lY3Rpb25zPG86cD48L286cD48L3A+DQogIDwvZGl2Pg0KICA8 ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQogIDwvZGl2 Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PHN0MTpjb3VudHJ5LXJlZ2lvbiB3OnN0 PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+PGZvbnQNCiAgICBzaXplPTMgZmFjZT1TaW1TdW4+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPktlbnQ8L3NwYW4+PC9mb250Pjwvc3QxOnBs YWNlPjwvc3QxOmNvdW50cnktcmVnaW9uPjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRp dj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4N CiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KICA8 L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPVNp bVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+LS0tLS1PcmlnaW5hbDwvc3Bhbj48 L2ZvbnQ+PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+TWVzc2FnZS0tLS0t PG86cD48L286cD48L3A+DQogIDwvZGl2Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9U2ltU3VuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5G cm9tOjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ b3duZXItbmV0Y29uZkBvcHMuaWV0Zi5vcmc8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFu PjwvZm9udD5bbWFpbHRvOm93bmVyLW5ldGNvbmZAb3BzLmlldGYub3JnXTxmb250DQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pk9uPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+QmVoYWxmPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+T2Y8 Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD55MDMwNzM3QG5qdXB0LmVkdS5j bjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+ U2VudDo8L3NwYW4+PC9mb250Pjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250 PlR1ZXNkYXksPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+SnVseTxmb250 DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjA1LDxmb250DQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250PjIwMDU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwv Zm9udD44OjIxPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+UE08bzpwPjwv bzpwPjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTMgZmFjZT1TaW1TdW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPlRvOjwvc3Bh bj48L2ZvbnQ+PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+bmV0Y29uZjxv OnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+U3Vi amVjdDo8L3NwYW4+PC9mb250Pjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250 Pmhvdzxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pmxvbmc8Zm9udA0KICBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5zaG91bGQ8Zm9udA0KICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7PC9zcGFuPjwvZm9udD50aGU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD5tYW5hZ2VyPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+bWFpbnRhaW48 Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD50aGU8Zm9udA0KICBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7PC9zcGFuPjwvZm9udD5jb25uZWN0aW9uPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+d2l0aDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250 Pmhpczxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmRldmljZT88bzpwPjwv bzpwPjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTMgZmFjZT1TaW1TdW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPmhp PC9zcGFuPjwvZm9udD48Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5hbGw6 PG86cD48L286cD48L3A+DQogIDwvZGl2Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+DQogIDwvZGl2Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCiAgc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+STxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+ PC9mb250PmhhdmU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5yZWFkPGZv bnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+dGhlPGZvbnQNCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+bmV0Y29uZi1wcm8wNjxmb250DQogIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250PmFuZDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250 PiZxdW90O3NjYWxhYmlsaXR5PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ b2Y8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5uZXRjb25mJnF1b3Q7PGZv bnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+dG9waWM8Zm9udA0KICBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7PC9zcGFuPjwvZm9udD5vbjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+ PC9mb250PnRoZTxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pmxpc3QsPGZv bnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+STxmb250DQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250PnNhdzxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw dCc+SnVlcmdlbjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+U2Nob2Vud2FlbGRlcjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250 PnNhaWQ8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5oZTxmb250DQogIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmZpbmQ8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD50aGF0PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ aG9sZGluZzxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjMwMDxmb250DQog IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PlRDUDxmb250DQogIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250PmNvbm5lY3Rpb25zPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+aXM8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5ub3Q8Zm9u dA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5hPGZvbnQNCiAgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+aGFyZDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9m b250PnRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQogIHN0 eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu DQogIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9mb250PmJ1dDxmb250DQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250Pkk8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9u dD53YW50PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+dG88Zm9udA0KICBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5rbm93PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+aW48Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD50 aGU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5yZWFsPGZvbnQNCiAgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+d29ybGQ8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD4sPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ZG9l czxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnRoZTxmb250DQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pm1hbmFnZXI8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD5qdXN0PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ aG9sZDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnRoZTxmb250DQogIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmNvbm5lY3Rpb248Zm9udA0KICBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7PC9zcGFuPjwvZm9udD53aGVuPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+dGhlcmU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5hcmU8Zm9u dA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5zdGlsbDxmb250DQogIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDs8L3NwYW4+PC9mb250PnNvbWU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFu PjwvZm9udD5jb25maWc8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5vcGVy YXRpb248Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5uZWVkPGZvbnQNCiAg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+dG88Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD5iZTxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnBl cmZvcm1lZDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmFuZDxmb250DQog IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnRoZTxmb250DQogIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250PmNvbm5lY3Rpb248Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFu PjwvZm9udD53aWxsPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+YmU8Zm9u dA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5raWxsPGZvbnQNCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+YXM8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwv Zm9udD5zb29uPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+YXM8Zm9udA0K ICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD50aGVzZTxmb250DQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250Pm9wZXJhdGlvbnM8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9z cGFuPjwvZm9udD5jb21wbGV0ZWQ/PGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOzwvc3Bh bj48L2ZvbnQ+T3I8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5pdDxmb250 DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PndpbGw8Zm9udA0KICBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7PC9zcGFuPjwvZm9udD5ob2xkPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+dGhlPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+Y29ubmVjdGlv bjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PndpdGg8Zm9udA0KICBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5oaXM8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9z cGFuPjwvZm9udD4mcXVvdDthZ2VudCZxdW90Ozxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3Nw YW4+PC9mb250PmFsbDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnRoZTxm b250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PnRpbWU8Zm9udA0KICBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7PC9zcGFuPjwvZm9udD51bnRpbDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3Nw YW4+PC9mb250PnNvbWU8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD5hY2Np ZGVudDxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmhhcHBlbnM/PGZvbnQN CiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQogIDwvZGl2 Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQog IDwvZGl2Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQogIDwvZGl2Pg0KICA8ZGl2Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9U2ltU3VuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz50aGFua3M8L3NwYW4+ PC9mb250Pjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmZvcjxmb250DQog IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmNvbWluZzxmb250DQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250PmluITxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4N CiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAg PGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPVNpbVN1bj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+QmVzdDwvc3Bhbj48L2ZvbnQ+PGZvbnQNCiAgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KICA8L2Rp dj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0K ICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgZmFjZT1TaW1TdW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPldhbmc8L3NwYW4+ PC9mb250Pjxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PkhhbjxvOnA+PC9v OnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+eTAz MDczN0BuanVwdC5lZHUuY248bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KICA8L2Rpdj4N CiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxzdDE6cGxhY2UgdzpzdD0ib24iPjxzdDE6 UGxhY2VOYW1lIHc6c3Q9Im9uIj48Zm9udA0KICAgIHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+UmVzZWFyY2g8L3NwYW4+PC9mb250Pjwvc3QxOlBsYWNl TmFtZT48Zm9udA0KICAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHN0MTpQbGFjZVR5 cGUNCiAgIHc6c3Q9Im9uIj5DZW50ZXI8L3N0MTpQbGFjZVR5cGU+PC9zdDE6cGxhY2U+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+b2Y8Zm9udA0KICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7PC9zcGFuPjwvZm9udD5OZXR3b3JrPGZvbnQNCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+VGVjaG5vbG9neTxvOnA+PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAg Y2xhc3M9TXNvTm9ybWFsPjxzdDE6cGxhY2UgdzpzdD0ib24iPjxzdDE6UGxhY2VOYW1lIHc6c3Q9 Im9uIj48Zm9udA0KICAgIHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEyLjBwdCc+TmFuamluZzwvc3Bhbj48L2ZvbnQ+PC9zdDE6UGxhY2VOYW1lPjxmb250DQogICBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3QxOlBsYWNlVHlwZQ0KICAgdzpzdD0ib24i PlVuaXZlcnNpdHk8L3N0MTpQbGFjZVR5cGU+PC9zdDE6cGxhY2U+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+b2Y8Zm9udA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwv Zm9udD5Qb3N0czxmb250DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PmFuZDxmb250 DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PlRlbGVjb21tdW5pY2F0aW9uczxvOnA+ PC9vOnA+PC9wPg0KICA8L2Rpdj4NCiAgPGRpdj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+LS0tPHNw YW4NCiAgbGFuZz1aSC1DTj7igJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJQ8L3NwYW4+PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHls ZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQogIDxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0K ICBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCiAgPC9kaXY+DQogIDxkaXY+DQog IDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT1TaW1TdW4+PHNwYW4gbGFuZz1a SC1DTg0KICBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+5oGrPC9zcGFuPnJ6dTxzcGFuIGxhbmc9 WkgtQ04+5562PC9zcGFuPno8c3Bhbg0KICBsYW5nPVpILUNOPua9veenuTwvc3Bhbj48L2ZvbnQ+ PGZvbnQgZmFjZT0iQXJpYWwgVW5pY29kZSBNUyI+PHNwYW4gbGFuZz1aSC1DTg0KICBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiJz7ula/lj5rnnqg8L3NwYW4+PC9mb250Pno8 c3BhbiBsYW5nPVpILUNOPueflOa+jzwvc3Bhbj56PHNwYW4NCiAgbGFuZz1aSC1DTj7kvLc8L3Nw YW4+d3J6PHNwYW4gbGFuZz1aSC1DTj7Qleelquefnzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAg PC9kaXY+DQogIDwvYmxvY2txdW90ZT4NCiAgPC90ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQ7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9U2ltU3VuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5SZWdh cmRzPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPVNpbVN1bj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+V2FuZw0KSGFuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9U2ltU3VuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPVNpbVN1bj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+V2FuZw0KSGFuPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+ eTAzMDczN0A8YQ0KaHJlZj0ibWFpbHRvOnkwMzA3MzdAbmp1cHQuZWR1LmNuIj5uanVwdC5lZHUu Y248L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3QxOnBsYWNlIHc6c3Q9Im9uIj48c3QxOlBsYWNlTmFtZSB3 OnN0PSJvbiI+PGZvbnQgc2l6ZT0zDQogIGZhY2U9U2ltU3VuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0Jz5SZXNlYXJjaDwvc3Bhbj48L2ZvbnQ+PC9zdDE6UGxhY2VOYW1lPg0KIDxzdDE6 UGxhY2VUeXBlIHc6c3Q9Im9uIj5DZW50ZXI8L3N0MTpQbGFjZVR5cGU+PC9zdDE6cGxhY2U+IG9m IE5ldHdvcmsNClRlY2hub2xvZ3k8YnI+DQo8c3QxOnBsYWNlIHc6c3Q9Im9uIj48c3QxOlBsYWNl TmFtZSB3OnN0PSJvbiI+TmFuamluZzwvc3QxOlBsYWNlTmFtZT4gPHN0MTpQbGFjZVR5cGUNCiB3 OnN0PSJvbiI+VW5pdmVyc2l0eTwvc3QxOlBsYWNlVHlwZT48L3N0MTpwbGFjZT4gb2YgUG9zdHMg YW5kDQpUZWxlY29tbXVuaWNhdGlvbnM8YnI+DQo8Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCUPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7DQpmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C5840C.4ADF69F9-- -- 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 Sat Jul 09 12:25:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrI99-0006r9-Qx for netconf-archive@megatron.ietf.org; Sat, 09 Jul 2005 12:25:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10076 for ; Sat, 9 Jul 2005 12:25:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrHwe-0000ni-8l for netconf-data@psg.com; Sat, 09 Jul 2005 16:12:48 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DrHwc-0000nT-80 for netconf@ops.ietf.org; Sat, 09 Jul 2005 16:12:46 +0000 Received: (qmail 13688 invoked by uid 78); 9 Jul 2005 16:06:51 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 9 Jul 2005 16:06:51 -0000 Message-ID: <42CFF59F.8020000@andybierman.com> Date: Sat, 09 Jul 2005 09:04:47 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bert Wijnen CC: Simon Leinen , David Kessens , netconf , iesg-secretary@ietf.org Subject: I-D Publication Request: draft-ietf-netconf-prot-07.txt (UPDATED 1.d) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Area] OPS-NM [WG] NETCONF [I-D] draft-ietf-netconf-prot-07.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt [Shep] Simon Leinen 1.a) Yes, the WG Chairs have reviewed this version of the document, and believe it is ready for publication. 1.b) Yes the document has had adequate review. Several WG members have reviewed this document. It has also been reviewed by non-WG members very familiar with XML, security, and network operations. 1.c) There are no open issues, and no further review is required, for this document. 1.d) There are no concerns with this document at this time. It is possible that clarifications will be identified as implementation and interoperability experience is reported to the WG. Note: The WG could not decide on a single application mapping for NETCONF, because different types of programmers want to use the protocol. Therefore, NETCONF defines three application mappings: SSH, BEEP, and SOAP, where SSH is the mandatory-to-implement protocol. 1.e) There is overwhelming WG consensus for this document. 1.f) No appeals have been threatened against this document. 1.g) There are no ID-nit issues in the document identified at this time. (See ID-nit log below). 1.h) Yes, references are split. No, there are no references to any unpublished documents. 1.j) I-D Submission Summary Technical Summary 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. Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. ---------------- [ID-nit log] idnits 1.74 tmp/draft-ietf-netconf-prot-07.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found. -- 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 Jul 11 07:33:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrwXP-0001Yj-Al for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 07:33:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02048 for ; Mon, 11 Jul 2005 07:33:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrwPS-0006qx-7W for netconf-data@psg.com; Mon, 11 Jul 2005 11:25:14 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DrwPP-0006qW-7n for netconf@ops.ietf.org; Mon, 11 Jul 2005 11:25:11 +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 j6BBP6n22719 for ; Mon, 11 Jul 2005 07:25:06 -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 Event Messages Draft Available Date: Mon, 11 Jul 2005 07:25:02 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40412A30A@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf Event Messages Draft Available Thread-Index: AcWGCy5ImULKlzZbSaKLB4O+tRfbQg== From: "Sharon Chisholm" To: "netconf" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi We've just submitted a -00 version of 'Netconf Event Messages' as a proposed solution to the previously discussed question around how to do asynchronous messaging in netconf and to fulfill one of the new proposed Netconf phase 2 charter items. It should be posted within the next week, but in the meantime it can be found here =09 http://standards.nortelnetworks.com/netconf/docs/netconfEvent/pre_00_net conf_event.txt 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 Mon Jul 11 07:39:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drwcn-0002h6-Ow for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 07:39: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 HAA02321 for ; Mon, 11 Jul 2005 07:39:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrwYL-0007Z1-1E for netconf-data@psg.com; Mon, 11 Jul 2005 11:34:25 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DrwYH-0007Yc-Ta for netconf@ops.ietf.org; Mon, 11 Jul 2005 11:34:22 +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 j6BBYJF14101 for ; Mon, 11 Jul 2005 07:34:19 -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: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 07:34:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40412A310@zcarhxm2.corp.nortel.com> Thread-Topic: I-D Publication Request: draft-ietf-netconf-soap-05.txt Thread-Index: AcWDZV+2nXRq0YZORcOX8in4wL482QCpeWhg From: "Sharon Chisholm" To: "netconf" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I have a clarifying question: The last paragraph of section 2.4 reads "It is also possible to respond to the concern on the re-use of port 80. A NETCONF SOAP service can be offered on any desired port, and it is recommended that a new standard port for SOAP over HTTP, or a new standard port for NETCONF over SOAP (over HTTP) be defined, as requested in the IANA considerations of this document." Which considering the IANA considerations section says the following "The IANA will assign TCP ports for NETCONF for SOAP over HTTP and SOAP over BEEP." seems too weak. Is the section in 2.4 left over from before it was decided we liked specific ports, or did we intend to leave port use as an exercise to the reader?=20 Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, July 07, 2005 10:22 PM To: Bert Wijnen Cc: Simon Leinen; David Kessens; netconf; iesg-secretary@ietf.org Subject: I-D Publication Request: draft-ietf-netconf-soap-05.txt [Area] OPS-NM [WG] NETCONF [I-D] draft-ietf-netconf-soap-05.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt [Shep] Andy Bierman 1.a) Yes, the WG Chairs have reviewed this version of the document, and believe it is ready for publication. 1.b) Yes the document has had adequate review. Several WG members have reviewed this document. =20 1.c) There are no open issues, and no further review is required, for this document. 1.d) There are no concerns with this document at this time. It is possible that clarifications will be identified as implementation and interoperability experience is reported to the WG. =20 1.e) There is strong WG consensus for this document. It is expected that more complex network applications (e.g., 1st or 3rd party commercial applications) will use this application mapping for NETCONF. 1.f) No appeals have been threatened against this document. 1.g) There are some minor ID-nits that will be fixed before RFC publication. (See ID-nit log below). 1.h) Yes, references are split. Yes, there is a reference to an unpublished document, namely the NETCONF Configuration Protocol document (draft-ietf-netconf-prot-07.txt), but this is also ready for publication. 1.j) I-D Submission Summary =20 Technical Summary The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over BEEP bindings for NETCONF. Working Group Summary =20 The NETCONF Working Group has consensus to publish this document as a Proposed Standard. =20 Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. ---------------- [ID-nit log] idnits 1.74 tmp/draft-ietf-netconf-soap-05.txt: tmp/draft-ietf-netconf-soap-05.txt(452): Line is too long: the offending characters are 'elope"' tmp/draft-ietf-netconf-soap-05.txt(464): Line is too long: the offending characters are 's:netconf:base:1.0">' Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (Expected a match on the following text: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.") (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. -- 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 Jul 11 08:05:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drx27-0000KM-NB for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 08:05:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04587 for ; Mon, 11 Jul 2005 08:05:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrwyC-0009vi-2r for netconf-data@psg.com; Mon, 11 Jul 2005 12:01:08 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Drwy9-0009v5-0b for netconf@ops.ietf.org; Mon, 11 Jul 2005 12:01:05 +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 j6BBxg907729 for ; Mon, 11 Jul 2005 07:59:42 -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: Proposed Update to Netconf Charter Date: Mon, 11 Jul 2005 08:00:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40412A324@zcarhxm2.corp.nortel.com> Thread-Topic: Proposed Update to Netconf Charter Thread-Index: AcWBflkFGm7fba7iSxixKrrmk9uEXwEkIY3g From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I'm in the process of updating the proposed charter updates based on all the comments that have been received. I have a few comments which I guess I will make here. Previous guidance from the working group chairs is that they wanted to see fully-baked solutions to various proposed problems, so as a result of that they will be seeing a string of individual submissions which below Andy was indicating he did not want to see. I think the goal with access control should be to try to integrate with existing deployed security solutions, not specifically with SNMP. If SNMP succeeds in ISMS, then it will all be integrated without turning the netconf access control mechanisms into VACM. Given the layering model in Netconf and the wide selection of application protocols and flavours of those application protocols that are available, I don't think it unreasonable that not all of these will be optimized for all netconf operations. Of course we don't want something to be precluded in a particular flavour of an application protocol, but if we limit ourselves to only what works very well over http, I think we will be in trouble. I think XML Schema needs to form the basis of our specifications. I hope we don't spend too much time debating it. I'd rather move forward and build upon that to define what we need to define to get interoperable netconf content. Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Tuesday, July 05, 2005 12:27 PM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Sharon Chisholm wrote: I have some real concerns with the wording of this charter text, but rather than focus on that, let's just try to agree on a bullet list form of the charter. I would much rather see agreement on specific features first, (and then let people propose solutions, from which the WG may select starting points for 1 or more standard documents), rather than have the WG deal with an ad-hoc array of individual submissions, as they come in. [In the interest of transparency, I am posting my personal preferences for charter extensions] Clearly, the addition of notifications is important to many people, and its already in the charter, so that seems like a no-brainer. However, a clean solution across all application mappings was not achieved in the first attempt, so let's see what new ideas come in this time around.. I also think that core data types are critical. There is actually no reason whatsoever this document couldn't have been published years ago -- it has no coupling to NETCONF at all -- it is just more XSD types to NETCONF. Access control is also critical to get in place early on. I prefer to start simple and evolve the complexity over time. IMO, a mapping to ISMS should be a separate work effort, and probably in that WG. NETCONF AC is unique because it is both "RPC method" and document oriented. IMO, old approaches like VACM will be clumsy and/or bloated if applied to NETCONF. Some new innovation is required here. I am also interested in the "SW image load" channel that has been discussed in the past. Often config reloads are coupled with image reloads, and it would be nice if NETCONF could integrate some SW image management features to support this requirement. Andy >hi > >As promised, here are the proposed updates to the Netconf charter to=20 >cover the work coming down the pipe: > >"Additional phase 2 work including: > >- Requirements and Guidelines for defining Netconf content to enable=20 >interoperable, high-quality and usable netconf implementations.=20 >Requirements will be defined around specification language, access=20 >control, compliance, backwards compatibility, depicting relationships,=20 >event specification, and application error message specification. > >- An initial set of application-level re-usable data types such as IP=20 >Addresses, MAC addresses, etc. This definition would be compliant to=20 >the above defined requirements and guidelines for Netconf content. > >- An XML Schema for reporting information about the Netconf system.=20 >This definition would be compliant to the above defined requirements=20 >and guidelines for Netconf content. > >- A netconf protocol specification for asynchronous messaging to enable >the sending of events. This must preserve the netconf layers." > > >Sharon Chisholm >Nortel >Ottawa, Ontario >Canada > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the=20 >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 Mon Jul 11 08:19:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrxFn-0003dJ-62 for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 08:19:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05351 for ; Mon, 11 Jul 2005 08:19:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrxAr-000BCP-PB for netconf-data@psg.com; Mon, 11 Jul 2005 12:14:13 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DrxAn-000BBw-O3 for netconf@ops.ietf.org; Mon, 11 Jul 2005 12:14:09 +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 j6BCE4F24759 for ; Mon, 11 Jul 2005 08:14:05 -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: Proposed Update to Netconf Charter Date: Mon, 11 Jul 2005 08:13:59 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40412A33A@zcarhxm2.corp.nortel.com> Thread-Topic: Proposed Update to Netconf Charter Thread-Index: AcWBo6y/tPsVE6n3T2qhjsejjUHrIgEbaawg From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Some comments on Contexts. I think this concept may well still be needed because=20 1. People are always going to have trouble predicting the future 2. Over-optimizing your schema for 'what ifs' can make the thing complicated. For example, in order to support virtual routers, do you really extend all of your traditional things like routing tables so you can have more than one of them? Perhaps the answer is yes, since this also means allows supports for distributed management, but is this worth it for the simple case of a single router with a single routing table? Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 Sent: Tuesday, July 05, 2005 4:54 PM To: David B Harrington Cc: 'Andy Bierman'; Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org Subject: RE: Proposed Update to Netconf Charter HI, Two specific items... 1) I don't see the need for contexts in NETCONF data modeling, since contexts are simply "a mechanism to add extra indexing when the MIB designer failed to predict the future evolution of technology" (or bandaid for poor MIB design). With XML, I don't really believe this limitation is present, and, thus, a "context" will not be needed. 2) SNMP VACM access control is based on 1) the identication of the management information (the variable name) 2) the operation type (read/write/notify) 3) the security model 4) the security level 5) the context 6) the group It doesn't depend on the value of object instance. This has resulted in MIB design patterns where objects are made (unnaturally) into index object(s). The usual case is where the security name (or group name) is made into an index. Many other systems, especially data base systems have access control based on data values. In the work that I have done explaining VACM, the concept that what security level is used can affect what can be accessed is always a very big surprise. So far, there is a single security model. If several were present, then the number of entries in the VACM table could increase by a factor of the number. In general, the SNMP acess model is unlike anything that most users are use to. Thus, they can not understand it, and its richness is typically never=20 used. It is also typically not used because the objects used by management apps are not typically characterized. Thus, most systems that I've seen provide no restriction to management platforms, and any restriction is done by a management platform as to which management applications any specific user can run. Thus, I would characterize VACM as completely missing the target. It is too complex for typical usage, and not rich enough for realworld usage. Regards, /david t. perkins On Tue, 5 Jul 2005, David B Harrington wrote: > Hi Andy, >=20 > > Access control is also critical to get in place early on. > > I prefer to start simple and evolve the complexity over time. IMO, a > > mapping to ISMS should be a separate work effort, and probably in=20 > > that WG. > >=20 > > NETCONF AC is unique because it is both "RPC method" and > > document oriented. > > IMO, old approaches like VACM will be clumsy and/or bloated if > applied > > to NETCONF. Some new innovation is required here. > >=20 >=20 > I'm interested in your views about the uniqueness of netconf AC. >=20 > In SNMPv3, as you know, we found that all operations could be=20 > abstracted into read/write/notify types of operations for purposes of=20 > AC. There was not a real need to distinguish between GET, GETBULK, and > other proposed GET-XXXX operations. Do you see a real need to=20 > distinguish between the various RPC methods, etc., that=20 > would be initiated by an operator? >=20 > In the SNMPv3 isAccessAllowed() ASI, variableName names the instance=20 > of the managed object. Would netconf use a similar (XML-based)=20 > variablename to identify the instance of the managed object? >=20 > Do you expect that "documents" will be aggregations of objects that=20 > are not necessarily from the same XML subtree? I can see this if the=20 > document is an HTML web page; but if it is built from data elements=20 > defined as an XML instance, then would AC based on the underlying XML=20 > suffice? Cf: a varbind list with an aggregation of various managed=20 > objects. Do you have something different in mind for documents? >=20 > In SNMPv3, we have contexts to differentiate MIB instances. I assume=20 > such a concept would also be needed for netconf. Do you agree? Is=20 > "running" and "candidate" about as deep as you need to go for netconf=20 > contexts, or do you need the greater depth found in the SNMP contexts? > Do you anticipate a future need to be able to configure, for example,=20 > the XML instance for a specific blade in a server? >=20 > I'm interested in your thoughts on this because VACM has not gained=20 > very wide acceptance, and a simpler AC model that could be used with=20 > both netconf's XML hierarchical naming scheme and SNMP's OID=20 > hierarchical naming scheme (or an XML-based SNMP naming scheme) could=20 > help both protocols. I'm also interested in probing how the=20 > requirements for netconf AC and SNMP AC might differ, since this could > also have an impact on whether ISMS design should even try to be=20 > future-compatible with netconf. >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 >=20 >=20 >=20 >=20 >=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: >=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 Mon Jul 11 08:33:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrxTe-0006Ph-QQ for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 08:33:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06072 for ; Mon, 11 Jul 2005 08:33:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrxOa-000CBk-Rv for netconf-data@psg.com; Mon, 11 Jul 2005 12:28:24 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DrxOY-000CBO-4W for netconf@ops.ietf.org; Mon, 11 Jul 2005 12:28:22 +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 j6BCSHF27613 for ; Mon, 11 Jul 2005 08:28: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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Updated Proposed update to Netconf Charter Date: Mon, 11 Jul 2005 08:28:13 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40412A358@zcarhxm2.corp.nortel.com> Thread-Topic: Updated Proposed update to Netconf Charter Thread-Index: AcWGFAGwr6NwNxydQ2+RqAosyEGYFw== From: "Sharon Chisholm" To: "netconf" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Here is the updated proposed charter extension for phase 2. I have split access control out from the data model framework and have added a couple items that people have mentioned. Obviously some of this will need to get deferred to phase 3, in the absence of infinite resources. "Additional phase 2 work including: - Requirements and Guidelines for defining Netconf data models to enable interoperable, netconf implementations. Requirements will be defined around specification language, compliance, backwards compatibility, depicting relationships, event specification, and application error message specification. - Framework for netconf access control. This access control mechanism should consider integration with existing deployed solutions. It should define a common authentication scheme. - An initial set of application-level re-usable data types such as IP Addresses, MAC addresses, etc. This definition would be compliant to the above defined requirements and guidelines for Netconf content. - A concrete data model (XML Schema) for reporting information about the Netconf system. This definition would be compliant to the above defined requirements and guidelines for Netconf content. - A netconf protocol specification for asynchronous messaging to enable the sending of event messages. This must preserve the netconf layers." - A method of delivering software loads over netconf. - A method of supporting multi-channels. 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 Mon Jul 11 09:15:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dry8I-0006Qc-SG for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 09:15:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08775 for ; Mon, 11 Jul 2005 09:15:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dry2A-000Fma-LJ for netconf-data@psg.com; Mon, 11 Jul 2005 13:09:18 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dry27-000Fm1-G7 for netconf@ops.ietf.org; Mon, 11 Jul 2005 13:09:15 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 72B79393AB; Mon, 11 Jul 2005 15:09:14 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 15771-10; Mon, 11 Jul 2005 15:09:13 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9F204391AD; Mon, 11 Jul 2005 15:09:13 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 38FBF3798F9; Mon, 11 Jul 2005 14:11:06 +0200 (CEST) Date: Mon, 11 Jul 2005 14:11:06 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050711121106.GA682@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B40412A324@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40412A324@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Jul 11, 2005 at 08:00:57AM -0400, Sharon Chisholm wrote: > I think the goal with access control should be to try to integrate with > existing deployed security solutions, not specifically with SNMP. If > SNMP succeeds in ISMS, then it will all be integrated without turning > the netconf access control mechanisms into VACM. I have no clue what you are trying to convey here - the ISMS charter is pretty clear in saying that ISMS is not supposed to touch access control issues. Perhaps you just wanted to say that NetConf access control should not be constrained by the way VACM works - something I do agree with. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 11 09:34:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryQ4-00038S-PH for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 09:34:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10476 for ; Mon, 11 Jul 2005 09:33:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DryJN-000HDD-Ik for netconf-data@psg.com; Mon, 11 Jul 2005 13:27:05 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DryJL-000HCx-Qc for netconf@ops.ietf.org; Mon, 11 Jul 2005 13:27:03 +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 j6BDR0n01380 for ; Mon, 11 Jul 2005 09:27:00 -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: Proposed Update to Netconf Charter Date: Mon, 11 Jul 2005 09:26:46 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40412A42A@zcarhxm2.corp.nortel.com> Thread-Topic: Proposed Update to Netconf Charter Thread-Index: AcWGGcENcaG7aRrVQcm2pervJxeB3wAANRyQ From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi More or less. That and we should ensure that everything plays nice with a common security infrastructure, rather than each other ___________ SNMP -------- / \ / \ CLI -------/ \ | Miracle \ Netconf -------\ | | / Syslog -------- \ \ -------------- As appose to SNMP <--miracle --> Netconf CLI <--miracle --> Netconf Syslog <--miracle --> Netconf SNMP <--miracle--> CLI SNMP <--miracle--> Syslog CLI <--miracle--> Syslog Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Monday, July 11, 2005 8:11 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter On Mon, Jul 11, 2005 at 08:00:57AM -0400, Sharon Chisholm wrote: > I think the goal with access control should be to try to integrate=20 > with existing deployed security solutions, not specifically with SNMP. > If SNMP succeeds in ISMS, then it will all be integrated without=20 > turning the netconf access control mechanisms into VACM. I have no clue what you are trying to convey here - the ISMS charter is pretty clear in saying that ISMS is not supposed to touch access control issues. Perhaps you just wanted to say that NetConf access control should not be constrained by the way VACM works - something I do agree with. /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 11 10:05:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryuT-0002UD-Sk for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 10:05:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13084 for ; Mon, 11 Jul 2005 10:05:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrypT-000Jz4-8n for netconf-data@psg.com; Mon, 11 Jul 2005 14:00:15 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DrypQ-000JyY-EN for netconf@ops.ietf.org; Mon, 11 Jul 2005 14:00:12 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 853BC3969A; Mon, 11 Jul 2005 16:00:11 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19398-10; Mon, 11 Jul 2005 16:00:10 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id A9EA8393AB; Mon, 11 Jul 2005 16:00:10 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 353D53799B5; Mon, 11 Jul 2005 15:08:23 +0200 (CEST) Date: Mon, 11 Jul 2005 15:08:22 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf Subject: Re: Updated Proposed update to Netconf Charter Message-ID: <20050711130822.GA900@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf References: <713043CE8B8E1348AF3C546DBE02C1B40412A358@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40412A358@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Jul 11, 2005 at 08:28:13AM -0400, Sharon Chisholm wrote: > - Framework for netconf access control. This access control mechanism > should consider integration with existing deployed solutions. It should > define a common authentication scheme. I don't know what the second sentence buys us - considering the integration with existing deployed solutions probably applies to almost all WGs in the IETF. On the other hand, having this sentence in the charter may lead to nasty discussions down the road if people start to force NETCONF access control to be compatible with VACM. I also fail to understand why you mix authentication in here. We already have netconf transports with different authentication schemes - do you want to open that can of worms? I suggest to only keep the first sentence and to remove the other two sentences or to clarify them. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 11 10:15:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drz4f-0005TM-92 for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 10:15:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14526 for ; Mon, 11 Jul 2005 10:15:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dryzw-000LA1-FF for netconf-data@psg.com; Mon, 11 Jul 2005 14:11:04 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dryzv-000L9o-F5 for netconf@ops.ietf.org; Mon, 11 Jul 2005 14:11:03 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 83C153969A; Mon, 11 Jul 2005 16:11:02 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20139-08; Mon, 11 Jul 2005 16:11:01 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6174F391C0; Mon, 11 Jul 2005 16:11:01 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id CA0EA379A65; Mon, 11 Jul 2005 16:11:00 +0200 (CEST) Date: Mon, 11 Jul 2005 16:11:00 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050711141100.GB971@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B40412A42A@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40412A42A@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Jul 11, 2005 at 09:26:46AM -0400, Sharon Chisholm wrote: > hi > > More or less. That and we should ensure that everything plays nice with > a common security infrastructure, rather than each other > > ___________ > SNMP -------- / \ > / \ > CLI -------/ \ > | Miracle \ > Netconf -------\ | > | / > Syslog -------- \ \ > -------------- > > As appose to > > SNMP <--miracle --> Netconf > CLI <--miracle --> Netconf > Syslog <--miracle --> Netconf > SNMP <--miracle--> CLI > SNMP <--miracle--> Syslog > CLI <--miracle--> Syslog We have VACM for SNMP and eventually we might have NACM for NETCONF. There is no agreed access control mechanism for CLIs and syslog and I think it is therefore out of scope to worry about this in the NETCONF WG. I also believe that VACM is rather SNMP specific since it relies on OID naming which luckily does not exist in NETCONF. So these two do not align well and even if you were to try, you would have to solve the SNMP naming to NETCONF naming coexistance/mapping problem as part of the solution. So I still believe NETCONF needs a good enough ACM for NETCONF, no more no less. This WG can't solve all the access control problems out there. Perhaps the only common denominator is the set of protocol specific operations an authenticated identity is allowed to perform if you consider integration. Everything above that which needs to be specific to the data model and representation will be rather difficult (and perhaps not even needed for a non-trivial class of operational environments). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 11 10:31:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrzJY-0000v3-Uh for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 10:31:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15701 for ; Mon, 11 Jul 2005 10:31:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrzDa-000MAC-6y for netconf-data@psg.com; Mon, 11 Jul 2005 14:25:10 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DrzDW-000M9t-Fa for netconf@ops.ietf.org; Mon, 11 Jul 2005 14:25:06 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j6BEOr911874; Mon, 11 Jul 2005 07:24:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j6BEOmj47439; Mon, 11 Jul 2005 07:24:48 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id j6BEUGYE076053; Mon, 11 Jul 2005 10:30:16 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200507111430.j6BEUGYE076053@idle.juniper.net> To: "Sharon Chisholm" cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter In-Reply-To: Your message of "Mon, 11 Jul 2005 09:26:46 EDT." <713043CE8B8E1348AF3C546DBE02C1B40412A42A@zcarhxm2.corp.nortel.com> Date: Mon, 11 Jul 2005 10:30:16 -0400 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk My guess is that miracles will always be outside our charter. Thanks, Phil "Sharon Chisholm" writes: >hi > >More or less. That and we should ensure that everything plays nice with >a common security infrastructure, rather than each other > > ___________ >SNMP -------- / \ > / \ >CLI -------/ \ > | Miracle \ >Netconf -------\ | > | / >Syslog -------- \ \ > -------------- > >As appose to > >SNMP <--miracle --> Netconf >CLI <--miracle --> Netconf >Syslog <--miracle --> Netconf >SNMP <--miracle--> CLI >SNMP <--miracle--> Syslog >CLI <--miracle--> Syslog > >Sharon > >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >Sent: Monday, July 11, 2005 8:11 AM >To: Chisholm, Sharon [CAR:5K50:EXCH] >Cc: netconf@ops.ietf.org >Subject: Re: Proposed Update to Netconf Charter > > >On Mon, Jul 11, 2005 at 08:00:57AM -0400, Sharon Chisholm wrote: > >> I think the goal with access control should be to try to integrate >> with existing deployed security solutions, not specifically with SNMP. > >> If SNMP succeeds in ISMS, then it will all be integrated without >> turning the netconf access control mechanisms into VACM. > >I have no clue what you are trying to convey here - the ISMS charter is >pretty clear in saying that ISMS is not supposed to touch access control > >issues. Perhaps you just wanted to say that NetConf access control >should not be constrained by the way VACM works - something I do agree >with. > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, >Germany > > >-- >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 Jul 11 10:58:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drzk5-0007Bp-Hx for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 10:58: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 KAA18291 for ; Mon, 11 Jul 2005 10:58:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DrzdQ-000O7B-Ru for netconf-data@psg.com; Mon, 11 Jul 2005 14:51:52 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DrzdO-000O6o-Pp for netconf@ops.ietf.org; Mon, 11 Jul 2005 14:51:50 +0000 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j6BEpoLb013724; Mon, 11 Jul 2005 07:51:50 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j6BEpjrt002174; Mon, 11 Jul 2005 07:51:45 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j6BEpjnw002170; Mon, 11 Jul 2005 07:51:45 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 11 Jul 2005 07:51:44 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Sharon Chisholm cc: netconf@ops.ietf.org Subject: RE: Proposed Update to Netconf Charter In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40412A33A@zcarhxm2.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, In SNMP, the identification of an instance of management information can only be extended in a backwards compatable way through use of contexts. In other management systems, such as CMIP and netconf, identification of an instance is simply extended by adding a new container object. In SNMP operations, a "context" applies to all items in the request, response, and notification. However, in other management protocols, the added container is needed only for those items for which it applies. Since Netconf can do a better job than SNMP in coping with not correctly predicting the future, I do not see a need for "contexts" (like those found in SNMP) in Netconf. Regards, /david t. perkins On Mon, 11 Jul 2005, Sharon Chisholm wrote: > hi > > Some comments on Contexts. I think this concept may well still be needed > because > > 1. People are always going to have trouble predicting the future > 2. Over-optimizing your schema for 'what ifs' can make the thing > complicated. > > For example, in order to support virtual routers, do you really extend > all of your traditional things like routing tables so you can have more > than one of them? Perhaps the answer is yes, since this also means > allows supports for distributed management, but is this worth it for the > simple case of a single router with a single routing table? > > Sharon > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, July 05, 2005 4:54 PM > To: David B Harrington > Cc: 'Andy Bierman'; Chisholm, Sharon [CAR:5K50:EXCH]; > netconf@ops.ietf.org > Subject: RE: Proposed Update to Netconf Charter > > > HI, > > Two specific items... > 1) I don't see the need for contexts in NETCONF data modeling, > since contexts are simply "a mechanism to add extra > indexing when the MIB designer failed to predict the future > evolution of technology" (or bandaid for poor MIB design). > With XML, I don't really believe this limitation is > present, and, thus, a "context" will not be needed. > > 2) SNMP VACM access control is based on > 1) the identication of the management information > (the variable name) > 2) the operation type (read/write/notify) > 3) the security model > 4) the security level > 5) the context > 6) the group > It doesn't depend on the value of object instance. This > has resulted in MIB design patterns where objects are > made (unnaturally) into index object(s). The usual > case is where the security name (or group name) > is made into an index. Many other systems, especially > data base systems have access control based on > data values. > > In the work that I have done explaining VACM, the > concept that what security level is used can affect > what can be accessed is always a very big surprise. > > So far, there is a single security model. If several > were present, then the number of entries in the VACM > table could increase by a factor of the number. > > In general, the SNMP acess model is unlike anything > that most users are use to. Thus, they can not > understand it, and its richness is typically never > used. It is also typically not used because the > objects used by management apps are not typically > characterized. Thus, most systems that I've seen > provide no restriction to management platforms, and > any restriction is done by a management platform > as to which management applications any specific > user can run. > > Thus, I would characterize VACM as completely missing > the target. It is too complex for typical usage, > and not rich enough for realworld usage. > > Regards, > /david t. perkins > > On Tue, 5 Jul 2005, David B Harrington wrote: > > > Hi Andy, > > > > > Access control is also critical to get in place early on. > > > I prefer to start simple and evolve the complexity over time. IMO, a > > > > mapping to ISMS should be a separate work effort, and probably in > > > that WG. > > > > > > NETCONF AC is unique because it is both "RPC method" and > > > document oriented. > > > IMO, old approaches like VACM will be clumsy and/or bloated if > > applied > > > to NETCONF. Some new innovation is required here. > > > > > > > I'm interested in your views about the uniqueness of netconf AC. > > > > In SNMPv3, as you know, we found that all operations could be > > abstracted into read/write/notify types of operations for purposes of > > AC. There was not a real need to distinguish between GET, GETBULK, and > > > other proposed GET-XXXX operations. Do you see a real need to > > distinguish between the various RPC methods, etc., that > > would be initiated by an operator? > > > > In the SNMPv3 isAccessAllowed() ASI, variableName names the instance > > of the managed object. Would netconf use a similar (XML-based) > > variablename to identify the instance of the managed object? > > > > Do you expect that "documents" will be aggregations of objects that > > are not necessarily from the same XML subtree? I can see this if the > > document is an HTML web page; but if it is built from data elements > > defined as an XML instance, then would AC based on the underlying XML > > suffice? Cf: a varbind list with an aggregation of various managed > > objects. Do you have something different in mind for documents? > > > > In SNMPv3, we have contexts to differentiate MIB instances. I assume > > such a concept would also be needed for netconf. Do you agree? Is > > "running" and "candidate" about as deep as you need to go for netconf > > contexts, or do you need the greater depth found in the SNMP contexts? > > > Do you anticipate a future need to be able to configure, for example, > > the XML instance for a specific blade in a server? > > > > I'm interested in your thoughts on this because VACM has not gained > > very wide acceptance, and a simpler AC model that could be used with > > both netconf's XML hierarchical naming scheme and SNMP's OID > > hierarchical naming scheme (or an XML-based SNMP naming scheme) could > > help both protocols. I'm also interested in probing how the > > requirements for netconf AC and SNMP AC might differ, since this could > > > also have an impact on whether ISMS design should even try to be > > future-compatible with netconf. > > > > David Harrington > > dbharrington@comcast.net > > > > > > > > > > > > > > > > -- > > 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: > -- 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 Jul 11 12:10:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds0rc-00046R-VU for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 12:10:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24717 for ; Mon, 11 Jul 2005 12:10:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds0gC-0003r8-AN for netconf-data@psg.com; Mon, 11 Jul 2005 15:58:48 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds0g8-0003qR-98 for netconf@ops.ietf.org; Mon, 11 Jul 2005 15:58:44 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 330A039185; Mon, 11 Jul 2005 17:58:43 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26565-01; Mon, 11 Jul 2005 17:58:42 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id F055A39150; Mon, 11 Jul 2005 17:58:41 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 4D96B379B94; Mon, 11 Jul 2005 17:58:41 +0200 (CEST) Date: Mon, 11 Jul 2005 17:58:41 +0200 From: Juergen Schoenwaelder To: "David T. Perkins" Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter Message-ID: <20050711155841.GC1333@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "David T. Perkins" , Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B40412A33A@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Jul 11, 2005 at 07:51:44AM -0700, David T. Perkins wrote: > In SNMP, the identification of an instance of management information > can only be extended in a backwards compatable way through use of > contexts. In other management systems, such as CMIP and netconf, > identification of an instance is simply extended by adding a new > container object. In SNMP operations, a "context" applies to > all items in the request, response, and notification. However, > in other management protocols, the added container is needed > only for those items for which it applies. Adding a container might be as difficult as adding an index to a table once a data model has been deployed. Note that CMIP really tried to tackle parts of this problem by introducing allomorphism. There are a few articles in CMIP Run! which deal with this topic in case someone is interested. I am sure Randy knows the details well and whether this was a success story. In modern programming languages such as Java, the concept of interfaces became popular and this allows on object to actually support multiple interfaces, which can be exploited for backwards compatibility if you want. But to be honest, I do not see any of these fancy concepts applying to XML encoded documents. I am not advocating to add something like contexts - if you have screwed something up in your XML hierarchy, fix it by fixing the data model and use name spaces and version numbers to deal with backwards compatibility issues. The hope is that the costs of doing this and adopting to such changes will be reasonably cheap in XML land. If netconf is successful, we will know in say 5 years whether this is actually true. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 11 12:27:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds189-0002jx-Md for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 12:27:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26266 for ; Mon, 11 Jul 2005 12:27:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds12F-0005o9-6Y for netconf-data@psg.com; Mon, 11 Jul 2005 16:21:35 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Ds12B-0005nk-Uu for netconf@ops.ietf.org; Mon, 11 Jul 2005 16:21:31 +0000 Received: from [10.18.39.60] ([142.59.18.89]) by www.icesoft.com (Kerio MailServer 6.0.10) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Mon, 11 Jul 2005 08:49:11 -0700 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40412A310@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B40412A310@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "netconf" Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 09:51:27 -0600 To: Sharon Chisholm X-Mailer: Apple Mail (2.730) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The idea was that new dedicated ports should be assigned, but their use is not mandatory. SOAP/HTTP allows applications to be distinguished by URL, thereby allowing a variety of applications to coexist on the same port (so the distinct port may be necessary for administrative policy, but it's not necessary for the functioning of the protocol). Perhaps the wording should be changed as follows? > A NETCONF SOAP service can be offered on any desired port, but > a new standard port for SOAP over HTTP, and a > new standard port for NETCONF over SOAP (over HTTP) will be defined Regards, Ted. On 11-Jul-05, at 5:34 AM, Sharon Chisholm wrote: > hi > > I have a clarifying question: > > The last paragraph of section 2.4 reads > > "It is also possible to respond to the concern on the re-use of port > 80. A NETCONF SOAP service can be offered on any desired port, and > it is recommended that a new standard port for SOAP over HTTP, or a > new standard port for NETCONF over SOAP (over HTTP) be defined, as > requested in the IANA considerations of this document." > > Which considering the IANA considerations section says the following > > "The IANA will assign TCP ports for NETCONF for SOAP over HTTP and > SOAP over BEEP." > > seems too weak. Is the section in 2.4 left over from before it was > decided we liked specific ports, or did we intend to leave port use as > an exercise to the reader? > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner- > netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, July 07, 2005 10:22 PM > To: Bert Wijnen > Cc: Simon Leinen; David Kessens; netconf; iesg-secretary@ietf.org > Subject: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > [Area] OPS-NM > [WG] NETCONF > [I-D] draft-ietf-netconf-soap-05.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt > [Shep] Andy Bierman > > 1.a) Yes, the WG Chairs have reviewed this version of the > document, and believe it is ready for publication. > > 1.b) Yes the document has had adequate review. Several > WG members have reviewed this document. > > 1.c) There are no open issues, and no further review is > required, for this document. > > 1.d) There are no concerns with this document at this time. > It is possible that clarifications will be identified > as implementation and interoperability experience is > reported to the WG. > > 1.e) There is strong WG consensus for this document. > It is expected that more complex network applications > (e.g., 1st or 3rd party commercial applications) will > use this application mapping for NETCONF. > > 1.f) No appeals have been threatened against this document. > > 1.g) There are some minor ID-nits that will be fixed > before RFC publication. (See ID-nit log below). > > 1.h) Yes, references are split. > Yes, there is a reference to an unpublished document, > namely the NETCONF Configuration Protocol document > (draft-ietf-netconf-prot-07.txt), but this is also ready > for publication. > > 1.j) I-D Submission Summary > > Technical Summary > > > The Network Configuration Protocol (NETCONF) is applicable to a > wide > range of devices in a variety of environments. The emergence of > Web > Services gives one such environment, and is presently characterized > by the use of the Simple Object Access Protocol (SOAP). NETCONF > finds many benefits in this environment: from the re-use of > existing > standards, to ease of software development, to integration with > deployed systems. Herein, we describe SOAP over HTTP and SOAP over > BEEP bindings for NETCONF. > > Working Group Summary > > The NETCONF Working Group has consensus to publish this document > as a Proposed Standard. > > Protocol Quality > > It is likely that there are several implementations of this > document in various stages of completion at this time. > Several major equipment vendors have indicated interest in > supporting this document, and some non-commercial > implementations are also expected. > > ---------------- > > [ID-nit log] > > idnits 1.74 > > tmp/draft-ietf-netconf-soap-05.txt: > > tmp/draft-ietf-netconf-soap-05.txt(452): > Line is too long: the offending characters are 'elope"' > tmp/draft-ietf-netconf-soap-05.txt(464): > Line is too long: the offending characters are 's:netconf:base: > 1.0">' > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > Checking conformance with RFC 3978/3979 boilerplate... > * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure > Acknowledgement. > > (Expected a match on the following text: > "By submitting this Internet-Draft, each author represents that > any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79.") > > (The document uses RFC 3667 boilerplate or RFC 3978-like > boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May > 2005, > submission of drafts without verbatim RFC 3978 boilerplate is not > accepted.) > > Checking nits according to > http://www.ietf.org/ietf/1id-guidelines.txt: > Nothing found here (but these checks do not cover all of > 1id-guidelines.txt yet). > > Miscellaneous warnings: > None. > > > > -- > 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: > -- 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 Jul 11 12:30:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1Ai-0003Lg-LH for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 12:30:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26503 for ; Mon, 11 Jul 2005 12:30:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds13D-0005rI-7l for netconf-data@psg.com; Mon, 11 Jul 2005 16:22:35 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Ds13C-0005r2-4A for netconf@ops.ietf.org; Mon, 11 Jul 2005 16:22:34 +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 j6BGMVn04699 for ; Mon, 11 Jul 2005 12:22:31 -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: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 12:22:30 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40412A732@zcarhxm2.corp.nortel.com> Thread-Topic: I-D Publication Request: draft-ietf-netconf-soap-05.txt Thread-Index: AcWGMGbpO1B+khjfRN67++8INhUCMgABCTlg From: "Sharon Chisholm" To: "netconf" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I like it. If there is agreement it could be added as one of those notes to the RFC editor. Sharon -----Original Message----- From: Ted Goddard [mailto:ted.goddard@icesoft.com]=20 Sent: Monday, July 11, 2005 11:51 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt The idea was that new dedicated ports should be assigned, but their use is not mandatory. SOAP/HTTP allows applications to be distinguished by URL, thereby allowing a variety of applications to coexist on the same port (so the distinct port may be necessary for administrative policy, but it's not necessary for the functioning of the protocol). Perhaps the wording should be changed as follows? > A NETCONF SOAP service can be offered on any desired port, but > a new standard port for SOAP over HTTP, and a > new standard port for NETCONF over SOAP (over HTTP) will be defined Regards, Ted. On 11-Jul-05, at 5:34 AM, Sharon Chisholm wrote: > hi > > I have a clarifying question: > > The last paragraph of section 2.4 reads > > "It is also possible to respond to the concern on the re-use of port > 80. A NETCONF SOAP service can be offered on any desired port, and > it is recommended that a new standard port for SOAP over HTTP, or a > new standard port for NETCONF over SOAP (over HTTP) be defined, as > requested in the IANA considerations of this document." > > Which considering the IANA considerations section says the following > > "The IANA will assign TCP ports for NETCONF for SOAP over HTTP and > SOAP over BEEP." > > seems too weak. Is the section in 2.4 left over from before it was=20 > decided we liked specific ports, or did we intend to leave port use as > an exercise to the reader? > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner- > netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, July 07, 2005 10:22 PM > To: Bert Wijnen > Cc: Simon Leinen; David Kessens; netconf; iesg-secretary@ietf.org > Subject: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > [Area] OPS-NM > [WG] NETCONF > [I-D] draft-ietf-netconf-soap-05.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt > [Shep] Andy Bierman > > 1.a) Yes, the WG Chairs have reviewed this version of the > document, and believe it is ready for publication. > > 1.b) Yes the document has had adequate review. Several > WG members have reviewed this document. > > 1.c) There are no open issues, and no further review is > required, for this document. > > 1.d) There are no concerns with this document at this time. > It is possible that clarifications will be identified > as implementation and interoperability experience is > reported to the WG. > > 1.e) There is strong WG consensus for this document. > It is expected that more complex network applications > (e.g., 1st or 3rd party commercial applications) will > use this application mapping for NETCONF. > > 1.f) No appeals have been threatened against this document. > > 1.g) There are some minor ID-nits that will be fixed > before RFC publication. (See ID-nit log below). > > 1.h) Yes, references are split. > Yes, there is a reference to an unpublished document, > namely the NETCONF Configuration Protocol document > (draft-ietf-netconf-prot-07.txt), but this is also ready > for publication. > > 1.j) I-D Submission Summary > > Technical Summary > > > The Network Configuration Protocol (NETCONF) is applicable to a > wide > range of devices in a variety of environments. The emergence of =20 > Web > Services gives one such environment, and is presently characterized > by the use of the Simple Object Access Protocol (SOAP). NETCONF > finds many benefits in this environment: from the re-use of =20 > existing > standards, to ease of software development, to integration with > deployed systems. Herein, we describe SOAP over HTTP and SOAP over > BEEP bindings for NETCONF. > > Working Group Summary > > The NETCONF Working Group has consensus to publish this document > as a Proposed Standard. > > Protocol Quality > > It is likely that there are several implementations of this > document in various stages of completion at this time. > Several major equipment vendors have indicated interest in > supporting this document, and some non-commercial > implementations are also expected. > > ---------------- > > [ID-nit log] > > idnits 1.74 > > tmp/draft-ietf-netconf-soap-05.txt: > > tmp/draft-ietf-netconf-soap-05.txt(452): > Line is too long: the offending characters are 'elope"' > tmp/draft-ietf-netconf-soap-05.txt(464): > Line is too long: the offending characters are 's:netconf:base: > 1.0">' > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > Checking conformance with RFC 3978/3979 boilerplate... > * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure > Acknowledgement. > > (Expected a match on the following text: > "By submitting this Internet-Draft, each author represents that > any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79.") > > (The document uses RFC 3667 boilerplate or RFC 3978-like > boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May > 2005, > submission of drafts without verbatim RFC 3978 boilerplate is not > accepted.) > > Checking nits according to > http://www.ietf.org/ietf/1id-guidelines.txt: > Nothing found here (but these checks do not cover all of > 1id-guidelines.txt yet). > > Miscellaneous warnings: > None. > > > > -- > 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: > -- 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 Jul 11 12:52:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1W7-00013d-N7 for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 12:52:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28657 for ; Mon, 11 Jul 2005 12:52:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds1Qw-0007vR-Q8 for netconf-data@psg.com; Mon, 11 Jul 2005 16:47:06 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds1Qs-0007uz-Kz for netconf@ops.ietf.org; Mon, 11 Jul 2005 16:47:02 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j6BGjkjs009034; Mon, 11 Jul 2005 09:45:50 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Jul 2005 09:46:31 -0700 Message-ID: From: "McDonald, Ira" To: "'Sharon Chisholm'" , netconf Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 09:46:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I think you're leaning in the wrong direction here, folks. Port-based screening is easy and standard to implement in firewalls and routers. URL-based screening inside SOAP takes a fairly expensive ALG (application layer gateway) in the firewall and still is much less secure (because denial-of-service only requires attacking the _port_, not the specific SOAP application). The IESG can and should vigorously object to NetConf being ambiguous about the requirement for using dedicated standard port(s). They discouraged deployment of IPP/1.0 in print systems for two years until IPP/1.1 required port 631 and deprecated the use of port 80. That mess led to RFC 3205 "On the use of HTTP as a Substrate". I suggest reading section 3 'Issues Regarding Reuse of Port 80' of RFC 3205. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Monday, July 11, 2005 12:23 PM > To: netconf > Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > hi > > I like it. If there is agreement it could be added as one of > those notes > to the RFC editor. > > Sharon > > -----Original Message----- > From: Ted Goddard [mailto:ted.goddard@icesoft.com] > Sent: Monday, July 11, 2005 11:51 AM > To: Chisholm, Sharon [CAR:5K50:EXCH] > Cc: netconf > Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > > The idea was that new dedicated ports should be assigned, but > their use > is not mandatory. SOAP/HTTP allows applications to be > distinguished by > URL, thereby allowing a variety of applications to coexist on the same > port (so the distinct port may be necessary for administrative policy, > but it's not necessary for the functioning of the protocol). > > Perhaps the wording should be changed as follows? > > > A NETCONF SOAP service can be offered on any desired port, but > > a new standard port for SOAP over HTTP, and a > > new standard port for NETCONF over SOAP (over HTTP) will > be defined > > > Regards, > Ted. > > On 11-Jul-05, at 5:34 AM, Sharon Chisholm wrote: > > > hi > > > > I have a clarifying question: > > > > The last paragraph of section 2.4 reads > > > > "It is also possible to respond to the concern on the re-use of port > > 80. A NETCONF SOAP service can be offered on any > desired port, and > > it is recommended that a new standard port for SOAP over > HTTP, or a > > new standard port for NETCONF over SOAP (over HTTP) be > defined, as > > requested in the IANA considerations of this document." > > > > Which considering the IANA considerations section says the following > > > > "The IANA will assign TCP ports for NETCONF for SOAP over HTTP and > > SOAP over BEEP." > > > > seems too weak. Is the section in 2.4 left over from before it was > > decided we liked specific ports, or did we intend to leave > port use as > > > an exercise to the reader? > > > > Sharon > > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org [mailto:owner- > > netconf@ops.ietf.org] On > > Behalf Of Andy Bierman > > Sent: Thursday, July 07, 2005 10:22 PM > > To: Bert Wijnen > > Cc: Simon Leinen; David Kessens; netconf; iesg-secretary@ietf.org > > Subject: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > > > > [Area] OPS-NM > > [WG] NETCONF > > [I-D] draft-ietf-netconf-soap-05.txt > > [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt > > [Shep] Andy Bierman > > > > 1.a) Yes, the WG Chairs have reviewed this version of the > > document, and believe it is ready for publication. > > > > 1.b) Yes the document has had adequate review. Several > > WG members have reviewed this document. > > > > 1.c) There are no open issues, and no further review is > > required, for this document. > > > > 1.d) There are no concerns with this document at this time. > > It is possible that clarifications will be identified > > as implementation and interoperability experience is > > reported to the WG. > > > > 1.e) There is strong WG consensus for this document. > > It is expected that more complex network applications > > (e.g., 1st or 3rd party commercial applications) will > > use this application mapping for NETCONF. > > > > 1.f) No appeals have been threatened against this document. > > > > 1.g) There are some minor ID-nits that will be fixed > > before RFC publication. (See ID-nit log below). > > > > 1.h) Yes, references are split. > > Yes, there is a reference to an unpublished document, > > namely the NETCONF Configuration Protocol document > > (draft-ietf-netconf-prot-07.txt), but this is also ready > > for publication. > > > > 1.j) I-D Submission Summary > > > > Technical Summary > > > > > > The Network Configuration Protocol (NETCONF) is applicable to a > > wide > > range of devices in a variety of environments. The > emergence of > > Web > > Services gives one such environment, and is presently > characterized > > by the use of the Simple Object Access Protocol (SOAP). NETCONF > > finds many benefits in this environment: from the re-use of > > existing > > standards, to ease of software development, to integration with > > deployed systems. Herein, we describe SOAP over HTTP > and SOAP over > > BEEP bindings for NETCONF. > > > > Working Group Summary > > > > The NETCONF Working Group has consensus to publish this document > > as a Proposed Standard. > > > > Protocol Quality > > > > It is likely that there are several implementations of this > > document in various stages of completion at this time. > > Several major equipment vendors have indicated interest in > > supporting this document, and some non-commercial > > implementations are also expected. > > > > ---------------- > > > > [ID-nit log] > > > > idnits 1.74 > > > > tmp/draft-ietf-netconf-soap-05.txt: > > > > tmp/draft-ietf-netconf-soap-05.txt(452): > > Line is too long: the offending characters are 'elope"' > > tmp/draft-ietf-netconf-soap-05.txt(464): > > Line is too long: the offending characters are 's:netconf:base: > > 1.0">' > > > > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > Checking conformance with RFC 3978/3979 boilerplate... > > * The document seems to lack an RFC 3978 Section 5.1 IPR > Disclosure > > Acknowledgement. > > > > (Expected a match on the following text: > > "By submitting this Internet-Draft, each author represents that > > any > > applicable patent or other IPR claims of which he or > she is aware > > have been or will be disclosed, and any of which he or > she becomes > > aware will be disclosed, in accordance with Section 6 > of BCP 79.") > > > > (The document uses RFC 3667 boilerplate or RFC 3978-like > > boilerplate instead of verbatim RFC 3978 boilerplate. > After 6 May > > > 2005, > > submission of drafts without verbatim RFC 3978 > boilerplate is not > > accepted.) > > > > Checking nits according to > > http://www.ietf.org/ietf/1id-guidelines.txt: > > Nothing found here (but these checks do not cover all of > > 1id-guidelines.txt yet). > > > > Miscellaneous warnings: > > None. > > > > > > > > -- > > 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: > > > > > > > -- > 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 Jul 11 13:08:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1lD-00060n-6K for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 13:08:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01423 for ; Mon, 11 Jul 2005 13:07:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds1fU-0009RI-BO for netconf-data@psg.com; Mon, 11 Jul 2005 17:02:08 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Ds1fR-0009Qw-5P for netconf@ops.ietf.org; Mon, 11 Jul 2005 17:02:05 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.0.10) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Mon, 11 Jul 2005 09:59:48 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "'Sharon Chisholm'" , netconf Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 11:02:04 -0600 To: "McDonald, Ira" X-Mailer: Apple Mail (2.730) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ira, > URL-based screening inside SOAP takes a fairly expensive ALG > (application layer gateway) in the firewall and still is much less > secure > (because denial-of-service only requires attacking the _port_, not the > specific SOAP application). Why can't the firewall simply drop all requests to the NETCONF URL if the origin of those requests is on a list of attackers? This seems more expensive to process (string comparison vs integer comparison) but not fundamentally less secure. Thanks, Ted. On 11-Jul-05, at 10:46 AM, McDonald, Ira wrote: > Hi, > > I think you're leaning in the wrong direction here, folks. > > Port-based screening is easy and standard to implement in firewalls > and > routers. URL-based screening inside SOAP takes a fairly expensive ALG > (application layer gateway) in the firewall and still is much less > secure > (because denial-of-service only requires attacking the _port_, not the > specific SOAP application). > > The IESG can and should vigorously object to NetConf being ambiguous > about the requirement for using dedicated standard port(s). They > discouraged deployment of IPP/1.0 in print systems for two years > until IPP/1.1 required port 631 and deprecated the use of port 80. > That mess led to RFC 3205 "On the use of HTTP as a Substrate". > > I suggest reading section 3 'Issues Regarding Reuse of Port 80' of > RFC 3205. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner- >> netconf@ops.ietf.org]On >> Behalf Of Sharon Chisholm >> Sent: Monday, July 11, 2005 12:23 PM >> To: netconf >> Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt >> >> >> hi >> >> I like it. If there is agreement it could be added as one of >> those notes >> to the RFC editor. >> >> Sharon >> >> -----Original Message----- >> From: Ted Goddard [mailto:ted.goddard@icesoft.com] >> Sent: Monday, July 11, 2005 11:51 AM >> To: Chisholm, Sharon [CAR:5K50:EXCH] >> Cc: netconf >> Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt >> >> >> >> The idea was that new dedicated ports should be assigned, but >> their use >> is not mandatory. SOAP/HTTP allows applications to be >> distinguished by >> URL, thereby allowing a variety of applications to coexist on the >> same >> port (so the distinct port may be necessary for administrative >> policy, >> but it's not necessary for the functioning of the protocol). >> >> Perhaps the wording should be changed as follows? >> >> >>> A NETCONF SOAP service can be offered on any desired port, but >>> a new standard port for SOAP over HTTP, and a >>> new standard port for NETCONF over SOAP (over HTTP) will >>> >> be defined >> >> >> Regards, >> Ted. >> >> On 11-Jul-05, at 5:34 AM, Sharon Chisholm wrote: >> >> >>> hi >>> >>> I have a clarifying question: >>> >>> The last paragraph of section 2.4 reads >>> >>> "It is also possible to respond to the concern on the re-use of port >>> 80. A NETCONF SOAP service can be offered on any >>> >> desired port, and >> >>> it is recommended that a new standard port for SOAP over >>> >> HTTP, or a >> >>> new standard port for NETCONF over SOAP (over HTTP) be >>> >> defined, as >> >>> requested in the IANA considerations of this document." >>> >>> Which considering the IANA considerations section says the following >>> >>> "The IANA will assign TCP ports for NETCONF for SOAP over HTTP and >>> SOAP over BEEP." >>> >>> seems too weak. Is the section in 2.4 left over from before it was >>> decided we liked specific ports, or did we intend to leave >>> >> port use as >> >> >>> an exercise to the reader? >>> >>> Sharon >>> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner- >>> netconf@ops.ietf.org] On >>> Behalf Of Andy Bierman >>> Sent: Thursday, July 07, 2005 10:22 PM >>> To: Bert Wijnen >>> Cc: Simon Leinen; David Kessens; netconf; iesg-secretary@ietf.org >>> Subject: I-D Publication Request: draft-ietf-netconf-soap-05.txt >>> >>> >>> [Area] OPS-NM >>> [WG] NETCONF >>> [I-D] draft-ietf-netconf-soap-05.txt >>> [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt >>> [Shep] Andy Bierman >>> >>> 1.a) Yes, the WG Chairs have reviewed this version of the >>> document, and believe it is ready for publication. >>> >>> 1.b) Yes the document has had adequate review. Several >>> WG members have reviewed this document. >>> >>> 1.c) There are no open issues, and no further review is >>> required, for this document. >>> >>> 1.d) There are no concerns with this document at this time. >>> It is possible that clarifications will be identified >>> as implementation and interoperability experience is >>> reported to the WG. >>> >>> 1.e) There is strong WG consensus for this document. >>> It is expected that more complex network applications >>> (e.g., 1st or 3rd party commercial applications) will >>> use this application mapping for NETCONF. >>> >>> 1.f) No appeals have been threatened against this document. >>> >>> 1.g) There are some minor ID-nits that will be fixed >>> before RFC publication. (See ID-nit log below). >>> >>> 1.h) Yes, references are split. >>> Yes, there is a reference to an unpublished document, >>> namely the NETCONF Configuration Protocol document >>> (draft-ietf-netconf-prot-07.txt), but this is also ready >>> for publication. >>> >>> 1.j) I-D Submission Summary >>> >>> Technical Summary >>> >>> >>> The Network Configuration Protocol (NETCONF) is applicable to a >>> wide >>> range of devices in a variety of environments. The >>> >> emergence of >> >>> Web >>> Services gives one such environment, and is presently >>> >> characterized >> >>> by the use of the Simple Object Access Protocol (SOAP). NETCONF >>> finds many benefits in this environment: from the re-use of >>> existing >>> standards, to ease of software development, to integration with >>> deployed systems. Herein, we describe SOAP over HTTP >>> >> and SOAP over >> >>> BEEP bindings for NETCONF. >>> >>> Working Group Summary >>> >>> The NETCONF Working Group has consensus to publish this document >>> as a Proposed Standard. >>> >>> Protocol Quality >>> >>> It is likely that there are several implementations of this >>> document in various stages of completion at this time. >>> Several major equipment vendors have indicated interest in >>> supporting this document, and some non-commercial >>> implementations are also expected. >>> >>> ---------------- >>> >>> [ID-nit log] >>> >>> idnits 1.74 >>> >>> tmp/draft-ietf-netconf-soap-05.txt: >>> >>> tmp/draft-ietf-netconf-soap-05.txt(452): >>> Line is too long: the offending characters are 'elope"' >>> tmp/draft-ietf-netconf-soap-05.txt(464): >>> Line is too long: the offending characters are 's:netconf:base: >>> 1.0">' >>> >>> >>> Checking nits according to http://www.ietf.org/ID-Checklist.html: >>> Checking conformance with RFC 3978/3979 boilerplate... >>> * The document seems to lack an RFC 3978 Section 5.1 IPR >>> >> Disclosure >> >>> Acknowledgement. >>> >>> (Expected a match on the following text: >>> "By submitting this Internet-Draft, each author represents that >>> any >>> applicable patent or other IPR claims of which he or >>> >> she is aware >> >>> have been or will be disclosed, and any of which he or >>> >> she becomes >> >>> aware will be disclosed, in accordance with Section 6 >>> >> of BCP 79.") >> >>> >>> (The document uses RFC 3667 boilerplate or RFC 3978-like >>> boilerplate instead of verbatim RFC 3978 boilerplate. >>> >> After 6 May >> >> >>> 2005, >>> submission of drafts without verbatim RFC 3978 >>> >> boilerplate is not >> >>> accepted.) >>> >>> Checking nits according to >>> http://www.ietf.org/ietf/1id-guidelines.txt: >>> Nothing found here (but these checks do not cover all of >>> 1id-guidelines.txt yet). >>> >>> Miscellaneous warnings: >>> None. >>> >>> >>> >>> -- >>> 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: >>> >>> >> >> >> >> >> -- >> 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: > -- 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 Jul 11 15:59:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds4Qv-0008Ke-Qu for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 15:59:18 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17343 for ; Mon, 11 Jul 2005 15:59:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds4LI-000NHs-Hd for netconf-data@psg.com; Mon, 11 Jul 2005 19:53:28 +0000 Received: from [85.73.177.31] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds4LF-000NG1-71 for netconf@ops.ietf.org; Mon, 11 Jul 2005 19:53:25 +0000 Received: by boskop.local (Postfix, from userid 501) id BF90F379CDD; Mon, 11 Jul 2005 21:53:22 +0200 (CEST) Date: Mon, 11 Jul 2005 21:53:22 +0200 From: Juergen Schoenwaelder To: Ted Goddard Cc: "McDonald, Ira" , "'Sharon Chisholm'" , netconf Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt Message-ID: <20050711195322.GA1558@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Ted Goddard , "McDonald, Ira" , 'Sharon Chisholm' , netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Jul 11, 2005 at 11:02:04AM -0600, Ted Goddard wrote: > Why can't the firewall simply drop all requests to the NETCONF URL > if the origin of those requests is on a list of attackers? This seems > more expensive to process (string comparison vs integer comparison) > but not fundamentally less secure. I think Ira was pointing to my Linux kernel which is pretty good in filtering packets based on port numbers but rather bad in filtering SOAP requests by URL or something like that. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 11 16:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5JD-0003Ec-3A for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 16:55: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 QAA13587 for ; Mon, 11 Jul 2005 16:55:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds5By-0002aJ-A4 for netconf-data@psg.com; Mon, 11 Jul 2005 20:47:54 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds5Bw-0002a6-Jv for netconf@ops.ietf.org; Mon, 11 Jul 2005 20:47:52 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j6BKlN40019165; Mon, 11 Jul 2005 13:47:23 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Jul 2005 13:48:10 -0700 Message-ID: From: "McDonald, Ira" To: "'j.schoenwaelder@iu-bremen.de'" , Ted Goddard Cc: "McDonald, Ira" , "'Sharon Chisholm'" , netconf Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 13:48:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, The point I was trying to make is that if NetConf shares port 80 with other applications, then ANY denial-of-service attack against port 80 blocks ALL of those applications (including the important NetConf for system management purposes). If you use a dedicated port, then much simpler protection can be performed. And NetConf doesn't wind up sharing port 80 with the embedded Web server that is often (unwisely?) included in pieces of network infrastructure equipment. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Monday, July 11, 2005 3:53 PM > To: Ted Goddard > Cc: McDonald, Ira; 'Sharon Chisholm'; netconf > Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > On Mon, Jul 11, 2005 at 11:02:04AM -0600, Ted Goddard wrote: > > > Why can't the firewall simply drop all requests to the NETCONF URL > > if the origin of those requests is on a list of attackers? > This seems > > more expensive to process (string comparison vs integer comparison) > > but not fundamentally less secure. > > I think Ira was pointing to my Linux kernel which is pretty good in > filtering packets based on port numbers but rather bad in filtering > SOAP requests by URL or something like that. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > -- 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 Jul 11 16:59:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5Mo-0005jy-Cc for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 16:59:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15053 for ; Mon, 11 Jul 2005 16:59:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds5Hf-00038O-RR for netconf-data@psg.com; Mon, 11 Jul 2005 20:53:47 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Ds5Hf-000387-DA for netconf@ops.ietf.org; Mon, 11 Jul 2005 20:53:47 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j6BKrbBm054797; Mon, 11 Jul 2005 13:53:37 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j6BKraj16735; Mon, 11 Jul 2005 13:53:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id j6BKx0YE077445; Mon, 11 Jul 2005 16:59:04 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200507112059.j6BKx0YE077445@idle.juniper.net> To: "McDonald, Ira" cc: "'j.schoenwaelder@iu-bremen.de'" , Ted Goddard , "'Sharon Chisholm'" , netconf Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt In-Reply-To: Your message of "Mon, 11 Jul 2005 13:48:01 PDT." Date: Mon, 11 Jul 2005 16:59:00 -0400 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk "McDonald, Ira" writes: >If you use a dedicated port, then much simpler protection can be >performed. I think this issue is an old one. We had concensus on not using port 80 and on requesting an official port. If the draft doesn't track this, it needs an update. Thanks, Phil -- 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 Jul 11 17:03:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5Qo-0002Pc-JD for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 17:03:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16059 for ; Mon, 11 Jul 2005 17:03:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds5LH-0003bA-UC for netconf-data@psg.com; Mon, 11 Jul 2005 20:57:31 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds5L2-0003Yh-3t for netconf@ops.ietf.org; Mon, 11 Jul 2005 20:57:30 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j6BKusOD019581; Mon, 11 Jul 2005 13:56:54 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Jul 2005 13:57:41 -0700 Message-ID: From: "McDonald, Ira" To: "'Phil Shafer'" , "McDonald, Ira" Cc: "'j.schoenwaelder@iu-bremen.de'" , Ted Goddard , "'Sharon Chisholm'" , netconf Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 13:57:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Phil, The draft certainly doesn't track that 'concensus'. The draft should explicitly say SHOULD NOT use port 80 for NetConf for reliability and security reasons. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Monday, July 11, 2005 4:59 PM > To: McDonald, Ira > Cc: 'j.schoenwaelder@iu-bremen.de'; Ted Goddard; 'Sharon Chisholm'; > netconf > Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > "McDonald, Ira" writes: > >If you use a dedicated port, then much simpler protection can be > >performed. > > I think this issue is an old one. We had concensus on > not using port 80 and on requesting an official port. > If the draft doesn't track this, it needs an update. > > Thanks, > Phil > -- 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 Jul 11 17:12:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5ZS-0008H5-UG for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 17:12:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16813 for ; Mon, 11 Jul 2005 17:12:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds5UA-0004hH-0l for netconf-data@psg.com; Mon, 11 Jul 2005 21:06:42 +0000 Received: from [207.69.195.67] (helo=pop-tawny.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds5U7-0004gq-AI for netconf@ops.ietf.org; Mon, 11 Jul 2005 21:06:39 +0000 Received: from h-68-166-37-248.snvacaid.dynamic.covad.net ([68.166.37.248] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ds5U5-0004Io-00 for netconf@ops.ietf.org; Mon, 11 Jul 2005 17:06:37 -0400 Message-ID: <00bc01c5865d$06a6c380$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "netconf" References: <713043CE8B8E1348AF3C546DBE02C1B40412A358@zcarhxm2.corp.nortel.com> Subject: Re: Updated Proposed update to Netconf Charter Date: Mon, 11 Jul 2005 14:10:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Sharon Chisholm" > To: "netconf" > Sent: Monday, July 11, 2005 5:28 AM > Subject: Updated Proposed update to Netconf Charter ... > - Framework for netconf access control. This access control mechanism > should consider integration with existing deployed solutions. It should > define a common authentication scheme. ... Access control mechanisms are about a lot more than just authentication. They involve the identification of the information to which access should be controlled, the identification of the possible operations, the identification of the roles/principals requesting access, and more. When you write "integration with existing deployed solutions", are you considering just the authentication aspect, or are you considering some mechanism for the distribution / maintenance of access control policies? Randy -- 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 Jul 11 17:41:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds61X-0001pX-36 for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 17:41:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18505 for ; Mon, 11 Jul 2005 17:41:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds5xU-0006oc-Ew for netconf-data@psg.com; Mon, 11 Jul 2005 21:37:00 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Ds5xS-0006oK-LK for netconf@ops.ietf.org; Mon, 11 Jul 2005 21:36:58 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.0.10) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Mon, 11 Jul 2005 14:34:44 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: netconf Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Mon, 11 Jul 2005 15:37:01 -0600 To: Ira McDonald , j.schoenwaelder@iu-bremen.de, Sharon Chisholm , Phil Shafer X-Mailer: Apple Mail (2.730) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit How about the following? A NETCONF SOAP service could be offered on any desired port, but a new standard port for NETCONF over SOAP (over HTTP) will be defined, as requested in the IANA considerations of this document. For reliability and security reasons, NETCONF SHOULD NOT be offered on port 80, and instead SHOULD use the IANA defined port. (This also removes the comment about possibly defining a standard port for SOAP over HTTP in general -- an interesting discussion on its own, but not essential for NETCONF.) Thanks, Ted. On 11-Jul-05, at 2:57 PM, McDonald, Ira wrote: > Hi Phil, > > The draft certainly doesn't track that 'concensus'. The draft > should explicitly say SHOULD NOT use port 80 for NetConf for > reliability and security reasons. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > >> -----Original Message----- >> From: Phil Shafer [mailto:phil@juniper.net] >> Sent: Monday, July 11, 2005 4:59 PM >> To: McDonald, Ira >> Cc: 'j.schoenwaelder@iu-bremen.de'; Ted Goddard; 'Sharon Chisholm'; >> netconf >> Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt >> >> >> "McDonald, Ira" writes: >> >>> If you use a dedicated port, then much simpler protection can be >>> performed. >>> >> >> I think this issue is an old one. We had concensus on >> not using port 80 and on requesting an official port. >> If the draft doesn't track this, it needs an update. >> >> Thanks, >> Phil >> >> > > -- > 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 Jul 11 18:01:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6L9-0004R9-9u for netconf-archive@megatron.ietf.org; Mon, 11 Jul 2005 18:01:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21368 for ; Mon, 11 Jul 2005 18:01:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds6Eb-00084C-69 for netconf-data@psg.com; Mon, 11 Jul 2005 21:54:41 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Ds6EZ-00083u-FC for netconf@ops.ietf.org; Mon, 11 Jul 2005 21:54:39 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j6BLsF917654; Mon, 11 Jul 2005 14:54:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j6BLs9j27825; Mon, 11 Jul 2005 14:54:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id j6BLxbYE077929; Mon, 11 Jul 2005 17:59:37 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200507112159.j6BLxbYE077929@idle.juniper.net> To: Ted Goddard cc: Ira McDonald , j.schoenwaelder@iu-bremen.de, Sharon Chisholm , netconf Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt In-Reply-To: Your message of "Mon, 11 Jul 2005 15:37:01 MDT." Date: Mon, 11 Jul 2005 17:59:37 -0400 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Simplify? A NETCONF SOAP service SHOULD be offered over a new standard port for NETCONF over SOAP (over HTTP) that will be defined as requested in the IANA considerations of this document. Maybe add something in the security section about the evils of using port 80? Thanks, Phil Ted Goddard writes: > >How about the following? > > A NETCONF SOAP service could be offered on any desired port, but a > new standard port for NETCONF over SOAP (over HTTP) will be defined, > as requested in the IANA considerations of this document. > For reliability and security reasons, NETCONF SHOULD NOT be > offered on port 80, and instead SHOULD use the IANA defined port. > >(This also removes the comment about possibly defining a standard >port for SOAP over HTTP in general -- an interesting discussion on its >own, but not essential for NETCONF.) > >Thanks, >Ted. > > >On 11-Jul-05, at 2:57 PM, McDonald, Ira wrote: > >> Hi Phil, >> >> The draft certainly doesn't track that 'concensus'. The draft >> should explicitly say SHOULD NOT use port 80 for NetConf for >> reliability and security reasons. >> >> Cheers, >> - Ira >> >> Ira McDonald (Musician / Software Architect) >> Blue Roof Music / High North Inc >> PO Box 221 Grand Marais, MI 49839 >> phone: +1-906-494-2434 >> email: imcdonald@sharplabs.com >> >> >>> -----Original Message----- >>> From: Phil Shafer [mailto:phil@juniper.net] >>> Sent: Monday, July 11, 2005 4:59 PM >>> To: McDonald, Ira >>> Cc: 'j.schoenwaelder@iu-bremen.de'; Ted Goddard; 'Sharon Chisholm'; >>> netconf >>> Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt >>> >>> >>> "McDonald, Ira" writes: >>> >>>> If you use a dedicated port, then much simpler protection can be >>>> performed. >>>> >>> >>> I think this issue is an old one. We had concensus on >>> not using port 80 and on requesting an official port. >>> If the draft doesn't track this, it needs an update. >>> >>> Thanks, >>> Phil >>> >>> >> >> -- >> 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 Jul 12 04:34:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGDL-0000Z4-64 for netconf-archive@megatron.ietf.org; Tue, 12 Jul 2005 04:34:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01111 for ; Tue, 12 Jul 2005 04:34:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsG4A-0001E0-F5 for netconf-data@psg.com; Tue, 12 Jul 2005 08:24:34 +0000 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DsG49-0001Dj-MI for netconf@ops.ietf.org; Tue, 12 Jul 2005 08:24:33 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E26D15179C for ; Tue, 12 Jul 2005 10:24:32 +0200 (CEST) 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 47A5951701 for ; Tue, 12 Jul 2005 10:24:32 +0200 (CEST) Message-ID: <42D37E04.9000506@loria.fr> Date: Tue, 12 Jul 2005 10:23:32 +0200 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Full support of a capability Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, A few questions on the Netconf draft: If an agent advertises the #writable-running capability, does it mean that the full data model has to support it ? Differently: if a part of the agent data model doesn't support #writable-running capability, is the agent allowed to advertise this capability ? Or can this be managed with "operation-not-supported" or "operation-failed" error when needed ? Vincent Crdlig -- 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 Jul 12 12:17:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNRr-0006Jc-Cl for netconf-archive@megatron.ietf.org; Tue, 12 Jul 2005 12:17:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12947 for ; Tue, 12 Jul 2005 12:17:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsNG0-000DiH-Qn for netconf-data@psg.com; Tue, 12 Jul 2005 16:05:16 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DsNFw-000DhY-SO for netconf@ops.ietf.org; Tue, 12 Jul 2005 16:05:13 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j6CG4LwL001079; Tue, 12 Jul 2005 09:04:21 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 12 Jul 2005 09:05:09 -0700 Message-ID: From: "McDonald, Ira" To: "'Phil Shafer'" , Ted Goddard Cc: "McDonald, Ira" , j.schoenwaelder@iu-bremen.de, Sharon Chisholm , netconf Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt Date: Tue, 12 Jul 2005 09:05:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Phil, Your short, positive statement below is better standards language. And I agree that something belongs in the security section about the evils of using port 80, with a reference to BCP 56 / RFC 3205. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Monday, July 11, 2005 6:00 PM > To: Ted Goddard > Cc: Ira McDonald; j.schoenwaelder@iu-bremen.de; Sharon > Chisholm; netconf > Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt > > > Simplify? > > A NETCONF SOAP service SHOULD be offered over a new standard > port for NETCONF over SOAP (over HTTP) that will be defined > as requested in the IANA considerations of this document. > > Maybe add something in the security section about the evils > of using port 80? > > Thanks, > Phil > > > > Ted Goddard writes: > > > >How about the following? > > > > A NETCONF SOAP service could be offered on any desired > port, but a > > new standard port for NETCONF over SOAP (over HTTP) will > be defined, > > as requested in the IANA considerations of this document. > > For reliability and security reasons, NETCONF SHOULD NOT be > > offered on port 80, and instead SHOULD use the IANA defined port. > > > >(This also removes the comment about possibly defining a standard > >port for SOAP over HTTP in general -- an interesting > discussion on its > >own, but not essential for NETCONF.) > > > >Thanks, > >Ted. > > > > > >On 11-Jul-05, at 2:57 PM, McDonald, Ira wrote: > > > >> Hi Phil, > >> > >> The draft certainly doesn't track that 'concensus'. The draft > >> should explicitly say SHOULD NOT use port 80 for NetConf for > >> reliability and security reasons. > >> > >> Cheers, > >> - Ira > >> > >> Ira McDonald (Musician / Software Architect) > >> Blue Roof Music / High North Inc > >> PO Box 221 Grand Marais, MI 49839 > >> phone: +1-906-494-2434 > >> email: imcdonald@sharplabs.com > >> > >> > >>> -----Original Message----- > >>> From: Phil Shafer [mailto:phil@juniper.net] > >>> Sent: Monday, July 11, 2005 4:59 PM > >>> To: McDonald, Ira > >>> Cc: 'j.schoenwaelder@iu-bremen.de'; Ted Goddard; 'Sharon > Chisholm'; > >>> netconf > >>> Subject: Re: I-D Publication Request: > draft-ietf-netconf-soap-05.txt > >>> > >>> > >>> "McDonald, Ira" writes: > >>> > >>>> If you use a dedicated port, then much simpler protection can be > >>>> performed. > >>>> > >>> > >>> I think this issue is an old one. We had concensus on > >>> not using port 80 and on requesting an official port. > >>> If the draft doesn't track this, it needs an update. > >>> > >>> Thanks, > >>> Phil > >>> > >>> > >> > >> -- > >> 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 Jul 12 22:08:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWfb-0002rg-9b for netconf-archive@megatron.ietf.org; Tue, 12 Jul 2005 22:08:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16902 for ; Tue, 12 Jul 2005 22:08:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsWUn-000Eys-LX for netconf-data@psg.com; Wed, 13 Jul 2005 01:57:09 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DsWUm-000EyS-Ij for netconf@ops.ietf.org; Wed, 13 Jul 2005 01:57:08 +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 j6D1tiQ29976 for ; Tue, 12 Jul 2005 21:55:44 -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_01C5874E.2A39A80B" Subject: FW: I-D ACTION:draft-chisholm-netconf-event-00.txt Date: Tue, 12 Jul 2005 21:57:00 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4041AA55D@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-chisholm-netconf-event-00.txt thread-index: AcWHKUXinWLCfyEkRHCg8pEumaR7nwAIi3Mw From: "Sharon Chisholm" To: "netconf" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5874E.2A39A80B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi Here's the actual draft. This is a proposed solution to the need to do asynchronous messaging in netconf. Andy suggested it would be good to understand what the requirements in this space are. Here are some big bullet items 1. MUST support different types of events=20 1.1 Large and Small messages 1.2 Different types of information 2. Client (manager) MUST be able to specify which events are of interest 3. Client (manager) MUST be able to stop receiving events 4. Client (manger) MUST be able to process events as they come in 5. Server (network element) should not be blocked after sending out an event 6. Events MUST work well for SSH 7. Events MUST work for Beep and SOAP 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: Tuesday, July 12, 2005 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-chisholm-netconf-event-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Netconf Event Messages Author(s) : S. Chisholm, K. Curran Filename : draft-chisholm-netconf-event-00.txt Pages : 26 Date : 2005-7-12 =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-00.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-00.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-00.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_01C5874E.2A39A80B Content-Type: application/octet-stream; name="ATT147151.TXT" Content-Description: ATT147151.TXT Content-Disposition: attachment; filename="ATT147151.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS03LTEyMTQ1NzQ2LkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoaXNob2xtLW5ldGNvbmYt ZXZlbnQtMDAudHh0DQo= ------_=_NextPart_001_01C5874E.2A39A80B Content-Type: application/octet-stream; name="draft-chisholm-netconf-event-00.URL" Content-Description: draft-chisholm-netconf-event-00.URL Content-Disposition: attachment; filename="draft-chisholm-netconf-event-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1jaGlzaG9sbS1uZXRjb25mLWV2ZW50LTAwLnR4dA0K ------_=_NextPart_001_01C5874E.2A39A80B Content-Type: text/plain; name="ATT147152.txt" Content-Description: ATT147152.txt Content-Disposition: attachment; filename="ATT147152.txt" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C5874E.2A39A80B-- -- 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 Jul 13 02:40:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsaup-0000Lt-RD for netconf-archive@megatron.ietf.org; Wed, 13 Jul 2005 02:40:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06734 for ; Wed, 13 Jul 2005 02:40:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dsam0-0009Lq-B4 for netconf-data@psg.com; Wed, 13 Jul 2005 06:31:12 +0000 Received: from [85.73.140.46] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dsalx-0009LP-6d for netconf@ops.ietf.org; Wed, 13 Jul 2005 06:31:09 +0000 Received: by boskop.local (Postfix, from userid 501) id 23AA1383BE6; Wed, 13 Jul 2005 08:31:06 +0200 (CEST) Date: Wed, 13 Jul 2005 08:31:06 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf Subject: Re: FW: I-D ACTION:draft-chisholm-netconf-event-00.txt Message-ID: <20050713063106.GB13364@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf References: <713043CE8B8E1348AF3C546DBE02C1B4041AA55D@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4041AA55D@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jul 12, 2005 at 09:57:00PM -0400, Sharon Chisholm wrote: > Here's the actual draft. This is a proposed solution to the need to do > asynchronous messaging in netconf. Andy suggested it would be good to > understand what the requirements in this space are. > > Here are some big bullet items > > 1. MUST support different types of events > 1.1 Large and Small messages > 1.2 Different types of information > 2. Client (manager) MUST be able to specify which events are of interest > 3. Client (manager) MUST be able to stop receiving events > 4. Client (manger) MUST be able to process events as they come in Not sure what this really means. > 5. Server (network element) should not be blocked after sending out an > event I guess I know what you mean but the bullet point itself does not really convey whay I guess you wanted to say. > 6. Events MUST work well for SSH > 7. Events MUST work for Beep and SOAP You probably mean SOAP/HTTP. The difference between "MUST work" and "MUST work well" also remains somewhat unclear. [And looking at the ID, I am not really clear how the SOAP/HTTP transport mapping (I continue to dislike the term "application protocol" in the NETCONF documents) is supposed to works - or my understanding of HTTP 1.1 chunked transfers is wrong. But now I am discussing the ID and not the bullet points so this remark is off topic for this thread.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 13 03:02:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbGL-0001xP-1L for netconf-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:02:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08091 for ; Wed, 13 Jul 2005 03:02:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dsb7P-000BNT-AX for netconf-data@psg.com; Wed, 13 Jul 2005 06:53:19 +0000 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dsb7O-000BMp-3y for netconf@ops.ietf.org; Wed, 13 Jul 2005 06:53:18 +0000 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 13 Jul 2005 12:35:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,285,1115017200"; d="scan'208"; a="44188665:sNHT24220212" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6D6pKbl013219; Wed, 13 Jul 2005 06:53:06 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Jul 2005 14:52:56 +0800 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: I-D ACTION:draft-chisholm-netconf-event-00.txt Date: Wed, 13 Jul 2005 14:52:56 +0800 Message-ID: Thread-Topic: I-D ACTION:draft-chisholm-netconf-event-00.txt Thread-Index: AcWHKUXinWLCfyEkRHCg8pEumaR7nwAIi3MwAApj1mA= From: "James Balestriere \(jbalestr\)" To: "Sharon Chisholm" , "netconf" X-OriginalArrivalTime: 13 Jul 2005 06:52:56.0840 (UTC) FILETIME=[80020080:01C58777] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Sharon , One question I had with BEEP was whether we should take advantage of the multiple BEEP channels and have the events sent on a different channel to the one doing the configuration. Other things which might be interesting are whether we wish to hold onto events for a while, by defining some thresholds values, and then send one superEvent which contains a list of events. Thresholds could be things like, time, number of events, bytes accumulated ... In the unfortunate situation where the Netconf session suffers from an outage and events cannot be delivered, do we need a queuing mechanism so when the remote side reattaches these events can be delivered ? Not all notifications=20 are of equal importance but some, like configuration change events, are critical. I can envisage a scenario where a hacker deliberately disrupts my netconf session and while I am disconnected compromises the router and reconfigures it. Then when my Netconf session reattaches I am none the wiser that some funny business went on. James. > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Wednesday, 13 July 2005 11:57 AM > To: netconf > Subject: FW: I-D ACTION:draft-chisholm-netconf-event-00.txt=20 >=20 > hi >=20 > Here's the actual draft. This is a proposed solution to the need to do > asynchronous messaging in netconf. Andy suggested it would be good to > understand what the requirements in this space are. >=20 > Here are some big bullet items >=20 > 1. MUST support different types of events=20 > 1.1 Large and Small messages > 1.2 Different types of information > 2. Client (manager) MUST be able to specify which events are=20 > of interest > 3. Client (manager) MUST be able to stop receiving events > 4. Client (manger) MUST be able to process events as they come in > 5. Server (network element) should not be blocked after sending out an > event > 6. Events MUST work well for SSH > 7. Events MUST work for Beep and SOAP >=20 > 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: Tuesday, July 12, 2005 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-chisholm-netconf-event-00.txt=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Netconf Event Messages > Author(s) : S. Chisholm, K. Curran > Filename : draft-chisholm-netconf-event-00.txt > Pages : 26 > Date : 2005-7-12 > =09 > This memo defines a framework for sending asynchronous messages, or > event messages in Netconf. It defines both the operations=20 > necessary > to support this concept, and also discusses implications for the > mapping to application protocols. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-eve nt-00.txt >=20 > 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=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > 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-00.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-chisholm-netconf-event-00.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. >=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 Jul 13 03:14:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbRZ-00062T-4u for netconf-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:14:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08880 for ; Wed, 13 Jul 2005 03:14:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsbM4-000D4O-PP for netconf-data@psg.com; Wed, 13 Jul 2005 07:08:28 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DsbM3-000D47-OH for netconf@ops.ietf.org; Wed, 13 Jul 2005 07:08:27 +0000 Received: (qmail 630 invoked by uid 78); 13 Jul 2005 05:38:14 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail4.netsol.inquent.com with SMTP; 13 Jul 2005 05:38:14 -0000 Message-ID: <42D4A843.1010900@andybierman.com> Date: Tue, 12 Jul 2005 22:36:03 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf Subject: Re: FW: I-D ACTION:draft-chisholm-netconf-event-00.txt References: <713043CE8B8E1348AF3C546DBE02C1B4041AA55D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4041AA55D@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: >hi > >Here's the actual draft. This is a proposed solution to the need to do >asynchronous messaging in netconf. Andy suggested it would be good to >understand what the requirements in this space are. > > Thanks Sharon. I urge everybody in the WG to read this draft and send their questions and comments to the WG mailing list. But first let's agree on the requirements bullet list (see below). >Here are some big bullet items > >1. MUST support different types of events > 1.1 Large and Small messages > > Why is this a different type of event? > 1.2 Different types of information > > Do you mean that there is a global event type field or something more here? >2. Client (manager) MUST be able to specify which events are of interest >3. Client (manager) MUST be able to stop receiving events >4. Client (manger) MUST be able to process events as they come in > > This is an implementation detail. NETCONF will only say events are delivered in the order they are sent. They may be queued by the sender or the receiver. >5. Server (network element) should not be blocked after sending out an >event > > See comment (4) >6. Events MUST work well for SSH >7. Events MUST work for Beep and SOAP > > I think 6 & 7 can be combined to "Events MUST work well for all standard application mappings:" Great list. I want the WG to agree on this list so it can go in the charter update. Does anybody else want to add high-level requirements to this list? (Not low-level, like all the different ways a manager might want to specify which events of are interest -- save that for later.) >Sharon > > thanks, Andy >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: Tuesday, July 12, 2005 3:50 PM >To: i-d-announce@ietf.org >Subject: I-D ACTION:draft-chisholm-netconf-event-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Netconf Event Messages > Author(s) : S. Chisholm, K. Curran > Filename : draft-chisholm-netconf-event-00.txt > Pages : 26 > Date : 2005-7-12 > > 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-00.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-chisholm-netconf-event-00.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-chisholm-netconf-event-00.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. > > >------------------------------------------------------------------------ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce > > -- 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 Jul 13 03:18:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbVS-0001QN-NX for netconf-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:18:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09451 for ; Wed, 13 Jul 2005 03:18:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsbRG-000DZl-5h for netconf-data@psg.com; Wed, 13 Jul 2005 07:13:50 +0000 Received: from [207.69.195.64] (helo=pop-knobcone.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DsbRE-000DZS-2a for netconf@ops.ietf.org; Wed, 13 Jul 2005 07:13:48 +0000 Received: from h-68-166-189-211.snvacaid.dynamic.covad.net ([68.166.189.211] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DsbRD-00037k-00 for netconf@ops.ietf.org; Wed, 13 Jul 2005 03:13:47 -0400 Message-ID: <009401c5877b$055c7640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "netconf" References: Subject: Re: I-D ACTION:draft-chisholm-netconf-event-00.txt Date: Wed, 13 Jul 2005 00:18:08 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "James Balestriere (jbalestr)" > To: "Sharon Chisholm" ; "netconf" > Sent: Tuesday, July 12, 2005 11:52 PM > Subject: RE: I-D ACTION:draft-chisholm-netconf-event-00.txt ... > In the unfortunate situation where the Netconf session suffers from an outage > and events cannot be delivered, do we need a queuing mechanism so when the > remote side reattaches these events can be delivered ? Not all notifications > are of equal importance but some, like configuration change events, are critical. ... The CMIP world developed some rather cool stuff to handle situations like these. The "disseminator" can be thought of as the result of crossing a log with an event forwarding discriminator, holding onto event records until they've been successfully delivered. Unfortunately, since it was developed after logs and EFDs, the inheritance and attributes weren't as aesthetically pleasing as they'd be if it had been in the architecture from the start. So, my $0.02 is that thinking up front about events, event queues, logs, notification subscription and delivery is well worthwhile. Randy -- 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 Jul 13 03:44:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbuR-0004q8-CI for netconf-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:44:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11744 for ; Wed, 13 Jul 2005 03:43:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dsbmg-000FYX-Ed for netconf-data@psg.com; Wed, 13 Jul 2005 07:35:58 +0000 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dsbmf-000FYK-BP for netconf@ops.ietf.org; Wed, 13 Jul 2005 07:35:57 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6556651AB0; Wed, 13 Jul 2005 09:35:56 +0200 (CEST) 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 B1A8651989; Wed, 13 Jul 2005 09:35:55 +0200 (CEST) Message-ID: <42D4C41C.6030604@loria.fr> Date: Wed, 13 Jul 2005 09:34:52 +0200 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman , netconf@ops.ietf.org Subject: Re: Full support of a capability References: <42D37E04.9000506@loria.fr> <42D3DCD8.60305@andybierman.com> In-Reply-To: <42D3DCD8.60305@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The #write-running capability was just an example for my question. If a data model is made of multiple parts, say datamodel1, datamodel2, datamodel3: [...] [...] [...] and if an agent advertises a capability c1, my question was: Does it mean that all parts (datamodel1, datamodel2, datamodel3) of the data model have to support this capability ? If yes, it means that all parts have to support exactly the same set of capabilities. If a vendor integrates a proprietary data model (like a MIB) in an existing Netconf agent and comes with its own proprietary capability, do all other sub data models have to implement this capability so that it can be advertised ? I hope it is more understandable. Thanks, Vincent Andy Bierman wrote: > Vincent Cridlig wrote: > >> Hi, >> >> A few questions on the Netconf draft: >> >> If an agent advertises the #writable-running capability, does it mean >> that the full data model has to support it ? >> Differently: if a part of the agent data model doesn't support >> #writable-running capability, is the agent allowed to advertise this >> capability ? > > > > The capability is for the whole device and is independent of the data > model > being modified. > >> >> Or can this be managed with "operation-not-supported" or >> "operation-failed" error when needed ? > > > > You mean the error-tag for the from to > (i.e., explicit NV-save for #writable-running) or some other operation? > > Let me see if I understand the details here... > > Depending on the data model content that is altered (or simply > installed?) > during a particular NETCONF session, the agent sometimes updates > the non-volatile storage as soon as the config is altered, > and sometimes it waits for an explicit operation to > update the config. What a mess. How is an application > supposed to know when it needs to use or not? > Also, only exists if #writable-running is true, and it is > supposed to be a conceptual mirror or , not a subset. > > Perhaps you mean that you have some data models that do not > get saved in NV-storage at all. In NETCONF terms, this is > state data, not config data. > > > >> >> Vincent Crdlig > > > > 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 Wed Jul 13 03:44:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbvH-0005Fb-7w for netconf-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:44:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11823 for ; Wed, 13 Jul 2005 03:44:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsbqK-000Frc-64 for netconf-data@psg.com; Wed, 13 Jul 2005 07:39:44 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DsbqJ-000FrK-EY for netconf@ops.ietf.org; Wed, 13 Jul 2005 07:39:43 +0000 Received: (qmail 24827 invoked by uid 78); 13 Jul 2005 07:39:42 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail6.netsol.inquent.com with SMTP; 13 Jul 2005 07:39:42 -0000 Message-ID: <42D4C4BB.2040503@andybierman.com> Date: Wed, 13 Jul 2005 00:37:31 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Cridlig CC: netconf@ops.ietf.org Subject: Re: Full support of a capability References: <42D37E04.9000506@loria.fr> <42D3DCD8.60305@andybierman.com> <42D4C41C.6030604@loria.fr> In-Reply-To: <42D4C41C.6030604@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Vincent Cridlig wrote: > The #write-running capability was just an example for my question. > If a data model is made of multiple parts, say datamodel1, datamodel2, > datamodel3: > > [...] > [...] > [...] > > > and if an agent advertises a capability c1, my question was: > Does it mean that all parts (datamodel1, datamodel2, datamodel3) of > the data model have to support this capability ? > If yes, it means that all parts have to support exactly the same set > of capabilities. I suppose it would depend on how the capability is defined. The ones in the NETCONF document are global and apply to the entire device. > > If a vendor integrates a proprietary data model (like a MIB) in an > existing Netconf agent and comes with its own proprietary capability, > do all other sub data models have to implement this capability so that > it can be advertised ? > > I hope it is more understandable. > > Thanks, > Vincent Andy > > > Andy Bierman wrote: > >> Vincent Cridlig wrote: >> >>> Hi, >>> >>> A few questions on the Netconf draft: >>> >>> If an agent advertises the #writable-running capability, does it >>> mean that the full data model has to support it ? >>> Differently: if a part of the agent data model doesn't support >>> #writable-running capability, is the agent allowed to advertise this >>> capability ? >> >> >> >> >> The capability is for the whole device and is independent of the data >> model >> being modified. >> >>> >>> Or can this be managed with "operation-not-supported" or >>> "operation-failed" error when needed ? >> >> >> >> >> You mean the error-tag for the from to >> (i.e., explicit NV-save for #writable-running) or some other operation? >> >> Let me see if I understand the details here... >> >> Depending on the data model content that is altered (or simply >> installed?) >> during a particular NETCONF session, the agent sometimes updates >> the non-volatile storage as soon as the config is altered, >> and sometimes it waits for an explicit operation to >> update the config. What a mess. How is an application >> supposed to know when it needs to use or not? >> Also, only exists if #writable-running is true, and it is >> supposed to be a conceptual mirror or , not a subset. >> >> Perhaps you mean that you have some data models that do not >> get saved in NV-storage at all. In NETCONF terms, this is >> state data, not config data. >> >> >> >>> >>> Vincent Crdlig >> >> >> >> >> 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 Wed Jul 13 03:48:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsbyk-0007bm-9m for netconf-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:48:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12169 for ; Wed, 13 Jul 2005 03:48:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dsbtk-000GCB-9t for netconf-data@psg.com; Wed, 13 Jul 2005 07:43:16 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dsbti-000GBv-Ep for netconf@ops.ietf.org; Wed, 13 Jul 2005 07:43:14 +0000 Received: (qmail 25926 invoked by uid 78); 12 Jul 2005 15:10:11 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 12 Jul 2005 15:10:11 -0000 Message-ID: <42D3DCD8.60305@andybierman.com> Date: Tue, 12 Jul 2005 08:08:08 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Cridlig CC: netconf@ops.ietf.org Subject: Re: Full support of a capability References: <42D37E04.9000506@loria.fr> In-Reply-To: <42D37E04.9000506@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Vincent Cridlig wrote: > Hi, > > A few questions on the Netconf draft: > > If an agent advertises the #writable-running capability, does it mean > that the full data model has to support it ? > Differently: if a part of the agent data model doesn't support > #writable-running capability, is the agent allowed to advertise this > capability ? The capability is for the whole device and is independent of the data model being modified. > > Or can this be managed with "operation-not-supported" or > "operation-failed" error when needed ? You mean the error-tag for the from to (i.e., explicit NV-save for #writable-running) or some other operation? Let me see if I understand the details here... Depending on the data model content that is altered (or simply installed?) during a particular NETCONF session, the agent sometimes updates the non-volatile storage as soon as the config is altered, and sometimes it waits for an explicit operation to update the config. What a mess. How is an application supposed to know when it needs to use or not? Also, only exists if #writable-running is true, and it is supposed to be a conceptual mirror or , not a subset. Perhaps you mean that you have some data models that do not get saved in NV-storage at all. In NETCONF terms, this is state data, not config data. > > Vincent Crdlig 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 Jul 14 10:10:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4QP-0004vi-6v for netconf-archive@megatron.ietf.org; Thu, 14 Jul 2005 10:10:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11540 for ; Thu, 14 Jul 2005 10:10:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt4GT-000KLe-0G for netconf-data@psg.com; Thu, 14 Jul 2005 14:00:37 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dt4GO-000KKJ-Mz for netconf@ops.ietf.org; Thu, 14 Jul 2005 14:00:32 +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 j6EDx7L20349 for ; Thu, 14 Jul 2005 09:59: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: Access Control (was charter discussion) Date: Thu, 14 Jul 2005 10:00:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4041AB030@zcarhxm2.corp.nortel.com> Thread-Topic: Access Control (was charter discussion) thread-index: AcWGImMwGhGiJqwqRZWKONbboUbQXwCV/EkQ From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi While we cannot solve the entire space of access control across all perceivable protocols, if we are clever we might just not make the problem worse.=20 We started to look at this in Netmod, but did not get too far. I am quite glad to see it treated as a separate topic. People may wish to take a look at section 2.3 of that specification (http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-03.txt ).=20 What I think is the most promising is the first of the four classes of access control discussed. This is based on a resource category. This category would be solution (netconf, snmp, syslog, cli, etc) agnostic. If we support this sort of coarse grain access control, perhaps not exclusively, then this provides a hook for an achievable method of defining cross-solution access control. We would not necessarily need to define the 'miracle', but we would be enabling it.=20 Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Monday, July 11, 2005 10:11 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf@ops.ietf.org Subject: Re: Proposed Update to Netconf Charter On Mon, Jul 11, 2005 at 09:26:46AM -0400, Sharon Chisholm wrote: > hi >=20 > More or less. That and we should ensure that everything plays nice=20 > with a common security infrastructure, rather than each other >=20 > ___________ > SNMP -------- / \ > / \ > CLI -------/ \ > | Miracle \ > Netconf -------\ | > | / > Syslog -------- \ \ > -------------- >=20 > As appose to >=20 > SNMP <--miracle --> Netconf > CLI <--miracle --> Netconf > Syslog <--miracle --> Netconf > SNMP <--miracle--> CLI > SNMP <--miracle--> Syslog > CLI <--miracle--> Syslog We have VACM for SNMP and eventually we might have NACM for NETCONF. There is no agreed access control mechanism for CLIs and syslog and I think it is therefore out of scope to worry about this in the NETCONF WG. I also believe that VACM is rather SNMP specific since it relies on OID naming which luckily does not exist in NETCONF. So these two do not align well and even if you were to try, you would have to solve the SNMP naming to NETCONF naming coexistance/mapping problem as part of the solution. So I still believe NETCONF needs a good enough ACM for NETCONF, no more no less. This WG can't solve all the access control problems out there. Perhaps the only common denominator is the set of protocol specific operations an authenticated identity is allowed to perform if you consider integration. Everything above that which needs to be specific to the data model and representation will be rather difficult (and perhaps not even needed for a non-trivial class of operational environments). /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 14 10:36:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4pY-0000WL-7c for netconf-archive@megatron.ietf.org; Thu, 14 Jul 2005 10:36:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14140 for ; Thu, 14 Jul 2005 10:36:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt4jQ-000NkW-Hk for netconf-data@psg.com; Thu, 14 Jul 2005 14:30:32 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dt4jN-000Njz-QG for netconf@ops.ietf.org; Thu, 14 Jul 2005 14:30:30 +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 j6EET5L07332 for ; Thu, 14 Jul 2005 10:29:05 -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: Latest Proposed Phase 2 Charter Updates Date: Thu, 14 Jul 2005 10:30:22 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40420BEA3@zcarhxm2.corp.nortel.com> Thread-Topic: Latest Proposed Phase 2 Charter Updates thread-index: AcWIgJE+LnyHDIEqRi2pmWTdm0OCbQ== From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I thought it might be helpful to make the latest version of the proposed charter updates available on a website we could refer to and update as we fine tune the text. http://standards.nortelnetworks.com/netconf/docs/proposed_phase2.html I likely didn't reword the access control one properly to reflect discussion. 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 Thu Jul 14 11:20:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5WB-0004Xz-FC for netconf-archive@megatron.ietf.org; Thu, 14 Jul 2005 11:20:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21358 for ; Thu, 14 Jul 2005 11:20:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt5O2-0002lq-1z for netconf-data@psg.com; Thu, 14 Jul 2005 15:12:30 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dt5O0-0002lT-PH for netconf@ops.ietf.org; Thu, 14 Jul 2005 15:12:29 +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 j6EFCOF11339 for ; Thu, 14 Jul 2005 11:12:24 -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: I-D ACTION:draft-chisholm-netconf-event-00.txt Date: Thu, 14 Jul 2005 11:11:59 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40420BF42@zcarhxm2.corp.nortel.com> Thread-Topic: I-D ACTION:draft-chisholm-netconf-event-00.txt thread-index: AcWHKUXinWLCfyEkRHCg8pEumaR7nwAIi3MwAApj1mAAQ40G0A== From: "Sharon Chisholm" To: "netconf" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi 1. Beep Channels This certainly came up when we were designing this solution. We found it confused the discussion quite a bit. The layers really start to blur. (We developed what I refer to as the 'egg yoke' diagram to try to keep it straight in our heads, but hopefully I can spare you guys from that figure ;-)). For the sake of simplicity, we decided to decouple the event message discussion from the discussion of multiple channels.=20 There could be a case to take another look at the native concept of the notification channel in beep, but I think we should be careful to keep that discussion to just the application mapping bit of the discussion.=20 2. Additional Event Related Operations Interesting. I think I had been thinking this would go into the data model. A get on an event log and filtering on timestamp for example. A generic resynchronization method might have some uses.=20 - I think it would be event-class agnostic. For example it would resend recent events, but not all active alarms. - It would have to be time based or sequence number based.=20 - It would have to be careful designed so it would be achievable on the network element. I will add this to the requirements list to ensure it is capture. 3. Thresholding I think you are describing the behaviour of the event, not the event message. Sharon -----Original Message----- From: James Balestriere (jbalestr) [mailto:jbalestr@cisco.com]=20 Sent: Wednesday, July 13, 2005 2:53 AM To: Chisholm, Sharon [CAR:5K50:EXCH]; netconf Subject: RE: I-D ACTION:draft-chisholm-netconf-event-00.txt=20 Hi Sharon , One question I had with BEEP was whether we should take advantage of the multiple BEEP channels and have the events sent on a different channel to the one doing the configuration. Other things which might be interesting are whether we wish to hold onto events for a while, by defining some thresholds values, and then send one superEvent which contains a list of events. Thresholds could be things like, time, number of events, bytes accumulated ... In the unfortunate situation where the Netconf session suffers from an outage and events cannot be delivered, do we need a queuing mechanism so when the remote side reattaches these events can be delivered ? Not all notifications=20 are of equal importance but some, like configuration change events, are critical. I can envisage a scenario where a hacker deliberately disrupts my netconf session and while I am disconnected compromises the router and reconfigures it. Then when my Netconf session reattaches I am none the wiser that some funny business went on. James. > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Wednesday, 13 July 2005 11:57 AM > To: netconf > Subject: FW: I-D ACTION:draft-chisholm-netconf-event-00.txt=20 >=20 > hi >=20 > Here's the actual draft. This is a proposed solution to the need to do > asynchronous messaging in netconf. Andy suggested it would be good to=20 > understand what the requirements in this space are. >=20 > Here are some big bullet items >=20 > 1. MUST support different types of events=20 > 1.1 Large and Small messages > 1.2 Different types of information > 2. Client (manager) MUST be able to specify which events are > of interest > 3. Client (manager) MUST be able to stop receiving events > 4. Client (manger) MUST be able to process events as they come in > 5. Server (network element) should not be blocked after sending out an > event > 6. Events MUST work well for SSH > 7. Events MUST work for Beep and SOAP >=20 > Sharon > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Tuesday, July 12, 2005 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-chisholm-netconf-event-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Netconf Event Messages > Author(s) : S. Chisholm, K. Curran > Filename : draft-chisholm-netconf-event-00.txt > Pages : 26 > Date : 2005-7-12 > =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. >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-eve nt-00.txt >=20 > 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. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-chisholm-netconf-event-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-chisholm-netconf-event-00.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=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=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 Thu Jul 14 11:22:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5Xi-00055r-Oi for netconf-archive@megatron.ietf.org; Thu, 14 Jul 2005 11:22:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21587 for ; Thu, 14 Jul 2005 11:22:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt5RS-00039g-Mv for netconf-data@psg.com; Thu, 14 Jul 2005 15:16:02 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dt5RP-00038t-0f for netconf@ops.ietf.org; Thu, 14 Jul 2005 15:15:59 +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 j6EFEaL00698 for ; Thu, 14 Jul 2005 11:14:36 -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: Requirements for Event Messages Date: Thu, 14 Jul 2005 11:15:53 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40420BF58@zcarhxm2.corp.nortel.com> Thread-Topic: Requirements for Event Messages thread-index: AcWIhuz08QoFHUA7Sb64Gr6ULzsxnA== From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I've updated the requirements list with clarifications from people's questions and added an additional requirement. It can be found at =09 http://standards.nortelnetworks.com/netconf/docs/netconfEvent/requiremen ts.html ----------------------------------- Requirements for Netconf Event Messages 1. MUST support different types of events Different sorts of events will have different messages sizes and contain different sorts of information.=20 2. Client (manager) MUST be able to specify which events are of interest 3. Client (manager) MUST be able to stop receiving events 4. Client (manger) MUST be able to process events as they come in The solution should not prevent them from doing this. A solution that sends incomplete XML documents, for example, could be viewed as something that prevents the events being processed as the come in=20 5. Server (network element) should not be blocked after sending out an event The solution must not force the server (network element) to wait until the event has been consumed by all interested parties before it can perform other tasks.=20 6. Events MUST work for SSH 7. Events SHOULD work for Beep and SOAP 8. The Client (manager) SHOULD be able to resynchronize recently sent events.=20 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 Thu Jul 14 17:49:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBZw-0005Xq-CB for netconf-archive@megatron.ietf.org; Thu, 14 Jul 2005 17:49:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05656 for ; Thu, 14 Jul 2005 17:49:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtBRW-000K9V-MP for netconf-data@psg.com; Thu, 14 Jul 2005 21:40:30 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DtBRS-000K8t-Jr for netconf@ops.ietf.org; Thu, 14 Jul 2005 21:40:27 +0000 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j6ELeOV6019522; Thu, 14 Jul 2005 23:40:24 +0200 (CEST) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.56264.777087.269929@diotima.switch.ch> Date: Thu, 14 Jul 2005 23:40:24 +0200 To: netconf@ops.ietf.org Subject: NETCONF will meet at IETF 63 in Paris X-Mailer: VM 7.18 under Emacs 21.3.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We have requested a slot for the NETCONF WG at the upcoming IETF meeting in Paris. It will be a one-hour slot, with the principal purpose of having a face-to-face discussion of the changes to the WG charter. If you have any additional SHORT agenda items, please send them to the chairs (Andy Bierman and myself) and we'll try to accomodate them. But charter discussion is really the main focus of the meeting. For those who won't be able to be there, there will be (unidirectional) unicast MP3 audio streaming as well as a (bidirectional) Jabber messaging service. Regards, -- Simon. -- 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 Jul 14 18:30:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtCDe-0005s9-Tt for netconf-archive@megatron.ietf.org; Thu, 14 Jul 2005 18:30:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14471 for ; Thu, 14 Jul 2005 18:30:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtC7N-000Oru-0c for netconf-data@psg.com; Thu, 14 Jul 2005 22:23:45 +0000 Received: from [85.73.176.214] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DtC7J-000OrC-Qt for netconf@ops.ietf.org; Thu, 14 Jul 2005 22:23:42 +0000 Received: by boskop.local (Postfix, from userid 501) id 3EA073855D1; Fri, 15 Jul 2005 00:23:31 +0200 (CEST) Date: Fri, 15 Jul 2005 00:23:28 +0200 From: Juergen Schoenwaelder To: netconf@ops.ietf.org Subject: comments on data types draft Message-ID: <20050714222328.GA5300@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: netconf@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk I just browsed and I have several comments: - I think more precise descriptions are needed. - There should be some consistent naming convention (e.g. use of uppercase/lowercase characters in type names. - Introducing a data _type_ "MD5" with the explanation "MD5 Message-Digest Algorithm" does not really make sense (unless you can express the algorithm in 32 hex digits ;-). Not sure this is even one of the most important types to worry about. - I am not sure the maxLength of IPAddress is a good thing. In fact, I would have expected that the construction is somewhat aligned in spirit with RFC 4001 and does not ignore zone indexes. - EthernetAddress seems to be a misnomer. RFC 2579 calls this a MAC address which I think is the correct term. (I don't think you want to provide new type definitions for each 802.N technology that happens to use MAC addresses.) - For PORT, take a look at InetPort (RFC 4001). Other RFC 4001 types do not seem to be covered. - I have doubts that AdminStatus and OperStatus are generally applicable. - More general: I think some document should explain which of the XML standard schema types we use for frequently used SNMP data types, especially string types and date and time related types. - We need to figure out how to organize definitions in modules, taking the IETF process requirements into account. (RFC 4001 for example started with a focus on IP addresses but now covers more general IP related definitions - and we cycled that document already three times to add and clarify things. We might have to follow a similar quick recycle period with XML core types as well. - We should have a plan how we deal with special values often used to express some special meaning. In the SNMP world, it has become good design practice to plan ahead for such special values. I am not really talking about place holders (I think there is little need for them in XML land) - I am talking about things like the inclusion of 0 in the InetPortNumber TC which might represent an ANY port in some situations. - We should also think about IANA controlled types that is how to provide definitions (most likely enumerations) that can be updated and maintained by IANA, perhaps in synchronization with corresponding SMIv2 definitions (things like ianaifType). Just some quick thoughts. I do believe it is worthwhile to write up some common XML data types and appreciate that someone kicks this off. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 15 07:56:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOo0-0007R9-Ku for netconf-archive@megatron.ietf.org; Fri, 15 Jul 2005 07:56:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27943 for ; Fri, 15 Jul 2005 07:56:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtOgJ-0001Pz-Uc for netconf-data@psg.com; Fri, 15 Jul 2005 11:48:39 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DtOgG-0001PU-2O for netconf@ops.ietf.org; Fri, 15 Jul 2005 11:48:36 +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 j6FBmV827998 for ; Fri, 15 Jul 2005 07:48:31 -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: comments on data types draft Date: Fri, 15 Jul 2005 07:48:00 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40420C421@zcarhxm2.corp.nortel.com> Thread-Topic: comments on data types draft thread-index: AcWIw/92B/bYMEJ7Ra25yZFrPlGYBQAbqtNw From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I agree that we probably don't want admin/oper status in this list. They don't seem to belong with the rest of things listed plus, as Juergen indicated, they may not be generally applicable. I would prefer something more along the lines of what we did in the Entity State MIB, but I say we just defer state textual conventions for now. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, July 14, 2005 6:23 PM To: netconf@ops.ietf.org Subject: comments on data types draft I just browsed and I have several comments: - I think more precise descriptions are needed.=20 - There should be some consistent naming convention (e.g. use of uppercase/lowercase characters in type names. - Introducing a data _type_ "MD5" with the explanation "MD5 Message-Digest=20 Algorithm" does not really make sense (unless you can express the algorithm in 32 hex digits ;-). Not sure this is even one of the most important types to worry about. - I am not sure the maxLength of IPAddress is a good thing. In fact, I would have expected that the construction is somewhat aligned in spirit with RFC 4001 and does not ignore zone indexes. - EthernetAddress seems to be a misnomer. RFC 2579 calls this a MAC address which I think is the correct term. (I don't think you want to provide new type definitions for each 802.N technology that happens to use MAC addresses.) - For PORT, take a look at InetPort (RFC 4001). Other RFC 4001 types do not seem to be covered. - I have doubts that AdminStatus and OperStatus are generally applicable. - More general: I think some document should explain which of the XML standard schema types we use for frequently used SNMP data=20 types, especially string types and date and time related types. - We need to figure out how to organize definitions in modules, taking the IETF process requirements into account. (RFC 4001 for example started with a focus on IP addresses but now covers more general IP related definitions - and we cycled that document already three times to add and clarify things. We might have to follow a similar quick recycle period with XML core types as well. - We should have a plan how we deal with special values often used to express some special meaning. In the SNMP world, it has become good design practice to plan ahead for such special values. I am not really talking about place holders (I think there is little need for them in XML land) - I am talking about things like the inclusion of 0 in the InetPortNumber TC which might represent an ANY port in some situations. - We should also think about IANA controlled types that is how to provide definitions (most likely enumerations) that can be=20 updated and maintained by IANA, perhaps in synchronization with corresponding SMIv2 definitions (things like ianaifType). Just some quick thoughts.=20 I do believe it is worthwhile to write up some common XML data types=20 and appreciate that someone kicks this off. /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 15 08:34:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPOJ-00062f-UO for netconf-archive@megatron.ietf.org; Fri, 15 Jul 2005 08:34:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01031 for ; Fri, 15 Jul 2005 08:34:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtPJg-0005lJ-H2 for netconf-data@psg.com; Fri, 15 Jul 2005 12:29:20 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DtPJe-0005l4-Js for netconf@ops.ietf.org; Fri, 15 Jul 2005 12:29:18 +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 j6FCRsK06161 for ; Fri, 15 Jul 2005 08:27:54 -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: comments on data types draft Date: Fri, 15 Jul 2005 08:29:14 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40420C452@zcarhxm2.corp.nortel.com> Thread-Topic: comments on data types draft thread-index: AcWIw/92B/bYMEJ7Ra25yZFrPlGYBQAbqtNwAAFoUWA= From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi A couple other points: - I think creating these type definitions is really important and this list seems to be at the correct level of abstraction, as appose to 100 flavours of integers. - In the next update, the XML Schema should be well formed. We are missing the , and other fun constructs in this definition. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon [CAR:5K50:EXCH] Sent: Friday, July 15, 2005 7:48 AM To: netconf@ops.ietf.org Subject: RE: comments on data types draft hi I agree that we probably don't want admin/oper status in this list. They don't seem to belong with the rest of things listed plus, as Juergen indicated, they may not be generally applicable. I would prefer something more along the lines of what we did in the Entity State MIB, but I say we just defer state textual conventions for now. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, July 14, 2005 6:23 PM To: netconf@ops.ietf.org Subject: comments on data types draft I just browsed and I have several comments: - I think more precise descriptions are needed.=20 - There should be some consistent naming convention (e.g. use of uppercase/lowercase characters in type names. - Introducing a data _type_ "MD5" with the explanation "MD5 Message-Digest=20 Algorithm" does not really make sense (unless you can express the algorithm in 32 hex digits ;-). Not sure this is even one of the most important types to worry about. - I am not sure the maxLength of IPAddress is a good thing. In fact, I would have expected that the construction is somewhat aligned in spirit with RFC 4001 and does not ignore zone indexes. - EthernetAddress seems to be a misnomer. RFC 2579 calls this a MAC address which I think is the correct term. (I don't think you want to provide new type definitions for each 802.N technology that happens to use MAC addresses.) - For PORT, take a look at InetPort (RFC 4001). Other RFC 4001 types do not seem to be covered. - I have doubts that AdminStatus and OperStatus are generally applicable. - More general: I think some document should explain which of the XML standard schema types we use for frequently used SNMP data=20 types, especially string types and date and time related types. - We need to figure out how to organize definitions in modules, taking the IETF process requirements into account. (RFC 4001 for example started with a focus on IP addresses but now covers more general IP related definitions - and we cycled that document already three times to add and clarify things. We might have to follow a similar quick recycle period with XML core types as well. - We should have a plan how we deal with special values often used to express some special meaning. In the SNMP world, it has become good design practice to plan ahead for such special values. I am not really talking about place holders (I think there is little need for them in XML land) - I am talking about things like the inclusion of 0 in the InetPortNumber TC which might represent an ANY port in some situations. - We should also think about IANA controlled types that is how to provide definitions (most likely enumerations) that can be=20 updated and maintained by IANA, perhaps in synchronization with corresponding SMIv2 definitions (things like ianaifType). Just some quick thoughts.=20 I do believe it is worthwhile to write up some common XML data types=20 and appreciate that someone kicks this off. /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: -- 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 Jul 15 09:32:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQIn-0005EL-Su for netconf-archive@megatron.ietf.org; Fri, 15 Jul 2005 09:32:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05287 for ; Fri, 15 Jul 2005 09:32:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtQE1-000BJB-Fg for netconf-data@psg.com; Fri, 15 Jul 2005 13:27:33 +0000 Received: from [85.73.147.183] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DtQDz-000BIx-HK for netconf@ops.ietf.org; Fri, 15 Jul 2005 13:27:31 +0000 Received: by boskop.local (Postfix, from userid 501) id 4CD3F386C0A; Fri, 15 Jul 2005 14:41:15 +0200 (CEST) Date: Fri, 15 Jul 2005 14:41:15 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: comments on data types draft Message-ID: <20050715124114.GA7551@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B40420C452@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40420C452@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jul 15, 2005 at 08:29:14AM -0400, Sharon Chisholm wrote: > - I think creating these type definitions is really important and this > list seems to be at the correct level of abstraction, as appose to 100 > flavours of integers. I am not sure I understand. Introducing types for things that essentially are integers such as port numbers, vlan ids, interface numbers, AS numbers, diffserv code points, ... is IMHO useful since these types usually come with specific restrictions that without well defined types tend to be incompatible and the types help to convey semantics to the reader if they are properly named. Perhaps you had something different in mind when you wrote "100 flavours of integers". Perhaps you meant the many different number types already present in the XML schema language. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 15 09:33:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQJw-0005MR-1K for netconf-archive@megatron.ietf.org; Fri, 15 Jul 2005 09:33: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 JAA05373 for ; Fri, 15 Jul 2005 09:33:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtQGg-000Baw-M3 for netconf-data@psg.com; Fri, 15 Jul 2005 13:30:18 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DtQGf-000Bab-U7 for netconf@ops.ietf.org; Fri, 15 Jul 2005 13:30:18 +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 j6FDSrK23753 for ; Fri, 15 Jul 2005 09:28:54 -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: comments on data types draft Date: Fri, 15 Jul 2005 09:30:13 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40420C508@zcarhxm2.corp.nortel.com> Thread-Topic: comments on data types draft thread-index: AcWJQPiH80xHmZE2QG++H9+laem1hwAACAag From: "Sharon Chisholm" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I meant that these have an application flavour as appose to: counter versus gauge versus INTEGER versus Integer versus ... Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Friday, July 15, 2005 8:41 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf@ops.ietf.org Subject: Re: comments on data types draft On Fri, Jul 15, 2005 at 08:29:14AM -0400, Sharon Chisholm wrote: > - I think creating these type definitions is really important and this > list seems to be at the correct level of abstraction, as appose to 100 > flavours of integers. I am not sure I understand. Introducing types for things that essentially are integers such as port=20 numbers, vlan ids, interface numbers, AS numbers, diffserv code points,=20 ... is IMHO useful since these types usually come with specific restrictions=20 that without well defined types tend to be incompatible and the types help to convey semantics to the reader if they are properly named.=20 Perhaps you had something different in mind when you wrote "100 flavours of integers". Perhaps you meant the many different number types already present in the XML schema language. ;-) /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Jul 15 09:58:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQi0-0004Xb-Ja for netconf-archive@megatron.ietf.org; Fri, 15 Jul 2005 09:58:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06876 for ; Fri, 15 Jul 2005 09:58:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtQcL-000Dfn-1f for netconf-data@psg.com; Fri, 15 Jul 2005 13:52:41 +0000 Received: from [85.73.147.183] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DtQcJ-000DfT-9P for netconf@ops.ietf.org; Fri, 15 Jul 2005 13:52:39 +0000 Received: by boskop.local (Postfix, from userid 501) id AB3F2386DCB; Fri, 15 Jul 2005 15:52:37 +0200 (CEST) Date: Fri, 15 Jul 2005 15:52:37 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: comments on data types draft Message-ID: <20050715135237.GA7781@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B40420C508@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40420C508@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jul 15, 2005 at 09:30:13AM -0400, Sharon Chisholm wrote: > I meant that these have an application flavour as appose to: counter > versus gauge versus INTEGER versus Integer versus ... Counter is BTW the most widely used data type, according to my analysis of > 850 MIB modules which I published at the last IM conference. But this probably does not mean much in the context of NetConf. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Sat Jul 16 16:57:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dttid-00069Z-Hc for netconf-archive@megatron.ietf.org; Sat, 16 Jul 2005 16:57:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01235 for ; Sat, 16 Jul 2005 16:57:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DttYL-0002DR-W5 for netconf-data@psg.com; Sat, 16 Jul 2005 20:46:29 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DttYJ-0002DA-Ug for netconf@ops.ietf.org; Sat, 16 Jul 2005 20:46:28 +0000 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j6GKjx7k027600; Sat, 16 Jul 2005 22:45:59 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17113.29190.667315.346475@diotima.switch.ch> X-Mailer: VM 7.18 under Emacs 21.3.1 From: Simon Leinen To: netconf@ops.ietf.org CC: agenda@ietf.org Subject: DRAFT agenda for NETCONF meeting at IETF #63 Date: Sat, 16 Jul 2005 22:45:59 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Network Configuration WG (netconf) IETF #62 August 4, 2005 : 0900 - 1000 =============================== Chairs: Simon Leinen Andy Bierman Agenda: - Administrativia (10 minutes) - Blue sheets, scribe/Jabber scribe, (volunteers are welcome to send a short advance note to the chairs) agenda bashing, status of WG Documents (Reminder: All four documents have been submitted to the IESG for publication.) - Charter Update Discussion (50 minutes) - Discuss specific "phase 2" standardization goals and whether the WG can realistically commit to them. Internet Drafts: no active WG drafts Individual contributions: draft-chisholm-netconf-model-03.txt draft-adwankar-netconf-reporting-00.txt draft-chisholm-netconf-event-00.txt draft-romascanu-netconf-datatypes-00.txt Guidelines for WG charters: BCP 25 (RFC 2419), "IETF Working Group Guidelines and Procedures" -- 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 Jul 21 14:38:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvfvm-0001T1-GN for netconf-archive@megatron.ietf.org; Thu, 21 Jul 2005 14:38:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25528 for ; Thu, 21 Jul 2005 14:38:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dvfnh-0003J9-HE for netconf-data@psg.com; Thu, 21 Jul 2005 18:29:41 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dvfnf-0003Ip-CR for netconf@ops.ietf.org; Thu, 21 Jul 2005 18:29:39 +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 j6LITYO07226 for ; Thu, 21 Jul 2005 14:29:34 -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: Offline Netconf Data Model Discussion In Paris Date: Thu, 21 Jul 2005 14:29:29 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4043166B0@zcarhxm2.corp.nortel.com> Thread-Topic: Offline Netconf Data Model Discussion In Paris thread-index: AcWOIiHlfKKSQ6c+QCStbfSN59SO4A== From: "Sharon Chisholm" To: , "Netconf Data Model Discussion" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I thought the offline editing session we had in Minneapolis earlier this year was really helpful to move forward the Netconf Data Model Framework specification, so I thought I would try that again. The Netconf meeting is scheduled for Thursday, so odds are this discussion would happen first. Looking at the schedule, Monday morning is currently looking good. Please let me know if you are interested. Thanks, 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 Thu Jul 28 11:24:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAF5-0004dK-7m for netconf-archive@megatron.ietf.org; Thu, 28 Jul 2005 11:24:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05296 for ; Thu, 28 Jul 2005 11:24:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DyA6L-0001mf-Sj for netconf-data@psg.com; Thu, 28 Jul 2005 15:15:13 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DyA6I-0001mB-Qm for netconf@ops.ietf.org; Thu, 28 Jul 2005 15:15:11 +0000 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j6SFEisn019121; Thu, 28 Jul 2005 17:14:44 +0200 (CEST) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17128.63076.259863.642313@diotima.switch.ch> Date: Thu, 28 Jul 2005 17:14:44 +0200 To: netconf@ops.ietf.org CC: agenda@ietf.org Subject: Updated agenda for NETCONF meeting at IETF #63 X-Mailer: VM 7.18 under Emacs 21.3.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Network Configuration WG (netconf) IETF #63 August 4, 2005 : 0900 - 1000, room 341 ====================================== Chairs: Simon Leinen Andy Bierman Agenda: - Administrativia (10 minutes) - Blue sheets, scribe/Jabber scribe, (volunteers are welcome to send a short advance note to the chairs) agenda bashing, status of WG Documents (Reminder: All four documents have been submitted to the IESG for publication.) - Charter Update Discussion (50 minutes) - Discuss specific "phase 2" standardization goals and whether the WG can realistically commit to them. Internet Drafts: no active WG drafts Individual contributions: draft-chisholm-netconf-model-03.txt draft-adwankar-netconf-reporting-00.txt draft-chisholm-netconf-event-00.txt draft-romascanu-netconf-datatypes-00.txt draft-atarashi-netconfmodel-architecture-02.txt Guidelines for WG charters: BCP 25 (RFC 2418), "IETF Working Group Guidelines and Procedures" -- 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 Jul 29 15:28:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaWg-0007ui-7H for netconf-archive@megatron.ietf.org; Fri, 29 Jul 2005 15:28:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03117 for ; Fri, 29 Jul 2005 15:28:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DyaOS-0006o9-Lm for netconf-data@psg.com; Fri, 29 Jul 2005 19:19:40 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DyaOQ-0006nJ-Ra for netconf@ops.ietf.org; Fri, 29 Jul 2005 19:19:39 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6TJJUic017523; Fri, 29 Jul 2005 14:19:31 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 29 Jul 2005 21:19:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507A50926@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Margaret Wasserman (E-mail)" , ted.goddard@icesoft.com Cc: "Netconf (E-mail)" Subject: AD review for: draft-ietf-netconf-ssh-04.txt Date: Fri, 29 Jul 2005 21:19:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Here is my complete AD review. As far as I am concerned this is ready for IETF Last Call. But if the authors do want to do a quick rev to address any of these comments, then we can wait. I am waiting for a response for the protocol doc comments too, and based on that response it is possible we may want another rev for that before we do IETF Last Call. In that case, maybe we should also revise this doc. Bert ------------------------------------------ AD review for: draft-ietf-netconf-ssh-04.txt - I believe we discussed that netconf over ssh was going to be mandatory to implement. But I cannot find a statement about that. Neither in this doc, not in the protocol doc. - missing some text about the use of MUST SHOULD and such and a citation and normative reference to RFC2119 nits and typos: - I think that in the abstract, I would do s/NETCONF configuration protocol/NETCONF protocol/ - you are using ]]>]]> before you have explained what it means. Might be better to explain earlier. - FIrst para sect 5. NETCONF is used to access and modify configuration and state information, so the ability to access this protocol should be limited to users and systems that are authorized to view or modify the agent's configuration and state data. I think I would change the sequence of "configuration and state data" to allign with the sequence of the verbs "view or modify". I doubt that state data can be modified (or can it? if so, ignore this comment, I may have missed something then). Checking the references/citations I get: !! Missing citation for Informative reference: P008 L030: [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol !! Missing citation for Informative reference: P008 L036: [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, I believe I also do not see a citation to RFC3668. I further believe that there is no reason to include citations and references to the RFCs 3667/3668 or its successors. w.r.t. IDNITS, I understand the doc was submitted in April, so before the new rfc3978/79 boilerplate was mandatory. idnits finds other issues also (as also reported by WG chair). But for completeness I include it here: $ idnits draft-ietf-netconf-ssh-04.txt idnits 1.74 draft-ietf-netconf-ssh-04.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) * There are 38 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. -- 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 Jul 29 15:28:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaWh-0007uu-DS for netconf-archive@megatron.ietf.org; Fri, 29 Jul 2005 15:28:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03129 for ; Fri, 29 Jul 2005 15:28:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DyaOQ-0006n4-CL for netconf-data@psg.com; Fri, 29 Jul 2005 19:19:38 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DyaOL-0006lR-Qm for netconf@ops.ietf.org; Fri, 29 Jul 2005 19:19:34 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6TJJU3V017525; Fri, 29 Jul 2005 14:19:31 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 29 Jul 2005 21:19:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507A50924@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rob Enns (E-mail)" Cc: "Netconf (E-mail)" Subject: AD review for: draft-ietf-netconf-prot-07.txt Date: Fri, 29 Jul 2005 21:19:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Here is my complete review comments/questions. Looking forward to the comments from the authors (and any other comments people may have). Bert AD review: draft-ietf-netconf-prot-07.txt - I believe we discussed that netconf over ssh was going to be mandatory to implement. But I cannot find a statement about that. Neither in this doc, not in the protocol doc. - on page 15, I think the rpc-reply needs a message-id. do I understand that correctly? - the example in 6.2.2 uses but then the text following that on top of page 19 says: Only nodes in the 'http://example.com/schema/1.2/config' which to me seems in conflict with the example, or am I missing something? - what is the real difference between the examples in sections 6.2.3 and 6.2.4? I think I understand the differences between containment and seclection nodes, but the examples confuse me instead of helping me, because they are exactly the same and even the descritive text directly following each example is exactly the same. --- new questions - I believe that it is probably better to use a 192.0.2.4 address (i.e. in range 192.0.2.0/24 as per RFC 3330) in the sample on page 39 (instead of 1.2.3.4). Part of ID-Checklist - same for the 192.168.0.1 addresses on page 40 and 41. please check whole doc if there are other occurences. - on page 41 at the bottom I read: A device may choose not to support the configuration datastore as the parameter of a operation. and I wonder what you mean there. In sect 8.2, you specify that (I guess) by default there is no write-running support and that such is a capability. Is that what you mean with the "may choose not to". Or do you mean that it is indeed under control of a published capability? If the latter, pls be clearer. If the former, probably need to be clearer too. - page 44 talks about an RPC msg to break a lock. Should you maybe add some text to say what happens to the modifications that have been made by the owner of the lock up to the time of when the lock gets killed/broken? I see in section 7.9 that that any "operations in progress will be aborted", but that does not help me understand what happens if a set of changes were already made in earlier operations during that session. Or am I worry-ing to much? - not sure I understand (1st para sect 8) what "must be able to process and ignore..." means. Maybe you can explain to me, maybe it needs clarfication? - When reading Sect 8.1 I think it states that a client must also send its capabilities. But I am not sure I got that right. Clarification might help. - sect 8.9.5.1 example Am I missing something? I do not understand "top" in that example. Could be me. - sect 10. IANA Considerations. I see just: TBD Well I think there are IANA considerations. Like a description of the registries (namespaces) to be created and to be maintained by IANA. Also rules about how new entries/assignments can be made (see RFC2434). Further I think that this document makes a set of registartions and so they should be listed here for IANA as the initial set of registrations to be administered/recorded. - I do not understand why reference [4] is normative The citation os from a "For example.." sentence, so that does not sound normative to me. - Same question as to why reference [7] has to be normative. - I think I would change "Author's Address" into "Editor's Address" on page 68. Specifically cause I get the impression that Rob is editor and that there are quite a set of contributing authors, which you have listed separately (good). - Has the XML Schema been validated for correct SYNTAX? Can you tell me which tool you used to do so? typos/nits (for whenever you do a new rev) - page 18, 1st para sect 6.2.1 s/elements to selected/elements to be selected/ - page 20, sect 6.2.5 6th bullet s/will interpreted/will be interpreted/ - page 44 1st para I think I would do: s/(SNMP and CLI scripts)/(e.g. SNMP and CLI scripts) - page 53, sect 8.3.1 3rd line s/can manipulated/can be manipulated/ - As a comment I note that was confused a few times (or put on the wrong leg) when I read about a "create operation". In fact that is the operation-attribute of the protocol operation edit-config. Not saying anything needs to be done about it, just that I would not be surprised if novice readers run into the same problem. Bert -- 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 Jul 29 15:29:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaXx-000810-Pz for netconf-archive@megatron.ietf.org; Fri, 29 Jul 2005 15:29:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03178 for ; Fri, 29 Jul 2005 15:29:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DyaOX-0006pr-Fs for netconf-data@psg.com; Fri, 29 Jul 2005 19:19:45 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DyaOO-0006mS-RK for netconf@ops.ietf.org; Fri, 29 Jul 2005 19:19:36 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6TJJX4S017561; Fri, 29 Jul 2005 14:19:34 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 29 Jul 2005 21:19:33 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507A50927@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Eliot Lear (E-mail)" , kcrozier@cisco.com Cc: "Netconf (E-mail)" Subject: AD review for: draft-ietf-netconf-beep-05.txt Date: Fri, 29 Jul 2005 21:19:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Here is my complete review for this document. Basically ready for IETF Last Call. Pls take a look at my comments and let me know if you want to respin a revision first. Bert -------------------------- AD review for: draft-ietf-netconf-beep-05.txt - I think that there is one more IANA action, and that is the registration for the netconf BEEP profile as described in sect 2.5 nits/typos: - It is best (RFC Editor will do it, but better do it ourselves) to expand acronyms when they are used for the first time. - I find it a bit rude to state in IANA considerations "IANA will assign". I would rather state "IANA is requested to assign". Checking the references and citations I get: !! Missing citation for Informative reference: P011 L042: [10] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the !! Missing citation for Informative reference: P011 L046: [11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote IDNIITS shows thie following (I Think that is acceptable for now): $ idnits draft-ietf-netconf-beep-05.txt idnits 1.74 draft-ietf-netconf-beep-05.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. * There are 41 instances of too long lines in the document, the longest one being 1 character in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. -- 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 Jul 31 10:30:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzEpE-0006ph-U4 for netconf-archive@megatron.ietf.org; Sun, 31 Jul 2005 10:30: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 KAA28317 for ; Sun, 31 Jul 2005 10:29:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzEgX-000NgN-RO for netconf-data@psg.com; Sun, 31 Jul 2005 14:21:01 +0000 Received: from [207.69.200.28] (helo=pop04.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzEgV-000Ng9-Lk for netconf@ops.ietf.org; Sun, 31 Jul 2005 14:21:00 +0000 Received: from wamui-chipeau.atl.sa.earthlink.net ([209.86.224.30]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzEgU-0006Mw-00 for netconf@ops.ietf.org; Sun, 31 Jul 2005 10:20:58 -0400 Message-ID: <16651888.1122819658893.JavaMail.root@wamui-chipeau.atl.sa.earthlink.net> Date: Sun, 31 Jul 2005 09:20:58 -0500 (GMT-05:00) From: Randy Presuhn Reply-To: Randy Presuhn To: netconf@ops.ietf.org Subject: netconf data model gathering Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - Sharon asked me to send this message to the list: Those interested in the netconf data model should meet at 9:00 a.m. monday at the IETF registration desk in the convention center. Randy -- 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: