From owner-netconf@ops.ietf.org Tue May 3 10:40:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25077 for ; Tue, 3 May 2005 10:40:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DSyP9-0003KY-A9 for netconf-data@psg.com; Tue, 03 May 2005 14:29:43 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DSyP7-0003KG-9d for netconf@ops.ietf.org; Tue, 03 May 2005 14:29:41 +0000 Received: (qmail 19551 invoked by uid 78); 3 May 2005 14:29:40 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 3 May 2005 14:29:40 -0000 Message-ID: <42778AD3.2070906@andybierman.com> Date: Tue, 03 May 2005 07:29:39 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: Begin WG Last Call: draft-ietf-netconf-prot-06.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.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 Hi, The NETCONF WG has completed work on the NETCONF Configuration Protocol. The WG proposes that the Internet draft 'draft-ietf-netconf-prot-06.txt' is the completed version of this document. This document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-06.txt The differences between the -05 and -06 versions can be found at: http://ietf.levkowetz.com/drafts/netconf/prot/draft-ietf-netconf-prot-06-from-05.diff.html Abstract: The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an 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 RPC layer. The WG members are strongly urged to review this document as soon as possible, and express any concerns, or identify any errors, in an email to the NETCONF WG mailing list. Unless there are strong objections, published on the NETCONF WG mailing list by May 17, 2005, this document will be forwarded to the OPS Area Directors for standards track consideration by the IESG. Please send all comments to the WG mailing list at netconf@ops.ietf.org. thanks, Andy and 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 May 5 13:28:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21557 for ; Thu, 5 May 2005 13:28:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DTk12-00020q-T2 for netconf-data@psg.com; Thu, 05 May 2005 17:20:00 +0000 Received: from [64.233.170.199] (helo=rproxy.gmail.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTk12-00020W-9M for netconf@ops.ietf.org; Thu, 05 May 2005 17:20:00 +0000 Received: by rproxy.gmail.com with SMTP id b11so377131rne for ; Thu, 05 May 2005 10:19:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:x-enigmail-version:x-enigmail-supports:content-type; b=e/o9UqXsA/AXgYPznrlphd6E9FrbQ8WUbwG0QSOMV87jcqwcRaf3xW7nUT/QJ/zI0SXVliSnUmWCUstpPiG35k4Q+5jK/krBcdPOpB43OJFvK1SZPNzVxj9XE2fVaRnk/DS5ViKuNlnITa96kUgIpg3JfYYuKRdpgV/sG0VS8+E= Received: by 10.38.125.64 with SMTP id x64mr637850rnc; Thu, 05 May 2005 10:19:59 -0700 (PDT) Received: from ?192.168.1.20? ([200.121.172.92]) by mx.gmail.com with ESMTP id 71sm1218268rnc.2005.05.05.10.19.58; Thu, 05 May 2005 10:19:59 -0700 (PDT) Message-ID: <427A55C8.8090909@gmail.com> Date: Thu, 05 May 2005 12:20:08 -0500 From: Nikolas Valcarcel User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Netconf on Debian X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4BD02191D101810DD01A2278" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_BY_IP, RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_MISC autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4BD02191D101810DD01A2278 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, im looking for some application to configure the network on some Debian servers, and i think in netconf, but i haven't found it, there are some way to use it on debian? i also can't find the sources of netconf to see if it is possible to patch it for Debian, can someone send me the sources or some link to download netconf for Debian? thank you for your time -- aka nxvl Key fingerprint: E140 4CC7 5E3C B6B4 DCA7 F6FD D22E 2FB4 A9BA 6877 gpg --keyserver subkeys.pgp.net --recv-keys A9BA6877 "Nada cuesta ser educado y responder amablemente" "Si no tienes nada inteligente que decir, mejor quedate callado" --------------enig4BD02191D101810DD01A2278 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCelXI0i4vtKm6aHcRAv48AJ9vYjF8nnXuFXn3ce9J/NrLUjLAzgCeLZhr uhpW6oo7JN5MzxJpou/EP3A= =w09U -----END PGP SIGNATURE----- --------------enig4BD02191D101810DD01A2278-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu May 5 18:00:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24281 for ; Thu, 5 May 2005 18:00:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DToGr-000MXF-FY for netconf-data@psg.com; Thu, 05 May 2005 21:52:37 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DToGq-000MWz-Gg for netconf@ops.ietf.org; Thu, 05 May 2005 21:52:36 +0000 Received: (qmail 30990 invoked by uid 78); 5 May 2005 16:36:31 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 5 May 2005 16:36:31 -0000 Message-ID: <427A4B8D.3080207@andybierman.com> Date: Thu, 05 May 2005 09:36:29 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: few comments on the prot-06 draft 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.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 Hi, Throughout the text, whenever a parameter value is mentioned, such as test-then-set, it should appear in single quotes, e.g., 'test-then-set'. Some text like this could be confusing if you don't have all the tag names memorized yet ;-) The 'confirm-commit' parameter in the XSD is incorrect. There is no 'type' attribute defined so an empty element is the only allowed construct. The following text is needed in the 'confirm-timeout' element: type="xs:positiveInteger" It appears an issue (which was brought up on the mailing list) slipped through the cracks, which would cause a semantic change: - PROT, sec. 8.4.5.1 (confirmed commit parameters) units of confirm-timeout not granular enough I strongly agree with the proposal to change the units of the confirm-timeout parameter from minutes to seconds. There are already use cases where the minimum rollback trigger of one minute is too slow. Networks get faster not slower, so we should fix this now before it's too late. The default can still be 10 minutes (value == 600 instead of 10). Please comment on the mailing list regarding this issue, so we can decide if there is consensus to make this change. thanks, 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 Thu May 5 18:11:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25613 for ; Thu, 5 May 2005 18:11:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DToTp-000Nqn-AE for netconf-data@psg.com; Thu, 05 May 2005 22:06:01 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DToTm-000Nq4-Gi for netconf@ops.ietf.org; Thu, 05 May 2005 22:05:58 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 05 May 2005 15:05:57 -0700 X-IronPort-AV: i="3.92,158,1112598000"; d="scan'208"; a="634577846:sNHT541083922" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j45M5OEl024851; Thu, 5 May 2005 15:05:53 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 15:05:54 -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: few comments on the prot-06 draft Date: Thu, 5 May 2005 15:05:54 -0700 Message-ID: Thread-Topic: few comments on the prot-06 draft Thread-Index: AcVRvQxhB5xjhh9JQmezTyIebaSukgAAVi8g From: "Steven Berl \(sberl\)" To: "Andy Bierman" , "netconf" X-OriginalArrivalTime: 05 May 2005 22:05:54.0687 (UTC) FILETIME=[9BA560F0:01C551BE] 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 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, May 05, 2005 9:36 AM > To: netconf > Subject: few comments on the prot-06 draft >=20 > Hi, >=20 > Throughout the text, whenever a parameter value is mentioned,=20 > such as test-then-set, it should appear in single quotes,=20 > e.g., 'test-then-set'. Some text like this could be=20 > confusing if you don't have all the tag names memorized yet ;-) >=20 > The 'confirm-commit' parameter in the XSD is incorrect. > There is no 'type' attribute defined so an empty element is=20 > the only allowed construct. The following text is needed > in the 'confirm-timeout' element: type=3D"xs:positiveInteger" I would have thought it should be type=3D"xs:duration". >=20 > It appears an issue (which was brought up on the mailing=20 > list) slipped through the cracks, which would cause a semantic change: >=20 > - PROT, sec. 8.4.5.1 (confirmed commit parameters) > units of confirm-timeout not granular enough Xs:duration gives all the granularity you could ever want from years down to milliseconds. -steve >=20 > I strongly agree with the proposal to change the units of the=20 > confirm-timeout parameter from minutes to seconds. There are=20 > already use cases where the minimum rollback trigger of one=20 > minute is too slow. Networks get faster not slower, so we=20 > should fix this now before it's too late. The default can=20 > still be 10 minutes (value =3D=3D 600 instead of 10). >=20 > Please comment on the mailing list regarding this issue, so=20 > we can decide if there is consensus to make this change. >=20 > thanks, > Andy >=20 >=20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu May 5 21:56:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19225 for ; Thu, 5 May 2005 21:56:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DTrxf-000E28-Nk for netconf-data@psg.com; Fri, 06 May 2005 01:49:03 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DTrxd-000E1v-Ua for netconf@ops.ietf.org; Fri, 06 May 2005 01:49:02 +0000 Received: (qmail 4864 invoked by uid 78); 6 May 2005 01:46:03 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 6 May 2005 01:46:03 -0000 Message-ID: <427ACC56.1010608@andybierman.com> Date: Thu, 05 May 2005 18:45:58 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven Berl (sberl)" CC: netconf Subject: Re: few comments on the prot-06 draft References: 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.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 Steven Berl (sberl) wrote: > > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>Sent: Thursday, May 05, 2005 9:36 AM >>To: netconf >>Subject: few comments on the prot-06 draft >> >>Hi, >> >>Throughout the text, whenever a parameter value is mentioned, >>such as test-then-set, it should appear in single quotes, >>e.g., 'test-then-set'. Some text like this could be >>confusing if you don't have all the tag names memorized yet ;-) >> >>The 'confirm-commit' parameter in the XSD is incorrect. >>There is no 'type' attribute defined so an empty element is >>the only allowed construct. The following text is needed >>in the 'confirm-timeout' element: type="xs:positiveInteger" >> >> > >I would have thought it should be type="xs:duration". > > Yikes! This is way more complicated than we need! (Look at the example in the Primer Part 0 spec: P1Y2M3DT10H30M12.3S is 1 year, 2 months, 3 days, 10 hours, 30 min. and 12.3 sec I don't think we need a minimum interval less than one second or a maximum interval over billions of seconds. I prefer to keep the encoding as simple as possible -- which is a positiveInteger. Andy > > >>It appears an issue (which was brought up on the mailing >>list) slipped through the cracks, which would cause a semantic change: >> >> - PROT, sec. 8.4.5.1 (confirmed commit parameters) >> units of confirm-timeout not granular enough >> >> > >Xs:duration gives all the granularity you could ever want from years >down to milliseconds. > >-steve > > > >>I strongly agree with the proposal to change the units of the >>confirm-timeout parameter from minutes to seconds. There are >>already use cases where the minimum rollback trigger of one >>minute is too slow. Networks get faster not slower, so we >>should fix this now before it's too late. The default can >>still be 10 minutes (value == 600 instead of 10). >> >>Please comment on the mailing list regarding this issue, so >>we can decide if there is consensus to make this change. >> >>thanks, >>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: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 6 02:57:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06873 for ; Fri, 6 May 2005 02:57:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DTwdl-000AWL-37 for netconf-data@psg.com; Fri, 06 May 2005 06:48:49 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTwdj-000AW5-G9 for netconf@ops.ietf.org; Fri, 06 May 2005 06:48:47 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 05 May 2005 23:48:47 -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 j466mfER020772; Thu, 5 May 2005 23:48:42 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp158.cisco.com [10.61.64.158]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j466ckjg001876; Thu, 5 May 2005 23:38:47 -0700 Message-ID: <427B1348.9030304@cisco.com> Date: Fri, 06 May 2005 08:48:40 +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: "Steven Berl (sberl)" , netconf Subject: Re: few comments on the prot-06 draft References: <427ACC56.1010608@andybierman.com> In-Reply-To: <427ACC56.1010608@andybierman.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115361528.901792"; x:"432200"; a:"rsa-sha1"; b:"nofws:170"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"BejGyUnEjUlLV8CJPiNnQ+vDVcpYJ69Fe0VMAwkXeWAOvhe2oqkCgKcZQ3o5v5r/l6HmZkt3" "jlLXdmn0ssxCsigTFe6dR+u//qVmBiXrbA870ADfk1606TGkJvtgq5cWjkIGl6laO6CMQrWcJlp" "+te07FR4hWr+VK31MtB7qhLU="; c:"Date: Fri, 06 May 2005 08:48:40 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: few comments on the prot-06 draft" 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 Bierman wrote: >> I would have thought it should be type="xs:duration". >> >> > Yikes! This is way more complicated than we need! On the other hand, it's there. There must be stuff to parse it already?! -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 6 12:12:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05755 for ; Fri, 6 May 2005 12:12:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DU5GD-0002YS-6T for netconf-data@psg.com; Fri, 06 May 2005 16:01:05 +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 1DU5GB-0002YB-Jq for netconf@ops.ietf.org; Fri, 06 May 2005 16:01:03 +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 j46G11Bm065132; Fri, 6 May 2005 09:01:01 -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 j46G0re60310; Fri, 6 May 2005 09:00:53 -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 j46G0mHe097474; Fri, 6 May 2005 12:00:49 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200505061600.j46G0mHe097474@idle.juniper.net> To: Andy Bierman cc: netconf Subject: Re: few comments on the prot-06 draft In-Reply-To: Your message of "Thu, 05 May 2005 09:36:29 PDT." <427A4B8D.3080207@andybierman.com> Date: Fri, 06 May 2005 12:00:48 -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 Andy Bierman writes: >I strongly agree with the proposal to change the units of the >confirm-timeout >parameter from minutes to seconds. There are already use cases where >the minimum rollback trigger of one minute is too slow. Can you share some of your use cases? IMHO declaring failure and triggering recovery procedures with such a fine timer is likely to cause as many issue as it solves. 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 Fri May 6 22:44:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05813 for ; Fri, 6 May 2005 22:44:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DUF6l-000KRx-4p for netconf-data@psg.com; Sat, 07 May 2005 02:31:59 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DUF6b-000KRJ-2w for netconf@ops.ietf.org; Sat, 07 May 2005 02:31:49 +0000 Received: (qmail 5302 invoked by uid 78); 6 May 2005 16:10:55 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 6 May 2005 16:10:55 -0000 Message-ID: <427B970E.8080707@andybierman.com> Date: Fri, 06 May 2005 09:10:54 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: "Steven Berl (sberl)" , netconf Subject: Re: few comments on the prot-06 draft References: <427ACC56.1010608@andybierman.com> <427B1348.9030304@cisco.com> In-Reply-To: <427B1348.9030304@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.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 Eliot Lear wrote: > > > Andy Bierman wrote: > >>> I would have thought it should be type="xs:duration". >>> >>> >> Yikes! This is way more complicated than we need! > > > On the other hand, it's there. There must be stuff to parse it already?! This is a pretty weak argument. The type 'positiveInteger' is also there and it's really easy to parse -- way easier than 'duration'. It's way easier for operators to use in their scripts as well. More importantly -- this parameter has been a positiveInteger in every I-D version. The XSD has had a bug all along -- the confirm-timeout parameter was not defined to correctly model the normative text. The fix (make the XSD match the normative text) is type="xs:positiveInteger. A separate issue arose - whether 'minutes' was the proper units for this parameter. There is a proposal to change the units from minutes to seconds. Now there is another proposal to change the data type to 'duration'. I do not think there is consensus to make any change at this time. I wonder what the rest of the WG thinks? 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 Sat May 7 01:39:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18071 for ; Sat, 7 May 2005 01:39:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DUHvF-000GBE-SO for netconf-data@psg.com; Sat, 07 May 2005 05:32:17 +0000 Received: from [85.73.143.234] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DUHvB-000GAr-K9 for netconf@ops.ietf.org; Sat, 07 May 2005 05:32:15 +0000 Received: by boskop.local (Postfix, from userid 501) id C47F02DC3ED; Sat, 7 May 2005 07:32:09 +0200 (CEST) Date: Sat, 7 May 2005 07:32:09 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Eliot Lear , "Steven Berl (sberl)" , netconf Subject: Re: few comments on the prot-06 draft Message-ID: <20050507053209.GA3577@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Eliot Lear , "Steven Berl (sberl)" , netconf References: <427ACC56.1010608@andybierman.com> <427B1348.9030304@cisco.com> <427B970E.8080707@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427B970E.8080707@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 Fri, May 06, 2005 at 09:10:54AM -0700, Andy Bierman wrote: > I do not think there is consensus to make any change at this time. > > I wonder what the rest of the WG thinks? I think positiveInteger is what we should use and I like the idea to allow for a resolution in seconds. /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 May 7 12:19:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25309 for ; Sat, 7 May 2005 12:19:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DURpd-0002P3-1t for netconf-data@psg.com; Sat, 07 May 2005 16:07:09 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DURpc-0002Oj-0b for netconf@ops.ietf.org; Sat, 07 May 2005 16:07:08 +0000 Received: (qmail 17496 invoked by uid 78); 6 May 2005 17:23:50 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 6 May 2005 17:23:50 -0000 Message-ID: <427BA825.4090109@andybierman.com> Date: Fri, 06 May 2005 10:23:49 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Shafer CC: netconf Subject: Re: few comments on the prot-06 draft References: <200505061600.j46G0mHe097474@idle.juniper.net> In-Reply-To: <200505061600.j46G0mHe097474@idle.juniper.net> 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.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 Phil Shafer wrote: >Andy Bierman writes: > > >>I strongly agree with the proposal to change the units of the >>confirm-timeout >>parameter from minutes to seconds. There are already use cases where >>the minimum rollback trigger of one minute is too slow. >> >> > >Can you share some of your use cases? IMHO declaring failure and >triggering recovery procedures with such a fine timer is likely to >cause as many issue as it solves. > > IMO, in environments with very reliable fast connectivity (<1s RTT), on large devices in which many incremental changes to the config are common (e.g., circuit provisioning), it is undesirable to wait a whole minute to recover from a config mistake that disrupts or crashes the device, especially since we only have global locking. However, if there isn't any consensus to change the units then let's leave it alone and fix it in the future if needed. >Thanks, > Phil > > 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 Sat May 7 14:30:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04244 for ; Sat, 7 May 2005 14:30:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DUTwK-000Bsd-Pp for netconf-data@psg.com; Sat, 07 May 2005 18:22:12 +0000 Received: from [216.168.230.142] (helo=omr5.netsolmail.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DUTwI-000BsQ-Rp for netconf@ops.ietf.org; Sat, 07 May 2005 18:22:11 +0000 Received: from ms1.netsolmail.com (IDENT:mirapoint@[216.168.230.167]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j47IM9qr005953 for ; Sat, 7 May 2005 14:22:09 -0400 (EDT) Received: from ms1.netsolmail.com (localhost.netsolmail.com [127.0.0.1]) by ms1.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DEN97293; Sat, 7 May 2005 14:22:07 -0400 (EDT) Message-Id: <200505071822.DEN97293@ms1.netsolmail.com> Received: from 69.138.196.63 by ms1.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Sat, 7 May 2005 14:22:07 -0400 Date: Sat, 7 May 2005 14:22:07 -0400 From: Bob Natale Subject: Re: few comments on the prot-06 draft -- positiveInteger/seconds To: netconf@ops.ietf.org Reply-To: Bob.Natale@AppliedSNMP.com X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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=BAYES_00, MSGID_FROM_MTA_HEADER autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Since overall WG feedback was sought: I share Juergen's position on both questions -- positiveInteger and seconds. Cheers, BobN ---- Original message ---- >Date: Sat, 7 May 2005 07:32:09 +0200 >From: Juergen Schoenwaelder >Subject: Re: few comments on the prot-06 draft >To: Andy Bierman >Cc: Eliot Lear , "Steven Berl (sberl)" , netconf > >On Fri, May 06, 2005 at 09:10:54AM -0700, Andy Bierman wrote: > >> I do not think there is consensus to make any change at this time. >> >> I wonder what the rest of the WG thinks? > >I think positiveInteger is what we should use and I like the idea >to allow for a resolution in seconds. > >/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 Sun May 8 08:33:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10042 for ; Sun, 8 May 2005 08:33:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DUkly-00025A-CJ for netconf-data@psg.com; Sun, 08 May 2005 12:20:38 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DUTQb-0009Is-PJ for netconf@ops.ietf.org; Sat, 07 May 2005 17:49:25 +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 j47HkxxS026590; Sat, 7 May 2005 10:46:59 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 May 2005 10:46:59 -0700 Message-ID: From: "McDonald, Ira" To: "'j.schoenwaelder@iu-bremen.de'" , Andy Bierman Cc: Eliot Lear , "Steven Berl (sberl)" , netconf Subject: RE: few comments on the prot-06 draft Date: Sat, 7 May 2005 10:46:57 -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 agree with Juergen that 'positiveInteger' is the right datatype. 'duration' is overkill. I also agree that seconds is the right resolution. Timers in minutes are generally unsuitable in network protocols. 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 Juergen Schoenwaelder > Sent: Saturday, May 07, 2005 1:32 AM > To: Andy Bierman > Cc: Eliot Lear; Steven Berl (sberl); netconf > Subject: Re: few comments on the prot-06 draft > > > On Fri, May 06, 2005 at 09:10:54AM -0700, Andy Bierman wrote: > > > I do not think there is consensus to make any change at this time. > > > > I wonder what the rest of the WG thinks? > > I think positiveInteger is what we should use and I like the idea > to allow for a resolution in seconds. > > /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 Sun May 8 13:43:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03434 for ; Sun, 8 May 2005 13:43:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DUpf6-000Mbz-LN for netconf-data@psg.com; Sun, 08 May 2005 17:33:52 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DUpW4-000M35-7H for netconf@ops.ietf.org; Sun, 08 May 2005 17:24:32 +0000 Received: (qmail 27427 invoked by uid 78); 8 May 2005 17:24:31 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 8 May 2005 17:24:31 -0000 Message-ID: <427E4B4D.2020108@andybierman.com> Date: Sun, 08 May 2005 10:24:29 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: More confirmed-commit issues 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.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 Hi, IMO, PROT, section 8.4 is not very clear what happens if locking is not used, or if the manager doesn't follow the elements of procedure that the document suggests. If a confirmed-commit timeout is pending, and the config is modified again before the 2nd or the timeout occurs, how does the agent interpret the that is intended to be for the newly modified ? What exactly is the the contents of after the confirm-commit timer pops? What if the 2nd commit is also a confirmed-commit? What if time(C2) < timer(C1)? How come a manager cannot cancel a confirmed commit (after commit-1 but before the timeout)? Note that this corner-case can occur naturally if locking is not properly used, or pathologically, if the manager holding the locks writes to the before finishing the first confirmed commit. (E.g., operator forgets a line of config -- adds it -- commits it.) The vague warning about "use locks properly" (8.4.1, para 2) is not relevant to agent implementers who have to make this work even if locking isn't used, used wrong, or the manager doesn't follow the implied transaction model. I would also like to note that the #rollback feature was thrown out because of these same corner-cases, that (IMO) are neither explained or properly handled in the current draft as they relate to the #candidate and #confirmed-commit capabilities. 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 Sun May 8 16:25:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28075 for ; Sun, 8 May 2005 16:25:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DUsCl-00085B-AB for netconf-data@psg.com; Sun, 08 May 2005 20:16:47 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DUsCh-00084e-5f for netconf@ops.ietf.org; Sun, 08 May 2005 20:16:43 +0000 Received: from pc6 (1Cust224.tnt14.lnd4.gbr.da.uu.net [62.188.143.224]) by astro.systems.pipex.net (Postfix) with SMTP id 80A98E000051 for ; Sun, 8 May 2005 21:16:30 +0100 (BST) Message-ID: <04b901c55401$e69bd540$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: References: <200505071822.DEN97293@ms1.netsolmail.com> Subject: Re: few comments on the prot-06 draft -- positiveInteger/seconds Date: Sun, 8 May 2005 21:05:24 +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 same for me Tom Petch ----- Original Message ----- From: "Bob Natale" To: Sent: Saturday, May 07, 2005 8:22 PM Subject: Re: few comments on the prot-06 draft -- positiveInteger/seconds > Since overall WG feedback was sought: > > I share Juergen's position on both questions -- positiveInteger and seconds. > > BobN > > ---- Original message ---- > >Date: Sat, 7 May 2005 07:32:09 +0200 > >From: Juergen Schoenwaelder > >Subject: Re: few comments on the prot-06 draft > >To: Andy Bierman > >Cc: Eliot Lear , "Steven Berl (sberl)" > , netconf > > > >On Fri, May 06, 2005 at 09:10:54AM -0700, Andy Bierman wrote: > > > >> I do not think there is consensus to make any change at this time. > >> > >> I wonder what the rest of the WG thinks? > > > >I think positiveInteger is what we should use and I like the idea > >to allow for a resolution in seconds. > > > >/js > > > >Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 -- 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 May 9 10:31:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19202 for ; Mon, 9 May 2005 10:31:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DV90d-0002SK-Sg for netconf-data@psg.com; Mon, 09 May 2005 14:13:23 +0000 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DV90a-0002Rf-RW for netconf@ops.ietf.org; Mon, 09 May 2005 14:13:21 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A1434EC9F; Mon, 9 May 2005 16:13:19 +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 370394EBD6; Mon, 9 May 2005 16:13:18 +0200 (CEST) Message-ID: <427F702F.8090809@loria.fr> Date: Mon, 09 May 2005 16:14:07 +0200 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org, Radu State Subject: Re: Netconf on Debian References: <427A55C8.8090909@gmail.com> In-Reply-To: <427A55C8.8090909@gmail.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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The Madynes research team has just released a new implementation of a Netconf agent (YencaP). We also released: - A light Netconf client - A web server to manage the Netconf agents. (Yenca-Man) - A BGP module that can be integrated into YencaP to manage BGP router configuration. (XBGP-man) YencaP is implemented in Python programming language and works under Linux (tested with Fedora, Debian and Gentoo). The license of this network management suite (EnSuite) is LGPL. It is available for download in our web page: http://madynes.loria.fr/ensuite Any questions, suggestions for improvement or comments are welcome. Regards, Vincent CRIDLIG email: vincent.cridlig@loria.fr Nikolas Valcarcel wrote: >Hi, im looking for some application to configure the network on some >Debian servers, and i think in netconf, but i haven't found it, there >are some way to use it on debian? i also can't find the sources of >netconf to see if it is possible to patch it for Debian, can someone >send me the sources or some link to download netconf for Debian? > >thank you for your time > > > -- 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 May 9 11:16:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25148 for ; Mon, 9 May 2005 11:16:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DV9mg-0006NQ-CI for netconf-data@psg.com; Mon, 09 May 2005 15:03:02 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DV9md-0006Mw-3d for netconf@ops.ietf.org; Mon, 09 May 2005 15:02:59 +0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j49F2sw17236 for ; Mon, 9 May 2005 11:02:55 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 May 2005 11:02:56 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D047120DE@zcarhxm0.corp.nortel.com> From: "Glenn Waters" To: netconf@ops.ietf.org Subject: RE: few comments on the prot-06 draft -- positiveInteger/seconds Date: Mon, 9 May 2005 11:02:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C554A8.296749A4" 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=BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C554A8.296749A4 Content-Type: text/plain Same for me. Regards, /gww > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Tom Petch > Sent: Sunday, May 08, 2005 15:05 > To: netconf@ops.ietf.org > Subject: Re: few comments on the prot-06 draft -- positiveInteger/seconds > > same for me > Tom Petch > > ----- Original Message ----- > From: "Bob Natale" > To: > Sent: Saturday, May 07, 2005 8:22 PM > Subject: Re: few comments on the prot-06 draft -- positiveInteger/seconds > > > > Since overall WG feedback was sought: > > > > I share Juergen's position on both questions -- positiveInteger and > seconds. > > > > BobN > > > > ---- Original message ---- > > >Date: Sat, 7 May 2005 07:32:09 +0200 > > >From: Juergen Schoenwaelder > > >Subject: Re: few comments on the prot-06 draft > > >To: Andy Bierman > > >Cc: Eliot Lear , "Steven Berl (sberl)" > > , netconf > > > > > >On Fri, May 06, 2005 at 09:10:54AM -0700, Andy Bierman wrote: > > > > > >> I do not think there is consensus to make any change at this time. > > >> > > >> I wonder what the rest of the WG thinks? > > > > > >I think positiveInteger is what we should use and I like the idea > > >to allow for a resolution in seconds. > > > > > >/js > > > > > >Juergen Schoenwaelder International University Bremen > > > P.O. Box 750 561, 28725 > > > -- > 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: ------_=_NextPart_001_01C554A8.296749A4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: few comments on the prot-06 draft -- = positiveInteger/seconds

Same for me.

Regards, /gww

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf= .org] On
> Behalf Of Tom Petch
> Sent: Sunday, May 08, 2005 15:05
> To: netconf@ops.ietf.org
> Subject: Re: few comments on the prot-06 draft = -- positiveInteger/seconds
>
> same for me
> Tom Petch
>
> ----- Original Message -----
> From: "Bob Natale" = <Bob.Natale@AppliedSNMP.com>
> To: <netconf@ops.ietf.org>
> Sent: Saturday, May 07, 2005 8:22 PM
> Subject: Re: few comments on the prot-06 draft = -- positiveInteger/seconds
>
>
> > Since overall WG feedback was = sought:
> >
> > I share Juergen's position on both = questions -- positiveInteger and
> seconds.
> >
> > BobN
> >
> > ---- Original message ----
> > >Date: Sat, 7 May 2005 07:32:09 = +0200
> > >From: Juergen Schoenwaelder = <j.schoenwaelder@iu-bremen.de>
> > >Subject: Re: few comments on the = prot-06 draft
> > >To: Andy Bierman = <ietf@andybierman.com>
> > >Cc: Eliot Lear <lear@cisco.com>, = "Steven Berl (sberl)"
> > <sberl@cisco.com>, netconf = <netconf@ops.ietf.org>
> > >
> > >On Fri, May 06, 2005 at 09:10:54AM = -0700, Andy Bierman wrote:
> > >
> > >> I do not think there is consensus = to make any change at this time.
> > >>
> > >> I wonder what the rest of the WG = thinks?
> > >
> > >I think positiveInteger is what we = should use and I like the idea
> > >to allow for a resolution in = seconds.
> > >
> > >/js
> > >
> > >Juergen = Schoenwaelder     International University = Bremen
> > ><http://www.eecs.iu-bremen.de/>   = ;  P.O. Box 750 561, 28725
>
>
> --
> 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: <http://ops.ietf.org/lists/netconf/>

------_=_NextPart_001_01C554A8.296749A4-- -- 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 May 9 12:21:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02064 for ; Mon, 9 May 2005 12:21:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVAnZ-000Bqh-0i for netconf-data@psg.com; Mon, 09 May 2005 16:08:01 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DVAnW-000BqH-WD for netconf@ops.ietf.org; Mon, 09 May 2005 16:07:59 +0000 Received: (qmail 2056 invoked by uid 78); 9 May 2005 15:11:40 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 9 May 2005 15:11:40 -0000 Message-ID: <427F7DAA.3070106@andybierman.com> Date: Mon, 09 May 2005 08:11:38 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Cridlig CC: netconf@ops.ietf.org, Radu State Subject: Re: Netconf on Debian References: <427A55C8.8090909@gmail.com> <427F702F.8090809@loria.fr> In-Reply-To: <427F702F.8090809@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.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 Vincent Cridlig wrote: > Hi, > > The Madynes research team has just released a new implementation of a > Netconf agent (YencaP). > We also released: > - A light Netconf client > - A web server to manage the Netconf agents. (Yenca-Man) > - A BGP module that can be integrated into YencaP to manage BGP > router configuration. (XBGP-man) > > YencaP is implemented in Python programming language and works under > Linux (tested with Fedora, Debian and Gentoo). > The license of this network management suite (EnSuite) is LGPL. > It is available for download in our web page: > http://madynes.loria.fr/ensuite > > Any questions, suggestions for improvement or comments are welcome. Glad to see implementers at work already! I can't tell from a quick look at the docs what transport is being used. Are any of the 3 application mapping drafts supported? > > Regards, > Vincent CRIDLIG thanks, Andy > > email: vincent.cridlig@loria.fr > > > Nikolas Valcarcel wrote: > >> Hi, im looking for some application to configure the network on some >> Debian servers, and i think in netconf, but i haven't found it, there >> are some way to use it on debian? i also can't find the sources of >> netconf to see if it is possible to patch it for Debian, can someone >> send me the sources or some link to download netconf for Debian? >> >> thank you for your time >> >> >> > > > -- > 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 May 9 15:54:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26249 for ; Mon, 9 May 2005 15:54:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVEBK-0002I4-8S for netconf-data@psg.com; Mon, 09 May 2005 19:44:46 +0000 Received: from [85.73.166.139] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVEBI-0002Hc-8P for netconf@ops.ietf.org; Mon, 09 May 2005 19:44:44 +0000 Received: by boskop.local (Postfix, from userid 501) id D0DDE2DD450; Mon, 9 May 2005 16:56:08 +0200 (CEST) Date: Mon, 9 May 2005 16:56:08 +0200 From: Juergen Schoenwaelder To: Vincent Cridlig Cc: netconf@ops.ietf.org, Radu State Subject: Re: Netconf on Debian Message-ID: <20050509145608.GA7011@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Vincent Cridlig , netconf@ops.ietf.org, Radu State References: <427A55C8.8090909@gmail.com> <427F702F.8090809@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427F702F.8090809@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=-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, May 09, 2005 at 04:14:07PM +0200, Vincent Cridlig wrote: > The Madynes research team has just released a new implementation of a > Netconf agent (YencaP). [...] > Any questions, suggestions for improvement or comments are welcome. Like the previous yenca release (which was written in C), you do not seem to support any of the three transport mappings that are discussed in the working group. The first yenca release used a TLS stream (but did not get the framing quite right) while this release runs netconf over TCP (but with a frame marking mechanism that is different from the one used in the netconf over ssh specification). In addition, you seems to support encryption and compression above the netconf rpc layer, which does not match the approach taken by the WG (which is to leave encryption and compression to the transport). I did not look through the other parts of the code but I am wondering how much netconf there actually is in yenca. I also like to know why you did depart from the netconf transport specifications (and perhaps other parts of netconf) and whether there is anything that the WG can learn from 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 Mon May 9 18:43:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21224 for ; Mon, 9 May 2005 18:43:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVGsj-000GIg-Mk for netconf-data@psg.com; Mon, 09 May 2005 22:37:45 +0000 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVGF4-000DF2-Ag for netconf@ops.ietf.org; Mon, 09 May 2005 21:56:46 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F1C334EC37; Mon, 9 May 2005 23:56:44 +0200 (CEST) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from webloria.loria.fr (webloria.loria.fr [152.81.144.22]) by macker.loria.fr (Postfix) with ESMTP id 64FA84E919; Mon, 9 May 2005 23:56:44 +0200 (CEST) Received: from 4be54-4-82-234-154-88.fbx.proxad.net (4be54-4-82-234-154-88.fbx.proxad.net [82.234.154.88]) by www.loria.fr (IMP) with HTTP for ; Mon, 9 May 2005 23:56:44 +0200 Message-ID: <1115675804.427fdc9c2cc44@www.loria.fr> Date: Mon, 9 May 2005 23:56:44 +0200 From: Radu.State@loria.fr To: j.schoenwaelder@iu-bremen.de Cc: Vincent Cridlig , netconf@ops.ietf.org, Radu State Subject: Re: Netconf on Debian References: <427A55C8.8090909@gmail.com> <427F702F.8090809@loria.fr> <20050509145608.GA7011@boskop.local> In-Reply-To: <20050509145608.GA7011@boskop.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.4 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,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Thanks for the comments. The current release has an optional encryption and compression module, which is mere optional. Its just an implementation of our IEEE/IFIP Integrated Management IM 2005 paper. Anyway, its usage is optional and transparent, basically if an application does not want to use them, everyhing should work just fine. We will support only the SSH binding in the short future: for the moment one has to rely on standart TCP/SSH tunneling, but we will add a programmatic support shortly. Regarding the frame marking, your are right. We will change it tomorrow, we forgot to change it. Thanks for pointing it out to us. There are some additional (with respect to the draft) features in the agent (like role based access control, XSLT pushing/rendering, etc), but they are optional in usage and transparent for a normal usage. Thanks one more time and please send us more comments/bugs notification. Rearding other potential interesting experience for the WG, we can post (if there is interest for, after IM 2005) a technical report on some implemented extensions to the draft and benchmarking results which are rather surprising. RS Selon Juergen Schoenwaelder : > On Mon, May 09, 2005 at 04:14:07PM +0200, Vincent Cridlig wrote: > > > The Madynes research team has just released a new implementation of a > > Netconf agent (YencaP). > > [...] > > > Any questions, suggestions for improvement or comments are welcome. > > Like the previous yenca release (which was written in C), you do not seem > to support any of the three transport mappings that are discussed in the > working group. The first yenca release used a TLS stream (but did not > get the framing quite right) while this release runs netconf over TCP > (but with a frame marking mechanism that is different from the one used > in the netconf over ssh specification). In addition, you seems to > support encryption and compression above the netconf rpc layer, which > does not match the approach taken by the WG (which is to leave encryption > and compression to the transport). > > I did not look through the other parts of the code but I am wondering > how much netconf there actually is in yenca. I also like to know why you > did depart from the netconf transport specifications (and perhaps other > parts of netconf) and whether there is anything that the WG can learn > from 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 Mon May 9 19:11:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24978 for ; Mon, 9 May 2005 19:11:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVHKQ-000IqC-NH for netconf-data@psg.com; Mon, 09 May 2005 23:06:22 +0000 Received: from [216.168.230.140] (helo=omr4.netsolmail.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVHKM-000InD-Le for netconf@ops.ietf.org; Mon, 09 May 2005 23:06:18 +0000 Received: from ms1.netsolmail.com (IDENT:mirapoint@[216.168.230.167]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j49N5neB002447; Mon, 9 May 2005 19:05:49 -0400 (EDT) Received: from ms1.netsolmail.com (localhost.netsolmail.com [127.0.0.1]) by ms1.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DEW07311; Mon, 9 May 2005 19:05:47 -0400 (EDT) Message-Id: <200505092305.DEW07311@ms1.netsolmail.com> Received: from 69.138.196.63 by ms1.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Mon, 9 May 2005 19:05:47 -0400 Date: Mon, 9 May 2005 19:05:47 -0400 From: Bob Natale Subject: Re: Netconf on Debian - benchmarking results To: Radu.State@loria.fr Cc: netconf@ops.ietf.org Reply-To: Bob.Natale@AppliedSNMP.com X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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=BAYES_00, MSGID_FROM_MTA_HEADER autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi RS, I would definitely be interested in seeing your benchmark resu= lts, when = you can publish them. Cheers, BobN ---- Original message ---- >D= ate: Mon, =A09 May 2005 23:56:44 +0200 >From: Radu.State@loria.fr = >Subject: Re: Netconf on Debian = >To: j.schoenwaelder@iu-bremen.de >Cc: Vincent Cridlig , netconf@ops.ietf.org, = Radu State > > >Thanks for the comments. > >T= he current release has an optional encryption and compression module, = which is >mere optional. Its just an implementation of our IEEE/IFIP In= tegrated >Management IM 2005 paper. Anyway, its usage is optional and = = transparent, >basically if an application does not want to use them, ev= eryhing = should work >just fine. > >We will support only the SSH binding in th= e short future: for the = moment one has >to rely on standart TCP/SSH tunneling, but we will add = a programmatic = support >shortly. > >Regarding the frame marking, your are right. We = will change it = tomorrow, we >forgot to change it. Thanks for pointing it out to us. >= >There are some additional (with respect to the draft) features in the= = agent >(like role based access control, XSLT pushing/rendering, etc), b= ut = they are >optional in usage and transparent for a normal usage. > >Th= anks one more time and please send us more comments/bugs = notification. > >Rearding other potential interesting experience for t= he WG, we can = post (if >there is interest for, after IM 2005) a technical report on s= ome = implemented >extensions to the draft and benchmarking results which ar= e rather = surprising. > >RS > > > >Selon Juergen Schoenwaelder : > >> On Mon, May 09, 2005 at 04:14:07PM +0200, Vinc= ent Cridlig wrote: >> >> > The Madynes research team has just released= a new implementation = of a >> > Netconf agent (YencaP). >> >> [...] >> >> > Any questions= , suggestions for improvement or comments are welcome. >> >> Like the = previous yenca release (which was written in C), you do not = seem >> to support any of the three transport mappings that are discuss= ed in = the >> working group. The first yenca release used a TLS stream (but di= d not >> get the framing quite right) while this release runs netconf o= ver TCP >> (but with a frame marking mechanism that is different from t= he one = used >> in the netconf over ssh specification). In addition, you seems = to >> support encryption and compression above the netconf rpc layer, w= hich >> does not match the approach taken by the WG (which is to leave = = encryption >> and compression to the transport). >> >> I did not look= through the other parts of the code but I am wondering >> how much net= conf there actually is in yenca. I also like to know why = you >> did depart from the netconf transport specifications (and perhap= s = other >> parts of netconf) and whether there is anything that the WG ca= n learn >> from this. >> >> /js >> >> -- >> Juergen Schoenwaelder = International University = Bremen >> P.O. Box 750 561, 28725 Bremen, Germany >> > > > > > > >-- >to unsubscribe send a messa= ge to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a si= ngle 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 May 10 12:44:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14100 for ; Tue, 10 May 2005 12:44:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVXgU-0008JT-8K for netconf-data@psg.com; Tue, 10 May 2005 16:34:14 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DVXgR-0008JB-TF for netconf@ops.ietf.org; Tue, 10 May 2005 16:34:12 +0000 Received: (qmail 28048 invoked by uid 78); 10 May 2005 15:07:44 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 10 May 2005 15:07:44 -0000 Message-ID: <4280CE3D.1060809@andybierman.com> Date: Tue, 10 May 2005 08:07:41 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: xml-dir@ietf.org, Simon Leinen , netconf Subject: Re: [xml-dir] request review of NETCONF protocol References: <427BFBDE.2020503@andybierman.com> 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.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 Tim Bray wrote: > > On May 6, 2005, at 4:21 PM, Andy Bierman wrote: > Thanks for your comments. I am cc:ing the NETCONF WG for comment. The most significant comment seems to be that we should not have subtree filtering because Xpath can be used instead. This was a very contentious issue for the WG. Xpath provides many more features than we need in NETCONF, at a non-trivial complexity level. The WG (operators most strongly felt this way) decided this extra complexity is unwarranted. Network vendors concerned about embedded code size and complexity also objected strongly to "full Xpath on the router". The WG discussed several potential subsets of Xpath, but decided an arbitrary subset of a standard is not a good idea. Many network operators said they liked the subtree filtering from Junoscript better than Xpath. The WG decided to make subtree filtering mandatory and full Xpath optional. Andy >> Hi, >> >> I would like the XML Directorate to review the NETCONF Protocol draft >> for any XML issues. The current version is: >> >> draft-ietf-netconf-prot-06.txt >> >> This protocol provides network configuration features and uses XML >> encoding. > > > Comments: > > 1. > > [mildly humorous]: When we chartered the Atompub WG, we were told > sternly that we had to call it the Atom Publishing Protocol because > "The IETF doesn't do APIs." > > 3.1 a URN is a URI, so sentence needs work. > > 3.2 DTD does not stand for Document Type Declaration. The statement > makes sense (no Document Type Declaration) but the "(DTDs)" should be > removed. > > 4.1 > > When implementing XML processing software, it is advantageous if the > set of element and attribute is fixed, and known in advance. This > allows them to be predeclared as fixed readonly constants. NETCONF > encodes method and argument names as element names, which is very > unconventional. While not illegal, it does fly in the face of the > common vocabulary design idiom for this kind of situation. > > Here's the example from 4.1 > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > 27606-0100 > > > > Most other similar XML vocabularies look like this: > > > > 276-0100 > > > > or > > > 27606-0100 > > > (the latter if you have a one-method-per-RPC constraint) > > I'm also troubled that NETCONF reserves the element "" (and a > bunch of others, see section 7...) so nobody defining their own > methods can define one named "get". This means that it's going to be > really tough to extend NETCONF in future with new built-in methods > because various devices out there may have taken those names. > > More broadly, it's somewhat troubling that there's no method of > disambiguating, not only between between NETCONF-defined and > device-defined names, but between different devices' methods. That is > to say, there can be an arbitrary number of "rock-the-vote" methods > out there in the network... network-management-system DBMS management > might be easy if NETCONF provided a built-in way to disambiguate > between these methods. (Mind you, the fact that I don't know the > NETCONF application is probably showing). > > [section 7.1, but it's related. See the example at the bottom of p. > 33; it's perfectly reasonable to have a chunk of device-specific XML > in the answer to a query, but most XML language designers would > require that it be in a different namespace, which would also sove the > disambiguation problems.] > > 4.2 - the element which appears here is not specified until > section 7, a couple dozen pages later. > > 4.3 - similar contents for things like the content of , > how to maintain collisions between NETCONF-defined and device-defined > content? > > 6.1 it says "XML subtree filtering is a mechanism that allows an > application to > select particular XML subtrees ". XML subtrees of what? I was > genuinely baffled. Then I guessed that the configuration datastores > introduced in section 5 are in fact XML constructs and you're > selecting out of them? Or am I wrong. Anyhow, some context is badly > needed. > > If this were the W3C, this whole subtree-filtering section would be > bounced instantly on the grounds that it seems to be re-inventing > XPath. Particularly since XPath is actually used in NETCONF, for > in 4.3, and then there's a whole section 8.9. > > Maybe the requirements of this are app are such that it's sensible to > re-invent something which has been widely implemented in a variety of > free high-quality implementations in basically every computer language. > > Sorry, I decline to study the details of yet another XML tree > extraction mechanism. This problem has been rather well solved, it > escapes me why it needs to be done again. Suffice it to say that > designing this kind of thing is hard and it is very easy to specify > things that turn out to have unforeseen high cost to implement. > > Grr... section 6.4.4, yes this really smells like a half-baked > reinvention of XPath. Sorry for being rude in the case that I missed > something obvious. > > 7. > > It might be a good idea to reorder the doc and move this up above some > other sections. Having read this, I now know the basic high-level > shape of the dialogue, and this gives context to things like the > element and the subtree filtering, that were introduced with no > context. Purely editorial. > > > > seems way smoother than > > > > > > > or, in the case where you can ask for more than one source: > > > > > > 7.2 same comments regarding - > in this case the definition says that there's a single target, so why > not use an attribute? > > Basically, the conventional wisdom is that XML markup should label > something, i.e. say what it is, while names usually go in content or > attribute values. > > [Section 8 is largely unreviewed as it's very app-specific] > > > -- 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 May 10 13:29:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22876 for ; Tue, 10 May 2005 13:29:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVYLh-000Btc-2o for netconf-data@psg.com; Tue, 10 May 2005 17:16:49 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DVYLg-000BtQ-Cz for netconf@ops.ietf.org; Tue, 10 May 2005 17:16:48 +0000 Received: (qmail 5064 invoked by uid 78); 10 May 2005 16:07:56 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 10 May 2005 16:07:56 -0000 Message-ID: <4280DC5A.8090707@andybierman.com> Date: Tue, 10 May 2005 09:07:54 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: no NETCONF WG meeting planned for Paris 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.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 Hi, At this time, it appears all WG milestones will be completed before the next IETF, so there are no plans to hold a NETCONF WG meeting at the Paris IETF. We understand that some people want to continue adding features to the protocol and/or work on standard data models, but this work would need to be chartered first -- a process that has not been started, and not likely to be completed before the next IETF. Andy and 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 Tue May 10 18:37:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00420 for ; Tue, 10 May 2005 18:37:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVdDM-000BgK-Vb for netconf-data@psg.com; Tue, 10 May 2005 22:28:32 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVdDK-000Bg0-50 for netconf@ops.ietf.org; Tue, 10 May 2005 22:28:30 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 10 May 2005 15:28:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,173,1112598000"; d="scan'208"; a="291107450:sNHT38676584" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 15:28:10 -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: few comments on the prot-06 draft -- positiveInteger/seconds Date: Tue, 10 May 2005 15:28:11 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D44099DF62E@photon.jnpr.net> Thread-Topic: few comments on the prot-06 draft -- positiveInteger/seconds Thread-Index: AcVUCxd2YMcH+/uiT+GE64RjXy/xVgBo+uNA From: "Rob Enns" To: X-OriginalArrivalTime: 10 May 2005 22:28:10.0765 (UTC) FILETIME=[8C1373D0:01C555AF] 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 Thanks all. Sounds to me like the positiveInteger/seconds=20 proposal for confirm-timeout has WG consensus. Change made. Rob > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Tom Petch > Sent: Sunday, May 08, 2005 12:05 PM > To: netconf@ops.ietf.org > Subject: Re: few comments on the prot-06 draft --=20 > positiveInteger/seconds >=20 > same for me > Tom Petch >=20 > ----- Original Message -----=20 > From: "Bob Natale" > To: > Sent: Saturday, May 07, 2005 8:22 PM > Subject: Re: few comments on the prot-06 draft --=20 > positiveInteger/seconds >=20 >=20 > > Since overall WG feedback was sought: > >=20 > > I share Juergen's position on both questions --=20 > positiveInteger and seconds. > >=20 > > BobN > >=20 > > ---- Original message ---- > > >Date: Sat, 7 May 2005 07:32:09 +0200 > > >From: Juergen Schoenwaelder =20 > > >Subject: Re: few comments on the prot-06 draft =20 > > >To: Andy Bierman > > >Cc: Eliot Lear , "Steven Berl (sberl)"=20 > > , netconf > > > > > >On Fri, May 06, 2005 at 09:10:54AM -0700, Andy Bierman wrote: > > > > > >> I do not think there is consensus to make any change at=20 > this time. > > >>=20 > > >> I wonder what the rest of the WG thinks? > > > > > >I think positiveInteger is what we should use and I like the idea > > >to allow for a resolution in seconds. > > > > > >/js > > > > > >Juergen Schoenwaelder International University Bremen > > > P.O. Box 750 561, 28725=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 Tue May 10 19:05:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02186 for ; Tue, 10 May 2005 19:05:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVdj5-000EOD-MD for netconf-data@psg.com; Tue, 10 May 2005 23:01:19 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVdj5-000ENx-84 for netconf@ops.ietf.org; Tue, 10 May 2005 23:01:19 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 10 May 2005 16:01:18 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,173,1112598000"; d="scan'208"; a="291187837:sNHT19657796" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 16:01:18 -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: few comments on the prot-06 draft Date: Tue, 10 May 2005 16:01:18 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D44099DF63C@photon.jnpr.net> Thread-Topic: few comments on the prot-06 draft Thread-Index: AcVRvQAWvzZNGFDtRDi2sOcU5gt5rwD9PvnQ From: "Rob Enns" To: "Andy Bierman" , "netconf" X-OriginalArrivalTime: 10 May 2005 23:01:18.0811 (UTC) FILETIME=[2D0B32B0:01C555B4] 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 > Throughout the text, whenever a parameter value is mentioned, > such as test-then-set, it should appear in single quotes, > e.g., 'test-then-set'. Some text like this could be confusing if you=20 > don't have all the tag names memorized yet ;-) Ack, will make the change for attributes. Similarly for consistency=20 element names should be delimited with <>. In most cases they are but there are a few I missed. Rob -- 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 May 11 04:05:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11593 for ; Wed, 11 May 2005 04:05:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVm3E-0005Kh-8M for netconf-data@psg.com; Wed, 11 May 2005 07:54:40 +0000 Received: from [216.93.167.200] (helo=zak.ecotroph.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVYFX-000BUs-Rx for netconf@ops.ietf.org; Tue, 10 May 2005 17:10:27 +0000 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 10 May 2005 13:10:26 -0400 id 000FFA02.4280EB02.000004BC In-Reply-To: <4280CE3D.1060809@andybierman.com> References: <427BFBDE.2020503@andybierman.com> <4280CE3D.1060809@andybierman.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: xml-dir@ietf.org, Simon Leinen , netconf , Tim Bray From: Andrew Newton Subject: Re: [xml-dir] request review of NETCONF protocol Date: Tue, 10 May 2005 13:10:20 -0400 To: Andy Bierman X-Mailer: Apple Mail (2.619.2) 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 On May 10, 2005, at 11:07 AM, Andy Bierman wrote: > The WG (operators most strongly felt this way) > decided this extra complexity is unwarranted. Network vendors > concerned > about embedded code size and complexity also objected strongly to > "full Xpath on the router". For what it is worth, NETCONF is not the first wg nor will be the last to have this concern regarding XPATH. If the participants have done their homework and find a reasonable and workable alternative, then I see nothing wrong with using it. Yes, XPATH would be preferable, but the world is not a perfect place. Perhaps this issue should be brought to the attention of the IAB so that guidance can be formulated for the next working group that must tackle this problem. -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 May 11 05:33:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16850 for ; Wed, 11 May 2005 05:33:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVnVR-000CCd-DE for netconf-data@psg.com; Wed, 11 May 2005 09:27:53 +0000 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVnVO-000CBy-49 for netconf@ops.ietf.org; Wed, 11 May 2005 09:27:50 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EF05A504D9; Wed, 11 May 2005 11:27:48 +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 2F2C1503BE; Wed, 11 May 2005 11:27:48 +0200 (CEST) Message-ID: <4281D045.7020501@loria.fr> Date: Wed, 11 May 2005 11:28:37 +0200 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org, Radu State Subject: Re: Netconf on Debian References: <427A55C8.8090909@gmail.com> <427F702F.8090809@loria.fr> <427F7DAA.3070106@andybierman.com> In-Reply-To: <427F7DAA.3070106@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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, YencaP now supports Netconf over SSH. This underlying application protocol is the default one in YencaP. We updated Yencap with standard message separator (meaning ]]>]]> caracter) instead of the previous method which consisted of sending the size of the request and then the request itself. For interoperability, all alternative features (XML-Encryption, Role-based access control, compression) are disabled when using SSH. For test purpose, YencaP still supports optionnally NetConf over TCP with the alternative security model and compression. Thanks for the comments and interest. Feel free to send more comments, questions and/or suggestions. Best regards, Vincent Cridlig Andy Bierman wrote: > Vincent Cridlig wrote: > >> Hi, >> >> The Madynes research team has just released a new implementation of a >> Netconf agent (YencaP). >> We also released: >> - A light Netconf client >> - A web server to manage the Netconf agents. (Yenca-Man) >> - A BGP module that can be integrated into YencaP to manage BGP >> router configuration. (XBGP-man) >> >> YencaP is implemented in Python programming language and works under >> Linux (tested with Fedora, Debian and Gentoo). >> The license of this network management suite (EnSuite) is LGPL. >> It is available for download in our web page: >> http://madynes.loria.fr/ensuite >> >> Any questions, suggestions for improvement or comments are welcome. > > > Glad to see implementers at work already! > I can't tell from a quick look at the docs what transport is being used. > Are any of the 3 application mapping drafts supported? > >> >> Regards, >> Vincent CRIDLIG > > > thanks, > Andy > >> >> email: vincent.cridlig@loria.fr >> >> >> Nikolas Valcarcel wrote: >> >>> Hi, im looking for some application to configure the network on some >>> Debian servers, and i think in netconf, but i haven't found it, there >>> are some way to use it on debian? i also can't find the sources of >>> netconf to see if it is possible to patch it for Debian, can someone >>> send me the sources or some link to download netconf for Debian? >>> >>> thank you for your time >>> >>> >>> >> >> >> -- >> 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 Wed May 11 16:28:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22743 for ; Wed, 11 May 2005 16:28:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVxhZ-0009tK-WB for netconf-data@psg.com; Wed, 11 May 2005 20:21:06 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DVxhZ-0009t6-AJ for netconf@ops.ietf.org; Wed, 11 May 2005 20:21:05 +0000 Received: (qmail 4361 invoked by uid 78); 11 May 2005 20:21:04 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 11 May 2005 20:21:04 -0000 Message-ID: <4282692D.4090208@andybierman.com> Date: Wed, 11 May 2005 13:21:01 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: another XSD alignment nit 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.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 Hi, Section 8.8.5 lists proto-op extensions for the #url capability. The XSD does not match the normative text in one place: - complexType editConfigType : the element is type 'configInlineType' but it should be a choice between configInlineType and configURIType [Rob understands the edits... :-) ] 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 Fri May 13 14:32:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12376 for ; Fri, 13 May 2005 14:32:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWeo4-0001Fr-9Y for netconf-data@psg.com; Fri, 13 May 2005 18:22:40 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWeo3-0001Fd-Ox for netconf@ops.ietf.org; Fri, 13 May 2005 18:22:39 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 13 May 2005 11:22:39 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,107,1115017200"; d="scan'208"; a="303369869:sNHT25818096" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:22:39 -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: another XSD alignment nit Date: Fri, 13 May 2005 11:22:29 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440A0036CB@photon.jnpr.net> Thread-Topic: another XSD alignment nit Thread-Index: AcVWZzgyRvROx/hNSu6lb9Gb/l2HigBgKUkg From: "Rob Enns" To: "Andy Bierman" , "netconf" X-OriginalArrivalTime: 13 May 2005 18:22:39.0236 (UTC) FILETIME=[BEA3C440:01C557E8] 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 > Section 8.8.5 lists proto-op extensions for the #url capability. > The XSD does not match the normative text in one place: >=20 > - complexType editConfigType : the element is type=20 > 'configInlineType' > but it should be a choice between configInlineType and=20 > configURIType Elsewhere (source/target parameters) NETCONF uses the=20 element as a sibling of , so I suspect we should do the same in . The resulting XSD would be: Use of the test-option element requires the #validate capability. Use of the url element requires the #url capability. I think this is better than stuffing inside in here, and using it as a sibling of in other spots. Cool? Rob -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 13 17:15:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10277 for ; Fri, 13 May 2005 17:15:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWhOo-000IPk-Gg for netconf-data@psg.com; Fri, 13 May 2005 21:08:46 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWhOn-000IPN-Nx for netconf@ops.ietf.org; Fri, 13 May 2005 21:08:45 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 13 May 2005 14:08:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,108,1115017200"; d="scan'208"; a="293842257:sNHT37149648" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 14:08:41 -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: More confirmed-commit issues Date: Fri, 13 May 2005 14:08:27 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440A003703@photon.jnpr.net> Thread-Topic: More confirmed-commit issues Thread-Index: AcVT9GdXvibYBMHzSd6g+m9GfppwMAEC1t1A From: "Rob Enns" To: "Andy Bierman" , "netconf" X-OriginalArrivalTime: 13 May 2005 21:08:41.0782 (UTC) FILETIME=[F0C7A560:01C557FF] 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 How does this replacement text sound? ---- 8.4 Confirmed Commit Capability 8.4.1 Description The #confirmed-commit capability indicates that the server will support the and parameters for the protocol operation. See section Section 8.3 for further details on the operation. A confirmed commit operation MUST be reverted if a follow-up commit (called the "confirming commit") is not issued within 600 seconds (10 minutes). The timeout period can be adjusted with the element. The confirming commit can itself include a parameter. If a confirming commit is not issued, the device will revert it's configuration to the state prior to the issuance of the confirmed commit. Note that any commit operation, including a commit which introduces additional changes to the configuration, will serve as a confirming commit. Thus to cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the confirming commit can explicitly restore the configuration to it's state before the confirmed commit was issued. For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, lock obtained before the edit-config operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration databases, configuration locking should also be used. 8.4.2 Dependencies The #confirmed-commit capability is only relevant if the #candidate capability is also supported. 8.4.3 Capability and Namespace The #confirmed-commit capability is identified by the following capability string: urn:ietf:params:xml:ns:netconf:base:1.0#confirmed-commit The #confirmed-commit capability uses the base NETCONF namespace URN. 8.4.4 New Operations None. 8.4.5 Modifications to Existing Operations 8.4.5.1 The #confirmed-commit capability allows 2 additional parameters to the operation. Parameters: confirmed: Perform a confirmed commit operation. confirm-timeout: Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds. Example: 120 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Sunday, May 08, 2005 10:24 AM > To: netconf > Subject: More confirmed-commit issues >=20 > Hi, >=20 > IMO, PROT, section 8.4 is not very clear what happens > if locking is not used, or if the manager doesn't follow > the elements of procedure that the document suggests. >=20 > If a confirmed-commit timeout is pending, and the > config is modified again before the 2nd or the timeout > occurs, how does the agent interpret the that is intended > to be for the newly modified ? What exactly is the the > contents of after the confirm-commit timer pops? > What if the 2nd commit is also a confirmed-commit? What if > time(C2) < timer(C1)? How come a manager cannot cancel a confirmed > commit (after commit-1 but before the timeout)? >=20 > Note that this corner-case can occur naturally if locking is not=20 > properly used, > or pathologically, if the manager holding the locks writes to the=20 > > before finishing the first confirmed commit. (E.g., operator=20 > forgets a line > of config -- adds it -- commits it.) >=20 > The vague warning about "use locks properly" (8.4.1, para 2) is not=20 > relevant > to agent implementers who have to make this work even if=20 > locking isn't=20 > used, > used wrong, or the manager doesn't follow the implied=20 > transaction model. >=20 > I would also like to note that the #rollback feature was=20 > thrown out because > of these same corner-cases, that (IMO) are neither explained=20 > or properly=20 > handled > in the current draft as they relate to the #candidate and =20 > #confirmed-commit > capabilities. >=20 > Andy >=20 >=20 >=20 >=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 Sat May 14 08:23:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27310 for ; Sat, 14 May 2005 08:23:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWvVr-0004gi-Qb for netconf-data@psg.com; Sat, 14 May 2005 12:12:59 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DWvVp-0004gU-JV for netconf@ops.ietf.org; Sat, 14 May 2005 12:12:57 +0000 Received: (qmail 20053 invoked by uid 78); 14 May 2005 12:12:51 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 14 May 2005 12:12:51 -0000 Message-ID: <4285EB3E.5030009@andybierman.com> Date: Sat, 14 May 2005 05:12:46 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: netconf Subject: Re: More confirmed-commit issues References: <062B922B6EC55149B5A267ECE78E5D440A003703@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440A003703@photon.jnpr.net> 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.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 Rob Enns wrote: >How does this replacement text sound? > >---- >8.4 Confirmed Commit Capability > >8.4.1 Description > > The #confirmed-commit capability indicates that the server will > support the and parameters for the > protocol operation. See section Section 8.3 for further > details on the operation. > > A confirmed commit operation MUST be reverted if a follow-up commit > (called the "confirming commit") is not issued within 600 seconds (10 > minutes). The timeout period can be adjusted with the timeout> element. The confirming commit can itself include a > parameter. > > This last sentence is confusing to me. It makes sense if the contains new changes and the 2nd confirmed commit starts a new "revert timeout" for these new changes. I really don't like the possible side effects from this confirmed commit, especially with our shared and global locking. If you don't maintain the session and hold the lock throughout the entire double commit, really bad things can happen. (NEW ISSUE: What happens to a confirmed commit in progress if the session is lost or the agent reboots?) T0 - boot with baseline config Tc - Manager A issues a confirmed commit, w/ revert to baseline at Tc+i Tc+1 - Manager A loses its connection and session Tc+10 - Manager B has no idea Manager A did this, comes along, gets the lock, and starts writing to the config, which starts with the contents of at time Tc Tc+20 - Then Manager A comes back and can't get a lock Tc+i - Manager A's revert timer pops before Manager B is done The agent reverts the state of to T0. (But B thinks the state of is Tc). At this point, it depends on the difference between config T0 and Tc, and what Manager B is doing, as to whether benign or devastating effects will follow. It's never a good thing to design this much "astonishment" into routing products. At a minimum, we need to document what happens in as many corner cases as we can think of, but we should also try to respect the principle of least astonishment. > If a confirming commit is not issued, the device will revert it's > configuration to the state prior to the issuance of the confirmed > commit. Note that any commit operation, including a commit which > introduces additional changes to the configuration, will serve as a > confirming commit. Thus to cancel a confirmed commit and revert > changes without waiting for the confirm timeout to expire, the > confirming commit can explicitly restore the configuration to it's > state before the confirmed commit was issued. > > I don't understand this last sentence, and this revert operation at all. BTW, s/it's/its/ in both paragraphs above. > For shared configurations, this feature can cause other configuration > changes (for example, via other NETCONF sessions) to be inadvertently > altered or removed, unless the configuration locking feature is used > (in other words, lock obtained before the edit-config operation is > started). Therefore, it is strongly suggested that in order to use > this feature with shared configuration databases, configuration > locking should also be used. > >8.4.2 Dependencies > > The #confirmed-commit capability is only relevant if the #candidate > capability is also supported. > >8.4.3 Capability and Namespace > > The #confirmed-commit capability is identified by the following > capability string: > > urn:ietf:params:xml:ns:netconf:base:1.0#confirmed-commit > > The #confirmed-commit capability uses the base NETCONF namespace URN. > >8.4.4 New Operations > > None. > >8.4.5 Modifications to Existing Operations > >8.4.5.1 > > The #confirmed-commit capability allows 2 additional parameters to > the operation. > > Parameters: > > confirmed: > > Perform a confirmed commit operation. > > confirm-timeout: > > Timeout period for confirmed commit, in seconds. If > unspecified, the confirm timeout defaults to 600 seconds. > > Example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > 120 > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>Sent: Sunday, May 08, 2005 10:24 AM >>To: netconf >>Subject: More confirmed-commit issues >> >>Hi, >> >>IMO, PROT, section 8.4 is not very clear what happens >>if locking is not used, or if the manager doesn't follow >>the elements of procedure that the document suggests. >> >>If a confirmed-commit timeout is pending, and the >>config is modified again before the 2nd or the timeout >>occurs, how does the agent interpret the that is intended >>to be for the newly modified ? What exactly is the the >>contents of after the confirm-commit timer pops? >>What if the 2nd commit is also a confirmed-commit? What if >>time(C2) < timer(C1)? How come a manager cannot cancel a confirmed >>commit (after commit-1 but before the timeout)? >> >>Note that this corner-case can occur naturally if locking is not >>properly used, >>or pathologically, if the manager holding the locks writes to the >> >>before finishing the first confirmed commit. (E.g., operator >>forgets a line >>of config -- adds it -- commits it.) >> >>The vague warning about "use locks properly" (8.4.1, para 2) is not >>relevant >>to agent implementers who have to make this work even if >>locking isn't >>used, >>used wrong, or the manager doesn't follow the implied >>transaction model. >> >>I would also like to note that the #rollback feature was >>thrown out because >>of these same corner-cases, that (IMO) are neither explained >>or properly >>handled >>in the current draft as they relate to the #candidate and >>#confirmed-commit >>capabilities. >> >>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 Mon May 16 17:16:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21220 for ; Mon, 16 May 2005 17:16:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DXmnh-000A1V-9Z for netconf-data@psg.com; Mon, 16 May 2005 21:06:57 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DXmnf-000A1A-Kg for netconf@ops.ietf.org; Mon, 16 May 2005 21:06:55 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 60B7A11D739; Mon, 16 May 2005 14:06:51 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Cc: Rob Enns , netconf Subject: Re: More confirmed-commit issues Organization: Sparta References: <062B922B6EC55149B5A267ECE78E5D440A003703@photon.jnpr.net> <4285EB3E.5030009@andybierman.com> Date: Mon, 16 May 2005 14:06:50 -0700 In-Reply-To: <4285EB3E.5030009@andybierman.com> (Andy Bierman's message of "Sat, 14 May 2005 05:12:46 -0700") 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 Andy> T0 - boot with baseline config Andy> Tc - Manager A issues a confirmed commit, w/ revert to baseline at Tc+i Andy> Tc+1 - Manager A loses its connection and session Andy> Tc+10 - Manager B has no idea Manager A did this, comes along, gets the Andy> lock, Andy> and starts writing to the config, which Andy> starts with the contents Andy> of at time Tc Andy> Tc+20 - Then Manager A comes back and can't get a lock Andy> Tc+i - Manager A's revert timer pops before Manager B is done Andy> The agent reverts the state of to T0. (But B Andy> thinks the Andy> state of is Tc). It's even more interesting when you think about A doing things like that intentionally. Since the lock has been dropped, you're down to auditing to figure out who the bad guy was that reverted changes out from under you. -- "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 Mon May 16 17:35:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23178 for ; Mon, 16 May 2005 17:35:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DXnAA-000CFF-7x for netconf-data@psg.com; Mon, 16 May 2005 21:30:10 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DXnA8-000CEr-9k for netconf@ops.ietf.org; Mon, 16 May 2005 21:30:08 +0000 Received: (qmail 18446 invoked by uid 78); 16 May 2005 21:30:07 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 16 May 2005 21:30:07 -0000 Message-ID: <428910DD.5040409@andybierman.com> Date: Mon, 16 May 2005 14:30:05 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker CC: Rob Enns , netconf Subject: Re: More confirmed-commit issues References: <062B922B6EC55149B5A267ECE78E5D440A003703@photon.jnpr.net> <4285EB3E.5030009@andybierman.com> 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.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 Wes Hardaker wrote: >Andy> T0 - boot with baseline config >Andy> Tc - Manager A issues a confirmed commit, w/ revert to baseline at Tc+i >Andy> Tc+1 - Manager A loses its connection and session >Andy> Tc+10 - Manager B has no idea Manager A did this, comes along, gets the >Andy> lock, >Andy> and starts writing to the config, which >Andy> starts with the contents >Andy> of at time Tc >Andy> Tc+20 - Then Manager A comes back and can't get a lock >Andy> Tc+i - Manager A's revert timer pops before Manager B is done >Andy> The agent reverts the state of to T0. (But B >Andy> thinks the >Andy> state of is Tc). > >It's even more interesting when you think about A doing things like >that intentionally. Since the lock has been dropped, you're down to >auditing to figure out who the bad guy was that reverted changes out >from under you. > > > I would be more worried about security-related config that gets reverted by mistake. There is no way or Mgr B to know a confirmed commit is in progress. We can fix this part by adding a "confirmed-commit-in-progress" warning (rpc-error response) that is generated if an rpc request which would alter the config is received by the agent while a 2nd commit operation or revert-timeout is pending. 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 Mon May 16 17:57:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29566 for ; Mon, 16 May 2005 17:57:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DXnUk-000ELo-5h for netconf-data@psg.com; Mon, 16 May 2005 21:51:26 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DXnUj-000ELX-EZ for netconf@ops.ietf.org; Mon, 16 May 2005 21:51:25 +0000 Received: (qmail 4064 invoked by uid 78); 16 May 2005 21:51:24 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 16 May 2005 21:51:24 -0000 Message-ID: <428915DB.6090300@andybierman.com> Date: Mon, 16 May 2005 14:51:23 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker CC: Rob Enns , netconf Subject: Re: More confirmed-commit issues References: <062B922B6EC55149B5A267ECE78E5D440A003703@photon.jnpr.net> <4285EB3E.5030009@andybierman.com> 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.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 Wes Hardaker wrote: >Andy> T0 - boot with baseline config >Andy> Tc - Manager A issues a confirmed commit, w/ revert to baseline at Tc+i >Andy> Tc+1 - Manager A loses its connection and session >Andy> Tc+10 - Manager B has no idea Manager A did this, comes along, gets the >Andy> lock, >Andy> and starts writing to the config, which >Andy> starts with the contents >Andy> of at time Tc >Andy> Tc+20 - Then Manager A comes back and can't get a lock >Andy> Tc+i - Manager A's revert timer pops before Manager B is done >Andy> The agent reverts the state of to T0. (But B >Andy> thinks the >Andy> state of is Tc). > >It's even more interesting when you think about A doing things like >that intentionally. Since the lock has been dropped, you're down to >auditing to figure out who the bad guy was that reverted changes out >from under you. > > The audit log may not help: - scenario above occurs - attacker (mgr B) logs in, makes changes to to open holes in firewalls, etc. but doesn't commit them. He doesn't close the session either. - Mgr A recovers from the lost connection, logs in, gets the lock, and issues a command, which serves to finish his confirmed commit, and also commit the attacker's changes. The 2nd in a confirmed-commit should be preceded by a operation, in the event the lock is lost after the first operation. 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 May 17 12:35:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13228 for ; Tue, 17 May 2005 12:35:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DY4sb-0004GC-Di for netconf-data@psg.com; Tue, 17 May 2005 16:25:13 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DY4sa-0004Fo-6O for netconf@ops.ietf.org; Tue, 17 May 2005 16:25:12 +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 j4HGP9rT002426 for ; Tue, 17 May 2005 11:25:10 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 May 2005 18:25:08 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155071BEBC1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: Protocol Action: 'Using the Simple Object Access Protocol (S OAP) in Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard Date: Tue, 17 May 2005 18:25:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 I believe this WG had a dependency on this update, so here it is. Bert -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org]On Behalf Of The IESG Sent: Tuesday, May 17, 2005 01:05 To: IETF-Announce Cc: Internet Architecture Board; RFC Editor Subject: Protocol Action: 'Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard The IESG has approved the following document: - 'Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) ' as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Scott Hollenbeck. Technical Summary This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. If approved, this document obsoletes RFC 3288. Working Group Summary This document is the work of individual submitters. It was subjected to a 4-week IETF last call. Last call comments were addressed prior to IESG review. Protocol Quality Scott Hollenbeck has reviewed this specification for the IESG. RFC Editor Note In section 6.1.1, please change IP address "10.0.0.2" to "192.0.2.0" to conform to the conventions described in RFC 3330. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-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 Tue May 17 14:56:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26000 for ; Tue, 17 May 2005 14:56:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DY78h-000EDS-1m for netconf-data@psg.com; Tue, 17 May 2005 18:49:59 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DY78e-000EDB-1A for netconf@ops.ietf.org; Tue, 17 May 2005 18:49:56 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 17 May 2005 11:49:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,114,1115017200"; d="scan'208"; a="332303672:sNHT29675128" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 11:49:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: More confirmed-commit issues Date: Tue, 17 May 2005 11:49:54 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440A0038C4@photon.jnpr.net> Thread-Topic: More confirmed-commit issues Thread-Index: AcVYfkf+pVjrd07JTwym3ykbqkMxFQCkfGTA From: "Rob Enns" To: "Andy Bierman" Cc: "netconf" X-OriginalArrivalTime: 17 May 2005 18:49:55.0402 (UTC) FILETIME=[3785E2A0:01C55B11] 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, comments below.=20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Saturday, May 14, 2005 5:13 AM > To: Rob Enns > Cc: netconf > Subject: Re: More confirmed-commit issues >=20 > Rob Enns wrote: >=20 > >How does this replacement text sound? > > > >---- > >8.4 Confirmed Commit Capability > > > >8.4.1 Description > > > > The #confirmed-commit capability indicates that the server will > > support the and parameters for the > > protocol operation. See section Section 8.3 for further > > details on the operation. > > > > A confirmed commit operation MUST be reverted if a=20 > follow-up commit > > (called the "confirming commit") is not issued within 600=20 > seconds (10 > > minutes). The timeout period can be adjusted with the > timeout> element. The confirming commit can itself include a > > parameter. > > =20 > > > This last sentence is confusing to me. It makes sense if the=20 > contains > new changes and the 2nd confirmed commit starts a new "revert=20 > timeout"=20 > for these > new changes. =20 That's the intent. I mention it here only to indicate that the confirming commit is not magic, it's a regular commit that could itself be confirmed or make additional changes. > I really don't like the possible side effects from this confirmed=20 > commit, especially with our > shared and global locking. If you don't maintain the=20 > session and hold the > lock throughout the entire double commit, really bad things=20 > can happen.=20 >=20 > (NEW ISSUE: What happens to a confirmed commit in progress if the=20 > session is lost > or the agent reboots?) >=20 > T0 - boot with baseline config > Tc - Manager A issues a confirmed commit, w/ revert to=20 > baseline at Tc+i > Tc+1 - Manager A loses its connection and session > Tc+10 - Manager B has no idea Manager A did this, comes=20 > along, gets the=20 > lock, > and starts writing to the config, which =20 > starts with the contents > of at time Tc > Tc+20 - Then Manager A comes back and can't get a lock > Tc+i - Manager A's revert timer pops before Manager B is done > The agent reverts the state of to T0. (But B=20 > thinks the > state of is Tc). >=20 > At this point, it depends on the difference between config T0=20 > and Tc, and > what Manager B is doing, as to whether benign or devastating effects=20 > will follow. >=20 > It's never a good thing to design this much "astonishment"=20 > into routing=20 > products. > At a minimum, we need to document what happens in as many=20 > corner cases as > we can think of, but we should also try to respect the principle of=20 > least astonishment. I don't view this as astonishing, or a side effect. It's very simple: when the timer pops from a confirmed commit, the device will revert to the T0 configuration. I'd argue that it's the kind of easy to understand basic behavior that operators like. > > If a confirming commit is not issued, the device will revert it's > > configuration to the state prior to the issuance of the confirmed > > commit. Note that any commit operation, including a commit which > > introduces additional changes to the configuration, will=20 > serve as a > > confirming commit. Thus to cancel a confirmed commit and revert > > changes without waiting for the confirm timeout to expire, the > > confirming commit can explicitly restore the configuration to it's > > state before the confirmed commit was issued. > > =20 > > > I don't understand this last sentence, and this revert=20 > operation at all. This is in reponse to your comment about how the configuration would be reverted before the timer pops. We can't use the rollback operation to explain it, because netconf doesn't have one at this point. I could remove that text completely if it's confusing. > BTW, s/it's/its/ in both paragraphs above. Quite right, thanks. Rob > > For shared configurations, this feature can cause other=20 > configuration > > changes (for example, via other NETCONF sessions) to be=20 > inadvertently > > altered or removed, unless the configuration locking=20 > feature is used > > (in other words, lock obtained before the edit-config operation is > > started). Therefore, it is strongly suggested that in=20 > order to use > > this feature with shared configuration databases, configuration > > locking should also be used. > > > >8.4.2 Dependencies > > > > The #confirmed-commit capability is only relevant if the=20 > #candidate > > capability is also supported. > > > >8.4.3 Capability and Namespace > > > > The #confirmed-commit capability is identified by the following > > capability string: > > > > urn:ietf:params:xml:ns:netconf:base:1.0#confirmed-commit > > > > The #confirmed-commit capability uses the base NETCONF=20 > namespace URN. > > > >8.4.4 New Operations > > > > None. > > > >8.4.5 Modifications to Existing Operations > > > >8.4.5.1 > > > > The #confirmed-commit capability allows 2 additional parameters to > > the operation. > > > > Parameters: > > > > confirmed: > > > > Perform a confirmed commit operation. > > > > confirm-timeout: > > > > Timeout period for confirmed commit, in seconds. If > > unspecified, the confirm timeout defaults to 600 seconds. > > > > Example: > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > 120 > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > >=20 > > > > =20 > > > >>-----Original Message----- > >>From: owner-netconf@ops.ietf.org=20 > >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > >>Sent: Sunday, May 08, 2005 10:24 AM > >>To: netconf > >>Subject: More confirmed-commit issues > >> > >>Hi, > >> > >>IMO, PROT, section 8.4 is not very clear what happens > >>if locking is not used, or if the manager doesn't follow > >>the elements of procedure that the document suggests. > >> > >>If a confirmed-commit timeout is pending, and the > >>config is modified again before the 2nd or the timeout > >>occurs, how does the agent interpret the that is intended > >>to be for the newly modified ? What exactly is the the > >>contents of after the confirm-commit timer pops? > >>What if the 2nd commit is also a confirmed-commit? What if > >>time(C2) < timer(C1)? How come a manager cannot cancel a confirmed > >>commit (after commit-1 but before the timeout)? > >> > >>Note that this corner-case can occur naturally if locking is not=20 > >>properly used, > >>or pathologically, if the manager holding the locks writes to the=20 > >> > >>before finishing the first confirmed commit. (E.g., operator=20 > >>forgets a line > >>of config -- adds it -- commits it.) > >> > >>The vague warning about "use locks properly" (8.4.1, para 2) is not=20 > >>relevant > >>to agent implementers who have to make this work even if=20 > >>locking isn't=20 > >>used, > >>used wrong, or the manager doesn't follow the implied=20 > >>transaction model. > >> > >>I would also like to note that the #rollback feature was=20 > >>thrown out because > >>of these same corner-cases, that (IMO) are neither explained=20 > >>or properly=20 > >>handled > >>in the current draft as they relate to the #candidate and =20 > >>#confirmed-commit > >>capabilities. > >> > >>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: > >> > >> =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: From owner-netconf@ops.ietf.org Wed May 18 14:26:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21053 for ; Wed, 18 May 2005 14:26:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYT5t-0007Qw-TV for netconf-data@psg.com; Wed, 18 May 2005 18:16:33 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DYT5q-0007QN-L1 for netconf@ops.ietf.org; Wed, 18 May 2005 18:16:30 +0000 Received: (qmail 29372 invoked by uid 78); 18 May 2005 14:29:39 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 18 May 2005 14:29:39 -0000 Message-ID: <428B5151.1080902@andybierman.com> Date: Wed, 18 May 2005 07:29:37 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: netconf Subject: Re: More confirmed-commit issues References: <062B922B6EC55149B5A267ECE78E5D440A0038C4@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440A0038C4@photon.jnpr.net> 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.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 Rob Enns wrote: >Hi, comments below. > > ditto > > >>-----Original Message----- >>From: Andy Bierman [mailto:ietf@andybierman.com] >>Sent: Saturday, May 14, 2005 5:13 AM >>To: Rob Enns >>Cc: netconf >>Subject: Re: More confirmed-commit issues >> >>Rob Enns wrote: >> >> >> >>>How does this replacement text sound? >>> >>>---- >>>8.4 Confirmed Commit Capability >>> >>>8.4.1 Description >>> >>> The #confirmed-commit capability indicates that the server will >>> support the and parameters for the >>> protocol operation. See section Section 8.3 for further >>> details on the operation. >>> >>> A confirmed commit operation MUST be reverted if a >>> >>> >>follow-up commit >> >> >>> (called the "confirming commit") is not issued within 600 >>> >>> >>seconds (10 >> >> >>> minutes). The timeout period can be adjusted with the >> timeout> element. The confirming commit can itself include a >>> parameter. >>> >>> >>> >>> >>This last sentence is confusing to me. It makes sense if the >> contains >>new changes and the 2nd confirmed commit starts a new "revert >>timeout" >>for these >>new changes. >> >> > >That's the intent. I mention it here only to indicate that the >confirming commit is not magic, it's a regular commit that could >itself be confirmed or make additional changes. > > ok > > >>I really don't like the possible side effects from this confirmed >>commit, especially with our >>shared and global locking. If you don't maintain the >>session and hold the >>lock throughout the entire double commit, really bad things >>can happen. >> >> (NEW ISSUE: What happens to a confirmed commit in progress if the >>session is lost >> or the agent reboots?) >> >> To confirm the above issues: If the session doing the confirmed commit is lost, the confirmed commit continues. If the agent reboots in the middle of a confirmed commit, I assume the box boots with the new config, so an agent reboot acts like a 2nd commit. Yuch. Or does the agent remember that a revert timeout was pending? If the timer doesn't survive, and the first commit CAUSED the reboot, isn't this device in an endless reboot loop? If the crash happens in the startup sequence, before the timer can pop, it's in an endless reboot loop anyway. >> T0 - boot with baseline config >> Tc - Manager A issues a confirmed commit, w/ revert to >>baseline at Tc+i >> Tc+1 - Manager A loses its connection and session >> Tc+10 - Manager B has no idea Manager A did this, comes >>along, gets the >>lock, >> and starts writing to the config, which >>starts with the contents >> of at time Tc >>Tc+20 - Then Manager A comes back and can't get a lock >>Tc+i - Manager A's revert timer pops before Manager B is done >> The agent reverts the state of to T0. (But B >>thinks the >> state of is Tc). >> >>At this point, it depends on the difference between config T0 >>and Tc, and >>what Manager B is doing, as to whether benign or devastating effects >>will follow. >> >>It's never a good thing to design this much "astonishment" >>into routing >>products. >>At a minimum, we need to document what happens in as many >>corner cases as >>we can think of, but we should also try to respect the principle of >>least astonishment. >> >> > >I don't view this as astonishing, or a side effect. It's very >simple: when the timer pops from a confirmed commit, the device >will revert to the T0 configuration. I'd argue that it's the kind >of easy to understand basic behavior that operators like. > > It is astonishing to Mgr B who has no way of knowing a revert timeout is pending. To me, the whole thing is just fragile. IMO, a configuration protocol should be robust, not fragile. A protocol that can allow the possibility of severely detrimental config changes (through unintended or malicious acts), by merely dropping a connection, is fragile. It's possible the security AD could have a problem with this too, during the IESG review. > > > >>> If a confirming commit is not issued, the device will revert it's >>> configuration to the state prior to the issuance of the confirmed >>> commit. Note that any commit operation, including a commit which >>> introduces additional changes to the configuration, will >>> >>> >>serve as a >> >> >>> confirming commit. Thus to cancel a confirmed commit and revert >>> changes without waiting for the confirm timeout to expire, the >>> confirming commit can explicitly restore the configuration to it's >>> state before the confirmed commit was issued. >>> >>> >>> >>> >>I don't understand this last sentence, and this revert >>operation at all. >> >> > >This is in reponse to your comment about how the configuration would >be reverted before the timer pops. We can't use the rollback operation >to explain it, because netconf doesn't have one at this point. I could >remove that text completely if it's confusing. > > The fact that you have a rollback operation in Junoscript doesn't really apply to this document. The sentence doesn't convey the idea that the confirmed commit can be canceled through proprietary mechanisms, outside the scope of the standard. IMO, we need to remove this sentence since there is no rollback operation in netconf. In fact, we should say instead that netconf provides no mechanism to force the agent to cancel the confirmed commit and revert the configuration. The manager has to wait for the timeout interval to pass. BTW, the phrase "the confirming commit can explicitly restore the configuration" doesn't really make sense. s/confirming commit/manager/ and it does. > > >>BTW, s/it's/its/ in both paragraphs above. >> >> > >Quite right, thanks. > >Rob > > > 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 May 18 14:28:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21284 for ; Wed, 18 May 2005 14:28:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYTAa-0007ih-Q0 for netconf-data@psg.com; Wed, 18 May 2005 18:21:24 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DYTAY-0007iS-IA for netconf@ops.ietf.org; Wed, 18 May 2005 18:21:22 +0000 Received: (qmail 15822 invoked by uid 78); 18 May 2005 14:59:41 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 18 May 2005 14:59:41 -0000 Message-ID: <428B585C.7030403@andybierman.com> Date: Wed, 18 May 2005 07:59:40 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "'Scott Hollenbeck'" , "'tbray@textuality.com'" , "Simon Leinen (E-mail)" , "'David Kessens'" , netconf Subject: Re: [xml-dir] request review of NETCONF protocol References: <7D5D48D2CAA3D84C813F5B154F43B15506AD77B6@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15506AD77B6@nl0006exch001u.nl.lucent.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.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 Wijnen, Bert (Bert) wrote: >Thanks Scott, I did also see it on xml-dir list. > >Thanks to the reviewer Tim Bray. > >I am assuming that WG chairs will follow up on this. > > Here is a summary of the issues raised in Tim's review: ============================================================ 1. term API [mildly humorous]: When we chartered the Atompub WG, we were told sternly that we had to call it the Atom Publishing Protocol because "The IETF doesn't do APIs." Response: The protocol isn't an API -- it provides operations to manipulate configuration datastores, which allows for a programmatic interface to be layered on top. Such an API will likely impose additional structure and semantics (meta-schema and data models) on the XML payloads in NETCONF PDUs. NETCONF simply requires a well-formed XML payload. between a manager and agent. I guess this paragraph should be more clear. ============================== 3.1, 3.2 : URN and DTD clarifications Response: Editor will fix the text ============================== 4.1: XML Encoding Issues When implementing XML processing software, it is advantageous if the set of element and attribute is fixed, and known in advance. This allows them to be predeclared as fixed readonly constants. NETCONF encodes method and argument names as element names, which is very unconventional. While not illegal, it does fly in the face of the common vocabulary design idiom for this kind of situation. Here's the example from 4.1 27606-0100 Most other similar XML vocabularies look like this: 276-0100 or 27606-0100 (the latter if you have a one-method-per-RPC constraint) Response: I think this came from Junoscript, and I don't think this issue was ever seriously discussed. Phil Shafer is also on xml-dir, and he strongly advocated this approach. One example that was discussed at length was the parameter. Many people suggested simple strings (e.g., "candidate" or "running") instead of element names. I think Phil convinced the WG this element name approach was better. I personally don't know how much complexity this adds to implementations or the importance of this XML style guideline. ** Needs more discussion. ============================== I'm also troubled that NETCONF reserves the element "" (and a bunch of others, see section 7...) so nobody defining their own methods can define one named "get". This means that it's going to be really tough to extend NETCONF in future with new built-in methods because various devices out there may have taken those names. More broadly, it's somewhat troubling that there's no method of disambiguating, not only between between NETCONF-defined and device-defined names, but between different devices' methods. That is to say, there can be an arbitrary number of "rock-the-vote" methods out there in the network... network-management-system DBMS management might be easy if NETCONF provided a built-in way to disambiguate between these methods. (Mind you, the fact that I don't know the NETCONF application is probably showing). Response: There is the namespace to differentiate method names. The NETCONF protocol has a fixed set of methods in the NETCONF namespace. The document is confusing because it calls standard methods "protocol operations", but conceptually they are no different than the "rock-the-house" type of , which is called a method in the draft. ==================================== [section 7.1, but it's related. See the example at the bottom of p. 33; it's perfectly reasonable to have a chunk of device-specific XML in the answer to a query, but most XML language designers would require that it be in a different namespace, which would also sove the disambiguation problems.] Response: The configuration data models are intended to be in a different namespace than the NETCONF protocol. In this example it is http://example.com/schema/1.2/config. ==================================== 4.2 - the element which appears here is not specified until section 7, a couple dozen pages later. 4.3 - similar contents for things like the content of , how to maintain collisions between NETCONF-defined and device-defined content? 6.1 it says "XML subtree filtering is a mechanism that allows an application to select particular XML subtrees ". XML subtrees of what? I was genuinely baffled. Then I guessed that the configuration datastores introduced in section 5 are in fact XML constructs and you're selecting out of them? Or am I wrong. Anyhow, some context is badly needed. Response: We will try to add clarifying text to provide better context. ====================================== If this were the W3C, this whole subtree-filtering section would be bounced instantly on the grounds that it seems to be re-inventing XPath. Particularly since XPath is actually used in NETCONF, for in 4.3, and then there's a whole section 8.9. Maybe the requirements of this are app are such that it's sensible to re-invent something which has been widely implemented in a variety of free high-quality implementations in basically every computer language. Sorry, I decline to study the details of yet another XML tree extraction mechanism. This problem has been rather well solved, it escapes me why it needs to be done again. Suffice it to say that designing this kind of thing is hard and it is very easy to specify things that turn out to have unforeseen high cost to implement. Response: There doesn't seem to be agreement on xml-dir on this issue. (One of them probably designed it ;-) The WG compromise is to use both XPATH and this lightweight subtree thing. Many in the WG (including me) believe that in time, XPATH will not be a burden to implement in most embedded devices, and we can make it mandatory-to-implement instead of optional. ====================================== Grr... section 6.4.4, yes this really smells like a half-baked reinvention of XPath. Sorry for being rude in the case that I missed something obvious. Response: The section name is misleading because the subtree filter doesn't really select nodes the same way as XPATH. Summary: The point of this subtree filtering is to provide a very limited set of selection criteria. XPATH has way more features than our protocol requires. The WG was faced with essentially two choices: 1) adopt something else that meets our needs 2) standardize a specific subset of XPATH that meets our needs The WG debated both approaches extensively and decided on (1). ========================================== 7. It might be a good idea to reorder the doc and move this up above some other sections. Having read this, I now know the basic high-level shape of the dialogue, and this gives context to things like the element and the subtree filtering, that were introduced with no context. Purely editorial. seems way smoother than or, in the case where you can ask for more than one source: Response: I don't see a lot of agreement on this point. In fact, most of the XML experts I know are saying attributes are bad for parameters because of namespace issues and lack of extensibility. ======================================================= 7.2 same comments regarding - in this case the definition says that there's a single target, so why not use an attribute? Basically, the conventional wisdom is that XML markup should label something, i.e. say what it is, while names usually go in content or attribute values. Response: Again, I don't see agreement on xml-dir (or wider consensus) that we should make more extensive use of attributes instead of elements. ======================================================== There are a couple of problems with the URN+#+name naming scheme in section 8. To start with, per RFC 2141, the #-fragment is not defined for URNs, in fact there's a SHOULD NOT. Second, if you read 3986 and http://www.w3.org/TR/webarch, you'll discover that there's a lot of weirdness around #-fragments. To start with, in principle URIs can be dereferenced, and the semantics of the #-fragment depend on the media type of what you get back. Blecch. It also occurs to me that if I were a device manufacturer and I wanted to publish device capabilities, I might want to name them with HTTP URIs so that you can actually dereference them to get details on the capability. In which case the #-fragment is even more troubling. Response: The vendors are allowed to use friendly HTTP URIs. We had that for netconf as well, but were told we were in violation of some RFC because we didn't have extremely verbose cryptic URNs instead (so we changed it). I don't care what the string is -- I just want the XML experts to agree on something, or agree it's not worth worrying about. =================================================== thanks, 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 May 18 15:45:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29656 for ; Wed, 18 May 2005 15:45:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYUJF-000CXJ-Sq for netconf-data@psg.com; Wed, 18 May 2005 19:34:25 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYUJF-000CX6-4E for netconf@ops.ietf.org; Wed, 18 May 2005 19:34:25 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 18 May 2005 12:34:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="306287113:sNHT24058336" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 12:34:24 -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: More confirmed-commit issues Date: Wed, 18 May 2005 12:33:53 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440A003995@photon.jnpr.net> Thread-Topic: More confirmed-commit issues Thread-Index: AcVbtgqYzCRosG2/SbaEoebYFmlIyAAJ34zg From: "Rob Enns" To: "Andy Bierman" Cc: "netconf" X-OriginalArrivalTime: 18 May 2005 19:34:24.0609 (UTC) FILETIME=[98E84D10:01C55BE0] 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 > >> (NEW ISSUE: What happens to a confirmed commit in progress if the=20 > >>session is lost > >> or the agent reboots?) >=20 > To confirm the above issues: >=20 > If the session doing the confirmed commit is lost, the=20 > confirmed commit=20 > continues. >=20 > If the agent reboots in the middle of a confirmed commit, I=20 > assume the=20 > box boots > with the new config, so an agent reboot acts like a 2nd=20 > commit. Yuch. =20 > Or does > the agent remember that a revert timeout was pending? If the=20 > timer doesn't > survive, and the first commit CAUSED the reboot, isn't this=20 > device in an > endless reboot loop? If the crash happens in the startup sequence,=20 > before the > timer can pop, it's in an endless reboot loop anyway. I think there are 2 cases here: 1) intentional reboot -> if an operator intentionally reboots the box in the middle of the confirmed commit, I'd say that effectively confirms the commit, and we should explicitly mention=20 this case in the protocol spec. 2) unintentional reboot (aka bug) -> we can't standardize what netconf does in this case, right? > >> T0 - boot with baseline config > >> Tc - Manager A issues a confirmed commit, w/ revert to=20 > >>baseline at Tc+i > >> Tc+1 - Manager A loses its connection and session > >> Tc+10 - Manager B has no idea Manager A did this, comes=20 > >>along, gets the=20 > >>lock, > >> and starts writing to the config, which =20 > >>starts with the contents > >> of at time Tc > >>Tc+20 - Then Manager A comes back and can't get a lock > >>Tc+i - Manager A's revert timer pops before Manager B is done > >> The agent reverts the state of to T0. (But B=20 > >>thinks the > >> state of is Tc). > >> > >>At this point, it depends on the difference between config T0=20 > >>and Tc, and > >>what Manager B is doing, as to whether benign or=20 > devastating effects=20 > >>will follow. > >> > >>It's never a good thing to design this much "astonishment"=20 > >>into routing=20 > >>products. > >>At a minimum, we need to document what happens in as many=20 > >>corner cases as > >>we can think of, but we should also try to respect the principle of=20 > >>least astonishment. > >> =20 > >> > > > >I don't view this as astonishing, or a side effect. It's very > >simple: when the timer pops from a confirmed commit, the device > >will revert to the T0 configuration. I'd argue that it's the kind > >of easy to understand basic behavior that operators like. > > =20 > > > It is astonishing to Mgr B who has no way of knowing a revert > timeout is pending. To me, the whole thing is just fragile.=20 > IMO, a configuration protocol should be robust, not fragile. I don't think it's fragile. The problem in this scenario is that Mgr A and Mgr B don't know what each other are doing. We can't standardize a way out of badly managed networks. > A protocol that can allow the possibility of severely detrimental > config changes (through unintended or malicious acts), by merely > dropping a connection, is fragile. Why would reverting to the T0 configuration, which is both what Mgr A wanted to do, and what the device was running before, be severely detrimental? We can sit around making up corner cases where Mgr A and Mgr B don't know what each other are doing, that's easy to do and not very productive. There's no way the device ends up with a sane configuration at the end of the day using _any_ configuration method, if the entities doing the configuration aren't coordinated.=20 The question is, what's the risk/reward of standardizing a feature like confirmed commit. The risk is that operators that aren't aware that a confirmed commit is underway could lose changes. The reward is that we have a standardized way to protect against devices falling off the network due to a change. IMO there a very clear benefit which outweighs the risk. And the risk is explicitly identified in the=20 protocol document. > It's possible the security AD could have a problem with this too, > during the IESG review. > > >>> If a confirming commit is not issued, the device will revert it's > >>> configuration to the state prior to the issuance of the confirmed > >>> commit. Note that any commit operation, including a commit which > >>> introduces additional changes to the configuration, will=20 > >>> =20 > >>> > >>serve as a > >> =20 > >> > >>> confirming commit. Thus to cancel a confirmed commit and revert > >>> changes without waiting for the confirm timeout to expire, the > >>> confirming commit can explicitly restore the=20 > configuration to it's > >>> state before the confirmed commit was issued. > >>>=20 > >>> > >>> =20 > >>> > >>I don't understand this last sentence, and this revert=20 > >>operation at all. > >> =20 > >> > > > >This is in reponse to your comment about how the configuration would > >be reverted before the timer pops. We can't use the rollback=20 > operation > >to explain it, because netconf doesn't have one at this=20 > point. I could > >remove that text completely if it's confusing. > > =20 > > > The fact that you have a rollback operation in Junoscript=20 > doesn't really > apply to this document. The sentence doesn't convey the idea that the > confirmed commit can be canceled through proprietary=20 > mechanisms, outside > the scope of the standard.=20 Sorry for the confusion, that's not what this is saying. The point is=20 that one can use netconf as specified to restore the configuration=20 using edit-config. It has nothing to do with a proprietary mechanism. > IMO, we need to remove this sentence since there is no rollback=20 > operation in netconf. > In fact, we should say instead that netconf provides no mechanism to=20 > force the > agent to cancel the confirmed commit and revert the =20 > configuration. > The manager has to wait for the timeout interval to pass. That's not true. Either way the cancel/revert is a manager initiated action. It's a little clunky for the manager to restore the configuration using edit-config, but it works. This seems to be causing confusion so I can remove it, but I don't think it's accurate to say that netconf provides no mechanism to revert the running configuration. It provides edit-config, which is awkward (because the manager has to have the configuration in hand) but works. > BTW, the phrase "the confirming commit can explicitly restore the=20 > configuration" > doesn't really make sense. s/confirming commit/manager/ and it does. Yes, that sounds good, thanks. Rob -- 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 May 18 16:51:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19035 for ; Wed, 18 May 2005 16:51:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYVNx-000HKh-Rh for netconf-data@psg.com; Wed, 18 May 2005 20:43:21 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYVNv-000HKP-Ug for netconf@ops.ietf.org; Wed, 18 May 2005 20:43:19 +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 j4IKhCYo003744; Wed, 18 May 2005 13:43:12 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 May 2005 13:43:12 -0700 Message-ID: From: "McDonald, Ira" To: "'Rob Enns'" , Andy Bierman Cc: netconf Subject: RE: More confirmed-commit issues Date: Wed, 18 May 2005 13:43:10 -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, My two cents - if a session/connection breaks before a commit, then rollback to previous/current config MUST happen as a hard requirement of NetConf. The idea that Manager B gets (all unknowing) the loose ends from Manager A's previous session will _never_ get past IESG Security review. 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 Rob Enns > Sent: Wednesday, May 18, 2005 3:34 PM > To: Andy Bierman > Cc: netconf > Subject: RE: More confirmed-commit issues > > > > >> (NEW ISSUE: What happens to a confirmed commit in > progress if the > > >>session is lost > > >> or the agent reboots?) > > > > To confirm the above issues: > > > > If the session doing the confirmed commit is lost, the > > confirmed commit > > continues. > > > > If the agent reboots in the middle of a confirmed commit, I > > assume the > > box boots > > with the new config, so an agent reboot acts like a 2nd > > commit. Yuch. > > Or does > > the agent remember that a revert timeout was pending? If the > > timer doesn't > > survive, and the first commit CAUSED the reboot, isn't this > > device in an > > endless reboot loop? If the crash happens in the startup sequence, > > before the > > timer can pop, it's in an endless reboot loop anyway. > > I think there are 2 cases here: > 1) intentional reboot > -> if an operator intentionally reboots the box in the > middle of the confirmed commit, I'd say that effectively > confirms the commit, and we should explicitly mention > this case in the protocol spec. > > 2) unintentional reboot (aka bug) > -> we can't standardize what netconf does in this case, right? > > > > > >> T0 - boot with baseline config > > >> Tc - Manager A issues a confirmed commit, w/ revert to > > >>baseline at Tc+i > > >> Tc+1 - Manager A loses its connection and session > > >> Tc+10 - Manager B has no idea Manager A did this, comes > > >>along, gets the > > >>lock, > > >> and starts writing to the > config, which > > >>starts with the contents > > >> of at time Tc > > >>Tc+20 - Then Manager A comes back and can't get a lock > > >>Tc+i - Manager A's revert timer pops before Manager B is done > > >> The agent reverts the state of to > T0. (But B > > >>thinks the > > >> state of is Tc). > > >> > > >>At this point, it depends on the difference between config T0 > > >>and Tc, and > > >>what Manager B is doing, as to whether benign or > > devastating effects > > >>will follow. > > >> > > >>It's never a good thing to design this much "astonishment" > > >>into routing > > >>products. > > >>At a minimum, we need to document what happens in as many > > >>corner cases as > > >>we can think of, but we should also try to respect the > principle of > > >>least astonishment. > > >> > > >> > > > > > >I don't view this as astonishing, or a side effect. It's very > > >simple: when the timer pops from a confirmed commit, the device > > >will revert to the T0 configuration. I'd argue that it's the kind > > >of easy to understand basic behavior that operators like. > > > > > > > > It is astonishing to Mgr B who has no way of knowing a revert > > timeout is pending. To me, the whole thing is just fragile. > > IMO, a configuration protocol should be robust, not fragile. > > I don't think it's fragile. The problem in this scenario is that > Mgr A and Mgr B don't know what each other are doing. We can't > standardize a way out of badly managed networks. > > > A protocol that can allow the possibility of severely detrimental > > config changes (through unintended or malicious acts), by merely > > dropping a connection, is fragile. > > Why would reverting to the T0 configuration, which is both what Mgr A > wanted to do, and what the device was running before, be severely > detrimental? > > We can sit around making up corner cases where Mgr A and Mgr B don't > know what each other are doing, that's easy to do and not very > productive. There's no way the device ends up with a sane > configuration > at the end of the day using _any_ configuration method, if > the entities > doing the configuration aren't coordinated. > > The question is, what's the risk/reward of standardizing a feature > like confirmed commit. The risk is that operators that aren't aware > that a confirmed commit is underway could lose changes. The reward is > that we have a standardized way to protect against devices falling > off the network due to a change. IMO there a very clear benefit which > outweighs the risk. And the risk is explicitly identified in the > protocol document. > > > It's possible the security AD could have a problem with this too, > > during the IESG review. > > > > >>> If a confirming commit is not issued, the device will > revert it's > > >>> configuration to the state prior to the issuance of > the confirmed > > >>> commit. Note that any commit operation, including a > commit which > > >>> introduces additional changes to the configuration, will > > >>> > > >>> > > >>serve as a > > >> > > >> > > >>> confirming commit. Thus to cancel a confirmed commit > and revert > > >>> changes without waiting for the confirm timeout to expire, the > > >>> confirming commit can explicitly restore the > > configuration to it's > > >>> state before the confirmed commit was issued. > > >>> > > >>> > > >>> > > >>> > > >>I don't understand this last sentence, and this revert > > >>operation at all. > > >> > > >> > > > > > >This is in reponse to your comment about how the > configuration would > > >be reverted before the timer pops. We can't use the rollback > > operation > > >to explain it, because netconf doesn't have one at this > > point. I could > > >remove that text completely if it's confusing. > > > > > > > > The fact that you have a rollback operation in Junoscript > > doesn't really > > apply to this document. The sentence doesn't convey the > idea that the > > confirmed commit can be canceled through proprietary > > mechanisms, outside > > the scope of the standard. > > Sorry for the confusion, that's not what this is saying. The point is > that one can use netconf as specified to restore the configuration > using edit-config. > > It has nothing to do with a proprietary mechanism. > > > IMO, we need to remove this sentence since there is no rollback > > operation in netconf. > > In fact, we should say instead that netconf provides no > mechanism to > > force the > > agent to cancel the confirmed commit and revert the > > configuration. > > The manager has to wait for the timeout interval to pass. > > That's not true. Either way the cancel/revert is a manager initiated > action. It's a little clunky for the manager to restore the > configuration > using edit-config, but it works. This seems to be causing confusion > so I can remove it, but I don't think it's accurate to say > that netconf > provides no mechanism to revert the running configuration. It provides > edit-config, which is awkward (because the manager has to have the > configuration in hand) but works. > > > BTW, the phrase "the confirming commit can explicitly restore the > > configuration" > > doesn't really make sense. s/confirming commit/manager/ and it does. > > Yes, that sounds good, thanks. > > Rob > > -- > 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 May 18 17:06:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20571 for ; Wed, 18 May 2005 17:06:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYVf7-000Irq-PB for netconf-data@psg.com; Wed, 18 May 2005 21:01:05 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYVf5-000IrU-QO for netconf@ops.ietf.org; Wed, 18 May 2005 21:01:03 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 18 May 2005 14:01:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="306521650:sNHT26081420" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 14:01:03 -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: More confirmed-commit issues Date: Wed, 18 May 2005 14:00:30 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440A0039B5@photon.jnpr.net> Thread-Topic: More confirmed-commit issues Thread-Index: AcVb6kNJi85KFKPbS2yQEjabP5bBJQAAaqmw From: "Rob Enns" To: "McDonald, Ira" , "Andy Bierman" Cc: "netconf" X-OriginalArrivalTime: 18 May 2005 21:01:03.0238 (UTC) FILETIME=[B3882260:01C55BEC] 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, >=20 > My two cents - if a session/connection breaks before > a commit, then rollback to previous/current config > MUST happen as a hard requirement of NetConf. Thanks Ira. I think this is a good way to address the issue. If the session is terminated for any reason before the commit is confirmed, the previous config is restored immediately. Rob > The idea that Manager B gets (all unknowing) the > loose ends from Manager A's previous session will > _never_ get past IESG Security review. >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org]On > > Behalf Of Rob Enns > > Sent: Wednesday, May 18, 2005 3:34 PM > > To: Andy Bierman > > Cc: netconf > > Subject: RE: More confirmed-commit issues > >=20 > >=20 > > > >> (NEW ISSUE: What happens to a confirmed commit in=20 > > progress if the=20 > > > >>session is lost > > > >> or the agent reboots?) > > >=20 > > > To confirm the above issues: > > >=20 > > > If the session doing the confirmed commit is lost, the=20 > > > confirmed commit=20 > > > continues. > > >=20 > > > If the agent reboots in the middle of a confirmed commit, I=20 > > > assume the=20 > > > box boots > > > with the new config, so an agent reboot acts like a 2nd=20 > > > commit. Yuch. =20 > > > Or does > > > the agent remember that a revert timeout was pending? If the=20 > > > timer doesn't > > > survive, and the first commit CAUSED the reboot, isn't this=20 > > > device in an > > > endless reboot loop? If the crash happens in the startup=20 > sequence,=20 > > > before the > > > timer can pop, it's in an endless reboot loop anyway. > >=20 > > I think there are 2 cases here: > > 1) intentional reboot > > -> if an operator intentionally reboots the box in the > > middle of the confirmed commit, I'd say that effectively > > confirms the commit, and we should explicitly mention=20 > > this case in the protocol spec. > >=20 > > 2) unintentional reboot (aka bug) > > -> we can't standardize what netconf does in this case, right? > >=20 > >=20 > >=20 > > > >> T0 - boot with baseline config > > > >> Tc - Manager A issues a confirmed commit, w/ revert to=20 > > > >>baseline at Tc+i > > > >> Tc+1 - Manager A loses its connection and session > > > >> Tc+10 - Manager B has no idea Manager A did this, comes=20 > > > >>along, gets the=20 > > > >>lock, > > > >> and starts writing to the =20 > > config, which =20 > > > >>starts with the contents > > > >> of at time Tc > > > >>Tc+20 - Then Manager A comes back and can't get a lock > > > >>Tc+i - Manager A's revert timer pops before Manager B is done > > > >> The agent reverts the state of to=20 > > T0. (But B=20 > > > >>thinks the > > > >> state of is Tc). > > > >> > > > >>At this point, it depends on the difference between config T0=20 > > > >>and Tc, and > > > >>what Manager B is doing, as to whether benign or=20 > > > devastating effects=20 > > > >>will follow. > > > >> > > > >>It's never a good thing to design this much "astonishment"=20 > > > >>into routing=20 > > > >>products. > > > >>At a minimum, we need to document what happens in as many=20 > > > >>corner cases as > > > >>we can think of, but we should also try to respect the=20 > > principle of=20 > > > >>least astonishment. > > > >> =20 > > > >> > > > > > > > >I don't view this as astonishing, or a side effect. It's very > > > >simple: when the timer pops from a confirmed commit, the device > > > >will revert to the T0 configuration. I'd argue that it's the kind > > > >of easy to understand basic behavior that operators like. > > > > =20 > > > > > > > It is astonishing to Mgr B who has no way of knowing a revert > > > timeout is pending. To me, the whole thing is just fragile.=20 > > > IMO, a configuration protocol should be robust, not fragile. > >=20 > > I don't think it's fragile. The problem in this scenario is that > > Mgr A and Mgr B don't know what each other are doing. We can't > > standardize a way out of badly managed networks. > >=20 > > > A protocol that can allow the possibility of severely detrimental > > > config changes (through unintended or malicious acts), by merely > > > dropping a connection, is fragile. > >=20 > > Why would reverting to the T0 configuration, which is both=20 > what Mgr A > > wanted to do, and what the device was running before, be severely > > detrimental? > >=20 > > We can sit around making up corner cases where Mgr A and Mgr B don't > > know what each other are doing, that's easy to do and not very > > productive. There's no way the device ends up with a sane=20 > > configuration > > at the end of the day using _any_ configuration method, if=20 > > the entities > > doing the configuration aren't coordinated.=20 > >=20 > > The question is, what's the risk/reward of standardizing a feature > > like confirmed commit. The risk is that operators that aren't aware > > that a confirmed commit is underway could lose changes. The=20 > reward is > > that we have a standardized way to protect against devices falling > > off the network due to a change. IMO there a very clear=20 > benefit which > > outweighs the risk. And the risk is explicitly identified in the=20 > > protocol document. > >=20 > > > It's possible the security AD could have a problem with this too, > > > during the IESG review. > > > > > > >>> If a confirming commit is not issued, the device will=20 > > revert it's > > > >>> configuration to the state prior to the issuance of=20 > > the confirmed > > > >>> commit. Note that any commit operation, including a=20 > > commit which > > > >>> introduces additional changes to the configuration, will=20 > > > >>> =20 > > > >>> > > > >>serve as a > > > >> =20 > > > >> > > > >>> confirming commit. Thus to cancel a confirmed commit=20 > > and revert > > > >>> changes without waiting for the confirm timeout to=20 > expire, the > > > >>> confirming commit can explicitly restore the=20 > > > configuration to it's > > > >>> state before the confirmed commit was issued. > > > >>>=20 > > > >>> > > > >>> =20 > > > >>> > > > >>I don't understand this last sentence, and this revert=20 > > > >>operation at all. > > > >> =20 > > > >> > > > > > > > >This is in reponse to your comment about how the=20 > > configuration would > > > >be reverted before the timer pops. We can't use the rollback=20 > > > operation > > > >to explain it, because netconf doesn't have one at this=20 > > > point. I could > > > >remove that text completely if it's confusing. > > > > =20 > > > > > > > The fact that you have a rollback operation in Junoscript=20 > > > doesn't really > > > apply to this document. The sentence doesn't convey the=20 > > idea that the > > > confirmed commit can be canceled through proprietary=20 > > > mechanisms, outside > > > the scope of the standard.=20 > >=20 > > Sorry for the confusion, that's not what this is saying.=20 > The point is=20 > > that one can use netconf as specified to restore the configuration=20 > > using edit-config. > >=20 > > It has nothing to do with a proprietary mechanism. > >=20 > > > IMO, we need to remove this sentence since there is no rollback=20 > > > operation in netconf. > > > In fact, we should say instead that netconf provides no=20 > > mechanism to=20 > > > force the > > > agent to cancel the confirmed commit and revert the =20 > > > configuration. > > > The manager has to wait for the timeout interval to pass. > >=20 > > That's not true. Either way the cancel/revert is a manager initiated > > action. It's a little clunky for the manager to restore the > > configuration > > using edit-config, but it works. This seems to be causing confusion > > so I can remove it, but I don't think it's accurate to say=20 > > that netconf > > provides no mechanism to revert the running configuration.=20 > It provides > > edit-config, which is awkward (because the manager has to have the > > configuration in hand) but works. > >=20 > > > BTW, the phrase "the confirming commit can explicitly restore the=20 > > > configuration" > > > doesn't really make sense. s/confirming commit/manager/=20 > and it does. > >=20 > > Yes, that sounds good, thanks. > >=20 > > Rob > >=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 >=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 May 18 17:08:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20772 for ; Wed, 18 May 2005 17:08:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYViF-000J9h-77 for netconf-data@psg.com; Wed, 18 May 2005 21:04:19 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYViD-000J9B-6k for netconf@ops.ietf.org; Wed, 18 May 2005 21:04:17 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id C1CC711D731; Wed, 18 May 2005 14:04:14 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Cc: Rob Enns , netconf Subject: Re: More confirmed-commit issues Organization: Sparta References: <062B922B6EC55149B5A267ECE78E5D440A0038C4@photon.jnpr.net> <428B5151.1080902@andybierman.com> Date: Wed, 18 May 2005 14:04:14 -0700 In-Reply-To: <428B5151.1080902@andybierman.com> (Andy Bierman's message of "Wed, 18 May 2005 07:29:37 -0700") 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 Andy> It is astonishing to Mgr B who has no way of knowing a revert Andy> timeout is pending. To me, the whole thing is just fragile. Andy> IMO, a configuration protocol should be robust, not fragile. Andy> A protocol that can allow the possibility of severely detrimental Andy> config changes (through unintended or malicious acts), by merely Andy> dropping a connection, is fragile. Andy> It's possible the security AD could have a problem with this Andy> too, during the IESG review. It's in line with all the other similar problems I've already expressed so I wasn't going to bring it up. confirmed-commits actually exasperate something that already exists in the global-config-store and locking problems. Previously it was acknowledged that you should always use locks to avoid multiple people modifying parts of the config at the same time when all of a sudden neither has the ability to actually perform a commit because the permissions of either don't include all the changes that would be required during the copy. With a confirmed commit if the locking session is lost intentionally or due to (potentially temporary) network issues caused by the commit a second user could actually come in, make a minor change to either running or candidate that would prevent the original person from being able to roll back in the first place. Since that was impossible to follow in text: X = 1 Y = 1 A can modify X but not Y B can modify Y but not X A locks candidate A locks running A changes X=2 in candidate A issues confirming commit, timeout = 60 A's session closes, losing both locks B opens session B modifies Y=2 in running B closes session A does *not* send a confirm At commit-time + 60, the box should revert running to X=1 Y=1 but can't because A doesn't have permission to change from current Y=2 to Y=1. Discussion of multiple overlapping confirming-commits left to the reader. One alternative is to say that locks last even beyond the session closure until the confirmed commit timer is finished. That has other ramifications too, but probably less-so. I've said before that the notion of shared scratch spaces really makes the protocol a root-only kind of protocol. Many of these security problems would go away if things were done via "delta"s instead of all-or-nothing from a shared space. -- "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 Thu May 19 00:52:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29052 for ; Thu, 19 May 2005 00:52:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYcsQ-000MUc-8Y for netconf-data@psg.com; Thu, 19 May 2005 04:43:18 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYX59-000Oby-V2 for netconf@ops.ietf.org; Wed, 18 May 2005 22:32:04 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 May 2005 15:31:49 -0700 X-IronPort-AV: i="3.93,119,1115017200"; d="scan'208"; a="266927533:sNHT898921926" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4IMVePo000769 for ; Wed, 18 May 2005 15:31:46 -0700 (PDT) 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); Thu, 19 May 2005 06:31:39 +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: consecutive locks on the same session Date: Thu, 19 May 2005 06:31:37 +0800 Message-ID: Thread-Topic: consecutive locks on the same session Thread-Index: AcVbbHEVJHfmHJqoSpuPsO+3A93kPwAUc2JgAA7BPcA= From: "James Balestriere \(jbalestr\)" To: X-OriginalArrivalTime: 18 May 2005 22:31:40.0069 (UTC) FILETIME=[5C22B550:01C55BF9] 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 =20 if a session does a lock and it gets the lock we send ok. if it does a lock again whilst it still has the lock, does it=20 get an error or ok ? =20 I am suspecting we send ok but it is not very clear from the spec. =20 James. =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 May 19 00:56:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29371 for ; Thu, 19 May 2005 00:56:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYd0D-000N4x-5h for netconf-data@psg.com; Thu, 19 May 2005 04:51:21 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYd0B-000N4a-Gp for netconf@ops.ietf.org; Thu, 19 May 2005 04:51:19 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 705A211D739; Wed, 18 May 2005 21:51:15 -0700 (PDT) From: Wes Hardaker To: "Rob Enns" Cc: "McDonald, Ira" , "Andy Bierman" , "netconf" Subject: Re: More confirmed-commit issues Organization: Sparta References: <062B922B6EC55149B5A267ECE78E5D440A0039B5@photon.jnpr.net> Date: Wed, 18 May 2005 21:51:14 -0700 In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440A0039B5@photon.jnpr.net> (Rob Enns's message of "Wed, 18 May 2005 14:00:30 -0700") 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 Rob> Thanks Ira. I think this is a good way to address the issue. Rob> If the session is terminated for any reason before the commit Rob> is confirmed, the previous config is restored immediately. That's a good solution too, though it leaves problems when a session may break because of the changes in question. Or changes to a device in between... But I think there isn't much choice. -- "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 Thu May 19 11:56:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19126 for ; Thu, 19 May 2005 11:56:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYnBV-000D88-Ru for netconf-data@psg.com; Thu, 19 May 2005 15:43:41 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DYnBU-000D7m-0z for netconf@ops.ietf.org; Thu, 19 May 2005 15:43:40 +0000 Received: (qmail 29600 invoked by uid 78); 19 May 2005 15:43:38 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 19 May 2005 15:43:38 -0000 Message-ID: <428CB429.7050708@andybierman.com> Date: Thu, 19 May 2005 08:43:37 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: netconf Subject: Re: More confirmed-commit issues References: <062B922B6EC55149B5A267ECE78E5D440A003995@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440A003995@photon.jnpr.net> 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.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 Rob Enns wrote: >>>> (NEW ISSUE: What happens to a confirmed commit in progress if the >>>>session is lost >>>> or the agent reboots?) >>>> >>>> >>To confirm the above issues: >> >>If the session doing the confirmed commit is lost, the >>confirmed commit >>continues. >> >>If the agent reboots in the middle of a confirmed commit, I >>assume the >>box boots >>with the new config, so an agent reboot acts like a 2nd >>commit. Yuch. >>Or does >>the agent remember that a revert timeout was pending? If the >>timer doesn't >>survive, and the first commit CAUSED the reboot, isn't this >>device in an >>endless reboot loop? If the crash happens in the startup sequence, >>before the >>timer can pop, it's in an endless reboot loop anyway. >> >> > >I think there are 2 cases here: >1) intentional reboot >-> if an operator intentionally reboots the box in the >middle of the confirmed commit, I'd say that effectively >confirms the commit, and we should explicitly mention >this case in the protocol spec. > >2) unintentional reboot (aka bug) >-> we can't standardize what netconf does in this case, right? > > no -- we can standardize what happens for a reboot of any reason. I don't agree with (1) above, because an attacker without any account access at all can effectively issue a operation by getting the device to reboot at the right time. IMO, the device should be required to save a boolean flag in NV-store that will tell the agent to revert to the last config before booting, which is what we decided should happen if the session that did the first commit is lost. BTW, this also helps fix the new-config-causes-a-reboot looping problem. > >.... > >>> >>> >>It is astonishing to Mgr B who has no way of knowing a revert >>timeout is pending. To me, the whole thing is just fragile. >>IMO, a configuration protocol should be robust, not fragile. >> >> > >I don't think it's fragile. The problem in this scenario is that >Mgr A and Mgr B don't know what each other are doing. We can't >standardize a way out of badly managed networks. > > I totally disagree. Managers can use locks correctly, as designed, and config-changes can at least be properly serialized. We have a special case here. IMO, this confirmed-commit is the only part of the NETCONF protocol that can cause really bad scenarios even when Mgr A and Mgr B are both using locks correctly. (Wes will now tell me otherwise :-) No other NETCONF operation causes the agent to make "silent" changes to the config in the background. We didn't add because of the same serious multi-manager issues that plague confirmed-commit. Another concern: NETCONF locks are supposed to be short-lived, but the default timeout for this operation is 10 minutes! By design, Mgr A is supposed to stay logged in and hold a lock on for 10+ minutes in order for this operation to work in a multi-manager environment. I am strongly opposed to this feature "as-is" unless we make the following changes: 1) add the "confirmed-commit-in-progress" warning I proposed (or something like it) so other managers can at least know their changes may be clobbered by the agent at time T 2) automatically revert the config if the "committing" session is lost (WG consensus for this already) 3) automatically revert the config upon startup if the agent reboots for any reason while a revert-timeout is pending I think we should of had a "manual revert" operation all along (not a generalized rollback -- just the ability to cause the revert-timer to pop), but we don't. I suspect it will show up in various proprietary forms, and we can standardize it later. 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 Thu May 19 13:48:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28972 for ; Thu, 19 May 2005 13:48:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYoxA-000LI1-I2 for netconf-data@psg.com; Thu, 19 May 2005 17:37:00 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DYox9-000LHo-Pk for netconf@ops.ietf.org; Thu, 19 May 2005 17:37:00 +0000 Received: (qmail 14810 invoked by uid 78); 19 May 2005 17:36:59 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 19 May 2005 17:36:59 -0000 Message-ID: <428CCEBA.4070400@andybierman.com> Date: Thu, 19 May 2005 10:36:58 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: access control issues 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.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 Hi, I am somewhat concerned about the lack of specificity in the NETCONF protocol document regarding proper access control techniques. We can say when and where access control must be applied, without specifying an access control model. (IMO, without a model, we actually are choosing the "everybody has access to everything" model, which is known to be broken and obsolete.) The document should say somewhere that access control (i.e., user's ability to access specific portions of particular configurations in particular ways) MUST be enforced, and error(s) returned (if needed), instead of other protocol, rpc, or application errors, that would otherwise be returned. For example, a user shouldn't be able to issue a command on the , for config data for which that user has no access. As for Wes' multi-mgr w/o locking scenario (mgr A allowed to access "foo", mgr B allowed to access "bar"): IMO, together the shared is wedged. Neither A or B should be allowed to invoke ANY of NETCONF operations related to at this point -- not even in the strictest sense. (Locks are there for a reason -- use them or risk this outcome. ;-) 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 Thu May 19 16:22:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27171 for ; Thu, 19 May 2005 16:22:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYrPU-0007Oc-JK for netconf-data@psg.com; Thu, 19 May 2005 20:14:24 +0000 Received: from [207.217.121.170] (helo=pop-a065b10.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYrPQ-0007OE-QJ for netconf@ops.ietf.org; Thu, 19 May 2005 20:14:20 +0000 Received: from h-68-166-38-112.snvacaid.dynamic.covad.net ([68.166.38.112] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DYrPN-0002Ps-00 for netconf@ops.ietf.org; Thu, 19 May 2005 13:14:17 -0700 Message-ID: <005b01c55caf$b4962c60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "netconf" References: <428CCEBA.4070400@andybierman.com> Subject: Re: access control issues Date: Thu, 19 May 2005 13:16:56 -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, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Andy Bierman" > To: "netconf" > Sent: Thursday, May 19, 2005 10:36 AM > Subject: access control issues ... > The document should say somewhere that access control (i.e., user's > ability to access specific portions of particular configurations in > particular ways) MUST be enforced, and error(s) returned (if needed), > instead of other protocol, rpc, or application errors, that would > otherwise be returned. ... It sounds like this would be different from the SNMP approach, which doesn't leak information about the existence of objects to which access is denied when responding to a get/next/bulk request. Are you proposing that the error would identify the specific element(s) in the configuration to which access was denied, or would it be more of a blanket response that *something* *somewhere* in the request ran afoul of the rules? 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 Thu May 19 17:11:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01886 for ; Thu, 19 May 2005 17:11:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYsDt-000B4B-PD for netconf-data@psg.com; Thu, 19 May 2005 21:06:29 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DYsDi-000B38-Ss for netconf@ops.ietf.org; Thu, 19 May 2005 21:06:19 +0000 Received: (qmail 12546 invoked by uid 78); 19 May 2005 21:06:17 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 19 May 2005 21:06:17 -0000 Message-ID: <428CFFC8.3080402@andybierman.com> Date: Thu, 19 May 2005 14:06:16 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: netconf Subject: Re: access control issues References: <428CCEBA.4070400@andybierman.com> <005b01c55caf$b4962c60$7f1afea9@oemcomputer> In-Reply-To: <005b01c55caf$b4962c60$7f1afea9@oemcomputer> 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.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 Randy Presuhn wrote: >Hi - > > > >>From: "Andy Bierman" >>To: "netconf" >>Sent: Thursday, May 19, 2005 10:36 AM >>Subject: access control issues >> >> >... > > >>The document should say somewhere that access control (i.e., user's >>ability to access specific portions of particular configurations in >>particular ways) MUST be enforced, and error(s) returned (if needed), >>instead of other protocol, rpc, or application errors, that would >>otherwise be returned. >> >> >... > >It sounds like this would be different from the SNMP approach, which >doesn't leak information about the existence of objects to which access >is denied when responding to a get/next/bulk request. Are you proposing >that the error would identify the specific element(s) in the configuration to >which access was denied, or would it be more of a blanket response that >*something* *somewhere* in the request ran afoul of the rules? > > the latter -- blanket response - a generic access-denied is fine. >Randy > > 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 May 19 18:56:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12583 for ; Thu, 19 May 2005 18:56:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYtrE-000I9k-6R for netconf-data@psg.com; Thu, 19 May 2005 22:51:12 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYtrA-000I9I-70 for netconf@ops.ietf.org; Thu, 19 May 2005 22:51:08 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 4A5DD11D8A5; Thu, 19 May 2005 15:51:04 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Cc: netconf Subject: Re: access control issues Organization: Sparta References: <428CCEBA.4070400@andybierman.com> Date: Thu, 19 May 2005 15:51:02 -0700 In-Reply-To: <428CCEBA.4070400@andybierman.com> (Andy Bierman's message of "Thu, 19 May 2005 10:36:58 -0700") 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 Thu, 19 May 2005 10:36:58 -0700, Andy Bierman said: Andy> I am somewhat concerned about the lack of specificity in the NETCONF Andy> protocol document regarding proper access control techniques. You may wish to look at the examples in the slides for in the proceedings that I bought up about this topic a while ago (San Diego). There are multiple oddities in processing access control that I think should be mentioned because they're not entirely obvious from reading the document. This was one such concern. The response to my presentation at the time was access control specifications were beyond scope. I'll certainly be happy if a discussion about access control requirements is put into the current document (not to define access control, but to define the requirements on future access control imposed by the current architecture). -- "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 Fri May 20 09:17:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12216 for ; Fri, 20 May 2005 09:17:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZ7CL-000Nqe-L1 for netconf-data@psg.com; Fri, 20 May 2005 13:05:53 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DZ7CL-000NqR-1o for netconf@ops.ietf.org; Fri, 20 May 2005 13:05:53 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 May 2005 06:05:52 -0700 X-IronPort-AV: i="3.93,123,1115017200"; d="scan'208"; a="267635602:sNHT31450920" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4KD5nPo019660; Fri, 20 May 2005 06:05:50 -0700 (PDT) Received: from [144.254.23.90] (dhcp-data-vlan10-23-90.cisco.com [144.254.23.90]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4KCsxP1020457; Fri, 20 May 2005 05:55:01 -0700 Message-ID: <428DE0AA.8020004@cisco.com> Date: Fri, 20 May 2005 15:05:46 +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: netconf Subject: Re: access control issues References: <428CCEBA.4070400@andybierman.com> In-Reply-To: <428CCEBA.4070400@andybierman.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116593702.444455"; x:"432200"; a:"rsa-sha1"; b:"nofws:924"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"TgkyPv5dCun3YLUdWY2aqy8kvqlnnjKyJPUzKR3eTKGqzk+PxU1m2d6aoJYXlLbP6ML5uLfr" "9PUdZ4UDUZDY4OMQJD6KIQbAqCs39loMeTo/fJ0srfkPDK9unnu+UWkDGnKZckQvWttnirrVlwL" "7dZIopMZKjrkgiSz15mWoTsI="; c:"Date: Fri, 20 May 2005 15:05:46 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: access control issues" 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy, Please see inline. Andy Bierman wrote: > We can say when and where access control must be applied, without > specifying an access control model. (IMO, without a model, we actually > are choosing the "everybody has access to everything" model, which > is known to be broken and obsolete.) Yes, but nobody is saying that. What we're saying is that we're not standardizing the model. Depending on who you are I might let you change an interface or not. I don't need to standardize a model to do that (although it may help from a robustness perspective). > > The document should say somewhere that access control (i.e., user's > ability to access specific portions of particular configurations in > particular ways) MUST be enforced, and error(s) returned (if needed), > instead of other protocol, rpc, or application errors, that would > otherwise be returned. > > For example, a user shouldn't be able to issue a command on > the , for config data for which that user has no access. Arguably a user shouldn't be able to a that was generated by a different user. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 20 11:21:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27973 for ; Fri, 20 May 2005 11:21:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZ9B8-0007Ag-Cc for netconf-data@psg.com; Fri, 20 May 2005 15:12:46 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DZ9B6-0007A4-Gw for netconf@ops.ietf.org; Fri, 20 May 2005 15:12:44 +0000 Received: (qmail 12467 invoked by uid 78); 20 May 2005 15:12:43 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 20 May 2005 15:12:43 -0000 Message-ID: <428DFE6A.9040002@andybierman.com> Date: Fri, 20 May 2005 08:12:42 -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: netconf Subject: Re: access control issues References: <428CCEBA.4070400@andybierman.com> <428DE0AA.8020004@cisco.com> In-Reply-To: <428DE0AA.8020004@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.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 Eliot Lear wrote: > Andy, > > Please see inline. > > Andy Bierman wrote: > >> We can say when and where access control must be applied, without >> specifying an access control model. (IMO, without a model, we actually >> are choosing the "everybody has access to everything" model, which >> is known to be broken and obsolete.) > > > Yes, but nobody is saying that. What we're saying is that we're not > standardizing the model. Depending on who you are I might let you > change an interface or not. I don't need to standardize a model to do > that (although it may help from a robustness perspective). Of course every vendor can do some different proprietary access control scheme. Or the IETF (or some other SDO) could develop a standard access control scheme for NETCONF. This is very coupled to the data modeling details, so it's out of our scope. For the document, (IMO) we just need to specify that (for security purposes) access control violations should cause application level errors to be suppressed in responses, which might otherwise reveal information about data models supported or instantiated by the device. It would also be nice to specify that portions of data models selected through filters for and , which cannot be returned because of insufficient access, are simply skipped in the retrieval process instead of causing an 'access-denied' error. The same is not true for of course. The command (as you mention below) is an interesting case. Should the agent skip over no-access data or abort with an access-denied error? IMO it should be an error, because if the works then a followup should work, but it won't in this case. > >> >> The document should say somewhere that access control (i.e., user's >> ability to access specific portions of particular configurations in >> particular ways) MUST be enforced, and error(s) returned (if needed), >> instead of other protocol, rpc, or application errors, that would >> otherwise be returned. >> >> For example, a user shouldn't be able to issue a command on >> the , for config data for which that user has no access. > > > Arguably a user shouldn't be able to a that was > generated by a different user. Well, technically, there should be an access-control model, and user X should only see the portions for which user X has been given read access. IMO, whether the data can be read should be based on the data itself, not who wrote it. The shared has a lot of problems, including this one. Note that the document (sec. 8.7) does not say that is affected by locking at all. We decided that and are not affected by locking, so by the same logic, neither is . > > Eliot 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 Fri May 20 12:51:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06093 for ; Fri, 20 May 2005 12:51:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZAZi-000DVo-8p for netconf-data@psg.com; Fri, 20 May 2005 16:42:14 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DZAZg-000DVa-Lu for netconf@ops.ietf.org; Fri, 20 May 2005 16:42:12 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 20 May 2005 09:42:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,123,1115017200"; d="scan'208"; a="311634179:sNHT21203396" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 09:42:11 -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: More confirmed-commit issues Date: Fri, 20 May 2005 09:41:37 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D440A003ABF@photon.jnpr.net> Thread-Topic: More confirmed-commit issues Thread-Index: AcVciY8L3D0f+YJdQMaX9u2ZbPle0wAz3Wyg From: "Rob Enns" To: "Andy Bierman" Cc: "netconf" X-OriginalArrivalTime: 20 May 2005 16:42:11.0495 (UTC) FILETIME=[DEB7BB70:01C55D5A] 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 > 1) add the "confirmed-commit-in-progress" warning I=20 > proposed (or something like it) so other managers can=20 > at least know their changes may be clobbered by the=20 > agent at time T This seems weak to me. The draft recommends that the lock be held, in which case other managers couldn't make changes during this window. One could argue for similar warnings in the case of a shared=20 candidate, or even a writable running configuration, given that=20 multiple managers can be making changes simultaneously. In other words, the automated restore that happens when an unconfirmed commit is reverted is no more surprising than another manager coming in and stomping on somebody's edits (candidate or not). I think the best way to solve this is with the lock, not by adding a warning message. > 2) automatically revert the config if the "committing" session is=20 > lost (WG consensus for this already) Change made. > 3) automatically revert the config upon startup if the agent reboots=20 > for any reason while a revert-timeout is pending Change made. Rob -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 20 13:12:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09321 for ; Fri, 20 May 2005 13:12:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZAxN-000Fei-3p for netconf-data@psg.com; Fri, 20 May 2005 17:06:41 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DZAxL-000FeO-CF for netconf@ops.ietf.org; Fri, 20 May 2005 17:06:39 +0000 Received: (qmail 21928 invoked by uid 78); 20 May 2005 17:06:38 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 20 May 2005 17:06:38 -0000 Message-ID: <428E191D.4030407@andybierman.com> Date: Fri, 20 May 2005 10:06: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: Rob Enns CC: netconf Subject: Re: More confirmed-commit issues References: <062B922B6EC55149B5A267ECE78E5D440A003ABF@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440A003ABF@photon.jnpr.net> 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.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 Rob Enns wrote: >> 1) add the "confirmed-commit-in-progress" warning I >>proposed (or something like it) so other managers can >>at least know their changes may be clobbered by the >>agent at time T >> >> > >This seems weak to me. The draft recommends that >the lock be held, in which case other managers couldn't make >changes during this window. > > This is only true now that we will revert automatically if Mgr A closes/loses its session. It does rely on Mgr A doing everything correctly. The warning should not be issued often if everything goes as planned. It's a warning not an error, so these operations still succeed. IMO, it's more robust to warn Mgr B about this unique situation. >One could argue for similar warnings in the case of a shared >candidate, or even a writable running configuration, given that >multiple managers can be making changes simultaneously. In other >words, the automated restore that happens when an unconfirmed >commit is reverted is no more surprising than another manager >coming in and stomping on somebody's edits (candidate or not). >I think the best way to solve this is with the lock, not by >adding a warning message. > > I think there should be a 'stomping-on-edits' warning too! :-; This protocol provides a programmatic interface for the benefit of operators. It may be easier on the agent developer not to bother with a warning, but it can help an application (and it's human operators) from potentially devastating consequences from a legal but not multi-manager friendly application. Remember -- use of locks is totally optional. To me it's no different than wanting my C compiler to tell me about suspicious uses of C language constructs. > > >> 2) automatically revert the config if the "committing" session is >>lost (WG consensus for this already) >> >> > >Change made. > > > >> 3) automatically revert the config upon startup if the agent reboots >>for any reason while a revert-timeout is pending >> >> > >Change made. > > >Rob > > > > 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 Sat May 21 12:23:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03646 for ; Sat, 21 May 2005 12:23:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZWbi-000PQb-LO for netconf-data@psg.com; Sat, 21 May 2005 16:13:46 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DZWbh-000PQM-QX for netconf@ops.ietf.org; Sat, 21 May 2005 16:13:46 +0000 Received: (qmail 5944 invoked by uid 78); 21 May 2005 16:13:41 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 21 May 2005 16:13:41 -0000 Message-ID: <428F5E33.7060802@andybierman.com> Date: Sat, 21 May 2005 09:13:39 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf CC: Rob Enns Subject: Re: More confirmed-commit issues References: <062B922B6EC55149B5A267ECE78E5D440A003ABF@photon.jnpr.net> <428E191D.4030407@andybierman.com> In-Reply-To: <428E191D.4030407@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.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 Andy Bierman wrote: > Rob Enns wrote: > >>> 1) add the "confirmed-commit-in-progress" warning I proposed (or >>> something like it) so other managers can at least know their changes >>> may be clobbered by the agent at time T >>> >> >> >> This seems weak to me. The draft recommends that >> the lock be held, in which case other managers couldn't make >> changes during this window. >> >> > > This is only true now that we will revert automatically if Mgr A > closes/loses > its session. It does rely on Mgr A doing everything correctly. The > warning > should not be issued often if everything goes as planned. It's a > warning not > an error, so these operations still succeed. IMO, it's more robust to > warn Mgr B about this unique situation. Another reason for the warning is that any manager can issue the 2nd , even if that manager is actually intending to do its own "regular" commit. I guess the warning isn't critical now that we've closed the 'dropped session' and 'reboot' holes, and changed the timeout units from minutes to seconds, so I'm not objecting to confirmed-commit anymore. Now it takes misuse to break things, instead of natural events like lost connections and reboots. 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 Mon May 23 11:08:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04111 for ; Mon, 23 May 2005 11:08:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaENi-0003ad-K0 for netconf-data@psg.com; Mon, 23 May 2005 14:58:14 +0000 Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaENf-0003aH-FJ for netconf@ops.ietf.org; Mon, 23 May 2005 14:58:11 +0000 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 252941522E for ; Mon, 23 May 2005 17:08:00 +0200 (CEST) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: MOME interoperability event colocated with 63rd IETF Date: Mon, 23 May 2005 16:58:09 +0200 Message-ID: <88F766D04E6AF3409B39E60D7D933EB22633B5@europa.office> Thread-Topic: MOME interoperability event colocated with 63rd IETF Thread-Index: AcVfp9WoyPLzseL+QtavZVr/0RaRww== From: "Saverio Niccolini" To: 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 Content-Transfer-Encoding: quoted-printable Dear subscribers of the NETCONF mailing list, please find here attached an invitation to an interoperability event. My apologies if you receive multiple copies of this. The MOME project invites you to participate to the Monitoring and Measurement Interoperability Testing event. Event Location and Date: The event will be co-located with the 63rd IETF meeting at=20 Le Palais des Congr=E8s De Paris (2, Place de la Porte Maillot, 75017 = Paris Cedex 17 France).=20 The event will take place from July the 28th to July the 30th 2005 from = 9:00 to 18:00 in the room 332M/333M. Event Scope: Monitoring and measurements of Internet traffic often involves not just = a single application, but a combination of different tools that process = measured information at different levels. In order to exchange information between these tools, common information = models, data models, file formats, and protocols are required. The = interoperability of measurement and monitoring tools depends largely on = the level of standardisation and its accurate implementation within = tools and libraries from different vendors. This event focuses on the Monitoring and Measurement related tools and = similar technologies. The detailed event description and programme can be found at: = http://www.ist-mome.org/events/interop/ Targeted Protocols are:=20 IPFIX=20 OWAMP=20 PSAMP=20 NSIS=20 NETFLOW(v9)=20 NETCONF=20 If you need to test other protocols or features, or like to provide tests, please contact us at: info@ist-mome.org The event is free but due to seats limitation we recommend you to = register. The registration form can be found at: = http://www.terena.nl/events/?eventID=3D152 Looking forward to see you in Paris. Best regards, The MOME project partners. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Research Staff Member Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 90511-18 Fax: +49 (0)6221 90511-55 e-mail: saverio.niccolini@netlab.nec.de =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- 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 May 23 19:10:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12337 for ; Mon, 23 May 2005 19:10:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaLuj-000BLu-13 for netconf-data@psg.com; Mon, 23 May 2005 23:00:49 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DaLuh-000BK2-3y for netconf@ops.ietf.org; Mon, 23 May 2005 23:00:47 +0000 Received: (qmail 10643 invoked by uid 78); 23 May 2005 16:09:36 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 May 2005 16:09:36 -0000 Message-ID: <4292003F.6020407@andybierman.com> Date: Mon, 23 May 2005 09:09:35 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: End WG Last Call: draft-ietf-netconf-prot-06.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.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 Hi, The Working Group Last Call for the NETCONF Configuration Protocol has concluded. Some issues have been identified and most of them are resolved. The following issues are considered resolved: - confirmed-commit - confirm-timeout units changed from minutes to seconds - default value now '600' instead of '10' - if 2nd commit contains a 'confirmed' parameter, then if the is dirty, this new commit starts a new confirmed-commit. If not, then there is nothing new to commit so the 2nd 'confirmed' should be ignored. - if the session issuing the first commit is lost before the second commit is issued, the agent reverts the config (and cancels the timeout) - if the agent reboots after the first commit but before the second commit is issued, the agent reverts the config (and cancels the timeout) upon reboot. - access control Add text to sec 4.3: rpc-error (something to this affect): The agent must insure that application-level error information (e.g., from a operation) is suppressed if the user does not have sufficient access rights to the underlying data models associated with the application-level error information. The following issues are not completely resolved: - XML Directorate review comments - use of fragments to identify capabilities. [Not sure how important this is in NETCONF, since strings are to be used for exact-match only -- no parsing involved.] - other XML style issues like use of attributes instead of elements [Waiting for response from Phil Shafer, but no document changes likely.] - document clarification requests [Hopefully Rob understands the edits.] IMO the XML style issues should not hold up the document progress, especially since there doesn't seem to be much agreement within the XML Directorate on these issues. Unless there are strong objections raised on this mailing list, the changes described above will be made and a new prot-07 version issued. This new version will not be subject to another WG Last Call, and will instead be forwarded to the Area Director for publication consideration as a Proposed Standard RFC. thanks, Andy and 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 Wed May 25 08:31:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06178 for ; Wed, 25 May 2005 08:31:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaupG-000HUG-Hi for netconf-data@psg.com; Wed, 25 May 2005 12:17:30 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Daumu-000HK2-8O for netconf@ops.ietf.org; Wed, 25 May 2005 12:15:04 +0000 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4PCE6UK007791 for ; Wed, 25 May 2005 14:15:03 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 14:14:14 +0200 Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 14:14:13 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: NETCONF versioning Date: Wed, 25 May 2005 14:14:13 +0200 Message-ID: <94B96B3383630441B365F764903403481AF737@esealmw103.eemea.ericsson.se> Thread-Topic: NETCONF versioning Thread-Index: AcVhI0OHeVJnQyKnSnW95N/M+RNt3w== From: "Stig Solberg \(LN/EAB\)" To: X-OriginalArrivalTime: 25 May 2005 12:14:13.0939 (UTC) FILETIME=[43D02030:01C56123] 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 have a few questions regarding versioning in NETCONF. Looking at the draft it seems like versioning is meant to be solved=20 using Namespaces that includes a version. This seems to be the=20 case for the protocol version as well as the "content layer version". My questions: a) Is the above statement a correct interpretation of the standard? b) In case of version mismatch, is the 'unknown-namespace' error sent = from the server supposed to include both the errornous and the correct = namespace? c) Wouldn't it be a good idea that versions where exchanged at Session = start; for instance in the same way as Capabilities are exanged (using the = hello element)? In this way a Client would know if the versions matches and decide = whether to continue the session or not. Best regards, Stig Stig Solberg Software Engineer Ericsson AB Email: stig.solberg@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed May 25 13:19:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01958 for ; Wed, 25 May 2005 13:19:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DazJn-000CbN-Bs for netconf-data@psg.com; Wed, 25 May 2005 17:05:19 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DazJl-000Caz-G9 for netconf@ops.ietf.org; Wed, 25 May 2005 17:05:17 +0000 Received: (qmail 21886 invoked by uid 78); 25 May 2005 17:05:11 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 25 May 2005 17:05:11 -0000 Message-ID: <4294B043.8040204@andybierman.com> Date: Wed, 25 May 2005 10:05: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: "Stig Solberg (LN/EAB)" CC: netconf@ops.ietf.org Subject: Re: NETCONF versioning References: <94B96B3383630441B365F764903403481AF737@esealmw103.eemea.ericsson.se> In-Reply-To: <94B96B3383630441B365F764903403481AF737@esealmw103.eemea.ericsson.se> 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.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 Stig Solberg (LN/EAB) wrote: >Hi, >I have a few questions regarding versioning in NETCONF. >Looking at the draft it seems like versioning is meant to be solved >using Namespaces that includes a version. This seems to be the >case for the protocol version as well as the "content layer version". > >My questions: >a) Is the above statement a correct interpretation of the standard? > > the protocol is not concerned with content versioning. The protocol itself is identified by the netconf namespace URI. If the version changed in the future, there would be a different URI assigned to that version. >b) In case of version mismatch, is the 'unknown-namespace' error sent from >the server supposed to include both the errornous and the correct namespace? > > no -- We don't know how to determine the 'correct' namespace in a standard way. >c) Wouldn't it be a good idea that versions where exchanged at Session start; > > they are -- in the netconf namespace URI. >for instance in the same way as Capabilities are exanged (using the hello element)? >In this way a Client would know if the versions matches and decide whether >to continue the session or not. > > the agent and manager need to exact-match the netconf URI string or shutdown the session immediately. There is no version negotiation. It is unclear at this time if netconf entities in the future should advertise all versions they support or just the newest. >Best regards, >Stig > >Stig Solberg >Software Engineer >Ericsson AB >Email: stig.solberg@ericsson.com > > 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 May 26 11:45:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07436 for ; Thu, 26 May 2005 11:45:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbKNN-0002qK-J6 for netconf-data@psg.com; Thu, 26 May 2005 15:34:25 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbKNL-0002pn-Iu for netconf@ops.ietf.org; Thu, 26 May 2005 15:34:23 +0000 Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4QFYKY29802 for ; Thu, 26 May 2005 11:34:21 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j4QFYrP25044 for ; Thu, 26 May 2005 11:34:53 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 May 2005 11:34:19 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4038ADE82@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf Subject: RE: no NETCONF WG meeting planned for Paris Date: Thu, 26 May 2005 11:34:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 So, as I indicated in Minneapolis, I plan two presentations into the Paris meeting. One on the Netmod work proposing that gets added to the charter and another on asynchronous messaging with a similar objectives. The technical work is being progressed as we speak. Are you suggesting that you would like to see the proposed updated charter before Paris? Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, May 10, 2005 12:08 PM To: netconf Subject: no NETCONF WG meeting planned for Paris Hi, At this time, it appears all WG milestones will be completed before the next IETF, so there are no plans to hold a NETCONF WG meeting at the Paris IETF. We understand that some people want to continue adding features to the protocol and/or work on standard data models, but this work would need to be chartered first -- a process that has not been started, and not likely to be completed before the next IETF. Andy and 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: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu May 26 11:52:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07965 for ; Thu, 26 May 2005 11:52:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbKZf-0003jn-Fy for netconf-data@psg.com; Thu, 26 May 2005 15:47:07 +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 1DbKZd-0003jR-LX for netconf@ops.ietf.org; Thu, 26 May 2005 15:47:05 +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 j4QFZXSp009583 for ; Thu, 26 May 2005 11:35:34 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j4QFYRSp007881 for ; Thu, 26 May 2005 11:34:43 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: no NETCONF WG meeting planned for Paris Date: Thu, 26 May 2005 18:45:46 +0300 Message-ID: Thread-Topic: no NETCONF WG meeting planned for Paris Thread-Index: AcViCMN9zOnEAcAAQJiusq17axUPbQAAPw5A From: "Romascanu, Dan \(Dan\)" To: "Sharon Chisholm" , "netconf" 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 Content-Transfer-Encoding: quoted-printable Anything prevents us drafting (or re-drafting) a charter update, circulating it for comments, and having it approved before the August meeting? We have another ten weeks to go.=20 Dan =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, May 26, 2005 6:34 PM > To: netconf > Subject: RE: no NETCONF WG meeting planned for Paris >=20 > hi >=20 > So, as I indicated in Minneapolis, I plan two presentations=20 > into the Paris meeting. One on the Netmod work proposing that=20 > gets added to the charter and another on asynchronous=20 > messaging with a similar objectives. The technical work is=20 > being progressed as we speak. >=20 > Are you suggesting that you would like to see the proposed=20 > updated charter before Paris? >=20 > Sharon >=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, May 10, 2005 12:08 PM > To: netconf > Subject: no NETCONF WG meeting planned for Paris >=20 >=20 > Hi, >=20 > At this time, it appears all WG milestones will be completed=20 > before the next IETF, so there are no plans to hold a NETCONF=20 > WG meeting at the Paris IETF.=20 >=20 > We understand that some people want to continue adding=20 > features to the protocol and/or work on standard data models,=20 > but this work would need to be chartered first -- a process=20 > that has not been started, and not likely to be completed=20 > before the next IETF. >=20 >=20 > Andy and Simon >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu May 26 11:58:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08208 for ; Thu, 26 May 2005 11:58:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbKe9-0004GS-2K for netconf-data@psg.com; Thu, 26 May 2005 15:51:45 +0000 Received: from [204.127.202.59] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbKe8-0004Fs-9x for netconf@ops.ietf.org; Thu, 26 May 2005 15:51:44 +0000 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005052615514301400i73bne>; Thu, 26 May 2005 15:51:43 +0000 Reply-To: From: "David B Harrington" To: "'Sharon Chisholm'" , "'netconf'" Subject: RE: no NETCONF WG meeting planned for Paris Date: Thu, 26 May 2005 11:51:39 -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: <713043CE8B8E1348AF3C546DBE02C1B4038ADE82@zcarhxm2.corp.nortel.com> Thread-Index: AcViCelnIkALBC1vS4CPvRVcGrqp4gAALsjQ 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 Message-Id: Content-Transfer-Encoding: 7bit It would be good to get a NETMOD charter defined and approved so the work could be done in a WG. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, May 26, 2005 11:34 AM > To: netconf > Subject: RE: no NETCONF WG meeting planned for Paris > > hi > > So, as I indicated in Minneapolis, I plan two presentations > into the Paris > meeting. One on the Netmod work proposing that gets added to > the charter and > another on asynchronous messaging with a similar objectives. > The technical > work is being progressed as we speak. > > Are you suggesting that you would like to see the proposed > updated charter > before Paris? > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Tuesday, May 10, 2005 12:08 PM > To: netconf > Subject: no NETCONF WG meeting planned for Paris > > > Hi, > > At this time, it appears all WG milestones will be completed > before the next > IETF, so there are no plans to hold a NETCONF WG meeting at > the Paris IETF. > > We understand that some people want to continue adding features to the > protocol and/or work on standard data models, but this work > would need to be > chartered first -- a process that has not been started, and > not likely to be > completed before the next IETF. > > > Andy and 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: > > > -- > 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 May 26 12:04:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08845 for ; Thu, 26 May 2005 12:04:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbKkt-0005Ka-Sb for netconf-data@psg.com; Thu, 26 May 2005 15:58:43 +0000 Received: from [198.152.12.100] (helo=tiere.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DbKks-0005KC-1c for netconf@ops.ietf.org; Thu, 26 May 2005 15:58:42 +0000 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j4QFuF5c016637 for ; Thu, 26 May 2005 11:56:16 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j4QFr95c011252 for ; Thu, 26 May 2005 11:54:37 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: no NETCONF WG meeting planned for Paris Date: Thu, 26 May 2005 18:55:21 +0300 Message-ID: Thread-Topic: no NETCONF WG meeting planned for Paris Thread-Index: AcViCelnIkALBC1vS4CPvRVcGrqp4gAALsjQAAAdkwA= From: "Romascanu, Dan \(Dan\)" To: , "Sharon Chisholm" , "netconf" 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 Content-Transfer-Encoding: quoted-printable In Minneapolis the Netconf WG decided to continue the NETMOD work within Netconf rather than creating a new WG. =20 Dan > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington > Sent: Thursday, May 26, 2005 6:52 PM > To: 'Sharon Chisholm'; 'netconf' > Subject: RE: no NETCONF WG meeting planned for Paris >=20 > It would be good to get a NETMOD charter defined and approved=20 > so the work could be done in a WG. >=20 > David Harrington > dbharrington@comcast.net >=20 > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > > Sent: Thursday, May 26, 2005 11:34 AM > > To: netconf > > Subject: RE: no NETCONF WG meeting planned for Paris > >=20 > > hi > >=20 > > So, as I indicated in Minneapolis, I plan two presentations=20 > into the=20 > > Paris meeting. One on the Netmod work proposing that gets=20 > added to the=20 > > charter and another on asynchronous messaging with a similar=20 > > objectives. > > The technical > > work is being progressed as we speak. > >=20 > > Are you suggesting that you would like to see the proposed updated=20 > > charter before Paris? > >=20 > > Sharon > >=20 > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > > Sent: Tuesday, May 10, 2005 12:08 PM > > To: netconf > > Subject: no NETCONF WG meeting planned for Paris > >=20 > >=20 > > Hi, > >=20 > > At this time, it appears all WG milestones will be completed=20 > > before the next > > IETF, so there are no plans to hold a NETCONF WG meeting at=20 > > the Paris IETF.=20 > >=20 > > We understand that some people want to continue adding features to > the > > protocol and/or work on standard data models, but this work=20 > > would need to be > > chartered first -- a process that has not been started, and=20 > > not likely to be > > completed before the next IETF. > >=20 > >=20 > > Andy and Simon > >=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 May 26 14:13:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18270 for ; Thu, 26 May 2005 14:13:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbMmG-000GIB-Ha for netconf-data@psg.com; Thu, 26 May 2005 18:08:16 +0000 Received: from [85.73.154.33] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbMmD-000GHg-L0 for netconf@ops.ietf.org; Thu, 26 May 2005 18:08:13 +0000 Received: by boskop.local (Postfix, from userid 501) id 0BA882F4F4E; Thu, 26 May 2005 20:08:11 +0200 (CEST) Date: Thu, 26 May 2005 20:08:11 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Cc: dbharrington@comcast.net, Sharon Chisholm , netconf Subject: Re: no NETCONF WG meeting planned for Paris Message-ID: <20050526180811.GA23450@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Romascanu, Dan (Dan)" , dbharrington@comcast.net, 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.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 Thu, May 26, 2005 at 06:55:21PM +0300, Romascanu, Dan (Dan) wrote: > In Minneapolis the Netconf WG decided to continue the NETMOD work within > Netconf rather than creating a new WG. Can a WG decide something during an IETF meeting? /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 Thu May 26 14:13:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18320 for ; Thu, 26 May 2005 14:13:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbMkN-000G6T-Fo for netconf-data@psg.com; Thu, 26 May 2005 18:06:19 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbMkK-000G5g-JC for netconf@ops.ietf.org; Thu, 26 May 2005 18:06:16 +0000 Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4QI6CY20662 for ; Thu, 26 May 2005 14:06:12 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4QI5vT00024 for ; Thu, 26 May 2005 14:05:57 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 May 2005 14:05:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4038AE0D2@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf Subject: RE: no NETCONF WG meeting planned for Paris Date: Thu, 26 May 2005 14:05:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 Actually, my remembrance is that a number of items were dropped solely as a scoping exercise. Note because they were not felt to be achievable or necessary. If there is working group consensus to take on additional work and the AD is sufficiently convinced of its value and achievability, are we then all on board? Just a note that the current Netmod work provides a framework to define content but does not actually define any content. Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Thursday, May 26, 2005 12:19 PM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf Subject: Re: no NETCONF WG meeting planned for Paris Sharon Chisholm wrote: >hi > >So, as I indicated in Minneapolis, I plan two presentations into the >Paris meeting. One on the Netmod work proposing that gets added to the >charter and another on asynchronous messaging with a similar >objectives. The technical work is being progressed as we speak. > >Are you suggesting that you would like to see the proposed updated >charter before Paris? > > Simon and I both agree that the NETCONF WG should concentrate on finishing the 1.0 document set and then take a little break -- like until the RFCs are actually published -- before charging ahead with more features. We would like to make sure the IESG approves the work we've done so far before building on that work. A little time for implementation, inter-operability testing, and deployment would be a good idea as well. Before this new work, we would of course need to update the WG charter, and to do that, we need consensus on that charter. Neither Simon or myself is eager to take on the NETMOD work in its current form. The deferred protocol features like notifications can be started if there if WG consensus. Of course, every feature on that list is there because it is difficult, contentious, and the WG couldn't reach agreement on it. I'm not convinced we will do any better the second time around. (Prove me wrong -- write a great draft that wins the WG over.) Solution proposals full of the same holes as the first time around aren't going to become WG drafts just because they exist. More on NETMOD: My preference is for NETCONF to be content-neutral, like the document claims. I would like to see other SDOs and even a NETMOD WG in the IETF define mappings between their data modeling constructs and the NETCONF protocol (operations and transaction model). I do not think a one-size-fits-all solution will ever work, or that the first cut at a data modeling standard will be long-lasting. Personally, I haven't seen anything yet that really removes enough complexity to be interesting, but I'm confident in the next few years somebody will figure it all out. >Sharon > > Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Tuesday, May 10, 2005 12:08 PM >To: netconf >Subject: no NETCONF WG meeting planned for Paris > > >Hi, > >At this time, it appears all WG milestones will be completed before the >next IETF, so there are no plans to hold a NETCONF WG meeting at the >Paris IETF. > >We understand that some people want to continue adding features to the >protocol and/or work on standard data models, but this work would need >to be chartered first -- a process that has not been started, and not >likely to be completed before the next IETF. > > >Andy and 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: > > >-- >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 May 26 14:22:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18811 for ; Thu, 26 May 2005 14:22:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbMvA-000H2e-B9 for netconf-data@psg.com; Thu, 26 May 2005 18:17:28 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbMv7-000H2L-HN for netconf@ops.ietf.org; Thu, 26 May 2005 18:17:25 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 26 May 2005 11:17:23 -0700 X-IronPort-AV: i="3.93,140,1115017200"; d="scan'208"; a="638837824:sNHT4720284032" 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 j4QIHIbw013880; Thu, 26 May 2005 11:17:18 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp462.cisco.com [10.61.65.206]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4QI68vU006966; Thu, 26 May 2005 11:06:09 -0700 Message-ID: <429612AD.4030402@cisco.com> Date: Thu, 26 May 2005 20:17:17 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf Subject: Re: no NETCONF WG meeting planned for Paris References: <713043CE8B8E1348AF3C546DBE02C1B4038AE0D2@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4038AE0D2@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117130770.392278"; x:"432200"; a:"rsa-sha1"; b:"nofws:3555"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"eI9N5IpTLAJJ8om+n2lbpfHTvoUNyL+7J8fvuSrQIUEBzINkhDeUsWWD72/mCLPpa6r8wgQi" "/iK4blimt55s1DKfnZxkwV36jNvTCAyb4meIa41KeN6ySekR8AlZEWmrbqKBDEZrbyolH5SiEP5" "ccrzTFhWCS90SVMqFzcFpkBE="; c:"Date: Thu, 26 May 2005 20:17:17 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: no NETCONF WG meeting planned for Paris" 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 I think it's important to do at least one of the extensions so we know we have it right. Eliot Sharon Chisholm wrote: > hi > > Actually, my remembrance is that a number of items were dropped solely as a > scoping exercise. Note because they were not felt to be achievable or > necessary. > > If there is working group consensus to take on additional work and the AD is > sufficiently convinced of its value and achievability, are we then all on > board? > > Just a note that the current Netmod work provides a framework to define > content but does not actually define any content. > > Sharon > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, May 26, 2005 12:19 PM > To: Chisholm, Sharon [CAR:5K50:EXCH] > Cc: netconf > Subject: Re: no NETCONF WG meeting planned for Paris > > > Sharon Chisholm wrote: > > >>hi >> >>So, as I indicated in Minneapolis, I plan two presentations into the >>Paris meeting. One on the Netmod work proposing that gets added to the >>charter and another on asynchronous messaging with a similar >>objectives. The technical work is being progressed as we speak. >> >>Are you suggesting that you would like to see the proposed updated >>charter before Paris? >> >> > > Simon and I both agree that the NETCONF WG should concentrate on finishing > the 1.0 document set and then take a little break -- like until the RFCs are > actually published -- before charging ahead with more features. We would > like to make sure the IESG approves the work we've done so far before > building on that work. A little time for implementation, inter-operability > testing, and deployment would be a good idea as well. > > Before this new work, we would of course need to update the WG charter, and > to do that, we need consensus on that charter. Neither Simon or myself is > eager to take on the NETMOD work in its current form. The deferred protocol > features like notifications can be started if there if WG > consensus. > > Of course, every feature on that list is there because it is difficult, > contentious, > and the WG couldn't reach agreement on it. I'm not convinced we will do any > better the second time around. (Prove me wrong -- write a great draft that > wins the WG over.) Solution proposals full of the same holes as the first > time around aren't going to become WG drafts just because they exist. > > More on NETMOD: My preference is for NETCONF to be content-neutral, > like the document claims. I would like to see other SDOs and even a > NETMOD > WG in the IETF define mappings between their data modeling constructs and > the NETCONF protocol (operations and transaction model). I do not think > a one-size-fits-all solution will ever work, or that the first cut at a > data modeling > standard will be long-lasting. Personally, I haven't seen anything yet > that really > removes enough complexity to be interesting, but I'm confident in the > next few > years somebody will figure it all out. > > >>Sharon >> >> > > Andy > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >>Behalf Of Andy Bierman >>Sent: Tuesday, May 10, 2005 12:08 PM >>To: netconf >>Subject: no NETCONF WG meeting planned for Paris >> >> >>Hi, >> >>At this time, it appears all WG milestones will be completed before the >>next IETF, so there are no plans to hold a NETCONF WG meeting at the >>Paris IETF. >> >>We understand that some people want to continue adding features to the >>protocol and/or work on standard data models, but this work would need >>to be chartered first -- a process that has not been started, and not >>likely to be completed before the next IETF. >> >> >>Andy and 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: >> >> >>-- >>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 Thu May 26 15:09:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22493 for ; Thu, 26 May 2005 15:09:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbNe3-000KOA-0P for netconf-data@psg.com; Thu, 26 May 2005 19:03:51 +0000 Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbNdz-000KNL-VP for netconf@ops.ietf.org; Thu, 26 May 2005 19:03:48 +0000 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <2005052619034701200a1e7ue>; Thu, 26 May 2005 19:03:47 +0000 Reply-To: From: "David B Harrington" To: "'Sharon Chisholm'" , "'netconf'" Subject: RE: no NETCONF WG meeting planned for Paris Date: Thu, 26 May 2005 15:03:43 -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: <713043CE8B8E1348AF3C546DBE02C1B4038AE0D2@zcarhxm2.corp.nortel.com> Thread-Index: AcViHp4LrlmG1YbgT2qvcWyn9Ojy0gAATnLg 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, To me, a protocol with no data modeling language and no data models is close to worthless as a standard. It provides only a "bucket transport" protocol where the contents of the bucket are proprietary. I agree the netconf WG needs to focus on the protocol issues, motivating independent implementations, and starting discussions on partial locking and other issues that were punted to get 1.0 out the door. I support Andy and Simon in this. A Netconf SMI is necessary to allow the development of standards-based data models, and a NETMOD SMI should be done in a separate WG from the protocol. If the Netconf WG decided to not try to start a NETMOD WG, I think that is a mistake. I recommend starting with an SMI that can map to existing SNMP information, since there is a wealth of data models already available, researchers have already developed tools that automate the translation, and Netconf implementations could use these data models to demonstrate that the Netconf protocol works properly. SNMP and SMIv2 are showing their 1980's roots, so we should work on defining a Netconf SMI in XML to provide additional capabilities, such as nested data structures. As the SMIv3 effort showed, the SNMP-adapted ASN.1 SMI has too much baggage to be able to design a backwards-compatible SMIv3 easily. Developing a new SMI in XML will give us a better chance of advancing the state of the art in NM data modeling. I also believe that we should start work on SNMPv4 - a version of SNMP based on XML messaging rather than ASN.1 messaging, leveraging existing transport layer message security, using an XML-based data modeling language, and using an access control method that is easier to read than VACM's OID hierarchies and can be utilized by SNMP and Netconf, thus sharing many ease-of-use design decisions between the monitoring and the (separate) configuration protocol standards. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, May 26, 2005 2:06 PM > To: netconf > Subject: RE: no NETCONF WG meeting planned for Paris > > hi > > Actually, my remembrance is that a number of items were > dropped solely as a > scoping exercise. Note because they were not felt to be achievable or > necessary. > > If there is working group consensus to take on additional > work and the AD is > sufficiently convinced of its value and achievability, are we > then all on > board? > > Just a note that the current Netmod work provides a framework > to define > content but does not actually define any content. > > Sharon > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, May 26, 2005 12:19 PM > To: Chisholm, Sharon [CAR:5K50:EXCH] > Cc: netconf > Subject: Re: no NETCONF WG meeting planned for Paris > > > Sharon Chisholm wrote: > > >hi > > > >So, as I indicated in Minneapolis, I plan two presentations into the > >Paris meeting. One on the Netmod work proposing that gets > added to the > >charter and another on asynchronous messaging with a similar > >objectives. The technical work is being progressed as we speak. > > > >Are you suggesting that you would like to see the proposed updated > >charter before Paris? > > > > > Simon and I both agree that the NETCONF WG should concentrate > on finishing > the 1.0 document set and then take a little break -- like > until the RFCs are > actually published -- before charging ahead with more > features. We would > like to make sure the IESG approves the work we've done so far before > building on that work. A little time for implementation, > inter-operability > testing, and deployment would be a good idea as well. > > Before this new work, we would of course need to update the > WG charter, and > to do that, we need consensus on that charter. Neither Simon > or myself is > eager to take on the NETMOD work in its current form. The > deferred protocol > features like notifications can be started if there if WG > consensus. > > Of course, every feature on that list is there because it is > difficult, > contentious, > and the WG couldn't reach agreement on it. I'm not convinced > we will do any > better the second time around. (Prove me wrong -- write a > great draft that > wins the WG over.) Solution proposals full of the same holes > as the first > time around aren't going to become WG drafts just because they exist. > > More on NETMOD: My preference is for NETCONF to be content-neutral, > like the document claims. I would like to see other SDOs and even a > NETMOD > WG in the IETF define mappings between their data modeling > constructs and > the NETCONF protocol (operations and transaction model). I > do not think > a one-size-fits-all solution will ever work, or that the > first cut at a > data modeling > standard will be long-lasting. Personally, I haven't seen > anything yet > that really > removes enough complexity to be interesting, but I'm confident in the > next few > years somebody will figure it all out. > > >Sharon > > > > > Andy > > >-----Original Message----- > >From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On > >Behalf Of Andy Bierman > >Sent: Tuesday, May 10, 2005 12:08 PM > >To: netconf > >Subject: no NETCONF WG meeting planned for Paris > > > > > >Hi, > > > >At this time, it appears all WG milestones will be completed > before the > >next IETF, so there are no plans to hold a NETCONF WG meeting at the > >Paris IETF. > > > >We understand that some people want to continue adding > features to the > >protocol and/or work on standard data models, but this work > would need > >to be chartered first -- a process that has not been > started, and not > >likely to be completed before the next IETF. > > > > > >Andy and 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: > > > > > >-- > >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 Thu May 26 15:10:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22534 for ; Thu, 26 May 2005 15:10:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbNfv-000Kl4-Ux for netconf-data@psg.com; Thu, 26 May 2005 19:05:47 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DbNfu-000KkZ-Qx for netconf@ops.ietf.org; Thu, 26 May 2005 19:05:47 +0000 Received: (qmail 20537 invoked by uid 78); 26 May 2005 16:19:05 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 26 May 2005 16:19:05 -0000 Message-ID: <4295F6F9.8050705@andybierman.com> Date: Thu, 26 May 2005 09:19: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: Sharon Chisholm CC: netconf Subject: Re: no NETCONF WG meeting planned for Paris References: <713043CE8B8E1348AF3C546DBE02C1B4038ADE82@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4038ADE82@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.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 Sharon Chisholm wrote: >hi > >So, as I indicated in Minneapolis, I plan two presentations into the Paris >meeting. One on the Netmod work proposing that gets added to the charter and >another on asynchronous messaging with a similar objectives. The technical >work is being progressed as we speak. > >Are you suggesting that you would like to see the proposed updated charter >before Paris? > > Simon and I both agree that the NETCONF WG should concentrate on finishing the 1.0 document set and then take a little break -- like until the RFCs are actually published -- before charging ahead with more features. We would like to make sure the IESG approves the work we've done so far before building on that work. A little time for implementation, inter-operability testing, and deployment would be a good idea as well. Before this new work, we would of course need to update the WG charter, and to do that, we need consensus on that charter. Neither Simon or myself is eager to take on the NETMOD work in its current form. The deferred protocol features like notifications can be started if there if WG consensus. Of course, every feature on that list is there because it is difficult, contentious, and the WG couldn't reach agreement on it. I'm not convinced we will do any better the second time around. (Prove me wrong -- write a great draft that wins the WG over.) Solution proposals full of the same holes as the first time around aren't going to become WG drafts just because they exist. More on NETMOD: My preference is for NETCONF to be content-neutral, like the document claims. I would like to see other SDOs and even a NETMOD WG in the IETF define mappings between their data modeling constructs and the NETCONF protocol (operations and transaction model). I do not think a one-size-fits-all solution will ever work, or that the first cut at a data modeling standard will be long-lasting. Personally, I haven't seen anything yet that really removes enough complexity to be interesting, but I'm confident in the next few years somebody will figure it all out. >Sharon > > Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Tuesday, May 10, 2005 12:08 PM >To: netconf >Subject: no NETCONF WG meeting planned for Paris > > >Hi, > >At this time, it appears all WG milestones will be completed before the next >IETF, so there are no plans to hold a NETCONF WG meeting at the Paris IETF. > >We understand that some people want to continue adding features to the >protocol and/or work on standard data models, but this work would need to be >chartered first -- a process that has not been started, and not likely to be >completed before the next IETF. > > >Andy and 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: > > >-- >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 May 26 21:31:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01710 for ; Thu, 26 May 2005 21:31:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbTYM-000MVO-He for netconf-data@psg.com; Fri, 27 May 2005 01:22:22 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DbTYJ-000MV5-Ck for netconf@ops.ietf.org; Fri, 27 May 2005 01:22:19 +0000 Received: (qmail 15133 invoked by uid 78); 27 May 2005 01:22:18 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 27 May 2005 01:22:18 -0000 Message-ID: <42967648.309@andybierman.com> Date: Thu, 26 May 2005 18:22:16 -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'" Subject: Re: no NETCONF WG meeting planned for Paris References: 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.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 David B Harrington wrote: >Hi, > >To me, a protocol with no data modeling language and no data models is >close to worthless as a standard. It provides only a "bucket >transport" protocol where the contents of the bucket are proprietary. > > There are some pretty powerful features within a decent transaction model to act on that bucket of XML content. I know some of us on the design team we're really just trying to eliminate screen-scraping the CLI with 1.0. Even if NETCONF is just used as a programmatic interface to the CLI at first, this is better than screen-scraping. We've had a mix of proprietary and standard SNMP data from day one, and it will be no different for NETCONF. >I agree the netconf WG needs to focus on the protocol issues, >motivating independent implementations, and starting discussions on >partial locking and other issues that were punted to get 1.0 out the >door. I support Andy and Simon in this. > >A Netconf SMI is necessary to allow the development of standards-based >data models, and a NETMOD SMI should be done in a separate WG from the >protocol. If the Netconf WG decided to not try to start a NETMOD WG, I >think that is a mistake. > > I don't remember the WG agreeing to work on specific features in the future, just that work should continue in the WG on protocol features. I do remember that we were very concerned not to get in the same "SMING/EOS" deadlock, where each WG wouldn't do work the other one needed. I'm not against doing the NETMOD work in the NETCONF WG if that's the WG consensus. I don't see a lot of energy and momentum around the current proposal based on the lack of email comments on the NETMOD list. >I recommend starting with an SMI that can map to existing SNMP >information, since there is a wealth of data models already available, >researchers have already developed tools that automate the >translation, and Netconf implementations could use these data models >to demonstrate that the Netconf protocol works properly. SNMP and >SMIv2 are showing their 1980's roots, so we should work on defining a >Netconf SMI in XML to provide additional capabilities, such as nested >data structures. As the SMIv3 effort showed, the SNMP-adapted ASN.1 >SMI has too much baggage to be able to design a backwards-compatible >SMIv3 easily. Developing a new SMI in XML will give us a better chance >of advancing the state of the art in NM data modeling. > > I think you are proving my point about the one-size-fits-all myth. I agree that this could be one of several data modeling approaches that can be mapped to the NETCONF protocol. >I also believe that we should start work on SNMPv4 - a version of SNMP >based on XML messaging rather than ASN.1 messaging, leveraging >existing transport layer message security, using an XML-based data >modeling language, and using an access control method that is easier >to read than VACM's OID hierarchies and can be utilized by SNMP and >Netconf, thus sharing many ease-of-use design decisions between the >monitoring and the (separate) configuration protocol standards. > > This sounds interesting (do you mean s/messaging/encoding/ in line 2?) >David Harrington >dbharrington@comcast.net > > Andy > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm >>Sent: Thursday, May 26, 2005 2:06 PM >>To: netconf >>Subject: RE: no NETCONF WG meeting planned for Paris >> >>hi >> >>Actually, my remembrance is that a number of items were >>dropped solely as a >>scoping exercise. Note because they were not felt to be achievable >> >> >or > > >>necessary. >> >>If there is working group consensus to take on additional >>work and the AD is >>sufficiently convinced of its value and achievability, are we >>then all on >>board? >> >>Just a note that the current Netmod work provides a framework >>to define >>content but does not actually define any content. >> >>Sharon >> >>-----Original Message----- >>From: Andy Bierman [mailto:ietf@andybierman.com] >>Sent: Thursday, May 26, 2005 12:19 PM >>To: Chisholm, Sharon [CAR:5K50:EXCH] >>Cc: netconf >>Subject: Re: no NETCONF WG meeting planned for Paris >> >> >>Sharon Chisholm wrote: >> >> >> >>>hi >>> >>>So, as I indicated in Minneapolis, I plan two presentations into >>> >>> >the > > >>>Paris meeting. One on the Netmod work proposing that gets >>> >>> >>added to the >> >> >>>charter and another on asynchronous messaging with a similar >>>objectives. The technical work is being progressed as we speak. >>> >>>Are you suggesting that you would like to see the proposed updated >>>charter before Paris? >>> >>> >>> >>> >>Simon and I both agree that the NETCONF WG should concentrate >>on finishing >>the 1.0 document set and then take a little break -- like >>until the RFCs are >>actually published -- before charging ahead with more >>features. We would >>like to make sure the IESG approves the work we've done so far >> >> >before > > >>building on that work. A little time for implementation, >>inter-operability >>testing, and deployment would be a good idea as well. >> >>Before this new work, we would of course need to update the >>WG charter, and >>to do that, we need consensus on that charter. Neither Simon >>or myself is >>eager to take on the NETMOD work in its current form. The >>deferred protocol >>features like notifications can be started if there if WG >>consensus. >> >>Of course, every feature on that list is there because it is >>difficult, >>contentious, >>and the WG couldn't reach agreement on it. I'm not convinced >>we will do any >>better the second time around. (Prove me wrong -- write a >>great draft that >>wins the WG over.) Solution proposals full of the same holes >>as the first >>time around aren't going to become WG drafts just because they >> >> >exist. > > >>More on NETMOD: My preference is for NETCONF to be content-neutral, >>like the document claims. I would like to see other SDOs and even >> >> >a > > >>NETMOD >>WG in the IETF define mappings between their data modeling >>constructs and >>the NETCONF protocol (operations and transaction model). I >>do not think >>a one-size-fits-all solution will ever work, or that the >>first cut at a >>data modeling >>standard will be long-lasting. Personally, I haven't seen >>anything yet >>that really >>removes enough complexity to be interesting, but I'm confident in >> >> >the > > >>next few >>years somebody will figure it all out. >> >> >> >>>Sharon >>> >>> >>> >>> >>Andy >> >> >> >>>-----Original Message----- >>>From: owner-netconf@ops.ietf.org >>> >>> >>[mailto:owner-netconf@ops.ietf.org] On >> >> >>>Behalf Of Andy Bierman >>>Sent: Tuesday, May 10, 2005 12:08 PM >>>To: netconf >>>Subject: no NETCONF WG meeting planned for Paris >>> >>> >>>Hi, >>> >>>At this time, it appears all WG milestones will be completed >>> >>> >>before the >> >> >>>next IETF, so there are no plans to hold a NETCONF WG meeting at >>> >>> >the > > >>>Paris IETF. >>> >>>We understand that some people want to continue adding >>> >>> >>features to the >> >> >>>protocol and/or work on standard data models, but this work >>> >>> >>would need >> >> >>>to be chartered first -- a process that has not been >>> >>> >>started, and not >> >> >>>likely to be completed before the next IETF. >>> >>> >>>Andy and 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: >>> >>> >>>-- >>>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 Thu May 26 22:59:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08378 for ; Thu, 26 May 2005 22:59:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbUx7-0002hJ-HO for netconf-data@psg.com; Fri, 27 May 2005 02:52:01 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbUx4-0002gv-3g for netconf@ops.ietf.org; Fri, 27 May 2005 02:51:58 +0000 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050527025157011002evmde>; Fri, 27 May 2005 02:51:57 +0000 Reply-To: From: "David B Harrington" To: "'Andy Bierman'" Cc: "'Sharon Chisholm'" , "'netconf'" Subject: RE: no NETCONF WG meeting planned for Paris Date: Thu, 26 May 2005 22:51:52 -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: <42967648.309@andybierman.com> Thread-Index: AcViW9JRQfiDTmdkSqa4AJeT9WUxqwABjlvA 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 Message-Id: Content-Transfer-Encoding: 7bit Hi Andy > There are some pretty powerful features within a > decent transaction model to act on that bucket of XML content. > I know some of us on the design team we're really just > trying to eliminate screen-scraping the CLI with 1.0. > Even if NETCONF is just used as a programmatic interface > to the CLI at first, this is better than screen-scraping. And I strongly support that vision. Screen-scraping needs to go. But we also need to move past the constraint that any operator must be able to lock the whole configuration to modify it, and a large number of other issues that you have collected during the development of netconf 1.0. Just changing from screen-scraping to XML isn't enough to meet operators' needs, even if it is a big step in the right direction. > We've had a mix of proprietary and standard SNMP data from > day one, and it will be no different for NETCONF. True, but the SMI and the OID hierarchy allowed us to develop mib modules in a relatively consistent manner, in a standard format, by providing an explicit mechanism for defining mibs independent of vendor, and to identify enterprise mibs versus standard mibs. Netconf doesn't yet have a standard language for defining schemas, or a mechanism to identify enterprise schemas versus standard schemas. Also, SNMP really got a foothold when mib-I and mib-II gave the industry something solid to build upon, and netconf has not yet done that. > > I don't remember the WG agreeing to work on specific features > in the future, > just that work should continue in the WG on protocol features. I do > remember > that we were very concerned not to get in the same > "SMING/EOS" deadlock, > where each WG wouldn't do work the other one needed. I share the concern that different WGs working on interlocking technologies can hold each other back. I think that is a very bad trend to support, but as much as I love Bert, I think he is too tied to breaking the work into smaller units that cannot be accomplished on their own without the corresponding pieces being able to be worked on together. EOS/SMIv3 proved the point that the pieces must be worked on together, and trying to "lock them apart" just doesn't cut it. I understanbd Bert's concerns about the community's history of not completing things, but not allowing any flexibility around the SNMPv3 architecture makes it harder than necessaruy to make progress. But if that is the reality we must deal with, then we should deal with it aggressively, and at least start work on an SMI, which is a key element betwen the protocol and the data models. That said, I am a strong supporter of modularity, where there can be multiple models to plug into a given subsystem, so I don't have a problem with competing SMIs or competing data models to make forward progress. > I'm not against doing the NETMOD work in the NETCONF WG if that's > the WG consensus. I don't see a lot of energy and momentum around the > current proposal based on the lack of email comments on the > NETMOD list. I hear ya. It's hard to get energetic about anything when the politics discourage WG creation, and it's hard to carry on conversations effectively on private email lists. I'm not sure how to make progress in the IETF O&M area given the obstacles that must be overcome in dealing the "SNMP old dogs" like myself, and WBEM proponents, and XML proponents that know XML but don't understand device/network management. > I think you are proving my point about the one-size-fits-all myth. > I agree that this could be one of several data modeling approaches > that can be mapped to the NETCONF protocol. Yup. SNMP mib modules are just one approach to data modeling, but mib modules are fairly ubiquitous and accepted as important by vendors, and could be a reasonable starting point to prove the protocol works, then we can work on new data and/or information models more suited to the XML world, such as the things that we tried to do with SMIv3 but couldn't get past the SMIv2 backwards-compatibility constraints. > > >I also believe that we should start work on SNMPv4 - a > version of SNMP > >based on XML messaging rather than ASN.1 messaging, leveraging > > This sounds interesting (do you mean s/messaging/encoding/ in line 2?) Yes, the encoding of the messages would be the starting point. But I also think the richness of RPC messaging could allow us to expand beyond SNMP's limited operations, while still keeping some simplicty to the design. > > >David Harrington > >dbharrington@comcast.net > > > > > > Andy > > > > > > >>-----Original Message----- > >>From: owner-netconf@ops.ietf.org > >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > >>Sent: Thursday, May 26, 2005 2:06 PM > >>To: netconf > >>Subject: RE: no NETCONF WG meeting planned for Paris > >> > >>hi > >> > >>Actually, my remembrance is that a number of items were > >>dropped solely as a > >>scoping exercise. Note because they were not felt to be achievable > >> > >> > >or > > > > > >>necessary. > >> > >>If there is working group consensus to take on additional > >>work and the AD is > >>sufficiently convinced of its value and achievability, are we > >>then all on > >>board? > >> > >>Just a note that the current Netmod work provides a framework > >>to define > >>content but does not actually define any content. > >> > >>Sharon > >> > >>-----Original Message----- > >>From: Andy Bierman [mailto:ietf@andybierman.com] > >>Sent: Thursday, May 26, 2005 12:19 PM > >>To: Chisholm, Sharon [CAR:5K50:EXCH] > >>Cc: netconf > >>Subject: Re: no NETCONF WG meeting planned for Paris > >> > >> > >>Sharon Chisholm wrote: > >> > >> > >> > >>>hi > >>> > >>>So, as I indicated in Minneapolis, I plan two presentations into > >>> > >>> > >the > > > > > >>>Paris meeting. One on the Netmod work proposing that gets > >>> > >>> > >>added to the > >> > >> > >>>charter and another on asynchronous messaging with a similar > >>>objectives. The technical work is being progressed as we speak. > >>> > >>>Are you suggesting that you would like to see the proposed updated > >>>charter before Paris? > >>> > >>> > >>> > >>> > >>Simon and I both agree that the NETCONF WG should concentrate > >>on finishing > >>the 1.0 document set and then take a little break -- like > >>until the RFCs are > >>actually published -- before charging ahead with more > >>features. We would > >>like to make sure the IESG approves the work we've done so far > >> > >> > >before > > > > > >>building on that work. A little time for implementation, > >>inter-operability > >>testing, and deployment would be a good idea as well. > >> > >>Before this new work, we would of course need to update the > >>WG charter, and > >>to do that, we need consensus on that charter. Neither Simon > >>or myself is > >>eager to take on the NETMOD work in its current form. The > >>deferred protocol > >>features like notifications can be started if there if WG > >>consensus. > >> > >>Of course, every feature on that list is there because it is > >>difficult, > >>contentious, > >>and the WG couldn't reach agreement on it. I'm not convinced > >>we will do any > >>better the second time around. (Prove me wrong -- write a > >>great draft that > >>wins the WG over.) Solution proposals full of the same holes > >>as the first > >>time around aren't going to become WG drafts just because they > >> > >> > >exist. > > > > > >>More on NETMOD: My preference is for NETCONF to be content-neutral, > >>like the document claims. I would like to see other SDOs and even > >> > >> > >a > > > > > >>NETMOD > >>WG in the IETF define mappings between their data modeling > >>constructs and > >>the NETCONF protocol (operations and transaction model). I > >>do not think > >>a one-size-fits-all solution will ever work, or that the > >>first cut at a > >>data modeling > >>standard will be long-lasting. Personally, I haven't seen > >>anything yet > >>that really > >>removes enough complexity to be interesting, but I'm confident in > >> > >> > >the > > > > > >>next few > >>years somebody will figure it all out. > >> > >> > >> > >>>Sharon > >>> > >>> > >>> > >>> > >>Andy > >> > >> > >> > >>>-----Original Message----- > >>>From: owner-netconf@ops.ietf.org > >>> > >>> > >>[mailto:owner-netconf@ops.ietf.org] On > >> > >> > >>>Behalf Of Andy Bierman > >>>Sent: Tuesday, May 10, 2005 12:08 PM > >>>To: netconf > >>>Subject: no NETCONF WG meeting planned for Paris > >>> > >>> > >>>Hi, > >>> > >>>At this time, it appears all WG milestones will be completed > >>> > >>> > >>before the > >> > >> > >>>next IETF, so there are no plans to hold a NETCONF WG meeting at > >>> > >>> > >the > > > > > >>>Paris IETF. > >>> > >>>We understand that some people want to continue adding > >>> > >>> > >>features to the > >> > >> > >>>protocol and/or work on standard data models, but this work > >>> > >>> > >>would need > >> > >> > >>>to be chartered first -- a process that has not been > >>> > >>> > >>started, and not > >> > >> > >>>likely to be completed before the next IETF. > >>> > >>> > >>>Andy and 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: > >>> > >>> > >>>-- > >>>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 Fri May 27 09:32:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10654 for ; Fri, 27 May 2005 09:32:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dbeni-000MVa-Eb for netconf-data@psg.com; Fri, 27 May 2005 13:22:58 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dbenh-000MV7-Lu for netconf@ops.ietf.org; Fri, 27 May 2005 13:22:57 +0000 Received: (qmail 18015 invoked by uid 78); 27 May 2005 13:22:54 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 27 May 2005 13:22:54 -0000 Message-ID: <42971F2C.6020106@andybierman.com> Date: Fri, 27 May 2005 06:22: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'" Subject: Re: no NETCONF WG meeting planned for Paris References: 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.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 David B Harrington wrote: >Hi Andy > > > >>There are some pretty powerful features within a >>decent transaction model to act on that bucket of XML content. >>I know some of us on the design team we're really just >>trying to eliminate screen-scraping the CLI with 1.0. >>Even if NETCONF is just used as a programmatic interface >>to the CLI at first, this is better than screen-scraping. >> >> > >And I strongly support that vision. Screen-scraping needs to go. > >But we also need to move past the constraint that any operator must be >able to lock the whole configuration to modify it, and a large number >of other issues that you have collected during the development of >netconf 1.0. Just changing from screen-scraping to XML isn't enough to >meet operators' needs, even if it is a big step in the right >direction. > > I disagree. The 2 main deferred features -- partial locking and notifications -- are both simply speed optimizations, which impact a relatively small number of use cases. We don't have any serialization in SNMP or CLI at all! Concurrent writes can clobber config now, but this doesn't seem to be a big problem. I'm not convinced the lack of locked concurrent writes in NETCONF is a problem yet. Notifications essentially provide a speed improvement over polling techniques. Currently, many CLI applications use SNMP notifications and SYSLOG for this purpose. The convenience of receiving async messages within a NETCONF session is probably balanced out by the increased localized cost of the NETCONF implementation, and most likely does not represent a significant percentage of either the implementation or deployment complexity. IMO, the lack of these deferred features has no significant impact on the usefulness of NETCONF 1.0. As for NETMOD -- I don't see much hope of a WG agreeing on the one true NETCONF data modeling language. I agree that would be the ideal from a standards-POV, but not realistic or even close to operationally optimal. E.g., A scheme tuned for SNMP integration isn't going to work well for CLI-oriented configuration. 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 Fri May 27 12:09:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22937 for ; Fri, 27 May 2005 12:09:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbhGD-0008vs-VE for netconf-data@psg.com; Fri, 27 May 2005 16:00:33 +0000 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbhG8-0008v4-8X for netconf@ops.ietf.org; Fri, 27 May 2005 16:00:33 +0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4RG0JF07254; Fri, 27 May 2005 12:00:20 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 May 2005 12:00:19 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D04B00279@zcarhxm0.corp.nortel.com> From: "Glenn Waters" To: Andy Bierman , dbharrington@comcast.net Cc: "Sharon Chisholm" , "'netconf'" Subject: RE: no NETCONF WG meeting planned for Paris Date: Fri, 27 May 2005 11:58:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C562D5.1A58326A" 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,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-netconf@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C562D5.1A58326A Content-Type: text/plain Inline. > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Friday, May 27, 2005 09:23 > To: dbharrington@comcast.net > Cc: Chisholm, Sharon [CAR:5K50:EXCH]; 'netconf' > Subject: Re: no NETCONF WG meeting planned for Paris > > I disagree. > The 2 main deferred features -- partial locking and notifications -- > are both simply speed optimizations, which impact a relatively small > number of use cases. We don't have any serialization in SNMP or > CLI at all! Concurrent writes can clobber config now, but this > doesn't seem to be a big problem. I'm not convinced the lack > of locked concurrent writes in NETCONF is a problem yet. While I would prefer that NETCONF supports partial locking I can live without this feature for now. However this feature is number 2 on my feature list with the number 1 feature listed below. > Notifications essentially provide a speed improvement over polling > techniques. Currently, many CLI applications use SNMP notifications > and SYSLOG for this purpose. The convenience of receiving async > messages within a NETCONF session is probably balanced out by > the increased localized cost of the NETCONF implementation, and > most likely does not represent a significant percentage of either > the implementation or deployment complexity. Polling is not a good substitute for notifications. Polling does not scale both with a large box and across large networks. Notifications are simply required and required within NETCONF. Using SNMP or Syslog for notifications does not provide the integrated solution required to build consolidated and robust applications. > IMO, the lack of these deferred features has no significant impact > on the usefulness of NETCONF 1.0. > > As for NETMOD -- I don't see much hope of a WG agreeing on the > one true NETCONF data modeling language. I agree that would > be the ideal from a standards-POV, but not realistic or even > close to operationally optimal. E.g., A scheme tuned for SNMP > integration isn't going to work well for CLI-oriented configuration. > > Andy Regards, /gww ------_=_NextPart_001_01C562D5.1A58326A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: no NETCONF WG meeting planned for Paris

Inline.

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf= .org] On
> Behalf Of Andy Bierman
> Sent: Friday, May 27, 2005 09:23
> To: dbharrington@comcast.net
> Cc: Chisholm, Sharon [CAR:5K50:EXCH]; = 'netconf'
> Subject: Re: no NETCONF WG meeting planned for = Paris
>
> I disagree.
> The 2 main deferred features -- partial locking = and notifications --
> are both simply speed optimizations, which = impact a relatively small
> number of use cases.   We don't have = any serialization in SNMP or
> CLI at all!  Concurrent writes can clobber = config now, but this
> doesn't seem to be a big problem.  I'm not = convinced the lack
> of locked concurrent writes in NETCONF is a = problem yet.

While I would prefer that NETCONF supports partial = locking I can live without this feature for now. However this feature = is number 2 on my feature list with the number 1 feature listed = below.

 
> Notifications essentially provide a speed = improvement over polling
> techniques.  Currently, many CLI = applications use SNMP notifications
> and SYSLOG for this purpose.  The = convenience of receiving async
> messages within a NETCONF session is probably = balanced out by
> the increased localized cost of the NETCONF = implementation, and
> most likely does not represent a significant = percentage of either
> the implementation or deployment = complexity.

Polling is not a good substitute for notifications. = Polling does not scale both with a large box and across large networks. = Notifications are simply required and required within NETCONF. Using = SNMP or Syslog for notifications does not provide the integrated = solution required to build consolidated and robust = applications.

 
> IMO, the lack of these deferred features has no = significant impact
> on the usefulness of NETCONF 1.0.
>
> As for NETMOD -- I don't see much hope of a WG = agreeing on the
> one true NETCONF data modeling language.  = I agree that would
> be the ideal from a standards-POV, but not = realistic or even
> close to operationally optimal.  E.g., A = scheme tuned for SNMP
> integration isn't going to work well for = CLI-oriented configuration.
>
> Andy

Regards, /gww

------_=_NextPart_001_01C562D5.1A58326A-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri May 27 13:17:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00129 for ; Fri, 27 May 2005 13:17:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbiMx-000H0X-8C for netconf-data@psg.com; Fri, 27 May 2005 17:11:35 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbiMw-000H0J-Dp for netconf@ops.ietf.org; Fri, 27 May 2005 17:11:34 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 27 May 2005 10:11:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,144,1115017200"; d="scan'208"; a="320913824:sNHT32138592" Received: from gluon.jnpr.net ([172.24.15.23]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 10:11:33 -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: no NETCONF WG meeting planned for Paris Date: Fri, 27 May 2005 10:11:32 -0700 Message-ID: Thread-Topic: no NETCONF WG meeting planned for Paris Thread-Index: AcViv3fFIkafJ8otSvGZOQiMxPfjXwAHVj9A From: "Faye Ly" To: "Andy Bierman" , Cc: "Sharon Chisholm" , "netconf" X-OriginalArrivalTime: 27 May 2005 17:11:33.0274 (UTC) FILETIME=[21B61FA0:01C562DF] 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 Andy, Very well said! I wonder if anybody has considered the following requirements for the need of notification besides SNMP and SYSLOG: (Sharon, if this duplicates your requirements I apologize.) 1. Customer may or may not want to punch so many holes in their firewall for management purpose. SNMP, SYSLOG and NETCONF all have different ports. Having a single TLS port helps eliminate the administration cost. 2. SNMP is not secure despite of v3. I think we have gone through this many times and not many customers seem to be deploying v3? Why, I am not an expert. I think NETCONF is very well designed with the security and notification channel is a natural next step. Again this saves admin cost that once you setup one secured management port you do both config and notification using the same port. =20 3. The scalability of SNMP traps is great for network devices but there has been some new requirement like the security device. The later sends a lot more logs than regular network device. Soaking no longer works as each log needs to be sent to the server to be examined. But I do agree with you that this might be a special case and we should not change the overall model just because some corner case. This largely depends on the member of this mailing list. Is this a high requirement for other network device as well? Best, -faye -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Friday, May 27, 2005 6:23 AM To: dbharrington@comcast.net Cc: 'Sharon Chisholm'; 'netconf' Subject: Re: no NETCONF WG meeting planned for Paris David B Harrington wrote: >Hi Andy=20 > > =20 > >>There are some pretty powerful features within a >>decent transaction model to act on that bucket of XML content. >>I know some of us on the design team we're really just >>trying to eliminate screen-scraping the CLI with 1.0. >>Even if NETCONF is just used as a programmatic interface >>to the CLI at first, this is better than screen-scraping. >> =20 >> > >And I strongly support that vision. Screen-scraping needs to go.=20 > >But we also need to move past the constraint that any operator must be >able to lock the whole configuration to modify it, and a large number >of other issues that you have collected during the development of >netconf 1.0. Just changing from screen-scraping to XML isn't enough to >meet operators' needs, even if it is a big step in the right >direction. > =20 > I disagree. The 2 main deferred features -- partial locking and notifications -- are both simply speed optimizations, which impact a relatively small number of use cases. We don't have any serialization in SNMP or CLI at all! Concurrent writes can clobber config now, but this doesn't seem to be a big problem. I'm not convinced the lack of locked concurrent writes in NETCONF is a problem yet. Notifications essentially provide a speed improvement over polling techniques. Currently, many CLI applications use SNMP notifications and SYSLOG for this purpose. The convenience of receiving async messages within a NETCONF session is probably balanced out by the increased localized cost of the NETCONF implementation, and most likely does not represent a significant percentage of either the implementation or deployment complexity. IMO, the lack of these deferred features has no significant impact on the usefulness of NETCONF 1.0. As for NETMOD -- I don't see much hope of a WG agreeing on the one true NETCONF data modeling language. I agree that would be the ideal from a standards-POV, but not realistic or even close to operationally optimal. E.g., A scheme tuned for SNMP integration isn't going to work well for CLI-oriented configuration. 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 Sat May 28 13:44:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20302 for ; Sat, 28 May 2005 13:44:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dc5Ck-0009j8-Sg for netconf-data@psg.com; Sat, 28 May 2005 17:34:34 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dc5Cg-0009iZ-Tl for netconf@ops.ietf.org; Sat, 28 May 2005 17:34:31 +0000 Received: (qmail 25276 invoked by uid 78); 28 May 2005 16:34:30 -0000 Received: from unknown (HELO ?192.168.0.11?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 28 May 2005 16:34:30 -0000 Message-ID: <42989D95.5030609@andybierman.com> Date: Sat, 28 May 2005 09:34:29 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: NETCONF Notifications 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.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 Hi, Let's start a thread to see if we agree on the problem we're trying to solve. First, let's remember where we left off. Here's what I remember: - we wanted to simply adopt RFC 3195 for notifications but decided that this was a problem because it was BEEP-only - our solutions for mapping multiple channels to SSH and SOAP mappings was not approved by the WG and dropped. Notifications over SOAP/HTTP were particularly clumsy (IMO). - the lack of any notification filtering (i.e., default is get-all) was a concern, but so was simply providing a proprietary hook instead of a standard solution for notification filtering. What did I forget (or remember wrong)? IMO, it's important that the NM application not have to use notifications differently (via capabilities) depending on the NETCONF application mapping in use for a particular session. I could live with a BEEP-only notification solution too, to solve this problem in minutes instead of weeks. I want to know what the WG thinks... 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 Sat May 28 20:21:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14596 for ; Sat, 28 May 2005 20:21:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcBPS-000GaK-Ol for netconf-data@psg.com; Sun, 29 May 2005 00:12:06 +0000 Received: from [85.73.136.180] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcBPP-000Ga2-PV for netconf@ops.ietf.org; Sun, 29 May 2005 00:12:04 +0000 Received: by boskop.local (Postfix, from userid 501) id D36B330ADF7; Sun, 29 May 2005 02:12:00 +0200 (CEST) Date: Sun, 29 May 2005 02:12:00 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf Subject: Re: NETCONF Notifications Message-ID: <20050529001200.GA23205@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf References: <42989D95.5030609@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42989D95.5030609@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 Sat, May 28, 2005 at 09:34:29AM -0700, Andy Bierman wrote: > Let's start a thread to see if we agree on the problem we're trying to > solve. First, let's remember where we left off. I think it is important to not ignore what is going on in the syslog WG. In particular, seems to be relevant. The only strong reason I see for a netconf notification transport would be the reuse of security associations. Perhaps a syslog mapping over ssh would kind of solve the problem. Bottom line: I am not really sure yet a notification channel within netconf is essential. Even if it is, we should not be blind and ignore that syslog is out there and that there is active work to build from the original BSD design and which is not bound to BEEP. /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 Sun May 29 07:21:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09114 for ; Sun, 29 May 2005 07:21:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcLh9-000Gbw-35 for netconf-data@psg.com; Sun, 29 May 2005 11:11:03 +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 1DcLh5-000GbQ-8G for netconf@ops.ietf.org; Sun, 29 May 2005 11:10:59 +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 j4TAxOq9006011 for ; Sun, 29 May 2005 06:59:24 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j4TAxIq9005801 for ; Sun, 29 May 2005 06:59:19 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: no NETCONF WG meeting planned for Paris Date: Sun, 29 May 2005 14:10:49 +0300 Message-ID: Thread-Topic: no NETCONF WG meeting planned for Paris Thread-Index: AcViHerzgEAOd47RSJSZhCuGNmOOXACIAd7Q From: "Romascanu, Dan \(Dan\)" To: Cc: , "Sharon Chisholm" , "netconf" 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: quoted-printable =20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Thursday, May 26, 2005 9:08 PM > To: Romascanu, Dan (Dan) > Cc: dbharrington@comcast.net; Sharon Chisholm; netconf > Subject: Re: no NETCONF WG meeting planned for Paris >=20 > On Thu, May 26, 2005 at 06:55:21PM +0300, Romascanu, Dan (Dan) wrote: >=20 > > In Minneapolis the Netconf WG decided to continue the NETMOD work=20 > > within Netconf rather than creating a new WG. >=20 > Can a WG decide something during an IETF meeting? >=20 Here are the minutes: ---------------------------- NETMOD Passes to Sharon for her presentation on data modeling.=20 Discussion ended with the suggestion to produce drafts about data modeling before the Paris meeting, and discuss them there.=20 --------------------------- ... Let us not become lawyers ... It was a discussion about if and where to do future work ... No decision, just room consensus, or what I got from it ... And we can debate this on the list ... Which seems to be what we are doing ...=20 Dan -- 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 May 30 04:56:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28311 for ; Mon, 30 May 2005 04:56:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcfpT-0006hK-CG for netconf-data@psg.com; Mon, 30 May 2005 08:40:59 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcfpS-0006h8-Md for netconf@ops.ietf.org; Mon, 30 May 2005 08:40:58 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 May 2005 01:40:58 -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 j4U8eqbw026094; Mon, 30 May 2005 01:40:53 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4446.cisco.com [10.61.81.93]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4U8TIVg027999; Mon, 30 May 2005 01:29:25 -0700 Message-ID: <429AD183.2080505@cisco.com> Date: Mon, 30 May 2005 10:40:35 +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: Andy Bierman , netconf Subject: Re: NETCONF Notifications References: <42989D95.5030609@andybierman.com> <20050529001200.GA23205@boskop.local> In-Reply-To: <20050529001200.GA23205@boskop.local> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117441769.451008"; x:"432200"; a:"rsa-sha1"; b:"nofws:1208"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"IrJO3Z9RmUfwv+ZHfwRxeMnMJzr8ujP/OOBgBXpXH0clF8i8PCueCyuuZczPArT/DhL4BdQH" "Bm4wg33RqlMWVkRYY6q7n5K7QKZrw7a7nrwn1RHFF5gBrHMpn5C1nLostr6zRHX92EEUBwYyIZ6" "848Sp5AjHE63CPyJ+eqvfq6Q="; c:"Date: Mon, 30 May 2005 10:40:35 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: NETCONF Notifications" 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 Juergen, SYSLOG is out there. Anyone can use it. However, for reliable and secure SYSLOG you have to do something different. Particularly, for reliable. That's what 3195 was meant to cover. If you want messages signed individually then that's a different kettle of fish, but to simply not have the messages go over the clear one can use the existing BEEP profile just fine. Realistically from a BEEP perspective I'm not even sure we need to make a change to NETCONF to enable 3195 support. We simply need to indicate that during a the profile is available. But this doesn't work for the other protocols (ssh, http). Eliot Juergen Schoenwaelder wrote: > On Sat, May 28, 2005 at 09:34:29AM -0700, Andy Bierman wrote: > > >>Let's start a thread to see if we agree on the problem we're trying to >>solve. First, let's remember where we left off. > > > I think it is important to not ignore what is going on in the syslog > WG. In particular, seems to be > relevant. > > The only strong reason I see for a netconf notification transport > would be the reuse of security associations. Perhaps a syslog mapping > over ssh would kind of solve the problem. > > Bottom line: I am not really sure yet a notification channel within > netconf is essential. Even if it is, we should not be blind and ignore > that syslog is out there and that there is active work to build from > the original BSD design and which is not bound to BEEP. > > /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 Mon May 30 13:58:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00877 for ; Mon, 30 May 2005 13:58:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcoMS-000KnJ-2T for netconf-data@psg.com; Mon, 30 May 2005 17:47:36 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcoMO-000Kmt-M2 for netconf@ops.ietf.org; Mon, 30 May 2005 17:47:32 +0000 Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4UHlTP15462 for ; Mon, 30 May 2005 13:47:29 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4UHlRi23581 for ; Mon, 30 May 2005 13:47:27 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 May 2005 13:47:27 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40390BC6D@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf Subject: RE: NETCONF Notifications Date: Mon, 30 May 2005 13:47:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 A number of us are very plugged into the current work being done in syslog. This does not mean there is not interest in netconf as a potential evolution of that space. I also don't think we need to even make it our primary use case for looking at asynchronous messaging. There are a number of cases where these asynchronous messages are used very much to support configuration operations, which I know is what the working group chairs are looking to see. The things to keep in mind when not wanting to preclude other forms of asynchronous messages is the idea what we may want to be able to easily identify the type of message to aid filtering and predictable content and also that asynchronous messages may be short in some cases and much longer in others. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear Sent: Monday, May 30, 2005 4:41 AM To: j.schoenwaelder@iu-bremen.de Cc: Andy Bierman; netconf Subject: Re: NETCONF Notifications Juergen, SYSLOG is out there. Anyone can use it. However, for reliable and secure SYSLOG you have to do something different. Particularly, for reliable. That's what 3195 was meant to cover. If you want messages signed individually then that's a different kettle of fish, but to simply not have the messages go over the clear one can use the existing BEEP profile just fine. Realistically from a BEEP perspective I'm not even sure we need to make a change to NETCONF to enable 3195 support. We simply need to indicate that during a the profile is available. But this doesn't work for the other protocols (ssh, http). Eliot Juergen Schoenwaelder wrote: > On Sat, May 28, 2005 at 09:34:29AM -0700, Andy Bierman wrote: > > >>Let's start a thread to see if we agree on the problem we're trying to >>solve. First, let's remember where we left off. > > > I think it is important to not ignore what is going on in the syslog > WG. In particular, seems to be > relevant. > > The only strong reason I see for a netconf notification transport > would be the reuse of security associations. Perhaps a syslog mapping > over ssh would kind of solve the problem. > > Bottom line: I am not really sure yet a notification channel within > netconf is essential. Even if it is, we should not be blind and ignore > that syslog is out there and that there is active work to build from > the original BSD design and which is not bound to BEEP. > > /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: -- 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 May 30 14:54:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04777 for ; Mon, 30 May 2005 14:54:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcpIz-000Oqf-Cj for netconf-data@psg.com; Mon, 30 May 2005 18:48:05 +0000 Received: from [85.73.134.197] (helo=boskop.local) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcpIx-000OqO-Bs for netconf@ops.ietf.org; Mon, 30 May 2005 18:48:03 +0000 Received: by boskop.local (Postfix, from userid 501) id 062E630B766; Mon, 30 May 2005 11:28:36 +0200 (CEST) Date: Mon, 30 May 2005 11:28:36 +0200 From: Juergen Schoenwaelder To: Eliot Lear Cc: Andy Bierman , netconf Subject: Re: NETCONF Notifications Message-ID: <20050530092836.GA24609@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Eliot Lear , Andy Bierman , netconf References: <42989D95.5030609@andybierman.com> <20050529001200.GA23205@boskop.local> <429AD183.2080505@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429AD183.2080505@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 Mon, May 30, 2005 at 10:40:35AM +0200, Eliot Lear wrote: > SYSLOG is out there. Anyone can use it. However, for reliable and > secure SYSLOG you have to do something different. Particularly, for > reliable. That's what 3195 was meant to cover. If you want messages > signed individually then that's a different kettle of fish, but to > simply not have the messages go over the clear one can use the existing > BEEP profile just fine. quite clearly states the following: : This protocol utilizes a layered : architecture, which allows the use of any number of transport : protocols for transmission of syslog messages. So I believe syslog is moving to support other transports and not only BEEP for reliable delivery. /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 May 30 15:26:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07704 for ; Mon, 30 May 2005 15:26:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dcpq3-0001L4-Mi for netconf-data@psg.com; Mon, 30 May 2005 19:22:15 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dcpq3-0001Kr-58 for netconf@ops.ietf.org; Mon, 30 May 2005 19:22:15 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 May 2005 12:22:14 -0700 X-IronPort-AV: i="3.93,151,1115017200"; d="scan'208"; a="271655066:sNHT30202468" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4UJMBlq012050; Mon, 30 May 2005 12:22:12 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp536.cisco.com [10.61.66.24]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4UJAjjq030276; Mon, 30 May 2005 12:10:45 -0700 Message-ID: <429B67DF.4020009@cisco.com> Date: Mon, 30 May 2005 21:22:07 +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: Andy Bierman , netconf Subject: Re: NETCONF Notifications References: <42989D95.5030609@andybierman.com> <20050529001200.GA23205@boskop.local> <429AD183.2080505@cisco.com> <20050530092836.GA24609@boskop.local> In-Reply-To: <20050530092836.GA24609@boskop.local> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117480247.175280"; x:"432200"; a:"rsa-sha1"; b:"nofws:167"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"QXhE2V90V1bCthmj/flW2MduoFakYSk9mXS0aM/OpqXYSR8NkHm5U/iPGsxU6qfAwMLqiXZj" "JpwCP2lCu9HGavSzZVtsnry7kbzLZprSYlBWl9j5a/bblIi4W+7j9mSV8vAnyZrCbF+jPrft1+n" "siY3TXTIgQ+21UpO9/dZfv5c="; c:"Date: Mon, 30 May 2005 21:22:07 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: NETCONF Notifications" 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 Juergen Schoenwaelder wrote: > So I believe syslog is moving to support other transports and not only > BEEP for reliable delivery. We'll have 3 or 4 of those as well. Great for interoperability. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon May 30 15:31:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08138 for ; Mon, 30 May 2005 15:31:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcpvV-00020u-T7 for netconf-data@psg.com; Mon, 30 May 2005 19:27:53 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcpvU-00020X-9x for netconf@ops.ietf.org; Mon, 30 May 2005 19:27:52 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 30 May 2005 12:27:50 -0700 X-IronPort-AV: i="3.93,151,1115017200"; d="scan'208"; a="639565831:sNHT27754112" Received: from sjc-xdm1.cisco.com (sjc-xdm1.cisco.com [171.71.162.58]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4UJRjbx007349; Mon, 30 May 2005 12:27:45 -0700 (PDT) Date: Mon, 30 May 2005 12:27:47 -0700 (PDT) From: Chris Lonvick To: Juergen Schoenwaelder cc: Eliot Lear , Andy Bierman , netconf Subject: Re: NETCONF Notifications In-Reply-To: <20050530092836.GA24609@boskop.local> Message-ID: References: <42989D95.5030609@andybierman.com> <20050529001200.GA23205@boskop.local> <429AD183.2080505@cisco.com> <20050530092836.GA24609@boskop.local> 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, On Mon, 30 May 2005, Juergen Schoenwaelder wrote: > On Mon, May 30, 2005 at 10:40:35AM +0200, Eliot Lear wrote: > > > SYSLOG is out there. Anyone can use it. However, for reliable and > > secure SYSLOG you have to do something different. Particularly, for > > reliable. That's what 3195 was meant to cover. If you want messages > > signed individually then that's a different kettle of fish, but to > > simply not have the messages go over the clear one can use the existing > > BEEP profile just fine. > > quite clearly states the following: > > : This protocol utilizes a layered > : architecture, which allows the use of any number of transport > : protocols for transmission of syslog messages. > > So I believe syslog is moving to support other transports and not only > BEEP for reliable delivery. That statement is there to allow for udp and the future possibilities of better transports. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-04.txt "Transmission of syslog messages over UDP" allows (more-r-less) backwards compatibility with everything that currently does syslog/udp. The WG (or successors) could also allow other protocols in the future but RFC 3195 is currently on the standards track for the syslog WG. We made the decision a very long time ago to separate the protcol from the transports for just this reason. Thanks, Chris -- 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: