From owner-netconf@ops.ietf.org Thu Dec 01 16:09:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehvgb-0000mf-B0 for netconf-archive@megatron.ietf.org; Thu, 01 Dec 2005 16:09:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02992 for ; Thu, 1 Dec 2005 16:08:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhvWP-00030T-A6 for netconf-data@psg.com; Thu, 01 Dec 2005 20:59:17 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhvWM-0002zv-3M for netconf@ops.ietf.org; Thu, 01 Dec 2005 20:59:14 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 01 Dec 2005 12:59:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,202,1131350400"; d="scan'208"; a="513348626:sNHT25602556" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 12:59:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IANA considerations update for NETCONF protocol draft Date: Thu, 1 Dec 2005 12:58:50 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30CB78@photon.jnpr.net> Thread-Topic: IANA considerations update for NETCONF protocol draft Thread-Index: AcX1/G+XESb7yqbPSI+WwoQKq4ugdAAte5cg From: "Rob Enns" To: "Wijnen, Bert \(Bert\)" , X-OriginalArrivalTime: 01 Dec 2005 20:59:13.0410 (UTC) FILETIME=[15727620:01C5F6BA] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks Bert, comments and updated sections below. > for an informational or experimental. > So that is why I think I prefer "Standards Action". "Standards Action" is fine with me too. =20 > > The initial content of the registry will be the capability URNs > > defined in Section 8. Once further experience is gained with > > NETCONF, this sub-namespace may be used for additional purposes. > >=20 > I think last sentence can go away, because defining the registry and > requiring Standards Action (or IETF consensus if that is what the WG > wants) basically allow for that Netconf impact anyway. Ok. > > 10.4. NETCONF Enterprise Capability URNs > >=20 > > This document requests that IANA create a registry for allocating > > NETCONF capability identifiers to enterprises. =20 > Allocation from the > > registry is on a First Come First Served basis, but a=20 > specification > > is required in the form of Appendix C of this document. > >=20 >=20 > Mmm the template in appendix C looks (to me anyway) a template to > register new entries in the "standards" space, not in the vendor=20 > or enterprise space. Or am I missing something? We can replace the "standard" NETCONF URN prefix in Appendix C with an {insert your capability URI here} wildcard and the single Appendix C should be ok. Here are the 2 updated sections from IANA considerations. 10.3. NETCONF Capability URNs This document requests that IANA create a registry for allocating NETCONF capability identifiers. Allocation from the registry requires IETF Standards Action. The initial content of the registry will be the capability URNs defined in Section 8. Following the guidelines in RFC 3553 [7], IANA is requested to assign a NETCONF sub-namespace as follows: Registry name: netconf Specification: Section 8 of this document. Repository: The following table. +--------------------+----------------------------------------------+ | Index | Capability Identifier | +--------------------+----------------------------------------------+ | :writable-running | urn:ietf:params:netconf:capability:writable- | | | running:1.0 | | :candidate | urn:ietf:params:netconf:capability:candidate | | | :1.0 | | :confirmed-commit | urn:ietf:params:netconf:capability:confirmed | | | -commit:1.0 | | :rollback-on-error | urn:ietf:params:netconf:capability:rollback- | | | on-error:1.0 | | :validate | urn:ietf:params:netconf:capability:validate: | | | 1.0 | | :startup | urn:ietf:params:netconf:capability:startup:1 | | | .0 | | :url | urn:ietf:params:netconf:capability:url:1.0 | | :xpath | urn:ietf:params:netconf:capability:xpath:1.0 | +--------------------+----------------------------------------------+ Index value: The capability name. 10.4. NETCONF Enterprise Capability URNs This document requests that IANA create a registry for allocating NETCONF capability identifiers to enterprises. Allocation from the registry is on a First Come First Served basis, but a specification is required in the form of Appendix C of this document. Following the guidelines in RFC 3553 [7], IANA is requested to assign a NETCONF sub-namespace as follows: Registry name: netconf-enterprise Specification: To be provided by the registrant. The specification document must conform to Appendix C of this document. Repository: IANA is requested to store the submitted specifications in a public location such as http://www.iana.org/assignments/netconf/capabilities.html. Index value: The capability name. -- to 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 Dec 01 16:29:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehvzj-0004rv-Lr for netconf-archive@megatron.ietf.org; Thu, 01 Dec 2005 16:29:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12145 for ; Thu, 1 Dec 2005 16:28:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhvvN-0005x6-2h for netconf-data@psg.com; Thu, 01 Dec 2005 21:25:05 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhvvJ-0005w6-SH for netconf@ops.ietf.org; Thu, 01 Dec 2005 21:25:01 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 01 Dec 2005 13:24:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,203,1131350400"; d="scan'208"; a="513352234:sNHT57723992828" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 13:24:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard Date: Thu, 1 Dec 2005 13:24:16 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30CB8A@photon.jnpr.net> Thread-Topic: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard Thread-Index: AcX18ver5iKxBXzqQuWvUcOyHBf+nwAyk3gg From: "Rob Enns" To: "Leslie Daigle" , "Pekka Savola" Cc: , X-OriginalArrivalTime: 01 Dec 2005 21:24:40.0641 (UTC) FILETIME=[A3BF6B10:01C5F6BD] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Is it really really necessary to refer back to RFC1630? RFC3986 > is the current URI syntax document, and has the benefit of > being standards-track. Since the reference seems to be for the > purpose of "defining" the URI, surely the (current) syntax document > would be appropriate? RFC3986 looks perfect, 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 Thu Dec 01 16:53:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhwMu-0002yd-Hk for netconf-archive@megatron.ietf.org; Thu, 01 Dec 2005 16:53:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20935 for ; Thu, 1 Dec 2005 16:52:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhwC8-0008A4-Ck for netconf-data@psg.com; Thu, 01 Dec 2005 21:42:24 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhwC5-00089Y-4I for netconf@ops.ietf.org; Thu, 01 Dec 2005 21:42:21 +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 jB1LgI5o009708; Thu, 1 Dec 2005 15:42:19 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Dec 2005 22:41:52 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508C0A3A0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Rob Enns , "Wijnen, Bert (Bert)" , netconf@ops.ietf.org Subject: RE: IANA considerations update for NETCONF protocol draft Date: Thu, 1 Dec 2005 22:42:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk > 10.4. NETCONF Enterprise Capability URNs > > This document requests that IANA create a registry for allocating > NETCONF capability identifiers to enterprises. Allocation from the > registry is on a First Come First Served basis, but a specification > is required in the form of Appendix C of this document. > > Following the guidelines in RFC 3553 [7], IANA is requested to assign > a NETCONF sub-namespace as follows: > > Registry name: netconf-enterprise > > Specification: To be provided by the registrant. The specification > document must conform to Appendix C of this document. > But appendix C now states: C.1.3. Capability Identifier The {name} is identified by following capability string: urn:ietf:params:xml:ns:netconf:capability:{name}:1.0 Which to me seems to apply be in sync with sect 10.3 for sect 10.4, it probably should be: urn:ietf:params:xml:ns:netconf-enterprise:capability:{name}:1.0 But even then, how do you avoid conflicts between multiple enterprises, and how do you you which capability is from which enterprise? Bert > Repository: IANA is requested to store the submitted specifications > in a public location such as > http://www.iana.org/assignments/netconf/capabilities.html. > > Index value: The capability name. > -- to 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 Dec 01 17:12:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehwf8-0004F3-Og for netconf-archive@megatron.ietf.org; Thu, 01 Dec 2005 17:12:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22876 for ; Thu, 1 Dec 2005 17:11:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhwXq-000AXS-Em for netconf-data@psg.com; Thu, 01 Dec 2005 22:04:50 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhwXn-000AXC-4L for netconf@ops.ietf.org; Thu, 01 Dec 2005 22:04:47 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jB1M4i054272; Thu, 1 Dec 2005 14:04:44 -0800 (PST) (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 jB1M4d557188; Thu, 1 Dec 2005 14:04:39 -0800 (PST) (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 jB1M9qYE024579; Thu, 1 Dec 2005 17:09:56 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512012209.jB1M9qYE024579@idle.juniper.net> To: "Wijnen, Bert (Bert)" cc: Rob Enns , netconf@ops.ietf.org Subject: Re: IANA considerations update for NETCONF protocol draft In-Reply-To: Your message of "Thu, 01 Dec 2005 22:42:06 +0100." <7D5D48D2CAA3D84C813F5B154F43B15508C0A3A0@nl0006exch001u.nl.lucent.com> Date: Thu, 01 Dec 2005 17:09:52 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Wijnen, Bert (Bert)" writes: >But even then, how do you avoid conflicts between multiple enterprises, >and how do you you which capability is from which enterprise? The normal rules for XML namespaces should be used, where an URL starts with an identifying domain name: urn:ietf:params:xml:ns:netconf:base:1.0 urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 urn:ietf:params:xml:ns:netconf:capability:validate:1.0 urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file http://xml.juniper.net/netconf/junos/1.0 36908 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 Dec 02 14:45:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiGqV-0005yH-2E for netconf-archive@megatron.ietf.org; Fri, 02 Dec 2005 14:45:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for ; Fri, 2 Dec 2005 14:44:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EiGiC-000435-M2 for netconf-data@psg.com; Fri, 02 Dec 2005 19:36:52 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EiGi9-00042n-F9 for netconf@ops.ietf.org; Fri, 02 Dec 2005 19:36:49 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 02 Dec 2005 11:36:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,207,1131350400"; d="scan'208"; a="513515228:sNHT22635316" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Dec 2005 11:36:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IANA considerations update for NETCONF protocol draft Date: Fri, 2 Dec 2005 11:36:37 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D9B7568@photon.jnpr.net> Thread-Topic: IANA considerations update for NETCONF protocol draft Thread-Index: AcX2wCNOKQFuzg80Q+aWcTwwAAFHKQArQWNA From: "Rob Enns" To: "Wijnen, Bert \(Bert\)" , X-OriginalArrivalTime: 02 Dec 2005 19:36:48.0660 (UTC) FILETIME=[BC8F3D40:01C5F777] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > But appendix C now states: >=20 > C.1.3. Capability Identifier >=20 > The {name} is identified by following capability string: >=20 > urn:ietf:params:xml:ns:netconf:capability:{name}:1.0 >=20 > Which to me seems to apply be in sync with sect 10.3 > for sect 10.4, it probably should be: >=20 > urn:ietf:params:xml:ns:netconf-enterprise:capability:{name}:1.0 >=20 > But even then, how do you avoid conflicts between multiple=20 > enterprises, > and how do you you which capability is from which enterprise? >=20 > Bert I didn't post the updated appendix C but the idea is that we update it to remove the netconf URN (like you did above) and request that enterprise capabilities are identified with a URI. Any URI that uniquely identifies the enterprise capability should be=20 sufficient. So for example an enterprise could register: http://www.example.net/netconf/mycapability The requirement on IANA would be to verify that the URI contains a unique enterprise identifier, such as a DNS name, and that=20 the registered capability URI is unique. I suspect IANA might feel this is too loosey goosey and not appropriate for IANA allocation. An alternative would be to have IANA allocate structured URNs for the NETCONF enterprise capabilities using enterprise names or enterprise OIDs. I don't think the adminsitrative hair is worth it for enterprise capabilities (because there won't be all that many). The last alternative would be to forget the idea of IANA allocated enterprise capabilities, and let enterprises do their own thing=20 with URIs. I'd like the WG to weigh in on this question. 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 Dec 02 15:11:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiHFs-0002oN-WE for netconf-archive@megatron.ietf.org; Fri, 02 Dec 2005 15:11:41 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09138 for ; Fri, 2 Dec 2005 15:10:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EiHAZ-00088B-1n for netconf-data@psg.com; Fri, 02 Dec 2005 20:06:11 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EiHAV-00087r-Ll for netconf@ops.ietf.org; Fri, 02 Dec 2005 20:06:07 +0000 Received: (qmail 26449 invoked by uid 78); 2 Dec 2005 20:06:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.58 with SMTP; 2 Dec 2005 20:06:05 -0000 Message-ID: <4390A941.1040006@andybierman.com> Date: Fri, 02 Dec 2005 12:06:25 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: "Wijnen, Bert \(Bert\)" , netconf@ops.ietf.org Subject: Re: IANA considerations update for NETCONF protocol draft References: <062B922B6EC55149B5A267ECE78E5D440D9B7568@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440D9B7568@photon.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Enns wrote: >>But appendix C now states: >> >> C.1.3. Capability Identifier >> >> The {name} is identified by following capability string: >> >> urn:ietf:params:xml:ns:netconf:capability:{name}:1.0 >> >>Which to me seems to apply be in sync with sect 10.3 >>for sect 10.4, it probably should be: >> >> urn:ietf:params:xml:ns:netconf-enterprise:capability:{name}:1.0 >> >>But even then, how do you avoid conflicts between multiple >>enterprises, >>and how do you you which capability is from which enterprise? >> >>Bert >> >> > >I didn't post the updated appendix C but the idea is that we update >it to remove the netconf URN (like you did above) and request that >enterprise capabilities are identified with a URI. > >Any URI that uniquely identifies the enterprise capability should be >sufficient. So for example an enterprise could register: > >http://www.example.net/netconf/mycapability > >The requirement on IANA would be to verify that the URI contains >a unique enterprise identifier, such as a DNS name, and that >the registered capability URI is unique. I suspect IANA might >feel this is too loosey goosey and not appropriate for IANA allocation. > >An alternative would be to have IANA allocate structured URNs for the >NETCONF enterprise capabilities using enterprise names or enterprise >OIDs. I don't think the adminsitrative hair is worth it for enterprise >capabilities (because there won't be all that many). > >The last alternative would be to forget the idea of IANA allocated >enterprise capabilities, and let enterprises do their own thing >with URIs. > >I'd like the WG to weigh in on this question. > > I don't think we really need this Enterprise Capability Registry. We created our own template for extending the standard (Appendix C) but that does not mean that IANA or the IETF needs to be involved whatsoever in proprietary extensions to the NETCONF protocol. >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 Dec 03 05:33:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiUhm-0001B9-Nd for netconf-archive@megatron.ietf.org; Sat, 03 Dec 2005 05:33:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16150 for ; Sat, 3 Dec 2005 05:32:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EiUZ4-0000VO-M0 for netconf-data@psg.com; Sat, 03 Dec 2005 10:24:22 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EiUZ1-0000SJ-0H for netconf@ops.ietf.org; Sat, 03 Dec 2005 10:24:19 +0000 Received: (qmail 9075 invoked by uid 78); 3 Dec 2005 10:24:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.54 with SMTP; 3 Dec 2005 10:24:18 -0000 Message-ID: <4391728E.1050400@andybierman.com> Date: Sat, 03 Dec 2005 02:25:18 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dbharrington@comcast.net CC: "'Chris Elliott'" , "'Phil Shafer'" , "'Balazs Lengyel'" , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <039e01c5f5d0$20135df0$0400a8c0@DJYXPY41> In-Reply-To: <039e01c5f5d0$20135df0$0400a8c0@DJYXPY41> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David B Harrington wrote: > > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Chris Elliott >> >>I'd rather not have to deal with two formats--and, yes, >>certain apps will >>have to deal with both formats and will have to try to resolve what >> >> >a > > >>particular SD-Param relates to in XML, or the SNMP MIB, or >>CLI...We have >>enough formats already. >> >> >> >I concur > > Unfortunately, this is precisely what will add to the Yet Another Format problem. If syslog WG goes in the SD-Param direction, and NETCONF creates its own XML encoding, then this WG will be responsible for the +1 in this case (not syslog). >David Harrington >dbharrington@comcast.net > > > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Dec 03 18:44:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eih3f-0003bJ-4d for netconf-archive@megatron.ietf.org; Sat, 03 Dec 2005 18:44:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14740 for ; Sat, 3 Dec 2005 18:43:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eiguv-000FKG-H7 for netconf-data@psg.com; Sat, 03 Dec 2005 23:35:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eigus-000FK0-Um for netconf@ops.ietf.org; Sat, 03 Dec 2005 23:35:42 +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 jB3NZWH5014663; Sat, 3 Dec 2005 15:35:36 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 3 Dec 2005 15:38:05 -0800 Message-ID: From: "McDonald, Ira" To: "'Andy Bierman'" , Rob Enns Cc: "Wijnen, Bert (Bert)" , netconf@ops.ietf.org Subject: RE: IANA considerations update for NETCONF protocol draft Date: Sat, 3 Dec 2005 15:37:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Andy Bierman wrote: > > Rob Enns wrote: > > > > >The last alternative would be to forget the idea of IANA allocated > >enterprise capabilities, and let enterprises do their own thing > >with URIs. > > > >I'd like the WG to weigh in on this question. > > > > > > I don't think we really need this Enterprise Capability Registry. > We created our own template for extending the standard (Appendix C) > but that does not mean that IANA or the IETF needs to be involved > whatsoever in proprietary extensions to the NETCONF protocol. > Forget the IANA Enterprise Capability Registry. Unless you bend IETF best practices badly, an IANA allocation should ALWAYS require _at_least_ IETF Designated Expert review. Instead, simply specify that Enterprise Capabilities MUST choose a _durable_ globally unique URI within one of the registered DNS domains for that enterprise (i.e., using GUIDs based on MAC address is NOT allowed). 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 -- to 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 Dec 04 12:45:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EixvH-0002sp-Rk for netconf-archive@megatron.ietf.org; Sun, 04 Dec 2005 12:45:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01142 for ; Sun, 4 Dec 2005 12:44:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eixns-000K73-Ab for netconf-data@psg.com; Sun, 04 Dec 2005 17:37:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eixnr-000K6k-Fl for netconf@ops.ietf.org; Sun, 04 Dec 2005 17:37:35 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB4HbUL18743 for ; Sun, 4 Dec 2005 12:37:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NETCONF Notifications: Consensus Points Date: Sun, 4 Dec 2005 12:37:28 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405F9429F@zcarhxm2.corp.nortel.com> Thread-Topic: NETCONF Notifications: Consensus Points Thread-Index: AcX0WZ3C+Qp1Ki77TumGSxhs+bCHjgEnvIbA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Because I don't think it is good engineering to add a lot of complexity for an optional-to-implement feature. There is way too much of that "kitchen-sink" approach in the IETF. Let's make it mandatory for everybody to implement if it's worth having. How many people still want it then? I don't. It can be added to the current proposal, but I've spoken with a lot of people who want robust messaging services, but they don't need this feature. Sharon -- to 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 Dec 04 13:48:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiyuR-0002BP-8O for netconf-archive@megatron.ietf.org; Sun, 04 Dec 2005 13:48:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05888 for ; Sun, 4 Dec 2005 13:47:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eiyoy-0001TM-Ec for netconf-data@psg.com; Sun, 04 Dec 2005 18:42:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eiyox-0001T7-Ch for netconf@ops.ietf.org; Sun, 04 Dec 2005 18:42:47 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jB4IdTi15581 for ; Sun, 4 Dec 2005 13:39:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NETCONF Notifications: Consensus Points Date: Sun, 4 Dec 2005 13:42:41 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405F942A3@zcarhxm2.corp.nortel.com> Thread-Topic: NETCONF Notifications: Consensus Points Thread-Index: AcX1MxhRBy4NFDLDQJqLTTwnFrSdYgDzgNPA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Couple points .... The SD-Param portion of the syslog message is not that much more economically encoded than the XML encoded one. Where you are getting all your size savings there is the bits which defines a set of information in a non-flexible order and encoding (no space, for example) of the information in the message.=20 We would often have these battles in SNMP MIBS, more in the proprietary space, about well-defined fields versus opaque blobs. People liked the opaque blobs because they allowed them to be clever and solve problems they couldn't using SMI, but then they were often more difficult to learn how to use and were not subjected to the same backwards compatibility rules. As someone more often then not ending up on the consuming end of management information, I tend to go for clarity over performance, but I recognize there are situations where more verbose encodings will make certain uses of the information intractable. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net]=20 Sent: Tuesday, November 29, 2005 5:25 PM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points=20 "Sharon Chisholm" writes: >I think bringing these in, not using SD-Param >grammar, but as properly tagged XML would be very very useful. XML has its uses, but log data is not one of them. We need to be careful that we don't start seeing everything as a nail to our xml hammer. XML is useful for encoding hierarchical data, but is horrible for simple flat data (try encoding a csv file in xml). XML is good at encoding data that is highly variable, but expensive for more normalizable data. XML is great for data interchange, where both sides of the conversation need to be flexible and resilient. But it's horrible for data storage. XML's overhead can be ignored for intermittent operations like configuration requests, but will kill you at high volume. Compare a notification in XML: RPD_RSVP_NBRUP my-host rpd 10.5.14.2 fe-1/3/0.0 RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 and the same data in syslog: Oct 18 16:01:37 my-host rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 The syslog-SD form of this would be something like: 1 888 4 00 2005-10-18-16:01:37 my-host rpd 2958 RPD_RSVP_NBRUP [JNPR-0 neighbor=3D"10.5.14.2" interface=3D"fe-1/3/0.0"] RSVP neighbor 10.5.14.2 = up on interface fe-1/3/0.0 (That should be close enough; I'm not an SD-guru) wc -c reports the lengths as 321, 104, and 168. I take it as a given that customers will use notification data from netconf in the same pattern we see with syslog data. They configure large volumes of data, which they store and use to investigate problems, either real-time or port-mortem. IMHO, the SD-PARAM version wins hands down, based on functionality .vs. footprint. I can filter by severity, date, msgid, and message content parameters. That's pretty much all I'm after. 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 Sun Dec 04 15:35:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej0Zg-0005FN-Rr for netconf-archive@megatron.ietf.org; Sun, 04 Dec 2005 15:35:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14654 for ; Sun, 4 Dec 2005 15:34:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ej0TV-000DB7-0j for netconf-data@psg.com; Sun, 04 Dec 2005 20:28:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ej0TT-000DAv-Up for netconf@ops.ietf.org; Sun, 04 Dec 2005 20:28:44 +0000 Received: (qmail 13107 invoked by uid 78); 4 Dec 2005 20:28:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.57 with SMTP; 4 Dec 2005 20:28:43 -0000 Message-ID: <4393517C.7080401@andybierman.com> Date: Sun, 04 Dec 2005 12:28:44 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <713043CE8B8E1348AF3C546DBE02C1B405F9429F@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405F9429F@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: > >Because I don't think it is good engineering to add a lot >of complexity for an optional-to-implement feature. >There is way too much of that "kitchen-sink" approach in the IETF. > >Let's make it mandatory for everybody to implement if it's worth having. >How many people still want it then? > > > >I don't. It can be added to the current proposal, but I've spoken with a >lot of people who want robust messaging services, but they don't need >this feature. > > > Ok -- "can be added" is sort of a chicken and egg thing. IMO, it's a non-trivial exercise to properly design and document this feature. The details cannot really be discussed without this exercise though. I'd like to settle this issue and move the charter proposal forward. I am declaring that the "application ack" feature is shelved further until a detailed written solution proposal is presented to the WG for consideration. The WG members can then decide second-order issues such as mandatory vs. optional, based on an evaluation of the proposal. Until then, we will move on without it. >Sharon > > 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 Sun Dec 04 15:44:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej0im-0007j4-0z for netconf-archive@megatron.ietf.org; Sun, 04 Dec 2005 15:44:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15486 for ; Sun, 4 Dec 2005 15:43:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ej0d0-000EHR-Gm for netconf-data@psg.com; Sun, 04 Dec 2005 20:38:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ej0cx-000EH7-FK for netconf@ops.ietf.org; Sun, 04 Dec 2005 20:38:31 +0000 Received: (qmail 30450 invoked from network); 4 Dec 2005 20:38:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.113 with SMTP; 4 Dec 2005 20:38:30 -0000 Message-ID: <439353C8.2020501@andybierman.com> Date: Sun, 04 Dec 2005 12:38:32 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <713043CE8B8E1348AF3C546DBE02C1B405F942A3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405F942A3@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: >hi > >Couple points .... > >The SD-Param portion of the syslog message is not that much more >economically encoded than the XML encoded one. Where you are getting all >your size savings there is the bits which defines a set of information >in a non-flexible order and encoding (no space, for example) of the >information in the message. > >We would often have these battles in SNMP MIBS, more in the proprietary >space, about well-defined fields versus opaque blobs. People liked the >opaque blobs because they allowed them to be clever and solve problems >they couldn't using SMI, but then they were often more difficult to >learn how to use and were not subjected to the same backwards >compatibility rules. > >As someone more often then not ending up on the consuming end of >management information, I tend to go for clarity over performance, but I >recognize there are situations where more verbose encodings will make >certain uses of the information intractable. > > > I think you are making valid points for the WG to consider. IMO, it is the information model elements, not the syntax, that is important. We have to agree on that model first. The actual syntax is not as high priority as other design goals, such as: - "keep the notification PDU the same syntax and semantics across all supported transports." The text specific to syslog can be removed and replaced with text that says: - "a notification content information model and encoding will be selected or specified." Can we agree on this much, update the charter text, and agree to get started? >Sharon > > Andy >-----Original Message----- >From: Phil Shafer [mailto:phil@juniper.net] >Sent: Tuesday, November 29, 2005 5:25 PM >To: Chisholm, Sharon [CAR:5K50:EXCH] >Cc: netconf@ops.ietf.org >Subject: Re: NETCONF Notifications: Consensus Points > > >"Sharon Chisholm" writes: > > >>I think bringing these in, not using SD-Param >>grammar, but as properly tagged XML would be very very useful. >> >> > >XML has its uses, but log data is not one of them. We need to be >careful that we don't start seeing everything as a nail to our xml >hammer. > >XML is useful for encoding hierarchical data, but is horrible for simple >flat data (try encoding a csv file in xml). XML is good at encoding >data that is highly variable, but expensive for more normalizable data. >XML is great for data interchange, where both sides of the conversation >need to be flexible and resilient. But it's horrible for data storage. >XML's overhead can be ignored for intermittent operations like >configuration requests, but will kill you at high volume. > >Compare a notification in XML: > > > > RPD_RSVP_NBRUP > my-host > rpd > > 10.5.14.2 > fe-1/3/0.0 > > RSVP neighbor 10.5.14.2 up on interface >fe-1/3/0.0 > > >and the same data in syslog: > >Oct 18 16:01:37 my-host rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor >10.5.14.2 up on interface fe-1/3/0.0 > >The syslog-SD form of this would be something like: > >1 888 4 00 2005-10-18-16:01:37 my-host rpd 2958 RPD_RSVP_NBRUP [JNPR-0 >neighbor="10.5.14.2" interface="fe-1/3/0.0"] RSVP neighbor 10.5.14.2 up >on interface fe-1/3/0.0 > >(That should be close enough; I'm not an SD-guru) > >wc -c reports the lengths as 321, 104, and 168. > >I take it as a given that customers will use notification data from >netconf in the same pattern we see with syslog data. They configure >large volumes of data, which they store and use to investigate problems, >either real-time or port-mortem. > >IMHO, the SD-PARAM version wins hands down, based on functionality .vs. >footprint. I can filter by severity, date, msgid, and message content >parameters. That's pretty much all I'm after. > >Thanks, > Phil > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Dec 04 20:47:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej5Rk-0000LP-HC for netconf-archive@megatron.ietf.org; Sun, 04 Dec 2005 20:47:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11222 for ; Sun, 4 Dec 2005 20:46:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ej5Iv-000AE8-V8 for netconf-data@psg.com; Mon, 05 Dec 2005 01:38:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [207.69.195.70] (helo=pop-borzoi.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ej5Iu-000ADv-Ih for netconf@ops.ietf.org; Mon, 05 Dec 2005 01:38:09 +0000 Received: from h-68-166-189-147.snvacaid.dynamic.covad.net ([68.166.189.147] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ej5It-0006Lz-00 for netconf@ops.ietf.org; Sun, 04 Dec 2005 20:38:07 -0500 Message-ID: <000c01c5f93d$36b0b9c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "netconf" References: Subject: Re: IANA considerations update for NETCONF protocol draft Date: Sun, 4 Dec 2005 17:42:54 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: "McDonald, Ira" > To: "'Andy Bierman'" ; "Rob Enns" > Cc: "Wijnen, Bert (Bert)" ; > Sent: Saturday, December 03, 2005 3:37 PM > Subject: RE: IANA considerations update for NETCONF protocol draft ... > Instead, simply specify that Enterprise Capabilities MUST choose a > _durable_ globally unique URI within one of the registered DNS domains > for that enterprise (i.e., using GUIDs based on MAC address is NOT > allowed). ... What happens when that domain name is recycled? (E.g., the company is swallowed by another, the domain registration is allowed to lapse, and some other orgnaization starts using it for thir own URIs.) Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 05 09:38:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjHUE-0002nB-AE for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 09:38:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26116 for ; Mon, 5 Dec 2005 09:37:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjHI8-000O3c-BC for netconf-data@psg.com; Mon, 05 Dec 2005 14:26:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjHI7-000O3G-Cc for netconf@ops.ietf.org; Mon, 05 Dec 2005 14:26:07 +0000 Received: from pc6 (1Cust177.tnt101.lnd4.gbr.da.uu.net [213.116.50.177]) by ranger.systems.pipex.net (Postfix) with SMTP id 95997E000531; Mon, 5 Dec 2005 14:25:56 +0000 (GMT) Message-ID: <01b901c5f99f$24414220$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Randy Presuhn" , "netconf" References: <000c01c5f93d$36b0b9c0$7f1afea9@oemcomputer> Subject: Re: IANA considerations update for NETCONF protocol draft Date: Mon, 5 Dec 2005 10:09:37 +0100 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 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Randy Presuhn" To: "netconf" Sent: Monday, December 05, 2005 2:42 AM Subject: Re: IANA considerations update for NETCONF protocol draft > Hi - > > > From: "McDonald, Ira" > > To: "'Andy Bierman'" ; "Rob Enns" > > Cc: "Wijnen, Bert (Bert)" ; > > Sent: Saturday, December 03, 2005 3:37 PM > > Subject: RE: IANA considerations update for NETCONF protocol draft > ... > > Instead, simply specify that Enterprise Capabilities MUST choose a > > _durable_ globally unique URI within one of the registered DNS domains > > for that enterprise (i.e., using GUIDs based on MAC address is NOT > > allowed). > ... > What happens when that domain name is recycled? (E.g., the company > is swallowed by another, the domain registration is allowed to lapse, > and some other orgnaization starts using it for thir own URIs.) > > Randy > Then we should have used URN 'which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable' [RFC3986] Not sure that it is worth it though. Tom Petch -- to 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 Dec 05 11:26:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJB2-0005Ea-I8 for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 11:26:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09413 for ; Mon, 5 Dec 2005 11:26:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjJ2s-00074n-2I for netconf-data@psg.com; Mon, 05 Dec 2005 16:18:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjJ2r-00074Z-DN for netconf@ops.ietf.org; Mon, 05 Dec 2005 16:18:29 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jB5GIG000921; Mon, 5 Dec 2005 08:18:20 -0800 (PST) (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 jB5GIA507291; Mon, 5 Dec 2005 08:18:10 -0800 (PST) (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 jB5GNRYE035642; Mon, 5 Dec 2005 11:23:27 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512051623.jB5GNRYE035642@idle.juniper.net> To: "Sharon Chisholm" cc: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points In-Reply-To: Your message of "Sun, 04 Dec 2005 13:42:41 EST." <713043CE8B8E1348AF3C546DBE02C1B405F942A3@zcarhxm2.corp.nortel.com> Date: Mon, 05 Dec 2005 11:23:27 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Sharon Chisholm" writes: >As someone more often then not ending up on the consuming end of >management information, I tend to go for clarity over performance But SD-Params are clear, right? They are name=value pairs. We don't need anything more than that and another WG has a wonderful draft that we can leverage to make our work easier in three ways, specification, implementation, and acceptance. We incorporate the syslog WG's work by reference, vendors leverage their new NG syslog implementation both for syslog and for netconf, and using syslog allows providers to leverage their new and old syslog infrastructure and tools. We get performance _and_ clarity. It's simpler _and_ easier. It's a dessert topping _and_ a floor cleaner. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 05 11:27:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJBG-0005Ey-LY for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 11:27:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09423 for ; Mon, 5 Dec 2005 11:26:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjJ6C-0007MU-GP for netconf-data@psg.com; Mon, 05 Dec 2005 16:21:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjJ6B-0007MG-TJ for netconf@ops.ietf.org; Mon, 05 Dec 2005 16:21:56 +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 jB5GLqBm066286; Mon, 5 Dec 2005 08:21:52 -0800 (PST) (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 jB5GLp509160; Mon, 5 Dec 2005 08:21:51 -0800 (PST) (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 jB5GR8YE035690; Mon, 5 Dec 2005 11:27:08 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512051627.jB5GR8YE035690@idle.juniper.net> To: "Randy Presuhn" cc: "netconf" Subject: Re: IANA considerations update for NETCONF protocol draft In-Reply-To: Your message of "Sun, 04 Dec 2005 17:42:54 PST." <000c01c5f93d$36b0b9c0$7f1afea9@oemcomputer> Date: Mon, 05 Dec 2005 11:27:08 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Randy Presuhn" writes: >What happens when that domain name is recycled? The capability out-lasts the company that defined it without becoming a standard? Is this a real world scenario? Doesn't the act of implementing netconf cement a company's future? ;^) Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 05 12:01:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJi6-0006r0-28 for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 12:01:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13244 for ; Mon, 5 Dec 2005 12:00:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjJc4-0009wM-3m for netconf-data@psg.com; Mon, 05 Dec 2005 16:54:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjJc0-0009w2-Q5 for netconf@ops.ietf.org; Mon, 05 Dec 2005 16:54:48 +0000 Received: (qmail 18255 invoked by uid 78); 5 Dec 2005 16:52:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.52 with SMTP; 5 Dec 2005 16:52:04 -0000 Message-ID: <43947032.6030809@andybierman.com> Date: Mon, 05 Dec 2005 08:52:02 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch CC: Randy Presuhn , netconf Subject: Re: IANA considerations update for NETCONF protocol draft References: <000c01c5f93d$36b0b9c0$7f1afea9@oemcomputer> <01b901c5f99f$24414220$0601a8c0@pc6> In-Reply-To: <01b901c5f99f$24414220$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tom Petch wrote: >From: "Randy Presuhn" >To: "netconf" >Sent: Monday, December 05, 2005 2:42 AM >Subject: Re: IANA considerations update for NETCONF protocol draft > > > > >>Hi - >> >> >> >>>From: "McDonald, Ira" >>>To: "'Andy Bierman'" ; "Rob Enns" >>>Cc: "Wijnen, Bert (Bert)" ; >>>Sent: Saturday, December 03, 2005 3:37 PM >>>Subject: RE: IANA considerations update for NETCONF protocol draft >>> >>> >>... >> >> >>>Instead, simply specify that Enterprise Capabilities MUST choose a >>>_durable_ globally unique URI within one of the registered DNS domains >>>for that enterprise (i.e., using GUIDs based on MAC address is NOT >>>allowed). >>> >>> >>... >> >> > > > >>What happens when that domain name is recycled? (E.g., the company >>is swallowed by another, the domain registration is allowed to lapse, >>and some other orgnaization starts using it for thir own URIs.) >> >>Randy >> >> >> > >Then we should have used URN 'which are required to remain globally unique > and persistent even when the resource ceases to exist or becomes unavailable' >[RFC3986] > >Not sure that it is worth it though. > > I doubt this is an operational problem. If acme.com goes away, the MGMT SW and NETCONF agent using a capability string with this value in it will still work. The odds that a new owner will release a NETCONF agent using the exact same capability strings (entire string matters--domain name is just a substring) is quite remote. The odds that this will happen and the new and old devices with matching capability strings will show up in the same administrative domain are even lower. >Tom Petch > > 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 Dec 05 13:12:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjKov-0004v6-DK for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 13:12:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22208 for ; Mon, 5 Dec 2005 13:11:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjKfr-000FFr-1i for netconf-data@psg.com; Mon, 05 Dec 2005 18:02:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjKfq-000FFf-CL for netconf@ops.ietf.org; Mon, 05 Dec 2005 18:02:50 +0000 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 05 Dec 2005 10:02:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,217,1131350400"; d="scan'208"; a="513983370:sNHT24767544" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Dec 2005 10:02:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IANA considerations update for NETCONF protocol draft Date: Mon, 5 Dec 2005 10:02:44 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D9B7698@photon.jnpr.net> Thread-Topic: IANA considerations update for NETCONF protocol draft Thread-Index: AcX5qEFiZj8nHOQdSImduuUkgyWTHwAHJNUQ From: "Rob Enns" To: "Tom Petch" , "Randy Presuhn" , "netconf" X-OriginalArrivalTime: 05 Dec 2005 18:02:49.0742 (UTC) FILETIME=[1ABDE2E0:01C5F9C6] 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 Tom Petch > Sent: Monday, December 05, 2005 1:10 AM > To: Randy Presuhn; netconf > Subject: Re: IANA considerations update for NETCONF protocol draft >=20 > From: "Randy Presuhn" > To: "netconf" > Sent: Monday, December 05, 2005 2:42 AM > Subject: Re: IANA considerations update for NETCONF protocol draft >=20 >=20 > > Hi - > > > > > From: "McDonald, Ira" > > > To: "'Andy Bierman'" ; "Rob Enns"=20 > > > > Cc: "Wijnen, Bert (Bert)" ;=20 > > > > Sent: Saturday, December 03, 2005 3:37 PM > > > Subject: RE: IANA considerations update for NETCONF protocol draft > > ... > > > Instead, simply specify that Enterprise Capabilities MUST choose a > > > _durable_ globally unique URI within one of the=20 > registered DNS domains > > > for that enterprise (i.e., using GUIDs based on MAC address is NOT > > > allowed). > > ... >=20 > > What happens when that domain name is recycled? (E.g., the company > > is swallowed by another, the domain registration is allowed=20 > to lapse, > > and some other orgnaization starts using it for thir own URIs.) > > > > Randy > > >=20 > Then we should have used URN 'which are required to remain=20 > globally unique > and persistent even when the resource ceases to exist or=20 > becomes unavailable' > [RFC3986] >=20 > Not sure that it is worth it though. I'm not sure it's worth it either. My preference is to drop the IANA allocated enterprise capability registry. Enterprises defining their own capabilities can choose URIs that make sense to them. Much like XML namespaces, common sense would dictate the choice of a URI that won't clash with others.=20 Rob =20 > Tom Petch -- to 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 Dec 05 13:15:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjKsV-00065d-Db for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 13:15:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22582 for ; Mon, 5 Dec 2005 13:15:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjKmy-000FvK-IR for netconf-data@psg.com; Mon, 05 Dec 2005 18:10:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjKmv-000Fv2-OS for netconf@ops.ietf.org; Mon, 05 Dec 2005 18:10:09 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 05 Dec 2005 10:10:09 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB5IA6BH024697; Mon, 5 Dec 2005 10:10:07 -0800 (PST) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4313.cisco.com [10.61.80.216]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jB5IHaaL032373; Mon, 5 Dec 2005 10:17:36 -0800 Message-ID: <4394827B.8090306@cisco.com> Date: Mon, 05 Dec 2005 19:10:03 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Rob Enns CC: Tom Petch , Randy Presuhn , netconf Subject: Re: IANA considerations update for NETCONF protocol draft References: <062B922B6EC55149B5A267ECE78E5D440D9B7698@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440D9B7698@photon.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=461; t=1133806657; x=1134238857; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20IANA=20considerations=20update=20for=20NETCONF=20protocol=20draf t| From:Eliot=20Lear=20| Date:Mon,=2005=20Dec=202005=2019=3A10=3A03=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=pkz/cUKG5EJGr6zB2yZKY1T1uMaCGN+yev6GPD4dkkwWiK/oKdywjNCfWqdBtsvg2Av4ayH9 +MapsOHXfatQZMDbdetlzN6sL+lpaTdY6BT4eG4KlMgRYsDyXtkR3B/xFp0mDhGBmLVzZQJ9LCv yRF/YmKtnpL1rAodWDn2qvAQ= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Enns wrote: > I'm not sure it's worth it either. My preference is to drop the IANA > allocated enterprise capability registry. Enterprises defining their > own capabilities can choose URIs that make sense to them. Much like > XML namespaces, common sense would dictate the choice of a URI that > won't clash with others. > Common sense is something that works with small numbers, but not with large. Why can't we solve this problem the same way SNMP solved it? I do think we can defer this until we see large numbers of netconf agent implementations. 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 Dec 05 13:33:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjL9W-0002A0-NK for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 13:33:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24462 for ; Mon, 5 Dec 2005 13:32:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjL3M-000HRf-Qt for netconf-data@psg.com; Mon, 05 Dec 2005 18:27:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjL3L-000HRR-U1 for netconf@ops.ietf.org; Mon, 05 Dec 2005 18:27:08 +0000 Received: from pc6 (1Cust244.tnt24.lnd4.gbr.da.uu.net [62.188.151.244]) by ranger.systems.pipex.net (Postfix) with SMTP id E8FD4E000133; Mon, 5 Dec 2005 18:26:57 +0000 (GMT) Message-ID: <02e901c5f9c0$cfd7f180$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Sharon Chisholm" , "Phil Shafer" Cc: References: <200512051623.jB5GNRYE035642@idle.juniper.net> Subject: Re: NETCONF Notifications: Consensus Points Date: Mon, 5 Dec 2005 18:24:38 +0100 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 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ---- Original Message ----- From: "Phil Shafer" To: "Sharon Chisholm" Cc: Sent: Monday, December 05, 2005 5:23 PM Subject: Re: NETCONF Notifications: Consensus Points > "Sharon Chisholm" writes: > >As someone more often then not ending up on the consuming end of > >management information, I tend to go for clarity over performance > > But SD-Params are clear, right? They are name=value pairs. We > don't need anything more than that and another WG has a wonderful > draft that we can leverage to make our work easier in three ways, > specification, implementation, and acceptance. We incorporate the > syslog WG's work by reference, vendors leverage their new NG syslog > implementation both for syslog and for netconf, and using syslog > allows providers to leverage their new and old syslog infrastructure > and tools. > > We get performance _and_ clarity. It's simpler _and_ easier. It's > a dessert topping _and_ a floor cleaner. > > Thanks, > Phil Sounds great but be aware that in November, the AD has issued a "formal Consultation prior to concluding the working group" on the grounds that consensus is unlikely to be reached. So if you like SDs, then sign up to syslog and agree with everything that the WG chair or Rainer (I-D editor) proposes. Then netconf will have an RFC to reference:-) Tom Petch -- to 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 Dec 05 13:56:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLWB-0007oA-Ua for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 13:56:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26817 for ; Mon, 5 Dec 2005 13:56:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjLMX-000JA1-Nk for netconf-data@psg.com; Mon, 05 Dec 2005 18:46:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjLMX-000J9p-4m for netconf@ops.ietf.org; Mon, 05 Dec 2005 18:46:57 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 05 Dec 2005 10:46:56 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,217,1131350400"; d="scan'208"; a="514892660:sNHT22110844" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Dec 2005 10:46:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IANA considerations update for NETCONF protocol draft Date: Mon, 5 Dec 2005 10:46:48 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D9B76A4@photon.jnpr.net> Thread-Topic: IANA considerations update for NETCONF protocol draft Thread-Index: AcX5xynp+1CvFoJ6SCeLER7macU9xwAAp3/g From: "Rob Enns" To: "Eliot Lear" Cc: "Tom Petch" , "Randy Presuhn" , "netconf" X-OriginalArrivalTime: 05 Dec 2005 18:46:56.0463 (UTC) FILETIME=[444F75F0:01C5F9CC] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I'm not sure it's worth it either. My preference is to drop the IANA > > allocated enterprise capability registry. Enterprises defining their > > own capabilities can choose URIs that make sense to them. Much like > > XML namespaces, common sense would dictate the choice of a URI that > > won't clash with others.=20 > > =20 >=20 > Common sense is something that works with small numbers, but not with > large. Why can't we solve this problem the same way SNMP=20 > solved it? I > do think we can defer this until we see large numbers of netconf agent > implementations. You are referring to the way enterprises register under the enterprise OID? For capabilities we could do the same but I think common sense will keep "foo networks" using foonetworks.com in their URI when defining new capabilities. Once we get around to defining data models, an enterprise registry is a necessity... so if we can defer capability registry until then, fair enough. 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 Mon Dec 05 14:14:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLml-0005C3-92 for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 14:14:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28819 for ; Mon, 5 Dec 2005 14:13:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjLdR-000Kes-Ne for netconf-data@psg.com; Mon, 05 Dec 2005 19:04:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjLdR-000Kef-2p for netconf@ops.ietf.org; Mon, 05 Dec 2005 19:04: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 jB5J467b013856; Mon, 5 Dec 2005 11:04:06 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Dec 2005 11:06:42 -0800 Message-ID: From: "McDonald, Ira" To: "'Eliot Lear'" , Rob Enns Cc: Tom Petch , Randy Presuhn , netconf Subject: RE: IANA considerations update for NETCONF protocol draft Date: Mon, 5 Dec 2005 11:06:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Eliot Lear wrote: > Sent: Monday, December 05, 2005 1:10 PM > To: Rob Enns > Cc: Tom Petch; Randy Presuhn; netconf > Subject: Re: IANA considerations update for NETCONF protocol draft > > > Rob Enns wrote: > > I'm not sure it's worth it either. My preference is to drop the IANA > > allocated enterprise capability registry. Enterprises defining their > > own capabilities can choose URIs that make sense to them. Much like > > XML namespaces, common sense would dictate the choice of a URI that > > won't clash with others. > > > > Common sense is something that works with small numbers, but not with > large. Why can't we solve this problem the same way SNMP > solved it? I > do think we can defer this until we see large numbers of netconf agent > implementations. XML sloppily addresses this problem (in dozens of W3C, OASIS, and other specs) by saying just use an enterprise URI (with the durability problem that Randy complains about). But this is not rocket science. The NetConf spec should say that Enterprise Capabilities MUST be prefixed by a durable URN (not simply a URI) and are not going to be IANA registered. End of problem. And I suggest that you further specify that Enterprise Capabilities SHOULD use the UUID URN Namespace (RFC 4122, July 2005). 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 -- to 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 Dec 05 16:57:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjOLG-0000zU-HO for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 16:57:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19849 for ; Mon, 5 Dec 2005 16:57:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjOCk-000ARv-QB for netconf-data@psg.com; Mon, 05 Dec 2005 21:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjOCk-000ARi-80 for netconf@ops.ietf.org; Mon, 05 Dec 2005 21:49:02 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 05 Dec 2005 13:49:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,218,1131350400"; d="scan'208"; a="514020359:sNHT22039676" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Dec 2005 13:49:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IANA considerations update for NETCONF protocol draft Date: Mon, 5 Dec 2005 13:48:35 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D9B76F1@photon.jnpr.net> Thread-Topic: IANA considerations update for NETCONF protocol draft Thread-Index: AcX5zrUVKspiQF9BQfSsgN1mqwP/HgAFTXFg From: "Rob Enns" To: "McDonald, Ira" , "Eliot Lear" Cc: "Tom Petch" , "Randy Presuhn" , "netconf" X-OriginalArrivalTime: 05 Dec 2005 21:49:01.0319 (UTC) FILETIME=[B4083170:01C5F9E5] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > XML sloppily addresses this problem (in dozens of W3C, OASIS, and other > specs) by saying just use an enterprise URI (with the durability problem=20 > that Randy complains about). Sloppy but workable. Just about sums up XML, doesn't it? :-) > But this is not rocket science. The NetConf spec should say that > Enterprise Capabilities MUST be prefixed by a durable URN (not simply > a URI) and are not going to be IANA registered. End of problem. How does one determine URN durability? Avoidance of DNS names for one thing. Is this term well known? (Googling "durable urn" leads down the wrong path) > And I suggest that you further specify that Enterprise Capabilities > SHOULD use the UUID URN Namespace (RFC 4122, July 2005). This is cool, but for capability URIs does NETCONF require this level of rigor? If an enterprise wants to add a capability to it's product, an enterprise URI should be sufficient. 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 Mon Dec 05 23:41:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjUdg-0004W1-BN for netconf-archive@megatron.ietf.org; Mon, 05 Dec 2005 23:41:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02315 for ; Mon, 5 Dec 2005 23:40:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjUUf-000M64-JD for netconf-data@psg.com; Tue, 06 Dec 2005 04:31:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjUUc-000M5r-NC for netconf@ops.ietf.org; Tue, 06 Dec 2005 04:31:55 +0000 Received: (qmail 20513 invoked by uid 78); 6 Dec 2005 04:31:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.59 with SMTP; 6 Dec 2005 04:31:53 -0000 Message-ID: <43951437.3070105@andybierman.com> Date: Mon, 05 Dec 2005 20:31:51 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netconf WG Subject: Update 1: NETCONF charter text proposal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This is the updated text that will be sent to the ADs for approval: thanks, Andy and Simon ============================================================ NETCONF WG Charter Update proposal: The original NETCONF WG charter contains the following line item, describing the characteristics that the protocol should have: - Provides support for asynchronous notifications This support was removed from the protocol for several reasons, including: - Removal of multiple channels (or connections) per session - Inconsistent notification support capabilities for each application mapping - Lack of a configurable notification type selection (filtering) mechanism - Lack of consensus on feature importance - Lack of time to reach consensus on all these issues Some time has passed, and there is now WG consensus to finish this work item, however the single line in the original charter needs to be expanded and this work scoped in much more detail. The NETCONF Notification work shall consist of the following: - Specify the message (capability exchange) details to support notifications. - Specify the application mapping details to support notifications. - Specify the protocol syntax and semantics of a notification message. - Specify or select a notification content information model. - Specify a mechanism for controlling the delivery (turn on/off) of notifications during a session. - Specify a mechanism for selectively receiving a configurable subset of all possible notification types. An individual submission Internet Draft has been proposed to the WG as the starting point for this work. Unless there are any strong objections or alternate proposals, the WG shall adopt the document identified as 'draft-chisholm-netconf-event-01.txt' as the starting point for this work. Goals and Milestones Dec 05 Update charter Jan 06 Submit first version of NETCONF Notifications document Sep 06 Begin WGLC of NETCONF Notifications document Dec 06 Submit final version of NETCONF Notifications document to IESG for consideration -- to 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 Dec 06 03:20:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjY4I-0007Us-Gb for netconf-archive@megatron.ietf.org; Tue, 06 Dec 2005 03:20:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21702 for ; Tue, 6 Dec 2005 03:20:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjXx9-000FZc-5Q for netconf-data@psg.com; Tue, 06 Dec 2005 08:13:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjXx7-000FZR-T4 for netconf@ops.ietf.org; Tue, 06 Dec 2005 08:13:34 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A2230E45 for ; Tue, 6 Dec 2005 09:13:29 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 09:12:00 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 09:11:59 +0100 Message-ID: <439547B8.7000908@ericsson.com> Date: Tue, 06 Dec 2005 09:11:36 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <200512051623.jB5GNRYE035642@idle.juniper.net> <02e901c5f9c0$cfd7f180$0601a8c0@pc6> In-Reply-To: <02e901c5f9c0$cfd7f180$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2005 08:12:00.0042 (UTC) FILETIME=[BB7CB0A0:01C5FA3C] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would not worry so much about reuse of domain name based capability names. Has the reuse problem ever happened with XML namespaces ? If someone wants a bulletproof solution he might choose a capability like SNMPOID:1.3.6.1.enterprises.ericsson.mycapability This would be as unique as he can get while others (like me) can use a domain name based capability if we are not worried about reuse. You should have to make this mandatory just maybe mention it. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Tel: +36-1-437-7320 email: Balazs.Lengyel@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 Tue Dec 06 06:06:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejaex-00049g-Cm for netconf-archive@megatron.ietf.org; Tue, 06 Dec 2005 06:06:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10392 for ; Tue, 6 Dec 2005 06:06:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjaYT-000AqY-Sj for netconf-data@psg.com; Tue, 06 Dec 2005 11:00:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjaYS-000AqC-4q for netconf@ops.ietf.org; Tue, 06 Dec 2005 11:00:16 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C58F04D1A2; Tue, 6 Dec 2005 12:00:14 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14758-10; Tue, 6 Dec 2005 12:00:13 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id E38334D10A; Tue, 6 Dec 2005 12:00:08 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 86696538DD2; Tue, 6 Dec 2005 12:00:07 +0100 (CET) Date: Tue, 6 Dec 2005 12:00:07 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Netconf WG Subject: Re: Update 1: NETCONF charter text proposal Message-ID: <20051206110007.GA10005@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Netconf WG References: <43951437.3070105@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43951437.3070105@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Dec 05, 2005 at 08:31:51PM -0800, Andy Bierman wrote: > This is the updated text that will be sent to the ADs for approval: Q: Is this a 'replace' or 'merge' operation on the charter? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 06 16:05:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejk0H-0004jp-Bu for netconf-archive@megatron.ietf.org; Tue, 06 Dec 2005 16:05:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22305 for ; Tue, 6 Dec 2005 16:04:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejjoo-000Jqq-AJ for netconf-data@psg.com; Tue, 06 Dec 2005 20:53:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejjol-000JqW-Sn for netconf@ops.ietf.org; Tue, 06 Dec 2005 20:53:43 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 06 Dec 2005 12:53:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208,217"; a="514231003:sNHT38892400" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Dec 2005 12:53:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5FAA7.2272A99A" Subject: RE: NETCONF inconsistency in get-config/source Date: Tue, 6 Dec 2005 12:53:16 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D9B77F9@photon.jnpr.net> Thread-Topic: NETCONF inconsistency in get-config/source Thread-Index: AcXxjTginvGJ4iMFSjKUh5uXwqGF6wJEXhqQ From: "Rob Enns" To: "Stig Solberg \(LN/EAB\)" , X-OriginalArrivalTime: 06 Dec 2005 20:53:40.0084 (UTC) FILETIME=[22D5B340:01C5FAA7] Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5FAA7.2272A99A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. The WG had previously decided that the element is = mandatory in , I'll strike the 2nd sentence in the = parameter description. =20 Rob =20 ________________________________ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On = Behalf Of Stig Solberg (LN/EAB) Sent: Thursday, November 24, 2005 10:55 PM To: netconf@ops.ietf.org Subject: NETCONF inconsistency in get-config/source =09 =09 Hi,=20 there seems to be an inconsistency in how the source element is = specified for get-config=20 in text (page 31) and how it it is specified in the NETCONF schema.=20 In the text section it is defined as follows. That is, it seems to be = an optional=20 element=20 source:=20 Name of the configuration datastore being queried, such as=20 . If this element is unspecified, the =20 configuration is used.=20 But in it NETCONF schema it is specified as being an mandatory element = since=20 minOccurs by default have the value 1:=20 =20 =20 =20 =20 =20 =20 =20 =20 Regards,=20 Stig Solberg=20 Software Engineer Voice: +46 (0)31 747 3251=20 Ericsson AB Fax : +46 (0)31 747 6033=20 G=F6teborg, Sweden Email: stig.solberg@ericsson.com=20 ------_=_NextPart_001_01C5FAA7.2272A99A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NETCONF inconsistency in get-config/source
Thanks. The WG had previously decided that the=20 <source> element is mandatory in <get-config>, I'll = strike the=20 2nd sentence in the <source> parameter = description.
 
Rob
 

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of Stig Solberg=20 (LN/EAB)
Sent: Thursday, November 24, 2005 10:55 = PM
To:=20 netconf@ops.ietf.org
Subject: NETCONF inconsistency in=20 get-config/source

Hi,
there seems=20 to be an inconsistency in how the source element is specified for=20 get-config
in text (page 31) = and how it it=20 is specified in the NETCONF schema.
In the=20 text section it is defined as follows. That is, it seems to be an = optional=20
element
     source:

        =20 Name of the configuration datastore being queried, such as =
         = <running/>.  If this element is unspecified, the=20 <running/>
         = configuration is=20 used.

But in it NETCONF schema it is = specified as being=20 an mandatory element since
minOccurs by=20 default have the value 1:
     <xs:complexType=20 name=3D"getConfigType">
       = <xs:complexContent>=20
        =20 <xs:extension base=3D"rpcOperationType">
          =20 <xs:sequence>
          &nbs= p; =20 <xs:element name=3D"source"
          &nbs= p;            = ; =20 type=3D"getConfigSourceType"/>
          &nbs= p; =20 <xs:element name=3D"filter"
          &nbs= p;            = ; =20 type=3D"filterInlineType" minOccurs=3D"0"/>
          =20 </xs:sequence>
<cut>=20

Regards,
Stig Solberg
Software=20 = Engineer           = ;  =20 Voice: +46 (0)31 747 3251 =
Ericsson AB    =           &nbs= p;    =20 Fax  : +46 (0)31 747=20 6033
G=F6teborg, = Sweden             &nbs= p;=20 Email: stig.solberg@ericsson.com=20



------_=_NextPart_001_01C5FAA7.2272A99A-- -- to 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 Dec 06 19:19:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejn2C-0004kA-8X for netconf-archive@megatron.ietf.org; Tue, 06 Dec 2005 19:19:48 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11825 for ; Tue, 6 Dec 2005 19:18:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjmwW-000IDq-2w for netconf-data@psg.com; Wed, 07 Dec 2005 00:13:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjmwV-000IDf-Gs for netconf@ops.ietf.org; Wed, 07 Dec 2005 00:13:55 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 06 Dec 2005 16:13:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="514264375:sNHT22165788" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Dec 2005 16:13:54 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AD review of: draft-ietf-netconf-prot-09.txt Date: Tue, 6 Dec 2005 16:13:08 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D9B785D@photon.jnpr.net> Thread-Topic: AD review of: draft-ietf-netconf-prot-09.txt Thread-Index: AcXwSNX+zV039JPfT5uTp1IPhFRXwwKefKhQ From: "Rob Enns" To: "Wijnen, Bert \(Bert\)" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 07 Dec 2005 00:13:54.0690 (UTC) FILETIME=[1C191620:01C5FAC3] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > - Appendix C.1.3. >=20 > I think appendix C.1.3. should fix > urn:ietf:params:xml:ns:netconf:capability:{name}:1.0 > into > urn:ietf:params:netconf:capability:{name}:1.0 > I know, you easily miss one if you make such changes. Resolved this by making the example URI in Appendix C generic. > - Sections 10.1 and 10.2 > I was checking with APPS AD Scot Hollenbeck, and he suggests > Bert, I see one small problem right away. =A0They're asking > IANA to both assign a namespace and to register a specific > one. =A0You can't do both. If they change the word "assign" > to "register" in the first sentence of sections 10.1 and > 10.2 I think the meaning will be much clearer. Done. > - Section 10.3 > So if I understand it correctly, then we do not allow any new > assignments for capabilities now. We (as a WG? as the IESG? > as the IETF?) may decide so later. But how is IANA to know > how/when that happens? Can we say some words about it? Resolved, future additions will require IETF approval. 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 Dec 07 13:05:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3fT-0002Ti-UO for netconf-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:05:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06770 for ; Wed, 7 Dec 2005 13:04:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek3Ul-000ELs-H3 for netconf-data@psg.com; Wed, 07 Dec 2005 17:54:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek3Ui-000ELf-ST for netconf@ops.ietf.org; Wed, 07 Dec 2005 17:54:21 +0000 Received: (qmail 5782 invoked by uid 78); 7 Dec 2005 17:54:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.60 with SMTP; 7 Dec 2005 17:54:20 -0000 Message-ID: <439721E0.8060403@andybierman.com> Date: Wed, 07 Dec 2005 09:54:40 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: nit in NETCONF XSD in prot-09 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was studying the XSD again, and I noticed 2 new things: 1) errorInfoContent maxOccurs is all wrong - ok-element should be "1", the rest are "unbounded" or maybe they are all "unbounded"? 2) errorInfoContent isn't used anywhere in the schema - so maybe it should just be removed? 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 Dec 07 13:44:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4H1-0004lV-70 for netconf-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:44:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11108 for ; Wed, 7 Dec 2005 13:43:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek49e-000ID4-AX for netconf-data@psg.com; Wed, 07 Dec 2005 18:36:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek49d-000ICs-H5 for netconf@ops.ietf.org; Wed, 07 Dec 2005 18:36:37 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 07 Dec 2005 10:36:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,226,1131350400"; d="scan'208"; a="515369854:sNHT23793842" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Dec 2005 10:36:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: nit in NETCONF XSD in prot-09 Date: Wed, 7 Dec 2005 10:34:41 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D9B791E@photon.jnpr.net> Thread-Topic: nit in NETCONF XSD in prot-09 Thread-Index: AcX7V78zGckWEWy2Se6aqUl24w48+QAAMRKw From: "Rob Enns" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 07 Dec 2005 18:36:37.0075 (UTC) FILETIME=[27F3DA30:01C5FB5D] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Removing it is fine for now. This part of NETCONF (error contents) has=20 had perhaps the least attention from implementors, judging from the=20 number of questions and comments we've received. Once we get some=20 experience it would be nice to tighten the XSD up a little. Rob=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, December 07, 2005 9:55 AM > To: Netconf (E-mail) > Subject: nit in NETCONF XSD in prot-09 >=20 > Hi, >=20 > I was studying the XSD again, and I noticed 2 new things: >=20 > 1) errorInfoContent maxOccurs is all wrong > - ok-element should be "1", the rest are "unbounded" > or maybe they are all "unbounded"? > 2) errorInfoContent isn't used anywhere in the schema > - so maybe it should just be removed? >=20 >=20 > > > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > > >=20 >=20 > Andy >=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 Thu Dec 08 08:33:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkLkW-0001fL-C6 for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 08:23:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07590 for ; Thu, 8 Dec 2005 07:21:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkKcf-000DLt-Np for netconf-data@psg.com; Thu, 08 Dec 2005 12:11:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkCZX-000ECp-Mt for netconf@ops.ietf.org; Thu, 08 Dec 2005 03:35:55 +0000 Received: (qmail 3770 invoked by uid 78); 8 Dec 2005 03:35:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.50 with SMTP; 8 Dec 2005 03:35:54 -0000 Message-ID: <4397AA85.5060303@andybierman.com> Date: Wed, 07 Dec 2005 19:37:41 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bert Wijnen , David Kessens CC: Simon Leinen , "Netconf (E-mail)" Subject: updated NETCONF charter text (replace instead of merge this time) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Description of Working Group: Wes Hardaker is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The Netconf Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides the following support for asynchronous notifications: - Specify the message (capability exchange) details to support notifications. - Specify the application mapping details to support notifications. - Specify the protocol syntax and semantics of a notification message. - Specify or select a notification content information model. - Specify a mechanism for controlling the delivery (turn on/off) of notifications during a session. - Specify a mechanism for selectively receiving a configurable subset of all possible notification types. The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures. The Netconf protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the Netconf protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s). The initial work will be restricted to the following items: - Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. - Netconf over Specification, which defines how the Netconf protocol is used with the transport protocol selected by the group, and how it meets the security and transport layer requirements of the Netconf Protocol Specification.. There will be a document of this type for each selected transport protocol. The working group will take the XMLCONF Configuration Protocol as a starting point. Additional Notification work will be addressed after the initial work is completed. An individual submission Internet Draft has been proposed to the WG as the starting point for the Notification work. The WG shall adopt the document identified as 'draft-chisholm-netconf-event-01.txt' as the starting point for this work. Goals and Milestones: Done Working Group formed Done Submit initial Netconf Protocol draft Done Submit initial Netconf over (transport-TBD) draft Done Begin Working Group Last Call for the Netconf Protocol draft Done Begin Working Group Last Call for the Netconf over (transport-TBD) draft Done Submit final version of the Netconf Protocol draft to the IESG Done Submit final version of the Netconf over SOAP draft to the IESG Done Submit final version of the Netconf over BEEP draft to the IESG Done Submit final version of the Netconf over SSH draft to the IESG Dec 05 Update charter Jan 06 Submit first version of NETCONF Notifications document Sep 06 Begin WGLC of NETCONF Notifications document Dec 06 Submit final version of NETCONF Notifications document to IESG for consideration -- to 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 Dec 08 10:23:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkNcA-0005Jj-JS for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 10:23:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27476 for ; Thu, 8 Dec 2005 10:22:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkNVF-0006Qw-Jt for netconf-data@psg.com; Thu, 08 Dec 2005 15:16:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.97] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkNVE-0006QY-Ky for netconf@ops.ietf.org; Thu, 08 Dec 2005 15:16:12 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe04.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 41530507 for netconf@ops.ietf.org; Thu, 08 Dec 2005 16:16:11 +0100 Date: Thu, 08 Dec 2005 16:16:05 +0100 (CET) Message-Id: <20051208.161605.116363794.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: lock From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In section 7.5 , the draft says: A lock MUST not be granted if any of the following conditions are true: [...] * the target configuration has already been modified and these changes have not been committed or rolled back I assume that this mean that the last condition applies only to the candidate configuration, since this is the only target configuration that can be committed through NETCONF. So the text could have been: * the target configuration is 'candidate' and it has already been modified and these changes have not been committed or rolled back. Is this correct? What is the purpose of this condition? Suppose user A is a good citizen and takes a lock and modifies the candidate, then releases the lock. Then, before committing, A wants to do another change. So A tries to grab the lock again - but this will fail since there are uncommitted changes. So A has to do the changes w/o the lock or do discard-changes, take the lock, redo all original modifications, do the new modifications, and then commit. Section 8.3.1 also says: The candidate configuration may be shared among multiple sessions. [...] It is therefore prudent for a client to lock the candidate configuration before modifying it. Is the intention that you have to commit after each modification? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 08 10:23:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkNcI-0005Jp-De for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 10:23:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27496 for ; Thu, 8 Dec 2005 10:22:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkNXU-0006fF-If for netconf-data@psg.com; Thu, 08 Dec 2005 15:18:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.65] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkNXT-0006f0-Rc for netconf@ops.ietf.org; Thu, 08 Dec 2005 15:18:32 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe03.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 44746911 for netconf@ops.ietf.org; Thu, 08 Dec 2005 16:18:29 +0100 Date: Thu, 08 Dec 2005 16:18:23 +0100 (CET) Message-Id: <20051208.161823.101605503.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: discard-changes From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In section 8.3.1 the draft says: The client can discard any changes since the last operation by executing the operation. The candidate configuration's content then reverts to the current committed configuration. What exactly does "current committed configuration" mean? Does it mean current running, or the candidate when the command was issued? If it is the latter, it means that a device has to store three copies of the configuration in order to support this correctly, since running might be modified through edit-configs (or CLI or whatever). /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 08 10:53:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO5J-0004uj-1H for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 10:53:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02078 for ; Thu, 8 Dec 2005 10:52:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkNzg-0009wU-8t for netconf-data@psg.com; Thu, 08 Dec 2005 15:47:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkNze-0009v4-S0 for netconf@ops.ietf.org; Thu, 08 Dec 2005 15:47:39 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58775101A for ; Thu, 8 Dec 2005 16:47:35 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 16:44:59 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 16:44:58 +0100 Message-ID: <439854F9.80501@ericsson.com> Date: Thu, 08 Dec 2005 16:44:57 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: "Netconf (E-mail)" Subject: Re: updated NETCONF charter text (replace instead of merge this time) References: <4397AA85.5060303@andybierman.com> In-Reply-To: <4397AA85.5060303@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 15:44:58.0896 (UTC) FILETIME=[582C3100:01C5FC0E] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Andy, I believe that a granular locking mechanism should be included in the second phase. Balazs Andy Bierman wrote: > Description of Working Group: > Wes Hardaker is Technical Advisor for Security Matters > > Configuration of networks of devices has become a critical requirement > for operators in today's highly interoperable networks. Operators from > large to small have developed their own mechanisms or used vendor > specific mechanisms to transfer configuration data to and from a > device, and for examining device state information which may impact > the configuration. Each of these mechanisms may be different in various > aspects, such as session establishment, user authentication, > configuration data exchange, and error responses. > > The Netconf Working Group is chartered to produce a protocol suitable > for network configuration, with the following characteristics: > > - Provides retrieval mechanisms which can differentiate between > configuration data and non-configuration data > - Is extensible enough that vendors will provide access to all > configuration data on the device using a single protocol > - Has a programmatic interface (avoids screen scraping and > formatting-related changes between releases) > - Uses a textual data representation, that can be easily > manipulated using non-specialized text manipulation tools. > - Supports integration with existing user authentication methods > - Supports integration with existing configuration database systems > - Supports network wide configuration transactions (with features > such as locking and rollback capability) > - Is as transport-independent as possible > - Provides the following support for asynchronous notifications: > - Specify the message (capability exchange) details to > support notifications. > - Specify the application mapping details to support notifications. > - Specify the protocol syntax and semantics of a notification message. > - Specify or select a notification content information model. > - Specify a mechanism for controlling the delivery (turn on/off) > of notifications during a session. > - Specify a mechanism for selectively receiving a configurable > subset of > all possible notification types. > > The Netconf protocol will use XML for data encoding purposes, > because XML is a widely deployed standard which is supported > by a large number of applications. XML also supports hierarchical data > structures. > > The Netconf protocol should be independent of the data definition > language and data models used to describe configuration and state > data. > > However, the authorization model used in the protocol is dependent on > the data model. Although these issues must be fully addressed to > develop standard data models, only a small part of this work will be > initially addressed. This group will specify requirements for standard > data models in order to fully support the Netconf protocol, such as: > > - identification of principals, such as user names or distinguished > names > - mechanism to distinguish configuration from non-configuration data > - XML namespace conventions > - XML usage guidelines > > It should be possible to transport the Netconf protocol using several > different protocols. The group will select at least one suitable > transport mechanism, and define a mapping for the selected protocol(s). > > The initial work will be restricted to the following items: > > - Netconf Protocol Specification, which defines the operational > model, protocol operations, transaction model, data model > requirements, security requirements, and transport layer > requirements. > > - Netconf over Specification, which defines how > the Netconf protocol is used with the transport protocol > selected by the group, and how it meets the security and > transport layer requirements of the Netconf Protocol > Specification.. There will be a document of this type for > each selected transport protocol. > > The working group will take the XMLCONF Configuration Protocol > as a starting point. > > Additional Notification work will be addressed after the initial work > is completed. > > An individual submission Internet Draft has been proposed to the WG > as the starting point for the Notification work. The WG shall adopt the > document identified as 'draft-chisholm-netconf-event-01.txt' as the > starting point for this work. > > Goals and Milestones: > Done Working Group formed Done Submit initial Netconf Protocol > draft Done Submit initial Netconf over (transport-TBD) draft > Done Begin Working Group Last Call for the Netconf Protocol draft > Done Begin Working Group Last Call for the Netconf over > (transport-TBD) draft Done Submit final version of the Netconf > Protocol draft to the IESG Done Submit final version of the Netconf > over SOAP draft to the IESG Done Submit final version of the Netconf > over BEEP draft to the IESG Done Submit final version of the Netconf > over SSH draft to the IESG Dec 05 Update charter > Jan 06 Submit first version of NETCONF Notifications document > Sep 06 Begin WGLC of NETCONF Notifications document > Dec 06 Submit final version of NETCONF Notifications document to IESG for > consideration > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager & AXD Operational Suite (AOS) OPM ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@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 Thu Dec 08 11:21:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkOVy-0003ot-6M for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 11:21:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05113 for ; Thu, 8 Dec 2005 11:20:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkOQW-000CvS-9S for netconf-data@psg.com; Thu, 08 Dec 2005 16:15:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkOQV-000Cv1-CZ for netconf@ops.ietf.org; Thu, 08 Dec 2005 16:15:23 +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 jB8GF89M029191; Thu, 8 Dec 2005 08:15:08 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Dec 2005 08:17:49 -0800 Message-ID: From: "McDonald, Ira" To: "'Balazs Lengyel'" Cc: "Netconf (E-mail)" Subject: RE: updated NETCONF charter text (replace instead of merge this t ime) Date: Thu, 8 Dec 2005 08:17:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, While I sympathize with the desire for a granular locking mechanism, in the absence of a mandatory standard data model for NetConf, the _meaning_ of a fine-grained lock is anyone's guess. 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 Balazs Lengyel > Sent: Thursday, December 08, 2005 10:45 AM > Cc: Netconf (E-mail) > Subject: Re: updated NETCONF charter text (replace instead of > merge this > time) > > > Hello Andy, > I believe that a granular locking mechanism should be > included in the second phase. > Balazs > > Andy Bierman wrote: > > Description of Working Group: > > Wes Hardaker is Technical Advisor for Security Matters > > > > Configuration of networks of devices has become a critical > requirement > > for operators in today's highly interoperable networks. > Operators from > > large to small have developed their own mechanisms or used vendor > > specific mechanisms to transfer configuration data to and from a > > device, and for examining device state information which may impact > > the configuration. Each of these mechanisms may be > different in various > > aspects, such as session establishment, user authentication, > > configuration data exchange, and error responses. > > > > The Netconf Working Group is chartered to produce a > protocol suitable > > for network configuration, with the following characteristics: > > > > - Provides retrieval mechanisms which can differentiate between > > configuration data and non-configuration data > > - Is extensible enough that vendors will provide access to all > > configuration data on the device using a single protocol > > - Has a programmatic interface (avoids screen scraping and > > formatting-related changes between releases) > > - Uses a textual data representation, that can be easily > > manipulated using non-specialized text manipulation tools. > > - Supports integration with existing user authentication methods > > - Supports integration with existing configuration database systems > > - Supports network wide configuration transactions (with features > > such as locking and rollback capability) > > - Is as transport-independent as possible > > - Provides the following support for asynchronous notifications: > > - Specify the message (capability exchange) details to > > support notifications. > > - Specify the application mapping details to support > notifications. > > - Specify the protocol syntax and semantics of a > notification message. > > - Specify or select a notification content information model. > > - Specify a mechanism for controlling the delivery (turn on/off) > > of notifications during a session. > > - Specify a mechanism for selectively receiving a configurable > > subset of > > all possible notification types. > > > > The Netconf protocol will use XML for data encoding purposes, > > because XML is a widely deployed standard which is supported > > by a large number of applications. XML also supports > hierarchical data > > structures. > > > > The Netconf protocol should be independent of the data definition > > language and data models used to describe configuration and state > > data. > > > > However, the authorization model used in the protocol is > dependent on > > the data model. Although these issues must be fully addressed to > > develop standard data models, only a small part of this work will be > > initially addressed. This group will specify requirements > for standard > > data models in order to fully support the Netconf protocol, such as: > > > > - identification of principals, such as user names or distinguished > > names > > - mechanism to distinguish configuration from > non-configuration data > > - XML namespace conventions > > - XML usage guidelines > > > > It should be possible to transport the Netconf protocol > using several > > different protocols. The group will select at least one suitable > > transport mechanism, and define a mapping for the selected > protocol(s). > > > > The initial work will be restricted to the following items: > > > > - Netconf Protocol Specification, which defines the operational > > model, protocol operations, transaction model, data model > > requirements, security requirements, and transport layer > > requirements. > > > > - Netconf over Specification, which defines how > > the Netconf protocol is used with the transport protocol > > selected by the group, and how it meets the security and > > transport layer requirements of the Netconf Protocol > > Specification.. There will be a document of this type for > > each selected transport protocol. > > > > The working group will take the XMLCONF Configuration Protocol > > as a starting point. > > > > Additional Notification work will be addressed after the > initial work > > is completed. > > > > An individual submission Internet Draft has been proposed to the WG > > as the starting point for the Notification work. The WG > shall adopt the > > document identified as 'draft-chisholm-netconf-event-01.txt' as the > > starting point for this work. > > > > Goals and Milestones: > > Done Working Group formed Done Submit initial > Netconf Protocol > > draft Done Submit initial Netconf over (transport-TBD) draft > > Done Begin Working Group Last Call for the Netconf > Protocol draft > > Done Begin Working Group Last Call for the Netconf over > > (transport-TBD) draft Done Submit final version of the Netconf > > Protocol draft to the IESG Done Submit final version of > the Netconf > > over SOAP draft to the IESG Done Submit final version > of the Netconf > > over BEEP draft to the IESG Done Submit final version > of the Netconf > > over SSH draft to the IESG Dec 05 Update charter > > Jan 06 Submit first version of NETCONF Notifications document > > Sep 06 Begin WGLC of NETCONF Notifications document > > Dec 06 Submit final version of NETCONF Notifications > document to IESG for > > consideration > > > > > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager & AXD Operational Suite (AOS) OPM > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@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: > -- to 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 Dec 08 12:50:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPuK-0000S7-Pf for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 12:50:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16784 for ; Thu, 8 Dec 2005 12:49:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkPoB-000LeK-21 for netconf-data@psg.com; Thu, 08 Dec 2005 17:43:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkPo9-000Le7-Nd for netconf@ops.ietf.org; Thu, 08 Dec 2005 17:43:53 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jB8Hho075958; Thu, 8 Dec 2005 09:43:50 -0800 (PST) (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 jB8Hhj502157; Thu, 8 Dec 2005 09:43:45 -0800 (PST) (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 jB8Hn2YE046724; Thu, 8 Dec 2005 12:49:02 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512081749.jB8Hn2YE046724@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: discard-changes In-Reply-To: Your message of "Thu, 08 Dec 2005 16:18:23 +0100." <20051208.161823.101605503.mbj@tail-f.com> Date: Thu, 08 Dec 2005 12:49:02 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Yes, it means it means the running configuration. Would this be more clear? The client can discard any uncommitted changes to the candidate configuration by executing the operation. This operation reverts the contents of the candidate configuration to the contents of the running configuration. Thanks, Phil Martin Bjorklund writes: >Hi, > >In section 8.3.1 the draft says: > > The client can discard any changes since the last operation > by executing the operation. The candidate > configuration's content then reverts to the current committed > configuration. > >What exactly does "current committed configuration" mean? Does it >mean current running, or the candidate when the command was >issued? If it is the latter, it means that a device has to store >three copies of the configuration in order to support this correctly, >since running might be modified through edit-configs (or CLI or >whatever). > > >/martin > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 08 16:00:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSst-0000Qm-FC for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 16:00:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10619 for ; Thu, 8 Dec 2005 16:00:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkSiK-000Gte-61 for netconf-data@psg.com; Thu, 08 Dec 2005 20:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkSiI-000GtE-UM for netconf@ops.ietf.org; Thu, 08 Dec 2005 20:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EkSiH-0007xC-NG; Thu, 08 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-soap-07.txt Message-Id: Date: Thu, 08 Dec 2005 15:50:01 -0500 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) Author(s) : T. Goddard Filename : draft-ietf-netconf-soap-07.txt Pages : 22 Date : 2005-12-8 The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP (Hypertext Transport Protocol) and SOAP over BEEP (Blocks Exchange Extensible Protocol) bindings for NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-soap-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-soap-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-8123019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-soap-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-soap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-8123019.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 08 16:40:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkTUo-0004qH-Ex for netconf-archive@megatron.ietf.org; Thu, 08 Dec 2005 16:40:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21082 for ; Thu, 8 Dec 2005 16:39:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkTPM-000L1l-9d for netconf-data@psg.com; Thu, 08 Dec 2005 21:34:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.97] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkTPJ-000KzV-CS for netconf@ops.ietf.org; Thu, 08 Dec 2005 21:34:29 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe04.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 41911076; Thu, 08 Dec 2005 22:34:27 +0100 Date: Thu, 08 Dec 2005 22:34:22 +0100 (CET) Message-Id: <20051208.223422.44785360.mbj@tail-f.com> To: phil@juniper.net Cc: netconf@ops.ietf.org Subject: Re: discard-changes From: Martin Bjorklund In-Reply-To: <200512081749.jB8Hn2YE046724@idle.juniper.net> References: <20051208.161823.101605503.mbj@tail-f.com> <200512081749.jB8Hn2YE046724@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: > Yes, it means it means the running configuration. Would > this be more clear? > > The client can discard any uncommitted changes to the candidate > configuration by executing the operation. This > operation reverts the contents of the candidate configuration > to the contents of the running configuration. Yes, thanks /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 06:28:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkgPy-0003ym-3i for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 06:28:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20015 for ; Fri, 9 Dec 2005 06:26:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkgFu-0005We-RY for netconf-data@psg.com; Fri, 09 Dec 2005 11:17:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.193] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkgFt-0005WP-UX for netconf@ops.ietf.org; Fri, 09 Dec 2005 11:17:38 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe07.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 41675519 for netconf@ops.ietf.org; Fri, 09 Dec 2005 12:17:35 +0100 Date: Fri, 09 Dec 2005 12:17:26 +0100 (CET) Message-Id: <20051209.121726.55733555.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: copy-config From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The operation takes source and target as parameters. I think the order of these is wrong - an implementation needs to buffer the entire inline config before knowing which target is used. I suggest that the order is reversed - target before source. The order is correct for edit-config. (our implementation makes use of this for both edit-config and copy-config in order to find a small set of diffs to apply to the db) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 06:43:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkgeU-0006Yf-Ed for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 06:43:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21861 for ; Fri, 9 Dec 2005 06:42:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkgZB-0007dR-JC for netconf-data@psg.com; Fri, 09 Dec 2005 11:37:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkgZ9-0007cm-NW for netconf@ops.ietf.org; Fri, 09 Dec 2005 11:37:32 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id F21364D278; Fri, 9 Dec 2005 12:37:29 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20733-06; Fri, 9 Dec 2005 12:37:28 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id A0B004D0BF; Fri, 9 Dec 2005 12:37:28 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 1C75E53E004; Fri, 9 Dec 2005 12:37:27 +0100 (CET) Date: Fri, 9 Dec 2005 12:37:27 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netconf@ops.ietf.org Subject: Re: copy-config Message-ID: <20051209113727.GD3209@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Martin Bjorklund , netconf@ops.ietf.org References: <20051209.121726.55733555.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051209.121726.55733555.mbj@tail-f.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Dec 09, 2005 at 12:17:26PM +0100, Martin Bjorklund wrote: > The operation takes source and target as parameters. I > think the order of these is wrong - an implementation needs to buffer > the entire inline config before knowing which target is used. I > suggest that the order is reversed - target before source. > > The order is correct for edit-config. > > (our implementation makes use of this for both edit-config and > copy-config in order to find a small set of diffs to apply to the db) You start processing an operation before you have completed the parsing of the request message which invokes that operation?? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 07:07:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekh1t-0006s0-1i for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 07:07:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24400 for ; Fri, 9 Dec 2005 07:06:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkgwC-0009sr-Kc for netconf-data@psg.com; Fri, 09 Dec 2005 12:01:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.225] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkgwB-0009sc-NZ for netconf@ops.ietf.org; Fri, 09 Dec 2005 12:01:19 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 41522114; Fri, 09 Dec 2005 13:01:16 +0100 Date: Fri, 09 Dec 2005 13:01:06 +0100 (CET) Message-Id: <20051209.130106.10302157.mbj@tail-f.com> To: j.schoenwaelder@iu-bremen.de Cc: netconf@ops.ietf.org Subject: Re: copy-config From: Martin Bjorklund In-Reply-To: <20051209113727.GD3209@boskop.local> References: <20051209.121726.55733555.mbj@tail-f.com> <20051209113727.GD3209@boskop.local> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Fri, Dec 09, 2005 at 12:17:26PM +0100, Martin Bjorklund wrote: > > > The operation takes source and target as parameters. I > > think the order of these is wrong - an implementation needs to buffer > > the entire inline config before knowing which target is used. I > > suggest that the order is reversed - target before source. > > > > The order is correct for edit-config. > > > > (our implementation makes use of this for both edit-config and > > copy-config in order to find a small set of diffs to apply to the db) > > You start processing an operation before you have completed the > parsing of the request message which invokes that operation?? Yes. No persistent stuff and no side effects of course; it's ok to get a parse error or whatever later. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 08:52:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkifS-0002dr-SX for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 08:52:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05814 for ; Fri, 9 Dec 2005 08:51:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkiX1-000JHW-0b for netconf-data@psg.com; Fri, 09 Dec 2005 13:43:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [216.148.227.152] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkiX0-000JHJ-7Q for netconf@ops.ietf.org; Fri, 09 Dec 2005 13:43:26 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc12) with SMTP id <20051209134325014008j9nke>; Fri, 9 Dec 2005 13:43:25 +0000 Reply-To: From: "David B Harrington" To: "'Martin Bjorklund'" , Subject: RE: copy-config Date: Fri, 9 Dec 2005 08:43:20 -0500 Message-ID: <00f401c5fcc6$84ef3300$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20051209.121726.55733555.mbj@tail-f.com> Thread-Index: AcX8s5ihScqVy7I2SvyyQpeZ8Pjp1AAESqCA Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This sounds to me like a detail related solely to implementation choices. I suggest you read the whole command so you know both the source and target, and then you can, in your implementation, process the arguments in the order you choose. It would probably be a good idea to validate the whole command before starting processing, because this could make your implementation more robust against mal-formed requests, including deliberate attempts to cause denial of service to other users of the system. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Martin Bjorklund > Sent: Friday, December 09, 2005 6:17 AM > To: netconf@ops.ietf.org > Subject: copy-config > > Hi, > > The operation takes source and target as parameters. I > think the order of these is wrong - an implementation needs to buffer > the entire inline config before knowing which target is used. I > suggest that the order is reversed - target before source. > > The order is correct for edit-config. > > (our implementation makes use of this for both edit-config and > copy-config in order to find a small set of diffs to apply to the db) > > > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 09:15:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekj1o-0007yB-GE for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 09:15:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09284 for ; Fri, 9 Dec 2005 09:14:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ekivo-000LdU-Vc for netconf-data@psg.com; Fri, 09 Dec 2005 14:09:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.129] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ekivn-000LdG-PE for netconf@ops.ietf.org; Fri, 09 Dec 2005 14:09:04 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe05.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 43189667; Fri, 09 Dec 2005 15:09:02 +0100 Date: Fri, 09 Dec 2005 15:08:56 +0100 (CET) Message-Id: <20051209.150856.02293715.mbj@tail-f.com> To: dbharrington@comcast.net Cc: netconf@ops.ietf.org Subject: Re: copy-config From: Martin Bjorklund In-Reply-To: <00f401c5fcc6$84ef3300$0400a8c0@DJYXPY41> References: <20051209.121726.55733555.mbj@tail-f.com> <00f401c5fcc6$84ef3300$0400a8c0@DJYXPY41> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "David B Harrington" wrote: > Hi, > > This sounds to me like a detail related solely to implementation > choices. I agree. But edit-config seems to be done that way (maybe unintentional?!?), and I think it's nice to specify a protocol so that it can be implemented as efficient as possible. > I suggest you read the whole command so you know both the > source and target, and then you can, in your implementation, process > the arguments in the order you choose. This is of course trivial, but the point is that an implementation will have to do more buffering than necessary. > It would probably be a good idea to validate the whole command before > starting processing, because this could make your implementation more > robust against mal-formed requests Of course we handle mal-formed requests - the processing done in our implementation at this point is more than plain parsing, but it does not involve any side effects. And (of course) we do validate everything before doing any side effects. As a somewhat simplified example, suppose I know that the target config is valid, and I get a copy-config which contains: ... eth0 10.0.0.1 ... more params follow ... (*) ... ... Now, at point (*) if the interface eth0 is unchanged, I can throw away that part of the data. But if I don't know which target to compare against, I can't do this trick. > including deliberate attempts to > cause denial of service to other users of the system. If the agent has to buffer everything, it might be easier to do a dos attack! /martin > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Martin Bjorklund > > Sent: Friday, December 09, 2005 6:17 AM > > To: netconf@ops.ietf.org > > Subject: copy-config > > > > Hi, > > > > The operation takes source and target as parameters. > I > > think the order of these is wrong - an implementation needs to > buffer > > the entire inline config before knowing which target is used. I > > suggest that the order is reversed - target before source. > > > > The order is correct for edit-config. > > > > (our implementation makes use of this for both edit-config and > > copy-config in order to find a small set of diffs to apply to the > db) > > > > > > > > /martin > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 12:52:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmPy-0000Ft-8n for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 12:52:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07290 for ; Fri, 9 Dec 2005 12:51:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkmDj-000ExZ-MF for netconf-data@psg.com; Fri, 09 Dec 2005 17:39:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkmDj-000ExK-3A for netconf@ops.ietf.org; Fri, 09 Dec 2005 17:39:47 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id jB9HddBm076727; Fri, 9 Dec 2005 09:39:39 -0800 (PST) (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 jB9HdY551514; Fri, 9 Dec 2005 09:39:35 -0800 (PST) (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 jB9HilYE050299; Fri, 9 Dec 2005 12:44:47 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512091744.jB9HilYE050299@idle.juniper.net> To: Martin Bjorklund cc: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org Subject: Re: copy-config In-Reply-To: Your message of "Fri, 09 Dec 2005 13:01:06 +0100." <20051209.130106.10302157.mbj@tail-f.com> Date: Fri, 09 Dec 2005 12:44:47 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Seems completely reasonable. Thanks, Phil Martin Bjorklund writes: >Juergen Schoenwaelder wrote: >> On Fri, Dec 09, 2005 at 12:17:26PM +0100, Martin Bjorklund wrote: >> >> > The operation takes source and target as parameters. I >> > think the order of these is wrong - an implementation needs to buffer >> > the entire inline config before knowing which target is used. I >> > suggest that the order is reversed - target before source. >> > >> > The order is correct for edit-config. >> > >> > (our implementation makes use of this for both edit-config and >> > copy-config in order to find a small set of diffs to apply to the db) >> >> You start processing an operation before you have completed the >> parsing of the request message which invokes that operation?? > >Yes. No persistent stuff and no side effects of course; it's ok to get >a parse error or whatever later. > > >/martin > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 13:41:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknBP-00024S-PN for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 13:41:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13173 for ; Fri, 9 Dec 2005 13:40:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ekn4h-000JTB-4N for netconf-data@psg.com; Fri, 09 Dec 2005 18:34:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ekn4f-000JSy-FJ for netconf@ops.ietf.org; Fri, 09 Dec 2005 18:34:29 +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 jB9IYRBm077340; Fri, 9 Dec 2005 10:34:28 -0800 (PST) (envelope-from lzhang@juniper.net) Received: from juniper.net (lzhang-bsd.juniper.net [172.17.58.29]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jB9IYR562536; Fri, 9 Dec 2005 10:34:27 -0800 (PST) (envelope-from lzhang@juniper.net) Message-ID: <4399CE33.3000002@juniper.net> Date: Fri, 09 Dec 2005 10:34:27 -0800 From: Lei Zhang User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Bjorklund CC: dbharrington@comcast.net, netconf@ops.ietf.org Subject: Re: copy-config References: <20051209.121726.55733555.mbj@tail-f.com> <00f401c5fcc6$84ef3300$0400a8c0@DJYXPY41> <20051209.150856.02293715.mbj@tail-f.com> In-Reply-To: <20051209.150856.02293715.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >>including deliberate attempts to >>cause denial of service to other users of the system. >> >> > >If the agent has to buffer everything, it might be easier to do a dos >attack! > > Second this. Requiring netconf server to buffer all inline data before start editing seems really lame. The DOS claim is unjustified - why would a properly authenticated user attack a netconf server? Lei -- to 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 Dec 09 13:55:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknPN-0005Re-HG for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 13:55:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15200 for ; Fri, 9 Dec 2005 13:54:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EknJV-000KrZ-0r for netconf-data@psg.com; Fri, 09 Dec 2005 18:49:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [207.69.195.67] (helo=pop-tawny.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EknJT-000KrD-97 for netconf@ops.ietf.org; Fri, 09 Dec 2005 18:49:48 +0000 Received: from h-64-105-136-210.snvacaid.dynamic.covad.net ([64.105.136.210] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EknJS-00019D-00 for netconf@ops.ietf.org; Fri, 09 Dec 2005 13:49:46 -0500 Message-ID: <004501c5fcf1$ff37ebe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20051209.121726.55733555.mbj@tail-f.com> <00f401c5fcc6$84ef3300$0400a8c0@DJYXPY41> <20051209.150856.02293715.mbj@tail-f.com> <4399CE33.3000002@juniper.net> Subject: Re: copy-config Date: Fri, 9 Dec 2005 10:54:33 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: "Lei Zhang" > To: "Martin Bjorklund" > Cc: ; > Sent: Friday, December 09, 2005 10:34 AM > Subject: Re: copy-config ... > The DOS claim is unjustified - why would a properly authenticated user > attack a netconf server? ... Wouldn't this be like arguing that if one has authentication, one does not need access control? There are cases where having an audit trail that identifies who caused the damage does little good, and it's much better to prevent the damage from occurring in the first place. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 15:06:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkoW6-0007wB-Mk for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 15:06:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23760 for ; Fri, 9 Dec 2005 15:06:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkoPO-0000j0-7g for netconf-data@psg.com; Fri, 09 Dec 2005 19:59:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkoPL-0000in-Ek for netconf@ops.ietf.org; Fri, 09 Dec 2005 19:59:55 +0000 Received: (qmail 13324 invoked by uid 78); 9 Dec 2005 19:59:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.54 with SMTP; 9 Dec 2005 19:59:54 -0000 Message-ID: <4399E238.1020200@andybierman.com> Date: Fri, 09 Dec 2005 11:59:52 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lei Zhang CC: Martin Bjorklund , dbharrington@comcast.net, netconf@ops.ietf.org Subject: Re: copy-config References: <20051209.121726.55733555.mbj@tail-f.com> <00f401c5fcc6$84ef3300$0400a8c0@DJYXPY41> <20051209.150856.02293715.mbj@tail-f.com> <4399CE33.3000002@juniper.net> In-Reply-To: <4399CE33.3000002@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Lei Zhang wrote: > Martin Bjorklund wrote: > >>> including deliberate attempts to >>> cause denial of service to other users of the system. >>> >> >> >> If the agent has to buffer everything, it might be easier to do a dos >> attack! >> >> > Second this. Requiring netconf server to buffer all inline data before > start editing seems really lame. > > The DOS claim is unjustified - why would a properly authenticated user > attack a netconf server? > A few comments: - This is good implementation feedback. the kind we said we wanted. - Dismissing the issue as implementation-specific is not a good idea. - Worrying about the buffering of a single parameter, but the WG doesn't care about a max-message-size? I don't get it. - Changing the parameter order at this late date is okay unless anybody objects strongly. - XML is verbose. Deal with it. It's very possible that future commands or even current ones can cause the agent to process large amounts of data. - The current parameter order is a result of considering the needs of the reader and writer, not the netconf engine implementor. That is our design focus. In this case, parameter order isn't very universal, since there are many examples where the order is (copyTo, copyFrom). > Lei 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 Fri Dec 09 18:59:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eks8p-0005h7-Hb for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:59:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00936 for ; Fri, 9 Dec 2005 18:58:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eks0G-000KLy-FN for netconf-data@psg.com; Fri, 09 Dec 2005 23:50:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eks0E-000KLP-IS for netconf@ops.ietf.org; Fri, 09 Dec 2005 23:50:16 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Eks02-00086V-37; Fri, 09 Dec 2005 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-prot-10.txt Message-Id: Date: Fri, 09 Dec 2005 18:50:02 -0500 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Configuration Protocol Author(s) : R. Enns Filename : draft-ietf-netconf-prot-10.txt Pages : 98 Date : 2005-12-9 The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-prot-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-prot-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-9162432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-prot-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-prot-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-9162432.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 09 21:05:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eku6W-0007p9-A5 for netconf-archive@megatron.ietf.org; Fri, 09 Dec 2005 21:05:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25592 for ; Fri, 9 Dec 2005 21:03:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ektym-0005HS-Sf for netconf-data@psg.com; Sat, 10 Dec 2005 01:56:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ektyl-0005HB-Av for netconf@ops.ietf.org; Sat, 10 Dec 2005 01:56:51 +0000 Received: (qmail 29936 invoked from network); 10 Dec 2005 01:56:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.112 with SMTP; 10 Dec 2005 01:56:50 -0000 Message-ID: <439A35E1.1070800@andybierman.com> Date: Fri, 09 Dec 2005 17:56:49 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" CC: "'Balazs Lengyel'" , "Netconf (E-mail)" Subject: Re: updated NETCONF charter text (replace instead of merge this time) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: >Hi, > >While I sympathize with the desire for a granular locking >mechanism, in the absence of a mandatory standard data model >for NetConf, the _meaning_ of a fine-grained lock is anyone's >guess. > > Ira is quite correct. Without a standard for object and instance naming, there cannot be a standard for identifying which subset of the configuration datastore is being locked. Has anyone implemented partial locking yet? Are you doing it by adding an Xpath expression parameter to the lock command (hint, hint)? What about instance naming though? Sidebar: I'm not impressed with the way ANY of the XML modeling languages handle instance naming, but more on that another day... >Cheers, >- Ira > > > Andy >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 Balazs Lengyel >>Sent: Thursday, December 08, 2005 10:45 AM >>Cc: Netconf (E-mail) >>Subject: Re: updated NETCONF charter text (replace instead of >>merge this >>time) >> >> >>Hello Andy, >>I believe that a granular locking mechanism should be >>included in the second phase. >>Balazs >> >>Andy Bierman wrote: >> >> >>>Description of Working Group: >>>Wes Hardaker is Technical Advisor for Security Matters >>> >>>Configuration of networks of devices has become a critical >>> >>> >>requirement >> >> >>>for operators in today's highly interoperable networks. >>> >>> >>Operators from >> >> >>>large to small have developed their own mechanisms or used vendor >>>specific mechanisms to transfer configuration data to and from a >>>device, and for examining device state information which may impact >>>the configuration. Each of these mechanisms may be >>> >>> >>different in various >> >> >>>aspects, such as session establishment, user authentication, >>>configuration data exchange, and error responses. >>> >>>The Netconf Working Group is chartered to produce a >>> >>> >>protocol suitable >> >> >>>for network configuration, with the following characteristics: >>> >>> - Provides retrieval mechanisms which can differentiate between >>> configuration data and non-configuration data >>> - Is extensible enough that vendors will provide access to all >>> configuration data on the device using a single protocol >>> - Has a programmatic interface (avoids screen scraping and >>> formatting-related changes between releases) >>> - Uses a textual data representation, that can be easily >>> manipulated using non-specialized text manipulation tools. >>> - Supports integration with existing user authentication methods >>> - Supports integration with existing configuration database systems >>> - Supports network wide configuration transactions (with features >>> such as locking and rollback capability) >>> - Is as transport-independent as possible >>> - Provides the following support for asynchronous notifications: >>> - Specify the message (capability exchange) details to >>> support notifications. >>> - Specify the application mapping details to support >>> >>> >>notifications. >> >> >>> - Specify the protocol syntax and semantics of a >>> >>> >>notification message. >> >> >>> - Specify or select a notification content information model. >>> - Specify a mechanism for controlling the delivery (turn on/off) >>> of notifications during a session. >>> - Specify a mechanism for selectively receiving a configurable >>>subset of >>> all possible notification types. >>> >>>The Netconf protocol will use XML for data encoding purposes, >>>because XML is a widely deployed standard which is supported >>>by a large number of applications. XML also supports >>> >>> >>hierarchical data >> >> >>>structures. >>> >>>The Netconf protocol should be independent of the data definition >>>language and data models used to describe configuration and state >>>data. >>> >>>However, the authorization model used in the protocol is >>> >>> >>dependent on >> >> >>>the data model. Although these issues must be fully addressed to >>>develop standard data models, only a small part of this work will be >>>initially addressed. This group will specify requirements >>> >>> >>for standard >> >> >>>data models in order to fully support the Netconf protocol, such as: >>> >>> - identification of principals, such as user names or distinguished >>> names >>> - mechanism to distinguish configuration from >>> >>> >>non-configuration data >> >> >>> - XML namespace conventions >>> - XML usage guidelines >>> >>>It should be possible to transport the Netconf protocol >>> >>> >>using several >> >> >>>different protocols. The group will select at least one suitable >>>transport mechanism, and define a mapping for the selected >>> >>> >>protocol(s). >> >> >>>The initial work will be restricted to the following items: >>> >>> - Netconf Protocol Specification, which defines the operational >>> model, protocol operations, transaction model, data model >>> requirements, security requirements, and transport layer >>> requirements. >>> >>> - Netconf over Specification, which defines how >>> the Netconf protocol is used with the transport protocol >>> selected by the group, and how it meets the security and >>> transport layer requirements of the Netconf Protocol >>> Specification.. There will be a document of this type for >>> each selected transport protocol. >>> >>>The working group will take the XMLCONF Configuration Protocol >>> as a starting point. >>> >>>Additional Notification work will be addressed after the >>> >>> >>initial work >> >> >>>is completed. >>> >>>An individual submission Internet Draft has been proposed to the WG >>>as the starting point for the Notification work. The WG >>> >>> >>shall adopt the >> >> >>>document identified as 'draft-chisholm-netconf-event-01.txt' as the >>>starting point for this work. >>> >>>Goals and Milestones: >>>Done Working Group formed Done Submit initial >>> >>> >>Netconf Protocol >> >> >>>draft Done Submit initial Netconf over (transport-TBD) draft >>>Done Begin Working Group Last Call for the Netconf >>> >>> >>Protocol draft >> >> >>>Done Begin Working Group Last Call for the Netconf over >>>(transport-TBD) draft Done Submit final version of the Netconf >>>Protocol draft to the IESG Done Submit final version of >>> >>> >>the Netconf >> >> >>>over SOAP draft to the IESG Done Submit final version >>> >>> >>of the Netconf >> >> >>>over BEEP draft to the IESG Done Submit final version >>> >>> >>of the Netconf >> >> >>>over SSH draft to the IESG Dec 05 Update charter >>>Jan 06 Submit first version of NETCONF Notifications document >>>Sep 06 Begin WGLC of NETCONF Notifications document >>>Dec 06 Submit final version of NETCONF Notifications >>> >>> >>document to IESG for >> >> >>> consideration >>> >>> >>> >>> >>> >>>-- >>>to unsubscribe send a message to netconf-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >>> >>-- >>Balazs Lengyel Ericsson Hungary Ltd. >>TSP System Manager & AXD Operational Suite (AOS) OPM >>ECN: 831 7320 Fax: +36 1 4377792 >>Tel: +36-1-437-7320 email: Balazs.Lengyel@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: >> >> >> > >-- >to 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 Dec 10 01:21:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky70-0003QS-1E for netconf-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:21:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18267 for ; Sat, 10 Dec 2005 01:20:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkxxK-0001O1-I4 for netconf-data@psg.com; Sat, 10 Dec 2005 06:11:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkxxJ-0001N8-JO for netconf@ops.ietf.org; Sat, 10 Dec 2005 06:11:37 +0000 Received: from pc6 (1Cust95.tnt102.lnd4.gbr.da.uu.net [213.116.52.95]) by astro.systems.pipex.net (Postfix) with SMTP id A55D6E0001CB; Fri, 9 Dec 2005 19:41:51 +0000 (GMT) Message-ID: <062401c5fcef$ea5eecc0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Rob Enns" , "McDonald, Ira" Cc: "netconf" References: <062B922B6EC55149B5A267ECE78E5D440D9B76F1@photon.jnpr.net> Subject: URN Re: IANA considerations update for NETCONF protocol draft Date: Fri, 9 Dec 2005 17:22:52 +0100 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 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit TP: below Tom Petch ----- Original Message ----- From: "Rob Enns" To: "McDonald, Ira" ; "Eliot Lear" Cc: "Tom Petch" ; "Randy Presuhn" ; "netconf" Sent: Monday, December 05, 2005 10:48 PM Subject: RE: IANA considerations update for NETCONF protocol draft > XML sloppily addresses this problem (in dozens of W3C, OASIS, and other > specs) by saying just use an enterprise URI (with the durability problem > that Randy complains about). Sloppy but workable. Just about sums up XML, doesn't it? :-) TP: sums it up beautifully:-( > But this is not rocket science. The NetConf spec should say that > Enterprise Capabilities MUST be prefixed by a durable URN (not simply > a URI) and are not going to be IANA registered. End of problem. How does one determine URN durability? Avoidance of DNS names for one thing. Is this term well known? (Googling "durable urn" leads down the wrong path) TP: tautology:-) as the RFC say (eg RFC1737) a key feature of a URN is persistence, even after the resource has gone (unlike a URL). > And I suggest that you further specify that Enterprise Capabilities > SHOULD use the UUID URN Namespace (RFC 4122, July 2005). This is cool, but for capability URIs does NETCONF require this level of rigor? If an enterprise wants to add a capability to it's product, an enterprise URI should be sufficient. TP: I agree, I think specifying URI would be enough. Organisations that grow by acquisition - eg Cisco - acquire multiple Assigned Numbers in a controlled namespace and then have to decide what to do about them, maintaining, obsoleting, migrating etc; I often see evidence of this but it has not been a problem for me. 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 Sun Dec 11 15:30:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElXpg-0007Ym-7o for netconf-archive@megatron.ietf.org; Sun, 11 Dec 2005 15:30:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04175 for ; Sun, 11 Dec 2005 15:28:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElXgY-0008d7-DQ for netconf-data@psg.com; Sun, 11 Dec 2005 20:20:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.225] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElXgX-0008cY-ER for netconf@ops.ietf.org; Sun, 11 Dec 2005 20:20:41 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 44167521 for netconf@ops.ietf.org; Sun, 11 Dec 2005 21:20:39 +0100 Date: Sun, 11 Dec 2005 21:20:34 +0100 (CET) Message-Id: <20051211.212034.84459880.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: xpath filter From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I know that this has been up on the list before, but I never saw any replies. The question is how to handle namespaces with the xpath capability. Consider the example in 8.9.5.1: top/users/user[name="fred"] If the box supports multiple namespaces, which namespace does top belong to? You could argue that this is a filter, so it should return results from all namespaces which match the filter. But what if you want to explicitly match a certain namespace? The XPath specification says that an xpath expression is evaluated with respect to a context (http://www.w3.org/TR/xpath#section-Introduction). A context contains, amongst other things, the set of namespace declarations in scope for the expression (a mapping from prefixes to namespace URIs). As one example, XSLT defines the context in http://www.w3.org/TR/xslt#section-Expressions. It defines the namespace declarations as: the set of namespace declarations are those in scope on the element which has the attribute in which the expression occurs; this includes the implicit declaration of the prefix xml required by the the XML Namespaces Recommendation [XML Names]; the default namespace (as declared by xmlns) is not part of this set I suggest that NETCONF uses a similar definition, so that one can write a filter such as: d:top/d:users/d:user[name="fred"] Also, I think that the XPath Core functions should be sufficient for NETCONF compliance; this is also not defined in the current draft. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Dec 11 17:49:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ela0n-0004mx-3F for netconf-archive@megatron.ietf.org; Sun, 11 Dec 2005 17:49:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19077 for ; Sun, 11 Dec 2005 17:48:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElZsd-000KhJ-7u for netconf-data@psg.com; Sun, 11 Dec 2005 22:41:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.65] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElZsc-000Kh2-6k for netconf@ops.ietf.org; Sun, 11 Dec 2005 22:41:18 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe03.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 48685222 for netconf@ops.ietf.org; Sun, 11 Dec 2005 23:41:16 +0100 Date: Sun, 11 Dec 2005 23:41:10 +0100 (CET) Message-Id: <20051211.234110.132586155.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: Re: lock From: Martin Bjorklund In-Reply-To: <20051208.161605.116363794.mbj@tail-f.com> References: <20051208.161605.116363794.mbj@tail-f.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi again, Since I didn't get any replies on this I'll try to rephrase. It is recommended that locks are used when working on the candidate. But the candidate is reverted to the running as soon as the lock is released. The only way to save the changes done after a lock is to commit. This means that the candidate can only be used by a single client before committing to running. From the rest of the text (e.g. section 9 and 8.3.1) I don't think this is the intention? Why isn't the special semantics of lock of the candidate (8.3.5.1 and 7.5) simply removed? [Ok, I realize that you _can_ get the same effect by using a local URL - clients always write with locks to a local file. When it's time to commit, you first copy-config from the local file to the candidate, then issue a commit command, possibly w/ a timeout.] /martin Martin Bjorklund wrote: > Hi, > > In section 7.5 , the draft says: > > A lock MUST not be granted if any of the following conditions are > true: > > [...] > > * the target configuration has already been modified and these > changes have not been committed or rolled back > > I assume that this mean that the last condition applies only to the > candidate configuration, since this is the only target configuration > that can be committed through NETCONF. So the text could have been: > > * the target configuration is 'candidate' and it has already > been modified and these changes have not been committed or > rolled back. > > Is this correct? > > > What is the purpose of this condition? Suppose user A is a good > citizen and takes a lock and modifies the candidate, then releases the > lock. Then, before committing, A wants to do another change. So A > tries to grab the lock again - but this will fail since there are > uncommitted changes. So A has to do the changes w/o the lock or do > discard-changes, take the lock, redo all original modifications, do > the new modifications, and then commit. > > Section 8.3.1 also says: > > The candidate configuration may be shared among multiple sessions. > [...] It is therefore prudent for a client to lock the candidate > configuration before modifying it. > > > Is the intention that you have to commit after each modification? > > > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Dec 11 23:49:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elfd1-0001p8-3z for netconf-archive@megatron.ietf.org; Sun, 11 Dec 2005 23:49:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23015 for ; Sun, 11 Dec 2005 23:48:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElfTV-000Nvx-Tk for netconf-data@psg.com; Mon, 12 Dec 2005 04:39:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElfTV-000Nvd-BO for netconf@ops.ietf.org; Mon, 12 Dec 2005 04:39:45 +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 jBC4diBm093191; Sun, 11 Dec 2005 20:39:44 -0800 (PST) (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 jBC4dh554946; Sun, 11 Dec 2005 20:39:44 -0800 (PST) (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 jBC4iuYE057261; Sun, 11 Dec 2005 23:44:56 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512120444.jBC4iuYE057261@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: lock In-Reply-To: Your message of "Sun, 11 Dec 2005 23:41:10 +0100." <20051211.234110.132586155.mbj@tail-f.com> Date: Sun, 11 Dec 2005 23:44:56 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Martin Bjorklund writes: >Since I didn't get any replies on this I'll try to rephrase. Sorry. Actually your original wording was fine. >The only way to save the changes done after a lock is to >commit. Well, you could , but most likely you'll commit or discard. >This means that the candidate can only be used by a single >client before committing to running. This is the intent. See more below.... >Martin Bjorklund wrote: >> I assume that this mean that the last condition applies only to the >> candidate configuration, since this is the only target configuration >> that can be committed through NETCONF. So the text could have been: >> >> * the target configuration is 'candidate' and it has already >> been modified and these changes have not been committed or >> rolled back. >> >> Is this correct? Yes, this is correct. >> What is the purpose of this condition? To prevent applications from (a) stealing the lock while a human user is in the process of making changes, and (b) preventing the script from committing changes which it did not make. >> Then, before committing, A wants to do another change. So A >> tries to grab the lock again - but this will fail since there are >> uncommitted changes. "A" would have no idea what changes are outstanding when it re-aquired the lock. Its changes could have been discarded, committed, or added to. If you could release the lock with outstanding changes or aquire a lock with outstanding changes the application would have no idea of the state of the configuration. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 01:34:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElhGO-0005VL-Bv for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 01:34:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04000 for ; Mon, 12 Dec 2005 01:33:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elh8C-0006r8-Mp for netconf-data@psg.com; Mon, 12 Dec 2005 06:25:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.12.11.32] (helo=smtp001.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elh8B-0006pp-G7 for netconf@ops.ietf.org; Mon, 12 Dec 2005 06:25:51 +0000 Received: (qmail 56513 invoked from network); 12 Dec 2005 06:25:50 -0000 Received: from unknown (HELO ?192.168.0.2?) (cridligv@62.34.158.224 with plain) by smtp001.mail.ukl.yahoo.com with SMTP; 12 Dec 2005 06:25:49 -0000 Message-ID: <439D1840.9030003@loria.fr> Date: Mon, 12 Dec 2005 07:27:12 +0100 From: Cridlig Vincent User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: xpath filter References: <20051211.212034.84459880.mbj@tail-f.com> <439C8FE8.101@loria.fr> <20051211.221906.22968422.mbj@tail-f.com> In-Reply-To: <20051211.221906.22968422.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA04000 Martin Bjorklund wrote: >Cridlig Vincent wrote: > =20 > >>I totally agree with your suggestion. >>I proposed earlier on this list to add a "contexts" element, seebling o= f=20 >>"filter", and containing one or more "context" elements (namespace +=20 >>prefix). >> =20 >> > >Yes, I know. I just hope we get a reply this time! > > =20 > >>It will be much much more efficient (at least in our Netconf=20 >>implementation) to find the right XML nodes in the case of such XPath=20 >>relative expression: "//name" >> =20 >> > >Same here. > > =20 > >>Moreover, the XPath expressions without prefix are still valid. >> =20 >> > >Do you check all namespaces in this case? > =20 > yes. Actually, we load the entire configuration data and then apply a=20 filter (easy solution but not performant). Ideally, it should parse the XML schemas to find some matching nodes (or=20 search in a dictionnary built from the schemas), load the configuration=20 data of each matching schemas and finally filter. For now, namespaces are not very well handled in our agent because I was=20 waiting for some clarifications on this context problem. Still some work=20 in the pipe... What about you ? Vincent =09 =09 =09 _________________________________________________________________________= __=20 Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenge= r=20 T=E9l=E9chargez cette version sur http://fr.messenger.yahoo.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 03:49:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EljN9-0007sf-8u for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 03:49:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18678 for ; Mon, 12 Dec 2005 03:48:22 -0500 (EST) From: owner-netconf@ops.ietf.org Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EljGE-000Im0-LU for netconf-data@psg.com; Mon, 12 Dec 2005 08:42:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: =20 X-Spam-Status: No, score=3D-2.6 required=3D5.0 tests=3DBAYES=5F00 autol= Message-Id: Date: Mon, 12 Dec 2005 08:42:18 +0000 earn=3Dham=20 =09version=3D3.1.0 Received: from [217.12.11.79] (helo=3Dsmtp010.mail.ukl.yahoo.com) =09by psg.com with smtp (Exim 4.60 (FreeBSD)) =09(envelope-from ) =09id 1ElY3l-000Ama-3y =09for netconf@ops.ietf.org; Sun, 11 Dec 2005 20:44:41 +0000 Received: (qmail 62444 invoked from network); 11 Dec 2005 20:44:39 -000= 0 Received: from unknown (HELO =3F192.168.0.2=3F) (cridligv@213.44.86.98 = with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 11 Dec 2005 20:44:39 -0000 Message-ID: <439C9008.30808@loria.fr> Date: Sun, 11 Dec 2005 21:46:00 +0100 From: Cridlig Vincent User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: xpath filter References: <20051211.212034.84459880.mbj@tail-f.com> In-Reply-To: <20051211.212034.84459880.mbj@tail-f.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk I totally agree with your suggestion. I proposed earlier on this list to add a "contexts" element, seebling o= f=20 "filter", and containing one or more "context" elements (namespace +=20= prefix). But I think the way you propose is more generally accepted in the XML=20= community. It will be much much more efficient (at least in our Netconf=20 implementation) to find the right XML nodes in the case of such XPath=20= relative expression: "//name" Moreover, the XPath expressions without prefix are still valid. Vincent CRIDLIG Madynes Martin Bjorklund wrote: >Hi, > >I know that this has been up on the list before, but I never saw any >replies. The question is how to handle namespaces with the xpath >capability. Consider the example in 8.9.5.1: > > > top/users/user[name=3D"fred"] > > >If the box supports multiple namespaces, which namespace does top >belong to=3F You could argue that this is a filter, so it should retu= rn >results from all namespaces which match the filter. But what if you >want to explicitly match a certain namespace=3F > >The XPath specification says that an xpath expression is evaluated >with respect to a context >(http://www.w3.org/TR/xpath#section-Introduction). A context >contains, amongst other things, the set of namespace declarations in >scope for the expression (a mapping from prefixes to namespace URIs). > >As one example, XSLT defines the context in >http://www.w3.org/TR/xslt#section-Expressions. It defines the >namespace declarations as: > =20 > the set of namespace declarations are those in scope on the element > which has the attribute in which the expression occurs; this > includes the implicit declaration of the prefix xml required by the > the XML Namespaces Recommendation [XML Names]; the default namespace= > (as declared by xmlns) is not part of this set > > >I suggest that NETCONF uses a similar definition, so that one can >write a filter such as: > > = > d:top/d:users/d:user[name=3D"fred"] > > >Also, I think that the XPath Core functions should be sufficient for >NETCONF compliance; this is also not defined in the current draft. > > >/martin > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > =20 > =09 =09 =09=09 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=20 Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messen= ger=20 T=E9l=E9chargez cette version sur http://fr.messenger.yahoo.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 03:56:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EljTo-0001Dz-8l for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 03:56:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19217 for ; Mon, 12 Dec 2005 03:55:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EljON-000JVS-Os for netconf-data@psg.com; Mon, 12 Dec 2005 08:50:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.12.11.79] (helo=smtp010.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElY3l-000Ama-3y for netconf@ops.ietf.org; Sun, 11 Dec 2005 20:44:41 +0000 Received: (qmail 62444 invoked from network); 11 Dec 2005 20:44:39 -0000 Received: from unknown (HELO ?192.168.0.2?) (cridligv@213.44.86.98 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 11 Dec 2005 20:44:39 -0000 Message-ID: <439C9008.30808@loria.fr> Date: Sun, 11 Dec 2005 21:46:00 +0100 From: Cridlig Vincent User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: xpath filter References: <20051211.212034.84459880.mbj@tail-f.com> In-Reply-To: <20051211.212034.84459880.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I totally agree with your suggestion. I proposed earlier on this list to add a "contexts" element, seebling of = "filter", and containing one or more "context" elements (namespace + = prefix). But I think the way you propose is more generally accepted in the XML = community. It will be much much more efficient (at least in our Netconf = implementation) to find the right XML nodes in the case of such XPath = relative expression: "//name" Moreover, the XPath expressions without prefix are still valid. Vincent CRIDLIG Madynes Martin Bjorklund wrote: >Hi, > >I know that this has been up on the list before, but I never saw any >replies. The question is how to handle namespaces with the xpath >capability. Consider the example in 8.9.5.1: > > > top/users/user[name=3D"fred"] > > >If the box supports multiple namespaces, which namespace does top >belong to? You could argue that this is a filter, so it should return >results from all namespaces which match the filter. But what if you >want to explicitly match a certain namespace? > >The XPath specification says that an xpath expression is evaluated >with respect to a context >(http://www.w3.org/TR/xpath#section-Introduction). A context >contains, amongst other things, the set of namespace declarations in >scope for the expression (a mapping from prefixes to namespace URIs). > >As one example, XSLT defines the context in >http://www.w3.org/TR/xslt#section-Expressions. It defines the >namespace declarations as: > = > the set of namespace declarations are those in scope on the element > which has the attribute in which the expression occurs; this > includes the implicit declaration of the prefix xml required by the > the XML Namespaces Recommendation [XML Names]; the default namespace > (as declared by xmlns) is not part of this set > > >I suggest that NETCONF uses a similar definition, so that one can >write a filter such as: > > > d:top/d:users/d:user[name=3D"fred"] > > >Also, I think that the XPath Core functions should be sufficient for >NETCONF compliance; this is also not defined in the current draft. > > >/martin > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > = > = = = _________________________________________________________________________= __ = Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenge= r = T=C3=A9l=C3=A9chargez cette version sur http://fr.messenger.yahoo.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 04:31:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elk1k-0007eX-04 for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 04:31:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23314 for ; Mon, 12 Dec 2005 04:30:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eljvq-000Mhr-BD for netconf-data@psg.com; Mon, 12 Dec 2005 09:25:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.193] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eljvm-000Mha-VT for netconf@ops.ietf.org; Mon, 12 Dec 2005 09:25:15 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe07.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 44903237; Mon, 12 Dec 2005 10:25:13 +0100 Date: Mon, 12 Dec 2005 10:25:03 +0100 (CET) Message-Id: <20051212.102503.68151162.mbj@tail-f.com> To: vincent.cridlig@loria.fr Cc: netconf@ops.ietf.org Subject: Re: xpath filter From: Martin Bjorklund In-Reply-To: <439D1840.9030003@loria.fr> References: <439C8FE8.101@loria.fr> <20051211.221906.22968422.mbj@tail-f.com> <439D1840.9030003@loria.fr> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Cridlig Vincent wrote: > >>Moreover, the XPath expressions without prefix are still valid. > >> > >> > > > >Do you check all namespaces in this case? > > > > > yes. Actually, we load the entire configuration data and then apply a > filter (easy solution but not performant). > Ideally, it should parse the XML schemas to find some matching nodes (or > search in a dictionnary built from the schemas), load the configuration > data of each matching schemas and finally filter. > > For now, namespaces are not very well handled in our agent because I was > waiting for some clarifications on this context problem. Still some work > in the pipe... > > What about you ? Our agent knows the data model, and thus we can do two things when filtering: if the filter uses a instance key, we just read the corresponding instance and continue filtering down there. (e.g. "interfaces/interface[ifName=eth0]/...") When no instance identifier is specified (e.g. "interfaces/interface[ifType=ethernet]/...") we check the match nodes (in the example ifType of each instance, if a match is found we read the rest of instance. This means that if you just want to read one or a few parameters in a given instance, we'll just do one read to the db to get the instance. As for namespaces for xpath, we don't handle that either - we're also waiting for clarification. For subtree filtering we handle namespaces though. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 05:10:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elkdw-0007AQ-AA for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 05:10:54 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27809 for ; Mon, 12 Dec 2005 05:09:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElkX1-0000OT-Sm for netconf-data@psg.com; Mon, 12 Dec 2005 10:03:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElkX0-0000OH-BE for netconf@ops.ietf.org; Mon, 12 Dec 2005 10:03:42 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5A17861181; Mon, 12 Dec 2005 11:03:41 +0100 (CET) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id 9226461181; Mon, 12 Dec 2005 11:03:40 +0100 (CET) Message-ID: <439D4B44.20407@loria.fr> Date: Mon, 12 Dec 2005 11:04:52 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Bjorklund Cc: netconf@ops.ietf.org Subject: Re: xpath filter References: <439C8FE8.101@loria.fr> <20051211.221906.22968422.mbj@tail-f.com> <439D1840.9030003@loria.fr> <20051212.102503.68151162.mbj@tail-f.com> In-Reply-To: <20051212.102503.68151162.mbj@tail-f.com> Content-Type: multipart/mixed; boundary="------------060909000204030103010403" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------060909000204030103010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If I understand well :-) 1. - you optimize your tool to limit the reading in your database *per value* - we optimize our tool to limit the reading *per module* 2. - you parse the XPath expression to build the XML document little by little - we build a brute subset XML document, and then we use an existing XPath library to select the nodes (so we have a full support of XPath). But it's better for us if the XPath expr starts in the same way as the registration XPath expr of an existing module. Otherwise, we have to query all modules... :-( (Hence the contexts, namespaces and prefixes...) You must have better performances but you have to reimplement XPath, don't you ? I guess that, in most cases (except for the relative expressions and exotic XPath requests), it probably looks like subtree filtering. Thanks for your replies. I find it very interesting to compare implementation choices. Vincent Martin Bjorklund wrote: >Cridlig Vincent wrote: > > >>>>Moreover, the XPath expressions without prefix are still valid. >>>> >>>> >>>> >>>> >>>Do you check all namespaces in this case? >>> >>> >>> >>> >>yes. Actually, we load the entire configuration data and then apply a >>filter (easy solution but not performant). >>Ideally, it should parse the XML schemas to find some matching nodes (or >>search in a dictionnary built from the schemas), load the configuration >>data of each matching schemas and finally filter. >> >>For now, namespaces are not very well handled in our agent because I was >>waiting for some clarifications on this context problem. Still some work >>in the pipe... >> >>What about you ? >> >> > >Our agent knows the data model, and thus we can do two things when >filtering: if the filter uses a instance key, we just read the >corresponding instance and continue filtering down there. >(e.g. "interfaces/interface[ifName=eth0]/...") >When no instance identifier is specified >(e.g. "interfaces/interface[ifType=ethernet]/...") we check the match >nodes (in the example ifType of each instance, if a match is found we >read the rest of instance. This means that if you just want to read >one or a few parameters in a given instance, we'll just do one read to >the db to get the instance. > >As for namespaces for xpath, we don't handle that either - we're also >waiting for clarification. For subtree filtering we handle >namespaces though. > > >/martin > > > > --------------060909000204030103010403 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Disposition: attachment; filename="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------060909000204030103010403-- -- to 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 Dec 12 07:46:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eln4E-0003a5-H6 for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 07:46:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16620 for ; Mon, 12 Dec 2005 07:45:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elmur-000EFv-CN for netconf-data@psg.com; Mon, 12 Dec 2005 12:36:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elmuq-000EFj-Sc for netconf@ops.ietf.org; Mon, 12 Dec 2005 12:36:28 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc11) with SMTP id <2005121212362701300c4ub2e>; Mon, 12 Dec 2005 12:36:28 +0000 Reply-To: From: "David B Harrington" To: "'Phil Shafer'" , "'Martin Bjorklund'" Cc: Subject: RE: lock Date: Mon, 12 Dec 2005 07:36:22 -0500 Message-ID: <02e601c5ff18$a9de18d0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200512120444.jBC4iuYE057261@idle.juniper.net> Thread-Index: AcX+124wpH04RUHJSAW9DriNflGQkQAQKCBw Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >Martin Bjorklund wrote: > >> I assume that this mean that the last condition applies only to the > >> candidate configuration, since this is the only target > configuration > >> that can be committed through NETCONF. So the text could have been: > >> > >> * the target configuration is 'candidate' and it has already > >> been modified and these changes have not been committed or > >> rolled back. > >> > >> Is this correct? > > Yes, this is correct. Hi, I think this is correct for version 1. There may be more than one possible candidate in future versions, and specifying that "the target configuration is 'candidate'" would be incompatible with those future versions. David Harrington dbharrington@comcast.net -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 11:51:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elqtg-0001ie-OU for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 11:51:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16457 for ; Mon, 12 Dec 2005 11:50:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elqi3-000Ddg-PE for netconf-data@psg.com; Mon, 12 Dec 2005 16:39:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elqi2-000DdT-PP for netconf@ops.ietf.org; Mon, 12 Dec 2005 16:39:30 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9561B9FA for ; Mon, 12 Dec 2005 17:39:29 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Dec 2005 17:39:29 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Dec 2005 17:39:29 +0100 Message-ID: <439DA7C0.8080807@ericsson.com> Date: Mon, 12 Dec 2005 17:39:28 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Questions on the Events draft ? References: <438758A3.6050603@andybierman.com> In-Reply-To: <438758A3.6050603@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2005 16:39:29.0227 (UTC) FILETIME=[9F1819B0:01C5FF3A] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit - Will it be allowed to transfer multiple events in one message ? What is the reasoning pro and contra ? - The sequence number belongs to the event or the event message ? What happens with it during node restart ? - Do we want anything like the active alarm list in RFC3877 ? - Can an event be resent by the node with changed content e.g. a stronger severity critical instead of major ? - Chapter 3.5 Event classes: I would like to see how I can transfer the ITU X.733/736 event/alarm classes (processingErrorAlarm, QualityofServiceAlarm, CommunicationsAlarm, EnviromentalAlarm, etc.) in the netconf event regards Balazs -- to 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 Dec 12 12:18:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElrJl-0008HV-K4 for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 12:18:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19596 for ; Mon, 12 Dec 2005 12:17:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElrEp-000HQv-1P for netconf-data@psg.com; Mon, 12 Dec 2005 17:13:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElrEo-000HQe-Be for netconf@ops.ietf.org; Mon, 12 Dec 2005 17:13:22 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id C1E7511D618; Mon, 12 Dec 2005 09:13:20 -0800 (PST) From: Wes Hardaker To: Cc: "'Phil Shafer'" , "'Martin Bjorklund'" , Subject: Re: lock Organization: Sparta References: <02e601c5ff18$a9de18d0$0400a8c0@DJYXPY41> Date: Mon, 12 Dec 2005 09:13:19 -0800 In-Reply-To: <02e601c5ff18$a9de18d0$0400a8c0@DJYXPY41> (David B. Harrington's message of "Mon, 12 Dec 2005 07:36:22 -0500") 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 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Mon, 12 Dec 2005 07:36:22 -0500, "David B Harrington" said: David> There may be more than one possible candidate in future versions, and David> specifying that "the target configuration is 'candidate'" would be David> incompatible with those future versions. Nah... You'd just have "candiate1" being different than "candidate"... Actually they'll like be named and the "unnamed" category will have be a special one for backwards compatibility. -- "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 Dec 12 15:07:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltxR-0003FQ-3Q for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:07:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16808 for ; Mon, 12 Dec 2005 15:06:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EltqK-0008NZ-6G for netconf-data@psg.com; Mon, 12 Dec 2005 20:00:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.161] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EltqF-0008ME-1S for netconf@ops.ietf.org; Mon, 12 Dec 2005 20:00:13 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe06.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 47059895; Mon, 12 Dec 2005 21:00:04 +0100 Date: Mon, 12 Dec 2005 20:59:54 +0100 (CET) Message-Id: <20051212.205954.65975569.mbj@tail-f.com> To: phil@juniper.net Cc: netconf@ops.ietf.org Subject: Re: lock From: Martin Bjorklund In-Reply-To: <200512120444.jBC4iuYE057261@idle.juniper.net> References: <20051211.234110.132586155.mbj@tail-f.com> <200512120444.jBC4iuYE057261@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: > >This means that the candidate can only be used by a single > >client before committing to running. > > This is the intent. Ok. > >Martin Bjorklund wrote: > >> I assume that this mean that the last condition applies only to the > >> candidate configuration, since this is the only target configuration > >> that can be committed through NETCONF. So the text could have been: > >> > >> * the target configuration is 'candidate' and it has already > >> been modified and these changes have not been committed or > >> rolled back. > >> What is the purpose of this condition? > > To prevent applications from (a) stealing the lock while a human > user is in the process of making changes, and (b) preventing the > script from committing changes which it did not make. I thought that (a) would be avoided by making the CLI/WebUI/whatever take a lock as well. But a script is allowed to make changes and even comitting w/o taking a lock. Since the draft talks about the candidate as possibly being "shared among multiple sessions" and also the text in section 9; I assume that the intention is that sometimes NETCONF locks will be used on the candidate and sometimes not? So a script can decide by itself if it wants to commit changes it didn't make or not. I'm just a bit surprised - I thought that the candidate was a persistent, shared, "scratchpad" configuration which could be made consistent using locks. As it is now, it behaves differently if locks are used or not - if locks are not used, it's a persistent shared scratchpad configuration which may or may not be consistent, but if locks are used it's a way of doing a transaction for a single client. Wouldn't it be more clean to separate these two functions? > >> Then, before committing, A wants to do another change. So A > >> tries to grab the lock again - but this will fail since there are > >> uncommitted changes. > > "A" would have no idea what changes are outstanding when it re-aquired > the lock. Its changes could have been discarded, committed, or added > to. If you could release the lock with outstanding changes or aquire a > lock with outstanding changes the application would have no idea of the > state of the configuration. "A" would have to do a get-config first of course, just as it would have to do if the changes were committed - after a commit, anyone could have made the changes you describe above. thanks /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 16:08:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elutt-0007O2-Bo for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:08:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28121 for ; Mon, 12 Dec 2005 16:07:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElulZ-000EZq-2x for netconf-data@psg.com; Mon, 12 Dec 2005 20:59:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.1] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElulW-000EZa-Rm for netconf@ops.ietf.org; Mon, 12 Dec 2005 20:59:24 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe01.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 45089814 for netconf@ops.ietf.org; Mon, 12 Dec 2005 21:59:10 +0100 Date: Mon, 12 Dec 2005 21:59:04 +0100 (CET) Message-Id: <20051212.215904.61219519.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: Re: xpath filter From: Martin Bjorklund In-Reply-To: <20051211.212034.84459880.mbj@tail-f.com> References: <20051211.212034.84459880.mbj@tail-f.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi again, There's another place where namespaces declarations need to be provided - the 'error-path' element. This is a bit different than the other, since xpath is just used to point to an instance. But namespaces need to be handled. I suggest that the namespace declarations set is the namespaces in scope of error-path, so that an agent can generate the following error-path: d:top/d:users/d:user[name="fred"]/d:companyInfo/d:dept /martin Martin Bjorklund wrote: > Hi, > > I know that this has been up on the list before, but I never saw any > replies. The question is how to handle namespaces with the xpath > capability. Consider the example in 8.9.5.1: > > > top/users/user[name="fred"] > > > If the box supports multiple namespaces, which namespace does top > belong to? You could argue that this is a filter, so it should return > results from all namespaces which match the filter. But what if you > want to explicitly match a certain namespace? > > The XPath specification says that an xpath expression is evaluated > with respect to a context > (http://www.w3.org/TR/xpath#section-Introduction). A context > contains, amongst other things, the set of namespace declarations in > scope for the expression (a mapping from prefixes to namespace URIs). > > As one example, XSLT defines the context in > http://www.w3.org/TR/xslt#section-Expressions. It defines the > namespace declarations as: > > the set of namespace declarations are those in scope on the element > which has the attribute in which the expression occurs; this > includes the implicit declaration of the prefix xml required by the > the XML Namespaces Recommendation [XML Names]; the default namespace > (as declared by xmlns) is not part of this set > > > I suggest that NETCONF uses a similar definition, so that one can > write a filter such as: > > > d:top/d:users/d:user[name="fred"] > > > Also, I think that the XPath Core functions should be sufficient for > NETCONF compliance; this is also not defined in the current draft. > > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 16:29:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElvEp-0004gT-LD for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:29:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00386 for ; Mon, 12 Dec 2005 16:28:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elv89-000Gsr-69 for netconf-data@psg.com; Mon, 12 Dec 2005 21:22:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elv88-000Gsa-F9 for netconf@ops.ietf.org; Mon, 12 Dec 2005 21:22:44 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id E255011D618; Mon, 12 Dec 2005 13:22:41 -0800 (PST) From: Wes Hardaker To: Phil Shafer Cc: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: lock Organization: Sparta References: <200512120444.jBC4iuYE057261@idle.juniper.net> Date: Mon, 12 Dec 2005 13:22:40 -0800 In-Reply-To: <200512120444.jBC4iuYE057261@idle.juniper.net> (Phil Shafer's message of "Sun, 11 Dec 2005 23:44:56 -0500") 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 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Sun, 11 Dec 2005 23:44:56 -0500, Phil Shafer said: Martin> * the target configuration is 'candidate' and it has already Martin> been modified and these changes have not been committed or Martin> rolled back. Martin> Martin> What is the purpose of this condition? Phil> To prevent applications from (a) stealing the lock while a human Phil> user is in the process of making changes, and (b) preventing the Phil> script from committing changes which it did not make. Martin: Note that the case you brought up about a user locking himself out of his own changes is one of many examples where locking can actually be misused. The more interesting cases, IMHO, are the ones where user B has made changes to the candidate config that user A isn't allowed to change. In this case, A can no longer commit the changes, get a lock, discard the changes, etc. IE, B doesn't have to lock the candidate configuration in order to make user A loose all ability to deal with the candidate configuration set in any useful way. >>> Then, before committing, A wants to do another change. So A >>> tries to grab the lock again - but this will fail since there are >>> uncommitted changes. Phil> "A" would have no idea what changes are outstanding when it re-aquired Phil> the lock. Its changes could have been discarded, committed, or added Phil> to. If you could release the lock with outstanding changes or aquire a Phil> lock with outstanding changes the application would have no idea of the Phil> state of the configuration. Phil> Thanks, Phil> Phil Phil> -- Phil> to unsubscribe send a message to netconf-request@ops.ietf.org with Phil> the word 'unsubscribe' in a single line as the message text body. Phil> archive: -- "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 Dec 12 17:21:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elw3D-0000CO-IC for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 17:21:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06414 for ; Mon, 12 Dec 2005 17:20:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elvyi-000M6X-Jx for netconf-data@psg.com; Mon, 12 Dec 2005 22:17:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Elvyh-000M6M-Sd for netconf@ops.ietf.org; Mon, 12 Dec 2005 22:17:04 +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 jBCMH3Bm016773; Mon, 12 Dec 2005 14:17:03 -0800 (PST) (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 jBCMH2556197; Mon, 12 Dec 2005 14:17:02 -0800 (PST) (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 jBCMMJYE059653; Mon, 12 Dec 2005 17:22:19 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512122222.jBCMMJYE059653@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: lock In-Reply-To: Your message of "Mon, 12 Dec 2005 20:59:54 +0100." <20051212.205954.65975569.mbj@tail-f.com> Date: Mon, 12 Dec 2005 17:22:19 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Martin Bjorklund writes: >> To prevent applications from (a) stealing the lock while a human >> user is in the process of making changes, and (b) preventing the >> script from committing changes which it did not make. >I thought that (a) would be avoided by making the CLI/WebUI/whatever >take a lock as well. We're trying to make something that will integrate easily with existing implementations and existing usage scenarios. So there's no "making [ancient users] take a lock". Users will enter and perform their ritual tasks in the Temple of the CLI without changing their actions. Forcing a new world order on them is a non-starter. >But a script is allowed to make changes and even comitting w/o taking >a lock. Since the draft talks about the candidate as possibly being >"shared among multiple sessions" and also the text in section 9; I >assume that the intention is that sometimes NETCONF locks will be used >on the candidate and sometimes not? So a script can decide by itself >if it wants to commit changes it didn't make or not. The suggestion is that locks always be used, but we make allowances for folks that avoid locking (for unknown reasons). Most of this is fallout from earlier drafts when locking was (for unknown reasons) an optional capability. >I'm just a bit surprised - I thought that the candidate was a >persistent, shared, "scratchpad" configuration which could be made >consistent using locks. As it is now, it behaves differently if locks >are used or not - if locks are not used, it's a persistent shared >scratchpad configuration which may or may not be consistent, but if >locks are used it's a way of doing a transaction for a single client. Yup, those are your choices. You can use it as a transaction mechanism for a single client, given protection and predictability to your world, or you can use it as a shared workspace, with the assumption that all those sharing the resource are sane and well-behaved. >"A" would have to do a get-config first of course, just as it would >have to do if the changes were committed - after a commit, anyone >could have made the changes you describe above. We don't want to force anyone to do a full get-config. If you just want to make a couple of minor changes, you don't need to traffic the entire config. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 17:44:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElwOm-0004zZ-6W for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 17:44:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08814 for ; Mon, 12 Dec 2005 17:43:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElwIv-000ODh-08 for netconf-data@psg.com; Mon, 12 Dec 2005 22:37:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.65] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElwIt-000OCz-Vl for netconf@ops.ietf.org; Mon, 12 Dec 2005 22:37:56 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe03.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 50083048; Mon, 12 Dec 2005 23:37:54 +0100 Date: Mon, 12 Dec 2005 23:37:48 +0100 (CET) Message-Id: <20051212.233748.119560212.mbj@tail-f.com> To: phil@juniper.net Cc: netconf@ops.ietf.org Subject: Re: lock From: Martin Bjorklund In-Reply-To: <200512122222.jBCMMJYE059653@idle.juniper.net> References: <20051212.205954.65975569.mbj@tail-f.com> <200512122222.jBCMMJYE059653@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: > Martin Bjorklund writes: > >> To prevent applications from (a) stealing the lock while a human > >> user is in the process of making changes, and (b) preventing the > >> script from committing changes which it did not make. > >I thought that (a) would be avoided by making the CLI/WebUI/whatever > >take a lock as well. > > We're trying to make something that will integrate easily > with existing implementations and existing usage scenarios. > So there's no "making [ancient users] take a lock". Users > will enter and perform their ritual tasks in the Temple of > the CLI without changing their actions. Forcing a new world > order on them is a non-starter. Agreed. But the CLI engine etc could do that for the user. The CLI engine must be aware of NETCONF locks anyway, as defined in the specs (7.5). > >But a script is allowed to make changes and even comitting w/o taking > >a lock. Since the draft talks about the candidate as possibly being > >"shared among multiple sessions" and also the text in section 9; I > >assume that the intention is that sometimes NETCONF locks will be used > >on the candidate and sometimes not? So a script can decide by itself > >if it wants to commit changes it didn't make or not. > > The suggestion is that locks always be used, but we make allowances > for folks that avoid locking (for unknown reasons). Most of this > is fallout from earlier drafts when locking was (for unknown > reasons) an optional capability. Ok. > >I'm just a bit surprised - I thought that the candidate was a > >persistent, shared, "scratchpad" configuration which could be made > >consistent using locks. As it is now, it behaves differently if locks > >are used or not - if locks are not used, it's a persistent shared > >scratchpad configuration which may or may not be consistent, but if > >locks are used it's a way of doing a transaction for a single client. > > Yup, those are your choices. You can use it as a transaction mechanism > for a single client, given protection and predictability to your world, or > you can use it as a shared workspace, with the assumption that all those > sharing the resource are sane and well-behaved. They don't have to be evil, you can get strange results if no locks are used just by bad timing. > >"A" would have to do a get-config first of course, just as it would > >have to do if the changes were committed - after a commit, anyone > >could have made the changes you describe above. > > We don't want to force anyone to do a full get-config. If you > just want to make a couple of minor changes, you don't need to > traffic the entire config. Thanks for the clarifications! Maybe some of these clarifications you just sent could go into the specs to make the intentions more clear for new readers? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 12 17:52:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElwXP-0006pE-KA for netconf-archive@megatron.ietf.org; Mon, 12 Dec 2005 17:52:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09682 for ; Mon, 12 Dec 2005 17:51:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElwTg-000PPT-Ku for netconf-data@psg.com; Mon, 12 Dec 2005 22:49:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElwTf-000PPH-VH for netconf@ops.ietf.org; Mon, 12 Dec 2005 22:49:04 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jBCMmw097126; Mon, 12 Dec 2005 14:48:58 -0800 (PST) (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 jBCMmr562844; Mon, 12 Dec 2005 14:48:53 -0800 (PST) (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 jBCMsAYE059861; Mon, 12 Dec 2005 17:54:10 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512122254.jBCMsAYE059861@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: lock In-Reply-To: Your message of "Mon, 12 Dec 2005 23:37:48 +0100." <20051212.233748.119560212.mbj@tail-f.com> Date: Mon, 12 Dec 2005 17:54:10 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Martin Bjorklund writes: >Agreed. But the CLI engine etc could do that for the user. The CLI >engine must be aware of NETCONF locks anyway, as defined in the specs >(7.5). The CLI could lock the config when the user does their first config change, but that would foil the scenario where two users are working together and don't want locks. And the CLI won't know whether the user wants to share the candidate with the NETCONF session or not. So we pseudo-lock the config from NETCONF by failing the lock if there are outstanding changes. Ensures that humans and applications can live in peace. >They don't have to be evil, you can get strange results if no locks are >used just by bad timing. Absolutely. >Thanks for the clarifications! Maybe some of these clarifications you >just sent could go into the specs to make the intentions more clear >for new readers? Amen. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 13 13:37:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmF29-0003kN-Rx for netconf-archive@megatron.ietf.org; Tue, 13 Dec 2005 13:37:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04412 for ; Tue, 13 Dec 2005 13:36:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmEog-0008vK-LP for netconf-data@psg.com; Tue, 13 Dec 2005 18:23:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmEoX-0008uJ-Pf for netconf@ops.ietf.org; Tue, 13 Dec 2005 18:23:49 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 13 Dec 2005 10:23:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBDINbQU013744; Tue, 13 Dec 2005 10:23:47 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 10:23:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on the Events draft ? Date: Tue, 13 Dec 2005 10:23:42 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB011C9A60@xmb-sjc-223.amer.cisco.com> Thread-Topic: Questions on the Events draft ? Thread-Index: AcX/OwP1cPmYbX/2Rs6/aByPR/l7TAA0HgTQ From: "Hector Trevino \(htrevino\)" To: "Balazs Lengyel" , X-OriginalArrivalTime: 13 Dec 2005 18:23:43.0232 (UTC) FILETIME=[592F4800:01C60012] 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 Balazs Lengyel > Sent: Monday, December 12, 2005 9:39 AM > To: netconf@ops.ietf.org > Subject: Questions on the Events draft ? >=20 > - Will it be allowed to transfer multiple events in one=20 > message ? What is the reasoning pro and contra ? HT: Right now the doc doesn't state whether or not this is allowed. However, the assumption has been one event/message. With that said, I've gotten requests from people at Cisco to allow multiple events/msg so this needs to be discussed further. The primary reason for doing this is efficiency.=20 > - The sequence number belongs to the event or the event=20 > message ? What happens with it during node restart ? HT: The sequenceNumber is in the header. So, it is per msg.=20 The what happens part is being put back (it got lost in the edits) The value of sequence number may be reset (i.e. value is not preserved across reboots) following a device reload/reboot.=20 > - Do we want anything like the active alarm list in RFC3877 ? HT: Eventually yes. But this would fall under the "modeling" work rather than extensions to support events. > - Can an event be resent by the node with changed content=20 > e.g. a stronger severity critical instead of major ? HT: This is outside the scope of the document. Your implementation could do this.=20 > - Chapter 3.5 Event classes: I would like to see how I can=20 > transfer the ITU X.733/736 event/alarm classes=20 > (processingErrorAlarm, QualityofServiceAlarm,=20 > CommunicationsAlarm, EnviromentalAlarm, etc.) in the netconf event HT: Right now there is no discussion on message encapsulation/transport other than syslog which is discussed in one of the appendices. Do you have a need/use for this (i.e. would u use it)? =20 >=20 > regards Balazs >=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 Tue Dec 13 14:10:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmFY7-0003JD-AI for netconf-archive@megatron.ietf.org; Tue, 13 Dec 2005 14:10:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08297 for ; Tue, 13 Dec 2005 14:09:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmFRt-000Dol-3m for netconf-data@psg.com; Tue, 13 Dec 2005 19:04:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmFRr-000DoY-QT for netconf@ops.ietf.org; Tue, 13 Dec 2005 19:04:27 +0000 Received: (qmail 30602 invoked from network); 13 Dec 2005 19:04:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.115 with SMTP; 13 Dec 2005 19:04:24 -0000 Message-ID: <439F1B3C.3090108@andybierman.com> Date: Tue, 13 Dec 2005 11:04:28 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hector Trevino (htrevino)" CC: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: Questions on the Events draft ? References: <6E21698722408147BEA594E073E2B0AB011C9A60@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB011C9A60@xmb-sjc-223.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hector Trevino (htrevino) wrote: > > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel >>Sent: Monday, December 12, 2005 9:39 AM >>To: netconf@ops.ietf.org >>Subject: Questions on the Events draft ? >> >>- Will it be allowed to transfer multiple events in one >>message ? What is the reasoning pro and contra ? >> >> > >HT: Right now the doc doesn't state whether or not this is allowed. >However, the assumption has been >one event/message. With that said, I've gotten requests from people at >Cisco to allow multiple events/msg >so this needs to be discussed further. > >The primary reason for doing this is efficiency. > > Seems reasonable -- IMO this is way different than multiple RPC requests per msg, which keeps coming up for some reason. The entire notification PDU should be <= the max-message-size of the receiver BTW. > > >>- The sequence number belongs to the event or the event >>message ? What happens with it during node restart ? >> >> > >HT: The sequenceNumber is in the header. So, it is per msg. > >The what happens part is being put back (it got lost in the edits) >The value of sequence number may be reset (i.e. value is not preserved >across reboots) following a device reload/reboot. > > > > >>- Do we want anything like the active alarm list in RFC3877 ? >> >> > >HT: Eventually yes. But this would fall under the "modeling" work rather >than extensions to support events. > > Thank you Hector for this answer! We need to separate the content layer from the rest of the PDU, just like every other NETCONF operation. I have a feeling there will not be agreement on a one-and-only content model for notifications. By NETCONF design, this is not a critical problem, but from an operational POV, the less variants the better. > > >>- Can an event be resent by the node with changed content >>e.g. a stronger severity critical instead of major ? >> >> > >HT: This is outside the scope of the document. Your implementation could >do this. > > > >>- Chapter 3.5 Event classes: I would like to see how I can >>transfer the ITU X.733/736 event/alarm classes >>(processingErrorAlarm, QualityofServiceAlarm, >>CommunicationsAlarm, EnviromentalAlarm, etc.) in the netconf event >> >> > >HT: Right now there is no discussion on message encapsulation/transport >other than syslog which is discussed in one of the >appendices. Do you have a need/use for this (i.e. would u use it)? > > >>regards Balazs >> >> >> 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 Dec 13 19:59:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKzV-00078w-45 for netconf-archive@megatron.ietf.org; Tue, 13 Dec 2005 19:59:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28038 for ; Tue, 13 Dec 2005 19:58:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKrL-000LyB-D0 for netconf-data@psg.com; Wed, 14 Dec 2005 00:51:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKrK-000Lxx-KL for netconf@ops.ietf.org; Wed, 14 Dec 2005 00:51:06 +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 jBE0ofkK029054 for ; Tue, 13 Dec 2005 18:50:41 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Dec 2005 01:50:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508DA0A64@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: Last Call: 'NETCONF Configuration Protocol' to Proposed Stand ard Date: Wed, 14 Dec 2005 01:50:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk FYI -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf Of Eliot Lear Sent: Friday, December 09, 2005 08:40 To: Sam Hartman Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard Hi Sam, > Hi. This is not a blocking comment nor am I even asking for a change; > I'm just asking people consider this for netconf and future work. > > Netconf currently recommends that netconf over ssh be run over a > different port than the normal ssh port. > > That seems like a fine idea. I think there are cases where you might > want to allow access to netconf but not allow access to the CLI > through the normal ssh port. > > However I think in many cases it would not be a security problem if > the netconf subsystem were available over the normal ssh port. In > many applications the same privileges will be granted to users over > the CLI as to the same users over netconf. In many cases the > functionality available through netconf will also be available through > the CLI. > Obviously what you're suggesting isn't hard to do, and I agree with you that in many cases use of port 22 would be safe (and it would certainly be true for the VAST majority of cases when connecting to network infrastructure). However, once we decide to cover the other cases where we are trying to give firewall administrators some leeway, I'm not sure there's an added advantage to adding text along the lines of "well, sometimes you can use port 22." For one it makes the tool building HARDER if the other port isn't LISTENED to as well, because your canned tools would end up playing guessing games or requiring extra configuration. And for our purposes I think I know of one SSH implementation on a general computing device that hardcodes the port to 22 and that implementation also doesn't have means to support additional applications. All of this having been said, I am beginning to grow concerned about port assignments and firewall administration. If you're a firewall administrator the IETF is about to make your life and perhaps the performance of some low end / old gear, slightly more complex. With netconf there will be either two or three new ports to block. ISMS will later add another port. And these are just the protocols I've been playing with, as of late. I'm sure a bunch of other protocols are out there that I don't know about. In addition there is the comparably minor matter of well known port assignments. All I'm saying now is that it is probably worth some thought to reconsider the substrate RFC to give additional guidance for protocols that have a notably similar purpose. Regards, 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 Tue Dec 13 19:59:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKzZ-00079i-Rz for netconf-archive@megatron.ietf.org; Tue, 13 Dec 2005 19:59:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28047 for ; Tue, 13 Dec 2005 19:58:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKqz-000Lsw-L9 for netconf-data@psg.com; Wed, 14 Dec 2005 00:50:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKqy-000LsQ-WD for netconf@ops.ietf.org; Wed, 14 Dec 2005 00:50:45 +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 jBE0ofe6029052 for ; Tue, 13 Dec 2005 18:50:41 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Dec 2005 01:50:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508DA0A62@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: Last Call: 'NETCONF Configuration Protocol' to Proposed Stand ard Date: Wed, 14 Dec 2005 01:50:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk FYI, 3 more postings coming -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf Of Sam Hartman Sent: Thursday, December 08, 2005 23:35 To: iesg@ietf.org Cc: ietf@ietf.org Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard Hi. This is not a blocking comment nor am I even asking for a change; I'm just asking people consider this for netconf and future work. Netconf currently recommends that netconf over ssh be run over a different port than the normal ssh port. That seems like a fine idea. I think there are cases where you might want to allow access to netconf but not allow access to the CLI through the normal ssh port. However I think in many cases it would not be a security problem if the netconf subsystem were available over the normal ssh port. In many applications the same privileges will be granted to users over the CLI as to the same users over netconf. In many cases the functionality available through netconf will also be available through the CLI. --Sam -- to 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 Dec 13 19:59:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKzq-0007GC-Af for netconf-archive@megatron.ietf.org; Tue, 13 Dec 2005 19:59:54 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28067 for ; Tue, 13 Dec 2005 19:58:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKr0-000LtV-Q1 for netconf-data@psg.com; Wed, 14 Dec 2005 00:50:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKr0-000Lt6-7X for netconf@ops.ietf.org; Wed, 14 Dec 2005 00:50:46 +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 jBE0ofsx029053 for ; Tue, 13 Dec 2005 18:50:41 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Dec 2005 01:50:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508DA0A65@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: Last Call: 'NETCONF Configuration Protocol' to Proposed Stand ard Date: Wed, 14 Dec 2005 01:50:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk FYI -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf Of Sam Hartman Sent: Friday, December 09, 2005 15:03 To: Eliot Lear Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard >>>>> "Eliot" == Eliot Lear writes: Eliot> Obviously what you're suggesting isn't hard to do, and I Eliot> agree with you that in many cases use of port 22 would be Eliot> safe (and it would certainly be true for the VAST majority Eliot> of cases when connecting to network infrastructure). Eliot> However, once we decide to cover the other cases where we Eliot> are trying to give firewall administrators some leeway, I'm Eliot> not sure there's an added advantage to adding text along Eliot> the lines of "well, sometimes you can use port 22." For Eliot> one it makes the tool building HARDER if the other port Eliot> isn't LISTENED to as well, because your canned tools would Eliot> end up playing guessing games or requiring extra Eliot> configuration. And for our purposes I think I know of one Eliot> SSH implementation on a general computing device that Eliot> hardcodes the port to 22 and that implementation also Eliot> doesn't have means to support additional applications. I think the only reason you might want to make the change is so that: * People authorized to use the CLI in environments that have not gotten around to opening up the netconf port can use netconf * People who have tunnel setups to get to ssh can also get to netconf. However as I said, I'm not actually asking for the change just asking people to think about it. I think that it is even more critical to think about it for isms than for netconf simply because we're at an earlier stage with isms. -- to 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 Dec 13 19:59:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKzt-0007GH-KD for netconf-archive@megatron.ietf.org; Tue, 13 Dec 2005 19:59:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28066 for ; Tue, 13 Dec 2005 19:58:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKr7-000Lu5-KJ for netconf-data@psg.com; Wed, 14 Dec 2005 00:50:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmKr7-000Ltp-2F for netconf@ops.ietf.org; Wed, 14 Dec 2005 00:50:53 +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 jBE0of2s029051 for ; Tue, 13 Dec 2005 18:50:41 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Dec 2005 01:50:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508DA0A63@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: Last Call: 'NETCONF Configuration Protocol' to Proposed Stand ard Date: Wed, 14 Dec 2005 01:50:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk FYI -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf Of Pekka Savola Sent: Friday, December 09, 2005 07:56 To: Sam Hartman Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard Hi, On Thu, 8 Dec 2005, Sam Hartman wrote: > Netconf currently recommends that netconf over ssh be run over a > different port than the normal ssh port. > > That seems like a fine idea. I think there are cases where you might > want to allow access to netconf but not allow access to the CLI > through the normal ssh port. > > However I think in many cases it would not be a security problem if > the netconf subsystem were available over the normal ssh port. In > many applications the same privileges will be granted to users over > the CLI as to the same users over netconf. In many cases the > functionality available through netconf will also be available through > the CLI. As an operator, I agree. Especially in smaller networks (say, less than 50 routers), the set of hosts where you can log in to the routers and the set of hosts from which network management (other than read-only SNMP) is expected to occur are similarly trusted. With the expectation that more fine-grained control (rather than just IP address/port filtering) of SSH vs NETCONF access can be made as part of router's configuration, having a separate port is not needed, but it doesn't do much harm either. However, I see that there may be different kinds of networks where being able to separate SSH and NETCONF access permissions at the IP/port filtering level may be desirable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to 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 Dec 14 15:04:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcrH-00086w-1k for netconf-archive@megatron.ietf.org; Wed, 14 Dec 2005 15:04:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17813 for ; Wed, 14 Dec 2005 15:03:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emcf7-000O71-4e for netconf-data@psg.com; Wed, 14 Dec 2005 19:51:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [192.54.144.134] (helo=thsmsgxrt11p.thalesgroup.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmbBB-000Alf-T9 for netconf@ops.ietf.org; Wed, 14 Dec 2005 18:16:42 +0000 Received: from thsmsgirt23p.corp.thales (unknown [10.33.231.7]) by thsmsgxrt11p.thalesgroup.com (Postfix) with ESMTP id 1F48D3C836 for ; Wed, 14 Dec 2005 19:16:41 +0100 (CET) Received: from thsmsgiav11p.corp.thales (10.33.231.31) by thsmsgirt23p.corp.thales (7.2.055.4) id 439EE49F0002FCBE for netconf@ops.ietf.org; Wed, 14 Dec 2005 19:16:39 +0100 Received: from (10.33.231.1) by thsmsgiav11p.corp.thales via smtp id 1a07_7ee5e536_6ccd_11da_9050_001143d32df6; Wed, 14 Dec 2005 19:14:41 +0100 (CET) Received: from NODALNET.clb.tcfr.thales (unknown [10.33.8.19]) by thsmsgirt11p.corp.thales (Postfix) with ESMTP id 2A50C3C00F for ; Wed, 14 Dec 2005 19:16:40 +0100 (CET) Received: by nodalnet.clb.tcfr.thales with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Dec 2005 19:16:40 +0100 Message-ID: <8840D182F8BB7540B173D2B1FA0CA9AB0750C6EE@argos.clb.tcfr.thales> From: Rose-Marie.LIEVROUW@fr.thalesgroup.com To: netconf@ops.ietf.org Subject: distinct startup capability Date: Wed, 14 Dec 2005 19:16:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, Client A does not implement the distinct startup capability and client B does. A and B display the model. If A does a modification in the running, the modification is done in the startup.B knows it. If B does a modification in the startup, only the startup is updated. How can A know it ? Actually this mades that A thinks the equipement will start with a configuration (running) although it will be with an other one (startup different from running). Does someone have the same problem ? thanks for your answer. Rose-Marie LIEVROUW -- to 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 Dec 14 15:27:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmdDP-0004zY-Tp for netconf-archive@megatron.ietf.org; Wed, 14 Dec 2005 15:27:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20251 for ; Wed, 14 Dec 2005 15:26:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emd9Z-0002Si-2L for netconf-data@psg.com; Wed, 14 Dec 2005 20:23:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emd9Y-0002SR-DH for netconf@ops.ietf.org; Wed, 14 Dec 2005 20:23:08 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jBEKN5048790; Wed, 14 Dec 2005 12:23:05 -0800 (PST) (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 jBEKN0593857; Wed, 14 Dec 2005 12:23:00 -0800 (PST) (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 jBEKSHYE068439; Wed, 14 Dec 2005 15:28:17 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200512142028.jBEKSHYE068439@idle.juniper.net> To: Rose-Marie.LIEVROUW@fr.thalesgroup.com cc: netconf@ops.ietf.org Subject: Re: distinct startup capability In-Reply-To: Your message of "Wed, 14 Dec 2005 19:16:48 +0100." <8840D182F8BB7540B173D2B1FA0CA9AB0750C6EE@argos.clb.tcfr.thales> Date: Wed, 14 Dec 2005 15:28:17 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Rose-Marie.LIEVROUW@fr.thalesgroup.com writes: >Actually this mades that A thinks the equipement will start with a configuration (runnin >g) although it will be with an other one (startup different from running). Yes, if A doesn't understand the distinct startup capability, it will fail to copy-config to startup, leaving the original config in place on the next reboot. This leads to the conclusion that all clients must understand/implement the distinct startup capability. The candidate capability makes a more interesting case, since the server faces a decision when a client attempts to write to running. They can fail the write, with an error message saying that only the candidate is writable, or they could assume the client doesn't grok the candidate capability and attempt to locally handle the logic to perform the change (lock, change, commit, unlock). Originally netconf had a base model and the client and server agreed on a set of capabilities that modified that base model. This makes the answer to your question more definitive, but was judged to painful to implement. 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 Wed Dec 14 15:59:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emdio-0004Tp-Ew for netconf-archive@megatron.ietf.org; Wed, 14 Dec 2005 15:59:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23974 for ; Wed, 14 Dec 2005 15:58:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emdcn-0005WN-IU for netconf-data@psg.com; Wed, 14 Dec 2005 20:53:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emdcm-0005W1-Cp for netconf@ops.ietf.org; Wed, 14 Dec 2005 20:53:20 +0000 Received: (qmail 22750 invoked from network); 14 Dec 2005 20:53:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.116 with SMTP; 14 Dec 2005 20:53:19 -0000 Message-ID: <43A0863E.9090706@andybierman.com> Date: Wed, 14 Dec 2005 12:53:18 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Shafer CC: Rose-Marie.LIEVROUW@fr.thalesgroup.com, netconf@ops.ietf.org Subject: Re: distinct startup capability References: <200512142028.jBEKSHYE068439@idle.juniper.net> In-Reply-To: <200512142028.jBEKSHYE068439@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: >Rose-Marie.LIEVROUW@fr.thalesgroup.com writes: > > >>Actually this mades that A thinks the equipement will start with a configuration (runnin >>g) although it will be with an other one (startup different from running). >> >> > >Yes, if A doesn't understand the distinct startup capability, it >will fail to copy-config to startup, leaving the original config >in place on the next reboot. This leads to the conclusion that all >clients must understand/implement the distinct startup capability. > >The candidate capability makes a more interesting case, since the >server faces a decision when a client attempts to write to running. >They can fail the write, with an error message saying that only the >candidate is writable, or they could assume the client doesn't grok >the candidate capability and attempt to locally handle the logic >to perform the change (lock, change, commit, unlock). > >Originally netconf had a base model and the client and server agreed >on a set of capabilities that modified that base model. This makes >the answer to your question more definitive, but was judged to >painful to implement. > > It was more than that. If other access modes such as CLI or SNMP use the native model (whatever it is) than things will break if NETCONF doesn't use the same model. We decided the best we could do is expose the different models in use and make the client deal with it. If you bother to write a NETCONF client then the various standard capabilities should all be understood. The extra commands (or parameter changes) dues to the startup config (1 copy-config command) are minor. >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: From owner-netconf@ops.ietf.org Fri Dec 16 06:17:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnDaw-0007VL-Lp for netconf-archive@megatron.ietf.org; Fri, 16 Dec 2005 06:17:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04481 for ; Fri, 16 Dec 2005 06:16:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnDSx-0002BH-Bq for netconf-data@psg.com; Fri, 16 Dec 2005 11:09:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnDSt-00023r-LO for netconf@ops.ietf.org; Fri, 16 Dec 2005 11:09:31 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2A4244F0002 for ; Fri, 16 Dec 2005 12:09:01 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Dec 2005 12:09:01 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Dec 2005 12:09:00 +0100 Message-ID: <43A2A037.1020009@ericsson.com> Date: Fri, 16 Dec 2005 12:08:39 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: Questions on the Events draft ? References: <6E21698722408147BEA594E073E2B0AB011C9A60@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB011C9A60@xmb-sjc-223.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2005 11:09:01.0000 (UTC) FILETIME=[1E33C480:01C60231] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the long run Ericsson might want to send all alarms via Netconf. When we do that we will definitely need the alarm class information. Also as Percieved Severity and Probable cause are already included in the Annex A this is the last bit of ITU alarm information that is missing. Balazs Hector Trevino (htrevino) wrote: > > >>- Chapter 3.5 Event classes: I would like to see how I can >>transfer the ITU X.733/736 event/alarm classes >>(processingErrorAlarm, QualityofServiceAlarm, >>CommunicationsAlarm, EnviromentalAlarm, etc.) in the netconf event > > > HT: Right now there is no discussion on message encapsulation/transport > other than syslog which is discussed in one of the > appendices. Do you have a need/use for this (i.e. would u use it)? > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager & AXD Operational Suite (AOS) OPM ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@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 Sat Dec 17 15:57:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enj7t-0008WD-9B for netconf-archive@megatron.ietf.org; Sat, 17 Dec 2005 15:57:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09942 for ; Sat, 17 Dec 2005 15:56:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EniyN-000Dkw-4N for netconf-data@psg.com; Sat, 17 Dec 2005 20:48:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.194.124.237] (helo=execdsl.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EniyM-000Dkh-0d for netconf@ops.ietf.org; Sat, 17 Dec 2005 20:48:06 +0000 Received: from [71.161.51.199] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12841801; Sat, 17 Dec 2005 13:45:44 -0700 Message-Id: <6.2.1.2.0.20051217094417.0306cc58@mail.stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 17 Dec 2005 15:47:58 -0500 To: From: "Joel M. Halpern" Subject: Re: [Gen-art] LC Review Assignment: draft-ietf-netconf-prot-10 Cc: bwijnen@lucent.com, Simon Leinen , Andy Bierman , netconf@ops.ietf.org, rpe@juniper.net In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netconf@ops.ietf.org Precedence: bulk I was selected as General Area Review Team reviewer for this specification (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). This document is nearly ready for publication as a proposed standard. It has some issues that should be considered. moderate: I can not find an actual description of the content of a element. I am not refering to the question of what data elements are to be used (that is for the data model I believe.) Rather, I am referring to the absence of a description of how the element actually selects an element to configure, and what attributes are legal on config elements. Reading between the lines, it appears that parallels except that it can have the operation attribute, which is not matched with the underlying data model. And for merge / replace operations seems to assume that the engine has a keying model which will allow it to determine which elements are keys and which elements are replacement values to go with the keys. Such knowledge is not unreasoanble. But it does not appear to be stated anywhere. minor: I believe the more recent XML RFCs have deprecated the distinction between URI and URN. If so, the second sentence of 3.1 about "MUST be URIs, and SHOULD be URNs" may not be particularly helpful. The NETCONF document sometimes uses the phrase "application protocol" for the transport protocol (SSH, TLS, BEEP, ...) This is used for example in 2.1 and 2.2. In other places (including 4.3) "application level" is used to mean the application running over the NETCONF protocol. There, "transport" is used for the supporting protocol. The filtering description starts using a path (file or XPATH like) terminology without providing any explanation of what "path" exactly means. 6.1 talks about the conceptual tree. While 6.2.2 talks about the "absolute path". Some descriptive text would be helpful. (I am guessing this is a reference to the applicable portion of the XPATH terminology, but the text does not seem to say.) is introduced in the example of getting a configuration in a given format. appears to be used to hold the requisite xmlns parameter. I suspect that the intent is that the xmlns parameter can be put on whatever the known top level element (document element) is of the configuration. If so, a little more wording before the example would be helpful. (If something else is intended, then significantly more wording is required.) The description of at the beginning of 7.2 states that this operation "allows the new configuration to be expressing several ways, such as using a local file, a remote file, or inline." However, there is no explanation in the parameters or related text of how one would specify a local file or a remote file. That should not be left purely to the schema. (I note that there is text about this in the section 7.3. Either similar text should be in 7.2, or the wording in the intro of 7.2 should be removed.) It probably would be helpful to explain in 8.3.4.1 the difference between a from candidate to running as compared to a operation. A simple forward reference to the Confirmed Commit capability may suffice. It is odd (not wrong, just odd) that in describing :candidate, the ability to use candidate as a source or target is described in the text, not in the modifications to operations section. But the modifications to lock and unlock, which use the element are described in the modifications section (6.2.5.1.) It is unclear whether the support of the :startup capabilities implies the ability to perform an on the configuration. As written, the text implies that such is not permitted. However, it would be better if this were stated explicitly. (And if this is not the intent, then more words are clearly required. In section 8.8 describing the :url capability, there is reference to various protocols being supported. I suspect that what is intended is actually support for different url schemes (after all, file: is not a protocol.) Down in appendix D (D.1.2, etc.) there is an assumption that the support of the :url capability implies support for named files. Probably, what is need here is that the sentence reference the :url capability should refer to the :url scheme with the file scheme supported. editorial: In the initial description of capabilities in 1.2, it says The capability definition may name one or more dependent capabilities. To support a capability, the server MUST support any capabilities upon which it depends. I presume that the first sentence is trying to say that a capability definition may name one or more capabilities upon which it depends, or upon which it is dependent. The common usage for "dependent capabilites" would mean that it names the capabilities which depend upon it, making extension difficult. ------ OAM NETCONF Configuration Protocol draft-ietf-netconf-prot-10.txt AD: Bert Wijnen Reviewer: Joel M. Halpern -- to 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 Dec 19 07:23:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoK3M-0000IN-Bd for netconf-archive@megatron.ietf.org; Mon, 19 Dec 2005 07:23:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06205 for ; Mon, 19 Dec 2005 07:22:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoJsM-000CX1-0v for netconf-data@psg.com; Mon, 19 Dec 2005 12:12:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoJsK-000CWm-Ce for netconf@ops.ietf.org; Mon, 19 Dec 2005 12:12:20 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F3D18940 for ; Mon, 19 Dec 2005 13:12:14 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 13:12:14 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 13:12:14 +0100 Message-ID: <43A6A39E.8060308@ericsson.com> Date: Mon, 19 Dec 2005 13:12:14 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: draft-lengyel-netconf-granular-locking-00.txt Content-Type: multipart/mixed; boundary="------------070109070404030704090508" X-OriginalArrivalTime: 19 Dec 2005 12:12:14.0691 (UTC) FILETIME=[72A85330:01C60495] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------070109070404030704090508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I wrote a short document about granular locking for Netconf. We in Ericsson feel that there is a strong need for granular locking. Some of our configuration databases are so big that we can not use candidate configurations and for the same reason we must allow simultaneous paralel configuration sessions to manipulate different parts of the configuration. I believe that we dont need to know the contents of the data model before we can devise a granular locking mechanism, just as the mechanism of the subtree-filter is not dependent on the data model it is filtering. Any comments ? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager & AXD Operational Suite (AOS) OPM ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com --------------070109070404030704090508 Content-Type: text/plain; name="draft-lengyel-netconf-granular-locking-00.txt" Content-Disposition: inline; filename="draft-lengyel-netconf-granular-locking-00.txt" Content-Transfer-Encoding: 7bit Network Working Group B. Lengyel Internet-Draft Ericsson Expires: May 14, 2006 December 11, 2005 Granular Locking for the NETCONF Configuration Protocol draft-lengyel-netconf-granular-locking-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The NETCONF protocol describes the lock and unlock operations that (un)lock an entire configuration datastore. Often it is needed to allow multiple management sessions to modify the configuration of a managed element. In these cases it would be needed to be able to lock only a part of a configuration datastore. This draft proposes a capability based extension to the NETCONF protocol to allow this. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. Lengyel Expires May 14, 2006 [Page 1] Internet-Draft Netconf Granular Locking December 2005 1. Introduction The NETCONF protocol describes the lock and unlock operations that (un)lock an entire configuration datastore. Often it is needed to allow multiple management sessions to modify the configuration of a managed element. In these cases it would be needed to be able to lock only a part of a configuration datastore. This draft proposes a capability based extension to the NETCONF protocol to allow this. The managed information model behind NETCONF will not be stable for a considerable time. Even so a mechanism for granular locking can be defined based on the existing subtree filtering and XPATH selection mechanisms in the protocl draft. Granular locking should be introduced as a capability into netconf. 2. Granular Locking Capability 2.1. Overview The :granular-locking capability indicates that the device supports the lock and unlock operations with a scope smaller then a complete configuration datastore. The target can be specified using a combination of a target datastore and a subtree filter or an XPATH filter expression. A granular lock will succeed only if no parts of the scope to be locked are locked by other management users including users of NETCONF or any other management method. The granular unlock operation has to specify the scope just the same way as the granular lock operation. Granular unlock will only succeed if the whole of the specified scope has been locked by the user attempting to use the unlock operation. 2.2. Dependencies The :granular-locking capability's XPATH option is only relevant if the :xpath capability is also supported. 2.3. Capability Identifier The :granular-locking capability is identified by the following capability string: urn:ietf:params:netconf:capability:granular-locking:1.0 2.4. New Operations None. Lengyel Expires May 14, 2006 [Page 3] Internet-Draft Netconf Granular Locking December 2005 2.5. Modifications to Existing Operations 2.5.1. The :granular-locking capability modifies the operation to accept a element beside a . 2.5.2. The :granular-locking capability modifies the operation to accept a element beside a . 3. Security Considerations No change compared to the and operation in [NETCONF]. 4. IANA Considerations None 5. Authors and Acknowledgements This document was written by: Balazs Lengyel, Ericsson 6. References 12.1. Normative References [NETCONF] Enns, R., "NETCONF Configuration Protocol", ID draft-ietf-netconf-prot-09, October 2005. Appendix A. Change Log A.1. First version o Initial version Author's Address Balazs Lengyel (editor) Ericsson P.O. BOX 107 1037 Budapest Hungary Email: balazs.lengyel@ericsson.com --------------070109070404030704090508-- -- to 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 Dec 19 09:38:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoM9Y-0004tT-UP for netconf-archive@megatron.ietf.org; Mon, 19 Dec 2005 09:38:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23408 for ; Mon, 19 Dec 2005 09:37:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoLyu-000G31-5L for netconf-data@psg.com; Mon, 19 Dec 2005 14:27:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoLys-000G2c-Gg for netconf@ops.ietf.org; Mon, 19 Dec 2005 14:27:14 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc12) with SMTP id <20051219142713014008h9qqe>; Mon, 19 Dec 2005 14:27:13 +0000 Reply-To: From: "David B Harrington" To: "'Balazs Lengyel'" , Subject: RE: draft-lengyel-netconf-granular-locking-00.txt Date: Mon, 19 Dec 2005 09:27:07 -0500 Message-ID: <017801c604a8$4b0874a0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYElw/mH4oN/+elSvWC2XebE3QZvAACV+4w In-Reply-To: <43A6A39E.8060308@ericsson.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Balazs, Thanks for submitting this document as a starting point. Can you add a section to your draft that discusses the potential issues that arise from having different operators working on different pieces of a configuration simultaneously, and any suggestions for how to address those issues? I assume that since this is required for some of your company's devices, that there is existing knowledge of issues, and how to address the problems that result from this, and having some of the issues and potential solutions identified here would be useful. Can you also address which other netconf operations might need to be changed to support partial configuration? The :granular-locking "target can be specified using a combination of a target datastore and a subtree filter or an XPATH filter expression." So, for example, will the copy-config, delete-config, and validate commands need to be changed to accept a filter as well? Your draft says "A granular lock will succeed only if no parts of the scope to be locked are locked by other management users including users of NETCONF or any other management method." Can you define scope in the document, so it is clear how one would determine overlap? Some issues surrounding separate configuration of pieces of the "grand" configuration were discussed in 2003. One such thread can be found in the archive at http://ops.ietf.org/lists/netconf/netconf.2003/msg00867.html. Thanks, David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Monday, December 19, 2005 7:12 AM > To: netconf@ops.ietf.org > Subject: draft-lengyel-netconf-granular-locking-00.txt > > I wrote a short document about granular locking for Netconf. > > We in Ericsson feel that there is a strong need for granular locking. > > Some of our configuration databases are so big that we can > not use candidate > configurations and for the same reason we must allow > simultaneous paralel configuration > sessions to manipulate different parts of the configuration. > > I believe that we dont need to know the contents of the data > model before we can devise a > granular locking mechanism, just as the mechanism of the > subtree-filter is not dependent > on the data model it is filtering. > > Any comments ? > > regards Balazs > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager & AXD Operational Suite (AOS) OPM > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@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 Mon Dec 19 11:39:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoO2n-0005Ns-Pd for netconf-archive@megatron.ietf.org; Mon, 19 Dec 2005 11:39:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09823 for ; Mon, 19 Dec 2005 11:38:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoNtX-000DKX-O5 for netconf-data@psg.com; Mon, 19 Dec 2005 16:29:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoNtW-000DFk-AJ for netconf@ops.ietf.org; Mon, 19 Dec 2005 16:29:50 +0000 Received: (qmail 15180 invoked from network); 19 Dec 2005 16:29:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.113 with SMTP; 19 Dec 2005 16:29:49 -0000 Message-ID: <43A6DFF8.9010501@andybierman.com> Date: Mon, 19 Dec 2005 08:29:44 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: draft-lengyel-netconf-granular-locking-00.txt References: <43A6A39E.8060308@ericsson.com> In-Reply-To: <43A6A39E.8060308@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Balazs Lengyel wrote: > I wrote a short document about granular locking for Netconf. > > We in Ericsson feel that there is a strong need for granular locking. > > Some of our configuration databases are so big that we can not use > candidate configurations and for the same reason we must allow > simultaneous paralel configuration sessions to manipulate different > parts of the configuration. > > I believe that we dont need to know the contents of the data model > before we can devise a granular locking mechanism, just as the > mechanism of the subtree-filter is not dependent on the data model it > is filtering. > > Any comments ? - Have you implemented this in product? - There isn't enough detail here for independent implementations to interoperate. - Multiple filter expressions resolve to the same set of nodes in the target configuration. The operator has no way of knowing which exact set of nodes is being locked. How do different operators easily debug a "lock denied" error? - This doesn't really work with our global candidate model does it? According to the standard, any lock is effectively a global lock here. - There are access control issues (not just global candidate issues). Can a user explicitly lock a portion of database without any access to that data? How do they know which portion of their filter expression caused the 'access-denied' error? - The filter mechanisms allow node selection by value. I can lock all the interfaces with an ifInOctets count < 4000. The agent has to honor this request. IMO, there are WAY MORE useless lock scenarios than useful ones that result from Xpath filtering. - I can lock an entry by value, even the value of regular columns (not in the key). What happens if the value changes, such that the Xpath or subtree filter expression changes value, while I hold the lock? Items in the granular lock can drift in and out of locked state. How fun is that to implement correctly? - How do other access modes (SNMP, CLI) interact properly with filter-based locks? If CLI or SNMP only have a global lock then NETCONF won't get to use its partial lock very often anyway. I don't think this problem is as easy to solve as you do. > > regards Balazs Andy >------------------------------------------------------------------------ > > > > >Network Working Group B. Lengyel >Internet-Draft Ericsson >Expires: May 14, 2006 December 11, 2005 > > > Granular Locking for the NETCONF Configuration Protocol > draft-lengyel-netconf-granular-locking-00.txt > >Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on April 14, 2006. > >Copyright Notice > > Copyright (C) The Internet Society (2005). > >Abstract > > The NETCONF protocol describes the lock and unlock operations > that (un)lock an entire configuration datastore. Often it is > needed to allow multiple management sessions to modify the > configuration of a managed element. In these cases it would be > needed to be able to lock only a part of a configuration > datastore. This draft proposes a capability based extension to > the NETCONF protocol to allow this. > > Please send comments to netconf@ops.ietf.org. To subscribe, use > netconf-request@ops.ietf.org. > > >Lengyel Expires May 14, 2006 [Page 1] > >Internet-Draft Netconf Granular Locking December 2005 > > >1. Introduction > > The NETCONF protocol describes the lock and unlock operations > that (un)lock an entire configuration datastore. Often it is > needed to allow multiple management sessions to modify the > configuration of a managed element. In these cases it would be > needed to be able to lock only a part of a configuration > datastore. This draft proposes a capability based extension to > the NETCONF protocol to allow this. > > The managed information model behind NETCONF will not be > stable for a considerable time. Even so a mechanism for granular > locking can be defined based on the existing subtree filtering > and XPATH selection mechanisms in the protocl draft. > > Granular locking should be introduced as a capability into netconf. > > >2. Granular Locking Capability > >2.1. Overview > > The :granular-locking capability indicates that the device supports > the lock and unlock operations with a scope smaller then a complete > configuration datastore. The target can be specified using a > combination of a target datastore and a subtree filter or an > XPATH filter expression. A granular lock will succeed only if no > parts of the scope to be locked are locked by other management > users including users of NETCONF or any other management method. > The granular unlock operation has to specify the scope just the > same way as the granular lock operation. Granular unlock will only > succeed if the whole of the specified scope has been locked by the > user attempting to use the unlock operation. > >2.2. Dependencies > > The :granular-locking capability's XPATH option is only relevant > if the :xpath capability is also supported. > >2.3. Capability Identifier > > The :granular-locking capability is identified by the following > capability string: > > urn:ietf:params:netconf:capability:granular-locking:1.0 > >2.4. New Operations > > None. > > >Lengyel Expires May 14, 2006 [Page 3] > >Internet-Draft Netconf Granular Locking December 2005 > >2.5. Modifications to Existing Operations > >2.5.1. > > The :granular-locking capability modifies the operation > to accept a element beside a . > >2.5.2. > > The :granular-locking capability modifies the operation > to accept a element beside a . > > >3. Security Considerations > > No change compared to the and operation in [NETCONF]. > > >4. IANA Considerations > > None > > >5. Authors and Acknowledgements > > This document was written by: > > Balazs Lengyel, Ericsson > > >6. References > >12.1. Normative References > > [NETCONF] Enns, R., "NETCONF Configuration Protocol", > ID draft-ietf-netconf-prot-09, October 2005. > > >Appendix A. Change Log > >A.1. First version > > o Initial version > > > >Author's Address > > Balazs Lengyel (editor) > Ericsson > P.O. BOX 107 > 1037 Budapest > Hungary > > Email: balazs.lengyel@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 Mon Dec 19 15:02:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoRCq-0006cZ-QO for netconf-archive@megatron.ietf.org; Mon, 19 Dec 2005 15:02:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05125 for ; Mon, 19 Dec 2005 15:00:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoR4h-000EnY-Ob for netconf-data@psg.com; Mon, 19 Dec 2005 19:53:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoR4g-000EnM-Lm for netconf@ops.ietf.org; Mon, 19 Dec 2005 19:53:35 +0000 Received: (qmail 27898 invoked from network); 19 Dec 2005 19:53:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.113 with SMTP; 19 Dec 2005 19:53:34 -0000 Message-ID: <43A70F9A.4090207@andybierman.com> Date: Mon, 19 Dec 2005 11:52:58 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: message-id attribute issues Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I just noticed a couple more details in the schema in prot-10: - the message-id is mandatory to use in the element but optional in the element. It should also be mandatory in the , since all attributes passed in the have to be copied in the . - the data type for this attribute is xsd:string This means everyone has to accept a message-id size of 65535 octets. That is a bit excessive IMO. Can we limit this mandatory attribute to a reasonable size, like 255? 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 Mon Dec 19 20:23:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoWEK-00024j-Gp for netconf-archive@megatron.ietf.org; Mon, 19 Dec 2005 20:23:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17599 for ; Mon, 19 Dec 2005 20:22:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoW5Y-000025-4y for netconf-data@psg.com; Tue, 20 Dec 2005 01:14:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoW5X-000Pyu-JB for netconf@ops.ietf.org; Tue, 20 Dec 2005 01:14:47 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 19 Dec 2005 17:14:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,269,1131350400"; d="scan'208"; a="516857373:sNHT22279480" Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Dec 2005 17:14:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: message-id attribute issues Date: Mon, 19 Dec 2005 17:14:45 -0800 Message-ID: Thread-Topic: message-id attribute issues Thread-Index: AcYE1lsLwQ5x/sWNTSywE4+j48N9zwAK2u7w From: "Rob Enns" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 20 Dec 2005 01:14:46.0623 (UTC) FILETIME=[C43096F0:01C60502] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I just noticed a couple more details in the schema in prot-10: >=20 > - the message-id is mandatory to use in the element > but optional in the element. It should also be > mandatory in the , since all attributes passed in > the have to be copied in the . This was done because if the client sends an without a message-id (which is an error), the server has to respond. > - the data type for this attribute is xsd:string > This means everyone has to accept a message-id size of=20 > 65535 octets. > That is a bit excessive IMO. > Can we limit this mandatory attribute to a reasonable=20 > size, like 255? CLR? ;-) Seriously, I think implementors may find creative things to do with message-id, and 255 could be a bit short. Every implementation will have a practical limit on the messages that can be received; do you think we should limit it in the spec? 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 Tue Dec 20 05:51:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eof61-0002bA-Do for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 05:51:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09909 for ; Tue, 20 Dec 2005 05:50:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eoetk-000JsA-5i for netconf-data@psg.com; Tue, 20 Dec 2005 10:39:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eoetj-000Jry-0K for netconf@ops.ietf.org; Tue, 20 Dec 2005 10:39:11 +0000 Received: (qmail 2904 invoked from network); 20 Dec 2005 10:39:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.111 with SMTP; 20 Dec 2005 10:39:10 -0000 Message-ID: <43A7DED1.5060402@andybierman.com> Date: Tue, 20 Dec 2005 02:37:05 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: "Netconf (E-mail)" Subject: Re: message-id attribute issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Enns wrote: >>I just noticed a couple more details in the schema in prot-10: >> >> - the message-id is mandatory to use in the element >> but optional in the element. It should also be >> mandatory in the , since all attributes passed in >> the have to be copied in the . >> >> > >This was done because if the client sends an without >a message-id (which is an error), the server has to respond. > > okay > > >> - the data type for this attribute is xsd:string >> This means everyone has to accept a message-id size of >>65535 octets. >> That is a bit excessive IMO. >> Can we limit this mandatory attribute to a reasonable >>size, like 255? >> >> > >CLR? ;-) Seriously, I think implementors may find creative things >to do with message-id, and 255 could be a bit short. Every >implementation >will have a practical limit on the messages that can be received; do you >think we should limit it in the spec? > > Right now we have a limit -- it's 65535. If your agent doesn't accept a message-id attribute this big, it is broken. (Imagine that some company like IWL is going to write a test suite to test every one of these limits and tell your customers every place your agent is broken.) >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 Tue Dec 20 08:57:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eohzh-0004De-Ph for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:57:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29162 for ; Tue, 20 Dec 2005 08:56:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eohu0-0008i7-F4 for netconf-data@psg.com; Tue, 20 Dec 2005 13:51:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eohtz-0008eZ-Fs for netconf@ops.ietf.org; Tue, 20 Dec 2005 13:51:39 +0000 Received: (qmail 15698 invoked from network); 20 Dec 2005 13:50:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.112 with SMTP; 20 Dec 2005 13:50:57 -0000 Message-ID: <43A80BC4.1020009@andybierman.com> Date: Tue, 20 Dec 2005 05:48:52 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: ok element Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, From prot-10, sec 4.4: The element is sent in messages if no error occurred during the processing of an request. And the schema for this bit: I think there is a corner-case that needs to be documented. What if the operation succeeds with warnings but no errors? I suggest this edit to sec 4.4: s/no error/no errors or warnings/ It might also be a good idea to point out that an operation can still succeed even if there are elements instead of an element. (They could be warnings, not errors.) 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 Dec 20 14:00:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EomiN-0006M3-Lf for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 13:59:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19140 for ; Tue, 20 Dec 2005 13:58:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EomZH-000BFE-Aq for netconf-data@psg.com; Tue, 20 Dec 2005 18:50:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EomZF-000BEp-Qn for netconf@ops.ietf.org; Tue, 20 Dec 2005 18:50:34 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 231104D3BD; Tue, 20 Dec 2005 19:50:32 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18204-09; Tue, 20 Dec 2005 19:50:30 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) by hermes.iu-bremen.de (Postfix) with ESMTP id DBEDF4CD20; Tue, 20 Dec 2005 19:49:52 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id EA924559CD6; Tue, 20 Dec 2005 19:49:50 +0100 (CET) Date: Tue, 20 Dec 2005 19:49:50 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Rob Enns , "Netconf (E-mail)" Subject: Re: message-id attribute issues Message-ID: <20051220184950.GA1909@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Rob Enns , "Netconf (E-mail)" References: <43A7DED1.5060402@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A7DED1.5060402@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Dec 20, 2005 at 02:37:05AM -0800, Andy Bierman wrote: > >CLR? ;-) Seriously, I think implementors may find creative things > >to do with message-id, and 255 could be a bit short. Every > >implementation > >will have a practical limit on the messages that can be received; do you > >think we should limit it in the spec? > > Right now we have a limit -- it's 65535. > If your agent doesn't accept a message-id attribute this big, it is broken. > > (Imagine that some company like IWL is going to write a test suite > to test every one of these limits and tell your customers every place your > agent is broken.) What about distinguishing between the upper limits as expressed in the XSD and implementation "conformance" requirements? I believe xsd:string is just fine wrt. the upper limit. If people feel strongly that there should be a smaller minimum implementation requirement, then lets define these things as part of an applicability statement or as implementation guidelines. The point is to not hardwire arbitrary choices if we do not have to. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 20 14:53:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EonYN-0006ta-MY for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 14:53:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27149 for ; Tue, 20 Dec 2005 14:52:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EonSd-000FiI-1y for netconf-data@psg.com; Tue, 20 Dec 2005 19:47:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EonSc-000Fi3-2n for netconf@ops.ietf.org; Tue, 20 Dec 2005 19:47:46 +0000 Received: (qmail 10462 invoked from network); 20 Dec 2005 19:47:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.113 with SMTP; 20 Dec 2005 19:47:45 -0000 Message-ID: <43A85FF0.9090909@andybierman.com> Date: Tue, 20 Dec 2005 11:48:00 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: Rob Enns , "Netconf (E-mail)" Subject: Re: message-id attribute issues References: <43A7DED1.5060402@andybierman.com> <20051220184950.GA1909@boskop.local> In-Reply-To: <20051220184950.GA1909@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Tue, Dec 20, 2005 at 02:37:05AM -0800, Andy Bierman wrote: > > > >>>CLR? ;-) Seriously, I think implementors may find creative things >>>to do with message-id, and 255 could be a bit short. Every >>>implementation >>>will have a practical limit on the messages that can be received; do you >>>think we should limit it in the spec? >>> >>> >>Right now we have a limit -- it's 65535. >>If your agent doesn't accept a message-id attribute this big, it is broken. >> >>(Imagine that some company like IWL is going to write a test suite >>to test every one of these limits and tell your customers every place your >>agent is broken.) >> >> > >What about distinguishing between the upper limits as expressed in the >XSD and implementation "conformance" requirements? I believe >xsd:string is just fine wrt. the upper limit. If people feel strongly >that there should be a smaller minimum implementation requirement, >then lets define these things as part of an applicability statement or >as implementation guidelines. The point is to not hardwire arbitrary >choices if we do not have to. > > Let's make conscious decisions about the protocol. This upper limit for the manager is the lower limit for the agent. If the manager is allowed to send it then the agent MUST accept it. I don't know what this idea of a smaller implementation requirement is supposed to mean. Please explain. >/js > > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 20 15:59:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooaO-00025P-Eb for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 15:59:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07536 for ; Tue, 20 Dec 2005 15:58:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EooPu-000JAf-Po for netconf-data@psg.com; Tue, 20 Dec 2005 20:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EooPt-000JAQ-IL for netconf@ops.ietf.org; Tue, 20 Dec 2005 20:49:01 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9A28C4D3DB; Tue, 20 Dec 2005 21:49:00 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28922-07; Tue, 20 Dec 2005 21:48:59 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) by hermes.iu-bremen.de (Postfix) with ESMTP id DB09D4D3D9; Tue, 20 Dec 2005 21:48:58 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 2A266559DA7; Tue, 20 Dec 2005 21:48:56 +0100 (CET) Date: Tue, 20 Dec 2005 21:48:56 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Rob Enns , "Netconf (E-mail)" Subject: Re: message-id attribute issues Message-ID: <20051220204856.GB1936@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Rob Enns , "Netconf (E-mail)" References: <43A7DED1.5060402@andybierman.com> <20051220184950.GA1909@boskop.local> <43A85FF0.9090909@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A85FF0.9090909@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Dec 20, 2005 at 11:48:00AM -0800, Andy Bierman wrote: > Let's make conscious decisions about the protocol. > This upper limit for the manager is the lower limit for the agent. > If the manager is allowed to send it then the agent MUST accept it. > I don't know what this idea of a smaller implementation requirement > is supposed to mean. Please explain. I guess it boils down to the question how hard-wired a limit is. The SMI specs state that an OID is 128 sub-identifiers (something people considered a useful large number several years ago). We now know that this limit hurts with table indexes becoming larger and if you want to do more fancy protocol extensions (which we never got agreement on - but at least the OID limit was one of the factors that did hurt). And we have other somehow arbitrary limits in the SNMP world which then led to CLRs. The size of the message-id attribute might be less of an issue - but who knows for sure? The question I think is whether we forsee that sizes might change in the future and we envision that new ones can be announced via say a capability or whether we hard-wire arbitrary size constraints in the XSD based on what we believe is a good choice today, which means the XSD has to change to lift such limits. /js PS: I did a quick scan of the IMAP specs to see whether they limit the size of the IMAP tag (which I think is very close in nature to netconf's message-id). I did not find a size limit - does anyone know whether such a thing exists? Otherwise, if IMAP can do without a specific size limit, perhaps netconf 1.0 can do as well. -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 20 16:35:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eop99-0000jB-Iq for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 16:35:48 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25294 for ; Tue, 20 Dec 2005 16:34:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eop2n-000LTn-Qo for netconf-data@psg.com; Tue, 20 Dec 2005 21:29:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eop2m-000LTX-Vt for netconf@ops.ietf.org; Tue, 20 Dec 2005 21:29:13 +0000 Received: (qmail 30085 invoked from network); 20 Dec 2005 21:29:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.113 with SMTP; 20 Dec 2005 21:29:12 -0000 Message-ID: <43A877BF.5020507@andybierman.com> Date: Tue, 20 Dec 2005 13:29:35 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: "Netconf (E-mail)" Subject: Re: message-id attribute issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Enns wrote: >..... > >CLR? ;-) Seriously, I think implementors may find creative things >to do with message-id, and 255 could be a bit short. > What would be a reasonable size to allow vendors to still be creative in the way they misuse the NETCONF protocol? :-) Why do they need to overload the message-id with extra semantics? You can put as many of your own attributes in the element as you want. My concern is that we describe (in 4.1) and show this field throughout the document as a 3 digit integer, yet we encode it as a 65535 byte string, without any explanation why. If nobody wants to lower the hard-limit of 65535 that we now have, that's fine. It will be interesting to see what actual hard-limits get used. Manager application developers might be forced to use trial-and-error, instead of the NETCONF spec, to figure out what they can actually send to an agent. >Every >implementation >will have a practical limit on the messages that can be received; do you >think we should limit it in the spec? > >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 Tue Dec 20 19:11:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EorZs-0007Xg-K7 for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 19:11:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21939 for ; Tue, 20 Dec 2005 19:10:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EorPc-0004ju-Ay for netconf-data@psg.com; Wed, 21 Dec 2005 00:00:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EorPb-0004jb-NW for netconf@ops.ietf.org; Wed, 21 Dec 2005 00:00:55 +0000 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 20 Dec 2005 16:00:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,277,1131350400"; d="scan'208"; a="518099174:sNHT22832784" Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 16:00:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: message-id attribute issues Date: Tue, 20 Dec 2005 16:00:36 -0800 Message-ID: Thread-Topic: message-id attribute issues Thread-Index: AcYFrHIlbjLLTl9BSy6ocYFAW2QWXQAFB9Bw From: "Rob Enns" To: "Andy Bierman" Cc: "Netconf \(E-mail\)" X-OriginalArrivalTime: 21 Dec 2005 00:00:55.0081 (UTC) FILETIME=[9D32B190:01C605C1] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > What would be a reasonable size to allow vendors to still be creative > in the way they misuse the NETCONF protocol? :-) >=20 > Why do they need to overload the message-id with extra semantics? > You can put as many of your own attributes in the =20 > element as you want. Yep, true. I just have a feeling (no secret plans) that folks may want to reuse message-ids from other places/namespaces when it's convenient so the flexibility would be nice. > My concern is that we describe (in 4.1) and show this field throughout > the document as a 3 digit integer, yet we encode it as a 65535 byte > string, without any explanation why. >=20 > If nobody wants to lower the hard-limit of 65535 that we now have, > that's fine. It will be interesting to see what actual=20 > hard-limits get used. >=20 > Manager application developers might be forced to use trial-and-error, > instead of the NETCONF spec, to figure out what they can=20 > actually send to an agent. Yes, also the same issue exists with the requirement to return any extra attributes, since they could be large. If we _had_ to come up with an upper limit on message-id length,=20 I'd lean to 1024 bytes as a nice round number. That could be the thin end of the wedge to getting upper limits on all attributes, so I'd still like to avoid it. Rob =20 > >Every > >implementation > >will have a practical limit on the messages that can be=20 > received; do you > >think we should limit it in the spec? > > > >Rob > > > > > > =20 >=20 > Andy >=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: From owner-netconf@ops.ietf.org Tue Dec 20 20:40:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EosxW-00044K-C5 for netconf-archive@megatron.ietf.org; Tue, 20 Dec 2005 20:40:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02313 for ; Tue, 20 Dec 2005 20:38:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eoso0-0009qx-Dg for netconf-data@psg.com; Wed, 21 Dec 2005 01:30:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eosnz-0009ql-G1 for netconf@ops.ietf.org; Wed, 21 Dec 2005 01:30:11 +0000 Received: (qmail 15404 invoked from network); 21 Dec 2005 01:30:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.113 with SMTP; 21 Dec 2005 01:30:10 -0000 Message-ID: <43A8B04C.4000301@andybierman.com> Date: Tue, 20 Dec 2005 17:30:52 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: "Netconf (E-mail)" Subject: Re: message-id attribute issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Enns wrote: >>What would be a reasonable size to allow vendors to still be creative >>in the way they misuse the NETCONF protocol? :-) >> >>Why do they need to overload the message-id with extra semantics? >>You can put as many of your own attributes in the >>element as you want. >> >> > >Yep, true. I just have a feeling (no secret plans) that folks may >want to reuse message-ids from other places/namespaces when it's >convenient so the flexibility would be nice. > > > >>My concern is that we describe (in 4.1) and show this field throughout >>the document as a 3 digit integer, yet we encode it as a 65535 byte >>string, without any explanation why. >> >>If nobody wants to lower the hard-limit of 65535 that we now have, >>that's fine. It will be interesting to see what actual >>hard-limits get used. >> >>Manager application developers might be forced to use trial-and-error, >>instead of the NETCONF spec, to figure out what they can >>actually send to an agent. >> >> > >Yes, also the same issue exists with the requirement to return any >extra attributes, since they could be large. > >If we _had_ to come up with an upper limit on message-id length, >I'd lean to 1024 bytes as a nice round number. That could be the >thin end of the wedge to getting upper limits on all attributes, >so I'd still like to avoid it. > > > What about 4095 octets? That's 20 times bigger than any message-id I would have thought we needed. Big enough to be useful, small enough to be mandatory-to-accept. I realize that this whole issue is sort of covered by the max-message-size issue. After all, that is the real limit here that matters. I understand that 4095 is just an arbitrary a limit as 65535. However, we envision this field being around 16 bytes in actual use. IMO, if we come up with new semantics over time, then we add an additional parameter with an appropriate data type at that time. I want to make sure that manager application developers can reasonably expect to code to the limits in the standard and have agents accept the request. IMO this is different than the size of the element that obviously grows in proportion to the size of the device. >Rob > > Andy > > > >>>Every >>>implementation >>>will have a practical limit on the messages that can be >>> >>> >>received; do you >> >> >>>think we should limit it in the spec? >>> >>>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 Dec 21 13:16:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8Va-0007h9-7Q for netconf-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:16:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26103 for ; Wed, 21 Dec 2005 13:15:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ep8LD-000Ogl-6D for netconf-data@psg.com; Wed, 21 Dec 2005 18:05:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ep8LC-000OgY-3o for netconf@ops.ietf.org; Wed, 21 Dec 2005 18:05:30 +0000 Received: (qmail 11822 invoked from network); 21 Dec 2005 18:05:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.115 with SMTP; 21 Dec 2005 18:05:29 -0000 Message-ID: <43A99964.1040905@andybierman.com> Date: Wed, 21 Dec 2005 10:05:24 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: standard notifications Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Although several WG members have expressed a wide spectrum of opinions on notification content, I think we need to keep trying to find some consensus. First, let's remember what we learned from SNMP. The Trap and Inform PDUs are totally separate (conceptually and in documentation) from the specific notification message content defined in MIB modules. The document we are producing first is the message processing part. The data modeling requirements (e.g., XSD and RelaxNG templates) need to be documented here, but we need a separate document for standard notification content, such as "config-change", "capability-change". We can work on both problems concurrently by starting a list (then a document) of standard notifications. This is a coupling and cohesion issue -- I'm not trying to defer or avoid the standard notification content issue. 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 Dec 21 13:58:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9Ar-00073K-3U for netconf-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:58:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00804 for ; Wed, 21 Dec 2005 13:57:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ep91K-0001XW-Su for netconf-data@psg.com; Wed, 21 Dec 2005 18:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ep91K-0001XG-9l for netconf@ops.ietf.org; Wed, 21 Dec 2005 18:49:02 +0000 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id jBLIn7cU008415; Wed, 21 Dec 2005 10:49:07 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id jBLImwJX029372; Wed, 21 Dec 2005 10:48:58 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id jBLImw01029369; Wed, 21 Dec 2005 10:48:58 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 21 Dec 2005 10:48:58 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: standard notifications In-Reply-To: <43A99964.1040905@andybierman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, I agree with you that the operations and the content can be separated. However, there are "fields" of SNMP v2Trap & inform that are encoded as part of the content. I believe that this is confusing. Also, time and again people that have used other notification systems wonder where are the missing fields such as perceived severity, and when told that they are not available, then wonder how to add them. So, to me, the critical issues are: 1) what fields should be part of the message and what should be optional subfields of the content 2) how can additional fields be added to the message On Wed, 21 Dec 2005, Andy Bierman wrote: > Hi, > > Although several WG members have expressed a wide spectrum > of opinions on notification content, I think we need to keep trying > to find some consensus. > > First, let's remember what we learned from SNMP. > The Trap and Inform PDUs are totally separate > (conceptually and in documentation) from the specific notification > message content defined in MIB modules. > > The document we are producing first is the message processing part. > The data modeling requirements (e.g., XSD and RelaxNG templates) > need to be documented here, but we need a separate document for > standard notification content, such as "config-change", "capability-change". > > We can work on both problems concurrently by starting a list > (then a document) of standard notifications. This is a coupling > and cohesion issue -- I'm not trying to defer or avoid the > standard notification content issue. > > Andy > Regards, /david t. perkins -- to 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 Dec 21 17:36:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpCZn-00061W-Ly for netconf-archive@megatron.ietf.org; Wed, 21 Dec 2005 17:36:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21600 for ; Wed, 21 Dec 2005 17:35:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpCR4-000JJT-A5 for netconf-data@psg.com; Wed, 21 Dec 2005 22:27:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpCR3-000JJH-NJ for netconf@ops.ietf.org; Wed, 21 Dec 2005 22:27:49 +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 jBLMRn1Z053256 for ; Wed, 21 Dec 2005 14:27:49 -0800 (PST) (envelope-from lzhang@juniper.net) Received: from juniper.net (lzhang-bsd.juniper.net [172.17.58.29]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBLMRm591758 for ; Wed, 21 Dec 2005 14:27:49 -0800 (PST) (envelope-from lzhang@juniper.net) Message-ID: <43A9D6E4.1070702@juniper.net> Date: Wed, 21 Dec 2005 14:27:48 -0800 From: Lei Zhang User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: kill-session: editorial mistake Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In draft 10: 7.9. Description: Force the termination of a NETCONF session. When a NETCONF entity receives a request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session and close any associated connections. ... ... Otherwise, the operation does not roll back configuration or other device state modifications made by the entity holding the lock. And: 8.3.5.1. and ... ... To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the operation or implicitly from session failure. The two sections conflict with each other. The 'otherwise' paragraph of seems to be misplaced right? Thanks, Lei -- to 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 Dec 21 22:55:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpHYF-0000Wa-JE for netconf-archive@megatron.ietf.org; Wed, 21 Dec 2005 22:55:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21398 for ; Wed, 21 Dec 2005 22:54:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpHL7-000GU1-0l for netconf-data@psg.com; Thu, 22 Dec 2005 03:42:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,HTML_90_100, HTML_MESSAGE,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [61.144.161.54] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpHL4-000GRr-TS for netconf@ops.ietf.org; Thu, 22 Dec 2005 03:42:00 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRV006DFRW6JB@szxga02-in.huawei.com> for netconf@ops.ietf.org; Thu, 22 Dec 2005 11:48:06 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRV008NQRW5AC@szxga02-in.huawei.com> for netconf@ops.ietf.org; Thu, 22 Dec 2005 11:48:06 +0800 (CST) Received: from l48181 ([10.110.100.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRV00DOBRVX4Y@szxml02-in.huawei.com> for netconf@ops.ietf.org; Thu, 22 Dec 2005 11:47:57 +0800 (CST) Date: Thu, 22 Dec 2005 11:37:19 +0800 From: =?gb2312?B?wO7R0g==?= Subject: rpc-reply fragmentation To: netconf@ops.ietf.org Message-id: <000001c606a9$035b69c0$39646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_qP4+OOQTlir2qY0p5IOfMg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_qP4+OOQTlir2qY0p5IOfMg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi I think we need rpc-reply fragmentation when the result of get or get-config operation is very huge. Suppose I retrieve a route table which contains 10,000 routes. I have to wait for a long time until the device form a whole rpc-reply. If we allow rpc-reply fragmentation, the 10,000 routes can be returned in multiple rpc-reply. So I can see a portion of result rapidly. What's your opinion? --Boundary_(ID_qP4+OOQTlir2qY0p5IOfMg) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable

Hi

I think we need rpc-reply fragmentation when the result of get or get-config = operation is very huge.

Suppose I retrieve a route table which contains 10,000 routes. I have to wait for = a long time until the device form a whole rpc-reply. If we allow rpc-reply fragmentation, the 10,000 routes can be returned in multiple rpc-reply. = So I can see a portion of result rapidly.

What's your opinion?

--Boundary_(ID_qP4+OOQTlir2qY0p5IOfMg)-- -- to 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 Dec 22 10:21:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpSFY-0003n3-L9 for netconf-archive@megatron.ietf.org; Thu, 22 Dec 2005 10:21:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24672 for ; Thu, 22 Dec 2005 10:19:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpS5O-000Kxf-6V for netconf-data@psg.com; Thu, 22 Dec 2005 15:10:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpS5M-000KxR-JE for netconf@ops.ietf.org; Thu, 22 Dec 2005 15:10:28 +0000 Received: (qmail 14911 invoked from network); 22 Dec 2005 15:10:27 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.115 with SMTP; 22 Dec 2005 15:10:27 -0000 Message-ID: <43AAC1E3.30205@andybierman.com> Date: Thu, 22 Dec 2005 07:10:27 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?GB2312?B?wO7R0g==?= CC: netconf@ops.ietf.org Subject: Re: rpc-reply fragmentation References: <000001c606a9$035b69c0$39646e0a@china.huawei.com> In-Reply-To: <000001c606a9$035b69c0$39646e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA24672 =C0=EE=D1=D2 wrote: > Hi > > I think we need rpc-reply fragmentation when the result of get or > get-config operation is very huge. > > Suppose I retrieve a route table which contains 10,000 routes. I have > to wait for a long time until the device form a whole rpc-reply. If we > allow rpc-reply fragmentation, the 10,000 routes can be returned in > multiple rpc-reply. So I can see a portion of result rapidly. > > What's your opinion? > The WG discussed this many times in the past. This is considered an implementation issue, since there are ways to implement NETCONF in a stream-oriented fashion, and there are ways for the manager to ask for subsets of data. 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 Dec 22 11:02:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpStj-0003Ra-Ns for netconf-archive@megatron.ietf.org; Thu, 22 Dec 2005 11:02:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28710 for ; Thu, 22 Dec 2005 11:01:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpSnY-000O5Z-Du for netconf-data@psg.com; Thu, 22 Dec 2005 15:56:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpSnX-000O5M-OL for netconf@ops.ietf.org; Thu, 22 Dec 2005 15:56:08 +0000 Received: (qmail 4292 invoked from network); 22 Dec 2005 15:56:07 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.115 with SMTP; 22 Dec 2005 15:56:07 -0000 Message-ID: <43AACC96.6020107@andybierman.com> Date: Thu, 22 Dec 2005 07:56:06 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lei Zhang CC: netconf@ops.ietf.org Subject: Re: kill-session: editorial mistake References: <43A9D6E4.1070702@juniper.net> In-Reply-To: <43A9D6E4.1070702@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Lei Zhang wrote: > In draft 10: > > 7.9. > > Description: > > Force the termination of a NETCONF session. > > When a NETCONF entity receives a request for an > open session, it will abort any operations currently in process, > release any locks and resources associated with the session and > close any associated connections. > > ... ... > > Otherwise, the operation does not roll back > configuration or other device state modifications made by the > entity holding the lock. > > And: > > 8.3.5.1. and > > ... ... To facilitate easy > recovery, any outstanding changes are discarded when the lock is > released, whether explicitly with the operation or > implicitly from session failure. > > > The two sections conflict with each other. The 'otherwise' paragraph > of > seems to be misplaced right? No. Sec. 7.9 is referring to changes that have been commited from to . If the occurs after the first but before the second , then the agent treats the the same as a dropped session, and reverts the config. Sec. 8.3.5.1 is referring to any edits pending in the which have not been committed yet. That sentence you highlighted says that a is implicitly performed by the agent whenever a lock on is released. > > Thanks, > Lei 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 Dec 22 12:09:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpTwP-0002DY-55 for netconf-archive@megatron.ietf.org; Thu, 22 Dec 2005 12:09:21 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06955 for ; Thu, 22 Dec 2005 12:08:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpToX-0002q3-Ec for netconf-data@psg.com; Thu, 22 Dec 2005 17:01:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpToU-0002pX-SL for netconf@ops.ietf.org; Thu, 22 Dec 2005 17:01:11 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jBMH16500902; Thu, 22 Dec 2005 09:01:06 -0800 (PST) (envelope-from lzhang@juniper.net) Received: from juniper.net (lzhang-bsd.juniper.net [172.17.58.29]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBMH11532941; Thu, 22 Dec 2005 09:01:01 -0800 (PST) (envelope-from lzhang@juniper.net) Message-ID: <43AADBCD.5020400@juniper.net> Date: Thu, 22 Dec 2005 09:01:01 -0800 From: Lei Zhang User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman CC: netconf@ops.ietf.org Subject: Re: kill-session: editorial mistake References: <43A9D6E4.1070702@juniper.net> <43AACC96.6020107@andybierman.com> In-Reply-To: <43AACC96.6020107@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > Sec. 7.9 is referring to changes that have been commited from > to . If the occurs after the first > but before > the second , then the agent treats the the same > as a dropped session, and reverts the config. ok that sounds reasonable. The text sure can use some rewrite to clarify things up. Thanks, Lei -- to 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 Dec 22 14:04:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpVk9-0007Nr-7o for netconf-archive@megatron.ietf.org; Thu, 22 Dec 2005 14:04:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20086 for ; Thu, 22 Dec 2005 14:03:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpVbP-000BJy-FY for netconf-data@psg.com; Thu, 22 Dec 2005 18:55:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpVbO-000BJm-Ua for netconf@ops.ietf.org; Thu, 22 Dec 2005 18:55:46 +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 jBMItY1V019619; Thu, 22 Dec 2005 10:55:34 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Dec 2005 10:58:41 -0800 Message-ID: From: "McDonald, Ira" To: "'Lei Zhang'" , Andy Bierman Cc: netconf@ops.ietf.org Subject: RE: kill-session: editorial mistake Date: Thu, 22 Dec 2005 10:58:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I agree with Lei Zhang - the spec is _very_ deficient in stating this subtle behavior. Thanks to Andy for clarifying the (somewhat) surprising intended behavior - but expecting implementors to get that much implied context out of these paragraphs in the spec is inherently unsafe for interoperability. 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 Lei Zhang > Sent: Thursday, December 22, 2005 12:01 PM > To: Andy Bierman > Cc: netconf@ops.ietf.org > Subject: Re: kill-session: editorial mistake > > > Andy Bierman wrote: > > > Sec. 7.9 is referring to changes that have been commited > from > > to . If the occurs after the first > > > but before > > the second , then the agent treats the > the same > > as a dropped session, and reverts the config. > > ok that sounds reasonable. The text sure can use some rewrite > to clarify > things up. > > Thanks, > Lei > > > > > -- > to 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 Dec 22 14:37:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpWFm-0002T5-8E for netconf-archive@megatron.ietf.org; Thu, 22 Dec 2005 14:37:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23846 for ; Thu, 22 Dec 2005 14:36:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpW7F-000E0d-Vr for netconf-data@psg.com; Thu, 22 Dec 2005 19:28:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpW7E-000E0S-Vw for netconf@ops.ietf.org; Thu, 22 Dec 2005 19:28:41 +0000 Received: (qmail 5673 invoked from network); 22 Dec 2005 19:28:40 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.111 with SMTP; 22 Dec 2005 19:28:40 -0000 Message-ID: <43AAFE67.5050803@andybierman.com> Date: Thu, 22 Dec 2005 11:28:39 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" CC: "'Lei Zhang'" , netconf@ops.ietf.org Subject: Re: kill-session: editorial mistake References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: >Hi, > >I agree with Lei Zhang - the spec is _very_ deficient >in stating this subtle behavior. > >Thanks to Andy for clarifying the (somewhat) surprising >intended behavior - but expecting implementors to get >that much implied context out of these paragraphs in >the spec is inherently unsafe for interoperability. > > Agreed that this detail is fairly well buried. At first, I thought this was a bug, but then I remembered we talked about this in the past (forget when). Phil explained to me that this is a feature, not a bug. I always learned that you try to keep the Astonishment Factor as low as possible. This is certainly not a side effect of that one would reasonably expect to find. But if you use locks correctly, nothing will be in the to discard. >Cheers, >- Ira > > 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 Dec 22 15:59:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXX1-0007zi-K7 for netconf-archive@megatron.ietf.org; Thu, 22 Dec 2005 15:59:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03451 for ; Thu, 22 Dec 2005 15:58:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpXM8-000Ohk-Rf for netconf-data@psg.com; Thu, 22 Dec 2005 20:48:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpXM8-000OhZ-91 for netconf@ops.ietf.org; Thu, 22 Dec 2005 20:48:08 +0000 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 22 Dec 2005 12:48:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,285,1131350400"; d="scan'208"; a="518508057:sNHT22585616" Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 12:48:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: message-id attribute issues Date: Thu, 22 Dec 2005 12:47:51 -0800 Message-ID: Thread-Topic: message-id attribute issues Thread-Index: AcYFziBiIhYanCfHTlWtsbxBErXU+gBaa+tw From: "Rob Enns" To: "Andy Bierman" Cc: "Netconf \(E-mail\)" X-OriginalArrivalTime: 22 Dec 2005 20:48:07.0674 (UTC) FILETIME=[034FF5A0:01C60739] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > What about 4095 octets? That's 20 times > bigger than any message-id I would have thought we needed. > Big enough to be useful, small enough to be mandatory-to-accept. >=20 > I realize that this whole issue is sort of > covered by the max-message-size issue. > After all, that is the real limit here that matters. >=20 > I understand that 4095 is just an arbitrary a limit as 65535. > However, we envision this field being around 16 bytes in > actual use. IMO, if we come up with new semantics over > time, then we add an additional parameter with an appropriate > data type at that time. >=20 > I want to make sure that manager application developers > can reasonably expect to code to the limits in the standard > and have agents accept the request. >=20 > IMO this is different than the size of the element that > obviously grows in proportion to the size of the device. 4095 bytes seems plenty large, but as you say it's still arbitrary. If you really think message-id should be capped, I'm fine with this value.=20 Any other opinions out there? 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 Sat Dec 24 13:39:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqEJ5-0007sx-Jn for netconf-archive@megatron.ietf.org; Sat, 24 Dec 2005 13:39:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14724 for ; Sat, 24 Dec 2005 13:38:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqEAO-0007Ef-DO for netconf-data@psg.com; Sat, 24 Dec 2005 18:30:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqEAN-0007EN-Kt for netconf@ops.ietf.org; Sat, 24 Dec 2005 18:30:51 +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 jBOIUfCm018574; Sat, 24 Dec 2005 10:30:41 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 24 Dec 2005 10:33:51 -0800 Message-ID: From: "McDonald, Ira" To: "'Rob Enns'" , Andy Bierman Cc: "Netconf (E-mail)" Subject: Limits in Netconf XML schema Date: Sat, 24 Dec 2005 10:33:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, 4095 seems more than sufficient for the message-id attribute (even allowing for several imbedded long opaque URIs in some vendor-specific format). I suggest that the XML Schema for Netconf SHOULD specify upper size limits on all string/keyword/URI attributes and lower/upper value limits on integer attributes. A Netconf test suite is going to try to test limits. If the upper limits are all implementation-specific, then quite soon some interoperability is going to get lost because an implementor made a (permitted) restrictive size choice. 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: Thursday, December 22, 2005 3:48 PM > To: Andy Bierman > Cc: Netconf (E-mail) > Subject: RE: message-id attribute issues > > > > What about 4095 octets? That's 20 times > > bigger than any message-id I would have thought we needed. > > Big enough to be useful, small enough to be mandatory-to-accept. > > > > I realize that this whole issue is sort of > > covered by the max-message-size issue. > > After all, that is the real limit here that matters. > > > > I understand that 4095 is just an arbitrary a limit as 65535. > > However, we envision this field being around 16 bytes in > > actual use. IMO, if we come up with new semantics over > > time, then we add an additional parameter with an appropriate > > data type at that time. > > > > I want to make sure that manager application developers > > can reasonably expect to code to the limits in the standard > > and have agents accept the request. > > > > IMO this is different than the size of the element that > > obviously grows in proportion to the size of the device. > > 4095 bytes seems plenty large, but as you say it's still arbitrary. > If you really think message-id should be capped, I'm fine with this > value. > Any other opinions out there? > > 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 Mon Dec 26 11:36:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqvKS-00038J-SP for netconf-archive@megatron.ietf.org; Mon, 26 Dec 2005 11:36:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03724 for ; Mon, 26 Dec 2005 11:34:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqvCE-000Leh-Kj for netconf-data@psg.com; Mon, 26 Dec 2005 16:27:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqvCD-000LeU-CY for netconf@ops.ietf.org; Mon, 26 Dec 2005 16:27:37 +0000 Received: (qmail 15033 invoked from network); 26 Dec 2005 16:27:36 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.116 with SMTP; 26 Dec 2005 16:27:36 -0000 Message-ID: <43B019F7.9010902@andybierman.com> Date: Mon, 26 Dec 2005 08:27:35 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: errorInfoContent Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We removed this group from the schema because it isn't used in the schema, but we still need it. There are standard error-info elements defined in the document that need normative syntax specified in the schema. The wrong syntax is shown below. Don't use this one from prot-09. I'm not sure how to write the correct schema, but here's how it should work: - the order and combinations of these elements should not be constrained - the standard errors specify the minimum content, not the only content, as this schema fragment might imply. - all syntax is QName, except session-id is SessionId (unsignedInt) - all maxOccurs should be "unbounded", except session-id is 1. - although in general there are no required elements (so minOccurs="0"), there are specific standard errors that require specific elements to be present in the error-info field. The schema does not reflect this, but the normative text is clear on the details. So Rob, do you understand the edits? :-) 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 Mon Dec 26 13:48:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqxOi-0002nA-KI for netconf-archive@megatron.ietf.org; Mon, 26 Dec 2005 13:48:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19010 for ; Mon, 26 Dec 2005 13:47:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqxHI-0006LI-SS for netconf-data@psg.com; Mon, 26 Dec 2005 18:41:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [207.69.195.70] (helo=pop-borzoi.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqxHH-0006L4-Nk for netconf@ops.ietf.org; Mon, 26 Dec 2005 18:41:00 +0000 Received: from h-68-166-37-167.snvacaid.dynamic.covad.net ([68.166.37.167] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EqxHE-0005tC-00 for netconf@ops.ietf.org; Mon, 26 Dec 2005 13:40:57 -0500 Message-ID: <000401c60a4c$aa8b83a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Netconf \(E-mail\)" References: <43B019F7.9010902@andybierman.com> Subject: Re: errorInfoContent Date: Mon, 26 Dec 2005 10:46:20 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: "Andy Bierman" > To: "Netconf (E-mail)" > Sent: Monday, December 26, 2005 8:27 AM > Subject: errorInfoContent ... > - the order and combinations of these elements should not be constrained ... I understand wanting to not constrain the combinations. What's the motivation for not constraining the order? Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 26 14:19:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqxsc-0007y3-Je for netconf-archive@megatron.ietf.org; Mon, 26 Dec 2005 14:19:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22622 for ; Mon, 26 Dec 2005 14:18:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqxoJ-0009Y7-9W for netconf-data@psg.com; Mon, 26 Dec 2005 19:15:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqxoG-0009X8-JX for netconf@ops.ietf.org; Mon, 26 Dec 2005 19:15:04 +0000 Received: (qmail 22693 invoked from network); 26 Dec 2005 19:15:03 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.112 with SMTP; 26 Dec 2005 19:15:03 -0000 Message-ID: <43B04131.9050406@andybierman.com> Date: Mon, 26 Dec 2005 11:14:57 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Netconf (E-mail)" Subject: Re: errorInfoContent References: <43B019F7.9010902@andybierman.com> <000401c60a4c$aa8b83a0$7f1afea9@oemcomputer> In-Reply-To: <000401c60a4c$aa8b83a0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: >Hi - > > > >>From: "Andy Bierman" >>To: "Netconf (E-mail)" >>Sent: Monday, December 26, 2005 8:27 AM >>Subject: errorInfoContent >> >> >... > > >> - the order and combinations of these elements should not be constrained >> >> >... > >I understand wanting to not constrain the combinations. >What's the motivation for not constraining the order? > > Because the real syntax of is 'any'. But if we have to constrain it because of XSD, then 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 Tue Dec 27 17:32:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNMz-0007EK-MB for netconf-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:32:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28015 for ; Tue, 27 Dec 2005 17:31:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErNDP-0006G0-9g for netconf-data@psg.com; Tue, 27 Dec 2005 22:22:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErNDO-0006Fc-Ky for netconf@ops.ietf.org; Tue, 27 Dec 2005 22:22:42 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 27 Dec 2005 14:22:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,298,1131350400"; d="scan'208"; a="519326721:sNHT24211096" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Dec 2005 14:22:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: errorInfoContent Date: Tue, 27 Dec 2005 14:22:19 -0800 Message-ID: Thread-Topic: errorInfoContent Thread-Index: AcYKOcwaVBZ/E0b5Ry+jidM1qvawxwA+Q1Yw From: "Rob Enns" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 27 Dec 2005 22:22:42.0055 (UTC) FILETIME=[0D928970:01C60B34] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Hi, >=20 > We removed this group from the schema because it > isn't used in the schema, but we still need it. >=20 > There are standard error-info elements defined in the document > that need normative syntax specified in the schema. >=20 > The wrong syntax is shown below. Don't use this one from prot-09. >=20 > > > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > > >=20 >=20 > I'm not sure how to write the correct schema, but here's how=20 > it should work: >=20 > - the order and combinations of these elements should not=20 > be constrained > - the standard errors specify the minimum content, not the=20 > only content, > as this schema fragment might imply. > - all syntax is QName, except session-id is SessionId (unsignedInt) > - all maxOccurs should be "unbounded", except session-id is 1. > - although in general there are no required elements (so=20 > minOccurs=3D"0"), > there are specific standard errors that require=20 > specific elements to > be present in the error-info field. The schema does=20 > not reflect=20 > this, > but the normative text is clear on the details. >=20 > So Rob, do you understand the edits? :-) I think I added this element and then botched the hookup into the rest of the schema, because I could not get my XSD validator to grok what I wanted to do. :-/ The rub, if I recall, was to get this element accepted, along with "anything else". I'll take another crack at it this week. 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 Dec 28 10:01:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ercng-0001xB-2j for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 10:01:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15494 for ; Wed, 28 Dec 2005 10:00:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ercfy-0009GE-KR for netconf-data@psg.com; Wed, 28 Dec 2005 14:53:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ercfv-0009Fu-D9 for netconf@ops.ietf.org; Wed, 28 Dec 2005 14:53:13 +0000 Received: (qmail 27832 invoked from network); 28 Dec 2005 14:53:10 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.111 with SMTP; 28 Dec 2005 14:53:10 -0000 Message-ID: <43B2A6DD.1050006@andybierman.com> Date: Wed, 28 Dec 2005 06:53:17 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: pending edits for prot-10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I want to wrap up the various change proposals to the protocol document, so Bert can get an updated version ASAP. The following changes will be made in the next version: 1) change the order of the and parameters in the command 2) add a maxLength="4095" constraint to the attribute 3) provide XSD for standard content (was removed from prot-10; needs to be fixed and replaced) The following change is agreed upon, but the replacement text with all the details has not been written yet: 4) optionally advertise your own max-message-size in the capabilities exchange Comments? Objections? 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 Dec 28 12:03:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EreiD-0002fl-N2 for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 12:03:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10473 for ; Wed, 28 Dec 2005 12:02:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EreZc-000IUM-9a for netconf-data@psg.com; Wed, 28 Dec 2005 16:54:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.65] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EreZb-000IU5-3j for netconf@ops.ietf.org; Wed, 28 Dec 2005 16:54:47 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe03.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 69073505; Wed, 28 Dec 2005 17:54:45 +0100 Date: Wed, 28 Dec 2005 17:54:39 +0100 (CET) Message-Id: <20051228.175439.75430174.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: pending edits for prot-10 From: Martin Bjorklund In-Reply-To: <43B2A6DD.1050006@andybierman.com> References: <43B2A6DD.1050006@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > 4) optionally advertise your own max-message-size in the > capabilities exchange > > I think this would be unfortunate if it's supposed to be used for all messages, and not just notifications. o This makes it difficult to implement agents which stream the XML, e.g. as you suggested as a way to handle big routing tables. (FYI, our implementation uses this technique). These implementations would have to buffer all data before sending it, or to try to calculate the size of the message before actually sending it (which may or may not be possible). o Some (most?) implementations will probably use a streaming approach for XML parsing, which means that it might be tricky to set a max message size since the overhead of the XML encoding can be difficult to calculate. o If it's optional, does that mean that an agent can choose to NOT recognize this parameter, and send larger messages anyway? In either case, a manager will probably have to be able to discard messages that are too big. So why can't the manager do this all the time? (for replies that is, for one-way non-acked notifications I can see the value in letting the agent know on beforehand if the manager will be able to handle the message or not. maybe...) o Making this a "global" value might also be difficult to implement for a manager - some replies might just be streamed to disk for later processing, such as a big routing table. (ok, a manager could start a new session each time a request would need a different value). > BTW, the type should probably be xs:positiveInteger. > Comments? Objections? The only other comment I have is that it would be nice to know why noone seems to be interested in the xpath namespace issue. Don't you think it's a real problem? Or should implementations invent their own ways of handling this (if so, it could be mentioned in the doc). /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 28 12:59:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErfaZ-0001Vj-CP for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 12:59:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18593 for ; Wed, 28 Dec 2005 12:58:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErfTB-000MDf-9l for netconf-data@psg.com; Wed, 28 Dec 2005 17:52:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErfTA-000MDT-Dw for netconf@ops.ietf.org; Wed, 28 Dec 2005 17:52:12 +0000 Received: (qmail 9701 invoked from network); 28 Dec 2005 17:50:36 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.112 with SMTP; 28 Dec 2005 17:50:36 -0000 Message-ID: <43B2D06B.6000604@andybierman.com> Date: Wed, 28 Dec 2005 09:50:35 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: pending edits for prot-10 References: <43B2A6DD.1050006@andybierman.com> <20051228.175439.75430174.mbj@tail-f.com> In-Reply-To: <20051228.175439.75430174.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >Andy Bierman wrote: > > >> 4) optionally advertise your own max-message-size in the >> capabilities exchange >> >> >> >> > >I think this would be unfortunate if it's supposed to be used for all >messages, and not just notifications. > > I think we need to say it's not used for anything until we understand all the details. Put item 4 in the 'pending' column. > o This makes it difficult to implement agents which stream the XML, > e.g. as you suggested as a way to handle big routing tables. > (FYI, our implementation uses this technique). These > implementations would have to buffer all data before sending it, > or to try to calculate the size of the message before actually > sending it (which may or may not be possible). > > o Some (most?) implementations will probably use a streaming > approach for XML parsing, which means that it might be tricky to > set a max message size since the overhead of the XML encoding can > be difficult to calculate. > > o If it's optional, does that mean that an agent can choose to NOT > recognize this parameter, and send larger messages anyway? In > either case, a manager will probably have to be able to discard > messages that are too big. So why can't the manager do this all > the time? (for replies that is, for one-way non-acked > notifications I can see the value in letting the agent know on > beforehand if the manager will be able to handle the message or > not. maybe...) > > Yes -- I should have clarified the word "optional". I think there was more consensus for this parameter if it was treated as a hint, not as a rule. How can one argue against that? What could that be? You would rather be ignorant of the fact the other NC peer is throwing away your messages? A stream-based implementation is not mandatory. An implementation is allowed to have a maximum message size (that it can receive), but there is no minimum value any implementation has to support. (This is a political compromise intended to confuse people when they try to assign blame for a broken multi-vendor NETCONF system ;-) If you want successful interoperability, I suggest not ignoring the max-message-size of the other peer. > o Making this a "global" value might also be difficult to implement > for a manager - some replies might just be streamed to disk for > later processing, such as a big routing table. (ok, a manager > could start a new session each time a request would need a > different value). > > > > >> >> >> > >BTW, the type should probably be xs:positiveInteger. > > okay > > > >>Comments? Objections? >> >> > >The only other comment I have is that it would be nice to know why >noone seems to be interested in the xpath namespace issue. Don't you >think it's a real problem? Or should implementations invent their own >ways of handling this (if so, it could be mentioned in the doc). > > oops - I forgot that one. Of course we care about namespaces! Right? I was planning on just following your suggestion in my implementation: I guess the document needs to clarify this issue. From your email on 12/12: d:top/d:users/d:user[name="fred"]/d:companyInfo/d:dept Xpath really doesn't have any way of specifying namespaces? Will the expression above break existing Xpath tools? Maybe most people just plan on getting namespace processing wrong :-) > > >/martin > > > > > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 28 14:17:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgnI-00054u-86 for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:17:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27728 for ; Wed, 28 Dec 2005 14:15:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErggP-0000Xp-J8 for netconf-data@psg.com; Wed, 28 Dec 2005 19:09:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.193] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErggO-0000Xd-DE for netconf@ops.ietf.org; Wed, 28 Dec 2005 19:09:56 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe07.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 64496651; Wed, 28 Dec 2005 20:09:53 +0100 Date: Wed, 28 Dec 2005 20:09:46 +0100 (CET) Message-Id: <20051228.200946.21927265.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: pending edits for prot-10 From: Martin Bjorklund In-Reply-To: <43B2D06B.6000604@andybierman.com> References: <43B2A6DD.1050006@andybierman.com> <20051228.175439.75430174.mbj@tail-f.com> <43B2D06B.6000604@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > Martin Bjorklund wrote: > > >Andy Bierman wrote: > > > > > >> 4) optionally advertise your own max-message-size in the > >> capabilities exchange > >> > >> > >> > >> > > > >I think this would be unfortunate if it's supposed to be used for all > >messages, and not just notifications. > > > > > > I think we need to say it's not used for anything until > we understand all the details. Put item 4 in the 'pending' column. ok. but if that's the case, why not wait and add the capability later? > > o This makes it difficult to implement agents which stream the XML, > > e.g. as you suggested as a way to handle big routing tables. > > (FYI, our implementation uses this technique). These > > implementations would have to buffer all data before sending it, > > or to try to calculate the size of the message before actually > > sending it (which may or may not be possible). > > > > o Some (most?) implementations will probably use a streaming > > approach for XML parsing, which means that it might be tricky to > > set a max message size since the overhead of the XML encoding can > > be difficult to calculate. > > > > o If it's optional, does that mean that an agent can choose to NOT > > recognize this parameter, and send larger messages anyway? In > > either case, a manager will probably have to be able to discard > > messages that are too big. So why can't the manager do this all > > the time? (for replies that is, for one-way non-acked > > notifications I can see the value in letting the agent know on > > beforehand if the manager will be able to handle the message or > > not. maybe...) > > > > > > Yes -- I should have clarified the word "optional". > I think there was more consensus for this parameter if it > was treated as a hint, not as a rule. > > How can one argue against that? > What could that be? You would rather be ignorant of > the fact the other NC peer is throwing away your messages? For a reply to a request by the same manager, yes, the agent could be ignorant, since the manager would have to do something clever anyway if it receives a message-too-big error. And for notifications, what should an agent do if the remote can't receive the message? Probably log the message, and increment some counter or something. Maybe send some other notification which informs about this? But a robust deployment would probably log anyway (if the notifs are one-way non-acked), so the agent doesn't really care that max-message size is too big, it would just not send the message. > A stream-based implementation is not mandatory. No, but again it would be nice if the protocol didn't rule this out (implicitly by having the max-message size parameter). > An implementation is allowed to have a maximum > message size (that it can receive), but there is no minimum value > any implementation has to support. (This is a political compromise > intended to confuse people when they try to assign blame for > a broken multi-vendor NETCONF system ;-) > > If you want successful interoperability, I suggest not ignoring > the max-message-size of the other peer. For notifications I agree (if max-message-size is added). But I don't see the value in having this for a reply. > >The only other comment I have is that it would be nice to know why > >noone seems to be interested in the xpath namespace issue. Don't you > >think it's a real problem? Or should implementations invent their own > >ways of handling this (if so, it could be mentioned in the doc). > > > > > > oops - I forgot that one. Of course we care about namespaces! Right? > I was planning on just following your suggestion in my implementation: > I guess the document needs to clarify this issue. Yes I think so, since I have seen one other suggestion (from Vincent). > From your email on 12/12: > > > d:top/d:users/d:user[name="fred"]/d:companyInfo/d:dept > > > Xpath really doesn't have any way of specifying namespaces? You can't define prefix to namespace uri mappings in the xpath expression itself, but you can check namespaces the way Vincent suggested (using the namespace-uri() function, which is kind of awkward). > Will the expression above break existing Xpath tools? I think many tools use some kind of resolve function for prefixes, or they take a prefix-to-namespace map as input. > Maybe most people just plan on getting namespace processing wrong :-) Maybe most implementations don't have xpath implemented yet... /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 28 15:02:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErhVS-00071P-Cf for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 15:02:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02977 for ; Wed, 28 Dec 2005 15:01:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErhOU-00039n-6g for netconf-data@psg.com; Wed, 28 Dec 2005 19:55:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErhOT-00039c-N5 for netconf@ops.ietf.org; Wed, 28 Dec 2005 19:55:29 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 28 Dec 2005 11:55:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,304,1131350400"; d="scan'208"; a="519504963:sNHT22469884" Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 11:55:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: pending edits for prot-10 Date: Wed, 28 Dec 2005 11:55:29 -0800 Message-ID: Thread-Topic: pending edits for prot-10 Thread-Index: AcYLvvZOwYLdLLILQMaPpr6z8ckeUwAKUUKA From: "Rob Enns" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 28 Dec 2005 19:55:28.0961 (UTC) FILETIME=[A70D1B10:01C60BE8] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > The following changes will be made in the next version: >=20 > 1) change the order of the and parameters > in the command >=20 > 2) add a maxLength=3D"4095" constraint to the = attribute >=20 > 3) provide XSD for standard content > (was removed from prot-10; needs to be fixed and replaced) Sounds good.=20 Also: o Update authors and acknowledgements (fix Andy's email, spell Sharon's name correctly). o Clarify that restrictions on locking a modified configuration apply to the candidate configuration. o Update IANA considerations. New NETCONF capabilities require IETF Standards Action. > The following change is agreed upon, but the replacement text > with all the details has not been written yet: >=20 > 4) optionally advertise your own max-message-size in the > capabilities exchange >=20 > Put this one on hold until we understand the implications? 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 Dec 28 15:13:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErhgB-000107-A2 for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 15:13:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04219 for ; Wed, 28 Dec 2005 15:12:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Erha2-0003sS-52 for netconf-data@psg.com; Wed, 28 Dec 2005 20:07:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Erha1-0003sH-L7 for netconf@ops.ietf.org; Wed, 28 Dec 2005 20:07:25 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 28 Dec 2005 12:07:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,304,1131350400"; d="scan'208"; a="519506739:sNHT22885204" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 12:07:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ok element Date: Wed, 28 Dec 2005 12:07:24 -0800 Message-ID: Thread-Topic: ok element Thread-Index: AcYFbOYuGLJIV/zjQvixaH/nbnkdpgGfVAFA From: "Rob Enns" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 28 Dec 2005 20:07:25.0144 (UTC) FILETIME=[51EDF580:01C60BEA] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Hi, >=20 > From prot-10, sec 4.4: >=20 > The element is sent in messages if no=20 > error occurred > during the processing of an request. >=20 > And the schema for this bit: >=20 > > > > > > use=3D"optional"/> > > > >=20 > I think there is a corner-case that needs to be documented. > What if the operation succeeds with warnings but no errors? >=20 > I suggest this edit to sec 4.4: s/no error/no errors or warnings/ Sounds fine. 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 Dec 28 20:23:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErmW7-0006Pu-UJ for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 20:23:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15957 for ; Wed, 28 Dec 2005 20:22:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErmND-000KY2-Mp for netconf-data@psg.com; Thu, 29 Dec 2005 01:14:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErmNC-000KXo-Fy for netconf@ops.ietf.org; Thu, 29 Dec 2005 01:14:31 +0000 Received: (qmail 1073 invoked from network); 29 Dec 2005 01:14:29 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by 10.49.34.112 with SMTP; 29 Dec 2005 01:14:29 -0000 Message-ID: <43B33873.5010201@andybierman.com> Date: Wed, 28 Dec 2005 17:14:27 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: "Netconf (E-mail)" Subject: Re: pending edits for prot-10 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Enns wrote: > >... > >> >> 4) optionally advertise your own max-message-size in the >> capabilities exchange >> >> >> >> > >Put this one on hold until we understand the implications? > > Yes -- I'm not sure everyone understands the 'hint' concept. If the agent sends me a hint that it will drop requests over 1 MB in size, then I can either take that into account and do the extra work in my manager to keep my requests to that agent under 1MB and get the job done -- or deal with the 'too-big' error and not get the job done. My choice. The optional part -- if I don't have a max-size for messages sent to me, or I don't want to bother letting anybody know what it is, then I don't advertise any max-message-size in the capabilities exchange. >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 Dec 28 20:37:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErmjH-0002Rc-AS for netconf-archive@megatron.ietf.org; Wed, 28 Dec 2005 20:37:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17640 for ; Wed, 28 Dec 2005 20:36:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ermfa-000LS8-NZ for netconf-data@psg.com; Thu, 29 Dec 2005 01:33:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ermfa-000LRw-57 for netconf@ops.ietf.org; Thu, 29 Dec 2005 01:33:30 +0000 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 28 Dec 2005 17:33:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,305,1131350400"; d="scan'208"; a="518387443:sNHT23472820" Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 17:33:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: errorInfoContent Date: Wed, 28 Dec 2005 17:33:28 -0800 Message-ID: Thread-Topic: errorInfoContent Thread-Index: AcYKOcwaVBZ/E0b5Ry+jidM1qvawxwBx2nZw From: "Rob Enns" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 29 Dec 2005 01:33:29.0606 (UTC) FILETIME=[DF41F260:01C60C17] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I'm not sure how to write the correct schema, but here's how=20 > it should work: >=20 > - the order and combinations of these elements should not=20 > be constrained > - the standard errors specify the minimum content, not the=20 > only content, > as this schema fragment might imply. > - all syntax is QName, except session-id is SessionId (unsignedInt) > - all maxOccurs should be "unbounded", except session-id is 1. > - although in general there are no required elements (so=20 > minOccurs=3D"0"), > there are specific standard errors that require=20 > specific elements to > be present in the error-info field. The schema does=20 > not reflect=20 > this, > but the normative text is clear on the details. I believe the following snippet meets NETCONF's requirements. Please take a look. To simplify the XSD a little, session-id must=20 appear first, if it appears. =20 There may well be a better way to write this bit of XSD, if some XSD black belts want to chime in here, please do. 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 Thu Dec 29 12:58:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es22W-00034u-Ee for netconf-archive@megatron.ietf.org; Thu, 29 Dec 2005 12:58:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24915 for ; Thu, 29 Dec 2005 12:57:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Es1ps-000PGN-Tj for netconf-data@psg.com; Thu, 29 Dec 2005 17:45:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Es1ps-000PG7-9o for netconf@ops.ietf.org; Thu, 29 Dec 2005 17:45:08 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 29 Dec 2005 09:45:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,310,1131350400"; d="scan'208"; a="519680589:sNHT23898120" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Dec 2005 09:45:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: errorInfoContent Date: Thu, 29 Dec 2005 09:45:06 -0800 Message-ID: Thread-Topic: errorInfoContent Thread-Index: AcYKOcwaVBZ/E0b5Ry+jidM1qvawxwBx2nZwACduhTA= From: "Rob Enns" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 29 Dec 2005 17:45:07.0402 (UTC) FILETIME=[9B73AAA0:01C60C9F] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I believe the following snippet meets NETCONF's requirements. > Please take a look. To simplify the XSD a little, session-id must=20 > appear first, if it appears. >=20 > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > > > > maxOccurs=3D"unbounded"/>=20 > > One small improvement. session-id only appears with lock errors, and shouldn't appear with any of the other error-info tags, so I moved it into a choice. =20 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: