From owner-netconf@ops.ietf.org Thu Jan 05 16:12:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EucPX-00082t-MV for netconf-archive@megatron.ietf.org; Thu, 05 Jan 2006 16:12: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 QAA17889 for ; Thu, 5 Jan 2006 16:11:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Euc5A-000Lha-My for netconf-data@psg.com; Thu, 05 Jan 2006 20:51:36 +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 1Euc5A-000LhK-2X for netconf@ops.ietf.org; Thu, 05 Jan 2006 20:51:36 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Euc3e-0007f6-DG; Thu, 05 Jan 2006 15: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-beep-08.txt Message-Id: Date: Thu, 05 Jan 2006 15: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 : Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) Author(s) : E. Lear, K. Crozier Filename : draft-ietf-netconf-beep-08.txt Pages : 14 Date : 2006-1-5 This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-08.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-beep-08.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-beep-08.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: <2006-1-5154108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-beep-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-beep-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-5154108.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 Mon Jan 09 11:44:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew08E-0005W5-2K for netconf-archive@megatron.ietf.org; Mon, 09 Jan 2006 11:44: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 LAA00440 for ; Mon, 9 Jan 2006 11:43:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Evzue-000Lnm-Te for netconf-data@psg.com; Mon, 09 Jan 2006 16:30:28 +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.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Evzub-000LnZ-G3 for netconf@ops.ietf.org; Mon, 09 Jan 2006 16:30:25 +0000 Received: (qmail 27670 invoked from network); 9 Jan 2006 16:30:24 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 9 Jan 2006 16:30:24 -0000 Message-ID: <43C28FA3.6020809@andybierman.com> Date: Mon, 09 Jan 2006 08:30: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: "Joel M. Halpern" CC: gen-art@ietf.org, bwijnen@lucent.com, Simon Leinen , netconf@ops.ietf.org, rpe@juniper.net Subject: Re: [Gen-art] LC Review Assignment: draft-ietf-netconf-prot-10 References: <6.2.1.2.0.20051217094417.0306cc58@mail.stevecrocker.com> In-Reply-To: <6.2.1.2.0.20051217094417.0306cc58@mail.stevecrocker.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 Joel M. Halpern wrote: > 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). Thanks Joel. These are really good comments. Now we will try to understand the edits. (Maybe I'll work with Rob offline on most of them, which might involve moving and/or clarifying some text.) There is one significant issue that jumps out at me. Does the :startup capability imply that the config can be the target of an operation? I think your comment is referring to this snippet from the text describing the target parameter: target: Configuration datastore being edited, such as or . Unfortunately, the set of operations is not consistent across all configurations. This reflects operational reality more than anything else. It should be made clear (in the #startup capability section) that if :startup is advertised: - and MAY be supported - , , and MUST be supported - MUST be supported (if :validate is also advertised) thanks, Andy > > 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 Wed Jan 11 08:39:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwgCd-0004pP-3W for netconf-archive@megatron.ietf.org; Wed, 11 Jan 2006 08: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 IAA12760 for ; Wed, 11 Jan 2006 08:38:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ewg2E-00025e-5g for netconf-data@psg.com; Wed, 11 Jan 2006 13:29:06 +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.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ewg2C-00025N-UK for netconf@ops.ietf.org; Wed, 11 Jan 2006 13:29:05 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0BDT0l22895 for ; Wed, 11 Jan 2006 08:29:00 -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: Netconf Event Notifications Draft Date: Wed, 11 Jan 2006 08:28:53 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40664D541@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf Event Notifications Draft Thread-Index: AcYWsveH9CKdTX7cQ/SOvLvcTjSuKA== From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi We submitted the internet draft for the Netconf Notification work a couple days ago, but for some reason it hasn't come out yet. While we wait, it can be found here =09 http://standards.nortel.com/netconf/docs/netconfEvent/draft-ietf-netconf -notification-00.txt Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jan 11 19:07:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewq0D-0008Uj-8l for netconf-archive@megatron.ietf.org; Wed, 11 Jan 2006 19:07: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 TAA28571 for ; Wed, 11 Jan 2006 19:06:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ewpj9-0009wX-L4 for netconf-data@psg.com; Wed, 11 Jan 2006 23:50:03 +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 1Ewpj8-0009vr-KX for netconf@ops.ietf.org; Wed, 11 Jan 2006 23:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ewpj7-0000Co-Dt; Wed, 11 Jan 2006 18: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-notification-00.txt Message-Id: Date: Wed, 11 Jan 2006 18: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 : NETCONF Event Notifications Author(s) : S. Chisholm, et al. Filename : draft-ietf-netconf-notification-00.txt Pages : 52 Date : 2006-1-11 This memo defines a framework for sending asynchronous messages, or event notifications in NETCONF. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to application protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-notification-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-notification-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2006-1-11162359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-notification-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-notification-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-11162359.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 Jan 12 05:20:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwzYs-0008H2-F2 for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 05:20: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 FAA07455 for ; Thu, 12 Jan 2006 05:18:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwzQM-000Gof-CB for netconf-data@psg.com; Thu, 12 Jan 2006 10:11: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=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 1EwzQL-000GoQ-8y for netconf@ops.ietf.org; Thu, 12 Jan 2006 10:11:17 +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 70579355 for netconf@ops.ietf.org; Thu, 12 Jan 2006 11:11:15 +0100 Date: Thu, 12 Jan 2006 11:11:09 +0100 (CET) Message-Id: <20060112.111109.39170812.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: error-path 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, error-path is really useful for troubleshooting. But it is unclear what the root of the absolute xpath expression is supposed to be. In our implementation, we currently generate error-path only for application errors, and generate an xpath expression with root in the datamodel, e.g. /srv:servers/srv:server foo But IF error-path is used for rpc/protocol errors (we don't do that), the root will have to be the protocol root: /rpc/get-config foo So the question is first if error-path should be allowed for rpc/protocol error-types? If so, should the root be different depending on error-type? If it's always the same (top-level), my first example would be /rpc/edit-config/config/srv:servers/srv:server /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 Jan 12 09:19:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3IL-0002Iy-DP for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 09:19: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 JAA20344 for ; Thu, 12 Jan 2006 09:17:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex37G-0004EV-DU for netconf-data@psg.com; Thu, 12 Jan 2006 14:07: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=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 1Ex37F-0004EB-Ah for netconf@ops.ietf.org; Thu, 12 Jan 2006 14:07:49 +0000 Received: (qmail 12445 invoked from network); 12 Jan 2006 14:07:48 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 12 Jan 2006 14:07:48 -0000 Message-ID: <43C662F2.6030105@andybierman.com> Date: Thu, 12 Jan 2006 06:08:50 -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: error-path References: <20060112.111109.39170812.mbj@tail-f.com> In-Reply-To: <20060112.111109.39170812.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >Hi, > >error-path is really useful for troubleshooting. But it is unclear >what the root of the absolute xpath expression is supposed to be. In >our implementation, we currently generate error-path only for >application errors, and generate an xpath expression with root in the >datamodel, e.g. > > > /srv:servers/srv:server > > > foo > > >But IF error-path is used for rpc/protocol errors (we don't do that), the root >will have to be the protocol root: > > > /rpc/get-config > > > foo > > > >So the question is first if error-path should be allowed for >rpc/protocol error-types? If so, should the root be different >depending on error-type? If it's always the same (top-level), my >first example would be > > > /rpc/edit-config/config/srv:servers/srv:server > > > I think this was our intent -- that the error-path would be from the 'rpc' root so it is always unambiguous. That is the whole point of this parameter. If the QName in is ambiguous (because it can occur at multiple levels) then use error-path also. Shouldn't the correct error-path in your example be: /rpc/edit-config/config/srv:servers/srv:server/srv:foo It needs to indicate the same node as . Andy > > >/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 Thu Jan 12 10:08:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex43y-0006Do-LY for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 10:08: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 KAA23422 for ; Thu, 12 Jan 2006 10:07:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex3uD-0006l0-Ct for netconf-data@psg.com; Thu, 12 Jan 2006 14:58: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 [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex3uC-0006kp-Ll for netconf@ops.ietf.org; Thu, 12 Jan 2006 14:58:24 +0000 Received: (qmail 7510 invoked from network); 12 Jan 2006 14:58:23 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 12 Jan 2006 14:58:23 -0000 Message-ID: <43C66ECD.4020603@andybierman.com> Date: Thu, 12 Jan 2006 06:59: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: "Netconf (E-mail)" Subject: Notification architecture 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, IMO, the architectural layering defined in the Notifications draft is broken. Currently, a notification is modeled as an operation -- as a child of the node in the PDU encoding. The whole notion of a one-way remote procedure call instead of an event notification seems convoluted to me. A notification is not a 'void' procedure call (i.e., just a function with no return value). It has temporal characteristics. That's why it has a timestamp and an RPC doesn't. needs to be a top-level element. This proposed layering creates several problems: - Access control configuration is more complicated. It is desirable to give separate access to users for notifications and real RPCs like . Nesting these elements forces more complex access control rules to be configured to accomplish this feature. - Notifications cannot be channelized in the BEEP transport unless is independent of . Obviously we want to take advantage of this feature in BEEP for asynch notifications. That's been our design goal from day 1. - Statistics for RPCs will be confusing It is desirable for the stats for RPCs to be separate from the stats for notifications, e.g. ncInRpcs == ncOutNoErrs + ncOutErrs[ncErrorType]; (for all ncErrorType) - Dual-role entities will be receiving as a real RPC and as a notification. This complicates the code path. Current implementations can set up internal structures and glean info from the 'rpc' node that is required for all real RPCs. As proposed, an implementation would have to either look ahead or undo and restart, because the internal code path for notification processing is totally different than for a real RPC (no error response handling for starters). Draft Proposed Layering: Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ My Proposed Layering Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ | | Operations | | +-------------+ \ | \ +-------------+ +--------------+ | RPC | | Notification | +-------------+ +--------------+ | / +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ There is no operation layer in a notification. There is only transport, notification header, and content. 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 Jan 12 10:47:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4fT-0007wO-3K for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 10:47: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 KAA25987 for ; Thu, 12 Jan 2006 10:45:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex4Sh-0008W7-EE for netconf-data@psg.com; Thu, 12 Jan 2006 15:34:03 +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 1Ex4Sg-0008Vo-5r for netconf@ops.ietf.org; Thu, 12 Jan 2006 15:34:02 +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 k0CFUKQ04628 for ; Thu, 12 Jan 2006 10:30:20 -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: Notification architecture Date: Thu, 12 Jan 2006 10:33:54 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4066B9EDA@zcarhxm2.corp.nortel.com> Thread-Topic: Notification architecture Thread-Index: AcYXikqmyG5CCi9XTKWfzz/BN/i+kwAAD2Dw From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Couple points: 1. Notifications are not layered on the , but rather a new wrapper of which is at the same Netconf layer as but is different. Therefore there should be no issues surrounding statistics and I don't think the beep mapping is hindered by this wrapper. 2. I've had good success in using the existing Netconf layer model to help people understand the different bits of Netconf. Your proposed update solves one problem I had around the fact that drawn the wrong way, it would imply that ran over or something along those lines, but it now breaks the fact that there are layers. This concept gets somewhat lost. 3. There are advantages to systems who want to process both synchronous and asynchronous messages to be able to use the same method - process rpc - process message By having two different architectures for these messages, things diverge much more. 4. I don't understand the access control comment. 5. Layer compression for notifications limits future extensibility options. What happens if some mythical day in the future we want to add another type of asynchronous message, or want to do acknowledged events? How does that work? Right now, I could conceive of running over as one method to do acknowledged events, which becomes more difficult with what you are proposing. I don't want to optimize the architecture for things that are out of scope of this release and things which we may never ever get to, but I think in general we should give some consideration to the implications on extensibility that this compression might have. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, January 12, 2006 9:59 AM To: Netconf (E-mail) Subject: Notification architecture Hi, IMO, the architectural layering defined in the Notifications draft is broken. Currently, a notification is modeled as an operation -- as a child of the node in the PDU encoding. The whole notion of a one-way remote procedure call instead of an event notification seems convoluted to me. A notification is not a 'void' procedure call (i.e., just a function with no return value). It has temporal characteristics. That's why it has a timestamp and an RPC doesn't. needs to be a top-level element. This proposed layering creates several problems: - Access control configuration is more complicated. It is desirable to give separate access to users for notifications and real RPCs like . Nesting these elements forces more complex access control rules to be configured to accomplish this feature. - Notifications cannot be channelized in the BEEP transport unless is independent of . Obviously we want to take advantage of this feature in BEEP for asynch notifications. That's been our design goal from day 1. - Statistics for RPCs will be confusing It is desirable for the stats for RPCs to be separate from the stats for notifications, e.g. ncInRpcs =3D=3D ncOutNoErrs + ncOutErrs[ncErrorType]; (for all ncErrorType) - Dual-role entities will be receiving as a real RPC and as a notification. This complicates the code path. Current implementations can set up internal structures and glean info from the 'rpc' node that is required for all real RPCs. As proposed, an implementation would have to either look ahead or undo and restart, because the internal code path for notification processing is totally different than for a real RPC (no error response handling for starters). Draft Proposed Layering: Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ My Proposed Layering Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ | | Operations | | +-------------+ \ | \ +-------------+ +--------------+ | RPC | | Notification | +-------------+ +--------------+ | / +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ There is no operation layer in a notification. There is only transport, notification header, and content. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 12 12:53:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex6dx-0004cB-9r for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 12:53: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 MAA03676 for ; Thu, 12 Jan 2006 12:52:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex6XV-000GTj-Th for netconf-data@psg.com; Thu, 12 Jan 2006 17:47: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 [212.247.154.33] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex6XT-000GTH-9Q for netconf@ops.ietf.org; Thu, 12 Jan 2006 17:47:07 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe02.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 84138073; Thu, 12 Jan 2006 18:47:02 +0100 Date: Thu, 12 Jan 2006 18:46:51 +0100 (CET) Message-Id: <20060112.184651.112825421.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: error-path From: Martin Bjorklund In-Reply-To: <43C662F2.6030105@andybierman.com> References: <20060112.111109.39170812.mbj@tail-f.com> <43C662F2.6030105@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: > >So the question is first if error-path should be allowed for > >rpc/protocol error-types? If so, should the root be different > >depending on error-type? If it's always the same (top-level), my > >first example would be > > > > > > /rpc/edit-config/config/srv:servers/srv:server > > > > > > I think this was our intent -- that the error-path would be from the > 'rpc' root Ok. > Shouldn't the correct error-path in your example be: > /rpc/edit-config/config/srv:servers/srv:server/srv:foo > > It needs to indicate the same node as . The text says "the node which is associated with the error". If the error is missing-element, my interpretation was that the error is in the parent. If the intention is that error-path MUST indicate the same node as bad-element, maybe this should be added to the text. /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 Jan 12 14:31:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex8As-0000yK-75 for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 14:31: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 OAA11781 for ; Thu, 12 Jan 2006 14:30:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex7x3-000LiT-Sz for netconf-data@psg.com; Thu, 12 Jan 2006 19:17:37 +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.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex7x2-000LiE-T1 for netconf@ops.ietf.org; Thu, 12 Jan 2006 19:17:37 +0000 Received: (qmail 18044 invoked from network); 12 Jan 2006 18:57:03 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 12 Jan 2006 18:57:03 -0000 Message-ID: <43C6A67A.8040408@andybierman.com> Date: Thu, 12 Jan 2006 10:56: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: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: error-path References: <20060112.111109.39170812.mbj@tail-f.com> <43C662F2.6030105@andybierman.com> <20060112.184651.112825421.mbj@tail-f.com> In-Reply-To: <20060112.184651.112825421.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: > > >>Martin Bjorklund wrote: >> >> >>>So the question is first if error-path should be allowed for >>>rpc/protocol error-types? If so, should the root be different >>>depending on error-type? If it's always the same (top-level), my >>>first example would be >>> >>> >>> /rpc/edit-config/config/srv:servers/srv:server >>> >>> >>> >>> >>I think this was our intent -- that the error-path would be from the >>'rpc' root >> >> > >Ok. > > > > >>Shouldn't the correct error-path in your example be: >> /rpc/edit-config/config/srv:servers/srv:server/srv:foo >> >>It needs to indicate the same node as . >> >> > >The text says "the node which is associated with the error". If the >error is missing-element, my interpretation was that the error is in >the parent. > >If the intention is that error-path MUST indicate the same node as >bad-element, maybe this should be added to the text. > > > > Actually, in this case, you should be using , not , and should point to 'foo', which is the missing element. We need to stop adding tiny little details to the draft. IMO, we don't need to change anything here. NOTE WELL: Implementation guidelines and errata will be collected and published separately (online) from now on. The IESG wants the final document versions now. Pencils down. Pass your papers to the front of the class ;-) >/martin > > Andy >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 12 15:03:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex8fA-0001Mp-VU for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 15:03: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 PAA14121 for ; Thu, 12 Jan 2006 15:01:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex8Wi-000NlB-0b for netconf-data@psg.com; Thu, 12 Jan 2006 19:54:28 +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 1Ex8Wg-000Nkx-Pi for netconf@ops.ietf.org; Thu, 12 Jan 2006 19:54:27 +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 71073825; Thu, 12 Jan 2006 20:54:24 +0100 Date: Thu, 12 Jan 2006 20:54:17 +0100 (CET) Message-Id: <20060112.205417.93408079.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: error-path From: Martin Bjorklund In-Reply-To: <43C6A67A.8040408@andybierman.com> References: <43C662F2.6030105@andybierman.com> <20060112.184651.112825421.mbj@tail-f.com> <43C6A67A.8040408@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: > >>Shouldn't the correct error-path in your example be: > >> /rpc/edit-config/config/srv:servers/srv:server/srv:foo > >> > >>It needs to indicate the same node as . > >> > >The text says "the node which is associated with the error". If the > >error is missing-element, my interpretation was that the error is in > >the parent. > > > >If the intention is that error-path MUST indicate the same node as > >bad-element, maybe this should be added to the text. > > > > > Actually, in this case, you should be using , > not , The element is in : /rpc/edit-config/config/srv:servers/srv:server foo There is no element . The is 'missing-element' in this case. > and should point to 'foo', > which is the missing element. Ok. > We need to stop adding tiny little details to the draft. > IMO, we don't need to change anything here. Ok. /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 Jan 12 16:11:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9jT-0005RR-O2 for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 16:11: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 QAA22503 for ; Thu, 12 Jan 2006 16:10:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ex9cl-0002Lq-4j for netconf-data@psg.com; Thu, 12 Jan 2006 21:04: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,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 1Ex9ch-0002LO-9i for netconf@ops.ietf.org; Thu, 12 Jan 2006 21:04:43 +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 k0CL11Q02208 for ; Thu, 12 Jan 2006 16:01:01 -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: Q: No max/ minMax length of anything? Date: Thu, 12 Jan 2006 16:04:37 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4066BA46D@zcarhxm2.corp.nortel.com> Thread-Topic: Q: No max/ minMax length of anything? Thread-Index: AcYXu8w2PxEFLrJSQDyaljBfEVkWJg== From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I'm looking to do some boundary testing against Netconf and it seems there isn't any guidance on the length of anything. Is this right? I know we have discussed this in terms of total message length, but is it also fair to say that the url one plugs into xmlns can be as long as you like? Other data is what you feel like implementing as well? While I agree with the principle of not constraining the implementations, I have suddenly realized it means more work for me with this particular task. If people have thoughts on what would be considered 'best practice' for this, I'd love to hear. Thanks, Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 12 17:00:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExAUT-0006xY-QM for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 17:00: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 QAA29417 for ; Thu, 12 Jan 2006 16:58:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExAOz-0005Zx-Uv for netconf-data@psg.com; Thu, 12 Jan 2006 21:54:37 +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 1ExAOy-0005Zl-Vd for netconf@ops.ietf.org; Thu, 12 Jan 2006 21:54:37 +0000 Received: (qmail 15739 invoked from network); 12 Jan 2006 21:50:48 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 12 Jan 2006 21:50:48 -0000 Message-ID: <43C6CF2E.7040209@andybierman.com> Date: Thu, 12 Jan 2006 13:50:38 -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 (E-mail)" Subject: Re: Q: No max/ minMax length of anything? References: <713043CE8B8E1348AF3C546DBE02C1B4066BA46D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4066BA46D@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 > >I'm looking to do some boundary testing against Netconf and it seems >there isn't any guidance on the length of anything. Is this right? I >know we have discussed this in terms of total message length, but is it >also fair to say that the url one plugs into xmlns can be as long as you >like? Other data is what you feel like implementing as well? > >While I agree with the principle of not constraining the >implementations, I have suddenly realized it means more work for me with >this particular task. If people have thoughts on what would be >considered 'best practice' for this, I'd love to hear. > > > We decided (and nobody objected) that the message-id attribute is maxLength="4095". Other than that, all data types are constrained AFAIK. We don't control the URL limits. >Thanks, > >Sharon Chisholm >Nortel >Ottawa, Ontario >Canada > > > 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 Jan 12 23:13:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExGJV-0006RZ-EP for netconf-archive@megatron.ietf.org; Thu, 12 Jan 2006 23:13: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 XAA27246 for ; Thu, 12 Jan 2006 23:11:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExG8S-0003pF-QC for netconf-data@psg.com; Fri, 13 Jan 2006 04:01: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=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 1ExG8S-0003p3-1x for netconf@ops.ietf.org; Fri, 13 Jan 2006 04:01:56 +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 k0D423cU026454; Thu, 12 Jan 2006 20:02:03 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k0D40SSv004495; Thu, 12 Jan 2006 20:00:28 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k0D40R6v004492; Thu, 12 Jan 2006 20:00:27 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 12 Jan 2006 20:00:27 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Eliot Lear cc: netconf@ops.ietf.org Subject: Re: notification charter proposal In-Reply-To: <4384B78B.50909@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, Just to make sure that there is no possibility of lost notifications... Please correct me if I've got this incorrect. I do believe that you can loose the last "n" notifications that you have sent unless you do application level acks. In this case, the notification receiver should receive the notification, write it to stable storage, and then provide the app level ack. How many notifications can be lost depends on the implementation of the app and the stack. What do you think? Regards, /david t. perkins On Wed, 23 Nov 2005, Eliot Lear wrote: > Glenn Waters wrote: > > Ahh, the challenges of multiple transports with differing features. So, > > if we chose (b) then we don't *need* to do anything the protocol for > > BEEP transport but we *need* to include something in the protocol for > > SSH transport (and SOAP I just don't know). > > > > Of course Netconf is transport independent so if we chose (b) then we > > *must* include in acks in the proto which means the BEEP transport will > > have an extra ack. > > How about "The right tool for the right job?" For those who need this > sort of thing, use BEEP. > > Eliot > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 13 03:01:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExJs6-0002se-5m for netconf-archive@megatron.ietf.org; Fri, 13 Jan 2006 03:01: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 CAA10761 for ; Fri, 13 Jan 2006 02:59:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExJgs-000HeJ-Fv for netconf-data@psg.com; Fri, 13 Jan 2006 07:49:42 +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.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExJgr-000He8-Tn for netconf@ops.ietf.org; Fri, 13 Jan 2006 07:49:41 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 12 Jan 2006 23:49:41 -0800 X-IronPort-AV: i="3.99,362,1131350400"; d="scan'208"; a="391312576:sNHT31136396" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0D7nfQi002790; Thu, 12 Jan 2006 23:49:41 -0800 (PST) Received: from [212.254.247.3] (ams-clip-vpn-dhcp366.cisco.com [10.61.65.110]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0D7sp5P031206; Thu, 12 Jan 2006 23:54:51 -0800 Message-ID: <43C75B92.6000708@cisco.com> Date: Fri, 13 Jan 2006 08:49:38 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: "David T. Perkins" CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=186; t=1137138892; x=1137571092; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Fri,=2013=20Jan=202006=2008=3A49=3A38=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=crgSqQz75n9wSZ8Sk1uMV2RDNc3J/tP33N6Y0+7BMGXemlLQxBCMUESjtI8nNpKMj/yEMn6l SSJW4vkQ4sN64sq2cXrVYgiZM0TDqw5vMk2TUnVDplVWyrM3OZyo8AIhaeehp85GqeGBF4yrM0Z 4IFXyknhtbl9P4VgTuvqSW54= 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 It depends on how BEEP is treated. If BEEP is treated as a TCP then you're right. If BEEP can allow for some amount of application control (like "let me tell you when to ACK") then no. BEEP: neither fish nor fowl! A feature. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 13 03:33:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExKMz-0003j6-3q for netconf-archive@megatron.ietf.org; Fri, 13 Jan 2006 03:33: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 DAA12508 for ; Fri, 13 Jan 2006 03:31:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExKD8-000Jjx-3Z for netconf-data@psg.com; Fri, 13 Jan 2006 08:23: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.247.154.225] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExKD7-000Jjg-3b for netconf@ops.ietf.org; Fri, 13 Jan 2006 08:23:01 +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 80837498; Fri, 13 Jan 2006 09:22:59 +0100 Date: Fri, 13 Jan 2006 09:22:53 +0100 (CET) Message-Id: <20060113.092253.28799954.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Q: No max/ minMax length of anything? From: Martin Bjorklund In-Reply-To: <43C6CF2E.7040209@andybierman.com> References: <713043CE8B8E1348AF3C546DBE02C1B4066BA46D@zcarhxm2.corp.nortel.com> <43C6CF2E.7040209@andybierman.com> 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 Andy Bierman wrote: > Sharon Chisholm wrote: > > >hi > > > >I'm looking to do some boundary testing against Netconf and it seems > >there isn't any guidance on the length of anything. Is this right? I > >know we have discussed this in terms of total message length, but is it > >also fair to say that the url one plugs into xmlns can be as long as you > >like? Other data is what you feel like implementing as well? > > > >While I agree with the principle of not constraining the > >implementations, I have suddenly realized it means more work for me with > >this particular task. If people have thoughts on what would be > >considered 'best practice' for this, I'd love to hear. > > > > > > > > We decided (and nobody objected) that the message-id attribute is > maxLength="4095". > Other than that, all data types are constrained AFAIK. We don't control > the URL limits. There are a few which aren't constrained: confirm-timeout is a positiveInteger (no upper bound) (could e.g. have been unsignedInt) error-app-tag is a (unbounded) xs:string error-path is a (unbounded) xs:string error-message is a (unbounded) xs:string Then there is the rule that any attribute in the element must be copied to the . Apart from that there is normal XML-stuff; the url length you mentioned, the number of xmlns attributes, length of element and attribute names etc. (A clever implementation can handle these anyway). /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 Jan 13 08:39:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExP9T-0007RT-5A for netconf-archive@megatron.ietf.org; Fri, 13 Jan 2006 08:39: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 IAA05857 for ; Fri, 13 Jan 2006 08:38:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExOtO-000BUP-0q for netconf-data@psg.com; Fri, 13 Jan 2006 13:22: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExOtD-000BSk-3L for netconf@ops.ietf.org; Fri, 13 Jan 2006 13:22:47 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0DDMgH19057 for ; Fri, 13 Jan 2006 08:22:42 -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: Q: No max/ minMax length of anything? Date: Fri, 13 Jan 2006 08:21:40 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4066BA6FC@zcarhxm2.corp.nortel.com> Thread-Topic: Q: No max/ minMax length of anything? Thread-Index: AcYXwsoeoVCHrVPVS2GVO4ZlgAGz2QAgRTCA From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Thursday, January 12, 2006 4:51 PM To: Chisholm, Sharon [CAR:ZZ00:EXCH] Cc: Netconf (E-mail) Subject: Re: Q: No max/ minMax length of anything? hi We decided (and nobody objected) that the message-id attribute is=20 maxLength=3D"4095". Other than that, all data types are constrained AFAIK. We don't control the URL limits. Did we? It isn't in -10 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 Fri Jan 13 08:43:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPDG-0000er-IV for netconf-archive@megatron.ietf.org; Fri, 13 Jan 2006 08:43: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 IAA06095 for ; Fri, 13 Jan 2006 08:42:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExP2A-000C83-D1 for netconf-data@psg.com; Fri, 13 Jan 2006 13:32: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExP29-000C7o-HY for netconf@ops.ietf.org; Fri, 13 Jan 2006 13:32:01 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0DDVwu27084 for ; Fri, 13 Jan 2006 08:31:58 -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: Q: No max/ minMax length of anything? Date: Fri, 13 Jan 2006 08:31:52 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4066BA716@zcarhxm2.corp.nortel.com> Thread-Topic: Q: No max/ minMax length of anything? Thread-Index: AcYYGpdk6SXwR6w8QiSamohqKAb4jQAKqBQw From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > We decided (and nobody objected) that the message-id attribute is > maxLength=3D"4095". > Other than that, all data types are constrained AFAIK. We don't control=20 > the URL limits. There are a few which aren't constrained: confirm-timeout is a positiveInteger (no upper bound) (could e.g. have been unsignedInt) error-app-tag is a (unbounded) xs:string error-path is a (unbounded) xs:string error-message is a (unbounded) xs:string Then there is the rule that any attribute in the element must be copied to the . I think Andy meant to say that the other data types were *not* constrained? Apart from that there is normal XML-stuff; the url length you mentioned, the number of xmlns attributes, length of element and attribute names etc. (A clever implementation can handle these anyway). I could not find any constraints on these in normal XML sources. Are there? Could you point to source? Thanks, 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 Fri Jan 13 09:08:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPbo-0000WL-HE for netconf-archive@megatron.ietf.org; Fri, 13 Jan 2006 09:08: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 JAA08183 for ; Fri, 13 Jan 2006 09:07:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExPRg-000Dl9-HM for netconf-data@psg.com; Fri, 13 Jan 2006 13:58: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 [212.247.154.33] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExPRf-000Dkw-LB for netconf@ops.ietf.org; Fri, 13 Jan 2006 13:58:23 +0000 X-T2-Posting-ID: 04PsghMIRU4ox5/fumld2A== X-Cloudmark-Score: 0.000000 [] Received: from [213.100.166.180] (HELO localhost) by mailfe02.swip.net (CommuniGate Pro SMTP 5.0.2) with ESMTP id 85187850; Fri, 13 Jan 2006 14:58:21 +0100 Date: Fri, 13 Jan 2006 14:58:10 +0100 (CET) Message-Id: <20060113.145810.38695003.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: Q: No max/ minMax length of anything? From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4066BA716@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4066BA716@zcarhxm2.corp.nortel.com> 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 "Sharon Chisholm" wrote: > > Apart from that there is normal XML-stuff; the url length you mentioned, > the number of xmlns attributes, length of element and attribute names > etc. (A clever implementation can handle these anyway). > > > I could not find any constraints on these in normal XML sources. Are > there? Could you point to source? No, that's what I meant - there are no constraints on these, but it's not NETCONF-specific, it's XML. /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 Jan 13 14:44:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUq8-0004wq-5M for netconf-archive@megatron.ietf.org; Fri, 13 Jan 2006 14: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 OAA01749 for ; Fri, 13 Jan 2006 14:42:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExUeV-000A2r-C7 for netconf-data@psg.com; Fri, 13 Jan 2006 19:31:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExUeU-000A2d-PB for netconf@ops.ietf.org; Fri, 13 Jan 2006 19:31:58 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 13 Jan 2006 11:31:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,366,1131350400"; d="scan'208"; a="522550545:sNHT21398876" Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 11:31:57 -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: Q: No max/ minMax length of anything? Date: Fri, 13 Jan 2006 11:31:56 -0800 Message-ID: Thread-Topic: Q: No max/ minMax length of anything? Thread-Index: AcYXwsoeoVCHrVPVS2GVO4ZlgAGz2QAgRTCAAAz7eGA= From: "Rob Enns" To: "Sharon Chisholm" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 13 Jan 2006 19:31:57.0944 (UTC) FILETIME=[04A0FF80:01C61878] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > We decided (and nobody objected) that the message-id attribute is=20 > maxLength=3D"4095". > Other than that, all data types are constrained AFAIK. We=20 > don't control >=20 > the URL limits. > >=20 > Did we? It isn't in -10 >=20 > It will be in -11 (hey, NETCONF goes to 11!) 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 Jan 14 01:12:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exeeh-0006GK-JS for netconf-archive@megatron.ietf.org; Sat, 14 Jan 2006 01:12: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 BAA23736 for ; Sat, 14 Jan 2006 01:11:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExeMK-000Kqi-JQ for netconf-data@psg.com; Sat, 14 Jan 2006 05:53: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 [203.91.193.32] (helo=wip-ec-wd.wipro.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExeMI-000Kol-LM for netconf@ops.ietf.org; Sat, 14 Jan 2006 05:53:51 +0000 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id DE5C4208B5 for ; Sat, 14 Jan 2006 10:49:35 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 942CB211AA for ; Sat, 14 Jan 2006 10:29:03 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:36:39 +0530 Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jan 2006 01:47:53 +0530 Received: from wip-ectls-mx13.wipro.com ([203.91.193.31]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jan 2006 01:33:49 +0530 Received: from wip-ectls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35A2A220067; Sat, 14 Jan 2006 01:33:22 +0530 (IST) Received: from psg.com (psg.com [147.28.0.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wip-ectls-mx2.wipro.com (Postfix) with ESMTP id B07FB264251; Sat, 14 Jan 2006 01:14:03 +0530 (IST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExUeV-000A2r-C7 for netconf-data@psg.com; Fri, 13 Jan 2006 19:31:59 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExUeU-000A2d-PB for netconf@ops.ietf.org; Fri, 13 Jan 2006 19:31:58 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 13 Jan 2006 11:31:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,366,1131350400"; d="scan'208"; a="522550545:sNHT21398876" Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 11:31:57 -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: Q: No max/ minMax length of anything? Date: Fri, 13 Jan 2006 11:31:56 -0800 Message-ID: Thread-Topic: Q: No max/ minMax length of anything? Thread-Index: AcYXwsoeoVCHrVPVS2GVO4ZlgAGz2QAgRTCAAAz7eGA= From: "Rob Enns" To: "Sharon Chisholm" , "Netconf (E-mail)" X-OriginalArrivalTime: 13 Jan 2006 19:31:57.0944 (UTC) FILETIME=[04A0FF80:01C61878] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > We decided (and nobody objected) that the message-id attribute is=20 > maxLength=3D"4095". > Other than that, all data types are constrained AFAIK. We=20 > don't control >=20 > the URL limits. > >=20 > Did we? It isn't in -10 >=20 > It will be in -11 (hey, NETCONF goes to 11!) 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 Sun Jan 15 14:26:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyDWS-00050o-5f for netconf-archive@megatron.ietf.org; Sun, 15 Jan 2006 14:26: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 OAA09428 for ; Sun, 15 Jan 2006 14:25:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyB3P-000N4z-Um for netconf-data@psg.com; Sun, 15 Jan 2006 16:48: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 [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExFjX-00024x-2S for netconf@ops.ietf.org; Fri, 13 Jan 2006 03:36:11 +0000 Received: (qmail 20528 invoked from network); 12 Jan 2006 14:52:54 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr5.mgt.bos.netsol.com with SMTP; 12 Jan 2006 14:52:54 -0000 Message-ID: <43C66D84.7050609@andybierman.com> Date: Thu, 12 Jan 2006 06:53:56 -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: Notification architecture 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, IMO, the architectural layering defined in the Notifications draft is broken. Currently, a notification is modeled as an operation -- as a child of the node in the PDU encoding. The whole notion of a one-way remote procedure call instead of an event notification seems convoluted to me. A notification is not a 'void' procedure call (i.e., just a function with no return value). It has temporal characteristics. That's why it has a timestamp and an RPC doesn't. needs to be a top-level element. This proposed layering creates several problems: - Access control configuration is more complicated. It is desirable to give separate access to users for notifications and real RPCs like . Nesting these elements forces more complex access control rules to be configured to accomplish this feature. - Notifications cannot be channelized in the BEEP transport unless is independent of . Obviously we want to take advantage of this feature in BEEP for asynch notifications. That's been our design goal from day 1. - Statistics for RPCs will be confusing It is desirable for the stats for RPCs to be separate from the stats for notifications, e.g. ncInRpcs == ncOutNoErrs + ncOutErrs[ncErrorType]; (for all ncErrorType) - Dual-role entities will be receiving as a real RPC and as a notification. This complicates the code path. Current implementations can set up internal structures and glean info from the 'rpc' node that is required for all real RPCs. As proposed, an implementation would have to either look ahead or undo and restart, because the internal code path for notification processing is totally different than for a real RPC (no error response handling for starters). Draft Proposed Layering: Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ My Proposed Layering Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ | | Operations | | +-------------+ \ | \ +-------------+ +--------------+ | RPC | | Notification | +-------------+ +--------------+ | / +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ There is no operation layer in a notification. There is only transport, notification header, and content. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jan 15 15:14:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyEGP-00072B-30 for netconf-archive@megatron.ietf.org; Sun, 15 Jan 2006 15:14: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 PAA12146 for ; Sun, 15 Jan 2006 15:12:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyE8Q-000CqX-7o for netconf-data@psg.com; Sun, 15 Jan 2006 20:05:54 +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 1EyE8N-000CqI-CR for netconf@ops.ietf.org; Sun, 15 Jan 2006 20:05:51 +0000 Received: (qmail 24146 invoked from network); 15 Jan 2006 20:05:50 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 15 Jan 2006 20:05:50 -0000 Message-ID: <43CAAB1D.7000503@andybierman.com> Date: Sun, 15 Jan 2006 12:05: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: Rob Enns CC: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Q: No max/ minMax length of anything? 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: >> >>We decided (and nobody objected) that the message-id attribute is >>maxLength="4095". >>Other than that, all data types are constrained AFAIK. We >>don't control >> >>the URL limits. >> >> >>Did we? It isn't in -10 >> >> >> >> > >It will be in -11 (hey, NETCONF goes to 11!) > > > > > > > > > I think xs:string is minLength="0" and maxLength="unbounded" by default. (Can somebody confirm this?) Doesn't that mean that we need minLength="1" in some cases? Here is Martin's list: confirm-timeout is a positiveInteger (no upper bound) (could e.g. have been unsignedInt) error-app-tag is a (unbounded) xs:string error-path is a (unbounded) xs:string error-message is a (unbounded) xs:string I think allowing message-id to be zero-length is broken. I also think the 3 error-* strings should have a minLength="1" facet. I know this is a CLR, but IMO, I would rather these optional parameters not be present in this case. Operationally, I can't think of any value zero-length strings will add to the debugging process. I agree with Martin, and would like to change confirm-timeout to a simpleType (base="unsignedInt" minInclusive="1"). The positiveInteger base type is a string, not a number. This requires much more processing internally than unsignedInt. positiveInteger has no upper bound, but unsignedInt does (and 4 billion seconds is a long enough timeout). > >Rob > > 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 Tue Jan 17 17:38:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyzTZ-0007Vg-Iq for netconf-archive@megatron.ietf.org; Tue, 17 Jan 2006 17:38: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 RAA01420 for ; Tue, 17 Jan 2006 17:37:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyzM1-000BUy-Mt for netconf-data@psg.com; Tue, 17 Jan 2006 22:31:05 +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 1EyzM0-000BUm-KB for netconf@ops.ietf.org; Tue, 17 Jan 2006 22:31:04 +0000 Received: (qmail 15007 invoked from network); 17 Jan 2006 22:31:03 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 17 Jan 2006 22:31:03 -0000 Message-ID: <43CD7027.3070603@andybierman.com> Date: Tue, 17 Jan 2006 14:31:03 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brzozowski, John" CC: "Netconf (E-mail)" Subject: Re: NETCONF Archives References: <2271C950731A734680BA3E2978816F18039DA216@NJCHLEXCMB01.cable.comcast.com> In-Reply-To: <2271C950731A734680BA3E2978816F18039DA216@NJCHLEXCMB01.cable.comcast.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 Brzozowski, John wrote: >Andy, > >I cannot access the archives @ https://ops.ietf.org/lists/netconf. Can >you help me out? > > Yep -- that link is broken alright. Seen this error before, so I tried HTTP instead of HTTPS. This works: http://ops.ietf.org/lists/netconf >Thanks, > >John > > 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 Jan 18 14:38:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJ8v-0007Pb-M5 for netconf-archive@megatron.ietf.org; Wed, 18 Jan 2006 14:38: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 OAA16764 for ; Wed, 18 Jan 2006 14:37:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzJ1O-000E4q-1V for netconf-data@psg.com; Wed, 18 Jan 2006 19:31:06 +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.161] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzJ1N-000E4Y-10 for netconf@ops.ietf.org; Wed, 18 Jan 2006 19:31:05 +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 89297813 for netconf@ops.ietf.org; Wed, 18 Jan 2006 20:31:01 +0100 Date: Wed, 18 Jan 2006 20:30:53 +0100 (CET) Message-Id: <20060118.203053.59677763.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: kill-session schema 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, The parameter session-id to kill-session is defined as: Should this parameter really be optional? Since you're not allowed to your own session, this seems strange. /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 Jan 18 17:52:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMA4-0006st-Ki for netconf-archive@megatron.ietf.org; Wed, 18 Jan 2006 17:52: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 RAA18009 for ; Wed, 18 Jan 2006 17:50:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzM2N-000568-12 for netconf-data@psg.com; Wed, 18 Jan 2006 22:44: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=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 1EzM2K-00055t-Ch for netconf@ops.ietf.org; Wed, 18 Jan 2006 22:44:16 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 18 Jan 2006 14:44:11 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,382,1131350400"; d="scan'208"; a="523608123:sNHT23975176" Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 14:44:12 -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: Q: No max/ minMax length of anything? Date: Wed, 18 Jan 2006 14:44:12 -0800 Message-ID: Thread-Topic: Q: No max/ minMax length of anything? Thread-Index: AcYaDxzZL2lclxDhQNGBZQh05CCxRwCV03iA From: "Rob Enns" To: "Andy Bierman" Cc: "Sharon Chisholm" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 18 Jan 2006 22:44:12.0667 (UTC) FILETIME=[B3ECCCB0:01C61C80] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I think xs:string is minLength=3D"0" and maxLength=3D"unbounded"=20 > by default. > (Can somebody confirm this?) xs:string is unconstrained by default, which (I think) is the same thing as minLength=3D"0" and maxLength=3D"unbounded". > Doesn't that mean that we need minLength=3D"1" in some cases? >=20 > Here is Martin's list: >=20 > confirm-timeout is a positiveInteger (no upper bound) =20 > (could e.g. > have been unsignedInt) > error-app-tag is a (unbounded) xs:string > error-path is a (unbounded) xs:string > error-message is a (unbounded) xs:string >=20 > I think allowing message-id to be zero-length is broken. >=20 > I also think the 3 error-* strings should have a minLength=3D"1" = facet. > I know this is a CLR, but IMO, I would rather these optional parameters > not be present in this case. Operationally, I can't think of=20 > any value > zero-length strings will add to the debugging process. I don't see any use for a zero length one of these, but I agree this is a CLR and we should be firm on the introduction of CLRs. In this case I suggest we let these stand as xs:string's. > I agree with Martin, and would like to change confirm-timeout to > a simpleType (base=3D"unsignedInt" minInclusive=3D"1"). The=20 > positiveInteger > base type is a string, not a number. This requires much more=20 > processing > internally than unsignedInt. positiveInteger has no upper bound, > but unsignedInt does (and 4 billion seconds is a long enough timeout). Sounds like a good change, I'll update -11 with this change. 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 Jan 18 18:26:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMh2-0003M2-TB for netconf-archive@megatron.ietf.org; Wed, 18 Jan 2006 18:26: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 SAA20158 for ; Wed, 18 Jan 2006 18:24:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzMc1-00089V-IF for netconf-data@psg.com; Wed, 18 Jan 2006 23:21: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 [205.178.146.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzMc0-00089J-Cs for netconf@ops.ietf.org; Wed, 18 Jan 2006 23:21:08 +0000 Received: (qmail 3412 invoked from network); 18 Jan 2006 23:21:06 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 18 Jan 2006 23:21:06 -0000 Message-ID: <43CECD5F.4040403@andybierman.com> Date: Wed, 18 Jan 2006 15:21:03 -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: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Q: No max/ minMax length of anything? 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 think xs:string is minLength="0" and maxLength="unbounded" >>by default. >>(Can somebody confirm this?) >> >> > >xs:string is unconstrained by default, which (I think) is the >same thing as minLength="0" and maxLength="unbounded". > > > >>Doesn't that mean that we need minLength="1" in some cases? >> >>Here is Martin's list: >> >> confirm-timeout is a positiveInteger (no upper bound) >>(could e.g. >> have been unsignedInt) >> error-app-tag is a (unbounded) xs:string >> error-path is a (unbounded) xs:string >> error-message is a (unbounded) xs:string >> >>I think allowing message-id to be zero-length is broken. >> >>I also think the 3 error-* strings should have a minLength="1" facet. >>I know this is a CLR, but IMO, I would rather these optional >> >> >parameters > > >>not be present in this case. Operationally, I can't think of >>any value >>zero-length strings will add to the debugging process. >> >> > >I don't see any use for a zero length one of these, but I agree this >is a CLR and we should be firm on the introduction of CLRs. In this >case I suggest we let these stand as xs:string's. > > Okay - This will be interesting. IMO, the law of unintended consequences is going to bite us later, but we will see... Personally, I would rather have a CLR that is consistently supported across all devices than a unbounded type that few implementations support in the same way. > > >>I agree with Martin, and would like to change confirm-timeout to >>a simpleType (base="unsignedInt" minInclusive="1"). The >>positiveInteger >>base type is a string, not a number. This requires much more >>processing >>internally than unsignedInt. positiveInteger has no upper bound, >>but unsignedInt does (and 4 billion seconds is a long enough timeout). >> >> > >Sounds like a good change, I'll update -11 with this change. > >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 Jan 18 22:40:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQfN-0005fa-Ja for netconf-archive@megatron.ietf.org; Wed, 18 Jan 2006 22:40: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 WAA13070 for ; Wed, 18 Jan 2006 22:39:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzQWx-0002YN-Vp for netconf-data@psg.com; Thu, 19 Jan 2006 03:32:11 +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_ABUSE,DNS_FROM_RFC_WHOIS,MSGID_FROM_MTA_HEADER,USERPASS autolearn=no version=3.1.0 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzQWw-0002Y7-6a for netconf@ops.ietf.org; Thu, 19 Jan 2006 03:32:10 +0000 Received: (eyou send program); Thu, 19 Jan 2006 11:03:25 +0800 Message-ID: <337686605.14726@njupt.edu.cn> Received: from 10.10.136.120 by em.njupt.edu.cn with HTTP; Thu, 19 Jan 2006 11:03:25 +0800 X-WebMAIL-MUA: [10.10.136.120] From: "=?gb2312?B?zfW6sQ==?=" To: netconf@ops.ietf.org Date: Thu, 19 Jan 2006 11:03:25 +0800 Reply-To: "=?gb2312?B?zfW6sQ==?=" X-Priority: 3 Subject: every message only can have one operation? Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk dear all: how many operations can be assembled in the same message? I read the netconf propose, and I find every message have only one operation in itself. can I generate such a message: //the 1th operation get // the 2th operation copy https://user@example.com:passphrase/cfg/new.txt -- to unsubscribe send a message to netconf-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 Jan 18 23:37:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzRY3-0001Jw-Kl for netconf-archive@megatron.ietf.org; Wed, 18 Jan 2006 23:37:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17159 for ; Wed, 18 Jan 2006 23:35:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzRTb-0007Pl-7m for netconf-data@psg.com; Thu, 19 Jan 2006 04:32:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,USERPASS autolearn=no 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 1EzRTa-0007PC-D2 for netconf@ops.ietf.org; Thu, 19 Jan 2006 04:32:46 +0000 Received: (qmail 584 invoked from network); 19 Jan 2006 04:32:45 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 19 Jan 2006 04:32:45 -0000 Message-ID: <43CF166D.3030601@andybierman.com> Date: Wed, 18 Jan 2006 20:32:45 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?546L572V?= CC: netconf@ops.ietf.org Subject: Re: every message only can have one operation? References: <337686605.14726@njupt.edu.cn> In-Reply-To: <337686605.14726@njupt.edu.cn> Content-Type: text/plain; charset=UTF-8; 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 XAA17159 =E7=8E=8B=E7=BD=95 wrote: >dear all: > > how many operations can be assembled in the same message? I read the = netconf >propose, and I find every message have only one operation in itself. > > can I generate such a message: > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > //the 1th operation get > > > > > // the 2th operation copy > > https://user@example.com:passphrase/cfg/new.txt > > > > > > > > =20 > no -- only 1 RPC method per request is allowed 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 Jan 18 23:43:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzRde-0002ds-Vo for netconf-archive@megatron.ietf.org; Wed, 18 Jan 2006 23:43:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17455 for ; Wed, 18 Jan 2006 23:41:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzRZW-0007x4-Q7 for netconf-data@psg.com; Thu, 19 Jan 2006 04:38:54 +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 1EzRZW-0007wr-2D for netconf@ops.ietf.org; Thu, 19 Jan 2006 04:38:54 +0000 Received: (qmail 3428 invoked from network); 19 Jan 2006 04:38:53 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 19 Jan 2006 04:38:53 -0000 Message-ID: <43CF17DC.8090005@andybierman.com> Date: Wed, 18 Jan 2006 20:38: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: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: kill-session schema References: <20060118.203053.59677763.mbj@tail-f.com> In-Reply-To: <20060118.203053.59677763.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >Hi, > >The parameter session-id to kill-session is defined as: > > type="SessionId" minOccurs="0"/> > >Should this parameter really be optional? Since you're not allowed to >your own session, this seems strange. > > This is a bug in the schema. It should be minOccurs="1". The normative text in sec. 7.9 does not say this is optional, so that means it is mandatory. > >/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 Thu Jan 19 03:23:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzV4t-0004Oy-Hl for netconf-archive@megatron.ietf.org; Thu, 19 Jan 2006 03:23: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 DAA29993 for ; Thu, 19 Jan 2006 03:22:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzUvR-000NhV-MV for netconf-data@psg.com; Thu, 19 Jan 2006 08:13: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=BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [64.233.162.205] (helo=zproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzUvR-000NhI-0D for netconf@ops.ietf.org; Thu, 19 Jan 2006 08:13:45 +0000 Received: by zproxy.gmail.com with SMTP id o37so166077nzf for ; Thu, 19 Jan 2006 00:13:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=T/eawY7jUD8P7pbkOT7sZa/ME7LaKKGPgXeajUCWPhKG5IBTmc6ywVGszbVeaioYI9LugqnagMPIRmt0EkXSknhxRw7gOhDLbLIRRmJHCfylqGJW2MZYtKeo/EfbjCGd86ZparieFUEHdZh/Yfw+cj7snQEKikSCNfTQycsUXQE= Received: by 10.65.230.13 with SMTP id h13mr121684qbr; Thu, 19 Jan 2006 00:13:44 -0800 (PST) Received: by 10.64.196.9 with HTTP; Thu, 19 Jan 2006 00:13:44 -0800 (PST) Message-ID: Date: Thu, 19 Jan 2006 09:13:44 +0100 From: "Jayaprakash Kulkarni (Wipro)" To: netconf@ops.ietf.org Subject: ok element definition in xsd MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi In the netconf xsd, The rpcReplyType is defined as : There is no type definition for the ok element. Is this correct? regards Jayaprakash -- to unsubscribe send a message to netconf-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 Jan 19 10:10:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbR2-0005vN-Ot for netconf-archive@megatron.ietf.org; Thu, 19 Jan 2006 10:10: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 KAA29784 for ; Thu, 19 Jan 2006 10:09:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzbIc-0002ut-Go for netconf-data@psg.com; Thu, 19 Jan 2006 15:02:06 +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.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzbIb-0002ud-D2 for netconf@ops.ietf.org; Thu, 19 Jan 2006 15:02:05 +0000 Received: (qmail 23719 invoked from network); 19 Jan 2006 15:02:04 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 19 Jan 2006 15:02:04 -0000 Message-ID: <43CFA9EC.10400@andybierman.com> Date: Thu, 19 Jan 2006 07:02:04 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?546L572V?= CC: "Netconf (E-mail)" Subject: Re: every message only can have one operation? References: <337711793.25519@njupt.edu.cn> In-Reply-To: <337711793.25519@njupt.edu.cn> Content-Type: text/plain; charset=UTF-8; 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 KAA29784 =E7=8E=8B=E7=BD=95 wrote: > thanks Andy, but why can't we put more methods in a rpc message? >it can reduce the Network management messages on Internet, can't it? > =20 > (I cc;ed the WG because this issue keeps coming up) It adds a lot of complexity to the protocol to do this. Since configuration is a relatively rare activity, it doesn't really save much bandwidth anyway. We aren't very worried about congestion due to network configuration PDUs. (In your example, you saved about 1% -- that's all. Once you add some overhead to differentiate the multiple replies, you give that savings back, and then some.) > =20 > >>no -- only 1 RPC method per request is allowed >> >>Andy >> >> =20 >> > > =20 > 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 Jan 19 11:31:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcgw-0004Vd-7s for netconf-archive@megatron.ietf.org; Thu, 19 Jan 2006 11:31: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 LAA04883 for ; Thu, 19 Jan 2006 11:29:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzcbJ-0009hT-KE for netconf-data@psg.com; Thu, 19 Jan 2006 16:25: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.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzcbH-0009hD-Ta for netconf@ops.ietf.org; Thu, 19 Jan 2006 16:25:28 +0000 Received: (qmail 3338 invoked from network); 19 Jan 2006 16:06:12 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 19 Jan 2006 16:06:12 -0000 Message-ID: <43CFB8F3.3000204@andybierman.com> Date: Thu, 19 Jan 2006 08:06:11 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?546L572V?= CC: "Netconf (E-mail)" Subject: Re: every message only can have one operation? References: <337711793.25519@njupt.edu.cn> <43CFA9EC.10400@andybierman.com> In-Reply-To: <43CFA9EC.10400@andybierman.com> Content-Type: text/plain; charset=UTF-8; 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 LAA04883 Andy Bierman wrote: > =E7=8E=8B=E7=BD=95 wrote: > >> thanks Andy, but why can't we put more methods in a rpc message? >> it can reduce the Network management messages on Internet, can't it? >> =20 >> > (I cc;ed the WG because this issue keeps coming up) > > It adds a lot of complexity to the protocol to do this. > Since configuration is a relatively rare activity, it doesn't really > save much bandwidth anyway. We aren't very worried > about congestion due to network configuration PDUs. > > (In your example, you saved about 1% -- that's all. > Once you add some overhead to differentiate the multiple replies, > you give that savings back, and then some.) > BTW, this is obviously a solved problem in other formats. The correct way to do what you want could be added as a vendor extension. For example: = =20 .... .... .... .... We want to keep the protocol simple to start out. Less complexity, less code, more chance vendors will get it right. Andy >> =20 >> >>> no -- only 1 RPC method per request is allowed >>> >>> Andy >>> >>> =20 >> >> >> =20 >> > > Andy > > > > --=20 > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 20 10:25:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezy8N-0008Lv-Ip for netconf-archive@megatron.ietf.org; Fri, 20 Jan 2006 10:25: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 KAA21243 for ; Fri, 20 Jan 2006 10:23:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ezy0D-000LZl-2v for netconf-data@psg.com; Fri, 20 Jan 2006 15:16:37 +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 1Ezy0C-000LZV-4T for netconf@ops.ietf.org; Fri, 20 Jan 2006 15:16:36 +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 78499759 for netconf@ops.ietf.org; Fri, 20 Jan 2006 16:16:33 +0100 Date: Fri, 20 Jan 2006 16:16:27 +0100 (CET) Message-Id: <20060120.161627.116376498.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: base capability 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.1, "urn:ietf:params:netconf:base:1.0" is referred to as "the base NETCONF capability", and it's sent in the element. But then section 8. says that a capability has the following format: urn:ietf:params:netconf:capability:{name}:1.0 Shouldn't base have the :capability: part: urn:ietf:params:netconf:capability:base:1.0 In either case, shouldn't base be listed in section 10.3? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 24 13:31:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Sx5-00053n-28 for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 13:31: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 NAA07587 for ; Tue, 24 Jan 2006 13:30:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1SoY-000C0f-3Z for netconf-data@psg.com; Tue, 24 Jan 2006 18:22: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 autolearn=ham version=3.1.0 Received: from [205.178.146.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1SoW-000C0F-5H for netconf@ops.ietf.org; Tue, 24 Jan 2006 18:22:44 +0000 Received: (qmail 15754 invoked from network); 24 Jan 2006 18:09:46 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 24 Jan 2006 18:09:46 -0000 Message-ID: <43D66D69.1090002@andybierman.com> Date: Tue, 24 Jan 2006 10:09:45 -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 (E-mail)" Subject: Re: Notification architecture References: <713043CE8B8E1348AF3C546DBE02C1B4066B9EDA@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4066B9EDA@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: > >1. Notifications are not layered on the , but rather a new wrapper >of which is at the same Netconf layer as but is >different. Therefore there should be no issues surrounding statistics >and I don't think the beep mapping is hindered by this wrapper. > > > I don't like it at all. The document is not very clear at all. There are many details that are buried in hard-to-read XSD and not explained in any human-readable text. >2. I've had good success in using the existing Netconf layer model to >help people understand the different bits of Netconf. Your proposed >update solves one problem I had around the fact that drawn the wrong >way, it would imply that ran over or something >along those lines, but it now breaks the fact that there are layers. >This concept gets somewhat lost. > > . IMO, it is way simpler to explain the notification path as separate from the operations path. They are separate in CLI and SNMP. I just don't see a notification as a one way remote procedure call. It is convoluted. BTW, we decided awhile back that we didn't want 'void' RPCs. That is why we have the element. >3. There are advantages to systems who want to process both synchronous >and asynchronous messages to be able to use the same method > - process rpc > - process message >By having two different architectures for these messages, things diverge >much more. > > Really? What are they? This looks like a broken architecture to me. Requests which return responses and/or status are not handled the same as async. notifications -- which is what we are chartered to add to netconf. >4. I don't understand the access control comment. > > > It was based on layering. It wasn't clear from the document that is under . (Why the extra layer -- oh yeah -- we may add other types of 1-way rpcs in the future :-) >5. Layer compression for notifications limits future extensibility >options. What happens if some mythical day in the future we want to add >another type of asynchronous message, or want to do acknowledged events? > > Like what? We can deal with that problem if it ever comes up. Extending XML is pretty easy. >How does that work? Right now, I could conceive of running > over as one method to do acknowledged >events, which becomes more difficult with what you are proposing. I >don't want to optimize the architecture for things that are out of scope >of this release and things which we may never ever get to, but I think >in general we should give some consideration to the implications on >extensibility that this compression might have. > > Nobody else seems to want to do this. (Have the manager listen for ?) Why do you want to make this so complicated? A notification, over RPC, with an operations layer? What is it used for? I don't get it. We should be solving current operational problems. We have both the syslog and SNMP notification models in use today. We should build on that, not reinvent it. >Sharon > > Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Thursday, January 12, 2006 9:59 AM >To: Netconf (E-mail) >Subject: Notification architecture > > >Hi, > > >IMO, the architectural layering defined in the Notifications draft is >broken. Currently, a notification is modeled as an operation -- as a >child of the node in the PDU encoding. The whole notion of a >one-way remote procedure call instead of an event notification seems >convoluted to me. A notification is not a 'void' procedure call (i.e., >just a function with no return value). It has temporal characteristics. >That's why it has a timestamp and an RPC doesn't. > > needs to be a top-level element. > >This proposed layering creates several problems: > > - Access control configuration is more complicated. It is > desirable to give separate access to users for notifications > and real RPCs like . Nesting these elements > forces more complex access control rules to be configured > to accomplish this feature. > - Notifications cannot be channelized in the BEEP transport > unless is independent of . Obviously > we want to take advantage of this feature in BEEP for asynch > notifications. That's been our design goal from day 1. > - Statistics for RPCs will be confusing > It is desirable for the stats for RPCs to be separate from > the stats for notifications, e.g. > ncInRpcs == ncOutNoErrs + ncOutErrs[ncErrorType]; > (for all ncErrorType) > - Dual-role entities will be receiving as a real RPC > and as a notification. This complicates the code path. > Current implementations can set up internal structures > and glean info from the 'rpc' node that is required > for all real RPCs. As proposed, an implementation would > have to either look ahead or undo and restart, because > the internal code path for notification processing > is totally different than for a real RPC (no error response > handling for starters). > > >Draft Proposed Layering: > > Layer Example > +-------------+ +-----------------------------+ > | Content | | Configuration data | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > | Operations | | , | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > | RPC | | , | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > | Application | | BEEP, SSH, SSL, console | > | Protocol | | | > +-------------+ +-----------------------------+ > > >My Proposed Layering > > Layer Example > +-------------+ +-----------------------------+ > | Content | | Configuration data | > +-------------+ +-----------------------------+ > | | > +-------------+ | > | Operations | | > +-------------+ \ > | \ > +-------------+ +--------------+ > | RPC | | Notification | > +-------------+ +--------------+ > | / > +-------------+ +-----------------------------+ > | Application | | BEEP, SSH, SSL, console | > | Protocol | | | > +-------------+ +-----------------------------+ > > >There is no operation layer in a notification. >There is only transport, notification header, and content. > >Andy > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 24 14:48:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1U9h-0001lt-9h for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 14:48: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 OAA12893 for ; Tue, 24 Jan 2006 14:47:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Tzt-0001gS-0n for netconf-data@psg.com; Tue, 24 Jan 2006 19:38:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Tzr-0001gG-R9 for netconf@ops.ietf.org; Tue, 24 Jan 2006 19:38:32 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 24 Jan 2006 11:38:31 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0OJcVWF008780; Tue, 24 Jan 2006 11:38:31 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 11:38:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Notification architecture Date: Tue, 24 Jan 2006 11:38:30 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB01499DAC@xmb-sjc-223.amer.cisco.com> Thread-Topic: Notification architecture Thread-Index: AcYhE4qsb8MRYpNqSdu7E2Ab1tajEgAAbGnQ From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" , "Sharon Chisholm" Cc: "Netconf \(E-mail\)" X-OriginalArrivalTime: 24 Jan 2006 19:38:31.0368 (UTC) FILETIME=[C1ABFC80:01C6211D] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, January 24, 2006 11:10 AM > To: Sharon Chisholm > Cc: Netconf (E-mail) > Subject: Re: Notification architecture >=20 > Sharon Chisholm wrote: >=20 > >hi > > > >Couple points: > > > >1. Notifications are not layered on the , but rather a=20 > new wrapper=20 > >of which is at the same Netconf layer as but is=20 > >different. Therefore there should be no issues surrounding=20 > statistics=20 > >and I don't think the beep mapping is hindered by this wrapper. > > > > =20 > > >=20 > I don't like it at all. > The document is not very clear at all. > There are many details that are buried in hard-to-read XSD=20 > and not explained in any human-readable text. HT: As Sharon said above, the proposal is to introduce a) new operation at rpc layer=20 (rpc-one-way) and b) a new message at the operations layer (notification). Perhaps you can explain what details you feel are missing.=20 String 0 2001-12-17T09:30:47.0Z The proposed approach satisfies the unacknowledged notification aspect. For ack notifications you could use the rpc, rpc-reply w/o changing the notification definition. You could of course say that notifications do not follow the layering scheme that the NETCONF protocol follows and remove the rpc-one-way. In this case then to indicate whether the notification is ackd or unackd a new field needs to be added to the notification operation/message. =20 >=20 > >2. I've had good success in using the existing Netconf layer=20 > model to=20 > >help people understand the different bits of Netconf. Your proposed=20 > >update solves one problem I had around the fact that drawn the wrong=20 > >way, it would imply that ran over or something=20 > >along those lines, but it now breaks the fact that there are layers. > >This concept gets somewhat lost. > > =20 > > > . > IMO, it is way simpler to explain the notification path as=20 > separate from the operations path. They are separate in CLI=20 > and SNMP. I just don't see a notification as a one way=20 > remote procedure call. It is convoluted. HT: Ok, should've read the email b4 typing. I don't see how it is convoluted & I think I sent you some references to other work that uses one way rpcs (so this is not unique to this proposal).=20 With that said, the definition could be done either way. But the goal was to preserve the layering scheme.=20 In SNMP you have a separate operation/PDU for notifications but everything else is the same. The protocol stack doesn't change. Same thing for other protocols (e.g. CMIP - I know bad comparison), remote invocation (ROSE) for event notifications is done in the same manner as for other protocol operations. =20 >=20 > BTW, we decided awhile back that we didn't want 'void' RPCs. > That is why we have the element. HT: Well but that didn't include discussion on notifications. Did it?=20 >=20 > >3. There are advantages to systems who want to process both=20 > synchronous=20 > >and asynchronous messages to be able to use the same method > > - process rpc > > - process message > >By having two different architectures for these messages, things=20 > >diverge much more. > > =20 > > >=20 > Really? What are they? > This looks like a broken architecture to me. > Requests which return responses and/or status are not handled=20 > the same as async. notifications -- which is what we are=20 > chartered to add to netconf. HT: You can define a protocol which notifies a remote entity that a message has been received in the same manner regardless of whether or not it is an async message. Maybe something else other than an rpc could've been used for NETCONF to accommodate cmd/rsp and one way messages. Anyway, you may ignore my previous comment.=20 >=20 > >4. I don't understand the access control comment. > > > > =20 > > >=20 > It was based on layering. > It wasn't clear from the document that is=20 > under . (Why the extra layer -- oh yeah -- we=20 > may add other types of 1-way rpcs in the future :-) >=20 >=20 > >5. Layer compression for notifications limits future extensibility=20 > >options. What happens if some mythical day in the future we=20 > want to add=20 > >another type of asynchronous message, or want to do=20 > acknowledged events? > > =20 > > >=20 > Like what? > We can deal with that problem if it ever comes up. > Extending XML is pretty easy. >=20 > >How does that work? Right now, I could conceive of running=20 > > over as one method to do=20 > acknowledged=20 > >events, which becomes more difficult with what you are proposing. I=20 > >don't want to optimize the architecture for things that are out of=20 > >scope of this release and things which we may never ever get=20 > to, but I=20 > >think in general we should give some consideration to the=20 > implications=20 > >on extensibility that this compression might have. > > =20 > > >=20 > Nobody else seems to want to do this. > (Have the manager listen for ?) >=20 > Why do you want to make this so complicated? > A notification, over RPC, with an operations layer? > What is it used for? I don't get it. >=20 > We should be solving current operational problems. > We have both the syslog and SNMP notification models in use=20 > today. We should build on that, not reinvent it. >=20 >=20 >=20 > >Sharon > > =20 > > >=20 > Andy >=20 > >-----Original Message----- > >From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On=20 > >Behalf Of Andy Bierman > >Sent: Thursday, January 12, 2006 9:59 AM > >To: Netconf (E-mail) > >Subject: Notification architecture > > > > > >Hi, > > > > > >IMO, the architectural layering defined in the Notifications=20 > draft is=20 > >broken. Currently, a notification is modeled as an=20 > operation -- as a=20 > >child of the node in the PDU encoding. The whole notion of a=20 > >one-way remote procedure call instead of an event notification seems=20 > >convoluted to me. A notification is not a 'void' procedure=20 > call (i.e.,=20 > >just a function with no return value). It has temporal=20 > characteristics. > >That's why it has a timestamp and an RPC doesn't. > > > > needs to be a top-level element. > > > >This proposed layering creates several problems: > > > > - Access control configuration is more complicated. It is > > desirable to give separate access to users for notifications > > and real RPCs like . Nesting these elements > > forces more complex access control rules to be configured > > to accomplish this feature. > > - Notifications cannot be channelized in the BEEP transport > > unless is independent of . Obviously > > we want to take advantage of this feature in BEEP for asynch > > notifications. That's been our design goal from day 1. > > - Statistics for RPCs will be confusing > > It is desirable for the stats for RPCs to be separate from > > the stats for notifications, e.g. > > ncInRpcs =3D=3D ncOutNoErrs + ncOutErrs[ncErrorType]; > > (for all ncErrorType) > > - Dual-role entities will be receiving as a real RPC > > and as a notification. This complicates the code path. > > Current implementations can set up internal structures > > and glean info from the 'rpc' node that is required > > for all real RPCs. As proposed, an implementation would > > have to either look ahead or undo and restart, because > > the internal code path for notification processing > > is totally different than for a real RPC (no error response > > handling for starters). > > > > > >Draft Proposed Layering: > > > > Layer Example > > +-------------+ +-----------------------------+ > > | Content | | Configuration data | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ +-----------------------------+ > > | Operations | | , | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ +-----------------------------+ > > | RPC | | , | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ +-----------------------------+ > > | Application | | BEEP, SSH, SSL, console | > > | Protocol | | | > > +-------------+ +-----------------------------+ > > > > > >My Proposed Layering > > > > Layer Example > > +-------------+ +-----------------------------+ > > | Content | | Configuration data | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ | > > | Operations | | > > +-------------+ \ > > | \ > > +-------------+ +--------------+ > > | RPC | | Notification | > > +-------------+ +--------------+ > > | / > > +-------------+ +-----------------------------+ > > | Application | | BEEP, SSH, SSL, console | > > | Protocol | | | > > +-------------+ +-----------------------------+ > > > > > >There is no operation layer in a notification. > >There is only transport, notification header, and content. > > > >Andy > > > > > > > >-- > >to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with the=20 > >word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > >-- > >to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with the=20 > >word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > > =20 > > >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=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 Jan 24 15:15:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UZJ-0001zI-5e for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 15:15: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 PAA14999 for ; Tue, 24 Jan 2006 15:13:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1URG-0003MP-6X for netconf-data@psg.com; Tue, 24 Jan 2006 20:06: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=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 1F1URF-0003M6-9J for netconf@ops.ietf.org; Tue, 24 Jan 2006 20:06:49 +0000 Received: (qmail 31743 invoked from network); 24 Jan 2006 20:06:48 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr5.mgt.bos.netsol.com with SMTP; 24 Jan 2006 20:06:48 -0000 Message-ID: <43D688D8.4040509@andybierman.com> Date: Tue, 24 Jan 2006 12:06:48 -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: prelim agenda for IETF #65 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, The NETCONF WG will meet for 1 session at IETF #65 in Dallas. The only agenda topic is the NETCONF Notifications charter item. There is only draft for review for this meeting: NETCONF Event Notifications http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-00.txt I urge all WG members to read this draft and make comments on the WG mailing list so we can establish an issues list before the meeting. 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 Tue Jan 24 15:27:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Ukm-0005lw-Ty for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 15:27: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 PAA15878 for ; Tue, 24 Jan 2006 15:25:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Ueo-0004Ad-8c for netconf-data@psg.com; Tue, 24 Jan 2006 20:20: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=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 1F1Uem-0004AI-Ky for netconf@ops.ietf.org; Tue, 24 Jan 2006 20:20:49 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A16E14D3C9; Tue, 24 Jan 2006 21:20:45 +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 31621-10; Tue, 24 Jan 2006 21:20:43 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) by hermes.iu-bremen.de (Postfix) with ESMTP id D5D344D034; Tue, 24 Jan 2006 21:20:43 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 24B725C6961; Tue, 24 Jan 2006 21:20:39 +0100 (CET) Date: Tue, 24 Jan 2006 21:20:39 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Notification architecture Message-ID: <20060124202039.GA853@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Sharon Chisholm , "Netconf (E-mail)" References: <713043CE8B8E1348AF3C546DBE02C1B4066B9EDA@zcarhxm2.corp.nortel.com> <43D66D69.1090002@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D66D69.1090002@andybierman.com> Fcc: =SENT 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, Jan 24, 2006 at 10:09:45AM -0800, Andy Bierman wrote: > > > >1. Notifications are not layered on the , but rather a new wrapper > >of which is at the same Netconf layer as but is > >different. Therefore there should be no issues surrounding statistics > >and I don't think the beep mapping is hindered by this wrapper. > > I don't like it at all. > The document is not very clear at all. > There are many details that are buried in > hard-to-read XSD and not explained in > any human-readable text. [...] Andy, I find your comments related to notifications a bit harsh and not really very constructive. If you think details are missing, please pose the question and let people have a chance to supply the details that are not well explained in human readable text. (I note that the level of detail you provided on this list was also not that great.) OK, I understand you don't like the proposed framing of notifications while others seem to think this is a good idea to have. So lets talk about the pros and cons of introducing . Once we have a clear cut list of the pros and cons, the WG might come to an informed conclusion. Right now, I have the feeling that the tone of the debate is counter productive and upsetting contributors. Perhaps it helps if Sharon posts an itemized list why having the framing is a good idea and Andy posts an itemized list why the addition of is not needed and a really bad idea. If both manage to stick to clear technical arguments, we might have an easier way to move forward on this issue. /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 Jan 24 15:27:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Ukn-0005m8-T5 for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 15:27: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 PAA15881 for ; Tue, 24 Jan 2006 15:25:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1UfR-0004Cs-5c for netconf-data@psg.com; Tue, 24 Jan 2006 20:21:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1UfP-0004CV-Sn for netconf@ops.ietf.org; Tue, 24 Jan 2006 20:21:28 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2006 12:21:11 -0800 X-IronPort-AV: i="4.01,214,1136188800"; d="scan'208"; a="395828899:sNHT43629524700" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0OKL9c1003491; Tue, 24 Jan 2006 12:21:09 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 12:21:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Notification architecture Date: Tue, 24 Jan 2006 12:21:08 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB01499DEF@xmb-sjc-223.amer.cisco.com> Thread-Topic: Notification architecture Thread-Index: AcYhE4qsb8MRYpNqSdu7E2Ab1tajEgAD8zpg From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" , "Sharon Chisholm" Cc: "Netconf \(E-mail\)" X-OriginalArrivalTime: 24 Jan 2006 20:21:09.0314 (UTC) FILETIME=[B6539220:01C62123] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I forgot to add... why don't we list the adv/disadv of the 2 or maybe 3 options for notifs layers/structure, discuss it and select one. =20 Hector =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, January 24, 2006 11:10 AM > To: Sharon Chisholm > Cc: Netconf (E-mail) > Subject: Re: Notification architecture >=20 > Sharon Chisholm wrote: >=20 > >hi > > > >Couple points: > > > >1. Notifications are not layered on the , but rather a=20 > new wrapper=20 > >of which is at the same Netconf layer as but is=20 > >different. Therefore there should be no issues surrounding=20 > statistics=20 > >and I don't think the beep mapping is hindered by this wrapper. > > > > =20 > > >=20 > I don't like it at all. > The document is not very clear at all. > There are many details that are buried in hard-to-read XSD=20 > and not explained in any human-readable text. >=20 > >2. I've had good success in using the existing Netconf layer=20 > model to=20 > >help people understand the different bits of Netconf. Your proposed=20 > >update solves one problem I had around the fact that drawn the wrong=20 > >way, it would imply that ran over or something=20 > >along those lines, but it now breaks the fact that there are layers. > >This concept gets somewhat lost. > > =20 > > > . > IMO, it is way simpler to explain the notification path as=20 > separate from the operations path. They are separate in CLI=20 > and SNMP. I just don't see a notification as a one way=20 > remote procedure call. It is convoluted. >=20 > BTW, we decided awhile back that we didn't want 'void' RPCs. > That is why we have the element. >=20 > >3. There are advantages to systems who want to process both=20 > synchronous=20 > >and asynchronous messages to be able to use the same method > > - process rpc > > - process message > >By having two different architectures for these messages, things=20 > >diverge much more. > > =20 > > >=20 > Really? What are they? > This looks like a broken architecture to me. > Requests which return responses and/or status are not handled=20 > the same as async. notifications -- which is what we are=20 > chartered to add to netconf. >=20 > >4. I don't understand the access control comment. > > > > =20 > > >=20 > It was based on layering. > It wasn't clear from the document that is=20 > under . (Why the extra layer -- oh yeah -- we=20 > may add other types of 1-way rpcs in the future :-) >=20 >=20 > >5. Layer compression for notifications limits future extensibility=20 > >options. What happens if some mythical day in the future we=20 > want to add=20 > >another type of asynchronous message, or want to do=20 > acknowledged events? > > =20 > > >=20 > Like what? > We can deal with that problem if it ever comes up. > Extending XML is pretty easy. >=20 > >How does that work? Right now, I could conceive of running=20 > > over as one method to do=20 > acknowledged=20 > >events, which becomes more difficult with what you are proposing. I=20 > >don't want to optimize the architecture for things that are out of=20 > >scope of this release and things which we may never ever get=20 > to, but I=20 > >think in general we should give some consideration to the=20 > implications=20 > >on extensibility that this compression might have. > > =20 > > >=20 > Nobody else seems to want to do this. > (Have the manager listen for ?) >=20 > Why do you want to make this so complicated? > A notification, over RPC, with an operations layer? > What is it used for? I don't get it. >=20 > We should be solving current operational problems. > We have both the syslog and SNMP notification models in use=20 > today. We should build on that, not reinvent it. >=20 >=20 >=20 > >Sharon > > =20 > > >=20 > Andy >=20 > >-----Original Message----- > >From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On=20 > >Behalf Of Andy Bierman > >Sent: Thursday, January 12, 2006 9:59 AM > >To: Netconf (E-mail) > >Subject: Notification architecture > > > > > >Hi, > > > > > >IMO, the architectural layering defined in the Notifications=20 > draft is=20 > >broken. Currently, a notification is modeled as an=20 > operation -- as a=20 > >child of the node in the PDU encoding. The whole notion of a=20 > >one-way remote procedure call instead of an event notification seems=20 > >convoluted to me. A notification is not a 'void' procedure=20 > call (i.e.,=20 > >just a function with no return value). It has temporal=20 > characteristics. > >That's why it has a timestamp and an RPC doesn't. > > > > needs to be a top-level element. > > > >This proposed layering creates several problems: > > > > - Access control configuration is more complicated. It is > > desirable to give separate access to users for notifications > > and real RPCs like . Nesting these elements > > forces more complex access control rules to be configured > > to accomplish this feature. > > - Notifications cannot be channelized in the BEEP transport > > unless is independent of . Obviously > > we want to take advantage of this feature in BEEP for asynch > > notifications. That's been our design goal from day 1. > > - Statistics for RPCs will be confusing > > It is desirable for the stats for RPCs to be separate from > > the stats for notifications, e.g. > > ncInRpcs =3D=3D ncOutNoErrs + ncOutErrs[ncErrorType]; > > (for all ncErrorType) > > - Dual-role entities will be receiving as a real RPC > > and as a notification. This complicates the code path. > > Current implementations can set up internal structures > > and glean info from the 'rpc' node that is required > > for all real RPCs. As proposed, an implementation would > > have to either look ahead or undo and restart, because > > the internal code path for notification processing > > is totally different than for a real RPC (no error response > > handling for starters). > > > > > >Draft Proposed Layering: > > > > Layer Example > > +-------------+ +-----------------------------+ > > | Content | | Configuration data | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ +-----------------------------+ > > | Operations | | , | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ +-----------------------------+ > > | RPC | | , | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ +-----------------------------+ > > | Application | | BEEP, SSH, SSL, console | > > | Protocol | | | > > +-------------+ +-----------------------------+ > > > > > >My Proposed Layering > > > > Layer Example > > +-------------+ +-----------------------------+ > > | Content | | Configuration data | > > +-------------+ +-----------------------------+ > > | | > > +-------------+ | > > | Operations | | > > +-------------+ \ > > | \ > > +-------------+ +--------------+ > > | RPC | | Notification | > > +-------------+ +--------------+ > > | / > > +-------------+ +-----------------------------+ > > | Application | | BEEP, SSH, SSL, console | > > | Protocol | | | > > +-------------+ +-----------------------------+ > > > > > >There is no operation layer in a notification. > >There is only transport, notification header, and content. > > > >Andy > > > > > > > >-- > >to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with the=20 > >word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > >-- > >to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with the=20 > >word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > > =20 > > >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=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 Jan 24 15:53:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VAM-0005AR-Kr for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 15:53: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 PAA18615 for ; Tue, 24 Jan 2006 15:51:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1V5W-0005mC-Bu for netconf-data@psg.com; Tue, 24 Jan 2006 20:48: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1V5T-0005lX-C7 for netconf@ops.ietf.org; Tue, 24 Jan 2006 20:48:23 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0OKmIF28950 for ; Tue, 24 Jan 2006 15:48:18 -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: Netconf Event: Issue #1: To RCP or Not to RPC Date: Tue, 24 Jan 2006 15:48:17 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40694BF52@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf Event: Issue #1: To RCP or Not to RPC Thread-Index: AcYhJ4EHdpgOnCXlRE6S6eNOlSibRA== From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi As Juergen suggested, I'm going to start off pros/cons list of having something at the RCP-layer in the Netconf Notification Solution. My list on each side is shorter than I was hoping, but it hopefully can start things off for us. In short though, once you have the Netconf Layers diagrammed engrained in your head, honouring these layers by having an rpc-layer wrapper seems to be the simplest solution. Removing it seems more like an optimization that says well, this new wrapper only can contain one type of operation, so why have it? I see the efficiency in removing it, but think we need to be careful about future proofing the architecture. Note that I've always viewed the term as a bit of a misnomer since the Netconf RPC isn't really a traditional RPC. I suspect that perhaps some of the disconnect on this issue might lie in how much one treats like an XML tag and how much one treats it like a traditional RPC. Pros ---- 1) Other netconf operations are wrapped in something in the RPC-layer. It seems cleanest to also wrap the in this layer. (Ease of understanding, ease of processing, etc) Cons ---- 1) If there is only one type of asynchronous message, then we can save some bits on the wire, but only having one wrapper instead of two. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 24 16:16:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VWd-0000bT-Co for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 16:16: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 QAA26905 for ; Tue, 24 Jan 2006 16:14:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1VQk-00078I-HG for netconf-data@psg.com; Tue, 24 Jan 2006 21:10:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [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 1F1VQj-000786-Tc for netconf@ops.ietf.org; Tue, 24 Jan 2006 21:10:21 +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 k0OL2E1Z060543; Tue, 24 Jan 2006 13:02:15 -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 k0OL2E522608; Tue, 24 Jan 2006 13:02:14 -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 k0OL7NYE091840; Tue, 24 Jan 2006 16:07:30 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200601242107.k0OL7NYE091840@idle.juniper.net> To: "Sharon Chisholm" cc: netconf@ops.ietf.org Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC In-Reply-To: Your message of "Tue, 24 Jan 2006 15:48:17 EST." <713043CE8B8E1348AF3C546DBE02C1B40694BF52@zcarhxm2.corp.nortel.com> Date: Tue, 24 Jan 2006 16:07:23 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Sharon Chisholm" writes: >Note that I've always viewed the term as a bit of a misnomer since >the Netconf RPC isn't really a traditional RPC. I suspect that perhaps >some of the disconnect on this issue might lie in how much one treats > like an XML tag and how much one treats it like a traditional RPC. I'd like to jump into the pro/con debate, but first I'd like to understand your point here, since that may be the source of my dislike this notification encoding. Please clue me in on why the Netconf RPC isn't really a traditional RPC. 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 Jan 24 16:30:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VkF-0007RO-9Y for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 16:30: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 QAA01223 for ; Tue, 24 Jan 2006 16:28:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Vg0-00082e-GL for netconf-data@psg.com; Tue, 24 Jan 2006 21:26: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.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Vfz-00082O-DQ for netconf@ops.ietf.org; Tue, 24 Jan 2006 21:26:07 +0000 Received: (qmail 20124 invoked from network); 24 Jan 2006 21:26:06 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 24 Jan 2006 21:26:06 -0000 Message-ID: <43D69B6E.2070909@andybierman.com> Date: Tue, 24 Jan 2006 13:26: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: j.schoenwaelder@iu-bremen.de CC: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Notification architecture References: <713043CE8B8E1348AF3C546DBE02C1B4066B9EDA@zcarhxm2.corp.nortel.com> <43D66D69.1090002@andybierman.com> <20060124202039.GA853@boskop.local> In-Reply-To: <20060124202039.GA853@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, Jan 24, 2006 at 10:09:45AM -0800, Andy Bierman wrote: > > >>>1. Notifications are not layered on the , but rather a new wrapper >>>of which is at the same Netconf layer as but is >>>different. Therefore there should be no issues surrounding statistics >>>and I don't think the beep mapping is hindered by this wrapper. >>> >>> >>I don't like it at all. >>The document is not very clear at all. >>There are many details that are buried in >>hard-to-read XSD and not explained in >>any human-readable text. >> >> > >[...] > >Andy, I find your comments related to notifications a bit harsh and >not really very constructive. If you think details are missing, please >pose the question and let people have a chance to supply the details >that are not well explained in human readable text. (I note that the >level of detail you provided on this list was also not that great.) > >OK, I understand you don't like the proposed framing of >notifications while others seem to think this is a good idea to have. >So lets talk about the pros and cons of introducing . >Once we have a clear cut list of the pros and cons, the WG might come >to an informed conclusion. Right now, I have the feeling that the tone >of the debate is counter productive and upsetting contributors. > > okay. I will be quiet now and let others read the draft and make comments. I have found that there is no better way to improve a design than by implementing it. I believe both co-Chairs of this WG would rather start (any charter item) with a deployed working solution than with an untested proposal. BTW, I will not interpret silence as positive consensus, so speak up if you have opinions. >Perhaps it helps if Sharon posts an itemized list why having the > framing is a good idea and Andy posts an itemized list >why the addition of is not needed and a really bad idea. >If both manage to stick to clear technical arguments, we might have an >easier way to move forward on this issue. > > I don't think we should have a complicated architecture unless we FULLY UNDERSTAND WHY. I am never swayed by arguments like "we might want to do some unknown thing the future". If the WG agrees on specific future extensions, that's something else. All engineering tradeoffs need to be cost-justified. >/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 Jan 24 16:40:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VtR-0004Ca-Fk for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 16:40: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 QAA04386 for ; Tue, 24 Jan 2006 16:38:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1VpT-0008b9-VK for netconf-data@psg.com; Tue, 24 Jan 2006 21:35: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1VpR-0008ag-7Z for netconf@ops.ietf.org; Tue, 24 Jan 2006 21:35:53 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0OLZoV29707 for ; Tue, 24 Jan 2006 16:35:50 -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 Event: Issue #1: To RCP or Not to RPC Date: Tue, 24 Jan 2006 16:35:49 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40694BFF8@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf Event: Issue #1: To RCP or Not to RPC Thread-Index: AcYhKpYhGxAYS93uR6+d/IbXyZDk+AAAQ10w From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Ok. This could get fun :-) So, while I can bend the definition of an RPC (http://www.cs.cf.ac.uk/Dave/C/node33.html) to kind of make it fit to what we are doing in Netconf, the fact is that even without a tag called we would still have - A connection between the client and server - The ability to execute a command on the server=20 We couldn't get the response, but we could have designed around it. Personally, I think the wrapper is much more elegant than doing that. It is its role as a wrapper that we are trying to mimic. Perhaps we should rename it to and loose the rpc bit. That might make things cleaner while still maintaining some alignment. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net]=20 Sent: Tuesday, January 24, 2006 4:07 PM To: Chisholm, Sharon [CAR:ZZ00:EXCH] Cc: netconf@ops.ietf.org Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC=20 "Sharon Chisholm" writes: >Note that I've always viewed the term as a bit of a misnomer=20 >since the Netconf RPC isn't really a traditional RPC. I suspect that=20 >perhaps some of the disconnect on this issue might lie in how much one=20 >treats like an XML tag and how much one treats it like a=20 >traditional RPC. I'd like to jump into the pro/con debate, but first I'd like to understand your point here, since that may be the source of my dislike this notification encoding. Please clue me in on why the Netconf RPC isn't really a traditional RPC. 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 Jan 24 16:40:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Vtu-0004Mr-RZ for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 16:40: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 QAA04472 for ; Tue, 24 Jan 2006 16:38:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1VpG-0008a5-ID for netconf-data@psg.com; Tue, 24 Jan 2006 21:35: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=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 1F1VpD-0008Zn-9R for netconf@ops.ietf.org; Tue, 24 Jan 2006 21:35:41 +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 97015007; Tue, 24 Jan 2006 22:35:36 +0100 Date: Tue, 24 Jan 2006 22:35:29 +0100 (CET) Message-Id: <20060124.223529.58460213.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification architecture From: Martin Bjorklund In-Reply-To: <43D66D69.1090002@andybierman.com> References: <713043CE8B8E1348AF3C546DBE02C1B4066B9EDA@zcarhxm2.corp.nortel.com> <43D66D69.1090002@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 Hi, This has probably been discussed before, and the answer might be obvious, but I can't find anything in the archives. I'd like to know why a new notification framework is needed? Is it simply that we need to be able to send larger messages than what syslog can do? Or is it because the content of the notifications will be tightly coupled to the ordinary netconf content, and therefore it's easier to use a new scheme than trying to map the netconf model to syslog? Or something else? I think the most important question then is the session model - if the manager should set up the session and keep it open or if the agent should establish the session when needed. If the manager is supposed to keep it open, how well does that scale? 1000 sessions? 10000? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 24 16:49:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1W30-0002oV-DR for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 16:49: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 QAA05870 for ; Tue, 24 Jan 2006 16:48:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1VzG-0009JV-1e for netconf-data@psg.com; Tue, 24 Jan 2006 21:46: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1VzF-0009Id-8w for netconf@ops.ietf.org; Tue, 24 Jan 2006 21:46:01 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0OLjuF13411 for ; Tue, 24 Jan 2006 16:45:56 -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: Notification architecture Date: Tue, 24 Jan 2006 16:45:56 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40694C01E@zcarhxm2.corp.nortel.com> Thread-Topic: Notification architecture Thread-Index: AcYhLgCNkK9H961uTPaPUFSEMayeBAAAE3Fg From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I have found that there is no better way to improve a design than by implementing it. I believe both co-Chairs of this WG would rather start (any charter item) with a deployed working solution than with an untested proposal.=20 So, you'll be pleased to learn that an earlier version of this is being/has been implemented. Any feedback we get from implementers or users we will be sure to feedback into the working group. I've already made some adjustments based on this sort of feedback. I don't think we should have a complicated architecture unless we FULLY UNDERSTAND WHY. I am never swayed by arguments like "we might want to do some unknown thing the future". If the WG agrees on specific future extensions, that's something else. All engineering tradeoffs need to be cost-justified. The problem is that we are both arguing that we are proposing the simpler architecture. That isn't helpful. 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 Tue Jan 24 17:02:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1WFI-0001Hj-DE for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 17:02: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 RAA06935 for ; Tue, 24 Jan 2006 17:01:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1WAS-0009x9-Nc for netconf-data@psg.com; Tue, 24 Jan 2006 21:57: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.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1WAR-0009ws-Mv for netconf@ops.ietf.org; Tue, 24 Jan 2006 21:57:35 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0OLvVF15083 for ; Tue, 24 Jan 2006 16:57: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: Notification architecture Date: Tue, 24 Jan 2006 16:57:30 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40694C047@zcarhxm2.corp.nortel.com> Thread-Topic: Notification architecture Thread-Index: AcYhL5+mGdmJtAr5TPGnjOKZg0BU1gAAENFw From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Tighter integration is a major driving factor. Plus, as much as we love syslog, there are a few problems that I can't figure out how to solve with it.=20 As far as sessions go, the network element would not have to maintain that many, perhaps only one, to the management application, so I am guessing you are asking about the management application. Management applications today that use things like TL1 and some proprietary protocols are used to connection-oriented management and see to cope OK. There is likely overhead, but they also save on not having to run keep polling the SNMP agent to ensure it can still talk to the device. I might look around to see if I can find any hard numbers (and if I can share them). Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Martin Bjorklund Sent: Tuesday, January 24, 2006 4:35 PM To: ietf@andybierman.com Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; netconf@ops.ietf.org Subject: Re: Notification architecture Hi, This has probably been discussed before, and the answer might be obvious, but I can't find anything in the archives. I'd like to know why a new notification framework is needed? Is it simply that we need to be able to send larger messages than what syslog can do? Or is it because the content of the notifications will be tightly coupled to the ordinary netconf content, and therefore it's easier to use a new scheme than trying to map the netconf model to syslog? Or something else? I think the most important question then is the session model - if the manager should set up the session and keep it open or if the agent should establish the session when needed. If the manager is supposed to keep it open, how well does that scale? 1000 sessions? 10000? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 24 17:34:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1WkX-00018B-EA for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 17:34: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 RAA10756 for ; Tue, 24 Jan 2006 17:33:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Wfl-000Bbp-9v for netconf-data@psg.com; Tue, 24 Jan 2006 22:29: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.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Wfi-000BbV-RQ for netconf@ops.ietf.org; Tue, 24 Jan 2006 22:29:55 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id EA0734D36A; Tue, 24 Jan 2006 23:29:50 +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 08302-09; Tue, 24 Jan 2006 23:29:49 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5AF134D339; Tue, 24 Jan 2006 23:29:49 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 671F55C82AF; Tue, 24 Jan 2006 23:29:46 +0100 (CET) Date: Tue, 24 Jan 2006 23:29:46 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: Notification architecture Message-ID: <20060124222946.GC1018@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B40694C047@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40694C047@zcarhxm2.corp.nortel.com> Fcc: =SENT 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, Jan 24, 2006 at 04:57:30PM -0500, Sharon Chisholm wrote: > As far as sessions go, the network element would not have to maintain > that many, perhaps only one, to the management application, so I am > guessing you are asking about the management application. Management > applications today that use things like TL1 and some proprietary > protocols are used to connection-oriented management and see to cope OK. > There is likely overhead, but they also save on not having to run keep > polling the SNMP agent to ensure it can still talk to the device. I > might look around to see if I can find any hard numbers (and if I can > share them). I posted some numbers to this list on Wed, 6 Jul 2005 17:25:38 +0200 under the thread "Scalability of Netconf". There were also some related postings and hence I suggest that people go back to the archives. /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 Jan 24 18:39:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XlW-0007ah-A4 for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 18:39: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 SAA15900 for ; Tue, 24 Jan 2006 18:38:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Xeg-000Eu2-QY for netconf-data@psg.com; Tue, 24 Jan 2006 23:32:54 +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 1F1Xee-000Etj-8X for netconf@ops.ietf.org; Tue, 24 Jan 2006 23:32:52 +0000 Received: (qmail 17680 invoked from network); 24 Jan 2006 23:32:51 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr5.mgt.bos.netsol.com with SMTP; 24 Jan 2006 23:32:51 -0000 Message-ID: <43D6B922.8070404@andybierman.com> Date: Tue, 24 Jan 2006 15:32:50 -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 (E-mail)" Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC References: <713043CE8B8E1348AF3C546DBE02C1B40694BF52@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40694BF52@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 > >As Juergen suggested, I'm going to start off pros/cons list of having >something at the RCP-layer in the Netconf Notification Solution. My list >on each side is shorter than I was hoping, but it hopefully can start >things off for us. > >In short though, once you have the Netconf Layers diagrammed engrained >in your head, honouring these layers by having an rpc-layer wrapper >seems to be the simplest solution. Removing it seems more like an >optimization that says well, this new wrapper only can contain one type >of operation, so why have it? I see the efficiency in removing it, but >think we need to be careful about future proofing the architecture. > >Note that I've always viewed the term as a bit of a misnomer since >the Netconf RPC isn't really a traditional RPC. I suspect that perhaps >some of the disconnect on this issue might lie in how much one treats > like an XML tag and how much one treats it like a traditional RPC. > >Pros >---- >1) Other netconf operations are wrapped in something in the RPC-layer. >It seems cleanest to also wrap the in this layer. (Ease >of understanding, ease of processing, etc) > > > This is where we really disagree. IMO, a notification is not an operation. You are not executing an operation on the remote peer. You are simply notifying the remote peer of something. In my code anyway, the node is processed in the same manner for all RPC methods. If I had to look ahead to see if this was really some kind of special notification instead, this will complicate processing, not simplify it. >Cons >---- >1) If there is only one type of asynchronous message, then we can save >some bits on the wire, but only having one wrapper instead of two. > > > I think this pros and cons list is really missing the point, and masks some important decisions the WG has to make: 1) Are we standardizing notifications based on syslog, or creating something entirely different? 2) How should our design deal with unspecified, unknown, future extensions to the initial document? >Sharon Chisholm >Nortel >Ottawa, Ontario >Canada > > 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 Jan 24 20:09:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Z9z-0006wM-AA for netconf-archive@megatron.ietf.org; Tue, 24 Jan 2006 20: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 UAA23542 for ; Tue, 24 Jan 2006 20:07:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Z3s-000M7c-0B for netconf-data@psg.com; Wed, 25 Jan 2006 01:03:00 +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 [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1Z3r-000M7Q-A0 for netconf@ops.ietf.org; Wed, 25 Jan 2006 01:02:59 +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 k0P0x1cU013983; Tue, 24 Jan 2006 16:59:02 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k0P0uPMu005308; Tue, 24 Jan 2006 16:56:25 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k0P0uOfq005298; Tue, 24 Jan 2006 16:56:24 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 24 Jan 2006 16:56:24 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Andy Bierman cc: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC In-Reply-To: <43D6B922.8070404@andybierman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, To me, the term "Remote procedure call" means do something on the "server". Thus, maybe all might find it easier to take if it was /* data for the event report */ With this way of thinking, then you might then add /* data for periodic sample that is sent by the managed node to a manager, based on a configured reporting system */ Now whether or not you always want a reply to the RPC-REQUEST, that is a different issue. This issue exists for both "SETs" and "ACTIONs", when the response returns "no data" and indicates only that the request was successful. I believe that you should always send an "applcation level" indication that a request is success, and that the protocol should allow multiple requests to be "in flight" upto a configurable max (not unlimited). Thus, event reporting and SETs and GETs will all look the same. On Tue, 24 Jan 2006, Andy Bierman wrote: > Sharon Chisholm wrote: > > >hi > > > >As Juergen suggested, I'm going to start off pros/cons list of having > >something at the RCP-layer in the Netconf Notification Solution. My list > >on each side is shorter than I was hoping, but it hopefully can start > >things off for us. > > > >In short though, once you have the Netconf Layers diagrammed engrained > >in your head, honouring these layers by having an rpc-layer wrapper > >seems to be the simplest solution. Removing it seems more like an > >optimization that says well, this new wrapper only can contain one type > >of operation, so why have it? I see the efficiency in removing it, but > >think we need to be careful about future proofing the architecture. > > > >Note that I've always viewed the term as a bit of a misnomer since > >the Netconf RPC isn't really a traditional RPC. I suspect that perhaps > >some of the disconnect on this issue might lie in how much one treats > > like an XML tag and how much one treats it like a traditional RPC. > > > >Pros > >---- > >1) Other netconf operations are wrapped in something in the RPC-layer. > >It seems cleanest to also wrap the in this layer. (Ease > >of understanding, ease of processing, etc) > > > > > > > > This is where we really disagree. > IMO, a notification is not an operation. > You are not executing an operation on the remote peer. > You are simply notifying the remote peer of something. > > In my code anyway, the node is processed in the > same manner for all RPC methods. If I had to look ahead > to see if this was really some kind of special notification > instead, this will complicate processing, not simplify it. > > >Cons > >---- > >1) If there is only one type of asynchronous message, then we can save > >some bits on the wire, but only having one wrapper instead of two. > > > > > > > > I think this pros and cons list is really missing the point, and masks > some important decisions the WG has to make: > > 1) Are we standardizing notifications based on syslog, or creating > something entirely different? > > 2) How should our design deal with unspecified, unknown, > future extensions to the initial document? > > >Sharon Chisholm > >Nortel > >Ottawa, Ontario > >Canada > > > > > > 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 Jan 25 01:25:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1e5e-00045W-0M for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 01:25: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 BAA12978 for ; Wed, 25 Jan 2006 01:23:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1dw9-000CSy-5R for netconf-data@psg.com; Wed, 25 Jan 2006 06:15: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 [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 1F1dw8-000CSf-94 for netconf@ops.ietf.org; Wed, 25 Jan 2006 06:15:20 +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 k0P65W504290; Tue, 24 Jan 2006 22:05:32 -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 k0P65F558582; Tue, 24 Jan 2006 22:05:19 -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 k0P6AVYE093191; Wed, 25 Jan 2006 01:10:31 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200601250610.k0P6AVYE093191@idle.juniper.net> To: "Sharon Chisholm" cc: netconf@ops.ietf.org Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC In-Reply-To: Your message of "Tue, 24 Jan 2006 16:35:49 EST." <713043CE8B8E1348AF3C546DBE02C1B40694BFF8@zcarhxm2.corp.nortel.com> Date: Wed, 25 Jan 2006 01:10:31 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Sharon Chisholm" writes: >Ok. This could get fun :-) Not likely ;^) >So, while I can bend the definition of an RPC >(http://www.cs.cf.ac.uk/Dave/C/node33.html) to kind of make it fit to >what we are doing in Netconf, the fact is that even without a tag called > we would still have > - A connection between the client and server > - The ability to execute a command on the server >We couldn't get the response, but we could have designed around it. >Personally, I think the wrapper is much more elegant than doing >that. I don't really follow you here, but it seems your example is a level above netconf. The URL talks about sunrpc's IDL and the XDR functions to encode data for it. We're more of the rfc1831 layer, where we're defining the bits over the wire, not the C-language interface to make those bits. One could even make a version of rpcgen that generates netconf calls . Anyhow, let's pretend we're happy with netconf's rpc model, cause I don't see it changing. I don't really see it as untraditional, in that it allows remote access to well-defined functions that accept a set of input arguments and return a set of output data. This allows one to sit in a high level language and say stuff like: $status = $jnx->commit_configuration(confirmed => true, timeout => 30); without knowing any details of the what's really going on. What I find disturbing about is (a) it's not an rpc, in the sense that it doesn't have a reply, and (b) it's going the wrong direction. You've got the server sending data to the client, which is definitely not an rpc. I tried to think of it as some sort of callback, but it's not really that either. It's really is a distinct channel of information, an ongoing reply to an already completed rpc, that's intermixed with the main netconf rpc content. All of which makes me wish we could resurrect the channels into netconf, but I don't really see this happening. Short of that, we're stuck with the server sending asynchronous data to the client, intermixed over the main rpc channel/stream. Well, I guess we could do notifications as long-lived RPCs, where I eat the entire connection with a RPC that only completes when the client s it (or closes the connection). >It is its role as a wrapper that we are trying to mimic. Perhaps we >should rename it to and loose the rpc bit. That might >make things cleaner while still maintaining some alignment. Choosing a better name will help, but the question Andy was asking is what else would we ever want the server to spontaneously and/or asynchronously send to the client that would behave exactly like the behavior we're defining for notifications that is not a notification? Unless we see something generic that will follow our fairly specific rules, what do we win by having ? 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 Jan 25 02:15:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1esR-0005zh-F3 for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 02:15: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 CAA16567 for ; Wed, 25 Jan 2006 02:14:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1emd-000F4h-Rr for netconf-data@psg.com; Wed, 25 Jan 2006 07: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 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 1F1emc-000F4T-EU for netconf@ops.ietf.org; Wed, 25 Jan 2006 07:09:34 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7D14E4D05E; Wed, 25 Jan 2006 08:09:33 +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 01905-03; Wed, 25 Jan 2006 08:09:31 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id D6A5F4BB38; Wed, 25 Jan 2006 08:09:31 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 7569A5CEFD7; Wed, 25 Jan 2006 08:09:30 +0100 (CET) Date: Wed, 25 Jan 2006 08:09:30 +0100 From: Juergen Schoenwaelder To: Phil Shafer Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC Message-ID: <20060125070930.GA4841@noname> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B40694BFF8@zcarhxm2.corp.nortel.com> <200601250610.k0P6AVYE093191@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601250610.k0P6AVYE093191@idle.juniper.net> Fcc: =SENT 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 Wed, Jan 25, 2006 at 01:10:31AM -0500, Phil Shafer wrote: > What I find disturbing about is (a) it's not an rpc, > in the sense that it doesn't have a reply, and (b) it's going the > wrong direction. You've got the server sending data to the client, > which is definitely not an rpc. I tried to think of it as some sort > of callback, but it's not really that either. It's really is a > distinct channel of information, an ongoing reply to an already > completed rpc, that's intermixed with the main netconf rpc content. Whether you need a reply depends on the semantics. Some people may even prefer to have a reply for a notification. In fact, confirmed notification delivery could be a reason which distinguishes netconf notifications from syslog. If we just rebuild syslog, I tend to agree with those who raise the very valid question why we want to do this in the first place. Regarding your second comment: Yes, client server roles switch for notification delivery. This is a long known issue with many interesting implications as we all learned over the years. But for me, it does not really matter whether the notification sits in an rpc frame or not - the issues that make notifications "interesting" will remain with or without it. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jan 25 02:55:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fVU-0002nf-4L for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 02:55: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 CAA18464 for ; Wed, 25 Jan 2006 02:54:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1fQj-000H5l-IL for netconf-data@psg.com; Wed, 25 Jan 2006 07:51:01 +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 1F1fQi-000H5Z-SL for netconf@ops.ietf.org; Wed, 25 Jan 2006 07:51:01 +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 k0P7db1Z067570; Tue, 24 Jan 2006 23:39:37 -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 k0P7da574877; Tue, 24 Jan 2006 23:39:36 -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 k0P7iqYE093400; Wed, 25 Jan 2006 02:44:52 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200601250744.k0P7iqYE093400@idle.juniper.net> To: j.schoenwaelder@iu-bremen.de cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC In-Reply-To: Your message of "Wed, 25 Jan 2006 08:09:30 +0100." <20060125070930.GA4841@noname> Date: Wed, 25 Jan 2006 02:44:52 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Juergen Schoenwaelder writes: >If we just rebuild syslog, I tend to agree >with those who raise the very valid question why we want to do this in >the first place. Yup, I've said before that syslog w/ SD-Params would make me happy. >Regarding your second comment: Yes, client server roles switch for >notification delivery. So maybe the easiest way forward (if we proceed) is to make notifications happen over a distinct connection where the server and client roles can be easily reversed and the notifications can be trafficed over the existing netconf protocol elements. 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 Jan 25 03:12:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1flW-0000YS-8O for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 03:12: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 DAA19482 for ; Wed, 25 Jan 2006 03:10:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1fgz-000HxP-0b for netconf-data@psg.com; Wed, 25 Jan 2006 08:07:49 +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.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1fgy-000HxD-58 for netconf@ops.ietf.org; Wed, 25 Jan 2006 08:07:48 +0000 Received: (qmail 4459 invoked from network); 25 Jan 2006 08:07:47 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 25 Jan 2006 08:07:47 -0000 Message-ID: <43D731D2.1000704@andybierman.com> Date: Wed, 25 Jan 2006 00:07:46 -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: Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC References: <713043CE8B8E1348AF3C546DBE02C1B40694BFF8@zcarhxm2.corp.nortel.com> <200601250610.k0P6AVYE093191@idle.juniper.net> <20060125070930.GA4841@noname> In-Reply-To: <20060125070930.GA4841@noname> 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 Wed, Jan 25, 2006 at 01:10:31AM -0500, Phil Shafer wrote: > > > >>What I find disturbing about is (a) it's not an rpc, >>in the sense that it doesn't have a reply, and (b) it's going the >>wrong direction. You've got the server sending data to the client, >>which is definitely not an rpc. I tried to think of it as some sort >>of callback, but it's not really that either. It's really is a >>distinct channel of information, an ongoing reply to an already >>completed rpc, that's intermixed with the main netconf rpc content. >> >> > >Whether you need a reply depends on the semantics. Some people may >even prefer to have a reply for a notification. In fact, confirmed >notification delivery could be a reason which distinguishes netconf >notifications from syslog. If we just rebuild syslog, I tend to agree >with those who raise the very valid question why we want to do this in >the first place. > >Regarding your second comment: Yes, client server roles switch for >notification delivery. This is a long known issue with many >interesting implications as we all learned over the years. But for me, >it does not really matter whether the notification sits in an rpc >frame or not - the issues that make notifications "interesting" will >remain with or without it. > > To me, an important interesting issue is whether we are standardizing best current practices or inventing new technology. I get very nervous when I see proposals for features that are not currently being widely used in the field by operators. When two or more independent organizations try to solve the same sort of problem, but with different solutions, in real products, then you know the industry is ready for a standard to solve that problem. To quote my favorite band: "You gave me something that I didn't have, but had no use..." We've done that so many times in SNMP, we should be more cautious by now. > >/js > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jan 25 07:34:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1jrD-0007jr-EQ for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 07:34: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 HAA06804 for ; Wed, 25 Jan 2006 07:33:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1jce-0005Hq-5H for netconf-data@psg.com; Wed, 25 Jan 2006 12:19: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 [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1jcc-0005He-Ph for netconf@ops.ietf.org; Wed, 25 Jan 2006 12:19:35 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9EF5761D; Wed, 25 Jan 2006 13:19:33 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 13:19:33 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jan 2006 13:19:33 +0100 Message-ID: <43D76CD4.1030004@ericsson.com> Date: Wed, 25 Jan 2006 13:19:32 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "David T. Perkins" , "Netconf (E-mail)" Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2006 12:19:33.0690 (UTC) FILETIME=[999B01A0:01C621A9] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David, I believe it is rather difficult to guess what a management box will do upon receiving a notification. Some possibilities are: log it, some automatic action to clear an alarm, notify a GUI that some long running configuration operation is complete, just be happy that a heart beat event is received. So for me this is really just a notification and it is really up to the receiver what he wants to do with it. Also for me it is important that the notifications are connected to the main part of netconf and can operate on the same managed data model, maybe refer to configuration RPC calls (e.g. to an edit-config), so the notification framework is much more then simply mapping to our protocol. Balazs David T. Perkins wrote: > HI, > > To me, the term "Remote procedure call" means do something > on the "server". Thus, maybe all might find it easier > to take if it was > > > /* data for the event report */ > > > > With this way of thinking, then you might then add > > > /* data for periodic sample that is sent by > the managed node to a manager, based on > a configured reporting system */ > > > > Now whether or not you always want a reply to the RPC-REQUEST, > that is a different issue. This issue exists for both > "SETs" and "ACTIONs", when the response returns "no data" > and indicates only that the request was successful. > > I believe that you should always send an "applcation level" > indication that a request is success, and that the protocol > should allow multiple requests to be "in flight" upto a > configurable max (not unlimited). Thus, event reporting > and SETs and GETs will all look the same. > > On Tue, 24 Jan 2006, Andy Bierman wrote: >> Sharon Chisholm wrote: >> >>> hi >>> >>> As Juergen suggested, I'm going to start off pros/cons list of having >>> something at the RCP-layer in the Netconf Notification Solution. My list >>> on each side is shorter than I was hoping, but it hopefully can start >>> things off for us. >>> >>> In short though, once you have the Netconf Layers diagrammed engrained >>> in your head, honouring these layers by having an rpc-layer wrapper >>> seems to be the simplest solution. Removing it seems more like an >>> optimization that says well, this new wrapper only can contain one type >>> of operation, so why have it? I see the efficiency in removing it, but >>> think we need to be careful about future proofing the architecture. >>> >>> Note that I've always viewed the term as a bit of a misnomer since >>> the Netconf RPC isn't really a traditional RPC. I suspect that perhaps >>> some of the disconnect on this issue might lie in how much one treats >>> like an XML tag and how much one treats it like a traditional RPC. >>> >>> Pros >>> ---- >>> 1) Other netconf operations are wrapped in something in the RPC-layer. >>> It seems cleanest to also wrap the in this layer. (Ease >>> of understanding, ease of processing, etc) >>> >>> >>> >> This is where we really disagree. >> IMO, a notification is not an operation. >> You are not executing an operation on the remote peer. >> You are simply notifying the remote peer of something. >> >> In my code anyway, the node is processed in the >> same manner for all RPC methods. If I had to look ahead >> to see if this was really some kind of special notification >> instead, this will complicate processing, not simplify it. >> >>> Cons >>> ---- >>> 1) If there is only one type of asynchronous message, then we can save >>> some bits on the wire, but only having one wrapper instead of two. >>> >>> >>> >> I think this pros and cons list is really missing the point, and masks >> some important decisions the WG has to make: >> >> 1) Are we standardizing notifications based on syslog, or creating >> something entirely different? >> >> 2) How should our design deal with unspecified, unknown, >> future extensions to the initial document? >> >>> Sharon Chisholm >>> Nortel >>> Ottawa, Ontario >>> Canada >>> >>> >> 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: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager 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 Wed Jan 25 08:59:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1lBC-00036n-No for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 08:59: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 IAA14127 for ; Wed, 25 Jan 2006 08:57:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1kzW-000AR8-5W for netconf-data@psg.com; Wed, 25 Jan 2006 13:47: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.1] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1kzV-000AQt-7z for netconf@ops.ietf.org; Wed, 25 Jan 2006 13:47:17 +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 83491545 for netconf@ops.ietf.org; Wed, 25 Jan 2006 14:47:13 +0100 Date: Wed, 25 Jan 2006 14:47:02 +0100 (CET) Message-Id: <20060125.144702.48373382.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: validate 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, Here's another one where the text and schema differs. In the text for the validate command, it says that the source parameter is the: Name of the configuration datastore being validated But the schema also allows for inline configurations like this: inline config Should I assume that the text is right and the schema wrong? /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 Jan 25 10:27:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1mYX-0000k3-K3 for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 10:27: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 KAA20630 for ; Wed, 25 Jan 2006 10:26:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1mKW-000FaG-Jw for netconf-data@psg.com; Wed, 25 Jan 2006 15:13: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 [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1mKT-000FZ6-40 for netconf@ops.ietf.org; Wed, 25 Jan 2006 15:13:01 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EE280628C8 for ; Wed, 25 Jan 2006 16:12:44 +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 6112561AAD for ; Wed, 25 Jan 2006 16:12:43 +0100 (CET) Message-ID: <43D79609.5050008@loria.fr> Date: Wed, 25 Jan 2006 16:15:21 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: edit-config operation Content-Type: multipart/mixed; boundary="------------080908040006000900070408" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080908040006000900070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, edit-config is not clear to me, in particular the merge operation: "merge: The configuration data identified by the element containing this attribute is merged with the configuration at the corresponding level in the configuration datastore identified by the target parameter. This is the default behavior." The draft says that the element must be merged in the config but it does not explain how. Is there a clear definition of merge for XML elements ? Also the given examples silently assume that the "name" element is a selection key. It should be explicit in the draft. For example, let's imagine a data model where: - the root element is "foo" - foo must have a "name" child - foo may have zero to two "bar" elements - "bar" is a simpleType element Initial config: bla bar1 Request: bla bar2 Possible outputs: bla bar2 bla bar1 bar2 Under merge meaning is implicitely a combination of replace or create operation ? There is no clear separation between the selecting nodes and nodes that must be updated. Even with replace operation we have the problem since we don't know which bar must be replaced. Anybody implementing has the same problems ? Another thing: we are planning to implement a new edit-config with xpath, as a new capability. It will look like that: Alice alicefoo a2 100 If the wg is interested to merge it to the standard xpath capability, just request more details. We believe that edit-config should be extended with XPath in a similar way than get-config. Sorry for the long mail. Thanks for your help. Vincent --------------080908040006000900070408 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 --------------080908040006000900070408-- -- to unsubscribe send a message to netconf-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 Jan 25 11:54:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1nut-00072Y-Qb for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 11:54: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 LAA29930 for ; Wed, 25 Jan 2006 11:53:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1nnD-000LM9-27 for netconf-data@psg.com; Wed, 25 Jan 2006 16:46: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 1F1nnC-000LLv-Bt for netconf@ops.ietf.org; Wed, 25 Jan 2006 16:46:46 +0000 Received: (qmail 2944 invoked from network); 25 Jan 2006 16:38:43 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 25 Jan 2006 16:38:43 -0000 Message-ID: <43D7A992.2030605@andybierman.com> Date: Wed, 25 Jan 2006 08:38:42 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Cridlig CC: netconf@ops.ietf.org Subject: Re: edit-config operation References: <43D79609.5050008@loria.fr> In-Reply-To: <43D79609.5050008@loria.fr> 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 Vincent Cridlig wrote: > Hi, > > edit-config is not clear to me, in particular the merge operation: > > "merge: The configuration data identified by the element > containing this attribute is merged with the configuration > at the corresponding level in the configuration datastore > identified by the target parameter. This is the default > behavior." > > The draft says that the element must be merged in the config but it > does not explain how. Is there a clear definition of merge for XML > elements ? merge is data-model specific. > Also the given examples silently assume that the "name" element is a > selection key. It should be explicit in the draft. > There is absolutely no data model naming scheme defined in netconf. I think these examples state that they are selecting by element called 'name'. > For example, let's imagine a data model where: > - the root element is "foo" > - foo must have a "name" child > - foo may have zero to two "bar" elements > - "bar" is a simpleType element > > Initial config: > > bla > bar1 > > > Request: > > bla > bar2 > > > Possible outputs: > > bla > bar2 > > > > bla > bar1 > bar2 > > > Under merge meaning is implicitely a combination of replace or create > operation ? > There is no clear separation between the selecting nodes and nodes > that must be updated. > Even with replace operation we have the problem since we don't know > which bar must be replaced. > > Anybody implementing has the same problems ? It is data model specific. Do you have suggestions for changing it? > > Another thing: we are planning to implement a new edit-config with > xpath, as a new capability. It will look like that: > > > > > > sel="/netconf/security/rbac/users/user[name='Alice']"> > > Alice > alicefoo > a2 > 100 > > > > > If the wg is interested to merge it to the standard xpath capability, > just request more details. > We believe that edit-config should be extended with XPath in a similar > way than get-config. You are using a nice clean XPath expression. Unfortunately, this is a small subset of the entire language. I think there are huge problems with setting or locking data items based on arbitrary Xpath expressions. > > Sorry for the long mail. > Thanks for your help. > Vincent > > > > 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 Jan 25 11:54:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1nv1-00074x-S5 for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 11:54: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 LAA29954 for ; Wed, 25 Jan 2006 11:53:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1njE-000L4S-5x for netconf-data@psg.com; Wed, 25 Jan 2006 16:42: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.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1njB-000L49-Fv for netconf@ops.ietf.org; Wed, 25 Jan 2006 16:42:37 +0000 Received: (qmail 3259 invoked from network); 25 Jan 2006 16:42:36 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 25 Jan 2006 16:42:36 -0000 Message-ID: <43D7AA7C.7010809@andybierman.com> Date: Wed, 25 Jan 2006 08:42:36 -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: validate References: <20060125.144702.48373382.mbj@tail-f.com> In-Reply-To: <20060125.144702.48373382.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >Hi, > >Here's another one where the text and schema differs. In the text for >the validate command, it says that the source parameter is the: > > Name of the configuration datastore being validated > >But the schema also allows for inline configurations like this: > > > > > inline config > > > >Should I assume that the text is right and the schema wrong? > > > This time the schema is right and the text is wrong. Inline validate is supposed to be supported. >/martin > > > Andy > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jan 25 14:21:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qD3-0004LA-Uo for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 14:21: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 OAA15228 for ; Wed, 25 Jan 2006 14:20:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1q6B-0003jj-Nz for netconf-data@psg.com; Wed, 25 Jan 2006 19: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=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.12.11.96] (helo=smtp007.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1q68-0003jL-Dy for netconf@ops.ietf.org; Wed, 25 Jan 2006 19:14:28 +0000 Received: (qmail 35372 invoked from network); 25 Jan 2006 19:14:26 -0000 Received: from unknown (HELO ?192.168.0.2?) (cridligv@212.194.114.217 with plain) by smtp007.mail.ukl.yahoo.com with SMTP; 25 Jan 2006 19:14:26 -0000 Message-ID: <43D7CEB4.9080904@loria.fr> Date: Wed, 25 Jan 2006 20:17:08 +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: [Fwd: Re: edit-config operation] Content-Type: multipart/mixed; boundary="------------040902020301010606080308" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------040902020301010606080308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------040902020301010606080308 Content-Type: message/rfc822; name="Re: edit-config operation" Content-Disposition: inline; filename="Re: edit-config operation" Message-ID: <43D7C95F.7010008@loria.fr> Date: Wed, 25 Jan 2006 19:54:23 +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: Andy Bierman Subject: Re: edit-config operation References: <43D79609.5050008@loria.fr> <43D7A992.2030605@andybierman.com> In-Reply-To: <43D7A992.2030605@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, > merge is data-model specific. I just need a clarification on how merge is working, which I didn't find in the draft. I am not sure to understand what you mean by "merge is data-model specific. ". Is merge behavior up to the implementor, or are there some general guidelines on what the merge is doing ? > It is data model specific. > Do you have suggestions for changing it? It would help a lot to explicitely state what data is to be created, deleted or replaced. I think one of these three operations must be explicitely present in each request. Specifying the key elements in the edit-config can help also. I understand "merge" as a way to hide the real operations (create, replace, delete). But it is ambiguous in some cases, even if you define a strict data model (see the examples). > You are using a nice clean XPath expression. > Unfortunately, this is a small subset of the entire language. > I think there are huge problems with setting or locking data items > based on arbitrary Xpath expressions. The XPath that I used is simple but it can be as complex as you want to. I don't see the problems that it could create. Can you explain more ? Vincent --------------040902020301010606080308-- ___________________________________________________________________________ Nouveau : tiliphonez moins cher avec Yahoo! Messenger ! Dicouvez les tarifs exceptionnels pour appeler la France et l'international. Tilichargez 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 Wed Jan 25 14:39:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qUJ-00027H-66 for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 14:39: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 OAA17354 for ; Wed, 25 Jan 2006 14:37:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1qNf-0004gE-U7 for netconf-data@psg.com; Wed, 25 Jan 2006 19:32: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=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.12.11.35] (helo=smtp004.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1qNd-0004fu-V9 for netconf@ops.ietf.org; Wed, 25 Jan 2006 19:32:34 +0000 Received: (qmail 9928 invoked from network); 25 Jan 2006 19:32:33 -0000 Received: from unknown (HELO ?192.168.0.2?) (cridligv@212.194.114.217 with plain) by smtp004.mail.ukl.yahoo.com with SMTP; 25 Jan 2006 19:32:32 -0000 Message-ID: <43D7D2F2.9080408@loria.fr> Date: Wed, 25 Jan 2006 20:35:14 +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: Andy Bierman , netconf@ops.ietf.org Subject: Re: edit-config operation References: <43D79609.5050008@loria.fr> <43D7A992.2030605@andybierman.com> <43D7C95F.7010008@loria.fr> <43D7CE59.6040104@andybierman.com> In-Reply-To: <43D7CE59.6040104@andybierman.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 OAA17354 Andy Bierman wrote: > Cridlig Vincent wrote: > >> Hi, >> >>> merge is data-model specific. >> >> >> >> I just need a clarification on how merge is working, which I didn't=20 >> find in the draft. >> I am not sure to understand what you mean by "merge is data-model=20 >> specific. ". Is merge behavior up to the implementor, or are there=20 >> some general guidelines on what the merge is doing ? > > > > This follows from the CLI. > First, it is obviously important to know how multiple > entries are distinguished and which fields need to be unique > in a particular naming scope. > > A data model for access control lists may merge entries differently > than a data model for assigning MAC addresses to an IP address. > >> >>> It is data model specific. >>> Do you have suggestions for changing it? >> >> >> >> It would help a lot to explicitely state what data is to be created,=20 >> deleted or replaced. I think one of these three operations must be=20 >> explicitely present in each request. >> Specifying the key elements in the edit-config can help also. >> >> I understand "merge" as a way to hide the real operations (create,=20 >> replace, delete). But it is ambiguous in some cases, even if you=20 >> define a strict data model (see the examples). > > > > Agreed. That's why I'm creating my own "internal" > data modeling language that deals with all these netconf details. > Merge could be automated with some additional data. > Standard algorithms like "first, last, natural-order, dont-care,=20 > user-defined" > can help. What would be great is an edit-config operation that is self-sufficient=20 to update the XML config. Just like XSLT is doing to transform a document to an XML output without=20 worrying about keys. > >> >>> You are using a nice clean XPath expression. >>> Unfortunately, this is a small subset of the entire language. >>> I think there are huge problems with setting or locking data items >>> based on arbitrary Xpath expressions. >> >> >> >> The XPath that I used is simple but it can be as complex as you want t= o. >> I don't see the problems that it could create. Can you explain more ? > > > > What if the expression can resolve to more than one node in the data=20 > model? > Do you pick one at random? Is the purpose of this to save space? > Using a path expression instead of the XML sub-tree does save space. If the number of selected nodes is higher than 1, they will be replaced=20 all (in case the operation is replace). This can happen also with=20 edit-config if the matching nodes match several nodes in the config. Not only it saves bandwidth, but it addresses a set of nodes=20 unambiguously and many people understand XPath. Vincent > > You understand that the instance documents will not likely carry instan= ce > naming and other semantic meta-data, along with the data itself. > This has been raised in the WG before. The schemas for those instance > documents are needed to implement netconf correctly. It has never > been a design goal of the WG for applications to be able to do real wor= k > with netconf with no understanding of the underlying data models. > =09 =09 =09 _________________________________________________________________________= __=20 Nouveau : t=E9l=E9phonez moins cher avec Yahoo! Messenger ! D=E9couvez le= s tarifs exceptionnels pour appeler la France et l'international. T=E9l=E9chargez 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 Wed Jan 25 15:01:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qpt-0004bR-VL for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 15:01:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19224 for ; Wed, 25 Jan 2006 15:00:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1qjv-00061T-5a for netconf-data@psg.com; Wed, 25 Jan 2006 19:55: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 1F1qju-00061C-0m for netconf@ops.ietf.org; Wed, 25 Jan 2006 19:55:34 +0000 Received: (qmail 13575 invoked from network); 25 Jan 2006 19:55:33 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 25 Jan 2006 19:55:33 -0000 Message-ID: <43D7D7B4.5050402@andybierman.com> Date: Wed, 25 Jan 2006 11:55: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: Cridlig Vincent CC: netconf@ops.ietf.org Subject: Re: edit-config operation References: <43D79609.5050008@loria.fr> <43D7A992.2030605@andybierman.com> <43D7C95F.7010008@loria.fr> <43D7CE59.6040104@andybierman.com> <43D7D2F2.9080408@loria.fr> In-Reply-To: <43D7D2F2.9080408@loria.fr> 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 PAA19224 Cridlig Vincent wrote: > Andy Bierman wrote: > >> Cridlig Vincent wrote: >> >>> Hi, >>> >>>> merge is data-model specific. >>> >>> >>> >>> >>> I just need a clarification on how merge is working, which I didn't=20 >>> find in the draft. >>> I am not sure to understand what you mean by "merge is data-model=20 >>> specific. ". Is merge behavior up to the implementor, or are there=20 >>> some general guidelines on what the merge is doing ? >> >> >> >> >> This follows from the CLI. >> First, it is obviously important to know how multiple >> entries are distinguished and which fields need to be unique >> in a particular naming scope. >> >> A data model for access control lists may merge entries differently >> than a data model for assigning MAC addresses to an IP address. >> >>> >>>> It is data model specific. >>>> Do you have suggestions for changing it? >>> >>> >>> >>> >>> It would help a lot to explicitely state what data is to be created,=20 >>> deleted or replaced. I think one of these three operations must be=20 >>> explicitely present in each request. >>> Specifying the key elements in the edit-config can help also. >>> >>> I understand "merge" as a way to hide the real operations (create,=20 >>> replace, delete). But it is ambiguous in some cases, even if you=20 >>> define a strict data model (see the examples). >> >> >> >> >> Agreed. That's why I'm creating my own "internal" >> data modeling language that deals with all these netconf details. >> Merge could be automated with some additional data. >> Standard algorithms like "first, last, natural-order, dont-care,=20 >> user-defined" >> can help. > > > > What would be great is an edit-config operation that is=20 > self-sufficient to update the XML config. > Just like XSLT is doing to transform a document to an XML output=20 > without worrying about keys. Sounds interesting. You should work up the details and implement it. Personally, I don't see NE device configuration as an XML document proble= m. I think it is more important to focus on the netconf, not on the XML. We=20 want NE device configuration data models to be static, canonical=20 representations of a conceptual datastore. But XSD and RelaxNG describe XML instance=20 documents, which to us means the on-the-wire encoding. This disconnect complicates=20 things. > > >> >>> >>>> You are using a nice clean XPath expression. >>>> Unfortunately, this is a small subset of the entire language. >>>> I think there are huge problems with setting or locking data items >>>> based on arbitrary Xpath expressions. >>> >>> >>> >>> >>> The XPath that I used is simple but it can be as complex as you want=20 >>> to. >>> I don't see the problems that it could create. Can you explain more ? >> >> >> >> >> What if the expression can resolve to more than one node in the data=20 >> model? >> Do you pick one at random? Is the purpose of this to save space? >> Using a path expression instead of the XML sub-tree does save space. > > > If the number of selected nodes is higher than 1, they will be=20 > replaced all (in case the operation is replace). This can happen also=20 > with edit-config if the matching nodes match several nodes in the confi= g. > Not only it saves bandwidth, but it addresses a set of nodes=20 > unambiguously and many people understand XPath. > I think it is worthwhile to explore further use of Xpath in netconf=20 operations. I'll send a separate email explaining more... > Vincent Andy > >> >> You understand that the instance documents will not likely carry=20 >> instance >> naming and other semantic meta-data, along with the data itself. >> This has been raised in the WG before. The schemas for those instance >> documents are needed to implement netconf correctly. It has never >> been a design goal of the WG for applications to be able to do real wo= rk >> with netconf with no understanding of the underlying data models. >> > > > =20 > > =20 > =20 > _______________________________________________________________________= ____=20 > Nouveau : t=E9l=E9phonez moins cher avec Yahoo! Messenger ! D=E9couvez = les=20 > tarifs exceptionnels pour appeler la France et l'international. > T=E9l=E9chargez 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 Wed Jan 25 15:21:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1r93-0003wz-JN for netconf-archive@megatron.ietf.org; Wed, 25 Jan 2006 15:21: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 PAA20467 for ; Wed, 25 Jan 2006 15:20:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1r3F-0007Cc-JQ for netconf-data@psg.com; Wed, 25 Jan 2006 20:15: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 [205.178.146.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1r3E-0007CO-PS for netconf@ops.ietf.org; Wed, 25 Jan 2006 20:15:33 +0000 Received: (qmail 30626 invoked from network); 25 Jan 2006 20:15:32 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 25 Jan 2006 20:15:32 -0000 Message-ID: <43D7DC63.70300@andybierman.com> Date: Wed, 25 Jan 2006 12:15:31 -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: How should we deal with experimental netconf work? 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 have an idea that may help those in the WG that believe standards based on real-world solutions are not that important. I have to clear it with Simon and the ADs first, but here goes... People with ideas for extensions should (hopefully) implement them, write them up in an Internet Draft, and propose them to the WG. We have a "netconf base" URI. We can also have a "netconf experimental" URI. (Yes, I know SMI has this already. We need it for the same reason.) The WG can then decide on new proposals: 1) no thanks 2) come back later with more details 3) develop it as Experimental first (decide on standard later) 4) charter it and develop it as a Proposed Standard This experimental branch (like in MIBs) would not be stable like a standard, but it is better than a vendor extension. Competitors in the same market will be reluctant to implement each other's proprietary extensions, but they will be able to agree in a WG to implement something as a "netconf experimental" extension. The bar for Experimental should be much lower than for Proposed Standard, in terms of initial proposal deployment, WG involvement and IESG review. Comments? 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 Jan 26 04:07:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F236E-0003MH-7w for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 04:07: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 EAA24968 for ; Thu, 26 Jan 2006 04:05:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F22vx-0004Bd-1p for netconf-data@psg.com; Thu, 26 Jan 2006 08:56:49 +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 1F22vv-0004BL-4R for netconf@ops.ietf.org; Thu, 26 Jan 2006 08:56:47 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 10AC362954 for ; Thu, 26 Jan 2006 09:56:46 +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 A9BA862954 for ; Thu, 26 Jan 2006 09:56:43 +0100 (CET) Message-ID: <43D88F67.8090702@loria.fr> Date: Thu, 26 Jan 2006 09:59:19 +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 Cc: netconf@ops.ietf.org Subject: Re: edit-config operation References: <43D79609.5050008@loria.fr> <43D7A992.2030605@andybierman.com> <43D7C95F.7010008@loria.fr> <43D7CE59.6040104@andybierman.com> <43D7D2F2.9080408@loria.fr> <43D7D7B4.5050402@andybierman.com> In-Reply-To: <43D7D7B4.5050402@andybierman.com> Content-Type: multipart/mixed; boundary="------------040105070904060003070104" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------040105070904060003070104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA24968 Hi, I specified in more details our #edit-config-xpath capability:=20 http://libresource.inria.fr/projects/ensuite/capabilities We are open to discussions to improve the syntax. Cheers, Vincent Andy Bierman wrote: > Cridlig Vincent wrote: > >> Andy Bierman wrote: >> >>> Cridlig Vincent wrote: >>> >>>> Hi, >>>> >>>>> merge is data-model specific. >>>> >>>> >>>> >>>> >>>> >>>> I just need a clarification on how merge is working, which I didn't=20 >>>> find in the draft. >>>> I am not sure to understand what you mean by "merge is data-model=20 >>>> specific. ". Is merge behavior up to the implementor, or are there=20 >>>> some general guidelines on what the merge is doing ? >>> >>> >>> >>> >>> >>> This follows from the CLI. >>> First, it is obviously important to know how multiple >>> entries are distinguished and which fields need to be unique >>> in a particular naming scope. >>> >>> A data model for access control lists may merge entries differently >>> than a data model for assigning MAC addresses to an IP address. >>> >>>> >>>>> It is data model specific. >>>>> Do you have suggestions for changing it? >>>> >>>> >>>> >>>> >>>> >>>> It would help a lot to explicitely state what data is to be=20 >>>> created, deleted or replaced. I think one of these three operations=20 >>>> must be explicitely present in each request. >>>> Specifying the key elements in the edit-config can help also. >>>> >>>> I understand "merge" as a way to hide the real operations (create,=20 >>>> replace, delete). But it is ambiguous in some cases, even if you=20 >>>> define a strict data model (see the examples). >>> >>> >>> >>> >>> >>> Agreed. That's why I'm creating my own "internal" >>> data modeling language that deals with all these netconf details. >>> Merge could be automated with some additional data. >>> Standard algorithms like "first, last, natural-order, dont-care,=20 >>> user-defined" >>> can help. >> >> >> >> >> What would be great is an edit-config operation that is=20 >> self-sufficient to update the XML config. >> Just like XSLT is doing to transform a document to an XML output=20 >> without worrying about keys. > > > > Sounds interesting. > You should work up the details and implement it. > > Personally, I don't see NE device configuration as an XML document=20 > problem. > I think it is more important to focus on the netconf, not on the XML.=20 > We want > NE device configuration data models to be static, canonical=20 > representations of > a conceptual datastore. But XSD and RelaxNG describe XML instance=20 > documents, > which to us means the on-the-wire encoding. This disconnect=20 > complicates things. > > >> >> >>> >>>> >>>>> You are using a nice clean XPath expression. >>>>> Unfortunately, this is a small subset of the entire language. >>>>> I think there are huge problems with setting or locking data items >>>>> based on arbitrary Xpath expressions. >>>> >>>> >>>> >>>> >>>> >>>> The XPath that I used is simple but it can be as complex as you=20 >>>> want to. >>>> I don't see the problems that it could create. Can you explain more = ? >>> >>> >>> >>> >>> >>> What if the expression can resolve to more than one node in the data=20 >>> model? >>> Do you pick one at random? Is the purpose of this to save space? >>> Using a path expression instead of the XML sub-tree does save space. >> >> >> >> If the number of selected nodes is higher than 1, they will be=20 >> replaced all (in case the operation is replace). This can happen also=20 >> with edit-config if the matching nodes match several nodes in the=20 >> config. >> Not only it saves bandwidth, but it addresses a set of nodes=20 >> unambiguously and many people understand XPath. >> > > I think it is worthwhile to explore further use of Xpath in netconf=20 > operations. > I'll send a separate email explaining more... > > >> Vincent > > > > Andy > >> >>> >>> You understand that the instance documents will not likely carry=20 >>> instance >>> naming and other semantic meta-data, along with the data itself. >>> This has been raised in the WG before. The schemas for those instanc= e >>> documents are needed to implement netconf correctly. It has never >>> been a design goal of the WG for applications to be able to do real=20 >>> work >>> with netconf with no understanding of the underlying data models. >>> >> >> >> =20 >> =20 >> ______________________________________________________________________= _____=20 >> Nouveau : t=E9l=E9phonez moins cher avec Yahoo! Messenger ! D=E9couvez= les=20 >> tarifs exceptionnels pour appeler la France et l'international. >> T=E9l=E9chargez sur http://fr.messenger.yahoo.com >> >> >> > > > --=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: --------------040105070904060003070104 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 --------------040105070904060003070104-- -- to unsubscribe send a message to netconf-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 Jan 26 05:05:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F240e-00066y-6C for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 05:05: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 FAA29722 for ; Thu, 26 Jan 2006 05:04:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F23tz-0007C4-UC for netconf-data@psg.com; Thu, 26 Jan 2006 09:58: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 [212.247.154.161] (helo=swip.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F23ty-0007Bp-Ea for netconf@ops.ietf.org; Thu, 26 Jan 2006 09:58:50 +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 99081622; Thu, 26 Jan 2006 10:58:46 +0100 Date: Thu, 26 Jan 2006 10:58:35 +0100 (CET) Message-Id: <20060126.105835.94576698.mbj@tail-f.com> To: vincent.cridlig@loria.fr Cc: netconf@ops.ietf.org Subject: Re: edit-config operation From: Martin Bjorklund In-Reply-To: <43D88F67.8090702@loria.fr> References: <43D7D2F2.9080408@loria.fr> <43D7D7B4.5050402@andybierman.com> <43D88F67.8090702@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 Hi, First of all, is it ok to discuss this on the list, or should we keep it off-line? Vincent Cridlig wrote: > I specified in more details our #edit-config-xpath capability: > http://libresource.inria.fr/projects/ensuite/capabilities > We are open to discussions to improve the syntax. This looks very good! I think it makes a lot of sense to separate the node selection expression from the data modification expressions. It makes edit-config less ambiguous and easier to understand. One added-value of this capability is that you can perform an operation on a set of nodes. This makes sense if you want to delete all instances which match a certain pattern, e.g. all with 2006-01-01. Another example might be if you want to disable all atm interfaces. But in order to do this, your "operation" attribute would have to support "merge" as well, so you could write: disabled But why can't the ordinary operation attribute be used? Then you would write disabled (actually in that example the operation could be omitted since the default 'merge' would do fine). or One drawback is probably (as Andy pointed out) that the cost of allowing arbitrary xpath expressions may be high. /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 Jan 26 06:53:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F25hF-0007p5-VE for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 06:53: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 GAA06766 for ; Thu, 26 Jan 2006 06:52:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F25bN-000D4Y-7q for netconf-data@psg.com; Thu, 26 Jan 2006 11:47:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [137.158.30.12] (helo=crglnx.uct.exp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F25bM-000D4I-Gv for netconf@ops.ietf.org; Thu, 26 Jan 2006 11:47:44 +0000 Received: from [10.128.1.91] (helo=ntanziw) by crglnx.uct.exp with smtp (Exim 4.50) id 1F25bK-0000zr-75 for netconf@ops.ietf.org; Thu, 26 Jan 2006 13:47:42 +0200 Message-ID: <020601c6226e$4f7dcfb0$5b01800a@ntanziw> From: "Ntanzi Carrilho" To: Subject: Netconf for network health/state monitoring Date: Thu, 26 Jan 2006 13:47:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0203_01C6227F.00E49850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0203_01C6227F.00E49850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Is there a study around that shows how any of the netconf = implementations performs when used for general network health/state monitoring? Also, is there a way to use netconf in a hierarchical management = scenario, where there are top level managers, mid level managers and the monitored nodes? Regards Ntanzi ------=_NextPart_000_0203_01C6227F.00E49850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi

Is there a study around that shows how any of the netconf = implementations
performs when used for general network health/state=20 monitoring?

Also, is there a way to use netconf in a hierarchical = management scenario,
where there are top level managers, mid level = managers=20 and the monitored
nodes?

Regards
Ntanzi
------=_NextPart_000_0203_01C6227F.00E49850-- -- to unsubscribe send a message to netconf-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 Jan 26 06:54:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F25hm-0008EZ-Jm for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 06:54: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 GAA06789 for ; Thu, 26 Jan 2006 06:52:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F25eU-000DJj-Fu for netconf-data@psg.com; Thu, 26 Jan 2006 11:50: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.56] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F25eT-000DJW-11 for netconf@ops.ietf.org; Thu, 26 Jan 2006 11:50:57 +0000 Received: (qmail 20202 invoked from network); 26 Jan 2006 11:50:56 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 26 Jan 2006 11:50:56 -0000 Message-ID: <43D8B79F.8050104@andybierman.com> Date: Thu, 26 Jan 2006 03:50:55 -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: vincent.cridlig@loria.fr, netconf@ops.ietf.org Subject: Re: edit-config operation References: <43D7D2F2.9080408@loria.fr> <43D7D7B4.5050402@andybierman.com> <43D88F67.8090702@loria.fr> <20060126.105835.94576698.mbj@tail-f.com> In-Reply-To: <20060126.105835.94576698.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Bjorklund wrote: >Hi, > >First of all, is it ok to discuss this on the list, or should we keep >it off-line? > > I think list traffic is light enough that this is okay. This is the sort of thing I had in mind when I sent the email about "netconf experimental". Actually, that does not have to be WG-controlled. It could be an IANA controlled (first-come, first-serve) registry. That way, anybody with enough ambition can create an extension that others may interoperate with. I knew when we added Xpath the the operations that this would happen. This is good though, to figure out all the costs, benefits, and pitfalls of this approach. Why I bet next you will be doing clever things like taking the output of your Xpath expression on and piping it somehow into a subsequent RPC, like multiple Xpath expressions on . Or you could add an attribute to (besides sel) called 'sel-target' so the target can be different from the Xpath target, and accomplish the same thing in 1 RPC. Definite power tool with the blade-guard off potential here. (But you can't cut any wood with the blade-guard in the way.) Andy > >Vincent Cridlig wrote: > > >>I specified in more details our #edit-config-xpath capability: >>http://libresource.inria.fr/projects/ensuite/capabilities >>We are open to discussions to improve the syntax. >> >> > >This looks very good! I think it makes a lot of sense to separate the >node selection expression from the data modification expressions. It >makes edit-config less ambiguous and easier to understand. > >One added-value of this capability is that you can perform an >operation on a set of nodes. This makes sense if you want to delete >all instances which match a certain pattern, e.g. all with >2006-01-01. Another example might be if you want to >disable all atm interfaces. But in order to do this, your "operation" >attribute would have to support "merge" as well, so you could write: > > > disabled > > >But why can't the ordinary operation attribute be used? Then you >would write > > > disabled > > >(actually in that example the operation could be omitted since the >default 'merge' would do fine). > >or > > sel="/interfaces/interface[type='atm']"> > > > >One drawback is probably (as Andy pointed out) that the cost of >allowing arbitrary xpath expressions may be high. > > > >/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 Jan 26 07:36:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26Md-00079f-5p for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 07:36: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 HAA09690 for ; Thu, 26 Jan 2006 07:35:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F26H0-000Fbd-M8 for netconf-data@psg.com; Thu, 26 Jan 2006 12:30: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F26Gz-000Fas-4z for netconf@ops.ietf.org; Thu, 26 Jan 2006 12:30:45 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QCUev21230 for ; Thu, 26 Jan 2006 07:30:41 -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: How should we deal with experimental netconf work? Date: Thu, 26 Jan 2006 07:30:38 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40694CD2D@zcarhxm2.corp.nortel.com> Thread-Topic: How should we deal with experimental netconf work? Thread-Index: AcYh7lMoq6g46+kFTzaqXIIeZdzBqAAhZtBw From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi My assumption would be that this work would be done in private namespace. What are the advantages and disadvantages of doing this in a shared commons?=20 I imagine if two vendors wanted to support the same experiment, then shared space would be good. I imagine though, that the shared experimental space would need to be managed as closely as real space wouldn't it? Would we ask IANA to do that? Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, January 25, 2006 3:16 PM To: Netconf (E-mail) Subject: How should we deal with experimental netconf work? Hi, I have an idea that may help those in the WG that believe standards based on real-world solutions are not that important. I have to clear it with Simon and the ADs first, but here goes... People with ideas for extensions should (hopefully) implement them, write them up in an Internet Draft, and propose them to the WG. We have a "netconf base" URI.=20 We can also have a "netconf experimental" URI. (Yes, I know SMI has this already. We need it for the same reason.) The WG can then decide on new proposals: 1) no thanks 2) come back later with more details 3) develop it as Experimental first (decide on standard later) 4) charter it and develop it as a Proposed Standard This experimental branch (like in MIBs) would not be stable like a standard, but it is better than a vendor extension. Competitors in the same market will be reluctant to implement each other's proprietary extensions, but they will be able to agree in a WG to implement something as a "netconf experimental" extension. The bar for Experimental should be much lower than for Proposed Standard, in terms of initial proposal deployment, WG involvement and IESG review. Comments? Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 26 07:45:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26VX-0001my-6r for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 07:45: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 HAA10128 for ; Thu, 26 Jan 2006 07:44:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F26Qa-000G9x-OU for netconf-data@psg.com; Thu, 26 Jan 2006 12:40: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F26Qa-000G9h-2U for netconf@ops.ietf.org; Thu, 26 Jan 2006 12:40:40 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QCeb912769 for ; Thu, 26 Jan 2006 07:40:37 -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 Event: Issue #1: To RCP or Not to RPC Date: Thu, 26 Jan 2006 07:40:33 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40694CD38@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf Event: Issue #1: To RCP or Not to RPC Thread-Index: AcYhdrf7txYRXw8sSQGh+bFXke6w3AA/gevA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Ok, the sense that I'm getting from this thread is that people are invested in the analogy of the tag to a traditional RPC. It's not useful to open up that debate, so I propose just accepting it and removing one of our three options off the table to resolve this issue. This leaves us with two: 1) Have a wrapper around the called something like which contains the message ID similar to the tag and also can appear in the same box in the Netconf Layer Picture. 2) Compress the two layers and move the message ID into the and replace the Netconf Layer Picture with a more complicated one that accurately shows this change in layers (Like the one Andy suggested at one point). 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 Thu Jan 26 09:31:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F289g-0000KR-QN for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 09:31: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 JAA20172 for ; Thu, 26 Jan 2006 09:29:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F280M-000LYf-W6 for netconf-data@psg.com; Thu, 26 Jan 2006 14:21: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=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 1F280K-000LYS-CH for netconf@ops.ietf.org; Thu, 26 Jan 2006 14:21:40 +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 97628639 for netconf@ops.ietf.org; Thu, 26 Jan 2006 15:21:38 +0100 Date: Thu, 26 Jan 2006 15:21:27 +0100 (CET) Message-Id: <20060126.152127.89415022.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: lock on candidate 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, Another detail. Section 8.3.5.1. talks about lock on the candidate. It says: To facilitate easy recovery, any outstanding changes are discarded when the lock is released What does 'discard' mean here? Does it mean the same as , which copies the *current* running to the candidate, or does it mean the state the candidate was in before the lock was set? /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 Jan 26 09:48:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F28Q9-0005Xq-AL for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 09:48: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 JAA21790 for ; Thu, 26 Jan 2006 09:46:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F28KT-000MdQ-Vu for netconf-data@psg.com; Thu, 26 Jan 2006 14:42: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F28KT-000MdA-6S for netconf@ops.ietf.org; Thu, 26 Jan 2006 14:42:29 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QEgO910870 for ; Thu, 26 Jan 2006 09:42:25 -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 for network health/state monitoring Date: Thu, 26 Jan 2006 09:42:22 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4069BB214@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf for network health/state monitoring Thread-Index: AcYib5EIZGu83xpAQNuijUailka66gAFQwMw From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi =20 For me, I think it's a bit early to draw a general conclusions from what I've seen from people trying to do general network health/state monitoring. I'm tempted, but I'll hold off until I am sure what problems are real and which are just anticipated. =20 As far as the hierarchical management scenario, I am seeing much more interest in other XML-based network management solution for the manager to manager interface than in using Netconf there. But, note that is the same thing I saw with SNMP, with the exception of one particular product family. Others may have different experiences. =20 Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Ntanzi Carrilho Sent: Thursday, January 26, 2006 6:47 AM To: netconf@ops.ietf.org Subject: Netconf for network health/state monitoring Hi Is there a study around that shows how any of the netconf implementations performs when used for general network health/state monitoring? Also, is there a way to use netconf in a hierarchical management scenario, where there are top level managers, mid level managers and the monitored nodes? Regards Ntanzi -- to unsubscribe send a message to netconf-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 Jan 26 10:19:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F28to-0001CH-9q for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 10:19: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 KAA24783 for ; Thu, 26 Jan 2006 10:17:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F28oN-000OPv-Ds for netconf-data@psg.com; Thu, 26 Jan 2006 15: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 [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F28oL-000OPj-QO for netconf@ops.ietf.org; Thu, 26 Jan 2006 15:13:22 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9B72D628C8; Thu, 26 Jan 2006 16:13:17 +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 B44AE628C8; Thu, 26 Jan 2006 16:13:14 +0100 (CET) Message-ID: <43D8E7A5.9060102@loria.fr> Date: Thu, 26 Jan 2006 16:15:49 +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: Andy Bierman , netconf@ops.ietf.org Subject: Re: edit-config operation References: <43D7D2F2.9080408@loria.fr> <43D7D7B4.5050402@andybierman.com> <43D88F67.8090702@loria.fr> <20060126.105835.94576698.mbj@tail-f.com> <43D8B79F.8050104@andybierman.com> In-Reply-To: <43D8B79F.8050104@andybierman.com> Content-Type: multipart/mixed; boundary="------------020605050004040400030604" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------020605050004040400030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andy Bierman wrote: > Why I bet next you will be doing clever things like taking > the output of your Xpath expression on > and piping it somehow into a subsequent RPC, like multiple > Xpath expressions on . > Or you could add an attribute to (besides sel) > called 'sel-target' so the target can be different > from the Xpath target, and accomplish the same thing in 1 RPC. > > Definite power tool with the blade-guard off potential here. > (But you can't cut any wood with the blade-guard in the way.) There is an obvious solution to not apply the XPath to the whole running configuration. Example: Alice alicefoo 1. Find the namespace of the element that will be created or replaced (here "my:own:namespace:users") 2. Query only the elements related to that namespace in order to build a sub document (Here it will just build a document containing the users) 3. Apply the XPath on it 4. Check that the user does not exist under the nodes selected 5. Create the user on your system It scales with the number of namespaces (the number of sub-model of your config). Namespaces are very useful to discriminate between nodes. Vincent --------------020605050004040400030604 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 --------------020605050004040400030604-- -- to unsubscribe send a message to netconf-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 Jan 26 11:33:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A3Q-00071k-0d for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 11:33: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 LAA02197 for ; Thu, 26 Jan 2006 11:31:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F29y0-0002ul-1x for netconf-data@psg.com; Thu, 26 Jan 2006 16:27: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 [205.178.146.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F29xy-0002uV-Uw for netconf@ops.ietf.org; Thu, 26 Jan 2006 16:27:23 +0000 Received: (qmail 10676 invoked from network); 26 Jan 2006 16:27:22 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 26 Jan 2006 16:27:22 -0000 Message-ID: <43D8F869.5010107@andybierman.com> Date: Thu, 26 Jan 2006 08:27:21 -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: netconf notification transport 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, Phil brought up some transport issues again, that I think we should find out some opinions, one way or the other. 1) Multi-use session Is it important that a manager be able to issue calls and receive messages within the same session? The other option (Single-use session) implies that the manager will establish multiple single purpose sessions instead. As Phil pointed out, if single-use is okay, then the manager can simply make a 'start-receiving-notifications' RPC call that never finishes (usually until the manager shuts down the session). 2) Multiple channels and Multiple Connections Should we try to bring back this concept? Wasn't this the main reason we picked BEEP in the first place? Is the BEEP mapping that relevant without it? This issue is only relevant if multi-use sessions are required. 3) Application Acks and Reverse RPCs As Phil and I pointed out in emails, a notification with an application-ack is really just another method, but from the agent to the manager. It might be simpler to define how to reverse the flow for notification purposes, rather than redefining the and elements. Should this feature be dropped, capability-based, or mandatory? If kept, how should it be done? 4) Any More Transport Issues?? 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 Jan 26 11:33:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A3Q-00071w-Bj for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 11:33: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 LAA02196 for ; Thu, 26 Jan 2006 11:31:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2A06-00030i-4u for netconf-data@psg.com; Thu, 26 Jan 2006 16:29: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 [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 1F2A05-00030W-Gn for netconf@ops.ietf.org; Thu, 26 Jan 2006 16:29:33 +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 k0QGTU559839; Thu, 26 Jan 2006 08:29:30 -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 k0QGTP541617; Thu, 26 Jan 2006 08:29:25 -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 k0QGYfYE097595; Thu, 26 Jan 2006 11:34:41 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200601261634.k0QGYfYE097595@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: lock on candidate In-Reply-To: Your message of "Thu, 26 Jan 2006 15:21:27 +0100." <20060126.152127.89415022.mbj@tail-f.com> Date: Thu, 26 Jan 2006 11:34:41 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Yes, all outstanding changes are discarded, which effectively restores the candidate to the current running config. Thanks, Phil Martin Bjorklund writes: >Hi, > >Another detail. Section 8.3.5.1. talks about lock on the candidate. >It says: > > To facilitate easy recovery, any outstanding changes are discarded > when the lock is released > >What does 'discard' mean here? Does it mean the same as >, which copies the *current* running to the >candidate, or does it mean the state the candidate was in before the >lock was set? > > >/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 Jan 26 11:49:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AJD-0002m6-2N for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 11:49: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 LAA03621 for ; Thu, 26 Jan 2006 11:47:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2AEw-0003xg-OS for netconf-data@psg.com; Thu, 26 Jan 2006 16:44:54 +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 1F2AEv-0003xU-BL for netconf@ops.ietf.org; Thu, 26 Jan 2006 16:44:53 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4EB2D4F0001 for ; Thu, 26 Jan 2006 17:44:52 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 17:44:52 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 17:44:51 +0100 Message-ID: <43D8FC82.9000801@ericsson.com> Date: Thu, 26 Jan 2006 17:44:50 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Re: netconf notification transport issues References: <43D8F869.5010107@andybierman.com> In-Reply-To: <43D8F869.5010107@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2006 16:44:51.0154 (UTC) FILETIME=[D3910320:01C62297] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Someone brought up the scenario that one netconf management system might supervise many (thousands) nodes. In this case requiring the manager to have 2 instead of one sessions for each node might be a problem. What is the problem actually with multi-use ? (The advantage of having fewer sessions is clear.) Even if we have multi-use sessions do we really need multiple channels ? Why ? Having a never ending RPC call that sound as a strange use of the RPC concept for me also someone told me on this list that one RPC call can only get ONE reply. Is that so ? regards Balazs Andy Bierman wrote: > Hi, > > Phil brought up some transport issues again, that I think we should > find out some opinions, one way or the other. > > 1) Multi-use session > > Is it important that a manager be able to issue calls and > receive messages within the same session? > > The other option (Single-use session) implies that the manager > will establish multiple single purpose sessions instead. > > As Phil pointed out, if single-use is okay, then the manager can > simply make a 'start-receiving-notifications' RPC call that > never finishes (usually until the manager shuts down the session). > > > 2) Multiple channels and Multiple Connections > > Should we try to bring back this concept? > Wasn't this the main reason we picked BEEP in the first place? > Is the BEEP mapping that relevant without it? > This issue is only relevant if multi-use sessions are required. > > > 3) Application Acks and Reverse RPCs > > As Phil and I pointed out in emails, a notification with an > application-ack is really just another method, but > from the agent to the manager. It might be simpler to define > how to reverse the flow for notification purposes, rather > than redefining the and elements. > > Should this feature be dropped, capability-based, or mandatory? > If kept, how should it be done? > > > 4) Any More Transport Issues?? > > 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: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager 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 Jan 26 12:13:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AgO-0004A0-FH for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 12:13: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 MAA05560 for ; Thu, 26 Jan 2006 12:11:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Ab8-0005Ge-An for netconf-data@psg.com; Thu, 26 Jan 2006 17:07: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=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 1F2Ab7-0005GR-Cy for netconf@ops.ietf.org; Thu, 26 Jan 2006 17:07:49 +0000 Received: (qmail 29811 invoked from network); 26 Jan 2006 17:07:48 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr6.mgt.bos.netsol.com with SMTP; 26 Jan 2006 17:07:48 -0000 Message-ID: <43D901E4.1090308@andybierman.com> Date: Thu, 26 Jan 2006 09:07:48 -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 (E-mail)" Subject: Re: netconf notification transport issues References: <43D8F869.5010107@andybierman.com> <43D8FC82.9000801@ericsson.com> In-Reply-To: <43D8FC82.9000801@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: > Hello, > Someone brought up the scenario that one netconf management system > might supervise many (thousands) nodes. In this case requiring the > manager to have 2 instead of one sessions for each node might be a > problem. > > What is the problem actually with multi-use ? (The advantage of having > fewer sessions is clear.) Even if we have multi-use sessions do we > really need multiple channels ? Why ? > It is a complexity tradeoff, not a problem. I think the WG wants multi-use sessions, but I want to make sure. The point of multiple channels or connections per session is too keep notifications and rpcs separate. If they share, they are serialized. So let's say your application is dumping the entire config on a huge router -- a that takes 28 minutes to complete. Let's also say that a one of the power supplies on that router freaks out and fries 3 daughter-cards at once, 30 seconds after this starts. That means you have a major outage for at least 27.5 minutes before you know about it. Not exactly how async notifications are meant to be used. This is why you really don't want to do RPCs and receive notifications on the message path, if you care about fault response time. Andy > Having a never ending RPC call that sound as a strange use of the RPC > concept for me also someone told me on this list that one RPC call can > only get ONE reply. Is that so ? > > regards Balazs > > Andy Bierman wrote: > >> Hi, >> >> Phil brought up some transport issues again, that I think we should >> find out some opinions, one way or the other. >> >> 1) Multi-use session >> >> Is it important that a manager be able to issue calls and >> receive messages within the same session? >> >> The other option (Single-use session) implies that the manager >> will establish multiple single purpose sessions instead. >> >> As Phil pointed out, if single-use is okay, then the manager can >> simply make a 'start-receiving-notifications' RPC call that >> never finishes (usually until the manager shuts down the session). >> >> >> 2) Multiple channels and Multiple Connections >> >> Should we try to bring back this concept? >> Wasn't this the main reason we picked BEEP in the first place? >> Is the BEEP mapping that relevant without it? >> This issue is only relevant if multi-use sessions are required. >> >> >> 3) Application Acks and Reverse RPCs >> >> As Phil and I pointed out in emails, a notification with an >> application-ack is really just another method, but >> from the agent to the manager. It might be simpler to define >> how to reverse the flow for notification purposes, rather >> than redefining the and elements. >> >> Should this feature be dropped, capability-based, or mandatory? >> If kept, how should it be done? >> >> >> 4) Any More Transport Issues?? >> >> Andy >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 26 12:20:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Amw-0006dd-Eb for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 12:20: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 MAA06517 for ; Thu, 26 Jan 2006 12:18:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Ahv-0005jj-87 for netconf-data@psg.com; Thu, 26 Jan 2006 17:14: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Aht-0005jP-5h for netconf@ops.ietf.org; Thu, 26 Jan 2006 17:14:49 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QHEkJ26945 for ; Thu, 26 Jan 2006 12:14:46 -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 notification transport issues Date: Thu, 26 Jan 2006 12:14:43 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4069BB5B8@zcarhxm2.corp.nortel.com> Thread-Topic: netconf notification transport issues Thread-Index: AcYillV3+/tfhKolRgO64CTzfdSFIwAA35Zw From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi 1) Multi-use session Is it important that a manager be able to issue calls and receive messages within the same session? The other option (Single-use session) implies that the manager will establish multiple single purpose sessions instead. As Phil pointed out, if single-use is okay, then the manager can simply make a 'start-receiving-notifications' RPC call that never finishes (usually until the manager shuts down the session). This is a design alternative that we (internal to my organization) brought up and rejected early on in the design process. One disadvantage is, as you have noted, you can't do synchronous and asynchronous communication on the same connection and there are times you want to do that. Also, you can't run more than one notification stream on the same connection, and again there are times you want to do that (event replay being a big one). Also, questions were raised on the ability to process as you go if the receiver is looking for a complete XML document. There may have been other reasons this was rejected as well. I'll try and see if we captured more reasoning. 2) Multiple channels and Multiple Connections Should we try to bring back this concept? Wasn't this the main reason we picked BEEP in the first place? Is the BEEP mapping that relevant without it? This issue is only relevant if multi-use sessions are required. I think we eventually need to go there, but it can be decoupled from this discussion. We can wait and tackle it later when it is clear that we absolutely need it - ie, people are maxing out their connections and need to multi-plex. 3) Application Acks and Reverse RPCs As Phil and I pointed out in emails, a notification with an application-ack is really just another method, but from the agent to the manager. =20 Yes, I said the same thing in my argument for why having the extra wrapper around the notification was good future proofing. I'm not sure it helps in the case of unacknowledged events. It might be simpler to define how to reverse the flow for notification purposes, rather than redefining the and elements. Should this feature be dropped, capability-based, or mandatory? If kept, how should it be done? I don't see how it supports notifications, but I think Eliot wanted it for call-home. 4) Any More Transport Issues?? From my perspective, the weakest part of the current draft is its mappings to the application protocols. I would love to see some of the people who wrote the application protocol mapping documents review those sections. 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 Thu Jan 26 12:23:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AqC-0003gy-Ug for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 12:23:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06884 for ; Thu, 26 Jan 2006 12:21:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Akq-0005yd-At for netconf-data@psg.com; Thu, 26 Jan 2006 17:17: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Akp-0005yO-D3 for netconf@ops.ietf.org; Thu, 26 Jan 2006 17:17:51 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QHHm920354 for ; Thu, 26 Jan 2006 12:17:48 -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 notification transport issues Date: Thu, 26 Jan 2006 12:17:45 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4069BB5BF@zcarhxm2.corp.nortel.com> Thread-Topic: netconf notification transport issues Thread-Index: AcYim/jndXYYqhAKSoKm6584tvkC6wAAC3OA From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi There are cases when you want to have your synchronous commands on the same connection as your asynchronous one. This obviously does not imply you always want to do this. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, January 26, 2006 12:08 PM To: Balazs Lengyel Cc: Netconf (E-mail) Subject: Re: netconf notification transport issues Balazs Lengyel wrote: > Hello, > Someone brought up the scenario that one netconf management system > might supervise many (thousands) nodes. In this case requiring the=20 > manager to have 2 instead of one sessions for each node might be a=20 > problem. > > What is the problem actually with multi-use ? (The advantage of having > fewer sessions is clear.) Even if we have multi-use sessions do we=20 > really need multiple channels ? Why ? > It is a complexity tradeoff, not a problem. I think the WG wants multi-use sessions, but I want to make sure. The point of multiple channels or connections per session is too keep notifications and rpcs separate. If they share, they are serialized. So let's say your application is dumping the entire config on a huge router -- a that takes 28 minutes to complete. Let's also say=20 that a one of the power supplies on that router freaks out and fries 3=20 daughter-cards at once, 30 seconds after this starts. That means you have=20 a major outage for at least 27.5 minutes before you know about it. Not exactly how async notifications are meant to be used. This is why you really don't want to do RPCs and receive notifications=20 on the message path, if you care about fault response time. Andy > Having a never ending RPC call that sound as a strange use of the RPC=20 > concept for me also someone told me on this list that one RPC call can > only get ONE reply. Is that so ? > > regards Balazs > > Andy Bierman wrote: > >> Hi, >> >> Phil brought up some transport issues again, that I think we should >> find out some opinions, one way or the other. >> >> 1) Multi-use session >> >> Is it important that a manager be able to issue calls and >> receive messages within the same session? >> >> The other option (Single-use session) implies that the manager >> will establish multiple single purpose sessions instead. >> >> As Phil pointed out, if single-use is okay, then the manager can >> simply make a 'start-receiving-notifications' RPC call that >> never finishes (usually until the manager shuts down the session). >> >> >> 2) Multiple channels and Multiple Connections >> >> Should we try to bring back this concept? >> Wasn't this the main reason we picked BEEP in the first place? >> Is the BEEP mapping that relevant without it? >> This issue is only relevant if multi-use sessions are required. >> >> >> 3) Application Acks and Reverse RPCs >> >> As Phil and I pointed out in emails, a notification with an >> application-ack is really just another method, but >> from the agent to the manager. It might be simpler to define >> how to reverse the flow for notification purposes, rather >> than redefining the and elements. >> >> Should this feature be dropped, capability-based, or mandatory? >> If kept, how should it be done? >> >> >> 4) Any More Transport Issues?? >> >> Andy >> >> >> --=20 >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-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 Jan 26 12:47:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BDl-0004ic-L8 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 12:47:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08932 for ; Thu, 26 Jan 2006 12:46:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2B8X-0007Qq-BG for netconf-data@psg.com; Thu, 26 Jan 2006 17:42: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.52] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2B8W-0007Qe-9z for netconf@ops.ietf.org; Thu, 26 Jan 2006 17:42:20 +0000 Received: (qmail 17795 invoked from network); 26 Jan 2006 17:42:19 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr2.mgt.bos.netsol.com with SMTP; 26 Jan 2006 17:42:19 -0000 Message-ID: <43D909FA.5020005@andybierman.com> Date: Thu, 26 Jan 2006 09:42: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: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: netconf notification transport issues References: <713043CE8B8E1348AF3C546DBE02C1B4069BB5BF@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4069BB5BF@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 > >There are cases when you want to have your synchronous commands on the >same connection as your asynchronous one. This obviously does not imply >you always want to do this. > > Agreed. That's why I specifically said 'fault'. (I tried to remind people which problem-space really matters, and why netconf is much more than an XML document problem.) I like the subscribe-model that is in the current draft. It allows for subscribing to notifications for eventClass='fault' separately from everything else. You could call this RPC multiple times, but there needs to be a way to tell the agent to use a separate message path somehow. The transport details need to be resolved of course. >Sharon > > Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Thursday, January 26, 2006 12:08 PM >To: Balazs Lengyel >Cc: Netconf (E-mail) >Subject: Re: netconf notification transport issues > > >Balazs Lengyel wrote: > > > >>Hello, >>Someone brought up the scenario that one netconf management system >>might supervise many (thousands) nodes. In this case requiring the >>manager to have 2 instead of one sessions for each node might be a >>problem. >> >>What is the problem actually with multi-use ? (The advantage of having >>fewer sessions is clear.) Even if we have multi-use sessions do we >>really need multiple channels ? Why ? >> >> >> > >It is a complexity tradeoff, not a problem. >I think the WG wants multi-use sessions, but I want to make sure. >The point of multiple channels or connections per session is too >keep notifications and rpcs separate. If they share, they are >serialized. > > >So let's say your application is dumping the entire config on a huge >router > -- a that takes 28 minutes to complete. Let's also say >that a >one of the power supplies on that router freaks out and fries 3 >daughter-cards >at once, 30 seconds after this starts. That means you have >a major >outage for at least 27.5 minutes before you know about it. Not exactly >how >async notifications are meant to be used. > >This is why you really don't want to do RPCs and receive notifications >on the >message path, if you care about fault response time. > >Andy > > > >>Having a never ending RPC call that sound as a strange use of the RPC >>concept for me also someone told me on this list that one RPC call can >> >> > > > >>only get ONE reply. Is that so ? >> >>regards Balazs >> >>Andy Bierman wrote: >> >> >> >>>Hi, >>> >>>Phil brought up some transport issues again, that I think we should >>>find out some opinions, one way or the other. >>> >>>1) Multi-use session >>> >>> Is it important that a manager be able to issue calls and >>> receive messages within the same session? >>> >>> The other option (Single-use session) implies that the manager >>> will establish multiple single purpose sessions instead. >>> >>> As Phil pointed out, if single-use is okay, then the manager can >>> simply make a 'start-receiving-notifications' RPC call that >>> never finishes (usually until the manager shuts down the session). >>> >>> >>>2) Multiple channels and Multiple Connections >>> >>> Should we try to bring back this concept? >>> Wasn't this the main reason we picked BEEP in the first place? >>> Is the BEEP mapping that relevant without it? >>> This issue is only relevant if multi-use sessions are required. >>> >>> >>>3) Application Acks and Reverse RPCs >>> >>> As Phil and I pointed out in emails, a notification with an >>> application-ack is really just another method, but >>> from the agent to the manager. It might be simpler to define >>> how to reverse the flow for notification purposes, rather >>> than redefining the and elements. >>> >>> Should this feature be dropped, capability-based, or mandatory? >>> If kept, how should it be done? >>> >>> >>>4) Any More Transport Issues?? >>> >>>Andy >>> >>> >>>-- >>>to unsubscribe send a message to netconf-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >>> >> >> > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-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 Jan 26 13:18:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bhy-0002nV-68 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 13:18: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 NAA11895 for ; Thu, 26 Jan 2006 13:17:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Bd5-0009FS-0b for netconf-data@psg.com; Thu, 26 Jan 2006 18:13: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 1F2Bd4-0009FD-7m for netconf@ops.ietf.org; Thu, 26 Jan 2006 18:13:54 +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 k0QIDe561331; Thu, 26 Jan 2006 10:13:40 -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 k0QIDY559031; Thu, 26 Jan 2006 10:13:34 -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 k0QIIpYE097878; Thu, 26 Jan 2006 13:18:51 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200601261818.k0QIIpYE097878@idle.juniper.net> To: "Sharon Chisholm" cc: "Netconf \(E-mail\)" Subject: Re: netconf notification transport issues In-Reply-To: Your message of "Thu, 26 Jan 2006 12:17:45 EST." <713043CE8B8E1348AF3C546DBE02C1B4069BB5BF@zcarhxm2.corp.nortel.com> Date: Thu, 26 Jan 2006 13:18:51 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Sharon Chisholm" writes: >There are cases when you want to have your synchronous commands on the >same connection as your asynchronous one. This obviously does not imply >you always want to do this. Can you give details or use cases? 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 Thu Jan 26 13:30:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bt3-0005xj-M8 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 13:30:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12786 for ; Thu, 26 Jan 2006 13:28:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2BoO-000A16-MR for netconf-data@psg.com; Thu, 26 Jan 2006 18:25:36 +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 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2BoN-000A0l-O3 for netconf@ops.ietf.org; Thu, 26 Jan 2006 18:25:35 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 26 Jan 2006 10:25:35 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0QIPTjv027798; Thu, 26 Jan 2006 10:25:30 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 10:25:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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 notification transport issues Date: Thu, 26 Jan 2006 10:25:27 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0149A622@xmb-sjc-223.amer.cisco.com> Thread-Topic: netconf notification transport issues Thread-Index: AcYileOeCOzx4R9LRrisgLRkDEnYHgACdtQQ From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 26 Jan 2006 18:25:29.0678 (UTC) FILETIME=[E2CEA6E0:01C622A5] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, January 26, 2006 9:27 AM > To: Netconf (E-mail) > Subject: netconf notification transport issues >=20 > Hi, >=20 > Phil brought up some transport issues again, that I think we=20 > should find out some opinions, one way or the other. >=20 > 1) Multi-use session >=20 > Is it important that a manager be able to issue calls and > receive messages within the same session? >=20 > The other option (Single-use session) implies that the manager > will establish multiple single purpose sessions instead. >=20 > As Phil pointed out, if single-use is okay, then the manager can > simply make a 'start-receiving-notifications' RPC call that > never finishes (usually until the manager shuts down the session). HT: I think that both of the options above should be supported. The client should be allowed to decide whether to setup multiple dedicated sessions or a multi-purpose one. By doing this you are providing the same (similar) capabilities over communication protocols with different properties (e.g. BEEP, SSH).=20 BTW, since Andy likes implementations... this is what we chose to do.=20 >=20 >=20 > 2) Multiple channels and Multiple Connections >=20 > Should we try to bring back this concept? HT: Yes - unless people think that BEEP is not going anywhere. Maybe we should find out who is implementing/using BEEP.=20 > Wasn't this the main reason we picked BEEP in the first place? HT: AFAIK yes.=20 > Is the BEEP mapping that relevant without it? HT: I don't think so > This issue is only relevant if multi-use sessions are required. >=20 >=20 > 3) Application Acks and Reverse RPCs >=20 > As Phil and I pointed out in emails, a notification with an > application-ack is really just another method, but > from the agent to the manager. It might be simpler to define > how to reverse the flow for notification purposes, rather > than redefining the and elements. >=20 > Should this feature be dropped, capability-based, or mandatory? HT: I think it should be kept but made capability-based. This will allow vendors to support the capability based on demands.=20 > If kept, how should it be done? HT: This goes back to the previous discussion on one-way-msg. 1) Choosing to add a new message (unack'd) and re-using the (ack'd) preserves the message structure=20 (i.e. the info in the ), also preserves the protocol stack, but semantics (reply or no reply) are in the rpc layer only. =20 2) If the rpc layer is removed then the semantics (reply/no reply) are put into the message itself as well as any other information previously under the rpc portion of the message.=20 The third option and I think this is what you suggested before is to maintain the put the=20 notification semantics in the message itself and have the extra message exchange.=20 If with no reply is allowed then I'd go w/ #3. The extra message is ok for people wanting confirmed notifications Otherwise it is a toss up between #1 and #2. =20 >=20 >=20 > 4) Any More Transport Issues?? >=20 > Andy >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 26 13:30:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bt8-0005zY-1T for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 13:30: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 NAA12789 for ; Thu, 26 Jan 2006 13:28:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Bor-000A3p-4r for netconf-data@psg.com; Thu, 26 Jan 2006 18:26:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 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 1F2Boo-000A3a-NS for netconf@ops.ietf.org; Thu, 26 Jan 2006 18:26:02 +0000 Received: from pc6 (1Cust119.tnt29.lnd3.gbr.da.uu.net [62.188.120.119]) by ranger.systems.pipex.net (Postfix) with SMTP id 03327E000328; Thu, 26 Jan 2006 18:25:58 +0000 (GMT) Message-ID: <025301c6229d$7f4cfe80$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Andy Bierman" , "Netconf (E-mail)" References: <43D7DC63.70300@andybierman.com> Subject: Re: How should we deal with experimental netconf work? Date: Thu, 26 Jan 2006 18:23: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 The trick that SNMP failed to solve was how to amend all the OIDs in the debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without introducing any errors. I see this as the reason for the lack of use of SNMP experimental. So the question is, can this problem be avoided in XML? Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Netconf (E-mail)" Sent: Wednesday, January 25, 2006 9:15 PM Subject: How should we deal with experimental netconf work? > Hi, > > I have an idea that may help those in the WG that believe > standards based on real-world solutions are not that important. > I have to clear it with Simon and the ADs first, but here goes... > > People with ideas for extensions should (hopefully) implement them, write > them up in an Internet Draft, and propose them to the WG. > > We have a "netconf base" URI. > We can also have a "netconf experimental" URI. > (Yes, I know SMI has this already. We need it for the same reason.) > > The WG can then decide on new proposals: > 1) no thanks > 2) come back later with more details > 3) develop it as Experimental first (decide on standard later) > 4) charter it and develop it as a Proposed Standard > > This experimental branch (like in MIBs) would not be stable > like a standard, but it is better than a vendor extension. > Competitors in the same market will be reluctant to implement > each other's proprietary extensions, but they will be able to > agree in a WG to implement something as a "netconf experimental" extension. > > The bar for Experimental should be much lower than for Proposed Standard, > in terms of initial proposal deployment, WG involvement and IESG review. > > Comments? > > 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 Jan 26 13:52:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CEH-0007YA-Vv for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 13:52: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 NAA15271 for ; Thu, 26 Jan 2006 13:50:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2C9R-000BVx-AM for netconf-data@psg.com; Thu, 26 Jan 2006 18:47: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,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2C9Q-000BVk-8H for netconf@ops.ietf.org; Thu, 26 Jan 2006 18:47:20 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QIlH910018 for ; Thu, 26 Jan 2006 13:47:17 -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: How should we deal with experimental netconf work? Date: Thu, 26 Jan 2006 13:46:55 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4069BB722@zcarhxm2.corp.nortel.com> Thread-Topic: How should we deal with experimental netconf work? Thread-Index: AcYiprr8R4d4bJMwTEWCqRVTNFQ+LQAAfZrQ From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I think you would just have to switch the namespace when it moved. I think that makes it a bit cleaner than with SNMP, but still potentially a problem. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Tom Petch Sent: Thursday, January 26, 2006 12:24 PM To: Andy Bierman; Netconf (E-mail) Subject: Re: How should we deal with experimental netconf work? The trick that SNMP failed to solve was how to amend all the OIDs in the debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without introducing any errors. I see this as the reason for the lack of use of SNMP experimental. So the question is, can this problem be avoided in XML? Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Netconf (E-mail)" Sent: Wednesday, January 25, 2006 9:15 PM Subject: How should we deal with experimental netconf work? > Hi, > > I have an idea that may help those in the WG that believe standards=20 > based on real-world solutions are not that important. I have to clear=20 > it with Simon and the ADs first, but here goes... > > People with ideas for extensions should (hopefully) implement them,=20 > write them up in an Internet Draft, and propose them to the WG. > > We have a "netconf base" URI. > We can also have a "netconf experimental" URI. > (Yes, I know SMI has this already. We need it for the same reason.) > > The WG can then decide on new proposals: > 1) no thanks > 2) come back later with more details > 3) develop it as Experimental first (decide on standard later) > 4) charter it and develop it as a Proposed Standard > > This experimental branch (like in MIBs) would not be stable like a=20 > standard, but it is better than a vendor extension. Competitors in the > same market will be reluctant to implement each other's proprietary=20 > extensions, but they will be able to agree in a WG to implement=20 > something as a "netconf experimental" extension. > > The bar for Experimental should be much lower than for Proposed=20 > Standard, in terms of initial proposal deployment, WG involvement and=20 > IESG review. > > Comments? > > Andy > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 26 13:53:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CFD-0008FK-K6 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 13:53: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 NAA15411 for ; Thu, 26 Jan 2006 13:51:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2C7k-000BOB-6d for netconf-data@psg.com; Thu, 26 Jan 2006 18:45: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.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2C7j-000BNs-CA for netconf@ops.ietf.org; Thu, 26 Jan 2006 18:45:35 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0QIjUJ16210 for ; Thu, 26 Jan 2006 13:45: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 notification transport issues Date: Thu, 26 Jan 2006 13:45:27 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4069BB71A@zcarhxm2.corp.nortel.com> Thread-Topic: netconf notification transport issues Thread-Index: AcYipEISJq/P4UHrQkW3jZt3ZIOVFwAAzcFg From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi The generalized use case is when you want to send commands to get or edit information related to the thing you are receiving notifications about. So, if you wanted to retrieve information about active alarms, component state, statistics or configuration before or during receiving notifications. It also makes for easier notification triggered polling. If I receive information that a component has been modified, but did not receive all the information I wanted for whatever reason, then you simply do a query to retrieve this information and then carry on receiving events. The main trick for this is if the response to a command is too large, then the benefits of having the single connection get outweighed by the delay in processing events. Then you need to open a second connection for that function. Oh, and another advantage of this approach is it allows you to modify the subscription without tearing it down and restarting it. This eliminates the chances of missing events. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net]=20 Sent: Thursday, January 26, 2006 1:19 PM To: Chisholm, Sharon [CAR:ZZ00:EXCH] Cc: Netconf (E-mail) Subject: Re: netconf notification transport issues=20 "Sharon Chisholm" writes: >There are cases when you want to have your synchronous commands on the=20 >same connection as your asynchronous one. This obviously does not=20 >imply you always want to do this. Can you give details or use cases? 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 Thu Jan 26 13:56:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CId-0001Bt-Ct for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 13:56: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 NAA15719 for ; Thu, 26 Jan 2006 13:55:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2CEc-000BuT-5q for netconf-data@psg.com; Thu, 26 Jan 2006 18:52: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 [205.178.146.51] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2CEb-000BuG-BR for netconf@ops.ietf.org; Thu, 26 Jan 2006 18:52:41 +0000 Received: (qmail 21848 invoked from network); 26 Jan 2006 18:52:40 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 26 Jan 2006 18:52:40 -0000 Message-ID: <43D91A76.2060404@andybierman.com> Date: Thu, 26 Jan 2006 10:52:38 -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: "Netconf (E-mail)" Subject: Re: How should we deal with experimental netconf work? References: <43D7DC63.70300@andybierman.com> <025301c6229d$7f4cfe80$0601a8c0@pc6> In-Reply-To: <025301c6229d$7f4cfe80$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: >The trick that SNMP failed to solve was how to amend all the OIDs in the >debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without introducing any >errors. I see this as the reason for the lack of use of SNMP experimental. > > > To this day I still don't understand why manager station SW had such a huge problem getting this right. And don't get me started on module-scoped imports. So many mgmt apps completely ignored this, so FOO-MIB::blah and BAR-MIB::blah in the same module never worked like it's supposed to. I guess this is relevant to netconf because the same human nature will bite us in similar ways. In netconf, it is more than data that can be extended. Namespace processing is mandatory in netconf, and the difference between "base" and "experimental" is just one xmlns declaration. Literally just 8 characters different on the wire. (Let's see SNMP try that ;-) It is quite likely that the version that eventually gets standardized will not be exactly the same as the experimental version anyway, so this may not turn out to be a practical concern. Andy >So the question is, can this problem be avoided in XML? > >Tom Petch > >----- Original Message ----- >From: "Andy Bierman" >To: "Netconf (E-mail)" >Sent: Wednesday, January 25, 2006 9:15 PM >Subject: How should we deal with experimental netconf work? > > > > >>Hi, >> >>I have an idea that may help those in the WG that believe >>standards based on real-world solutions are not that important. >>I have to clear it with Simon and the ADs first, but here goes... >> >>People with ideas for extensions should (hopefully) implement them, write >>them up in an Internet Draft, and propose them to the WG. >> >>We have a "netconf base" URI. >>We can also have a "netconf experimental" URI. >>(Yes, I know SMI has this already. We need it for the same reason.) >> >>The WG can then decide on new proposals: >> 1) no thanks >> 2) come back later with more details >> 3) develop it as Experimental first (decide on standard later) >> 4) charter it and develop it as a Proposed Standard >> >>This experimental branch (like in MIBs) would not be stable >>like a standard, but it is better than a vendor extension. >>Competitors in the same market will be reluctant to implement >>each other's proprietary extensions, but they will be able to >>agree in a WG to implement something as a "netconf experimental" extension. >> >>The bar for Experimental should be much lower than for Proposed Standard, >>in terms of initial proposal deployment, WG involvement and IESG review. >> >>Comments? >> >>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 Jan 26 14:04:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CPb-00035X-5m for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 14:04: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 OAA16145 for ; Thu, 26 Jan 2006 14:02:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2CKB-000COJ-0h for netconf-data@psg.com; Thu, 26 Jan 2006 18:58:27 +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 1F2CKA-000CO8-9h for netconf@ops.ietf.org; Thu, 26 Jan 2006 18:58:26 +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 k0QIwG2S022746; Thu, 26 Jan 2006 10:58:16 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Jan 2006 10:58:16 -0800 Message-ID: From: "McDonald, Ira" To: "'Sharon Chisholm'" , "Netconf (E-mail)" Subject: RE: How should we deal with experimental netconf work? Date: Thu, 26 Jan 2006 10:58:15 -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, Yes, the same problem - the different base OID or XML namespace makes them mutually unintelligible to standard applications. XML namespaces (which are sloppily managed, in my experience) are actually _worse_ than OID-based MIBs for interoperability. And so we advance into the shining web-based sunset... Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Thursday, January 26, 2006 1:47 PM > To: Netconf (E-mail) > Subject: RE: How should we deal with experimental netconf work? > > > hi > > I think you would just have to switch the namespace when it moved. I > think that makes it a bit cleaner than with SNMP, but still > potentially > a problem. > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Tom Petch > Sent: Thursday, January 26, 2006 12:24 PM > To: Andy Bierman; Netconf (E-mail) > Subject: Re: How should we deal with experimental netconf work? > > > The trick that SNMP failed to solve was how to amend all the > OIDs in the > debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without > introducing any errors. I see this as the reason for the > lack of use of > SNMP experimental. > > So the question is, can this problem be avoided in XML? > > Tom Petch > > ----- Original Message ----- > From: "Andy Bierman" > To: "Netconf (E-mail)" > Sent: Wednesday, January 25, 2006 9:15 PM > Subject: How should we deal with experimental netconf work? > > > > Hi, > > > > I have an idea that may help those in the WG that believe standards > > based on real-world solutions are not that important. I > have to clear > > it with Simon and the ADs first, but here goes... > > > > People with ideas for extensions should (hopefully) implement them, > > write them up in an Internet Draft, and propose them to the WG. > > > > We have a "netconf base" URI. > > We can also have a "netconf experimental" URI. > > (Yes, I know SMI has this already. We need it for the same reason.) > > > > The WG can then decide on new proposals: > > 1) no thanks > > 2) come back later with more details > > 3) develop it as Experimental first (decide on standard later) > > 4) charter it and develop it as a Proposed Standard > > > > This experimental branch (like in MIBs) would not be stable like a > > standard, but it is better than a vendor extension. > Competitors in the > > > same market will be reluctant to implement each other's proprietary > > extensions, but they will be able to agree in a WG to implement > > something as a "netconf experimental" extension. > > > > The bar for Experimental should be much lower than for Proposed > > Standard, in terms of initial proposal deployment, WG > involvement and > > IESG review. > > > > Comments? > > > > Andy > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 26 14:50:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2D8J-0006Pt-Mv for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 14: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 OAA19940 for ; Thu, 26 Jan 2006 14:48:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2D0K-0000ZO-G3 for netconf-data@psg.com; Thu, 26 Jan 2006 19:42:00 +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 1F2D0I-0000Z0-Li for netconf@ops.ietf.org; Thu, 26 Jan 2006 19:41:58 +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 k0QJfp562647; Thu, 26 Jan 2006 11:41:56 -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 k0QJfk575948; Thu, 26 Jan 2006 11:41:46 -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 k0QJl2YE098204; Thu, 26 Jan 2006 14:47:02 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200601261947.k0QJl2YE098204@idle.juniper.net> To: "Sharon Chisholm" cc: "Netconf \(E-mail\)" Subject: Re: netconf notification transport issues In-Reply-To: Your message of "Thu, 26 Jan 2006 13:45:27 EST." <713043CE8B8E1348AF3C546DBE02C1B4069BB71A@zcarhxm2.corp.nortel.com> Date: Thu, 26 Jan 2006 14:47:02 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Sharon Chisholm" writes: >The generalized use case is when you want to send commands to get or >edit information related to the thing you are receiving notifications >about. This could still be done over a separate connection. The only case for receiving notifications over the normal rpc connection I see is when the notifications pertain to the outstanding RPC. For example, if I do a and the system starts spewing notifications about the commit, it would be good to see them. But it would be good to see them _during_ the commit operations, not after, so having them delayed until completion of the rpc defeats the only use case I can imagine, leaving me to wonder what the win is. Why not just put them over another connection? System resources? Juergen's number question that. Simplicity? Seems to be adding complexity rather than removing it. FWIW, we've done this as a separate channel within beep, where the intermixing isn't an issue, and the developers feel that this was needless complexity. Using a distinct connection is such a win in simplicity that it's hard to beat. Re: parsing issues: Yes, this shifts you from a document world to a SAX world, but this does not seem like a huge deal. 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 Thu Jan 26 14:50:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2D8a-0006Rq-R4 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 14:50: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 OAA19953 for ; Thu, 26 Jan 2006 14:48:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2D4W-0000r7-IU for netconf-data@psg.com; Thu, 26 Jan 2006 19:46: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 [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2D4V-0000qm-I9 for netconf@ops.ietf.org; Thu, 26 Jan 2006 19:46:19 +0000 Received: (qmail 31905 invoked from network); 26 Jan 2006 19:39:39 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr3.mgt.bos.netsol.com with SMTP; 26 Jan 2006 19:39:39 -0000 Message-ID: <43D9257A.9000403@andybierman.com> Date: Thu, 26 Jan 2006 11:39:38 -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: "'Sharon Chisholm'" , "Netconf (E-mail)" Subject: Re: How should we deal with experimental netconf work? 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, > >Yes, the same problem - the different base OID or XML namespace >makes them mutually unintelligible to standard applications. > >XML namespaces (which are sloppily managed, in my experience) >are actually _worse_ than OID-based MIBs for interoperability. > >And so we advance into the shining web-based sunset... > > I thought I was the only one who hated namespaces. ;-) I'm experimenting with something I hope is significantly more human-friendly. The myth is that machines will properly handle all the cryptic goo and humans will never have to look at it or understand it. >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 Sharon Chisholm >>Sent: Thursday, January 26, 2006 1:47 PM >>To: Netconf (E-mail) >>Subject: RE: How should we deal with experimental netconf work? >> >> >>hi >> >>I think you would just have to switch the namespace when it moved. I >>think that makes it a bit cleaner than with SNMP, but still >>potentially >>a problem. >> >>Sharon >> >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On >>Behalf Of Tom Petch >>Sent: Thursday, January 26, 2006 12:24 PM >>To: Andy Bierman; Netconf (E-mail) >>Subject: Re: How should we deal with experimental netconf work? >> >> >>The trick that SNMP failed to solve was how to amend all the >>OIDs in the >>debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without >>introducing any errors. I see this as the reason for the >>lack of use of >>SNMP experimental. >> >>So the question is, can this problem be avoided in XML? >> >>Tom Petch >> >>----- Original Message ----- >>From: "Andy Bierman" >>To: "Netconf (E-mail)" >>Sent: Wednesday, January 25, 2006 9:15 PM >>Subject: How should we deal with experimental netconf work? >> >> >> >> >>>Hi, >>> >>>I have an idea that may help those in the WG that believe standards >>>based on real-world solutions are not that important. I >>> >>> >>have to clear >> >> >>>it with Simon and the ADs first, but here goes... >>> >>>People with ideas for extensions should (hopefully) implement them, >>>write them up in an Internet Draft, and propose them to the WG. >>> >>>We have a "netconf base" URI. >>>We can also have a "netconf experimental" URI. >>>(Yes, I know SMI has this already. We need it for the same reason.) >>> >>>The WG can then decide on new proposals: >>> 1) no thanks >>> 2) come back later with more details >>> 3) develop it as Experimental first (decide on standard later) >>> 4) charter it and develop it as a Proposed Standard >>> >>>This experimental branch (like in MIBs) would not be stable like a >>>standard, but it is better than a vendor extension. >>> >>> >>Competitors in the >> >> >> >>>same market will be reluctant to implement each other's proprietary >>>extensions, but they will be able to agree in a WG to implement >>>something as a "netconf experimental" extension. >>> >>>The bar for Experimental should be much lower than for Proposed >>>Standard, in terms of initial proposal deployment, WG >>> >>> >>involvement and >> >> >>>IESG review. >>> >>>Comments? >>> >>>Andy >>> >>> >>> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with the >>word 'unsubscribe' in a single line as the message text body. >>archive: >> >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> >> > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-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 Jan 26 14:59:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DH9-0000KM-Vj for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 14:59: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 OAA20541 for ; Thu, 26 Jan 2006 14:57:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2DDG-0001a5-5j for netconf-data@psg.com; Thu, 26 Jan 2006 19:55:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [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 1F2DDF-0001Za-EA for netconf@ops.ietf.org; Thu, 26 Jan 2006 19:55:21 +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 k0QJtF1Z010776; Thu, 26 Jan 2006 11:55:15 -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 k0QJtE578028; Thu, 26 Jan 2006 11:55:14 -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 k0QK0VYE098486; Thu, 26 Jan 2006 15:00:31 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200601262000.k0QK0VYE098486@idle.juniper.net> To: Andy Bierman cc: "McDonald, Ira" , "'Sharon Chisholm'" , "Netconf (E-mail)" Subject: Re: How should we deal with experimental netconf work? In-Reply-To: Your message of "Thu, 26 Jan 2006 11:39:38 PST." <43D9257A.9000403@andybierman.com> Date: Thu, 26 Jan 2006 15:00:30 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Andy Bierman writes: >I thought I was the only one who hated namespaces. ;-) Namespaces are a pain. Anyone who says otherwise is selling something. 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 Thu Jan 26 15:12:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DUA-0006Jy-2n for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 15:12: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 PAA21365 for ; Thu, 26 Jan 2006 15:11:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2DOu-0002LR-77 for netconf-data@psg.com; Thu, 26 Jan 2006 20:07: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 [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2DOr-0002LB-8Q for netconf@ops.ietf.org; Thu, 26 Jan 2006 20:07:21 +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 k0QK74dU006534; Thu, 26 Jan 2006 12:07:25 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k0QJjpWe014713; Thu, 26 Jan 2006 11:45:51 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k0QJjpZv014710; Thu, 26 Jan 2006 11:45:51 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 26 Jan 2006 11:45:51 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Sharon Chisholm cc: "Netconf (E-mail)" Subject: RE: How should we deal with experimental netconf work? In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4069BB722@zcarhxm2.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, To me, it looks like you are oversimplifying the issue. That is, it appears that you are turning this into a development tools issue. And note, many tools do make this a trival operation. However, from my view, it is a deployment and versioning issue. That is, SNMP agents and SNMP management applications are in all but the most trivial case developed independantly using different developers with different timelines, and different motivations. The motivators is key. A device vendor supports SNMP agents in their devices so that both their management apps can manage the device and so that management apps developed by other can manage the device. These others include generic SNMP tools such as MIB browsers, and poller/reporters (such as MRTG), and application specific tools (such as AdventNet's WiFi manager (http://manageengine.adventnet.com/products/wifi-manager/index.html)) However, if the company is not an independent network management application developer, then there is little motivation to add support for devices for other companies. Connecting the dots.... An SNMP agent is developed that uses an experimental or proprietary MIB objects. An matching management app (using those objects) is developed. Both the device and app are fielded and provide some useful functionality. Now, the experimental MIB objects are re-specified in a standards track document with the OIDs changed (plus some possible changes). There may be some motivation for the agent to be updated to support both the old and new objects (so that device can be managed by 3rd party management apps), but there is little motivation for the management app to be updated. Depending on scope of the "small changes" that are done in addition to the OID changes, the cost might be quite high. Depending on the SNMP agent technology (and possibly tool kit), it might be expensive from the code size to support both old and new OIDs for the objects. I see these same motivations and costs with XML encoded data. So, I believe it will continue to be an issue of fielding a product, and then applying an incompatable change without any delivered benefit. Regards, /david t. perkins On Thu, 26 Jan 2006, Sharon Chisholm wrote: > hi > > I think you would just have to switch the namespace when it moved. I > think that makes it a bit cleaner than with SNMP, but still potentially > a problem. > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Tom Petch > Sent: Thursday, January 26, 2006 12:24 PM > To: Andy Bierman; Netconf (E-mail) > Subject: Re: How should we deal with experimental netconf work? > > > The trick that SNMP failed to solve was how to amend all the OIDs in the > debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without > introducing any errors. I see this as the reason for the lack of use of > SNMP experimental. > > So the question is, can this problem be avoided in XML? > > Tom Petch > > ----- Original Message ----- > From: "Andy Bierman" > To: "Netconf (E-mail)" > Sent: Wednesday, January 25, 2006 9:15 PM > Subject: How should we deal with experimental netconf work? > > > > Hi, > > > > I have an idea that may help those in the WG that believe standards > > based on real-world solutions are not that important. I have to clear > > it with Simon and the ADs first, but here goes... > > > > People with ideas for extensions should (hopefully) implement them, > > write them up in an Internet Draft, and propose them to the WG. > > > > We have a "netconf base" URI. > > We can also have a "netconf experimental" URI. > > (Yes, I know SMI has this already. We need it for the same reason.) > > > > The WG can then decide on new proposals: > > 1) no thanks > > 2) come back later with more details > > 3) develop it as Experimental first (decide on standard later) > > 4) charter it and develop it as a Proposed Standard > > > > This experimental branch (like in MIBs) would not be stable like a > > standard, but it is better than a vendor extension. Competitors in the > > > same market will be reluctant to implement each other's proprietary > > extensions, but they will be able to agree in a WG to implement > > something as a "netconf experimental" extension. > > > > The bar for Experimental should be much lower than for Proposed > > Standard, in terms of initial proposal deployment, WG involvement and > > IESG review. > > > > Comments? > > > > Andy > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 26 15:19:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DaD-0007qf-I5 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 15:19: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 PAA21779 for ; Thu, 26 Jan 2006 15:17:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2DTG-0002av-VR for netconf-data@psg.com; Thu, 26 Jan 2006 20:11:54 +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 1F2DTG-0002ai-58 for netconf@ops.ietf.org; Thu, 26 Jan 2006 20:11:54 +0000 Received: (qmail 22611 invoked from network); 26 Jan 2006 20:11:53 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr1.mgt.bos.netsol.com with SMTP; 26 Jan 2006 20:11:53 -0000 Message-ID: <43D92D08.3030701@andybierman.com> Date: Thu, 26 Jan 2006 12:11: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: Phil Shafer CC: "McDonald, Ira" , "'Sharon Chisholm'" , "Netconf (E-mail)" Subject: XML Namespace labels (was Re: How should we deal with experimental netconf work?) References: <200601262000.k0QK0VYE098486@idle.juniper.net> In-Reply-To: <200601262000.k0QK0VYE098486@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: >Andy Bierman writes: > > >>I thought I was the only one who hated namespaces. ;-) >> >> > >Namespaces are a pain. Anyone who says otherwise is selling >something. > > Speaking of which, how are you handling this special case problem: The RPC processing mandates that all the attributes in are returned in . This includes all the xmlns declarations. Inside data models, the label for a given namespace can change (over and over) with yet more xmlns declarations. If an error occurs, and a QName needs to be returned in , do you reuse the labels forced in the or create a new xmlns declaration with the label used in the QName? And if that label is already in use for a different namespace (in the element)? Do you use the label from the xmlns in the original element? Since the URIs are the same, all SW is expected to figure out that different labels map to the same NS, and applications should handle it no matter what. XML is so fun... >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 Thu Jan 26 15:53:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2E74-0004oU-E9 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 15:53: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 PAA24281 for ; Thu, 26 Jan 2006 15:51:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2E1G-0004cf-6b for netconf-data@psg.com; Thu, 26 Jan 2006 20:47: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=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 1F2E1F-0004cL-2v for netconf@ops.ietf.org; Thu, 26 Jan 2006 20:47:01 +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 99205757; Thu, 26 Jan 2006 21:46:58 +0100 Date: Thu, 26 Jan 2006 21:46:48 +0100 (CET) Message-Id: <20060126.214648.67903537.mbj@tail-f.com> To: ietf@andybierman.com Cc: phil@juniper.net, imcdonald@sharplabs.com, schishol@nortel.com, netconf@ops.ietf.org Subject: Re: XML Namespace labels From: Martin Bjorklund In-Reply-To: <43D92D08.3030701@andybierman.com> References: <200601262000.k0QK0VYE098486@idle.juniper.net> <43D92D08.3030701@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: > Speaking of which, how are you handling this special case problem: > > The RPC processing mandates that all the attributes in are > returned in . This includes all the xmlns declarations. > > Inside data models, the label for a given namespace can change (over and > over) > with yet more xmlns declarations. > > If an error occurs, and a QName needs to be returned in , > do you reuse the labels forced in the or create a new xmlns > declaration with the label used in the QName? And if that label is > already in use for a different namespace (in the element)? Do you > use the label from the xmlns in the original element? When you write 'label', do you mean the namespace prefix? Actually I don't see the problem, but in this case, our implementation uses new prefixes and new xmlns declarations. > Since the URIs are the same, all SW is expected to figure out that different > labels map to the same NS, and applications should handle it no matter what. > > XML is so fun... Yes, but honestly I don't think namespace handling is the biggest problem when implementing netconf... But then I am selling something :) Anyway, you write: > The RPC processing mandates that all the attributes in are > returned in . This includes all the xmlns declarations. Is this intentional? Why is it important to return the xmlns declarations? Couldn't we just state that xmlns declarations are not returned? /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 Jan 26 16:22:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2EZ6-0008QZ-Em for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 16:22: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 QAA02633 for ; Thu, 26 Jan 2006 16:20:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2EUL-0006ZP-Ka for netconf-data@psg.com; Thu, 26 Jan 2006 21:17:05 +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 1F2EUI-0006ZD-Uv for netconf@ops.ietf.org; Thu, 26 Jan 2006 21:17:03 +0000 Received: (qmail 23008 invoked from network); 26 Jan 2006 21:17:02 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr5.mgt.bos.netsol.com with SMTP; 26 Jan 2006 21:17:02 -0000 Message-ID: <43D93C4B.7010702@andybierman.com> Date: Thu, 26 Jan 2006 13:16:59 -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: phil@juniper.net, imcdonald@sharplabs.com, schishol@nortel.com, netconf@ops.ietf.org Subject: Re: XML Namespace labels References: <200601262000.k0QK0VYE098486@idle.juniper.net> <43D92D08.3030701@andybierman.com> <20060126.214648.67903537.mbj@tail-f.com> In-Reply-To: <20060126.214648.67903537.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: > > >>Speaking of which, how are you handling this special case problem: >> >>The RPC processing mandates that all the attributes in are >>returned in . This includes all the xmlns declarations. >> >>Inside data models, the label for a given namespace can change (over and >>over) >>with yet more xmlns declarations. >> >>If an error occurs, and a QName needs to be returned in , >>do you reuse the labels forced in the or create a new xmlns >>declaration with the label used in the QName? And if that label is >>already in use for a different namespace (in the element)? Do you >>use the label from the xmlns in the original element? >> >> > >When you write 'label', do you mean the namespace prefix? Actually I >don't see the problem, but in this case, our implementation uses new >prefixes and new xmlns declarations. > > Yes I mean prefix. > > >>Since the URIs are the same, all SW is expected to figure out that different >>labels map to the same NS, and applications should handle it no matter what. >> >>XML is so fun... >> >> > >Yes, but honestly I don't think namespace handling is the biggest >problem when implementing netconf... But then I am selling something :) > >Anyway, you write: > > > >>The RPC processing mandates that all the attributes in are >>returned in . This includes all the xmlns declarations. >> >> > >Is this intentional? Why is it important to return the xmlns >declarations? Couldn't we just state that xmlns declarations are not >returned? > > No. We state that all attributes in the are returned unchanged in the . We can add extras after that. > >/martin > > Andy > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 26 23:01:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Knp-0003qf-S8 for netconf-archive@megatron.ietf.org; Thu, 26 Jan 2006 23:01: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 XAA03707 for ; Thu, 26 Jan 2006 23:00:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Kg6-0000wn-JH for netconf-data@psg.com; Fri, 27 Jan 2006 03:53: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.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Kg4-0000wZ-HR for netconf@ops.ietf.org; Fri, 27 Jan 2006 03:53:36 +0000 Received: (qmail 27807 invoked from network); 27 Jan 2006 03:53:35 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 27 Jan 2006 03:53:35 -0000 Message-ID: <43D9993E.4060909@andybierman.com> Date: Thu, 26 Jan 2006 19:53:34 -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: Timer on Optional NETCONF Application Mappings 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 mostly comes from the ADs, but Simon and I agree with it.] We are concerned, especially from some recent emails, that the optional BEEP and SOAP application mappings are not being implemented. As any good engineer knows, you are done when you finish taking things out, not when you finish adding things. When we do our implementation reports in a year or so for standards advancement, if there aren't multiple independent complete implementations using BEEP and SOAP, then those application mapping documents will go Historic. 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 Fri Jan 27 14:14:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Z3e-0001m3-GI for netconf-archive@megatron.ietf.org; Fri, 27 Jan 2006 14:14: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 OAA06471 for ; Fri, 27 Jan 2006 14:13:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2YwD-000NNf-BW for netconf-data@psg.com; Fri, 27 Jan 2006 19:07: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.179.9.4] (helo=mail3.extremenetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2YwC-000NNR-OZ for netconf@ops.ietf.org; Fri, 27 Jan 2006 19:07:12 +0000 Received: by mail3 with Internet Mail Service (5.5.2657.72) id ; Fri, 27 Jan 2006 11:07:12 -0800 Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E101112F6E@sc-msexch-16.extremenetworks.com> From: Zihong Lu To: "'netconf@ops.ietf.org'" Subject: how people implement in netconf over SOAP? Date: Fri, 27 Jan 2006 11:07:12 -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 > I am looking into the implementation detail of netconf over SOAP. Wonder > how people implement in SOAP. Can any one please shed some > light? > > > In general, SOAP is a service function based protocol. It should be > possible to be message-based, but it will not be as easy to implement, and > the SOAP benefit will mostly be lost. For example, the part, > we have a message looks like this: > > > > > > > > > > > > > > Currently, most SOAP toolkit will automatically convert this message to a > function call > > RpcReply rpc(GetConfig g); > > When it gets to the filter part, you are on your own, since the netconf > schema passes in the under the filter. The agent code will have > to parse the xml document! > > If there is such a netconf module (toolkit) that can be put behind SOAP > toolkits like gSoap, or Axis for Java, etc, which converts the > part (or GetConfig object, returned from normal SOAP toolkit) > into a function for getting the detail data, so that all agent codes need > to to is to provide functions like > > RpcReply GetConfigFilter(TargetData d, Source s); > RpcReply EditConfig( ... ); > > it will become much easier to implement in SOAP paradigm. Not sure if > this kind of netconf toolkit exists. > > > -Zihong > -- to unsubscribe send a message to netconf-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 Jan 30 02:36:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3TaL-0005Tp-RI for netconf-archive@megatron.ietf.org; Mon, 30 Jan 2006 02:36: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 CAA03523 for ; Mon, 30 Jan 2006 02:34:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3TOZ-000KRt-Ow for netconf-data@psg.com; Mon, 30 Jan 2006 07:24:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_40,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS,MSGID_FROM_MTA_HEADER autolearn=no version=3.1.0 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3TOQ-000KRN-M4 for netconf@ops.ietf.org; Mon, 30 Jan 2006 07:24:07 +0000 Received: (eyou send program); Mon, 30 Jan 2006 14:58:02 +0800 Message-ID: <338651082.27850@njupt.edu.cn> Received: from 61.173.161.128 by em.njupt.edu.cn with HTTP; Mon, 30 Jan 2006 14:58:02 +0800 X-WebMAIL-MUA: [61.173.161.128] From: "=?gb2312?B?zfW6sQ==?=" To: zlu@extremenetworks.com, netconf@ops.ietf.org Date: Mon, 30 Jan 2006 14:58:02 +0800 Reply-To: "=?gb2312?B?zfW6sQ==?=" X-Priority: 3 Subject: Re:how people implement in netconf over SOAP? Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk I guess it should be the vedors' job. 在您的来信中曾经提到: >From: Zihong Lu >Reply-To: >To: "'netconf@ops.ietf.org'" >Subject: how people implement in netconf over SOAP? >Date:Fri, 27 Jan 2006 11:07:12 -0800 > > > > > > I am looking into the implementation detail of netconf over SOAP. Wonder > > how people implement in SOAP. Can any one please shed some > > light? > > > > > > In general, SOAP is a service function based protocol. It should be > > possible to be message-based, but it will not be as easy to implement, and > > the SOAP benefit will mostly be lost. For example, the part, > > we have a message looks like this: > > > > > > > > > > > > > > > > > -- to unsubscribe send a message to netconf-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 Jan 31 04:59:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3sIQ-0008EW-9W for netconf-archive@megatron.ietf.org; Tue, 31 Jan 2006 04:59: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 EAA00918 for ; Tue, 31 Jan 2006 04:57:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3s9K-000EJQ-W7 for netconf-data@psg.com; Tue, 31 Jan 2006 09:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [137.158.128.183] (helo=smtp1.uct.ac.za) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3s9I-000EHe-RG for netconf@ops.ietf.org; Tue, 31 Jan 2006 09:50:10 +0000 Received: from anubis.uct.ac.za ([137.158.128.125]) by smtp1.uct.ac.za with esmtp (Exim 4.30; FreeBSD) id 1F3s9A-0001WP-1n for netconf@ops.ietf.org; Tue, 31 Jan 2006 11:50:00 +0200 Received: from crg.ee.uct.ac.za ([137.158.30.12] helo=crglnx.uct.exp) by anubis.uct.ac.za with esmtp (Exim 4.43 (FreeBSD)) id 1F3s99-0003pa-PM for netconf@ops.ietf.org; Tue, 31 Jan 2006 11:49:59 +0200 Received: from localhost ([127.0.0.1] helo=crgmail.uct.exp ident=www-data) by crglnx.uct.exp with esmtp (Exim 4.50) id 1F3s98-0000u8-EA for netconf@ops.ietf.org; Tue, 31 Jan 2006 11:49:58 +0200 Received: from 10.128.1.66 (SquirrelMail authenticated user ntanzi) by crgmail.uct.exp with HTTP; Tue, 31 Jan 2006 11:49:58 +0200 (SAST) Message-ID: <50780.10.128.1.66.1138700998.squirrel@crgmail.uct.exp> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4069BB214@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4069BB214@zcarhxm2.corp.nortel.com> Date: Tue, 31 Jan 2006 11:49:58 +0200 (SAST) Subject: RE: Netconf for network health/state monitoring From: ntanzi@crg.ee.uct.ac.za To: netconf@ops.ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > hi > > For me, I think it's a bit early to draw a general conclusions from what > I've seen from people trying to do general network health/state > monitoring. I'm tempted, but I'll hold off until I am sure what > problems are real and which are just anticipated. > > As far as the hierarchical management scenario, I am seeing much more > interest in other XML-based network management solution for the manager > to manager interface than in using Netconf there. But, note that is the Can you provide me with some examples of those solutions so that I can take a look at it. > same thing I saw with SNMP, with the exception of one particular product > family. Others may have different experiences. > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Ntanzi Carrilho > Sent: Thursday, January 26, 2006 6:47 AM > To: netconf@ops.ietf.org > Subject: Netconf for network health/state monitoring > > > Hi > > Is there a study around that shows how any of the netconf > implementations > performs when used for general network health/state monitoring? > > Also, is there a way to use netconf in a hierarchical management > scenario, > where there are top level managers, mid level managers and the monitored > nodes? > > Regards > Ntanzi > > > -- > to 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 Jan 31 15:56:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42YL-00078b-Fb for netconf-archive@megatron.ietf.org; Tue, 31 Jan 2006 15:56: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 PAA26965 for ; Tue, 31 Jan 2006 15:54:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F42R8-000NMP-43 for netconf-data@psg.com; Tue, 31 Jan 2006 20:49: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.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F42R7-000NMC-Ex for netconf@ops.ietf.org; Tue, 31 Jan 2006 20:49:13 +0000 Received: (qmail 29473 invoked from network); 31 Jan 2006 20:49:12 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr5.mgt.bos.netsol.com with SMTP; 31 Jan 2006 20:49:12 -0000 Message-ID: <43DFCD47.8080703@andybierman.com> Date: Tue, 31 Jan 2006 12:49:11 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: FYI: XSD Best Practices 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, Not sure how accurate or up-to-date the following WEB site is, but the articles I looked at seem pretty good: http://www.xfront.com/BestPracticesHomepage.html 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 Jan 31 21:29:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F47kZ-0001fd-Bq for netconf-archive@megatron.ietf.org; Tue, 31 Jan 2006 21: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 VAA27793 for ; Tue, 31 Jan 2006 21:27:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F47c1-000AmG-Tr for netconf-data@psg.com; Wed, 01 Feb 2006 02:20:49 +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.54] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F47c0-000Am3-Rv for netconf@ops.ietf.org; Wed, 01 Feb 2006 02:20:49 +0000 Received: (qmail 29553 invoked from network); 1 Feb 2006 02:20:48 -0000 Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237) by omr4.mgt.bos.netsol.com with SMTP; 1 Feb 2006 02:20:48 -0000 Message-ID: <43E01AFF.4000304@andybierman.com> Date: Tue, 31 Jan 2006 18:20:47 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: terminology change 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 are making a terminology change to fix one of Joel's review comments. The term "application mapping" is used to mean the transport layer below netconf rpc. The term "application layer" is used to mean the content layer above netconf operations. Joel thinks this is confusing. Phil and I agree. I hope there are no strong objections, because we don't want to change it again. We are going back to our original term "transport mapping", which aligns with our architecture diagrams (which include the transport, rpc, operations, and application layers). These layer names are used in the element as well. The term "application layer" will not change. 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 Jan 31 23:49:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F49wA-0004te-8F for netconf-archive@megatron.ietf.org; Tue, 31 Jan 2006 23:49: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 XAA06646 for ; Tue, 31 Jan 2006 23:48:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F49q6-000ICn-3R for netconf-data@psg.com; Wed, 01 Feb 2006 04:43: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 [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F49q4-000ICa-SY for netconf@ops.ietf.org; Wed, 01 Feb 2006 04:43:29 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B55C84D882; Wed, 1 Feb 2006 05:43:27 +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 22331-07; Wed, 1 Feb 2006 05:43:26 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id F16964D879; Wed, 1 Feb 2006 05:43:25 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 329A15E26AA; Wed, 1 Feb 2006 05:43:26 +0100 (CET) Date: Wed, 1 Feb 2006 05:43:26 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Netconf (E-mail)" Subject: Re: terminology change Message-ID: <20060201044326.GA20461@noname> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , "Netconf (E-mail)" References: <43E01AFF.4000304@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E01AFF.4000304@andybierman.com> Fcc: =SENT 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, Jan 31, 2006 at 06:20:47PM -0800, Andy Bierman wrote: > We are going back to our original term "transport mapping", > which aligns with our architecture diagrams (which include > the transport, rpc, operations, and application layers). Thank you very much. Very strong support from me here. /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: