From owner-netconf@ops.ietf.org Mon Oct 02 13:08:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURHm-0004L8-Gw for netconf-archive@lists.ietf.org; Mon, 02 Oct 2006 13:08:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GURHl-0003sU-W7 for netconf-archive@lists.ietf.org; Mon, 02 Oct 2006 13:08:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GURBZ-0009vg-7Z for netconf-data@psg.com; Mon, 02 Oct 2006 17:02:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GURBW-0009vL-2u for netconf@ops.ietf.org; Mon, 02 Oct 2006 17:02:32 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Q8ib1uHQJS6HPCw0gnBR5/eEQhazedYs4KRCsQlMcEfoq81yKDd4OOSZBt5AnTno; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.89] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GURBQ-000635-15 for netconf@ops.ietf.org; Mon, 02 Oct 2006 13:02:24 -0400 Message-ID: <002101c6e645$091d87e0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf" Subject: Fw: WG Review: Network Endpoint Assessment (nea) Date: Mon, 2 Oct 2006 10:05:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af259dec1ec212d9cd5dcf99b754a6b20b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.89 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Hi - Somehow this sounds vaguely familiar... Could this be where netconf data models end up actually being done? Randy > From: "IESG Secretary" > To: > Cc: > Sent: Monday, October 02, 2006 7:30 AM > Subject: WG Review: Network Endpoint Assessment (nea) > > A new IETF working group has been proposed in the Security Area. > The IESG has not made any determination as yet. The following draft > charter was submitted, and is provided for informational purposes only. > Please send your comments to the IESG mailing list (iesg@ietf.org) > by October 9. > > +++ > > Network Endpoint Assessment (nea) > ====================================== > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Security Area Director(s): > Russ Housley > Sam Hartman > > Security Area Advisor: > Russ Housley > > Mailing List: nea@ietf.org > > Description of Working Group: > > Network Endpoint Assessment (NEA) architectures have been implemented in > the industry to assess the "posture" of endpoint devices for the > purposes of monitoring compliance to an organization's posture policy > and optionally restricting access until the endpoint has been updated to > satisfy the posture requirements. An endpoint that does not comply with > posture policy may be vulnerable to a number of known threats that may > exist on the network. The intent of NEA is to facilitate corrective > actions > to address these known vulnerabilities before a host is exposed to > potential attack. > Two deployment scenarios will be supported: advisory mode and mandatory > mode. > In advisory mode, an endpoint may be advised of the result of posture > assessment > and any recommended remediation actions, but is provided normal network > access > regardless of the result. In mandatory mode, a non-compliant endpoint is > given > restricted access to the network sufficient for remediation purposes > and any essential > services or denied access completely. > > Posture refers to the hardware or software configuration of an > endpoint as it pertains to an organization's security policy. Posture > may include knowledge that software installed to protect the machine > (e.g. patch management software, anti-virus software, host firewall > software, > host intrusion protection software or any custom software) is enabled > and up-to-date. > On network access and while connected, an endpoint supporting NEA > protocols can be > queried for such posture information in either advisory or mandatory > modes. > > Since NEA involves many different components from different vendors, > interoperation is highly desirable. The priority of the NEA working > group is to > standardize protocols at the higher layers in the architectures: > the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). > PA and PB will be designed to support a variety of lower layer protocols. > When used with standards for lower layers, these new protocols will allow > interoperability between an NEA Client from one vendor and an NEA > Server from another. > > Since there are already several non-standard protocols at these higher > layers, the NEA working group will consider these existing protocols > as candidates for standardization. A requirements document will be > written and used as a basis for evaluating the candidate protocols. > The working group may decide to standardize one of the candidate > protocols, use one of them as a basis for a new or revised protocol, > or decide that a new protocol is needed. > > The NEA Requirements document will include a problem statement, > definition of terms, requirements for the PA and PB protocols, and an > overall > security analysis. It will also include generic requirements for the > protocol > transporting PA, PB: the Posture Transport protocol (PT). PT protocols may > be > standardized in other WGs since these protocols may not be specific > to NEA. The NEA WG > will identify one mandatory to implement PT protocol to ensure > interoperability. > > PA, the Posture Attribute protocol, consists of posture attributes > that are carried between a particular Posture Collector in a NEA > client and a particular Posture Validator in a NEA Server. The PA > protocol is carried inside the PB protocol. Certain posture attributes > will be standardized to ensure interoperability but vendor-specific > attributes will also be supported. Vendor-specific attributes must > be documented in an RFC. > > The PB (Posture Broker) protocol aggregates posture attributes > from one or more Posture Collectors in an NEA client and sends them to > the NEA server for assessment by one or more Posture Validators. > > The PT (Posture Transport) protocol (or stack of protocols) is > suitable for carrying > the PB protocol at the time of network connection, or shortly after. > > The NEA working group will not specify protocols other than PA and PB at > this > time. The expectation is that an existing protocol can be used for the PT. > > > One commonly discussed issue with NEA systems is how to handle > compromised endpoints, whose reports of their own posture may not be > accurate. Detecting or handling such endpoints is out of scope of > the NEA WG. Work on PA will focus on attributes useful for assessing > posture of those endpoints reporting accurate information. However, > the protocols developed by the NEA WG must be designed to accommodate > emerging technologies for identifying and dealing with lying endpoints. > > Note that NEA is not chartered to standardize protocols for remediation. > NEA is intended to be used with new or existing tools that can be used in > the absence of NEA. There is an open issue with respect to NEA > applicability > in deployment scenarios where the endpoint is owned by a party that > is different > from the organization providing network access. > > Further work in the NEA WG will be considered via the standard > rechartering > process after the completion of these milestones. > > Milestones: > > June 2006: > * Submit first version of NEA Requirements I-D > > July 2006: > * Agree on charter and milestones at IETF 66 > > October 2006: > * Submit first draft of NEA Requirements I-D > > November 2006: > * At IETF 67, discuss issues with NEA Requirements I-D > * Agree on solutions to issues with NEA Requirements I-D > > December 2006: > * Deadline for submission of candidate specs for PA and PB > * Submit first version of NEA Evaluation I-D > > January 2007: > * WG Last Call on NEA Evaluation I-D > > February 2007: > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > * Submit first draft of PA and PB specs for review > > March 2007: > * Discuss unresolved issues with PA and PB specs at IETF 68 > * Agree on solutions to unresolved issues with PA and PB specs > > April 2007: > * Submit revised draft of PA and PB specs > > June 2007 > * WG Last Call on PA and PB specs > > July 2007 > * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 > > August 2007: > * Submit PA and PB specs to IESG for publication as Proposed > > September 2007: > * Decide how to address MTI PT, recharter if needed > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 02 23:46:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbEV-0006m2-Eg for netconf-archive@lists.ietf.org; Mon, 02 Oct 2006 23:46:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUbEU-0007cu-1S for netconf-archive@lists.ietf.org; Mon, 02 Oct 2006 23:46:15 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GUb8H-000Erw-N4 for netconf-data@psg.com; Tue, 03 Oct 2006 03:39:49 +0000 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GUb8E-000ErS-E9 for netconf@ops.ietf.org; Tue, 03 Oct 2006 03:39:46 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k933VNX1031755 for ; Mon, 2 Oct 2006 23:31:24 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6E69D.9069C8DB" Subject: FW: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Tue, 3 Oct 2006 05:39:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Thread-Index: AcbmMm8exuiAKahkTV2vSOzsQQ2RXgAawbKQ From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E69D.9069C8DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 In case some of you are not subscribed to i-d-announce.=20 Dan =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, October 02, 2006 4:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Master-agent Sub-agent Communication Protocol Author(s) : J. Kulkarni Filename : draft-kulkarni-netconf-subagent-prot-00.txt Pages : 16 Date : 2006-10-2 =09 This memo contains a mechanism by which NETCONF server and client can extended to operate in a master-agent sub-agent scheme. It extends the base NETCONF protocol with additional NETCONF operations, describes the protocol for this interaction and provides error messages exchanged during this interaction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-subagent-prot -00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-kulkarni-netconf-subagent-prot-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kulkarni-netconf-subagent-prot-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C6E69D.9069C8DB Content-Type: application/octet-stream; name="ATT402756.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT402756.TXT Content-Disposition: attachment; filename="ATT402756.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0xMC0yMDg1MTQzLkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWt1bGthcm5pLW5ldGNvbmYt c3ViYWdlbnQtcHJvdC0wMC50eHQNCg== ------_=_NextPart_001_01C6E69D.9069C8DB Content-Type: application/octet-stream; name="draft-kulkarni-netconf-subagent-prot-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-kulkarni-netconf-subagent-prot-00.URL Content-Disposition: attachment; filename="draft-kulkarni-netconf-subagent-prot-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1rdWxrYXJuaS1uZXRjb25mLXN1YmFnZW50LXByb3QtMDAudHh0DQo= ------_=_NextPart_001_01C6E69D.9069C8DB Content-Type: text/plain; name="ATT402757.txt" Content-Transfer-Encoding: base64 Content-Description: ATT402757.txt Content-Disposition: attachment; filename="ATT402757.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C6E69D.9069C8DB-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 03 09:53:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkiM-0003He-Ac for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 09:53:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUkUC-0005U3-SG for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 09:39:07 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GUkKA-0007ZH-4y for netconf-data@psg.com; Tue, 03 Oct 2006 13:28:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [135.245.0.37] (helo=ihemail3.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GUkJw-0007Xz-0C for netconf@ops.ietf.org; Tue, 03 Oct 2006 13:28:28 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k93DSPwQ015130 for ; Tue, 3 Oct 2006 08:28:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Oct 2006 15:28:24 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550ACBF601@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: netconf@ops.ietf.org Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Date: Tue, 3 Oct 2006 15:28:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Not sure if WG chairs agree to discuss this draft on this list. I did a very evry quick browse. Looks to me that we need to see example scenarios on how this woprks with chaninging (i.e. configuring) a device/system. How are the locking mechanims handled in that case? The subagent approach for gets is relatively easy I think, but the problems may arise when we want to modify data... Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, October 03, 2006 05:40 > To: netconf@ops.ietf.org > Subject: FW: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > > > In case some of you are not subscribed to i-d-announce. > > Dan > > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, October 02, 2006 4:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : NETCONF Master-agent Sub-agent Communication > Protocol > Author(s) : J. Kulkarni > Filename : draft-kulkarni-netconf-subagent-prot-00.txt > Pages : 16 > Date : 2006-10-2 > > This memo contains a mechanism by which NETCONF server and client can > extended to operate in a master-agent sub-agent scheme. It extends > the base NETCONF protocol with additional NETCONF operations, > describes the protocol for this interaction and provides error > messages exchanged during this interaction. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-sub agent-prot -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-kulkarni-netconf-subagent-prot-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-kulkarni-netconf-subagent-prot-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. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 03 12:12:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmsU-0006C4-5O for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 12:12:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmsS-0006t8-My for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 12:12:18 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GUmlr-0004gj-AT for netconf-data@psg.com; Tue, 03 Oct 2006 16:05:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GUmlk-0004f5-OJ for netconf@ops.ietf.org; Tue, 03 Oct 2006 16:05:21 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k93G52Bb000911 for ; Tue, 3 Oct 2006 12:05:08 -0400 Received: (qmail 30662 invoked by uid 78); 3 Oct 2006 16:05:02 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 3 Oct 2006 16:05:02 -0000 Message-ID: <45228A63.9050909@andybierman.com> Date: Tue, 03 Oct 2006 09:05:55 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt References: <7D5D48D2CAA3D84C813F5B154F43B1550ACBF601@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550ACBF601@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Wijnen, Bert (Bert) wrote: > Not sure if WG chairs agree to discuss this draft on this list. > > I did a very evry quick browse. > Looks to me that we need to see example scenarios on how this > woprks with chaninging (i.e. configuring) a device/system. > How are the locking mechanims handled in that case? > > The subagent approach for gets is relatively easy I think, but the > problems may arise when we want to modify data... > The WG is not going to standardize a sub-agent protocol, not only because there are more important issues already in the queue, but because this is a very agent implementation specific problem. The complexity required for robust support is just huge. And what about special RPCs like which might be implemented across multiple sub-agents? The notion of a "standard" agent callback implementation design is not something we are ready to think about (or even should think about in this WG). > Bert Andy > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >> Behalf Of Romascanu, Dan (Dan) >> Sent: Tuesday, October 03, 2006 05:40 >> To: netconf@ops.ietf.org >> Subject: FW: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >> >> >> >> In case some of you are not subscribed to i-d-announce. >> >> Dan >> >> >> >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Monday, October 02, 2006 4:50 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : NETCONF Master-agent Sub-agent Communication >> Protocol >> Author(s) : J. Kulkarni >> Filename : draft-kulkarni-netconf-subagent-prot-00.txt >> Pages : 16 >> Date : 2006-10-2 >> >> This memo contains a mechanism by which NETCONF server and client can >> extended to operate in a master-agent sub-agent scheme. It extends >> the base NETCONF protocol with additional NETCONF operations, >> describes the protocol for this interaction and provides error >> messages exchanged during this interaction. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-sub > agent-prot > -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-kulkarni-netconf-subagent-prot-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-kulkarni-netconf-subagent-prot-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. > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 03 14:15:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUoo8-0004yl-8I for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 14:15:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUoo6-0006aX-A0 for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 14:15:56 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GUofP-00014t-HO for netconf-data@psg.com; Tue, 03 Oct 2006 18:06:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_90_100,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.5 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GUofI-00013U-Lp for netconf@ops.ietf.org; Tue, 03 Oct 2006 18:06:49 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2006 11:06:47 -0700 X-IronPort-AV: i="4.09,251,1157353200"; d="scan'208,217"; a="344377682:sNHT102459374" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93I6kD9032269; Tue, 3 Oct 2006 11:06:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k93I6kYp022138; Tue, 3 Oct 2006 11:06:46 -0700 (PDT) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:06:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E716.B0097833" Subject: RE: A question on notifications-03 Date: Tue, 3 Oct 2006 11:06:43 -0700 Message-ID: <6E21698722408147BEA594E073E2B0AB028AA507@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A question on notifications-03 Thread-Index: AcbkdZhGSrpdC2tVTGiYCwxKghZbcgCnovwA From: "Hector Trevino \(htrevino\)" To: "Li Yan" , "Sharon Chisholm" Cc: X-OriginalArrivalTime: 03 Oct 2006 18:06:45.0635 (UTC) FILETIME=[B018CD30:01C6E716] DKIM-Signature: a=rsa-sha1; q=dns; l=34242; t=1159898806; x=1160762806; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20 |Subject:RE=3A=20A=20question=20on=20notifications-03; X=v=3Dcisco.com=3B=20h=3DzYZ2Ttes0q0fO/dbDiV9geQCPlA=3D; b=d6GcpVk1hL/wT9oVxaAoH4EfY+8GDElTY73e98jD/Hj7L/rSjDXRC8CWbZS2dX0Y+mHQcmxG OnMdBFjnlTxsXaItlzmnX1u5wyFQhpLzMMxo0oN9SvK5xyXuDQtOTF37; Authentication-Results: sj-dkim-3.cisco.com; header.From=htrevino@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: cdc29c58dbe62a8af768e96593e872ad This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E716.B0097833 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Yan, =20 Hi, see in-line Hector =20 ________________________________ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Li Yan Sent: Saturday, September 30, 2006 3:49 AM To: 'Sharon Chisholm' Cc: netconf@ops.ietf.org Subject: A question on notifications-03 =09 =09 Hi, I have a question on notifications-03. 2.3 Terminating the Subscription Closing of the event notification subscription is done by terminating the Netconf session ( )or via some action outside the scope of this specification. Does it imply that configuration and notification MUST run in two different sessions?=20 [HT:] It can be a different session/channel. But yes, configuration and notifications are independent. This was one of the agreements that came out of the Montreal meeting (i.e. no mixing of commands and notifications).=20 =20 Otherwise, configuration operations could be broke by . In addition, I believe the Subscription Id doesn't make sense any more, because and operations have been eliminated. A notification subscription should associate with a session-id, thus we can use to close a notification subscription. [HT:] Sharon and I had this discussion and left the Subscription Id in because: it is used in the notification subscription schema (i.e. unique identifier & search key) & also to allow for possible future enhancements.=20 =20 Yan ------_=_NextPart_001_01C6E716.B0097833 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Yan,
 
Hi, see in-line
Hector
 

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of Li = Yan
Sent:=20 Saturday, September 30, 2006 3:49 AM
To: 'Sharon=20 Chisholm'
Cc: netconf@ops.ietf.org
Subject: A = question on=20 notifications-03

Hi,

I have = a=20 question on notifications-03.

2.3 =20 Terminating the Subscription

  =20 Closing of the event notification subscription is done by=20 terminating

   the=20 Netconf session ( <kill-session> )or via some action outside=20 the

  =20 scope of this specification.

Does = it imply=20 that configuration and notification MUST run in two different = sessions?=20
[HT:] It=20 can be a different session/channel. But yes, configuration and=20 notifications are independent. This was one of the agreements that = came out of=20 the Montreal meeting (i.e. no mixing of commands and notifications).=20

 

 Otherwise, configuration = operations=20 could be broke by <kill-session>.

In = addition, I=20 believe the Subscription Id doesn't make sense any more, because=20 <cancel-subscription> and <modify-subscription> operations = have=20 been eliminated. A notification subscription should associate with a=20 session-id, thus we can use <kill-session> to close a = notification=20 subscription.
[HT:] Sharon=20 and I had this discussion and left the = Subscription Id=20 in because: it is used in the notification subscription = schema (i.e.=20 unique identifier & search key) & also to allow for possible = future=20 enhancements.

 

Yan

------_=_NextPart_001_01C6E716.B0097833-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 03 17:32:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrs6-0002tH-3Q for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 17:32:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUrs3-0004fY-Ns for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 17:32:14 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GUrjo-0009yk-TA for netconf-data@psg.com; Tue, 03 Oct 2006 21:23:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GUrji-0009xO-AT for netconf@ops.ietf.org; Tue, 03 Oct 2006 21:23:35 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k93LNXee005589 for ; Tue, 3 Oct 2006 17:23:33 -0400 Received: (qmail 17341 invoked by uid 78); 3 Oct 2006 21:23:33 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 3 Oct 2006 21:23:33 -0000 Message-ID: <4522D4CC.8050502@andybierman.com> Date: Tue, 03 Oct 2006 14:23:24 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Hector Trevino (htrevino)" CC: Li Yan , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: A question on notifications-03 References: <6E21698722408147BEA594E073E2B0AB028AA507@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB028AA507@xmb-sjc-223.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Hector Trevino (htrevino) wrote: > > Yan, > > Hi, see in-line > Hector > > > ------------------------------------------------------------------------ > *From:* owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] *On Behalf Of *Li Yan > *Sent:* Saturday, September 30, 2006 3:49 AM > *To:* 'Sharon Chisholm' > *Cc:* netconf@ops.ietf.org > *Subject:* A question on notifications-03 > > Hi, > > I have a question on notifications-03. > > 2.3 Terminating the Subscription > > Closing of the event notification subscription is done by terminating > > the Netconf session ( )or via some action outside the > > scope of this specification. > > Does it imply that configuration and notification MUST run in two > different sessions? > [HT:] It can be a different session/channel. But yes, configuration > and notifications are independent. This was one of the agreements > that came out of the Montreal meeting (i.e. no mixing of commands > and notifications). > > > > Otherwise, configuration operations could be broke by . > > In addition, I believe the Subscription Id doesn't make sense any > more, because and > operations have been eliminated. A notification subscription should > associate with a session-id, thus we can use to close > a notification subscription. > [HT:] Sharon and I had this discussion and left the Subscription Id > in because: it is used in the notification subscription schema (i.e. > unique identifier & search key) & also to allow for possible future > enhancements. This is a bit disturbing to me. The WG already decided to take this out. At the point when the WG makes a decision, the document Editor is supposed to carry out that decision. The search key argument is not really valid since there is only 1 subscription per session (because the session ID is the only relevant identifier). The future enhancements argument is even less compelling because whatever XML is needed can be added WHEN it is needed. Adding parameters with no current use is not good engineering. > > > > Yan > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 03 22:51:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwqt-0003DC-KM for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 22:51:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwqq-0001c5-4l for netconf-archive@lists.ietf.org; Tue, 03 Oct 2006 22:51:19 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GUwjs-000LZ4-4B for netconf-data@psg.com; Wed, 04 Oct 2006 02:44:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GUwjg-000LXj-Lx for netconf@ops.ietf.org; Wed, 04 Oct 2006 02:43:58 +0000 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k942hq0N017185 for ; Tue, 3 Oct 2006 22:43:52 -0400 Received: (qmail 27121 invoked by uid 78); 4 Oct 2006 02:43:51 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 4 Oct 2006 02:43:51 -0000 Message-ID: <45231FD4.8060600@andybierman.com> Date: Tue, 03 Oct 2006 19:43:32 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: comments on draft-ietf-netconf-notification-03 Content-Type: multipart/mixed; boundary="------------060402010908010407020107" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 This is a multi-part message in MIME format. --------------060402010908010407020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Some comments may have already been raised by others... Andy --------------060402010908010407020107 Content-Type: text/plain; name="comments on draft-ietf-netconf-notification-03.txt.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="comments on draft-ietf-netconf-notification-03.txt.txt" General: - Getting much closer to being ready for WGLC Abstract: - What framework is actually defined by this document? - Implications about mappings or just mappings? Suggest: This document defines mechanisms which provide an asynchronous event notification delivery service for the NETCONF protocol. It defines the capabilities, operations, transport mappings, and data models needed to support this service. Sec 1.2, para 3: OLD: A capability may be defined NEW: A capability may be advertised Sec 2.1.1: The term 'operation' is used to refer to an RPC method. I know this is a nit, but it should be mentioned somewhere (terms section). Parameters: What happens if both the filter and named profile are specified? How are they combined, or is this an error? Positive response: This should be instead of a element containing the subscription ID. The WG decided there is only one stream active per session. That means there is no need for a subscription ID in the document. Sec 2.2.1: Mention that is a top level element, to make it clear this is not another RPC method as in the previous section. The Positive Response and Negative Response document format is only for RPC methods, so this text should be removed instead of saying 'none'. The current text is confusing because is a sibling of and and the behavior for is not relevant. Sec 2.3: Remove "or via some action outside the scope of this document". There is no need to mention any unknown and undefined extensions that may be present on a particular implementation. Sec 3.1: The capabilities URN format is different than the NS format. (Use the other one.) Sec 3.2.6.2: Remove the statement about multiple subscriptions via multiple channels per NETCONF session. There is no concept of multiple channels within a NETCONF session. Sec 3.3: Not clear of the purpose of this section. Expand and clarify. Sec 3.2.5.3: How about if we compromise on the controversial 'access control' extensions? How about if we leave in (if we can agree on the enumeration values), but take out ? As I have pointed out several times, the concept of minAccess should be associated with a conformance statement, not with the data model itself (as in SMIv2). There are several people who have expressed different (incompatible) ideas for the NETCONF access control model. This issue will need to be worked out on the mailing list. Sec 3.5: It is not clear why this section is needed, especially towards the end of the document. The 1-way message is not similar to a 2-way RPC message. It is a totally different concept, different XML syntax, and different message semantics. Sec 3.6: Why do we need the complexity of combining RPC parameter filters and stored profile filters? IMO this should be an XML choice. Sec 4: - subscriptionID should be removed, and added later if we ever define a standard use for it. - SequenceNumber is declared with a base type of 'integer', which means it is infinite and there is no common wrap point. Suggest changing 'integer' to 'unsignedInt'. - the create-subscription element has a 'startTime' child parameter that has not been mentioned at all at this point in the document. - the element in the example should be in a container called . Also, any assumptions about naming and keys in the examples need to be stated. Sec 5.2.1: - We should remove any reference to non-existent BEEP modifications in this document. This is not an option. Stuff like this will only get stuck later anyway in the publication process. - The NETCONF over BEEP authors (and others clueful in BEEP) need to provide input on all of sec. 5.2 - rpc-one-way is still in the document. This doesn't belong, and is not explained. Sec 5.3: - Para 2 seems a bit unclear, and needs punctuation. Explain why it is more important. Sec 6.1: - This example assumes some data model with a root named , with a child element named . Change 'neb' to 'top' to be more consistent with other examples. - The example showing a child node of named is not very clear, or a realistic data model. Sec 7.1: - The warning message is not very clear. It needs to be completely specified in the Negative Response section (7.5.1). Sec 8: - The Security Considerations need to be specified. This cannot remain TBD as we go move towards WG Last Call. --------------060402010908010407020107-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 04 04:06:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV1lq-0000kw-RL for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 04:06:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV1ln-0006KU-C8 for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 04:06:26 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GV1aI-0001Pg-3N for netconf-data@psg.com; Wed, 04 Oct 2006 07:54:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.58] (helo=omr8.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GV0XU-000KKC-Cg for netconf@ops.ietf.org; Wed, 04 Oct 2006 06:47:37 +0000 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k942hKBF005079 for ; Tue, 3 Oct 2006 22:43:20 -0400 Received: (qmail 1860 invoked by uid 78); 4 Oct 2006 02:43:19 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 4 Oct 2006 02:43:19 -0000 Message-ID: <45231FB4.8090002@andybierman.com> Date: Tue, 03 Oct 2006 19:43:00 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: comments on draft-ietf-netconf-notification-03 Content-Type: multipart/mixed; boundary="------------010600040201020604050400" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 This is a multi-part message in MIME format. --------------010600040201020604050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Some comments may have already been raised by others... Andy --------------010600040201020604050400 Content-Type: text/plain; name="comments on draft-ietf-netconf-notification-03.txt.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="comments on draft-ietf-netconf-notification-03.txt.txt" General: - Getting much closer to being ready for WGLC Abstract: - What framework is actually defined by this document? - Implications about mappings or just mappings? Suggest: This document defines mechanisms which provide an asynchronous event notification delivery service for the NETCONF protocol. It defines the capabilities, operations, transport mappings, and data models needed to support this service. Sec 1.2, para 3: OLD: A capability may be defined NEW: A capability may be advertised Sec 2.1.1: The term 'operation' is used to refer to an RPC method. I know this is a nit, but it should be mentioned somewhere (terms section). Parameters: What happens if both the filter and named profile are specified? How are they combined, or is this an error? Positive response: This should be instead of a element containing the subscription ID. The WG decided there is only one stream active per session. That means there is no need for a subscription ID in the document. Sec 2.2.1: Mention that is a top level element, to make it clear this is not another RPC method as in the previous section. The Positive Response and Negative Response document format is only for RPC methods, so this text should be removed instead of saying 'none'. The current text is confusing because is a sibling of and and the behavior for is not relevant. Sec 2.3: Remove "or via some action outside the scope of this document". There is no need to mention any unknown and undefined extensions that may be present on a particular implementation. Sec 3.1: The capabilities URN format is different than the NS format. (Use the other one.) Sec 3.2.6.2: Remove the statement about multiple subscriptions via multiple channels per NETCONF session. There is no concept of multiple channels within a NETCONF session. Sec 3.3: Not clear of the purpose of this section. Expand and clarify. Sec 3.2.5.3: How about if we compromise on the controversial 'access control' extensions? How about if we leave in (if we can agree on the enumeration values), but take out ? As I have pointed out several times, the concept of minAccess should be associated with a conformance statement, not with the data model itself (as in SMIv2). There are several people who have expressed different (incompatible) ideas for the NETCONF access control model. This issue will need to be worked out on the mailing list. Sec 3.5: It is not clear why this section is needed, especially towards the end of the document. The 1-way message is not similar to a 2-way RPC message. It is a totally different concept, different XML syntax, and different message semantics. Sec 3.6: Why do we need the complexity of combining RPC parameter filters and stored profile filters? IMO this should be an XML choice. Sec 4: - subscriptionID should be removed, and added later if we ever define a standard use for it. - SequenceNumber is declared with a base type of 'integer', which means it is infinite and there is no common wrap point. Suggest changing 'integer' to 'unsignedInt'. - the create-subscription element has a 'startTime' child parameter that has not been mentioned at all at this point in the document. - the element in the example should be in a container called . Also, any assumptions about naming and keys in the examples need to be stated. Sec 5.2.1: - We should remove any reference to non-existent BEEP modifications in this document. This is not an option. Stuff like this will only get stuck later anyway in the publication process. - The NETCONF over BEEP authors (and others clueful in BEEP) need to provide input on all of sec. 5.2 - rpc-one-way is still in the document. This doesn't belong, and is not explained. Sec 5.3: - Para 2 seems a bit unclear, and needs punctuation. Explain why it is more important. Sec 6.1: - This example assumes some data model with a root named , with a child element named . Change 'neb' to 'top' to be more consistent with other examples. - The example showing a child node of named is not very clear, or a realistic data model. Sec 7.1: - The warning message is not very clear. It needs to be completely specified in the Negative Response section (7.5.1). Sec 8: - The Security Considerations need to be specified. This cannot remain TBD as we go move towards WG Last Call. --------------010600040201020604050400-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 04 04:44:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV2Mo-0003Rg-PQ for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 04:44:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV2Mj-00047K-Fr for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 04:44:38 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GV2Fs-00065L-DA for netconf-data@psg.com; Wed, 04 Oct 2006 08:37:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GV2Fg-00063z-JM for netconf@ops.ietf.org; Wed, 04 Oct 2006 08:37:22 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 78FDA1B8016; Wed, 4 Oct 2006 10:37:14 +0200 (CEST) Date: Wed, 04 Oct 2006 10:37:05 +0200 (CEST) Message-Id: <20061004.103705.76986183.mbj@tail-f.com> To: ietf@andybierman.com Cc: bwijnen@lucent.com, netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt From: Martin Bjorklund In-Reply-To: <45228A63.9050909@andybierman.com> References: <7D5D48D2CAA3D84C813F5B154F43B1550ACBF601@nl0006exch001u.nl.lucent.com> <45228A63.9050909@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Andy Bierman wrote: > The WG is not going to standardize a sub-agent protocol, If the WG does not want to work on a subagent protocol, that's fine. I just want to say that I do think the subagent idea (in general) is appealing, and I know for a fact that subagents will be used in some netconf deployments. > The complexity required for robust support > is just huge. I don't think it is. XPath filtering across subagents is more tricky... > And what about special RPCs like > which might be implemented across multiple sub-agents? This might be another reason for using a standard method (where the operation itself is defined in the data model) as been discussed earlier. /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 Oct 04 13:46:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVApP-0005bU-AT for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 13:46:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVApN-0007Ob-Ni for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 13:46:43 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVAiL-000Hfd-PF for netconf-data@psg.com; Wed, 04 Oct 2006 17:39:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.5 Received: from [216.148.227.153] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVAiA-000Hdg-6G for netconf@ops.ietf.org; Wed, 04 Oct 2006 17:39:19 +0000 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (rwcrmhc13) with SMTP id <20061004173912m1300m377je>; Wed, 4 Oct 2006 17:39:13 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Wijnen, Bert \(Bert\)'" Cc: Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Date: Wed, 4 Oct 2006 13:37:04 -0400 Message-ID: <0bf601c6e7db$b5f0f780$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <45228A63.9050909@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcbnBrNDfdMjjwBMSHyM3FtO0AggZwA0qIfA Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Hi, The SNMPv3 WG and the agentX WGs worked independently, because the implementation interfaces being defined by agentX were largely outside the scope of the SNMP operations, and the operations were clearly defined. In the RFC3411 diagram, the agentX interfaces would be positioned between the "SNMP application" and the underlying instrumentation. A master-subagent proposal might also be viable for netconf, but it would be really helpful if netconf had an architecture that showed where the interface is between netconf and the instrumentation, and what functionality is included in the netconf environment. It will be somewhat more difficult, I expect, to design an interface between the internal "applications" and the instrumentation, when the nature of "applications" is not yet defined, and special verbs might be related to specific sets of data. Presumably, special verbs will only work with specially-addressed data. The lack of any addressing model of data in netconf is going to make it difficukt to divide the data into addressable subsets in a master-subagent design. As Bert points out, it may be more difficult to design a subagent interface for SETs. For monitoring functionality, a standard can be defined based on a common vendor-neutral subset, but SET commands typically need to deal with extra parameters that may be vendor or equipment-model specific. dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, October 03, 2006 12:06 PM > To: Wijnen, Bert (Bert) > Cc: netconf@ops.ietf.org > Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > Wijnen, Bert (Bert) wrote: > > Not sure if WG chairs agree to discuss this draft on this list. > > > > I did a very evry quick browse. > > Looks to me that we need to see example scenarios on how this > > woprks with chaninging (i.e. configuring) a device/system. > > How are the locking mechanims handled in that case? > > > > The subagent approach for gets is relatively easy I think, but the > > problems may arise when we want to modify data... > > > > The WG is not going to standardize a sub-agent protocol, > not only because there are more important issues already > in the queue, but because this is a very agent implementation > specific problem. > > The complexity required for robust support > is just huge. And what about special RPCs like > which might be implemented across multiple sub-agents? > > The notion of a "standard" agent callback implementation design > is not something we are ready to think about (or even should > think about in this WG). > > > > Bert > > Andy > > > > >> -----Original Message----- > >> From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]On > >> Behalf Of Romascanu, Dan (Dan) > >> Sent: Tuesday, October 03, 2006 05:40 > >> To: netconf@ops.ietf.org > >> Subject: FW: I-D > ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > >> > >> > >> > >> In case some of you are not subscribed to i-d-announce. > >> > >> Dan > >> > >> > >> > >> > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Monday, October 02, 2006 4:50 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : NETCONF Master-agent Sub-agent Communication > >> Protocol > >> Author(s) : J. Kulkarni > >> Filename : draft-kulkarni-netconf-subagent-prot-00.txt > >> Pages : 16 > >> Date : 2006-10-2 > >> > >> This memo contains a mechanism by which NETCONF server and > client can > >> extended to operate in a master-agent sub-agent scheme. It extends > >> the base NETCONF protocol with additional NETCONF operations, > >> describes the protocol for this interaction and provides error > >> messages exchanged during this interaction. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-sub > > agent-prot > > -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-kulkarni-netconf-subagent-prot-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-kulkarni-netconf-subagent-prot-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. > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 04 16:55:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDmI-0004jX-48 for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 16:55:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDmF-0004Ah-4H for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 16:55:41 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVDfD-000Atl-Vv for netconf-data@psg.com; Wed, 04 Oct 2006 20:48:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVDf0-000ArA-V2 for netconf@ops.ietf.org; Wed, 04 Oct 2006 20:48:17 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k94Kb5JD030435 for ; Wed, 4 Oct 2006 16:37:05 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Date: Wed, 4 Oct 2006 22:48:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Thread-Index: AcbnBrNDfdMjjwBMSHyM3FtO0AggZwA0qIfAAAcYUnA= From: "Romascanu, Dan \(Dan\)" To: "David B Harrington" , "Andy Bierman" , "Wijnen, Bert \(Bert\)" Cc: X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 To me this means two things: 1. Maybe it's not that much about netconf lacking an architecture, but about not having documented the architecture that draws the relation between protocol and implementation 2. Defining a way to organize data in netconf may need to happen before we can talk about standardizing something like a master-subagent protocol Dan (speaking as a low-bandwidth contributor) =20 =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington > Sent: Wednesday, October 04, 2006 7:37 PM > To: 'Andy Bierman'; 'Wijnen, Bert (Bert)' > Cc: netconf@ops.ietf.org > Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >=20 > Hi, >=20 > The SNMPv3 WG and the agentX WGs worked independently,=20 > because the implementation interfaces being defined by agentX=20 > were largely outside the scope of the SNMP operations, and=20 > the operations were clearly defined. In the RFC3411 diagram,=20 > the agentX interfaces would be positioned between the "SNMP=20 > application" and the underlying instrumentation. >=20 > A master-subagent proposal might also be viable for netconf,=20 > but it would be really helpful if netconf had an architecture=20 > that showed where the interface is between netconf and the=20 > instrumentation, and what functionality is included in the=20 > netconf environment.=20 >=20 > It will be somewhat more difficult, I expect, to design an=20 > interface between the internal "applications" and the=20 > instrumentation, when the nature of "applications" is not yet=20 > defined, and special verbs might be related to specific sets=20 > of data. Presumably, special verbs will only work with=20 > specially-addressed data. >=20 > The lack of any addressing model of data in netconf is going=20 > to make it difficukt to divide the data into addressable=20 > subsets in a master-subagent design. >=20 > As Bert points out, it may be more difficult to design a=20 > subagent interface for SETs. For monitoring functionality, a=20 > standard can be defined based on a common vendor-neutral=20 > subset, but SET commands typically need to deal with extra=20 > parameters that may be vendor or equipment-model specific. >=20 > dbh >=20 > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > > Sent: Tuesday, October 03, 2006 12:06 PM > > To: Wijnen, Bert (Bert) > > Cc: netconf@ops.ietf.org > > Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > >=20 > > Wijnen, Bert (Bert) wrote: > > > Not sure if WG chairs agree to discuss this draft on this list. > > >=20 > > > I did a very evry quick browse. > > > Looks to me that we need to see example scenarios on how=20 > this woprks=20 > > > with chaninging (i.e. configuring) a device/system. > > > How are the locking mechanims handled in that case? > > >=20 > > > The subagent approach for gets is relatively easy I=20 > think, but the=20 > > > problems may arise when we want to modify data... > > >=20 > >=20 > > The WG is not going to standardize a sub-agent protocol, not only=20 > > because there are more important issues already in the queue, but=20 > > because this is a very agent implementation specific problem. > >=20 > > The complexity required for robust support is=20 > just huge. =20 > > And what about special RPCs like which might be=20 > > implemented across multiple sub-agents? > >=20 > > The notion of a "standard" agent callback implementation=20 > design is not=20 > > something we are ready to think about (or even should think=20 > about in=20 > > this WG). > >=20 > >=20 > > > Bert > >=20 > > Andy > >=20 > > >=20 > > >> -----Original Message----- > > >> From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org]On > > >> Behalf Of Romascanu, Dan (Dan) > > >> Sent: Tuesday, October 03, 2006 05:40 > > >> To: netconf@ops.ietf.org > > >> Subject: FW: I-D > > ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > >> > > >> > > >> =20 > > >> In case some of you are not subscribed to i-d-announce.=20 > > >> > > >> Dan > > >> > > >> > > >> =20 > > >> > > >> -----Original Message----- > > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > >> Sent: Monday, October 02, 2006 4:50 PM > > >> To: i-d-announce@ietf.org > > >> Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > >> > > >> A New Internet-Draft is available from the on-line > Internet-Drafts > > >> directories. > > >> > > >> > > >> Title : NETCONF Master-agent Sub-agent Communication > > >> Protocol > > >> Author(s) : J. Kulkarni > > >> Filename : draft-kulkarni-netconf-subagent-prot-00.txt > > >> Pages : 16 > > >> Date : 2006-10-2 > > >> =09 > > >> This memo contains a mechanism by which NETCONF server and > > client can > > >> extended to operate in a master-agent sub-agent scheme. It > extends > > >> the base NETCONF protocol with additional NETCONF operations,=20 > > >> describes the protocol for this interaction and provides error=20 > > >> messages exchanged during this interaction. > > >> > > >> A URL for this Internet-Draft is: > > >> http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-sub > > > agent-prot > > > -00.txt > > >=20 > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > > the message.=20 > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > >=20 > > > Internet-Drafts are also available by anonymous FTP. Login with > the=20 > > > username "anonymous" and a password of your e-mail address. After=20 > > > logging in, type "cd internet-drafts" and then "get=20 > > > draft-kulkarni-netconf-subagent-prot-00.txt". > > >=20 > > > A list of Internet-Drafts directories can be found in=20 > > > http://www.ietf.org/shadow.html or=20 > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >=20 > > > Internet-Drafts can also be obtained by e-mail. > > >=20 > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > > /internet-drafts/draft-kulkarni-netconf-subagent-prot-00.txt". > > > =09 > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" > or > > > a MIME-compliant mail reader. Different MIME-compliant mail=20 > > > 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. > > >=20 > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > Internet-Draft. > > >=20 > > >=20 > > > -- > > > to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with=20 > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: > > >=20 > > >=20 > >=20 > >=20 > > -- > > 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 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 04 17:38:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVERt-0004Zu-Mp for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 17:38:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVERq-0003Wj-Vw for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 17:38:41 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVEMb-000FH0-2K for netconf-data@psg.com; Wed, 04 Oct 2006 21:33:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.5 Received: from [209.128.82.1] (helo=shell4.bayarea.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVEMP-000FGE-EH for netconf@ops.ietf.org; Wed, 04 Oct 2006 21:33:07 +0000 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k94LWk1N030434; Wed, 4 Oct 2006 14:32:46 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k94LWkG4030427; Wed, 4 Oct 2006 14:32:46 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 4 Oct 2006 14:32:45 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Romascanu, Dan (Dan)" cc: David B Harrington , Andy Bierman , "Wijnen, Bert (Bert)" , netconf@ops.ietf.org Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b HI, Some people love AgentX. I don't, since I believe that it represents a failure of the managed system to provide "usable" control paths that can be used for SNMP. And I believe that a netconf-subagent would proprogate forward such failures. Lets assume we buy the argument of "let's be practical - it's easier to add another control path in a system than to fix the existing control path(s) to add support for another management interface", and look at the costs of AgentX. First, it limits changes in the management protocol. When Wes and I (and others) wanted to add an improved retrieval operation to SNMP, it couldn't really be done with AgentX, since it didn't support it. (And also, if you want to add caching in the "master", the AgentX protocol is not very efficient for doing this.) There are other protocol limitations due to AgentX. In addition, there are access control issues with agentx, primarily with not making the security identity from the request available to subagents. So, I haven't read the details of the netconf-subagent proposal, but I do have concerns based on both issues voiced by andy, but also from the SNMP agentX experience. Regards, /david t. perkins On Wed, 4 Oct 2006, Romascanu, Dan (Dan) wrote: > To me this means two things: > > 1. Maybe it's not that much about netconf lacking an architecture, but > about not having documented the architecture that draws the relation > between protocol and implementation > 2. Defining a way to organize data in netconf may need to happen before > we can talk about standardizing something like a master-subagent > protocol > > Dan > (speaking as a low-bandwidth contributor) > > > > > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington > > Sent: Wednesday, October 04, 2006 7:37 PM > > To: 'Andy Bierman'; 'Wijnen, Bert (Bert)' > > Cc: netconf@ops.ietf.org > > Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > > > Hi, > > > > The SNMPv3 WG and the agentX WGs worked independently, > > because the implementation interfaces being defined by agentX > > were largely outside the scope of the SNMP operations, and > > the operations were clearly defined. In the RFC3411 diagram, > > the agentX interfaces would be positioned between the "SNMP > > application" and the underlying instrumentation. > > > > A master-subagent proposal might also be viable for netconf, > > but it would be really helpful if netconf had an architecture > > that showed where the interface is between netconf and the > > instrumentation, and what functionality is included in the > > netconf environment. > > > > It will be somewhat more difficult, I expect, to design an > > interface between the internal "applications" and the > > instrumentation, when the nature of "applications" is not yet > > defined, and special verbs might be related to specific sets > > of data. Presumably, special verbs will only work with > > specially-addressed data. > > > > The lack of any addressing model of data in netconf is going > > to make it difficukt to divide the data into addressable > > subsets in a master-subagent design. > > > > As Bert points out, it may be more difficult to design a > > subagent interface for SETs. For monitoring functionality, a > > standard can be defined based on a common vendor-neutral > > subset, but SET commands typically need to deal with extra > > parameters that may be vendor or equipment-model specific. > > > > dbh > > > > > -----Original Message----- > > > From: owner-netconf@ops.ietf.org > > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > > > Sent: Tuesday, October 03, 2006 12:06 PM > > > To: Wijnen, Bert (Bert) > > > Cc: netconf@ops.ietf.org > > > Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > > > > > Wijnen, Bert (Bert) wrote: > > > > Not sure if WG chairs agree to discuss this draft on this list. > > > > > > > > I did a very evry quick browse. > > > > Looks to me that we need to see example scenarios on how > > this woprks > > > > with chaninging (i.e. configuring) a device/system. > > > > How are the locking mechanims handled in that case? > > > > > > > > The subagent approach for gets is relatively easy I > > think, but the > > > > problems may arise when we want to modify data... > > > > > > > > > > The WG is not going to standardize a sub-agent protocol, not only > > > because there are more important issues already in the queue, but > > > because this is a very agent implementation specific problem. > > > > > > The complexity required for robust support is > > just huge. > > > And what about special RPCs like which might be > > > implemented across multiple sub-agents? > > > > > > The notion of a "standard" agent callback implementation > > design is not > > > something we are ready to think about (or even should think > > about in > > > this WG). > > > > > > > > > > Bert > > > > > > Andy > > > > > > > > > > >> -----Original Message----- > > > >> From: owner-netconf@ops.ietf.org > > > [mailto:owner-netconf@ops.ietf.org]On > > > >> Behalf Of Romascanu, Dan (Dan) > > > >> Sent: Tuesday, October 03, 2006 05:40 > > > >> To: netconf@ops.ietf.org > > > >> Subject: FW: I-D > > > ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > > >> > > > >> > > > >> > > > >> In case some of you are not subscribed to i-d-announce. > > > >> > > > >> Dan > > > >> > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > >> Sent: Monday, October 02, 2006 4:50 PM > > > >> To: i-d-announce@ietf.org > > > >> Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt > > > >> > > > >> A New Internet-Draft is available from the on-line > > Internet-Drafts > > > >> directories. > > > >> > > > >> > > > >> Title : NETCONF Master-agent Sub-agent Communication > > > >> Protocol > > > >> Author(s) : J. Kulkarni > > > >> Filename : draft-kulkarni-netconf-subagent-prot-00.txt > > > >> Pages : 16 > > > >> Date : 2006-10-2 > > > >> > > > >> This memo contains a mechanism by which NETCONF server and > > > client can > > > >> extended to operate in a master-agent sub-agent scheme. It > > extends > > > >> the base NETCONF protocol with additional NETCONF operations, > > > >> describes the protocol for this interaction and provides error > > > >> messages exchanged during this interaction. > > > >> > > > >> A URL for this Internet-Draft is: > > > >> http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-sub > > > > agent-prot > > > > -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-kulkarni-netconf-subagent-prot-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-kulkarni-netconf-subagent-prot-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. > > > > > > > > > > > > -- > > > > to unsubscribe send a message to > > netconf-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message text body. > > > > archive: > > > > > > > > > > > > > > > > > -- > > > to unsubscribe send a message to > > netconf-request@ops.ietf.org with the > > > word 'unsubscribe' in a single line as the message text body. > > > archive: > > > > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org > > with the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 04 21:12:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVHmT-0005yH-SR for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 21:12:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVHmQ-0001R8-78 for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 21:12:09 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVHdM-00085K-QJ for netconf-data@psg.com; Thu, 05 Oct 2006 01:02:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVHdA-00084X-Qi for netconf@ops.ietf.org; Thu, 05 Oct 2006 01:02:38 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9512VoE009395 for ; Wed, 4 Oct 2006 21:02:31 -0400 Received: (qmail 30124 invoked by uid 78); 5 Oct 2006 01:02:30 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 5 Oct 2006 01:02:30 -0000 Message-ID: <452459A3.6030507@andybierman.com> Date: Wed, 04 Oct 2006 18:02:27 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: David B Harrington , "Wijnen, Bert \(Bert\)" , netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Romascanu, Dan (Dan) wrote: > To me this means two things: > > 1. Maybe it's not that much about netconf lacking an architecture, but > about not having documented the architecture that draws the relation > between protocol and implementation > 2. Defining a way to organize data in netconf may need to happen before > we can talk about standardizing something like a master-subagent > protocol I seem to remember a massive amount of effort going into the SNMPv3 architecture, and its ASI definitions, yet implementors found it less than relevant. It turned out that not 1 implementation followed the ASIs. IMO, we are in a discovery stage, in which developers are trying to go beyond the SNMP "peek/poke" architecture, to a service oriented architecture, focusing on high-level operations, not data models. If we create a NETCONF architecture now, based on what we learned from SNMP (and a tiny bit of NETCONF) we will probably not end up with a viable long-term solution. > > Dan > (speaking as a low-bandwidth contributor) Andy > > > > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington >> Sent: Wednesday, October 04, 2006 7:37 PM >> To: 'Andy Bierman'; 'Wijnen, Bert (Bert)' >> Cc: netconf@ops.ietf.org >> Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >> >> Hi, >> >> The SNMPv3 WG and the agentX WGs worked independently, >> because the implementation interfaces being defined by agentX >> were largely outside the scope of the SNMP operations, and >> the operations were clearly defined. In the RFC3411 diagram, >> the agentX interfaces would be positioned between the "SNMP >> application" and the underlying instrumentation. >> >> A master-subagent proposal might also be viable for netconf, >> but it would be really helpful if netconf had an architecture >> that showed where the interface is between netconf and the >> instrumentation, and what functionality is included in the >> netconf environment. >> >> It will be somewhat more difficult, I expect, to design an >> interface between the internal "applications" and the >> instrumentation, when the nature of "applications" is not yet >> defined, and special verbs might be related to specific sets >> of data. Presumably, special verbs will only work with >> specially-addressed data. >> >> The lack of any addressing model of data in netconf is going >> to make it difficukt to divide the data into addressable >> subsets in a master-subagent design. >> >> As Bert points out, it may be more difficult to design a >> subagent interface for SETs. For monitoring functionality, a >> standard can be defined based on a common vendor-neutral >> subset, but SET commands typically need to deal with extra >> parameters that may be vendor or equipment-model specific. >> >> dbh >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org >>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>> Sent: Tuesday, October 03, 2006 12:06 PM >>> To: Wijnen, Bert (Bert) >>> Cc: netconf@ops.ietf.org >>> Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >>> >>> Wijnen, Bert (Bert) wrote: >>>> Not sure if WG chairs agree to discuss this draft on this list. >>>> >>>> I did a very evry quick browse. >>>> Looks to me that we need to see example scenarios on how >> this woprks >>>> with chaninging (i.e. configuring) a device/system. >>>> How are the locking mechanims handled in that case? >>>> >>>> The subagent approach for gets is relatively easy I >> think, but the >>>> problems may arise when we want to modify data... >>>> >>> The WG is not going to standardize a sub-agent protocol, not only >>> because there are more important issues already in the queue, but >>> because this is a very agent implementation specific problem. >>> >>> The complexity required for robust support is >> just huge. >>> And what about special RPCs like which might be >>> implemented across multiple sub-agents? >>> >>> The notion of a "standard" agent callback implementation >> design is not >>> something we are ready to think about (or even should think >> about in >>> this WG). >>> >>> >>>> Bert >>> Andy >>> >>>>> -----Original Message----- >>>>> From: owner-netconf@ops.ietf.org >>> [mailto:owner-netconf@ops.ietf.org]On >>>>> Behalf Of Romascanu, Dan (Dan) >>>>> Sent: Tuesday, October 03, 2006 05:40 >>>>> To: netconf@ops.ietf.org >>>>> Subject: FW: I-D >>> ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >>>>> >>>>> >>>>> In case some of you are not subscribed to i-d-announce. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>>> Sent: Monday, October 02, 2006 4:50 PM >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >>>>> >>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : NETCONF Master-agent Sub-agent Communication >>>>> Protocol >>>>> Author(s) : J. Kulkarni >>>>> Filename : draft-kulkarni-netconf-subagent-prot-00.txt >>>>> Pages : 16 >>>>> Date : 2006-10-2 >>>>> >>>>> This memo contains a mechanism by which NETCONF server and >>> client can >>>>> extended to operate in a master-agent sub-agent scheme. It >> extends >>>>> the base NETCONF protocol with additional NETCONF operations, >>>>> describes the protocol for this interaction and provides error >>>>> messages exchanged during this interaction. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-sub >>>> agent-prot >>>> -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-kulkarni-netconf-subagent-prot-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-kulkarni-netconf-subagent-prot-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. >>>> >>>> >>>> -- >>>> to unsubscribe send a message to >> netconf-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: >>>> >>>> >>> >>> -- >>> to unsubscribe send a message to >> netconf-request@ops.ietf.org with the >>> word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org >> with the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 04 21:35:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVI92-0004JF-9C for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 21:35:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVI91-0005eq-03 for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 21:35:28 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVI4T-000AZq-D1 for netconf-data@psg.com; Thu, 05 Oct 2006 01:30:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVI4I-000AXy-Es for netconf@ops.ietf.org; Thu, 05 Oct 2006 01:30:39 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k951UXim004795 for ; Wed, 4 Oct 2006 21:30:33 -0400 Received: (qmail 16450 invoked by uid 78); 5 Oct 2006 01:30:33 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 5 Oct 2006 01:30:33 -0000 Message-ID: <45246037.40507@andybierman.com> Date: Wed, 04 Oct 2006 18:30:31 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Request for reviewers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, We are planning to get one more update of the notifications draft done before the San Diego IETF. We really need more people to read the latest draft and send review comments to the WG mailing list. http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-03.txt thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 04 22:55:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJOA-0006mG-HO for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 22:55:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVJO6-0002r4-4o for netconf-archive@lists.ietf.org; Wed, 04 Oct 2006 22:55:10 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVJII-0000ko-Q7 for netconf-data@psg.com; Thu, 05 Oct 2006 02:49:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVJIH-0000kZ-IX for netconf@ops.ietf.org; Thu, 05 Oct 2006 02:49:06 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k952nAeJ011313 for ; Wed, 4 Oct 2006 22:49:10 -0400 Received: (qmail 5738 invoked by uid 78); 5 Oct 2006 02:49:10 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 5 Oct 2006 02:49:10 -0000 Message-ID: <452472A3.4090902@andybierman.com> Date: Wed, 04 Oct 2006 19:49:07 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: bwijnen@lucent.com, netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt References: <7D5D48D2CAA3D84C813F5B154F43B1550ACBF601@nl0006exch001u.nl.lucent.com> <45228A63.9050909@andybierman.com> <20061004.103705.76986183.mbj@tail-f.com> In-Reply-To: <20061004.103705.76986183.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Martin Bjorklund wrote: > Andy Bierman wrote: >> The WG is not going to standardize a sub-agent protocol, > > If the WG does not want to work on a subagent protocol, that's fine. > > I just want to say that I do think the subagent idea (in general) is > appealing, and I know for a fact that subagents will be used in some > netconf deployments. > >> The complexity required for robust support >> is just huge. > > I don't think it is. XPath filtering across subagents is more > tricky... I think it would be almost as much work to write this document as it was to write the netconf-prot document. In practice, the capabilities and operations will not be the same across all sub-agents. All the bells and whistles (error-option, confirmed-commit, etc.), for all the operations seems like a lot of complexity to me. > >> And what about special RPCs like >> which might be implemented across multiple sub-agents? > > This might be another reason for using a standard method (where > the operation itself is defined in the data model) as been discussed > earlier. My point was that if every RPC is to be supported, then a generalized algorithm would be needed to define how it is properly invoked in the presence of multiple sub-agents. IMO, this is difficult. It is hard enough to define the algorithm for RPC methods we know about (like ), but what about any arbitrary RPC? I don't think really helps here, unless the contents of the exec command are tightly constrained. > > > /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 Oct 05 07:23:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRJu-0001Yo-QH for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 07:23:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVRJp-0003d9-G0 for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 07:23:18 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVR8R-000CXO-W3 for netconf-data@psg.com; Thu, 05 Oct 2006 11:11:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVR8Q-000CWc-2M for netconf@ops.ietf.org; Thu, 05 Oct 2006 11:11:27 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 296041B8011; Thu, 5 Oct 2006 13:11:20 +0200 (CEST) Date: Thu, 05 Oct 2006 13:11:11 +0200 (CEST) Message-Id: <20061005.131111.43403693.mbj@tail-f.com> To: ietf@andybierman.com Cc: bwijnen@lucent.com, netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt From: Martin Bjorklund In-Reply-To: <452472A3.4090902@andybierman.com> References: <45228A63.9050909@andybierman.com> <20061004.103705.76986183.mbj@tail-f.com> <452472A3.4090902@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Andy Bierman wrote: > I think it would be almost as much work to write this document > as it was to write the netconf-prot document. In practice, > the capabilities and operations will not be the same across > all sub-agents. All the bells and whistles (error-option, > confirmed-commit, etc.), for all the operations seems like > a lot of complexity to me. I agree. > >> And what about special RPCs like > >> which might be implemented across multiple sub-agents? > > > > This might be another reason for using a standard method (where > > the operation itself is defined in the data model) as been discussed > > earlier. > > My point was that if every RPC is to be supported, > then a generalized algorithm would be needed to > define how it is properly invoked in the presence > of multiple sub-agents. IMO, this is difficult. I agree. > It is hard enough to define the algorithm for > RPC methods we know about (like ), > but what about any arbitrary RPC? I don't > think really helps here, unless the contents > of the exec command are tightly constrained. The idea with exec is that the operation is defined for an instance in the data model. Something like restart /interface[ifIndex='1'] If the master knows which subagent handles /interface, he can dispatch to that subagent. Anyway, I agree that this isn't high on the priority list, and we should probably collect real-world experience before doing this. /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 Oct 05 07:42:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRcv-0001c7-Tk for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 07:42:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVRcm-0006R9-GI for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 07:42:57 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVRXH-000LKR-0g for netconf-data@psg.com; Thu, 05 Oct 2006 11:37:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVRXF-000LJb-CN for netconf@ops.ietf.org; Thu, 05 Oct 2006 11:37:06 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DBB7DE45 for ; Thu, 5 Oct 2006 13:37:03 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 13:37:03 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 13:37:02 +0200 Message-ID: <4524EE5E.3090206@ericsson.com> Date: Thu, 05 Oct 2006 13:37:02 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 11:37:03.0051 (UTC) FILETIME=[93D121B0:01C6E872] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I believe we will need this sub-agent stuff in the future, but not just now yet. I could also mention a couple of additional solvable but interesting problems. Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Oct 05 12:12:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVpQ-0006xp-O2 for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 12:12:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVpP-00084U-7J for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 12:12:08 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVVdj-000Fvr-GW for netconf-data@psg.com; Thu, 05 Oct 2006 16:00:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVVdi-000Fv9-G8 for netconf@ops.ietf.org; Thu, 05 Oct 2006 16:00:03 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k95FxliJ025754 for ; Thu, 5 Oct 2006 11:59:52 -0400 Received: (qmail 29148 invoked by uid 78); 5 Oct 2006 15:59:47 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 5 Oct 2006 15:59:47 -0000 Message-ID: <45252BF5.1030104@andybierman.com> Date: Thu, 05 Oct 2006 08:59:49 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: bwijnen@lucent.com, netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt References: <45228A63.9050909@andybierman.com> <20061004.103705.76986183.mbj@tail-f.com> <452472A3.4090902@andybierman.com> <20061005.131111.43403693.mbj@tail-f.com> In-Reply-To: <20061005.131111.43403693.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >... > Anyway, I agree that this isn't high on the priority list, and we > should probably collect real-world experience before doing this. > Agree 110% The AgentX work was done after many years of experience with the SNMP protocol, and after multiple high-quality implementations of a master-agent/sub-agent system. > > /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 Oct 05 12:22:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVzl-0003wn-H4 for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 12:22:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVzj-0001PB-6X for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 12:22:49 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVVsx-000KGS-4U for netconf-data@psg.com; Thu, 05 Oct 2006 16:15:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVVsu-000KFc-Uo for netconf@ops.ietf.org; Thu, 05 Oct 2006 16:15:46 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k95G7DvS002123 for ; Thu, 5 Oct 2006 12:07:14 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Date: Thu, 5 Oct 2006 18:15:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Thread-Index: Acbol7L9xukHwn/iTw2StOem7EFp5QAAO8Sg From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Martin Bjorklund" Cc: , X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 A very good observation. The AgentX work happened after many years of operational experience and deployment of 'monolithic' agents, and in the conditions when at least three different software packages that I remember were offering agent-subagent SNMP stacks.=20 Dan (contributor) =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, October 05, 2006 6:00 PM > To: Martin Bjorklund > Cc: bwijnen@lucent.com; netconf@ops.ietf.org > Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >=20 > >... >=20 > > Anyway, I agree that this isn't high on the priority list, and we=20 > > should probably collect real-world experience before doing this. > >=20 >=20 > Agree 110% > The AgentX work was done after many years of experience with=20 > the SNMP protocol, and after multiple high-quality=20 > implementations of a master-agent/sub-agent system. >=20 > >=20 > > /martin >=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: From owner-netconf@ops.ietf.org Thu Oct 05 15:17:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYig-0002th-Je for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 15:17:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYif-0004FV-Uc for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 15:17:22 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVYce-000O3p-Ds for netconf-data@psg.com; Thu, 05 Oct 2006 19:11:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,HTML_30_40, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.5 Received: from [203.91.193.32] (helo=wip-ec-wd.wipro.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVYcc-000O2w-G5 for netconf@ops.ietf.org; Thu, 05 Oct 2006 19:11:07 +0000 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 67DCD20624 for ; Fri, 6 Oct 2006 00:36:19 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 4C15620600 for ; Fri, 6 Oct 2006 00:36:19 +0530 (IST) Received: from blr-itp-msg.wipro.com ([10.185.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 00:41:03 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E8B1.FFC0D32C" Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Date: Fri, 6 Oct 2006 00:41:02 +0530 Message-ID: <30A4A576EB47C64AB2694E1F17DBE11702055936@blr-itp-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Thread-Index: Acbosf+5QtsMdo4YQGKGjZdMIK5N7w== From: To: X-OriginalArrivalTime: 05 Oct 2006 19:11:03.0059 (UTC) FILETIME=[00207E30:01C6E8B2] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E8B1.FFC0D32C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for all the comments on the draft. I note following problems that need to be updated in the draft: - problems with edit-config operation esp like locking mechanisms, = error-options, confirmed-commit etc=20 - complexities in Xpath filtering - capability variations between agents - data model sharing between sub-agent and master-agent - dealing with vendor specific operations and extra parameters in the = standard operations - passing on security identity to sub-agents I believe there will be cases for master agent-subagent implementation, = because in a multi-vendor unit with FRUs coming from various vendors or = various business units with in a organisation, using a standard protocol = is the only way for the controller card to interact with the line cards. Regards Jayaprakash =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org = ] On Behalf Of ext Romascanu, Dan = (Dan) Sent: Tuesday, 03 October, 2006 05:40 To: netconf@ops.ietf.org Subject: FW: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt=20 In case some of you are not subscribed to i-d-announce.=20 Dan =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org = ] Sent: Monday, October 02, 2006 4:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 Title : NETCONF Master-agent Sub-agent Communication Protocol Author(s) : J. Kulkarni Filename : draft-kulkarni-netconf-subagent-prot-00.txt Pages : 16 Date : 2006-10-2 This memo contains a mechanism by which NETCONF server and client can = extended to operate in a master-agent sub-agent scheme. It extends the = base NETCONF protocol with additional NETCONF operations, describes the = protocol for this interaction and provides error messages exchanged = during this interaction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-subagent-prot = =20 -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.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce = =20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get = draft-kulkarni-netconf-subagent-prot-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 = =20 Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kulkarni-netconf-subagent-prot-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. =20 ------_=_NextPart_001_01C6E8B1.FFC0D32C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A=

Thanks for all the comments on the = draft.

=0A=

I note following problems that need to be = updated in =0A= the draft:

=0A=

- problems with edit-config operation esp = like =0A= locking mechanisms, error-options, confirmed-commit etc

=0A=

- complexities in Xpath = filtering

=0A=

- capability variations between = agents

=0A=

- data model sharing between sub-agent and =0A= master-agent

=0A=

- dealing with vendor specific operations = and extra =0A= parameters in the standard operations

=0A=

- passing on security identity to =0A= sub-agents

=0A=

I believe there will be cases for master =0A= agent-subagent implementation, because in a multi-vendor unit with FRUs = coming =0A= from various vendors or various business units with in a organisation, = using a =0A= standard protocol is the only way for the controller card to interact = with the =0A= line cards.

=0A=

Regards

=0A=

Jayaprakash

=0A=

 

=0A=

-----Original Message-----

=0A=

From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf =0A= Of ext Romascanu, Dan (Dan)

=0A=

Sent: Tuesday, 03 October, 2006 05:40

=0A=

To: netconf@ops.ietf.org

=0A=

Subject: FW: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt =

=0A=

=0A=

In case some of you are not subscribed to i-d-announce.

=0A=

Dan

=0A=

 

=0A=

=0A=

-----Original Message-----

=0A=

From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]

=0A=

Sent: Monday, October 02, 2006 4:50 PM

=0A=

To: i-d-announce@ietf.org

=0A=

Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt

=0A=

A New Internet-Draft is available from the on-line Internet-Drafts =0A= directories.

=0A=

 

=0A=

Title : NETCONF Master-agent Sub-agent Communication

=0A=

Protocol

=0A=

Author(s) : J. Kulkarni

=0A=

Filename : draft-kulkarni-netconf-subagent-prot-00.txt

=0A=

Pages : 16

=0A=

Date : 2006-10-2

=0A=

=0A=

This memo contains a mechanism by which NETCONF server and client can =0A= extended to operate in a master-agent sub-agent scheme. It extends the = base =0A= NETCONF protocol with additional NETCONF operations, describes the = protocol for =0A= this interaction and provides error messages exchanged during this =0A= interaction.

=0A=

A URL for this Internet-Draft is:

=0A=

http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-subag= ent-prot

=0A=

-00.txt

=0A=

To remove yourself from the I-D Announcement list, send a message to =0A= i-d-announce-request@ietf.org with the word unsubscribe in the body of = the =0A= message.

=0A=

You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

=0A=

to change your subscription settings.

=0A=

Internet-Drafts are also available by anonymous FTP. Login with the = username =0A= "anonymous" and a password of your e-mail address. After logging in, = type "cd =0A= internet-drafts" and then "get = draft-kulkarni-netconf-subagent-prot-00.txt".

=0A=

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

=0A=

Internet-Drafts can also be obtained by e-mail.

=0A=

Send a message to:

=0A=

mailserv@ietf.org.

=0A=

In the body type:

=0A=

"FILE

=0A=

/internet-drafts/draft-kulkarni-netconf-subagent-prot-00.txt".

=0A=

=0A=

NOTE: The mail server at ietf.org can return the document in

=0A=

MIME-encoded form by using the "mpack" utility. To use this

=0A=

feature, insert the command "ENCODING mime" before the "FILE"

=0A=

command. To decode the response(s), you will need "munpack" or

=0A=

a MIME-compliant mail reader. Different MIME-compliant mail = readers

=0A=

exhibit different behavior, especially when dealing with

=0A=

"multipart" MIME messages (i.e. documents which have been split

=0A=

up into multiple messages), so check your local documentation on

=0A=

how to manipulate these messages.

=0A=

Below is the data which will enable a MIME compliant mail reader =0A= implementation to automatically retrieve the ASCII version of the =0A= Internet-Draft.

=0A=

 

------_=_NextPart_001_01C6E8B1.FFC0D32C-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Oct 05 15:28:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYtS-0002ta-Ik for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 15:28:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYtP-0008TK-8Q for netconf-archive@lists.ietf.org; Thu, 05 Oct 2006 15:28:30 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVYpx-0001nk-5F for netconf-data@psg.com; Thu, 05 Oct 2006 19:24:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVYpw-0001nY-9b for netconf@ops.ietf.org; Thu, 05 Oct 2006 19:24:52 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k95JOpDF001670 for ; Thu, 5 Oct 2006 15:24:51 -0400 Received: (qmail 17203 invoked by uid 78); 5 Oct 2006 19:24:51 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 5 Oct 2006 19:24:51 -0000 Message-ID: <45255C05.6090004@andybierman.com> Date: Thu, 05 Oct 2006 12:24:53 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: jayaprakash.kulkarni@wipro.com CC: netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt References: <30A4A576EB47C64AB2694E1F17DBE11702055936@blr-itp-msg.wipro.com> In-Reply-To: <30A4A576EB47C64AB2694E1F17DBE11702055936@blr-itp-msg.wipro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 jayaprakash.kulkarni@wipro.com wrote: > Thanks for all the comments on the draft. > > I note following problems that need to be updated in the draft: > > - problems with edit-config operation esp like locking mechanisms, > error-options, confirmed-commit etc > > - complexities in Xpath filtering > > - capability variations between agents > > - data model sharing between sub-agent and master-agent > > - dealing with vendor specific operations and extra parameters in the > standard operations > > - passing on security identity to sub-agents > > I believe there will be cases for master agent-subagent implementation, > because in a multi-vendor unit with FRUs coming from various vendors or > various business units with in a organisation, using a standard protocol > is the only way for the controller card to interact with the line cards. > I think it would be a good idea (if you do update the draft) to start another mailing list for discussion of this topic. I suggest asking the AD for a "pre-BOF" mailing list for this purpose. > Regards > > Jayaprakash > > 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 Oct 06 10:56:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVr7q-0004Jf-73 for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 10:56:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVr7o-0006cb-Sk for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 10:56:34 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVr1R-0001hv-Vx for netconf-data@psg.com; Fri, 06 Oct 2006 14:49:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVr1Q-0001hX-3O for netconf@ops.ietf.org; Fri, 06 Oct 2006 14:49:57 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k96Bip0b018736 for ; Fri, 6 Oct 2006 07:44:52 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Date: Fri, 6 Oct 2006 13:56:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Thread-Index: AcbotBWI73VeCT5RS3G04MNW0xFzwAAibwkw From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , Cc: X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, October 05, 2006 9:25 PM > To: jayaprakash.kulkarni@wipro.com > Cc: netconf@ops.ietf.org > Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt >=20 > jayaprakash.kulkarni@wipro.com wrote: > > Thanks for all the comments on the draft. > >=20 > > I note following problems that need to be updated in the draft: > >=20 > > - problems with edit-config operation esp like locking mechanisms,=20 > > error-options, confirmed-commit etc > >=20 > > - complexities in Xpath filtering > >=20 > > - capability variations between agents > >=20 > > - data model sharing between sub-agent and master-agent > >=20 > > - dealing with vendor specific operations and extra=20 > parameters in the=20 > > standard operations > >=20 > > - passing on security identity to sub-agents > >=20 > > I believe there will be cases for master agent-subagent=20 > > implementation, because in a multi-vendor unit with FRUs=20 > coming from=20 > > various vendors or various business units with in a organisation,=20 > > using a standard protocol is the only way for the=20 > controller card to interact with the line cards. > >=20 >=20 > I think it would be a good idea (if you do update the draft)=20 > to start another mailing list for discussion of this topic. > I suggest asking the AD for a "pre-BOF" mailing list for this purpose. >=20 It would be good indeed to let the netconf list focus on discussions about or closely related to the netconf WG chartered items. If there is a demand we can create a separate list for proposals on possible extensions of netconf. Note that a list (netmod) for data modeling issues already exists.=20 Dan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Oct 06 10:56:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVr89-0004Pj-K6 for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 10:56:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVr83-0006do-8t for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 10:56:53 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVqyj-0001MG-RF for netconf-data@psg.com; Fri, 06 Oct 2006 14:47:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVqyi-0001Ll-3c for netconf@ops.ietf.org; Fri, 06 Oct 2006 14:47:09 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k96E1DGQ006237 for ; Fri, 6 Oct 2006 10:01:13 -0400 Received: (qmail 10853 invoked by uid 78); 6 Oct 2006 14:01:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 6 Oct 2006 14:01:13 -0000 Message-ID: <452661A1.5010501@andybierman.com> Date: Fri, 06 Oct 2006 07:01:05 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: NETCONF Notifications References Issues Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, I just noticed a few more problems in the Notifications draft. 1) The references need to be split into Normative and Informative sections. 2) The reference to [NETCONF-Datamodel] needs to go away. We cannot block the Notifications document in this manner. There should not be any reason to cite this unchartered and unpublished document. 3) The xml2rfc macros did not all come out right [refs.RFCXXXX] instead of [RFCXXXX]. 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 Oct 06 11:00:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrBM-0004xd-Rw for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 11:00:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrBK-0007E5-I7 for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 11:00:12 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVr4x-0002BN-1W for netconf-data@psg.com; Fri, 06 Oct 2006 14:53:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.58] (helo=omr8.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVr4w-0002B7-3E for netconf@ops.ietf.org; Fri, 06 Oct 2006 14:53:34 +0000 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k96DrSTj008386 for ; Fri, 6 Oct 2006 09:53:28 -0400 Received: (qmail 23421 invoked by uid 78); 6 Oct 2006 13:53:28 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 6 Oct 2006 13:53:28 -0000 Message-ID: <45265FCF.3080606@andybierman.com> Date: Fri, 06 Oct 2006 06:53:19 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: jayaprakash.kulkarni@wipro.com, netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >... > > It would be good indeed to let the netconf list focus on discussions > about or closely related to the netconf WG chartered items. If there is > a demand we can create a separate list for proposals on possible > extensions of netconf. Note that a list (netmod) for data modeling > issues already exists. > I am sorry for not politely suggesting from the start that discussion of non-chartered work items be taken to a different mailing list. So to be clear, this mailing list is only for discussion of issues related to WG documents or the NETCONF Notifications work item. > Dan 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 Oct 06 11:17:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrSP-0006Jz-KZ for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 11:17:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrGS-0007vm-Px for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 11:05:30 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVrBp-0004B8-Qq for netconf-data@psg.com; Fri, 06 Oct 2006 15:00:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVrBp-0004Ae-13 for netconf@ops.ietf.org; Fri, 06 Oct 2006 15:00:41 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k96ELXYk009804 for ; Fri, 6 Oct 2006 10:21:37 -0400 Received: (qmail 8005 invoked by uid 78); 6 Oct 2006 14:21:33 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 6 Oct 2006 14:21:33 -0000 Message-ID: <45266665.3090905@andybierman.com> Date: Fri, 06 Oct 2006 07:21:25 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: access control mechanisms Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi, I am very concerned about the and constructs in the Notifications draft. This document needs to be clean (in both design and references) in order for the publication process to go smoothly. In my previous comments I said that would be OK iff we could agree on the enumerated values. Now I realize that we will be backing into an ad-hoc undefined access control model if this is done. The only real requirement that can be derived from the NETCONF documents is the ability to distinguish configuration data from other data. The requirement for a machine-friendly mechanism (in addition to the DESCRIPTION clause) is nice-to-have, but not critical. Therefore, I suggest we either create no extension for this purpose, or create something other than . For example: appInfo Extension: (type boolean) Values: true: The data construct is classified as configuration data. false: The data construct is not classified as configuration data. IMO, we do not need to say any more than this before the data modeling work is officially started. A extension can then be added later as part of a coherent and fully documented access control model. 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 Oct 06 11:43:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrqw-000331-Bb for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 11:43:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrqt-0003VR-T6 for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 11:43:10 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVrma-000Dsq-CG for netconf-data@psg.com; Fri, 06 Oct 2006 15:38:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVrmY-000Ds6-7s for netconf@ops.ietf.org; Fri, 06 Oct 2006 15:38:39 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2E25459765; Fri, 6 Oct 2006 10:12:49 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10648-04; Fri, 6 Oct 2006 10:12:46 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 562A4594EE; Fri, 6 Oct 2006 10:12:46 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 03086806CE7; Fri, 6 Oct 2006 10:12:43 +0200 (CEST) Date: Fri, 6 Oct 2006 10:12:43 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Cc: Andy Bierman , Martin Bjorklund , bwijnen@lucent.com, netconf@ops.ietf.org Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Message-ID: <20061006081243.GC4086@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Romascanu, Dan (Dan)" , Andy Bierman , Martin Bjorklund , bwijnen@lucent.com, netconf@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Thu, Oct 05, 2006 at 06:15:41PM +0200, Romascanu, Dan (Dan) wrote: > A very good observation. The AgentX work happened after many years of > operational experience and deployment of 'monolithic' agents, and in the > conditions when at least three different software packages that I > remember were offering agent-subagent SNMP stacks. Before we all start to be proud of the AgentX story, lets not forget that sub-agent technology was invented very shortly after SNMP did see the light (around 1990) and that attempts to standardize were kind of blocked until 1996 and then it took then the usual IETF time to get AgentX out in January 1998 (see RFC 1227 and RFC 1228 for early works in this area or the special issue of the Simple Times, Volume 4, Number 2 April, 1996). A great deal of standardization work seems to be related to good timing and I am not sure AgentX is an example we can be proud of in terms of good timing. /js PS: I am not arguing for doing netconf subagent work now nor do I have an opinion whether such a standard is needed at all; I just think we need to be careful with the history. -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Oct 06 17:10:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVwxn-0001S0-Pb for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 17:10:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVwxm-0002R4-D1 for netconf-archive@lists.ietf.org; Fri, 06 Oct 2006 17:10:35 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVwrm-0006Of-Op for netconf-data@psg.com; Fri, 06 Oct 2006 21:04:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [209.86.89.62] (helo=elasmtp-dupuy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GVwrk-0006Nk-IK for netconf@ops.ietf.org; Fri, 06 Oct 2006 21:04:22 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HC3Q6t7d+HP1GBDzDTfvlzc4DMOWUFmPia1A62uvX2HxyU0wpYXUitRXvlJhi44c; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.4.236] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GVwrk-0001nW-3Q for netconf@ops.ietf.org; Fri, 06 Oct 2006 17:04:20 -0400 Message-ID: <003a01c6e98b$91560ee0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20061006081243.GC4086@boskop.local> Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt Date: Fri, 6 Oct 2006 14:08:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee65cc8e3e18c0beaf7f02ba529b8b82120350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.4.236 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi - > From: "Juergen Schoenwaelder" > To: "Romascanu, Dan (Dan)" > Cc: "Andy Bierman" ; "Martin Bjorklund" ; ; > Sent: Friday, October 06, 2006 1:12 AM > Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt ... > A great deal of standardization work seems to be related to good > timing and I am not sure AgentX is an example we can be proud of in > terms of good timing. ... Indeed. There was an incredible amount of well-entrenched political opposition to pursuing any kind of subagent work, and lots of disingenuous FUD. Old-timers will recall the "dogs of a feather" held in San Jose outside IETF auspices because those in power at the time would not permit a BoF. In the case of netconf, until there's an instance naming architecture and we have some idea what data models are going to look like, I think we'll just have to assume that netconf implementations will be totally monolithic, despite all the limitations that that will entail for large, complex, multi-vendor or dynamic systems. With the very limited applicability envisioned for netconf, this might not be a problem. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 10 05:38:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXE4Q-000868-Jx for netconf-archive@lists.ietf.org; Tue, 10 Oct 2006 05:38:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXE4H-0007Bk-5H for netconf-archive@lists.ietf.org; Tue, 10 Oct 2006 05:38:42 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXDuZ-0004iQ-44 for netconf-data@psg.com; Tue, 10 Oct 2006 09:28:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXDuX-0004hd-EJ for netconf@ops.ietf.org; Tue, 10 Oct 2006 09:28:30 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81760639 for ; Tue, 10 Oct 2006 11:28:28 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 11:28:28 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 11:28:28 +0200 Message-ID: <452B67BB.9090007@ericsson.com> Date: Tue, 10 Oct 2006 11:28:27 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: More comments on notifications-03 References: <20060927.190533.133433864.mbj@tail-f.com> In-Reply-To: <20060927.190533.133433864.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2006 09:28:28.0076 (UTC) FILETIME=[71661EC0:01C6EC4E] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hello Some more comments on the draft. Sorry if some are due to my misunderstanding of the draft. Chapter 3.2.5.3 page 16) annotation/documentation states this is a schema for event streams 10 lines lover nm:description states A schema that can be used to learn about current Netconf Event subscriptions and creating named profiles Which is true ? Chapter 3.3) First sentence states that subscriptions don't exist in datastores, then in 3.4 we define a schema to read about them. If they don,t exist how can you read them ? My guess is that you either have to drop the schema or explain it a bit more. Chapter 4, page 26, Symmetrical operations) There is in the schema for which I do not find the corresponding opening tag. Chapter 4, page 26) I don't really understand the schema defining one-way operations. Is it complete? Where do you put your own data? Chapter 5.2.1.1) This is the only, single place where rpc-one-way is mentioned. Either remove it or explain it some more. regards Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 10 12:28:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKSt-0005dA-Ex for netconf-archive@lists.ietf.org; Tue, 10 Oct 2006 12:28:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKSr-0002uw-So for netconf-archive@lists.ietf.org; Tue, 10 Oct 2006 12:28:23 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXKBn-000LRv-7O for netconf-data@psg.com; Tue, 10 Oct 2006 16:10:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXKBm-000LRc-Be for netconf@ops.ietf.org; Tue, 10 Oct 2006 16:10:42 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9AGAQmC006161 for ; Tue, 10 Oct 2006 12:10:29 -0400 Received: (qmail 18232 invoked by uid 78); 10 Oct 2006 16:10:26 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 10 Oct 2006 16:10:26 -0000 Message-ID: <452BC5EB.7090305@andybierman.com> Date: Tue, 10 Oct 2006 09:10:19 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: security considerations section Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, I want to start a thread to discuss what needs to be in the Security Considerations section of the Notifications draft. IMO, there does not seem to be that much we need to say, because the elements are never sent before the transport layer and the netconf layer (capabilities exchange) have been established, and the manager has been identified and authenticated. We need to explain all the vulnerabilities in some detail, and identify what can and should "be secured" by an operator: - invocation - use of - read-only data models - read-write data models - notification content Is this list complete? Does anyone want to volunteer to write text for the Editor to incorporate into the next draft? 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 Oct 10 14:59:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMoh-0005YT-P3 for netconf-archive@lists.ietf.org; Tue, 10 Oct 2006 14:59:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMog-0008QW-Bv for netconf-archive@lists.ietf.org; Tue, 10 Oct 2006 14:59:03 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXMih-000OiM-J4 for netconf-data@psg.com; Tue, 10 Oct 2006 18:52:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [204.127.192.84] (helo=rwcrmhc14.comcast.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXMig-000Oi9-9h for netconf@ops.ietf.org; Tue, 10 Oct 2006 18:52:50 +0000 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (rwcrmhc14) with SMTP id <20061010183636m14003r1cfe>; Tue, 10 Oct 2006 18:36:37 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Netconf \(E-mail\)'" Subject: RE: security considerations section Date: Tue, 10 Oct 2006 14:34:21 -0400 Message-ID: <113701c6ec9a$b4f9db30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <452BC5EB.7090305@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcbsiSygd4ChfCW8RMKdJEDVc6AGhwAEAA7g Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi, To save some time, I recommend looking at the list of threats in RFC3411 to help make sure you don't overlook any of the categories of vulnerability identified there. I think that list contains pretty much what the security directorate goes looking for when assessing a security considerations section. That, of course, would only be a starting point; netconf notifications may have specific vulnerabiltiies that do not apply to other NM protocols such as SNMP. One issue related to the notifications draft is the transport of data from non-netconf streams, such as syslog and SNMP. The considerations should probably mention that this data may be more vulnerable (or is not more vulnerable) when being transported over netconf than when being transported using the protocol normally used for transporting it. dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, October 10, 2006 12:10 PM > To: Netconf (E-mail) > Subject: security considerations section > > Hi, > > I want to start a thread to discuss what needs to be in the > Security Considerations section of the Notifications draft. > > IMO, there does not seem to be that much we need to say, because > the elements are never sent before the transport > layer and the netconf layer (capabilities exchange) have been > established, and the manager has been identified and authenticated. > > We need to explain all the vulnerabilities in some detail, > and identify what can and should "be secured" by an operator: > > - invocation > - use of > - read-only data models > - read-write data models > - notification content > > Is this list complete? > Does anyone want to volunteer to write text for the Editor > to incorporate into the next draft? > > thanks, > Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 11 18:04:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXmBn-0006vj-BR for netconf-archive@lists.ietf.org; Wed, 11 Oct 2006 18:04:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXmBm-0005uW-Qv for netconf-archive@lists.ietf.org; Wed, 11 Oct 2006 18:04:35 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXm4w-000MH2-Cf for netconf-data@psg.com; Wed, 11 Oct 2006 21:57:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [135.245.0.37] (helo=ihemail3.lucent.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXm4v-000MGo-18 for netconf@ops.ietf.org; Wed, 11 Oct 2006 21:57:29 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k9BLvRfk025648 for ; Wed, 11 Oct 2006 16:57:28 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Oct 2006 23:57:26 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AD31B80@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: netconf@ops.ietf.org Subject: My review of and comments for: draft-ietf-netconf-notification-03 .txt Date: Wed, 11 Oct 2006 23:57:19 +0200 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 So I did finally find some time to review. I did not check if any of my comments overlap with comments from others, so appology if there are duplicates. 1. I see: 1.3 Motivation The motivation for this work is to enable the sending of asynchronous messages that are consistent with the data model (content) and security model used within a Netconf implementation. I find it somewhat strange to read about consistency with "the data model" and "security model". Because I do not recall we have defined any. I understand we want to send notifications over NETCONF (and if netconf is secured via (for example) ssh or some such, then we want to do so too, but is that a security model? I know we want to at least send notification if some config erorr occurs as a result of our NETCONF config changes etc. In that sense, the content is probably "consistent" with what we use in the Netconf protocol to configure a device/system/server. Anyway, not sure how serious we need to specify our motivation, but I would prefer to not suggest we have done/completed more than what we really did. 2. Consistency. In 1.1 we define "Managed Entity" (also sometimes called "NetConf server") In 1.2 we speak about a "Netconf client" without having defined the term. In 1.2 and in 1.4, we also speak about "an agent", where I think we mean "Netconf server". In any event, we did not define "agent" In 1.4 we speak about "a manager" which I think means "Netconf client" I expect that most of us on this WG mailing list understand what is meant with all these terms. But it might be better to try and be consistent in the terms we use for the "entities" on each side of the connection. More consistency Either use "subscription ID" or "subscription Id" But pls be consistent. More consistency In the protocol spec, the scetion headers for the operations have: 7.1. Description: While this notification spec has: 2.1.1 create-subscription Description: Maybe we better try to be consistent. Makes it easier for novices. More consistency On page 13 (in the reply) you use .... It seems to me that the end-tags are in the wrong order Also, sessnioEventStream is singular while end-tag is plural In the get-config sessionEventStream is all singular. On page 14, sessionEventStreamns is always plural. I have not checked other places. Indentation and alignment of indented tags could be better so it is easier to check examples. 3. Requirements (sect 1.4) I think that instead of: The requirements for this solution are as follows: I would state: The following are the requirements we have addressed in this solution: But maybe that is just personal taste. 4. Comments on some bullets in sect 1.4: o solution should provide a filtering mechanism Do we mean that filtering moust occur/be provided at the notification origin/source? If so, pls be explicit. o solution should support replay of locally logged notifications I guess "locally" mean on the "managed entity" ?? But that is not 100% clear. 5. Do we consider notifications a capability. Not sure what sect 3.1 tries to say. But I wonder if this: "urn:ietf:params:xml:ns:netconf:notification:1.0" For Example urn:ietf:params:xml:ns:netconf:base:1.0 urn:ietf:params:xml:ns:netconf:capability:startup:1.0 urn:ietf:params:xml:ns:netconf:notification:1.0 4 Would not be better defined as a capability and so the URU would be: "urn:ietf:params:xml:ns:netconf:capability:notification:1.0" And then I guess we would need to update the document to describe notifications as a capability, that ius, use the template to do so. Just wondering and thinking aloud here. If the WG feels I am just rambling... then I will shut up on this. 6. Page 13. I think that in thebeginning there is a missing tag 7. Pages 13-15 Not sure I understand (not even sure we need) the differentiation between sessionEventStreams and systemEventStreams. I do see that the SAME streams themselves get listed in the example responses to both a get for sessionEventStreams and for systemEventStreams?? So what is the difference (if any)? 8. W.r.t. 3.2.5.3 Stream Retrieval Schema Mmm.. in the protocol doc, we have done the Schema in an appendix. Why do we have it in the middle of the document in this case? The schema itself and its indentation is kind of unreadable if you ask me. I'll need to take another look at that later. 9. I will have to study sect 3.4 in much much more detail before I can comment. It looks awfully complex to me. 10. I will have to study sect 4 in more detail before I can comment. 11. Why is this capability: 7.3 Capability Identifier The Event Notification Replay capability is identified by following capability string: http://ietf.org/netconf/notificationReplay/1.0 represented with a URI as suggested by the capability template? I also am not sure we agreed that we need/want a replay capability, did we? 12. I believe that this piece of text The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Is NOT sipposed to be in the RFC. I get these problems with citations/references. Not sure if teh tool reports them correctly, but the authors/editors may want to check: !! Missing Reference for citation: [3] P004 L042: document are to be interpreted as described in RFC 2119 [3]. !! Missing Reference for citation: [NETCONF-PROTO] P004 L008: NETCONF [NETCONF-PROTO] can be conceptually partitioned into four P004 L046: Managed Entity: A node, which supports NETCONF[NETCONF-PROTO] and has !! Missing Reference for citation: [NETCONF-SSH] P027 L016: over SSH transport mapping [NETCONF-SSH] P027 L024: As the examples in [NETCONF-SSH] illustrate, a special character !! Missing Reference for citation: [NETCONF] P038 L022: [NETCONF] Enns, R., "NETCONF Configuration Protocol", !! Missing Reference for citation: [URI] P038 L045: [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform !! Missing Reference for citation: [XML] P004 L044: Element: An XML Element[XML]. P038 L049: [XML] World Wide Web Consortium, "Extensible Markup Language !! Missing Reference for citation: [refs.RFC2026] P038 L053: [refs.RFC2026] !! Missing Reference for citation: [refs.RFC2119] P039 L009: [refs.RFC2119] !! Missing Reference for citation: [refs.RFC2223] P039 L013: [refs.RFC2223] !! Missing Reference for citation: [refs.RFC3080] P039 L017: [refs.RFC3080] Bert -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Oct 13 17:06:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUEm-0001QM-75 for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 17:06:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYUEk-00034N-R7 for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 17:06:36 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYU8K-0003nZ-61 for netconf-data@psg.com; Fri, 13 Oct 2006 20:59:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYU8I-0003n3-Uu for netconf@ops.ietf.org; Fri, 13 Oct 2006 20:59:55 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9DKxrvs007593 for ; Fri, 13 Oct 2006 16:59:54 -0400 Received: (qmail 2651 invoked by uid 78); 13 Oct 2006 20:59:53 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 13 Oct 2006 20:59:53 -0000 Message-ID: <452FFE43.4010407@andybierman.com> Date: Fri, 13 Oct 2006 13:59:47 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" CC: Balazs Lengyel Subject: action RPC I-D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi, Balazs Lengyel has written a brief draft for a Generic Action RPC: http://www.ietf.org/internet-drafts/draft-lengyel-action-rpc-00.txt I think this might be relevant to our initial data modeling efforts, and possibly the Notifications work as well. First, the WG needs to decide how it wants to add features (as extensions) to the protocol. I am personally less comfortable with an ad-hoc, approach than a designed approach. Notifications were left over from the initial charter, not really an add-on. Why is this new special standard RPC method needed? What increased multi-vendor interoperability does it provide? What exactly is an "action"? It is not defined in this document. I know "reboot" is an action. What about "save and reboot" (which changes config and then does an action)? IMO, the agent and manager MUST know the security and other requirements a priori anyway (via a schema), so some generic 'container' for actions does not provide any real value -- just extra XML. In your 'restart' example, 'actionName' could just as well be the actual RPC method name, and 'callingPoint' is really just an RPC parameter, along with the entire 'parameters' sub-tree. How do you manage the allocation of action names? You propose just xs:string as a data type, and all these unbounded strings are in the NETCONF namespace. This implies the WG is going to define the contents, but that is not stated in the draft. Do we really need a standard "action" RPC method container, without defining any actual standard actions? 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 Oct 13 17:46:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUrG-0004U4-4s for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 17:46:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYUrE-0005Ml-MH for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 17:46:22 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYUmW-0008ux-6b for netconf-data@psg.com; Fri, 13 Oct 2006 21:41:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYUmV-0008uP-AW for netconf@ops.ietf.org; Fri, 13 Oct 2006 21:41:27 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2006 14:41:25 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9DLfPSx026760; Fri, 13 Oct 2006 14:41:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9DLfOWI025153; Fri, 13 Oct 2006 14:41:25 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 14:41:24 -0700 Received: from 10.21.112.145 ([10.21.112.145]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Oct 2006 21:41:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3243595282_749284" In-Reply-To: <452FFE43.4010407@andybierman.com> Content-class: urn:content-classes:message Subject: Re: action RPC I-D Date: Fri, 13 Oct 2006 14:41:22 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: action RPC I-D Thread-Index: AcbvEFMjkYIkqVsDEduxvAAUUR2zPg== From: "Steven Berl \(sberl\)" To: "Andy Bierman" , "Netconf \(E-mail\)" Cc: "Balazs Lengyel" X-OriginalArrivalTime: 13 Oct 2006 21:41:24.0517 (UTC) FILETIME=[54A3BD50:01C6EF10] DKIM-Signature: a=rsa-sha1; q=dns; l=3838; t=1160775685; x=1161639685; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sberl@cisco.com; z=From:=22Steven=20Berl=20\(sberl\)=22=20 |Subject:Re=3A=20action=20RPC=20I-D; X=v=3Dcisco.com=3B=20h=3D1hZviWNDog8m/WrsS9o0GyVosEc=3D; b=UtLapvBaTYpkvbpdoE9pO1Jnxsrg6y06jMAPgjTJpNuFZQb6U/QDl79wi7WbGf8t2w/QwZ7G Oe53yX3IN7CLQu0bDkXxIq7IUZiFBPFhi/ANKTieSuZ7441DNc5dZCs0; Authentication-Results: sj-dkim-1.cisco.com; header.From=sberl@cisco.com; dkim=pass ( 25 extraneous bytes; sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3243595282_749284 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Why wouldn't we define standard actions? Seems like there are several the would be useful. Off the top of my head - reboot - file system operations such as: - copy - delete - rename - erase/format - mkdir - ping - traceroute -steve On 10/13/06 1:59 PM, "Andy Bierman" wrote: > Do we really need a standard "action" RPC method container, > without defining any actual standard actions? > > thanks, > Andy > --B_3243595282_749284 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIIUwYJKoZIhvcNAQcCoIIIRDCCCEACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bh8wggLYMIICQaADAgECAhBYFfIrIwiObSOOH7tPCDd1MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjEwMTIyMTU3 MjFaFw0wNzEwMTIyMTU3MjFaMEExHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx HjAcBgkqhkiG9w0BCQEWD3NiZXJsQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAJ4hITTKNaKQNFOwZBevkZ1HpMJtnb5xNB+VjLITefpUXt9V5pxckL/RGPpM 7+zhNXX4FxBvW7OoP75gpytu1KDDixxC+mhXS/dSoHY5k7n7a9vXMPIDG0K9DG+B2KOW/aZa mhsJPyTgiNPODUheOQPRfL6UmIRBFRQoiRinhEZgyVzS1IiR/qga4Y6E5CvnlHjS65EmFHVe TxamWbSNICtuWt2VwC6FL8MbUtgnA6W2Bwzy41myrWCMKmzCYUCwaPas3UPrlkrj5VbNjfxt SXMIu/dMOnANqtgyMf8Sx9Dd0CVyUABGTgVXfyEO0X4RfruwPbt6dvAU/zl6Fox8gHECAwEA AaMsMCowGgYDVR0RBBMwEYEPc2JlcmxAY2lzY28uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI hvcNAQEFBQADgYEAjzdD66SDCk557x5OjBraUoalM7kkjWHwtxGu7WZfudc6O4z/svfEIg6R ioJmBjFGfSHgZl104FrdXGRdCJyCyti6Pn1RnDG6ZRD4dGltAYbhJh7dPo7PFeXfiU9Xl2Ro JDEGuLLxAHkIG7pkKl4uLZk+QsCJpyWsHg7OLuDLsxwwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJj WiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenpruf ZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIB ADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMT EVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+v rL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRi x9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECEFgV8isjCI5tI44fu08IN3UwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBT9UZK+rycXRwjqRU8zyBnRbounBzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNjEwMTMyMTQxMjJaMA0GCSqGSIb3DQEBAQUABIIBABBGA3DQm0vdnNfF HM0PjP1E2GSGlz7l4cqJTlEkGj3HR81nhM4nUHHNRb264qGIpb8P7gchk9C0XvBr1w6++hzu JCATmXLKGbbnwfONxFFqqAN/IOYS8jZ8A8GykhfoN2ytOWr4vr9PUIQFjDLOh+nu9nfUeTwP Z3BmLtr92zf2eIcnwo8BPVrtmjUCu8J53Gdv8tmhlHyNKGT+p9ImKsQEixvB6AiJbUt6ZqYE 9s+x5P0r3StiXEN6L69sZT0LQztGm+zniI7Y6GXPLMHj12Ks/5+1hwfOmHBjMN9HzPNUS6lm 3cdLcEzX/jVDSylqSLGZrg1fjZKeuLAwzi6a5k8= --B_3243595282_749284-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Oct 13 18:06:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYVAy-0001zq-97 for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 18:06:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYVAw-000899-Pz for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 18:06:44 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYV6C-000Bv8-J6 for netconf-data@psg.com; Fri, 13 Oct 2006 22:01:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYV6B-000Bus-MJ for netconf@ops.ietf.org; Fri, 13 Oct 2006 22:01:48 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9DM1gGN008456 for ; Fri, 13 Oct 2006 18:01:44 -0400 Received: (qmail 7194 invoked by uid 78); 13 Oct 2006 22:01:42 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 13 Oct 2006 22:01:42 -0000 Message-ID: <45300CC0.60203@andybierman.com> Date: Fri, 13 Oct 2006 15:01:36 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Steven Berl (sberl)" CC: "Netconf (E-mail)" , Balazs Lengyel Subject: Re: action RPC I-D 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Steven Berl (sberl) wrote: > Why wouldn't we define standard actions? Seems like there are several the > would be useful. Off the top of my head > > - reboot > - file system operations such as: > - copy > - delete > - rename > - erase/format > - mkdir > - ping > - traceroute > I agree. But we don't need an extra wrapper to define this. I.e. ... ... vs. ping ... ... > -steve Andy > > > On 10/13/06 1:59 PM, "Andy Bierman" wrote: > >> Do we really need a standard "action" RPC method container, >> without defining any actual standard actions? >> >> 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 Oct 13 19:28:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYWSW-0006Ka-Hs for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 19:28:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYWSN-0002rn-G7 for netconf-archive@lists.ietf.org; Fri, 13 Oct 2006 19:28:56 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYWMb-000LL3-9m for netconf-data@psg.com; Fri, 13 Oct 2006 23:22:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GYWMa-000LHq-Hz for netconf@ops.ietf.org; Fri, 13 Oct 2006 23:22:48 +0000 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2006 16:22:28 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9DNMRbh024574; Fri, 13 Oct 2006 16:22:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9DNMNOV012624; Fri, 13 Oct 2006 16:22:23 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 16:22:22 -0700 Received: from 10.21.112.145 ([10.21.112.145]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Oct 2006 23:22:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3243601340_1131758" In-Reply-To: <45300CC0.60203@andybierman.com> Content-class: urn:content-classes:message Subject: Re: action RPC I-D Date: Fri, 13 Oct 2006 16:22:20 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: action RPC I-D Thread-Index: AcbvHm39rElaUVsREduxvAAUUR2zPg== From: "Steven Berl \(sberl\)" To: "Andy Bierman" Cc: "Netconf \(E-mail\)" , "Balazs Lengyel" X-OriginalArrivalTime: 13 Oct 2006 23:22:22.0871 (UTC) FILETIME=[6FB33270:01C6EF1E] DKIM-Signature: a=rsa-sha1; q=dns; l=4457; t=1160781747; x=1161645747; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sberl@cisco.com; z=From:=22Steven=20Berl=20\(sberl\)=22=20 |Subject:Re=3A=20action=20RPC=20I-D; X=v=3Dcisco.com=3B=20h=3DWNkwV5VCyY0+kUV5qtqLfNJKyJA=3D; b=ncFunCluGOk8MmM8iWfTiccKLxrtJu8ZM0L4CDoIrQDDW10pCJbJ7kUMan0/kvuUcwGHsVYc RJ5pH2gb9smMTx2Dp57xmyit5uL/9mJsL4bjLU2UYuFD/HUMGRBD1D8s; Authentication-Results: sj-dkim-7.cisco.com; header.From=sberl@cisco.com; dkim=pass ( 26 extraneous bytes; sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3243601340_1131758 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree. I misunderstood which part you were objecting to. -steve On 10/13/06 3:01 PM, "Andy Bierman" wrote: > Steven Berl (sberl) wrote: >> Why wouldn't we define standard actions? Seems like there are several the >> would be useful. Off the top of my head >> >> - reboot >> - file system operations such as: >> - copy >> - delete >> - rename >> - erase/format >> - mkdir >> - ping >> - traceroute >> > > I agree. > But we don't need an extra wrapper to define this. > I.e. > > > > ... > ... > > > > vs. > > > > ping > > ... > ... > > > > > >> -steve > > Andy > >> >> >> On 10/13/06 1:59 PM, "Andy Bierman" wrote: >> >>> Do we really need a standard "action" RPC method container, >>> without defining any actual standard actions? >>> >>> thanks, >>> Andy >>> --B_3243601340_1131758 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIIUwYJKoZIhvcNAQcCoIIIRDCCCEACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bh8wggLYMIICQaADAgECAhBYFfIrIwiObSOOH7tPCDd1MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjEwMTIyMTU3 MjFaFw0wNzEwMTIyMTU3MjFaMEExHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx HjAcBgkqhkiG9w0BCQEWD3NiZXJsQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAJ4hITTKNaKQNFOwZBevkZ1HpMJtnb5xNB+VjLITefpUXt9V5pxckL/RGPpM 7+zhNXX4FxBvW7OoP75gpytu1KDDixxC+mhXS/dSoHY5k7n7a9vXMPIDG0K9DG+B2KOW/aZa mhsJPyTgiNPODUheOQPRfL6UmIRBFRQoiRinhEZgyVzS1IiR/qga4Y6E5CvnlHjS65EmFHVe TxamWbSNICtuWt2VwC6FL8MbUtgnA6W2Bwzy41myrWCMKmzCYUCwaPas3UPrlkrj5VbNjfxt SXMIu/dMOnANqtgyMf8Sx9Dd0CVyUABGTgVXfyEO0X4RfruwPbt6dvAU/zl6Fox8gHECAwEA AaMsMCowGgYDVR0RBBMwEYEPc2JlcmxAY2lzY28uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI hvcNAQEFBQADgYEAjzdD66SDCk557x5OjBraUoalM7kkjWHwtxGu7WZfudc6O4z/svfEIg6R ioJmBjFGfSHgZl104FrdXGRdCJyCyti6Pn1RnDG6ZRD4dGltAYbhJh7dPo7PFeXfiU9Xl2Ro JDEGuLLxAHkIG7pkKl4uLZk+QsCJpyWsHg7OLuDLsxwwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJj WiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenpruf ZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIB ADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMT EVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+v rL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRi x9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECEFgV8isjCI5tI44fu08IN3UwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBRJRmS7vgNyVMrEp3vDowz6jQtc2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNjEwMTMyMzIyMjBaMA0GCSqGSIb3DQEBAQUABIIBAG6DAylvsUkm0SDV h8/xmdGqxquO30Xda65hNwKJ3u7Cr0Y9ea2rLD50Vw18m/9/hNzmQI6od+0PIgGPEo51mKpW DOoR4s5D/f8+ajEHSSNlY23PN6KOgD+5kAmJu1mX/Uojs5YY4lKkDeoWdPz7AbXQpKJxMqY9 blwovynbguAgwWV7W0ogyLSm49FlYdVWQgLApvzDEMocel54D8GBhQ2M5eqELfvcpdPSU1oG rWKsXF+dK05H/9wkvwJxvp15xKlRRZGmgsrRwq53nMKgnGxbY349FUepPsnSWi+o0MrrX2ZP Qg2xqWa+vqYyyd5dUbj0rABRXX6U6vb3BgZ1BD8= --B_3243601340_1131758-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Oct 15 13:36:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ9uj-0008Am-8Q for netconf-archive@lists.ietf.org; Sun, 15 Oct 2006 13:36:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ9ui-00073M-FM for netconf-archive@lists.ietf.org; Sun, 15 Oct 2006 13:36:41 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZ9mG-000GSf-W8 for netconf-data@psg.com; Sun, 15 Oct 2006 17:27:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.5 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZ9mF-000GSE-60 for netconf@ops.ietf.org; Sun, 15 Oct 2006 17:27:56 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9FHLE826801 for ; Sun, 15 Oct 2006 13:21:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F07F.3E37A72A" Subject: Issues for a bit more Discussion - Netconf Notifications Date: Sun, 15 Oct 2006 13:27:48 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40B5B22EC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues for a bit more Discussion - Netconf Notifications Thread-Index: Acbwfzv+RvucjvhJTimx0IF6EaOntg== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F07F.3E37A72A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi As promised, here is the list of issues I think require a bit more discussion. Note that this does not mean that I, as a technical contributor, necessarily disagree with the person who raised the issue or proposed a change. 1. In section 5.2.1.2, do we need this new construct? As this is related to the Beep transport mapping which is currently not properly understood, it is difficult to say for sure. (source Balazs & Andy) a. We should remove any reference to non-existent BEEP modifications in this document. This is not an option. Stuff like this will only get stuck later anyway in the publication process. - The NETCONF over BEEP authors (and others clueful in BEEP) need to provide input on all of sec. 5.2 2. In section 5.3, paragraph 2 seems a bit unclear, and needs punctuation. Explain why it is more important. (source Andy) a. This text came from someone. I don't remember what it means 3. In section 3.2.6.2, it talks about opening either a new session or a new channel on an existing session. Is this appropriate (source: Martin) a. The reason channels were mentioned is that connection conservation is more of an issue with the loss of 'mix-mode' b. Technically, do I run a different session on each channel, rather then how it is currently worded? So, it would be more correct to just talk about sessions and leave multiple channels out of it? 4. In section 3.4, an object called 'lastModified' exists. Should this not be called 'creationTime' instead since we lost the modifySubscription command? (source Martin) a. lastModified is more consistent with SNMP b. What if an implementation defined their own way to modify the subscription. (They could always add their own object later I suppose) 5. In section 3.4, the number of messages sent is defined to be an xs:integer which is not bound, but later in the document (section 4), there is discussion about how sequence numbers roll over the message counter when it reaches its capacity, which is also defined as an xs:integer. These are inconsistent. Change to unsignedInt (Source Martin & Andy) a. In Netconf we have been taking a general policy of not setting limits to things b. Is there any value in forcing implementations to keep this in a number larger then a 32 bit integer? 6. In section 7, replay has a startTime associated with it, which leads to some time-related questions. Is the time associated with the event the time it is logged or the time it was generated, or the time was sent out via Netconf? (source Martin) a. From our implementations perspective, we expect all notifications to contain an event timestamp and we expect logging to happen before it reaches to netconf stack. So, this means we could probably support either the time it was generated or the time it was logged. My preference is the latter. 7. In section 7, why isn't their a symmetrical stopTime. a. From the use cases I've seen, stopTime is present time, so I don't think we need an explicit stopTime to be able to specify something else. 8. Do we still need an identifier called subscription ID (source Andy) a. Given that the base definition of notifications does not support multiple subscriptions per session, do we still need this b. I only have one Netconf session per connection, but still have a session identifier don't I? c. There are a couple of reasons why this is needed. One is to support retrieval of subscription information. We need an identifier that uniquely identifies it. You could argue that this only needs to exist within the XML Schema. d. Yes, as much as we hate to talk about future features, it will be necessary for some optional capabilities that some implementations may choose to support=20 e. Are we using this in more ways then the use cases require? 9. The documentation currently defines appinfo to annotate information in the document. Primarily the maxAccess clause and some module Identity. We can't publish with a dependency on this document since it would block us.=20 a. We talked about just publishing a short little document that would define the appInfo bits we needed, as appose to full data specification b. Andy has suggested instead of maxAccess, moving to config or not config, which I think could also work. State versus statistics would also be a nice distinction to be able to make, but perhaps that can wait. 10. In section 3.1, the URN for Netconf Notifications, is this defined correctly? (source Bert) a. Currently: urn:ietf:params:xml:ns:netconf:notification:1.0 b. Should it be: urn:ietf:params:xml:ns:netconf:capability:notification:1.0 11. Should the XML Schema for retrieving stuff be defined in the main body of the document or in the appendix (source Bert) Sharon Chisholm Nortel=20 Ottawa, Ontario Canada ------_=_NextPart_001_01C6F07F.3E37A72A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issues for a bit more Discussion - Netconf Notifications

Hi

As promised, here = is the list of issues I think require a bit more discussion. Note that = this does not mean that I, as a technical contributor, necessarily = disagree with the person who raised the issue or proposed a = change.

1.      In section 5.2.1.2, do we = need this new construct? As this is related to the Beep transport = mapping which is currently not properly understood, it is difficult to = say for sure. (source Balazs & Andy)

a.      We should remove any reference = to non-existent BEEP modifications in this document.  This is not = an option.  Stuff like this will only get stuck later anyway in the = publication process. - The NETCONF over BEEP authors (and others clueful = in BEEP)  need to provide input on all of sec. = 5.2

2.      In section 5.3, paragraph 2 = seems a bit unclear, and needs punctuation. Explain why it is more = important. (source Andy)

a.      This text came from someone. I = don’t remember what it means
3.      In section 3.2.6.2, it talks = about opening either a new session or a new channel on an existing = session. Is this appropriate (source: Martin)

a.      The reason channels were = mentioned is that connection conservation is more of an issue with the = loss of ‘mix-mode’

        b.      Technically, do I run a different session on each channel, rather = then how it is currently worded? So, it would be more correct to just = talk about sessions and leave multiple channels out of = it?

4.      In section 3.4, an object called = ‘lastModified’ exists. Should this not be called = ‘creationTime’ instead since we lost the modifySubscription = command? (source Martin)

a.      lastModified is more consistent = with SNMP

        b.      What if an implementation defined their own way to modify the = subscription. (They could always add their own object later I = suppose)

5.      In section 3.4, the number of = messages sent is defined to be an xs:integer which is not bound, but = later in the document (section 4), there is discussion about how = sequence numbers roll over the message counter when it reaches its = capacity, which is also defined as an xs:integer. These are = inconsistent. Change to unsignedInt  (Source Martin & = Andy)

a.      In Netconf we have been taking a = general policy of not setting limits to things

        b.      Is there any value in forcing implementations to keep this in a = number larger then a 32 bit integer?

6.      In section 7, replay has a = startTime associated with it, which leads to some time-related = questions. Is the time associated with the event the time it is logged = or the time it was generated, or the time was sent out via Netconf? = (source Martin)

a.      From our implementations = perspective, we expect all notifications to contain an event timestamp = and we expect logging to happen before it reaches to netconf stack. So, = this means we could probably support either the time it was generated or = the time it was logged. My preference is the latter.

7.      In section 7, why isn’t = their a symmetrical stopTime.
a.      From the use cases I’ve = seen, stopTime is present time, so I don’t think we need an = explicit stopTime to be able to specify something = else.

8.      Do we still need an identifier = called subscription ID (source Andy)
a.      Given that the base definition = of notifications does not support multiple subscriptions per session, do = we still need this

        b.      I only have one Netconf session per connection, but still have a = session identifier don’t I?
        c.      There are a couple of reasons = why this is needed. One is to support retrieval of subscription = information. We need an identifier that uniquely identifies it. You = could argue that this only needs to exist within the XML = Schema.

        d.      Yes, as much as we hate to talk = about future features, it will be necessary for some optional = capabilities that some implementations may choose to support =

        e.      Are we using this in more ways = then the use cases require?

9.      The documentation currently = defines appinfo to annotate information in the document. Primarily the = maxAccess clause and some module Identity. We can’t publish with a = dependency on this document since it would block us.

a.      We talked about just publishing = a short little document that would define the appInfo bits we needed, as = appose to full data specification

        b.      Andy has suggested instead of maxAccess, moving to config or not = config, which I think could also work.  State versus statistics = would also be a nice distinction to be able to make, but perhaps that = can wait.

10.     In section 3.1, the URN for Netconf = Notifications, is this defined correctly? (source Bert)
a.      Currently: = urn:ietf:params:xml:ns:netconf:notification:1.0

        b.      Should it be: = urn:ietf:params:xml:ns:netconf:capability:notification:1.0

11.     Should the XML Schema for retrieving = stuff be defined in the main body of the document or in the appendix = (source Bert)


Sharon = Chisholm
Nortel =
Ottawa, = Ontario
Canada

------_=_NextPart_001_01C6F07F.3E37A72A-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Oct 15 13:38:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ9w8-0000th-8S for netconf-archive@lists.ietf.org; Sun, 15 Oct 2006 13:38:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ9w7-0007AO-41 for netconf-archive@lists.ietf.org; Sun, 15 Oct 2006 13:38:08 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZ9hG-000EmL-In for netconf-data@psg.com; Sun, 15 Oct 2006 17:22:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.5 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZ9hD-000El0-SC for netconf@ops.ietf.org; Sun, 15 Oct 2006 17:22: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 k9FHMbX19095 for ; Sun, 15 Oct 2006 13:22:38 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F07E.82797782" Subject: Proposed Edits to Notification Draft Date: Sun, 15 Oct 2006 13:22:31 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40B5B22EB@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Edits to Notification Draft Thread-Index: Acbwfn1aCvgt4y2bT1yp29D2bq69BQ== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 919970d5fe16e84197d564bf094e8b04 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F07E.82797782 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I've gone through all the comments received and compiled this list of edits. Note that the source listed is the source of the issue and may or may not agree with the proposed edit, although any disagreement was not intentional on my part. I'll also be following up this email with a list of issues I think might require a bit more discussion before I'm confident in turning them into editing instructions. But, feel free to disagree with my interpretation of having consensus on these issues as well. Thanks to everyone who took the time to review the document. 1. Make it clearer in the document that the notification feature is an optional capability that builds on the base protocol definitions in the main protocol specification. This would go in the abstraction and section 1, Instruction. (source: Balazs & Bert)=20 2. In abstract and Introduction, don't use the term "Framework". We are not defining a framework. (source Andy) a. This document defines mechanisms which provide an asynchronous event notification delivery service for the NETCONF protocol. It defines the capabilities, operations, transport mappings, and data models needed to support this service. 3. In section 1.1, as managed entity is defined and never used, delete it (source Bert) 4. There are a few instances in the document where agent and manger terminology is used instead of client server. These should be changed to client and server. Note that the Beep transport mapping does use the terminology of agent and manager, so any references within the Beep mapping section should be consistent with the Beep draft. 5. In section 1.1, define term operation. It is used in sections like 2.1.1 without definition. (source Andy) 6. Consistently refer to Subscription ID, and not Subscription Id. (source Bert) 7. Align indenting of XML Schema to enable easier reading. (source Bert) 8. In various examples, change from to to be more consistent (source Andy) 9. In section 1.2 last paragraphs, clarify that the netconf server is not required to process RPC request on the same netconf session. They are still required to process them on other netconf sessions. (source: Balazs) 10. In section 1.3, paragraph three, replace "A capability may be defined", with "A capability may be advertised". (source Andy) 11. In section 1.4, instead of saying that the requirements for the solution are the following, indicate that the following requirements have been addressed by the solution (source Bert) 12. Delete the following requirements from section 1.4 (source: Balazs) a. The solution should not bind subscriptions to a connection b. solution should support agent initiated connections c. channels for configuration change notifications should share fate with a session that includes a configuration channel 13. In section 1.4, clarify the location (on the same box as the netconf server, as oppose to the on the same box as the netconf client) for the following two requirements (source Bert) a. Local logging b. Filtering 14. In section 2.1.1, in create subscription, clarify what happens if both filter and named profile are specified. Is this an error or are they combined? (source Andy). a. Combined. Clarify behaviour. 15. In section 2.1.1, in create subscription (source Andy) a. This should be instead of a element containing the subscription ID. The WG decided there is only one stream active per session. That means there is no need for a subscription ID in the document. 16. In section 2.1.1, in create-subscription, mentioned startTime (source Andy) a. Note that this is only used in the replay command, so I was not sure if it should go here. It is defined later in the replay section. If it makes sense to add it here, I'm fine. 17. In section 2.2.1, mention that is a top level element, to make it clear this is not another RPC method as in the previous section. (source Andy) 18. In section 2.2.1, the Positive Response and Negative Response document format is only for RPC methods, so this text should be removed instead of saying 'none'. The current text is confusing because is a sibling of and and the behaviour for is not relevant. 19. In section 3.2.5.1, replace namespace example.com with real namespace. Align to section 3.2.5.2 (source: Balazs) 20. In section 3.2.5.1, fix references to sessionEventStream and systemEventStream to reflect just eventStream, as defined in the actual schema in section 3.2.5.2 (source Balazs & Bert) 21. In section 3.2.5.1, it does not need to use both and . seems the more appropriate verb since this information is defined as read-only. (source: Balazs & Martin) 22. In section 3.2.5.1, verify order of closing tags (page 13). Also verify the plurality of eventStream versus eventStreams in the tag names (page 14). (Source Bert) 23. In section 3.2.5.2, fix the description clause in which claims this is about subscription retrieval instead of stream retrieval (source Balazs) 24. In section 3.3, clarify the distinction between not being stored in the datastore as appose to not being retrievable via a get operation. Subscriptions are like sessions in that respect. (source Balazs & Andy) 25. Delete section 3.5 (source Andy, others) 26. In section 4, add missing stream tag to subscription definition. Allow for more then one stream to be specified. (source Balazs) 27. In section 4, add missing data to notificationType (source Martin & Balazs) [Editor's note: I swear I've already fixed this at least once already. Gremlins] 28. In section 4, fix errors of missing close element tag. 29. In section 5.1, make corrections as outlined by Martin 30. In section 5, (source Andy) a. - the element in the example should be in a container called . Also, any assumptions about naming and keys in the examples need to be stated. 31. In section 5.2.1.1 remove reference to rpc-one-way message 32. In section 6.1, make corrections as outlined by Martin=20 33. In section 7.1, paragraph 3, the expected warning message need to be more formally defined (aligned with how this was done in the base specification). Define it in 7.5.1 (source: Balazs & Andy) 34. In section 7.1, paragraph 3, it should be clarified why the warning message is required. The subscriber needs to be able to differentiate between when no messages were sent in a given timeframe and when no messages are in the log for a given timeframe (source: Martin) 35. In section 7.1, define an event notification that gets sent when the replay is done to alert the client that replay is completed. The session will also be available to process commands at this point, but I don't believe this is a sufficient way to tell replay is done. (source Martin) 36. In section 7.3, fix replay capability to be uri instead of http. (source Bert & Andy) 37. In section 8 (Security Considerations), add some text as follows: (source Andy & Dave) a. Note that the elements are never sent before the transport layer and the netconf layer (capabilities exchange) have been established, and the manager has been identified and authenticated. b. It is recommended that care be taken to ensure the secure operation of the following commands:=20 i. invocation ii. use of iii. read-only data models iv. read-write data models v. notification content c. One issue related to the notifications draft is the transport of data from non-netconf streams, such as syslog and SNMP. Note that this data may be more vulnerable (or is not more vulnerable) when being transported over netconf than when being transported using the protocol normally used for transporting it, depending on the security credentials of the two subsystems. 38. Misc reference Issues (source Bert) Edits that need to be done if Sharon's tools allow her to 1. Split references into Normative and Informative (Note, I don't think we have any informative references) (source Andy) 2. refs.RFCXXXX instead of RFCXXXX (source Andy) 3. The base protocol specification has headers like , while this draft as create-subscription 4. There is a piece of text that indicates that the IETF has been notified about an IPR claim. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada ------_=_NextPart_001_01C6F07E.82797782 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proposed Edits to Notification Draft

    Hi

    I've gone through = all the comments received and compiled this list of edits. Note that the = source listed is the source of the issue and may or may not agree with = the proposed edit, although any disagreement was not intentional on my = part. I'll also be following up this email with a list of issues I think = might require a bit more discussion before I'm confident in turning them = into editing instructions. But, feel free to disagree with my = interpretation of having consensus on these issues as = well.

    Thanks to = everyone who took the time to review the document.

1.      Make it clearer in the document = that the notification feature is an optional capability that builds on = the base protocol definitions in the main protocol specification.  = This would go in the abstraction and section 1, Instruction. (source: = Balazs & Bert)

    2.      In abstract and Introduction, don’t use the term = “Framework”. We are not defining a framework. (source = Andy)

a.      This document defines mechanisms = which provide an asynchronous event notification delivery service for = the NETCONF protocol.  It defines the capabilities, operations, = transport mappings, and data models needed  to support this = service.

3.      In section 1.1, as managed = entity is defined and never used, delete it (source Bert)

    4.      There are a few instances in the document where agent and manger = terminology is used instead of client server. These should be changed to = client and server. Note that the Beep transport mapping does use the = terminology of agent and manager, so any references within the Beep = mapping section should be consistent with the Beep = draft.

    5.      In section 1.1, define term = operation. It is used in sections like 2.1.1 without definition. (source = Andy)
    6.      Consistently refer to = Subscription ID, and not Subscription Id. (source Bert)
    7.      Align indenting of XML Schema to = enable easier reading. (source Bert)
    8.      In various examples, change from = <neb> to <top> to be more consistent (source = Andy)
    9.      In section 1.2 last paragraphs, = clarify that the netconf server is not required to process RPC request = on the same netconf session. They are still required to process them on = other netconf sessions. (source: Balazs)

    10.     In section 1.3, paragraph three, = replace “A capability may be defined“, with “A = capability may be advertised”. (source Andy)

    11.     In section 1.4, instead of saying = that the requirements for the solution are the following, indicate that = the following requirements have been addressed by the solution (source = Bert)

    12.     Delete the following requirements = from section 1.4 (source: Balazs)

a.      The solution should not bind = subscriptions to a connection

        b.      solution should support agent initiated connections
        c.      channels for configuration = change notifications should share fate with a session that includes a = configuration channel

13.     In section 1.4, clarify the location = (on the same box as the netconf server, as oppose to the on the same box = as the netconf client) for the following two requirements (source = Bert)

a.      Local logging

        b.      Filtering

14.     In section 2.1.1, in create = subscription, clarify what happens if both filter and named profile are = specified. Is this an error or are they combined? (source = Andy).

a.      Combined. Clarify = behaviour.
15.     In section 2.1.1, in create = subscription (source Andy)
a.      This should be <ok> = instead of a <data> element containing the subscription ID.  = The WG decided there is only one stream active per session.  That = means there is no need for a subscription ID in the = document.

16.     In section 2.1.1, in = create-subscription, mentioned startTime (source Andy)
a.      Note that this is only used in = the replay command, so I was not sure if it should go here. It is = defined later in the replay section. If it makes sense to add it here, = I’m fine.

17.     In section 2.2.1, mention that = <notification> is a top level element, to make it clear this is = not another RPC method as in the previous section. (source = Andy)

    18.     In section 2.2.1, the Positive Response and Negative Response = document format is only for RPC methods, so this text should be removed = instead of saying 'none'. The current text is confusing because = <notification> is a sibling of <rpc> and <rpc-reply> = and the behaviour for <rpc-reply> is not = relevant.

    19.     In section 3.2.5.1, replace namespace = example.com with real namespace. Align to section 3.2.5.2 (source: = Balazs)

    20.     In section 3.2.5.1, fix references to = sessionEventStream and systemEventStream to reflect just eventStream, as = defined in the actual schema in section 3.2.5.2 (source Balazs & = Bert)

    21.     In section 3.2.5.1, it does not need = to use both <get> and <get-config>. <get> seems the = more appropriate verb since this information is defined as read-only. = (source: Balazs & Martin)

    22.     In section 3.2.5.1, verify order of = closing tags (page 13). Also verify the plurality of eventStream versus = eventStreams in the tag names (page 14). (Source Bert)

    23.     In section 3.2.5.2, fix the = description clause in <nm:description> which claims this is about = subscription retrieval instead of stream retrieval (source = Balazs)

    24.     In section 3.3, clarify the = distinction between not being stored in the datastore as appose to not = being retrievable via a get operation. Subscriptions are like sessions = in that respect. (source Balazs & Andy)

    25.     Delete section 3.5 (source Andy, = others)
    26.     In section 4, add missing stream tag = to subscription definition. Allow for more then one stream to be = specified. (source Balazs)

    27.     In section 4, add missing data to = notificationType (source Martin & Balazs) [Editor’s note: I = swear I’ve already fixed this at least once already. = Gremlins]

    28.     In section 4, fix errors of missing = close element tag.
    29.     In section 5.1, make corrections as = outlined by Martin
    30.     In section 5, (source = Andy)

a.      - the <interface> element = in the example should be in a container called <interfaces>. Also, = any assumptions about naming and keys in the examples need to be = stated.

31.     In section 5.2.1.1 remove reference = to rpc-one-way message

    32.     In section 6.1, make corrections as outlined by Martin =
    33.     In section 7.1, paragraph 3, the = expected warning message need to be more formally defined (aligned with = how this was done in the base specification).  Define it in 7.5.1 = (source: Balazs & Andy)

    34.     In section 7.1, paragraph 3, it = should be clarified why the warning message is required. The subscriber = needs to be able to differentiate between when no messages were sent in = a given timeframe and when no messages are in the log for a given = timeframe (source: Martin)

    35.     In section 7.1, define an event = notification that gets sent when the replay is done to alert the client = that replay is completed.  The session will also be available to = process commands at this point, but I don’t believe this is a = sufficient way to tell replay is done. (source Martin)

    36.     In section 7.3, fix replay capability = to be uri instead of http. (source Bert & Andy)
    37.     In section 8 (Security = Considerations), add some text as follows: (source Andy & = Dave)

a.      Note that the = <notification> elements are never sent before the transport layer = and the netconf layer (capabilities exchange) have been established, and = the manager has been identified and authenticated.

        b.      It is recommended that care be taken to ensure the secure = operation of the following commands:

i.       = <create-subscription> invocation

            ii.      use of <kill-session>
            iii.     read-only data models
            iv.      read-write data = models
            v.       notification = content

c.      One issue related to the = notifications draft is the transport of data from non-netconf streams, = such as syslog and SNMP. Note that this data may be more vulnerable (or = is not more vulnerable) when being transported over netconf than when = being transported using the protocol normally used for transporting it, = depending on the security credentials of the two = subsystems.

38.     Misc reference Issues (source = Bert)


Edits that need = to be done if Sharon’s tools allow her to

    1. Split references = into Normative and Informative (Note, I don’t think we have any = informative references) (source Andy)
    2. refs.RFCXXXX = instead of RFCXXXX (source Andy)
    3. The base = protocol specification has headers like <get-config>, while this = draft as create-subscription
    4. There is a piece = of text that indicates that the IETF has been notified about an IPR = claim.


Sharon = Chisholm
Nortel =
Ottawa, = Ontario
Canada

------_=_NextPart_001_01C6F07E.82797782-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 03:20:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMmA-0002SL-0i for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 03:20:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZMm7-0004Zw-4g for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 03:20:41 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZMdZ-0000qO-CT for netconf-data@psg.com; Mon, 16 Oct 2006 07:11:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZMdY-0000ov-JQ for netconf@ops.ietf.org; Mon, 16 Oct 2006 07:11:48 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2006 00:11:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9G7BmsO015862; Mon, 16 Oct 2006 00:11:48 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9G7Bmin025885; Mon, 16 Oct 2006 00:11:48 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp100.cisco.com [10.61.64.100]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9G6xtQu007709; Sun, 15 Oct 2006 23:59:56 -0700 Message-ID: <453330B3.8020607@cisco.com> Date: Mon, 16 Oct 2006 09:11:47 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications References: <713043CE8B8E1348AF3C546DBE02C1B40B5B22EC@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B5B22EC@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1566; t=1160982708; x=1161846708; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20Issues=20for=20a=20bit=20more=20Discussion=20-=20Netconf=20Notif ications; X=v=3Dcisco.com=3B=20h=3DFHNmqTWeG1JLjE6/IxaEBfEM9LQ=3D; b=OWiLgoEv/iI0jKJ8M4YVT9MwA1fXb/fUmFzXoJ8BIzQayvjgD4JPEDvkDj/EIJOj8IOX0Ffs xeTD9pRYeyobtPtRNR5tBVNTKZn1BD4uX94jUIyGblr5ZSASK5nubmUv; Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Sharon, > > Hi > > As promised, here is the list of issues I think require a bit more > discussion. Note that this does not mean that I, as a technical > contributor, necessarily disagree with the person who raised the issue > or proposed a change. > > 1. In section 5.2.1.2, do we need this new construct? As this is > related to the Beep transport mapping which is currently not properly > understood, it is difficult to say for sure. (source Balazs & Andy) > > a. We should remove any reference to non-existent BEEP > modifications in this document. This is not an option. Stuff like > this will only get stuck later anyway in the publication process. - > The NETCONF over BEEP authors (and others clueful in BEEP) need to > provide input on all of sec. 5.2 > To be clear, I do not have a huge amount of time to devote to this, and almost assuredly Ken has less. The fundamental issue is what level of acknowledgment you want. If you want NONE, then just use one large MSG that is chunked, and let the client parse the page real time. However, I don't know what XML junkies would say about that. On the other hand, if you want application level acknowledgments, then group the messages into groups you want acknowledged and use MSGs that should be ANSed (this is my recommendation, since you can in effect implement the other approach by using VERY large groupings). Either way, the notifier sends the agent sends the MSGs and the manager sends the responses (RPY for one big page or ANS for multiples). Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 04:49:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOAW-00061v-Fz for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 04:49:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZOAM-0006bI-UO for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 04:49:56 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZO5j-000Lih-At for netconf-data@psg.com; Mon, 16 Oct 2006 08:44:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZO5h-000LiL-Dw for netconf@ops.ietf.org; Mon, 16 Oct 2006 08:44:58 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C621CCC8; Mon, 16 Oct 2006 10:44:28 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 10:44:28 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 10:44:27 +0200 Message-ID: <4533466E.9080103@ericsson.com> Date: Mon, 16 Oct 2006 10:44:30 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> In-Reply-To: <45300CC0.60203@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 08:44:27.0909 (UTC) FILETIME=[4A371B50:01C6F0FF] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hello, I completely agree that there might be standard actions later, but my basic premise is that there will always be vendor specific actions as well. Just as I don't believe we can ever FULLY standardize the data model, the same way I believe we will never be able to standardize all actions. I believe handling non-standard actions is easier if we define them in the data model and not as separate operations. It particularly helps intermediate SW to handle the actions. I agree with Andy that the "end-user" of the action must always understand all new actions whatever the form used to transfer them. However there may be, there will be a number of intermediate SW blocks on the path. I gave a few examples in the draft of intermediate SW, but just as one more possibility to consider, think about the recent sub-agent draft and it's proposed architecture. The master-agent would also delegate the handling of some RPCs to other SW entities. With the generic action it just has to check the calling-point and can forward the action. Also we have already know of working examples of this construct: - LDAP extended operations - Ericsson has a Netconf implementation that misuses the operation to achieve just the same result - Ericsson has a number of other implementations based on other protocols For all these reasons I would ask the workgroup and it's chairmen to consider adopting the topic. Balazs Andy Bierman wrote: > Steven Berl (sberl) wrote: >> Why wouldn't we define standard actions? Seems like there are several the >> would be useful. Off the top of my head >> >> - reboot >> - file system operations such as: >> - copy >> - delete >> - rename >> - erase/format >> - mkdir >> - ping >> - traceroute >> > > I agree. > But we don't need an extra wrapper to define this. > I.e. > > > > ... > ... > > > > vs. > > > > ping > > ... > ... > > > > > >> -steve > > Andy > >> >> >> On 10/13/06 1:59 PM, "Andy Bierman" wrote: >> >>> Do we really need a standard "action" RPC method container, >>> without defining any actual standard actions? >>> >>> thanks, >>> Andy >>> > -- 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 Mon Oct 16 05:13:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOXF-0000Z4-N7 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 05:13:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZOXA-0004aQ-96 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 05:13:25 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZOSM-0001p4-B5 for netconf-data@psg.com; Mon, 16 Oct 2006 09:08:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZOSK-0001no-QV for netconf@ops.ietf.org; Mon, 16 Oct 2006 09:08:21 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5CB5EB84; Mon, 16 Oct 2006 11:08:19 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:08:18 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:08:18 +0200 Message-ID: <45334C02.3070003@ericsson.com> Date: Mon, 16 Oct 2006 11:08:18 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: action RPC I-D References: <452FFE43.4010407@andybierman.com> In-Reply-To: <452FFE43.4010407@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 09:08:18.0748 (UTC) FILETIME=[9F0FCFC0:01C6F102] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Hello, Andy Bierman wrote: > What exactly is an "action"? > It is not defined in this document. [BALAZS]: An action could be basically any management operation. I propose 2 cases when actions are really useful (from the draft): 1) "operations that do not change the configuration data (e.g. ping)" 2) "reading or writing a set of data that form a logical group but might be scattered in different parts of the management data model." For number 1) I interpret your comment as I should have written: "operations where the main aim is an effect that does not change the configuration although the configuration might be changed as a secondary effect." Naturally if you want to misuse action, you could do a action. However you can misuse all other Netconf operations as well, so this is nothing new. I believe it is impossible to give an exact, precise rule that can not be misinterpreted about when to use actions. > > I know "reboot" is an action. > What about "save and reboot" (which changes > config and then does an action)? > > IMO, the agent and manager MUST know the security and > other requirements a priori anyway (via a schema), so > some generic 'container' for actions does not provide any > real value -- just extra XML. > > In your 'restart' example, 'actionName' could just as well be > the actual RPC method name, and 'callingPoint' is really > just an RPC parameter, along with the entire 'parameters' sub-tree. [BALAZS]: You are right, this is also possible. However, I try to say that doing it as a generic action will spare us some problems, work specially with intermediate SW and vendor specific actions. > > How do you manage the allocation of action names? > You propose just xs:string as a data type, and all these > unbounded strings are in the NETCONF namespace. > This implies the WG is going to define the contents, > but that is not stated in the draft. [BALAZS]: Good question, sorry for omitting it. Just some initial ideas: - some other RFCs state that vendor specific extensions should be based on DNS types names to avoid conflicts. > > Do we really need a standard "action" RPC method container, > without defining any actual standard actions? [BALAZS]: generic actions are aimed specifically for management commands that we do not standardize. For standardized commands we still might chose between putting them into generic actions or making them into separate operations. (But I do not want to open this debate, I just say that the options remain open.) > > thanks, > Andy > > > > > -- 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 Mon Oct 16 07:07:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZQJh-00063K-CO for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 07:07:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZQJZ-0003Ye-0g for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 07:07:33 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZQBB-000CxY-Ez for netconf-data@psg.com; Mon, 16 Oct 2006 10:58:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZQBA-000Cx7-3D for netconf@ops.ietf.org; Mon, 16 Oct 2006 10:58:44 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 4FC841B8011; Mon, 16 Oct 2006 12:58:40 +0200 (CEST) Date: Mon, 16 Oct 2006 12:58:30 +0200 (CEST) Message-Id: <20061016.125830.90119364.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: action RPC I-D From: Martin Bjorklund In-Reply-To: <4533466E.9080103@ericsson.com> References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Andy Bierman wrote: > In your 'restart' example, 'actionName' could just as well be > the actual RPC method name, and 'callingPoint' is really > just an RPC parameter, along with the entire 'parameters' sub-tree. and Balazs Lengyel wrote: > I believe handling non-standard actions is easier if we define them > in the data model and not as separate operations. It particularly > helps intermediate SW to handle the actions. I agree with Andy that > the "end-user" of the action must always understand all new actions > whatever the form used to transfer them. However there may be, there > will be a number of intermediate SW blocks on the path. I also agree that a data model effort should allow for operations to be defined within the data model. However, how this is mapped to Netconf rpcs is a different question. An operation could be mapped to a generic rpc, or to a new rpc for each action. I agree with the "intermediate SW argument" though. Andy Bierman wrote: > IMO, the agent and manager MUST know the security and > other requirements a priori anyway (via a schema), so > some generic 'container' for actions does not provide any > real value -- just extra XML. We could apply this argument to e.g. edit-config - why is edit-config needed at all? Vendors could define their own rpcs, and the could have been some parameter (possibly different paramtere names all the time) in . Andy Bierman wrote: > How do you manage the allocation of action names? Without a wrapper each operation name would have to be unique per namespace. With an rpc, the operation could be identified with an "OID" and the action name, which could be a subtree expression or a XPath expression (such as /interfaces/[ifIndex="2"]/reset). This means that the action name would be unique per "object". The callping-point parameter would not be needed in this case either. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 09:42:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSjg-0006EI-4s for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 09:42:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSjd-0005kN-QE for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 09:42:32 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZSfK-0002OA-NL for netconf-data@psg.com; Mon, 16 Oct 2006 13:38:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZSfJ-0002Nc-RI for netconf@ops.ietf.org; Mon, 16 Oct 2006 13:38:02 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GDc1JP025497 for ; Mon, 16 Oct 2006 09:38:01 -0400 Received: (qmail 9027 invoked by uid 78); 16 Oct 2006 13:37:51 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 13:37:51 -0000 Message-ID: <45338B28.9040300@andybierman.com> Date: Mon, 16 Oct 2006 06:37:44 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Eliot Lear CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications References: <713043CE8B8E1348AF3C546DBE02C1B40B5B22EC@zcarhxm2.corp.nortel.com> <453330B3.8020607@cisco.com> In-Reply-To: <453330B3.8020607@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Eliot Lear wrote: > Sharon, >> Hi >> >> As promised, here is the list of issues I think require a bit more >> discussion. Note that this does not mean that I, as a technical >> contributor, necessarily disagree with the person who raised the issue >> or proposed a change. >> >> 1. In section 5.2.1.2, do we need this new construct? As this is >> related to the Beep transport mapping which is currently not properly >> understood, it is difficult to say for sure. (source Balazs & Andy) >> >> a. We should remove any reference to non-existent BEEP >> modifications in this document. This is not an option. Stuff like >> this will only get stuck later anyway in the publication process. - >> The NETCONF over BEEP authors (and others clueful in BEEP) need to >> provide input on all of sec. 5.2 >> > > To be clear, I do not have a huge amount of time to devote to this, and > almost assuredly Ken has less. The fundamental issue is what level of > acknowledgment you want. If you want NONE, then just use one large MSG > that is chunked, and let the client parse the page real time. However, > I don't know what XML junkies would say about that. On the other hand, > if you want application level acknowledgments, then group the messages > into groups you want acknowledged and use MSGs that should be ANSed > (this is my recommendation, since you can in effect implement the other > approach by using VERY large groupings). Either way, the notifier sends > the agent sends the MSGs and the manager sends the responses (RPY for > one big page or ANS for multiples). The WG already decided we do not want app-level ACKs. They are supposed to be removed completely. My comment (a) above is fairly clear -- we cannot create new BEEP features or in any way rely on BEEP features that do not exist in a Proposed Standard RFC. > > Eliot Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 09:44:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSlY-0008SU-Kr for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 09:44:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSlW-0005vA-6B for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 09:44:28 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZSaa-0000xY-CN for netconf-data@psg.com; Mon, 16 Oct 2006 13:33:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZSaZ-0000xI-BS for netconf@ops.ietf.org; Mon, 16 Oct 2006 13:33:07 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GDX6cQ014959 for ; Mon, 16 Oct 2006 09:33:06 -0400 Received: (qmail 8538 invoked by uid 78); 16 Oct 2006 13:33:06 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 13:33:06 -0000 Message-ID: <45338A0B.8020306@andybierman.com> Date: Mon, 16 Oct 2006 06:32:59 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> In-Reply-To: <20061016.125830.90119364.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Martin Bjorklund wrote: > Andy Bierman wrote: >> In your 'restart' example, 'actionName' could just as well be >> the actual RPC method name, and 'callingPoint' is really >> just an RPC parameter, along with the entire 'parameters' sub-tree. > > and > > Balazs Lengyel wrote: >> I believe handling non-standard actions is easier if we define them >> in the data model and not as separate operations. It particularly >> helps intermediate SW to handle the actions. I agree with Andy that >> the "end-user" of the action must always understand all new actions >> whatever the form used to transfer them. However there may be, there >> will be a number of intermediate SW blocks on the path. > > I also agree that a data model effort should allow for operations to > be defined within the data model. However, how this is mapped to > Netconf rpcs is a different question. An operation could be mapped to > a generic rpc, or to a new rpc for each action. > > I agree with the "intermediate SW argument" though. Why? This seems like an implementation-specific detail to me. Your access control model should be more robust than simply allowing user X to do anything called . I don't see what benefit an intermediate SW component can realize if an extra generic container is added to . > > Andy Bierman wrote: >> IMO, the agent and manager MUST know the security and >> other requirements a priori anyway (via a schema), so >> some generic 'container' for actions does not provide any >> real value -- just extra XML. > > We could apply this argument to e.g. edit-config - why is edit-config > needed at all? Vendors could define their own rpcs, and > the could have been some parameter (possibly different > paramtere names all the time) in . > > > Andy Bierman wrote: >> How do you manage the allocation of action names? > > Without a wrapper each operation name would have to be unique > per namespace. With an rpc, the operation could be This is not true. The WG or any vendor could put multiple elements in the same namespace, just as we have and in the same namespace now. > identified with an "OID" and the action name, which could be a subtree > expression or a XPath expression (such as > /interfaces/[ifIndex="2"]/reset). This means that the action name > would be unique per "object". The callping-point parameter would not > be needed in this case either. Why should action RPCs be identified differently than other RPCs? This seems to create complexity, not reduce it. > > > > /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 Mon Oct 16 10:28:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTSV-0004nd-PD for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 10:28:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTSS-00036H-Aq for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 10:28:51 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZTJp-000DDX-TM for netconf-data@psg.com; Mon, 16 Oct 2006 14:19:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZTJo-000DDH-Kz for netconf@ops.ietf.org; Mon, 16 Oct 2006 14:19:53 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 5412D1B8011; Mon, 16 Oct 2006 16:19:51 +0200 (CEST) Date: Mon, 16 Oct 2006 16:19:41 +0200 (CEST) Message-Id: <20061016.161941.13773425.mbj@tail-f.com> To: ietf@andybierman.com Cc: balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D From: Martin Bjorklund In-Reply-To: <45338A0B.8020306@andybierman.com> References: <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> In your 'restart' example, 'actionName' could just as well be > >> the actual RPC method name, and 'callingPoint' is really > >> just an RPC parameter, along with the entire 'parameters' sub-tree. > > > > and > > > > Balazs Lengyel wrote: > >> I believe handling non-standard actions is easier if we define them > >> in the data model and not as separate operations. It particularly > >> helps intermediate SW to handle the actions. I agree with Andy that > >> the "end-user" of the action must always understand all new actions > >> whatever the form used to transfer them. However there may be, there > >> will be a number of intermediate SW blocks on the path. > > > > I also agree that a data model effort should allow for operations to > > be defined within the data model. However, how this is mapped to > > Netconf rpcs is a different question. An operation could be mapped to > > a generic rpc, or to a new rpc for each action. > > > > I agree with the "intermediate SW argument" though. > > Why? > This seems like an implementation-specific detail to me. Yes, since the argument is that it might be easier to design/implement/envision intermediate SW components if the structure of the rpc is well-known; I guess this argument can be rejected as being an implementation issue. > Your access control model should be more robust than > simply allowing user X to do anything called . > I don't see what benefit an intermediate SW component > can realize if an extra generic container is added to . I didn't think of the access control model, but maybe that is a good example. It will be more complicated to design an ACM which has to look into any nested XML structure for a parameter in some format which points to an object. > > Andy Bierman wrote: > >> How do you manage the allocation of action names? > > > > Without a wrapper each operation name would have to be unique > > per namespace. With an rpc, the operation could be > > This is not true. > The WG or any vendor could put multiple elements in the > same namespace, just as we have and > in the same namespace now. I didn't say that there could be a single operation per namespace, I said that the operation name has to be unique within it's namespace. > > identified with an "OID" and the action name, which could be a subtree > > expression or a XPath expression (such as > > /interfaces/[ifIndex="2"]/reset). This means that the action name > > would be unique per "object". The callping-point parameter would not > > be needed in this case either. > > Why should action RPCs be identified differently than other RPCs? > This seems to create complexity, not reduce it. It's not identified differently, I wasn't clear - I meant something like this: /interfaces[ifIndex="2"]/reset more of an OO style I guess - execute the 'reset' action on the '/interface[ifIndex="2"]' object. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 10:46:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTjd-0008A2-5G for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 10:46:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTja-0005Lg-QL for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 10:46:33 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZTYR-000F8F-C0 for netconf-data@psg.com; Mon, 16 Oct 2006 14:34:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZTYQ-000F7y-Bt for netconf@ops.ietf.org; Mon, 16 Oct 2006 14:34:58 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GEYhLI017809 for ; Mon, 16 Oct 2006 10:34:47 -0400 Received: (qmail 17178 invoked by uid 78); 16 Oct 2006 14:34:43 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 14:34:43 -0000 Message-ID: <4533987D.9080209@andybierman.com> Date: Mon, 16 Oct 2006 07:34:37 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: NETCONF Instance Identifiers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi, Several people have requested that we solve this problem. I don't think it needs to be tied to the Notification work, but it is useful for notification content to have a common way to describe a particular instance of an XML element within a NETCONF data model. It seems to me this problem is fairly simple. It seems to me we could agree on naming without agreeing on any particular data modeling language constructs, because an instance identifier is just an absolute Xpath expression. Here is something to throw darts at, and see how much consensus exists on this issue: ================================================================================== NETCONF Instance Identifiers An instance of an element is defined by its absolute path from the root. 1) There is a 'fixed' root, starting at , for methods and data. There is also a conceptual 'relative' root for data. This is unnamed, and will be called or or in a NETCONF PDU. There is no default namespace associated with the root. 2) An absolute Xpath expression containing all relevant conceptual INDEX (key) components represents an instance. Order within an INDEX is significant. The leftmost INDEX component is the major index. Each minor index in succession is listed left to right. E.g.: is a table indexed by x and y: /foo/bar[x="3",y="4"] E.g.: is a table indexed by a name string: /foo/bar[x="3",y="4"]/baz[name="fred"] 3) Unnamed instances (e.g. maxOccurs="unbounded") are identified by their position (relative to other instances of the same element), using a special INDEX component called 'position'. Unnamed instances are numbered starting at zero. Conceptually, all unnamed, single-instance elements can be identified as position="0". E.g.: is a simple type that can occur 0 or more times /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"] 4) RPC methods are identified by their path from the absolute root, and instance identifiers used within elements may identify the entire path to the element. /rpc/edit-config/error-option /rpc/edit-config/config/interfaces/interface[name="eth0"] 5) If namespaces are used then components within the Xpath expression must consist of properly formatted Qualified Names. /nc:rpc/edit-config/config/acme:interfaces/interface[name="eth0"] =========================================================================== Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 10:53:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTqo-0002Nu-Q1 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 10:53:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTqh-0006Xm-W4 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 10:53:58 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZTiU-000Gc7-MB for netconf-data@psg.com; Mon, 16 Oct 2006 14:45:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZTiT-000Gbn-5E for netconf@ops.ietf.org; Mon, 16 Oct 2006 14:45:22 +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 k9GEjD1Z023987; Mon, 16 Oct 2006 07:45:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k9GEjCu67400; Mon, 16 Oct 2006 07:45:12 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k9GEj8wn092718; Mon, 16 Oct 2006 10:45:08 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200610161445.k9GEj8wn092718@idle.juniper.net> To: Martin Bjorklund cc: ietf@andybierman.com, balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D In-Reply-To: Your message of "Mon, 16 Oct 2006 16:19:41 +0200." <20061016.161941.13773425.mbj@tail-f.com> Date: Mon, 16 Oct 2006 10:45:08 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Martin Bjorklund writes: >It's not identified differently, I wasn't clear - I meant something >like this: > > > /interfaces[ifIndex="2"]/reset > > >more of an OO style I guess - execute the 'reset' action on the >'/interface[ifIndex="2"]' object. We have a rich history of failed OO-ish approaches. IMHO the key to netconf lies in leveraging the existing infrastructure of existing CLIs. CLIs are not oriented toward this sort of approach, but use more direct action verbs: reset interface 2 ping foo.net reboot install new-sw.tgz which translate easily into direct RPCs: foo.net Options from the "ping" command become xml elements under the element. Imagine trying to encode options under a string like "/interfaces[ifIndex="2"]/reset". In addition, using a string loses all the specificity that an XML schema tries to buy you. Your only tool to restrict the content of a string is a regex, which, well, stinks when compared with the descriptive capabilities of schema for a element and its contents. >Yes, since the argument is that it might be easier to >design/implement/envision intermediate SW components if the structure >of the rpc is well-known; I guess this argument can be rejected as >being an implementation issue. Let the schema (or whatever your schema is generated from) drive your intermediate SW components. If your command hierarchy (and/or config hierarchy) drives your xml content, then the same internal data can drive it all. XML schemas, XML parsers, and command parsers all groking the same data will help keep the schema, API, and CLI in sync. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 11:21:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUHZ-0001Kj-KN for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 11:21:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUHV-0001o1-8x for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 11:21:37 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZU0n-000K92-5X for netconf-data@psg.com; Mon, 16 Oct 2006 15:04:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZU0m-000K8a-H1 for netconf@ops.ietf.org; Mon, 16 Oct 2006 15:04:16 +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 k9GF2sX84694 for ; Mon, 16 Oct 2006 08:04:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k9GF2nu72198; Mon, 16 Oct 2006 08:02:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k9GF2nwn092786; Mon, 16 Oct 2006 11:02:49 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200610161502.k9GF2nwn092786@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: NETCONF Instance Identifiers In-Reply-To: Your message of "Mon, 16 Oct 2006 07:34:37 PDT." <4533987D.9080209@andybierman.com> Date: Mon, 16 Oct 2006 11:02:49 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Andy Bierman writes: >1) There is a 'fixed' root, starting at , for methods > and data. There is also a conceptual 'relative' root for data. > This is unnamed, and will be called or or > in a NETCONF PDU. There is no default namespace associated with > the root. or ? > /foo/bar[x="3",y="4"] Stick w/ xpath syntax and use "and": /foo/bar[x=3 and y=4] >3) Unnamed instances (e.g. maxOccurs="unbounded") are identified > by their position (relative to other instances of the same element), > using a special INDEX component called 'position'. Unnamed > instances are numbered starting at zero. Conceptually, all > unnamed, single-instance elements can be identified as position="0". > > E.g.: is a simple type that can occur 0 or more times > > /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"] This makes "position" a magic token. In XPath, position() is a function that does approximately the same thing (origin 1). goo[position() = 3] >4) RPC methods are identified by their path from the absolute root, > and instance identifiers used within elements may identify > the entire path to the element. > > /rpc/edit-config/error-option > > /rpc/edit-config/config/interfaces/interface[name="eth0"] I don't follow you here. Why would an xpath originated at /rpc/ be valuable? >5) If namespaces are used then components within the Xpath expression > must consist of properly formatted Qualified Names. > /nc:rpc/edit-config/config/acme:interfaces/interface[name="eth0"] Yup, and don't forget the joys of namespaces and attributes. But I feel like I'm missing something. Aren't we really needing something in the schema that defines what elemenents are identifiers, rather than XPath syntax for it? My developer/app needs to know that the "interface" element is identified by the "name" element and the most convenient place to "know" this is the schema that defines the "interface" element. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 11:34:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUTx-0006ho-E9 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 11:34:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUTv-0002xo-3O for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 11:34:25 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZUNn-0001au-LX for netconf-data@psg.com; Mon, 16 Oct 2006 15:28:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZUNm-0001ae-Ap for netconf@ops.ietf.org; Mon, 16 Oct 2006 15:28:02 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2006 08:28:02 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GFS16S002535; Mon, 16 Oct 2006 08:28:01 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9GFS1W4003872; Mon, 16 Oct 2006 08:28:01 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp100.cisco.com [10.61.64.100]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9GFG7sw018994; Mon, 16 Oct 2006 08:16:08 -0700 Message-ID: <4533A500.8080201@cisco.com> Date: Mon, 16 Oct 2006 17:28:00 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Andy Bierman CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications References: <713043CE8B8E1348AF3C546DBE02C1B40B5B22EC@zcarhxm2.corp.nortel.com> <453330B3.8020607@cisco.com> <45338B28.9040300@andybierman.com> In-Reply-To: <45338B28.9040300@andybierman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=684; t=1161012481; x=1161876481; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20Issues=20for=20a=20bit=20more=20Discussion=20-=20Netconf=20Notif ications; X=v=3Dcisco.com=3B=20h=3DWqNgINFglWZPyy9HxCtwgVoK6Fg=3D; b=YW4RUWn1PlpTeygM3P4KDnZtug/hVW/Bxrgo//wklQqW+xMvfJxS5brJ2gx5RjigwS45mJJG L8XUdkGPUrjNOOZtyT6pyLDdqcU9suYE9ikfZ5KMIXHENuR2/mo3k21X; Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Andy, > The WG already decided we do not want app-level ACKs. > They are supposed to be removed completely. My point was that you get this for free with BEEP (like so many other things) simply by choosing your grouping of messages and how you would process them (e.g., not waiting for the whole page). You really need no additional PROTOCOL support for those acknowledgments (although some additional *application library* support on the part of the agent would be necessary). > > My comment (a) above is fairly clear -- we cannot create > new BEEP features or in any way rely on BEEP features that do > not exist in a Proposed Standard RFC. I agree. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 11:39:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUYo-0002Zi-Ml for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 11:39:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUYl-0003UK-1u for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 11:39:26 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZUSa-0002Cg-1A for netconf-data@psg.com; Mon, 16 Oct 2006 15:33:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZUSY-0002C8-Mj for netconf@ops.ietf.org; Mon, 16 Oct 2006 15:32:59 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GFWedh025634 for ; Mon, 16 Oct 2006 11:32:50 -0400 Received: (qmail 9469 invoked by uid 78); 16 Oct 2006 15:32:40 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 15:32:40 -0000 Message-ID: <4533A611.9060409@andybierman.com> Date: Mon, 16 Oct 2006 08:32:33 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Phil Shafer CC: "Netconf (E-mail)" Subject: Re: NETCONF Instance Identifiers References: <200610161502.k9GF2nwn092786@idle.juniper.net> In-Reply-To: <200610161502.k9GF2nwn092786@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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Phil Shafer wrote: > Andy Bierman writes: >> 1) There is a 'fixed' root, starting at , for methods >> and data. There is also a conceptual 'relative' root for data. >> This is unnamed, and will be called or or >> in a NETCONF PDU. There is no default namespace associated with >> the root. > > or ? /rpc for RPC methods and relative root == == , etc.) for data > >> /foo/bar[x="3",y="4"] > > Stick w/ xpath syntax and use "and": OK > > /foo/bar[x=3 and y=4] > >> 3) Unnamed instances (e.g. maxOccurs="unbounded") are identified >> by their position (relative to other instances of the same element), >> using a special INDEX component called 'position'. Unnamed >> instances are numbered starting at zero. Conceptually, all >> unnamed, single-instance elements can be identified as position="0". >> >> E.g.: is a simple type that can occur 0 or more times >> >> /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"] > > This makes "position" a magic token. In XPath, position() is a > function that does approximately the same thing (origin 1). > > goo[position() = 3] OK > >> 4) RPC methods are identified by their path from the absolute root, >> and instance identifiers used within elements may identify >> the entire path to the element. >> >> /rpc/edit-config/error-option >> >> /rpc/edit-config/config/interfaces/interface[name="eth0"] > > I don't follow you here. Why would an xpath originated at > /rpc/ be valuable? It is needed to identify the bad parameter, which could be just as well as something in the data underneath > >> 5) If namespaces are used then components within the Xpath expression >> must consist of properly formatted Qualified Names. >> /nc:rpc/edit-config/config/acme:interfaces/interface[name="eth0"] > > Yup, and don't forget the joys of namespaces and attributes. > > But I feel like I'm missing something. Aren't we really needing > something in the schema that defines what elemenents are identifiers, > rather than XPath syntax for it? My developer/app needs to know > that the "interface" element is identified by the "name" element > and the most convenient place to "know" this is the schema that > defines the "interface" element. Yes we do need that to tell the tools about the data structure. We do not need that to identify data instances within elements. Using a common format for a conceptual instance identifier is useful beyond this 1 element of course, but currently out of scope. But if we decide to create a standard 'config-change' notification, then it will be useful to identify what changed without returning all the changed XML. > > 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 Mon Oct 16 12:12:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZV5H-0005k4-5P for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:12:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZV5E-0008LE-SM for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:12:59 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZUyS-0007Yq-Kx for netconf-data@psg.com; Mon, 16 Oct 2006 16:05:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZUyR-0007YV-Vf for netconf@ops.ietf.org; Mon, 16 Oct 2006 16:05:56 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GG5hlW001332 for ; Mon, 16 Oct 2006 12:05:48 -0400 Received: (qmail 11019 invoked by uid 78); 16 Oct 2006 16:05:43 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 16:05:43 -0000 Message-ID: <4533ADCF.1090704@andybierman.com> Date: Mon, 16 Oct 2006 09:05:35 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Phil Shafer CC: "Netconf (E-mail)" Subject: Re: NETCONF Instance Identifiers References: <200610161502.k9GF2nwn092786@idle.juniper.net> In-Reply-To: <200610161502.k9GF2nwn092786@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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi Phil, .... >> /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"] Xpath position() is 1 .. N based, and does not seem to be needed: /foo/goo[position()=3] == /foo/goo[3] So this example should be: /foo/bar[x=3 and y=4]/baz[name='fred']/zoo/goo[3] I like concise 'C' style syntax better of course: foo.bar[3,4].baz[fred].zoo.goo[2] but it isn't XMLish enough, so never mind. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 12:45:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVap-0007qo-Ti for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:45:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVal-0005U7-Fl for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:45:35 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVVJ-000Ikx-HQ for netconf-data@psg.com; Mon, 16 Oct 2006 16:39:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVVH-000IkO-1c for netconf@ops.ietf.org; Mon, 16 Oct 2006 16:39:52 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A65B15AE2E; Mon, 16 Oct 2006 18:39:49 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04571-06; Mon, 16 Oct 2006 18:39:46 +0200 (CEST) Received: from noname.localhost (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id BB5525AD99; Mon, 16 Oct 2006 18:39:46 +0200 (CEST) Received: by noname.localhost (Postfix, from userid 501) id D2BD7810182; Mon, 16 Oct 2006 18:39:45 +0200 (CEST) Date: Mon, 16 Oct 2006 18:39:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Netconf (E-mail)" Subject: Re: NETCONF Instance Identifiers Message-ID: <20061016163945.GA9465@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , "Netconf (E-mail)" References: <4533987D.9080209@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4533987D.9080209@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Mon, Oct 16, 2006 at 07:34:37AM -0700, Andy Bierman wrote: > Several people have requested that we solve this problem. > I don't think it needs to be tied to the Notification work, > but it is useful for notification content to have a common way to describe > a particular instance of an XML element within a NETCONF data model. > > It seems to me this problem is fairly simple. > It seems to me we could agree on naming without agreeing > on any particular data modeling language constructs, > because an instance identifier is just an absolute Xpath expression. Using xpath (or a subset of it) is fine with me. I note, however, that once we go down this path, we have a situation where we use instance identifiers where subtree filtering is unable to select such instances. Personally, I believe this is fine since I disliked the introduction of subtree filtering in the first place... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 12:46:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVbP-00005I-Qf for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:46:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVbO-0005aN-Hr for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:46:11 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVVy-000Is3-T0 for netconf-data@psg.com; Mon, 16 Oct 2006 16:40:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVVx-000Irm-RY for netconf@ops.ietf.org; Mon, 16 Oct 2006 16:40:34 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 883F91B8011; Mon, 16 Oct 2006 18:40:31 +0200 (CEST) Date: Mon, 16 Oct 2006 18:40:21 +0200 (CEST) Message-Id: <20061016.184021.35020155.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D From: Martin Bjorklund In-Reply-To: <200610161445.k9GEj8wn092718@idle.juniper.net> References: <20061016.161941.13773425.mbj@tail-f.com> <200610161445.k9GEj8wn092718@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Phil Shafer wrote: > Options from the "ping" command become xml elements under the > element. Imagine trying to encode options under a > string like "/interfaces[ifIndex="2"]/reset". This string is just to identify the action. In Balazs' draft, this identifier is split into two parts, the and the . Parameters are passed with in element in his draft. They would not be "encoded" into the action name. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 12:54:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVje-0002rX-Ot for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:54:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVjd-0007VM-Fu for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:54:42 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVfI-000KYj-IE for netconf-data@psg.com; Mon, 16 Oct 2006 16:50:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVfH-000KYQ-J0 for netconf@ops.ietf.org; Mon, 16 Oct 2006 16:50:11 +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 k9GGns1Z025968; Mon, 16 Oct 2006 09:49:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k9GGnsu02540; Mon, 16 Oct 2006 09:49:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k9GGncwn093184; Mon, 16 Oct 2006 12:49:38 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200610161649.k9GGncwn093184@idle.juniper.net> To: Martin Bjorklund cc: ietf@andybierman.com, balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D In-Reply-To: Your message of "Mon, 16 Oct 2006 18:40:21 +0200." <20061016.184021.35020155.mbj@tail-f.com> Date: Mon, 16 Oct 2006 12:49:38 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Martin Bjorklund writes: >Phil Shafer wrote: >> Options from the "ping" command become xml elements under the >> element. Imagine trying to encode options under a >> string like "/interfaces[ifIndex="2"]/reset". > >This string is just to identify the action. In Balazs' draft, this >identifier is split into two parts, the and the >. Parameters are passed with in element in his >draft. They would not be "encoded" into the action name. Okay, an action has a name, a target, and a set of parameters. Your suggestion puts the name and the target in a string which is uncontrolled and undocumented (as far as schema). Putting the parameters in an element won't help you constrain them, since the constraints need to be tied to the particular action. So the question is: what does a generic action buy you? And are you trade that against what a schema-friendly RPC buys you? Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 12:58:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVnQ-0005g0-Oh for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:58:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVnP-00088r-FX for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 12:58:36 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVjK-000L8a-Lr for netconf-data@psg.com; Mon, 16 Oct 2006 16:54:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZVjK-000L8G-0d for netconf@ops.ietf.org; Mon, 16 Oct 2006 16:54:22 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id EB75D1B8011; Mon, 16 Oct 2006 18:54:20 +0200 (CEST) Date: Mon, 16 Oct 2006 18:54:11 +0200 (CEST) Message-Id: <20061016.185411.50364525.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers From: Martin Bjorklund In-Reply-To: <4533987D.9080209@andybierman.com> References: <4533987D.9080209@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Andy Bierman wrote: > Hi, > > Several people have requested that we solve this problem. > I don't think it needs to be tied to the Notification work, > but it is useful for notification content to have a common way to describe > a particular instance of an XML element within a NETCONF data model. > > It seems to me this problem is fairly simple. > It seems to me we could agree on naming without agreeing > on any particular data modeling language constructs, > because an instance identifier is just an absolute Xpath expression. With the XPath fixes already suggested, I think this is excellent. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 13:52:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWdR-0000lj-Vu for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 13:52:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWdQ-0002dY-Lq for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 13:52:21 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZWVP-0006UG-PX for netconf-data@psg.com; Mon, 16 Oct 2006 17:44:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZWVO-0006TT-Ri for netconf@ops.ietf.org; Mon, 16 Oct 2006 17:44:03 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 7F2001B8011; Mon, 16 Oct 2006 19:44:01 +0200 (CEST) Date: Mon, 16 Oct 2006 19:43:51 +0200 (CEST) Message-Id: <20061016.194351.48692922.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D From: Martin Bjorklund In-Reply-To: <200610161649.k9GGncwn093184@idle.juniper.net> References: <20061016.184021.35020155.mbj@tail-f.com> <200610161649.k9GGncwn093184@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Phil Shafer wrote: > Martin Bjorklund writes: > >Phil Shafer wrote: > >> Options from the "ping" command become xml elements under the > >> element. Imagine trying to encode options under a > >> string like "/interfaces[ifIndex="2"]/reset". > > > >This string is just to identify the action. In Balazs' draft, this > >identifier is split into two parts, the and the > >. Parameters are passed with in element in his > >draft. They would not be "encoded" into the action name. > > Okay, an action has a name, a target, and a set of parameters. > Your suggestion puts the name and the target in a string which > is uncontrolled and undocumented (as far as schema). Putting > the parameters in an element won't help you constrain them, > since the constraints need to be tied to the particular action. No, they wouldn't be uncontrolled, just as parameters within an edit-config are not uncontrolled. But anyway, I just said that I do agree with the "intermediate SW argument", i.e. using a well-known rpc might make it easier to write this kind of software. As an example, suppose you have a set of hosts, each with a set of services, and a service can be reset. Using a normal rpc, this reset could be: foo web now Using the , with Balazs syntax, /hosts/host[name="foo"]/service[name="foo"] reset now My only point is that the latter might be easier for a SW component like a master agent. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 13:55:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWgM-0003xi-JV for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 13:55:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWgL-0003HJ-9y for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 13:55:22 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZWat-0008Kp-R6 for netconf-data@psg.com; Mon, 16 Oct 2006 17:49:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZWat-0008KC-1k for netconf@ops.ietf.org; Mon, 16 Oct 2006 17:49:43 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id EE2AF1B8011; Mon, 16 Oct 2006 19:49:40 +0200 (CEST) Date: Mon, 16 Oct 2006 19:49:31 +0200 (CEST) Message-Id: <20061016.194931.122337557.mbj@tail-f.com> To: j.schoenwaelder@iu-bremen.de Cc: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers From: Martin Bjorklund In-Reply-To: <20061016163945.GA9465@boskop.local> References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Juergen Schoenwaelder wrote: > On Mon, Oct 16, 2006 at 07:34:37AM -0700, Andy Bierman wrote: > > > Several people have requested that we solve this problem. > > I don't think it needs to be tied to the Notification work, > > but it is useful for notification content to have a common way to describe > > a particular instance of an XML element within a NETCONF data model. > > > > It seems to me this problem is fairly simple. > > It seems to me we could agree on naming without agreeing > > on any particular data modeling language constructs, > > because an instance identifier is just an absolute Xpath expression. > > Using xpath (or a subset of it) is fine with me. I note, however, that > once we go down this path, we have a situation where we use instance > identifiers where subtree filtering is unable to select such > instances. You mean b/c of the use of position()? I assume that position() would be used only when the data model indicates that there is a set of instances, but they don't have a key. So I guess the real issue is that if the data model allows instances without keys, then subtree filtering can't be used to select such instances. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 14:16:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZX0R-0006lm-TV for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 14:16:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWqz-0006yQ-V1 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 14:06:23 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZWlS-000BtB-DV for netconf-data@psg.com; Mon, 16 Oct 2006 18:00:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZWlR-000BsG-9R for netconf@ops.ietf.org; Mon, 16 Oct 2006 18:00:37 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GI0Ljw018569 for ; Mon, 16 Oct 2006 14:00:28 -0400 Received: (qmail 30808 invoked by uid 78); 16 Oct 2006 18:00:21 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 18:00:21 -0000 Message-ID: <4533C8AE.4000507@andybierman.com> Date: Mon, 16 Oct 2006 11:00:14 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D References: <20061016.184021.35020155.mbj@tail-f.com> <200610161649.k9GGncwn093184@idle.juniper.net> <20061016.194351.48692922.mbj@tail-f.com> In-Reply-To: <20061016.194351.48692922.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >... > But anyway, I just said that I do agree with the "intermediate SW > argument", i.e. using a well-known rpc might make it easier > to write this kind of software. > > As an example, suppose you have a set of hosts, each with a set of > services, and a service can be reset. Using a normal rpc, this reset > could be: > > > foo > web > now > > > Using the , with Balazs syntax, > > > /hosts/host[name="foo"]/service[name="foo"] > reset > > now > > > > My only point is that the latter might be easier for a SW component > like a master agent. > IMO this is an implementation choice. I prefer the former approach because I already have SW components that auto-generate PDU fragments based on the element in the existing netconf-prot document. Plus, the less XML layers the better. I also agree with Phil that the version is more XSD-friendly. Some people prefer not to couple all the 'action' RPC implementation details together. Others may prefer a common gateway approach. The RPC method could use internal (implementation specific) mechanisms to convert the XML parameters to different forms. Exposing the complex RPC to managers seems to make things harder on the manager than the version in your example. > > /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 Mon Oct 16 15:06:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXmz-0007gJ-Gs for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:06:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXdW-000342-A1 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 14:56:31 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZXWo-0001Bq-22 for netconf-data@psg.com; Mon, 16 Oct 2006 18:49:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZXWm-0001BG-Ge for netconf@ops.ietf.org; Mon, 16 Oct 2006 18:49:33 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2DA4E5AE69; Mon, 16 Oct 2006 20:49:31 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14960-09; Mon, 16 Oct 2006 20:49:28 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 06FF55AE4A; Mon, 16 Oct 2006 20:49:28 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 286D381028C; Mon, 16 Oct 2006 20:49:25 +0200 (CEST) Date: Mon, 16 Oct 2006 20:49:25 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers Message-ID: <20061016184925.GA9592@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Martin Bjorklund , netconf@ops.ietf.org References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061016.194931.122337557.mbj@tail-f.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Mon, Oct 16, 2006 at 07:49:31PM +0200, Martin Bjorklund wrote: > > Using xpath (or a subset of it) is fine with me. I note, however, that > > once we go down this path, we have a situation where we use instance > > identifiers where subtree filtering is unable to select such > > instances. > > You mean b/c of the use of position()? I assume that position() would > be used only when the data model indicates that there is a set of > instances, but they don't have a key. So I guess the real issue is > that if the data model allows instances without keys, then subtree > filtering can't be used to select such instances. This argument sounds backwards to me. We either allow things like position() or we don't. If we allow such things (which I do like and support), then we simply have an instance identification mechanism which has more expressive power than subtree filtering has (and it is IMHO irrelevant whether you have other keys that can identify the same instance or not). I strongly dislike an approach where certain xpath features (like position()) may only be used under some conditions. Given the SMIv2 experience with special cases and the implied consistency language rules, I strongly prefer to avoid special case constructions. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 15:11:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXs5-00051y-Od for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:11:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXs4-0006b6-Bu for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:11:33 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZXnV-0004zk-W3 for netconf-data@psg.com; Mon, 16 Oct 2006 19:06:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZXnU-0004xW-Fw for netconf@ops.ietf.org; Mon, 16 Oct 2006 19:06:48 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GJ6ijr006934 for ; Mon, 16 Oct 2006 15:06:45 -0400 Received: (qmail 14071 invoked by uid 78); 16 Oct 2006 19:06:44 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 19:06:44 -0000 Message-ID: <4533D83E.6090400@andybierman.com> Date: Mon, 16 Oct 2006 12:06:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> In-Reply-To: <20061016184925.GA9592@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Juergen Schoenwaelder wrote: > On Mon, Oct 16, 2006 at 07:49:31PM +0200, Martin Bjorklund wrote: > >>> Using xpath (or a subset of it) is fine with me. I note, however, that >>> once we go down this path, we have a situation where we use instance >>> identifiers where subtree filtering is unable to select such >>> instances. >> You mean b/c of the use of position()? I assume that position() would >> be used only when the data model indicates that there is a set of >> instances, but they don't have a key. So I guess the real issue is >> that if the data model allows instances without keys, then subtree >> filtering can't be used to select such instances. > > This argument sounds backwards to me. We either allow things like > position() or we don't. > > If we allow such things (which I do like and support), then we simply > have an instance identification mechanism which has more expressive > power than subtree filtering has (and it is IMHO irrelevant whether > you have other keys that can identify the same instance or not). > > I strongly dislike an approach where certain xpath features (like > position()) may only be used under some conditions. Given the SMIv2 > experience with special cases and the implied consistency language > rules, I strongly prefer to avoid special case constructions. > IMO we want the simplest approach possible. This does not impact in PDUs. It is a simple canonical format for identifying ONE instance of an element. It is not intended to be some sort of filtering tool. > /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 Mon Oct 16 15:11:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXs7-00055a-Ng for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:11:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXs5-0006bH-DG for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:11:35 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZXmP-0004kx-2E for netconf-data@psg.com; Mon, 16 Oct 2006 19:05:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZXmO-0004kh-5w for netconf@ops.ietf.org; Mon, 16 Oct 2006 19:05:40 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 4278E1B8011; Mon, 16 Oct 2006 21:05:39 +0200 (CEST) Date: Mon, 16 Oct 2006 21:05:29 +0200 (CEST) Message-Id: <20061016.210529.02341268.mbj@tail-f.com> To: j.schoenwaelder@iu-bremen.de Cc: netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers From: Martin Bjorklund In-Reply-To: <20061016184925.GA9592@boskop.local> References: <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Juergen Schoenwaelder wrote: > On Mon, Oct 16, 2006 at 07:49:31PM +0200, Martin Bjorklund wrote: > > > > Using xpath (or a subset of it) is fine with me. I note, however, that > > > once we go down this path, we have a situation where we use instance > > > identifiers where subtree filtering is unable to select such > > > instances. > > > > You mean b/c of the use of position()? I assume that position() would > > be used only when the data model indicates that there is a set of > > instances, but they don't have a key. So I guess the real issue is > > that if the data model allows instances without keys, then subtree > > filtering can't be used to select such instances. > > This argument sounds backwards to me. We either allow things like > position() or we don't. > > If we allow such things (which I do like and support), then we simply > have an instance identification mechanism which has more expressive > power than subtree filtering has (and it is IMHO irrelevant whether > you have other keys that can identify the same instance or not). Ok. So you mean that these two identifiers would be ok? /interface[name="eth0"] and /interface[2] One problem with the second alternative is that it's difficult to know whether the string will identify the same object over time, since interfaces might come and go. > I strongly dislike an approach where certain xpath features (like > position()) may only be used under some conditions. Are you suggesting that any XPath construct should be valid in an Instance Identifier? Or do you mean that if position() can be used in some places in an Instance Identifier, then it should be possible to use it anywhere in the Instance Identifier? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 15:31:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYAu-0007ST-2P for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:31:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYAs-0002P0-La for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:31:00 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZY5G-000AOW-Jz for netconf-data@psg.com; Mon, 16 Oct 2006 19:25:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZY5F-000ANx-Rw for netconf@ops.ietf.org; Mon, 16 Oct 2006 19:25:10 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GJP4fU023471 for ; Mon, 16 Oct 2006 15:25:05 -0400 Received: (qmail 2641 invoked by uid 78); 16 Oct 2006 19:25:04 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 19:25:04 -0000 Message-ID: <4533DC89.6010206@andybierman.com> Date: Mon, 16 Oct 2006 12:24:57 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers References: <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <20061016.210529.02341268.mbj@tail-f.com> In-Reply-To: <20061016.210529.02341268.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Oct 16, 2006 at 07:49:31PM +0200, Martin Bjorklund wrote: >> >>>> Using xpath (or a subset of it) is fine with me. I note, however, that >>>> once we go down this path, we have a situation where we use instance >>>> identifiers where subtree filtering is unable to select such >>>> instances. >>> You mean b/c of the use of position()? I assume that position() would >>> be used only when the data model indicates that there is a set of >>> instances, but they don't have a key. So I guess the real issue is >>> that if the data model allows instances without keys, then subtree >>> filtering can't be used to select such instances. >> This argument sounds backwards to me. We either allow things like >> position() or we don't. >> >> If we allow such things (which I do like and support), then we simply >> have an instance identification mechanism which has more expressive >> power than subtree filtering has (and it is IMHO irrelevant whether >> you have other keys that can identify the same instance or not). > > Ok. So you mean that these two identifiers would be ok? > > /interface[name="eth0"] and /interface[2] No -- IMO producing the correct instance ID requires the SW to know the data model. For named data, the canonical instance ID must use the naming components. The position identifier is only the canonical ID for unnamed data. Again -- let's be clear to distinguish an Xpath expression used in NETCONF PDU constructs as a selector (e.g., ) and PDU constructs used as an Instance Identifier (e.g., ). For the latter, we want a simple, constrained, canonical format. We have no constraints on the former. > > One problem with the second alternative is that it's difficult to know > whether the string will identify the same object over time, since > interfaces might come and go. > >> I strongly dislike an approach where certain xpath features (like >> position()) may only be used under some conditions. > > Are you suggesting that any XPath construct should be valid in an > Instance Identifier? Or do you mean that if position() can be used in > some places in an Instance Identifier, then it should be possible to > use it anywhere in the Instance Identifier? > > > /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 Mon Oct 16 15:46:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYQD-0003ru-38 for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:46:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYOH-0003x3-Md for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:44:52 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZYKX-000FGW-KO for netconf-data@psg.com; Mon, 16 Oct 2006 19:40:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZYKW-000FG7-Ke for netconf@ops.ietf.org; Mon, 16 Oct 2006 19:40:57 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GJesgq016017 for ; Mon, 16 Oct 2006 15:40:55 -0400 Received: (qmail 17645 invoked by uid 78); 16 Oct 2006 19:40:48 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 19:40:48 -0000 Message-ID: <4533E03A.9010805@andybierman.com> Date: Mon, 16 Oct 2006 12:40:42 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <4533D83E.6090400@andybierman.com> <20061016192621.GA9780@boskop.local> In-Reply-To: <20061016192621.GA9780@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Juergen Schoenwaelder wrote: > On Mon, Oct 16, 2006 at 12:06:38PM -0700, Andy Bierman wrote: > >> IMO we want the simplest approach possible. > > Without specifying how you measure simplicity, your statement is > rather pointless. > >> This does not impact in PDUs. >> It is a simple canonical format for identifying ONE instance of an element. >> It is not intended to be some sort of filtering tool. > > A framework which allows to identify instances in some language X (and > uses this language for say error reporting and access control) and has > a required to implement a filter language which supports a filtering > language Y where the expressive power of Y is a true subset of X seems > a bit, lets say, surprising. Once again, I like X and I do believe Y > will be overcome anyway if netconf is going to be successful. (So I > better stop here since I believe the issue is pretty clear.) We don't have 2 languages X and Y. We have a constrained algorithm for using Xpath to represent an Instance Identifier. I didn't think we needed to discuss all the functional requirements for an Instance Identifier, but let's try: - non-ambiguous, deterministic, canonical format - identifies a single instance in a static manner (Note that all filter expressions can yield different results based on when they are applied to the underlying datastore. We want an Instance ID to have 0 or 1 matches - An instance ID could be thought of as just an Xpath filter that selects a single instance, based solely on the data model naming components and element position.) - persistence: We would like an Instance ID 'match' at time T0 and later time T1 to represent the same conceptual instance. (Insert long debate about discontinuity markers here.) > > /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 Mon Oct 16 15:46:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYQL-0003wF-Go for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:46:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYKz-0003p2-Gb for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:41:26 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZYFw-000Don-B8 for netconf-data@psg.com; Mon, 16 Oct 2006 19:36:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZYFv-000Dny-4z for netconf@ops.ietf.org; Mon, 16 Oct 2006 19:36:11 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 426745AE82; Mon, 16 Oct 2006 21:36:10 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19175-01; Mon, 16 Oct 2006 21:36:07 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 21AD15622A; Mon, 16 Oct 2006 21:36:07 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 784AC8103CE; Mon, 16 Oct 2006 21:36:05 +0200 (CEST) Date: Mon, 16 Oct 2006 21:36:05 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers Message-ID: <20061016193605.GB9780@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Martin Bjorklund , netconf@ops.ietf.org References: <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <20061016.210529.02341268.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061016.210529.02341268.mbj@tail-f.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 On Mon, Oct 16, 2006 at 09:05:29PM +0200, Martin Bjorklund wrote: > Ok. So you mean that these two identifiers would be ok? > > /interface[name="eth0"] and /interface[2] > > One problem with the second alternative is that it's difficult to know > whether the string will identify the same object over time, since > interfaces might come and go. Oh, this is a classic. I concluded several years ago that there is simply no way to get this naming right (and I am ignoring the fact that on some systems you can arbitrarily rename interfaces - did you ever see what xen 3.0 does to your interfaces when it boots?). How you best refer to an interface is really something you can only answer when you understand the purpose of the reference. There are valid reasons to sometimes refer to an interface with a given name, sometime you like to refer to an interface with a given address, sometimes you really like to refer to an interface whose alias matches a certain regex, sometimes you might have a valid reason to refer to the 2nd interface. The nice thing about netconf is that it does allow some freedom which is a clear step ahead of what SNMP gave us. > > I strongly dislike an approach where certain xpath features (like > > position()) may only be used under some conditions. > > Are you suggesting that any XPath construct should be valid in an > Instance Identifier? Or do you mean that if position() can be used in > some places in an Instance Identifier, then it should be possible to > use it anywhere in the Instance Identifier? The later. The set of valid xpath constructs needs to be defined and what belongs to this set should be valid everywhere. Back at the time when we discussed filtering, I suggested an xpath subset to be used. Some other IETF WG has adopted a similar approach and they even defined the subset - I would have to dig to find the reference - it is somewhere in the netconf archive. The XML directorate might also know... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 15:47:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYQn-0004GP-Fz for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:47:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYCE-0002c7-Hk for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 15:32:25 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZY6b-000Aiw-9G for netconf-data@psg.com; Mon, 16 Oct 2006 19:26:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZY6a-000AiU-CP for netconf@ops.ietf.org; Mon, 16 Oct 2006 19:26:32 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8D58C5AE5E; Mon, 16 Oct 2006 21:26:31 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18270-03; Mon, 16 Oct 2006 21:26:28 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8C02A5AE6A; Mon, 16 Oct 2006 21:26:28 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 8CCE58103A2; Mon, 16 Oct 2006 21:26:21 +0200 (CEST) Date: Mon, 16 Oct 2006 21:26:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers Message-ID: <20061016192621.GA9780@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Martin Bjorklund , netconf@ops.ietf.org References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <4533D83E.6090400@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4533D83E.6090400@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Mon, Oct 16, 2006 at 12:06:38PM -0700, Andy Bierman wrote: > IMO we want the simplest approach possible. Without specifying how you measure simplicity, your statement is rather pointless. > This does not impact in PDUs. > It is a simple canonical format for identifying ONE instance of an element. > It is not intended to be some sort of filtering tool. A framework which allows to identify instances in some language X (and uses this language for say error reporting and access control) and has a required to implement a filter language which supports a filtering language Y where the expressive power of Y is a true subset of X seems a bit, lets say, surprising. Once again, I like X and I do believe Y will be overcome anyway if netconf is going to be successful. (So I better stop here since I believe the issue is pretty clear.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 16 22:16:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeV7-0003N4-AC for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 22:16:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZeV5-0003DX-TL for netconf-archive@lists.ietf.org; Mon, 16 Oct 2006 22:16:17 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZeNs-000EN7-Of for netconf-data@psg.com; Tue, 17 Oct 2006 02:08:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [204.127.200.81] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZeNr-000ELI-OT for netconf@ops.ietf.org; Tue, 17 Oct 2006 02:08:48 +0000 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc11) with SMTP id <20061016203141011006213je>; Mon, 16 Oct 2006 20:31:42 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Martin Bjorklund'" Cc: , , Subject: RE: action RPC I-D Date: Mon, 16 Oct 2006 16:29:21 -0400 Message-ID: <050901c6f161$c3d22a10$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4533C8AE.4000507@andybierman.com> Thread-Index: AcbxTcn5yxpQ3Q6WRbmYndXXJJ0WngAEs6sw Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi, At the IAB Workshop, one of the strong points was that operators want to be able to "read" the content on the wire. Adding such regex formatting will make the content much less human-friendly. I think the action increases the difficulty of access control specification, and increases the likelihood of non-interoperable commands. I prefer to not have the action layer. I don't see adequate benefits to justify the added complexity. dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Monday, October 16, 2006 2:00 PM > To: Martin Bjorklund > Cc: phil@juniper.net; balazs.lengyel@ericsson.com; > netconf@ops.ietf.org > Subject: Re: action RPC I-D > > Martin Bjorklund wrote: > > Phil Shafer wrote: > >> Martin Bjorklund writes: > >... > > > But anyway, I just said that I do agree with the "intermediate SW > > argument", i.e. using a well-known rpc might make it easier > > to write this kind of software. > > > > As an example, suppose you have a set of hosts, each with a set of > > services, and a service can be reset. Using a normal rpc, > this reset > > could be: > > > > > > foo > > web > > now > > > > > > Using the , with Balazs syntax, > > > > > > > /hosts/host[name="foo"]/service[name="foo"] lingPoint> > > reset > > > > now > > > > > > > > My only point is that the latter might be easier for a SW component > > like a master agent. > > > > IMO this is an implementation choice. > I prefer the former approach because I already have > SW components that auto-generate PDU fragments based > on the element in the existing netconf-prot document. > Plus, the less XML layers the better. I also agree with Phil > that the version is more XSD-friendly. > > Some people prefer not to couple all the 'action' RPC implementation > details together. Others may prefer a common gateway approach. > The RPC method could use internal > (implementation > specific) mechanisms to convert the XML parameters to different forms. > Exposing the complex RPC to managers seems to make things > harder on the manager than the > version in your example. > > > > > > /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 Tue Oct 17 01:48:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhod-00017d-Vj for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 01:48:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhoT-0007Jc-It for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 01:48:39 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZhi4-000BIm-Gg for netconf-data@psg.com; Tue, 17 Oct 2006 05:41:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.5 Received: from [194.199.18.100] (helo=mx-serv.inrialpes.fr) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZhi0-000BFZ-Ks for netconf@ops.ietf.org; Tue, 17 Oct 2006 05:41:51 +0000 Received: from smtps.inrialpes.fr (smtps.inrialpes.fr [194.199.18.58]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k9H5ffDF024847; Tue, 17 Oct 2006 07:41:41 +0200 (MEST) Received: from [192.168.0.2] (4be54-1-89-80-248-137.dsl.club-internet.fr [89.80.248.137]) (authenticated bits=0) by smtps.inrialpes.fr (8.13.7/8.13.4) with ESMTP id k9H5feW6020340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 07:41:41 +0200 Message-ID: <45346F32.1060405@loria.fr> Date: Tue, 17 Oct 2006 07:50:42 +0200 From: Cridlig Vincent User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Andy Bierman CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <4533D83E.6090400@andybierman.com> <20061016192621.GA9780@boskop.local> <4533E03A.9010805@andybierman.com> In-Reply-To: <4533E03A.9010805@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 17 Oct 2006 07:41:42 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.cridlig@loria.fr Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi, The following document might be of interest for this thread. It discusses location in XML context. http://www.xml.com/pub/a/2004/11/24/py-xml.html ------ Switching to developer mode, it would take two lines for me to build this absolute XPath exp ! ;-) from amara import domtools domtools.abs_path(node) ------ Regards, Vincent Andy Bierman a écrit : > Juergen Schoenwaelder wrote: >> On Mon, Oct 16, 2006 at 12:06:38PM -0700, Andy Bierman wrote: >> >>> IMO we want the simplest approach possible. >> >> Without specifying how you measure simplicity, your statement is >> rather pointless. >> >>> This does not impact in PDUs. >>> It is a simple canonical format for identifying ONE instance of an >>> element. >>> It is not intended to be some sort of filtering tool. >> >> A framework which allows to identify instances in some language X (and >> uses this language for say error reporting and access control) and has >> a required to implement a filter language which supports a filtering >> language Y where the expressive power of Y is a true subset of X seems >> a bit, lets say, surprising. Once again, I like X and I do believe Y >> will be overcome anyway if netconf is going to be successful. (So I >> better stop here since I believe the issue is pretty clear.) > > We don't have 2 languages X and Y. > We have a constrained algorithm for using Xpath to represent > an Instance Identifier. > > I didn't think we needed to discuss all the functional requirements > for an Instance Identifier, but let's try: > > - non-ambiguous, deterministic, canonical format > - identifies a single instance in a static manner > (Note that all filter expressions can yield different results > based on when they are applied to the underlying datastore. > We want an Instance ID to have 0 or 1 matches > - An instance ID could be thought of as just an Xpath filter > that selects a single instance, based solely on the data model > naming components and element position.) > - persistence: > We would like an Instance ID 'match' at time T0 and later time T1 > to represent the same conceptual instance. (Insert long debate > about discontinuity markers here.) > > > >> >> /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: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 17 04:09:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZk0U-000212-SB for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 04:09:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjnk-0000n7-1m for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 03:55:56 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZjhw-0001zT-OK for netconf-data@psg.com; Tue, 17 Oct 2006 07:49:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZjhv-0001xZ-6L for netconf@ops.ietf.org; Tue, 17 Oct 2006 07:49:52 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A27ED5AD3D; Tue, 17 Oct 2006 09:49:49 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31159-03; Tue, 17 Oct 2006 09:49:46 +0200 (CEST) Received: from boskop.local (unknown [10.71.237.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id ED6265AC3C; Tue, 17 Oct 2006 09:49:46 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 06E77810AB9; Tue, 17 Oct 2006 09:49:44 +0200 (CEST) Date: Tue, 17 Oct 2006 09:49:44 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers Message-ID: <20061017074944.GA10735@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Martin Bjorklund , netconf@ops.ietf.org References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <4533D83E.6090400@andybierman.com> <20061016192621.GA9780@boskop.local> <4533E03A.9010805@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4533E03A.9010805@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Mon, Oct 16, 2006 at 12:40:42PM -0700, Andy Bierman wrote: > We don't have 2 languages X and Y. > We have a constrained algorithm for using Xpath to represent > an Instance Identifier. Andy, a system which says "here is a name for an instance" and which does not subsequently allow me to retrieve this instance under that name is kind of odd, do you not think so? /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 Oct 17 05:00:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkof-0006DM-94 for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 05:00:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkod-0005pq-TH for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 05:00:53 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZkff-000KrU-HX for netconf-data@psg.com; Tue, 17 Oct 2006 08:51:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZkfd-000Kr5-GZ for netconf@ops.ietf.org; Tue, 17 Oct 2006 08:51:34 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id A66C11B8011; Tue, 17 Oct 2006 10:51:30 +0200 (CEST) Date: Tue, 17 Oct 2006 10:51:20 +0200 (CEST) Message-Id: <20061017.105120.57270350.mbj@tail-f.com> To: dbharrington@comcast.net Cc: ietf@andybierman.com, phil@juniper.net, balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D From: Martin Bjorklund In-Reply-To: <050901c6f161$c3d22a10$0600a8c0@china.huawei.com> References: <4533C8AE.4000507@andybierman.com> <050901c6f161$c3d22a10$0600a8c0@china.huawei.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 "David B Harrington" wrote: > Hi, > > At the IAB Workshop, one of the strong points was that operators want > to be able to "read" the content on the wire. Ok. > Adding such regex > formatting will make the content much less human-friendly. It's not regex, it's the Instance Identifier syntax (XPath) that Andy proposed. > I think the action increases the difficulty of access control > specification, Why? I think it actually might be easier to do access control, since the ACM can look at the callingPoint and name to find the operation, without knowing anything about the schema. In the example, the ACM would have to understand the schema to realize what the parameters and actually mean. /martin > and increases the likelihood of non-interoperable > commands. > > I prefer to not have the action layer. I don't see adequate benefits > to justify the added complexity. > > dbh > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > > Sent: Monday, October 16, 2006 2:00 PM > > To: Martin Bjorklund > > Cc: phil@juniper.net; balazs.lengyel@ericsson.com; > > netconf@ops.ietf.org > > Subject: Re: action RPC I-D > > > > Martin Bjorklund wrote: > > > Phil Shafer wrote: > > >> Martin Bjorklund writes: > > >... > > > > > But anyway, I just said that I do agree with the "intermediate SW > > > argument", i.e. using a well-known rpc might make it > easier > > > to write this kind of software. > > > > > > As an example, suppose you have a set of hosts, each with a set of > > > services, and a service can be reset. Using a normal rpc, > > this reset > > > could be: > > > > > > > > > foo > > > web > > > now > > > > > > > > > Using the , with Balazs syntax, > > > > > > > > > > > /hosts/host[name="foo"]/service[name="foo"] > lingPoint> > > > reset > > > > > > now > > > > > > > > > > > > My only point is that the latter might be easier for a SW > component > > > like a master agent. > > > > > > > IMO this is an implementation choice. > > I prefer the former approach because I already have > > SW components that auto-generate PDU fragments based > > on the element in the existing netconf-prot document. > > Plus, the less XML layers the better. I also agree with Phil > > that the version is more XSD-friendly. > > > > Some people prefer not to couple all the 'action' RPC implementation > > details together. Others may prefer a common gateway approach. > > The RPC method could use internal > > (implementation > > specific) mechanisms to convert the XML parameters to different > forms. > > Exposing the complex RPC to managers seems to make things > > harder on the manager than the > > version in your example. > > > > > > > > > > /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 Tue Oct 17 05:21:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZl8K-0003V5-HU for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 05:21:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZl8J-0001Iz-8D for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 05:21:12 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZl2i-000OSI-Q6 for netconf-data@psg.com; Tue, 17 Oct 2006 09:15:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZl2h-000ORn-RZ for netconf@ops.ietf.org; Tue, 17 Oct 2006 09:15:24 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9H9FMaE000695 for ; Tue, 17 Oct 2006 05:15:23 -0400 Received: (qmail 30599 invoked by uid 78); 17 Oct 2006 09:15:22 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 17 Oct 2006 09:15:22 -0000 Message-ID: <45349F9D.9000100@andybierman.com> Date: Tue, 17 Oct 2006 02:17:17 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <4533D83E.6090400@andybierman.com> <20061016192621.GA9780@boskop.local> <4533E03A.9010805@andybierman.com> <20061017074944.GA10735@boskop.local> In-Reply-To: <20061017074944.GA10735@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Juergen Schoenwaelder wrote: > On Mon, Oct 16, 2006 at 12:40:42PM -0700, Andy Bierman wrote: > >> We don't have 2 languages X and Y. >> We have a constrained algorithm for using Xpath to represent >> an Instance Identifier. > > Andy, > > a system which says "here is a name for an instance" and which does > not subsequently allow me to retrieve this instance under that name is > kind of odd, do you not think so? Yes, but that's not what we have. > > /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 Oct 17 05:24:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlBd-0005rh-VF for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 05:24:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlBc-0001xR-Ln for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 05:24:37 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZl7P-000P6d-GE for netconf-data@psg.com; Tue, 17 Oct 2006 09:20:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZl7O-000P6N-29 for netconf@ops.ietf.org; Tue, 17 Oct 2006 09:20:14 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9H9KDc6021069 for ; Tue, 17 Oct 2006 05:20:13 -0400 Received: (qmail 7706 invoked by uid 78); 17 Oct 2006 09:20:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 17 Oct 2006 09:20:13 -0000 Message-ID: <4534A0C0.2090500@andybierman.com> Date: Tue, 17 Oct 2006 02:22:08 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cridlig Vincent CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: NETCONF Instance Identifiers References: <4533987D.9080209@andybierman.com> <20061016163945.GA9465@boskop.local> <20061016.194931.122337557.mbj@tail-f.com> <20061016184925.GA9592@boskop.local> <4533D83E.6090400@andybierman.com> <20061016192621.GA9780@boskop.local> <4533E03A.9010805@andybierman.com> <45346F32.1060405@loria.fr> In-Reply-To: <45346F32.1060405@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 >... > Andy Bierman a écrit : >> Juergen Schoenwaelder wrote: >>> On Mon, Oct 16, 2006 at 12:06:38PM -0700, Andy Bierman wrote: >>> >>>> IMO we want the simplest approach possible. >>> >>> Without specifying how you measure simplicity, your statement is >>> rather pointless. >>> IMO, having 1 way to declare a construct is simpler than 3 or ways to define a construct, plus defining mappings between all the variants, plus defining algorithms for picking a canonical variant. (But this is XML, and when you only have one big clumsy hammer, you better just smash away, and expect everything you hit to be a nail...) Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 17 15:46:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZutc-00009t-AF for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 15:46:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZutY-0003qv-V2 for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 15:46:40 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZulS-000Mr9-Pk for netconf-data@psg.com; Tue, 17 Oct 2006 19:38:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZulR-000Mqv-LK for netconf@ops.ietf.org; Tue, 17 Oct 2006 19:38:14 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9HJc9mA012174 for ; Tue, 17 Oct 2006 15:38:10 -0400 Received: (qmail 31124 invoked by uid 78); 17 Oct 2006 19:38:06 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 17 Oct 2006 19:38:06 -0000 Message-ID: <45353192.1010505@andybierman.com> Date: Tue, 17 Oct 2006 12:40:02 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: operation somewhat broken Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi, IMO, the command is not actually useful for 'inline' configuration validation. The reason the edit-config operation does not have a 'test-only' mode is because the validate operation is supposed to provide that feature. Except it doesn't actually work. Problem 1) Assumed target. Since the parameter is a choice, the manager cannot specify a target -- it is assumed to be either the or config. There is no way to specify a user-named config (url) as the target if the inline mode is used. Problem 2) Assumed default operation. There is no way to pass the default-operation parameter that would be used in the along with the element. The operation is supposed to come up with the same answer as an would in this mode, but without this critical parameter, that is impossible. The text in 8.6.4.1 does not match the XSD. It does not indicate that 'inline config' or 'url' modes are allowed here. The only example shows the 'config name' variant. Why didn't anybody bring this up until now? Does anybody support this operation? Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 17 17:52:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwrG-0000ql-6W for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 17:52:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZwrC-00006C-RD for netconf-archive@lists.ietf.org; Tue, 17 Oct 2006 17:52:22 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZwmG-000MuX-Vl for netconf-data@psg.com; Tue, 17 Oct 2006 21:47:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GZwmD-000Mtm-RY for netconf@ops.ietf.org; Tue, 17 Oct 2006 21:47:12 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9HLl892004226 for ; Tue, 17 Oct 2006 17:47:08 -0400 Received: (qmail 20578 invoked by uid 78); 17 Oct 2006 21:47:08 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 17 Oct 2006 21:47:08 -0000 Message-ID: <45354F56.1020300@andybierman.com> Date: Tue, 17 Oct 2006 14:47:02 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: operation somewhat broken References: <45353192.1010505@andybierman.com> In-Reply-To: <45353192.1010505@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Andy Bierman wrote: > Hi, > > IMO, the command is not actually useful for 'inline' > configuration validation. > I think the WG should decide what to do about this problem: 1) Ignore it 2) Document it 3) Fix it IMO, the proper engineering fix requires 2 independent changes: 1) Add a 'test-only' enumeration to the (edit-config) test-option parameter. (Remember that this entire parameter is only supported if the :validate capability is supported. This change could be done as a validate-2.0 capability, and not change the 1.0 capability. 2) Remove configInlineType as one of the options for the 'source' parameter in the validate operation. (Make it the same data type as the getConfig source parameter). The normative text only mentions 'config name' as a possible value for the 'source' parameter, so perhaps the URL support in the XSD is wrong as well. The validate command is only used to check an entire configuration, so configInlineType is wrong, even if no other change is made. The 'operation' attribute should not be present in the data nodes, for the validate operation, unlike the edit-config operation. I remember we had a test-only mode for edit-config and took it out because the validate operation covered it. Maybe this is not important enough to people that we fix it. We will see. Andy > The reason the edit-config operation does not have a 'test-only' mode > is because the validate operation is supposed to provide that feature. > Except it doesn't actually work. > > Problem 1) Assumed target. Since the parameter is a choice, > the manager cannot specify a target -- it is assumed to be either > the or config. There is no way to specify > a user-named config (url) as the target if the inline mode is > used. > > Problem 2) Assumed default operation. There is no way to pass the > default-operation parameter that would be used in the > along with the element. The operation is supposed > to come up with the same answer as an would in this mode, > but without this critical parameter, that is impossible. > > > The text in 8.6.4.1 does not match the XSD. > It does not indicate that 'inline config' or 'url' modes > are allowed here. The only example shows the 'config name' variant. > Why didn't anybody bring this up until now? Does anybody support > this operation? > > > Andy > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 18 04:17:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6bp-000070-20 for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 04:17:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6bj-0004j2-N6 for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 04:17:05 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Ga6TH-0000aV-4c for netconf-data@psg.com; Wed, 18 Oct 2006 08:08:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Ga6TF-0000Z6-KB for netconf@ops.ietf.org; Wed, 18 Oct 2006 08:08:14 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id C64C91B8011; Wed, 18 Oct 2006 10:08:01 +0200 (CEST) Date: Wed, 18 Oct 2006 10:07:51 +0200 (CEST) Message-Id: <20061018.100751.93473753.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: operation somewhat broken From: Martin Bjorklund In-Reply-To: <45353192.1010505@andybierman.com> References: <45353192.1010505@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Andy Bierman wrote: > Hi, > > IMO, the command is not actually useful for 'inline' > configuration validation. > > The reason the edit-config operation does not have a 'test-only' mode > is because the validate operation is supposed to provide that feature. > Except it doesn't actually work. > > Problem 1) Assumed target. Since the parameter is a choice, > the manager cannot specify a target -- it is assumed to be either > the or config. There is no way to specify > a user-named config (url) as the target if the inline mode is used. > > Problem 2) Assumed default operation. There is no way to pass the > default-operation parameter that would be used in the > along with the element. The operation is supposed > to come up with the same answer as an would in this mode, > but without this critical parameter, that is impossible. > > > The text in 8.6.4.1 does not match the XSD. > It does not indicate that 'inline config' or 'url' modes > are allowed here. It says Name of the configuration datastore being validated, such as or the element containing the configuration subtree to validate. So inline config is mentioned, but url is not. > The only example shows the 'config name' variant. > Why didn't anybody bring this up until now? I think we touched on this in the thread leading up to http://ops.ietf.org/lists/netconf/netconf.2006/msg00189.html and other mails. I brought it up at that time, and I still think that (as it is defined) is useful for complete configs only. But the complete config can be inline or a local file or a datastore name. > Does anybody support this operation? Do you mean validation of inline config? Yes, we support that, but it will be on a syntactical level only, i.e. it can't do integrity checks (as discussed in the email thread mentioned above). /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 Oct 18 04:28:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6my-0006rf-Ea for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 04:28:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6mx-0007XT-4t for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 04:28:36 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Ga6fJ-0004X8-24 for netconf-data@psg.com; Wed, 18 Oct 2006 08:20:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Ga6fI-0004TA-BZ for netconf@ops.ietf.org; Wed, 18 Oct 2006 08:20:40 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 45DE31B8011; Wed, 18 Oct 2006 10:20:19 +0200 (CEST) Date: Wed, 18 Oct 2006 10:20:09 +0200 (CEST) Message-Id: <20061018.102009.131946487.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: operation somewhat broken From: Martin Bjorklund In-Reply-To: <45354F56.1020300@andybierman.com> References: <45353192.1010505@andybierman.com> <45354F56.1020300@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Andy Bierman wrote: > Andy Bierman wrote: > > Hi, > > > > IMO, the command is not actually useful for 'inline' > > configuration validation. > > > > I think the WG should decide what to do about this problem: > > 1) Ignore it > 2) Document it > 3) Fix it > > IMO, the proper engineering fix requires 2 independent changes: > > 1) Add a 'test-only' enumeration to the (edit-config) test-option > parameter. (Remember that this entire parameter is only supported > if the :validate capability is supported. This change could > be done as a validate-2.0 capability, and not change the 1.0 capability. I think this would be a very useful enhancement. > 2) Remove configInlineType as one of the options for the 'source' > parameter in the validate operation. (Make it the same data type > as the getConfig source parameter). That means that you could only the 'candidate', 'running' or 'startup'? I think this would be fine, b/c test-only is a much more useful operation. [side note: does it make sense to validate 'running'?] /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 Oct 18 09:02:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaB3u-0003Nt-OQ for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:02:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaB3r-0002bZ-Ag for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:02:22 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaAtK-000FUB-Nx for netconf-data@psg.com; Wed, 18 Oct 2006 12:51:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaAtJ-000FTS-Hx for netconf@ops.ietf.org; Wed, 18 Oct 2006 12:51:26 +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 k9ICpIg00823 for ; Wed, 18 Oct 2006 08:51:18 -0400 (EDT) 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: Issues for a bit more Discussion - Netconf Notifications Date: Wed, 18 Oct 2006 08:51:08 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40B6A080D@zcarhxm2.corp.nortel.com> In-Reply-To: <4533A500.8080201@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues for a bit more Discussion - Netconf Notifications Thread-Index: AcbxN65SDyOSDc2mRXGNEjZPXIW0CgBe/p8w From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hi Ideally we will issue updates to the various transport mapping documents with any required changes in order to be able to support notifications. Presumably we can't start that work until the documents are published as RFCs. We've been holding the text in our document for safe keeping (although I agree the BEEP text is a bit broken currently). Are we suggesting now is the time to remove this text from the document? Where would it go?=20 Sharon=20 -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com]=20 Sent: Monday, October 16, 2006 11:28 AM To: Andy Bierman Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications Andy, > The WG already decided we do not want app-level ACKs. > They are supposed to be removed completely. My point was that you get this for free with BEEP (like so many other things) simply by choosing your grouping of messages and how you would process them (e.g., not waiting for the whole page). You really need no additional PROTOCOL support for those acknowledgments (although some additional *application library* support on the part of the agent would be necessary). > > My comment (a) above is fairly clear -- we cannot create new BEEP=20 > features or in any way rely on BEEP features that do not exist in a=20 > Proposed Standard RFC. I agree. 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 Wed Oct 18 09:09:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBAr-0001Cj-Nn for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:09:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBAo-0003Wq-CR for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:09:33 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaB2e-000Ghy-KQ for netconf-data@psg.com; Wed, 18 Oct 2006 13:01:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaB2d-000GhQ-KF for netconf@ops.ietf.org; Wed, 18 Oct 2006 13:01:04 +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 k9ID10120300 for ; Wed, 18 Oct 2006 09:01:00 -0400 (EDT) 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: Proposed Edits to Notification Draft Date: Wed, 18 Oct 2006 09:00:40 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40B6A0837@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B5B22EB@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Edits to Notification Draft Thread-Index: Acbwfn1aCvgt4y2bT1yp29D2bq69BQCNazDA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 hi =20 I have a clarifying question on one of the editing instructions. I had interpreted the following to be decoupled from the subscriptionId or not subscriptionId discussion which is listed in the issues for discussion section. I had interpreted this to simply be that Andy is saying the correct way to return the subscription Id is with and not . On re-read, that sounds a bit off. What is the correct way to return a subscription ID? =20 > 1 5. In section 2.1.1, in create subscription (source Andy)=20 > a. This should be instead of a element containing the subscription ID. The WG decided there is only one stream active per session. That means there is no need for a subscription ID in the document.=20 =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 18 09:36:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBaf-00049L-QL for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:36:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBad-0000AW-FS for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:36:13 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaBTv-000LFL-07 for netconf-data@psg.com; Wed, 18 Oct 2006 13:29:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaBTu-000LF6-Cs for netconf@ops.ietf.org; Wed, 18 Oct 2006 13:29:14 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2006 06:29:15 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IDTES0013817; Wed, 18 Oct 2006 06:29:14 -0700 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 k9IDTDAo011214; Wed, 18 Oct 2006 06:29:13 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4259.cisco.com [10.61.80.162]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9IDHCfe014835; Wed, 18 Oct 2006 06:17:13 -0700 Message-ID: <45362C27.2060603@cisco.com> Date: Wed, 18 Oct 2006 15:29:11 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications References: <713043CE8B8E1348AF3C546DBE02C1B40B6A080D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B6A080D@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1294; t=1161178154; x=1162042154; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20Issues=20for=20a=20bit=20more=20Discussion=20-=20Netconf=20Notif ications; X=v=3Dcisco.com=3B=20h=3DLc36HnFtJww7owuwPUSHKSuIMbg=3D; b=C2siDCZvhStHgoek53b2yknoM7HrJRLBw9gez2WSGdSgzUplUivtRvZMVH0tg2v5lm9Gl6gk XpqVr6sH9nO5ZYUfy5tlpUarXLuLzexZJXM+prRh2ICtsEvWl++B1v7B; Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Sharon, > Hi > > Ideally we will issue updates to the various transport mapping documents > with any required changes in order to be able to support notifications. > Presumably we can't start that work until the documents are published as > RFCs. We've been holding the text in our document for safe keeping > (although I agree the BEEP text is a bit broken currently). > > Are we suggesting now is the time to remove this text from the document? > Where would it go? Once again I think we are suffering the poor choices we have made in the past by both having multiple transports and by requiring that each capability be available to each mapping. Yes, we said that. If we stick to that, the best approach to implement this silliness is to actually do what you did and stick this stuff in one document that updates all three. Just get people to test each and you should be able to easily get to proposed this way. If you really want three documents, then I assure this working group that we will not have three separate but equal mappings, because it is as likely as not for each capability you will not have an author or implementation available. This having been said, I've given you the basis for text that should be sufficient for 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: From owner-netconf@ops.ietf.org Wed Oct 18 09:42:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBh4-0000UV-2o for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:42:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBh0-0001F1-PO for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:42:50 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaBc3-000Np3-T3 for netconf-data@psg.com; Wed, 18 Oct 2006 13:37:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.58] (helo=omr8.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaBc2-000No3-KJ for netconf@ops.ietf.org; Wed, 18 Oct 2006 13:37:39 +0000 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9IDbbYW002006 for ; Wed, 18 Oct 2006 09:37:37 -0400 Received: (qmail 23557 invoked by uid 78); 18 Oct 2006 13:37:37 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 18 Oct 2006 13:37:37 -0000 Message-ID: <45362E1A.5020606@andybierman.com> Date: Wed, 18 Oct 2006 06:37:30 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications References: <713043CE8B8E1348AF3C546DBE02C1B40B6A080D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B6A080D@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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Sharon Chisholm wrote: > Hi > > Ideally we will issue updates to the various transport mapping documents > with any required changes in order to be able to support notifications. > Presumably we can't start that work until the documents are published as > RFCs. We've been holding the text in our document for safe keeping > (although I agree the BEEP text is a bit broken currently). > > Are we suggesting now is the time to remove this text from the document? > Where would it go? > The key phrase here is 'required changes'. We don't have app-level ACKs, so there should be no text related to that. If there are any required changes to the transport documents, let's identify them now. We should decide where they go, once we know what they are. > Sharon Andy > > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Monday, October 16, 2006 11:28 AM > To: Andy Bierman > Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ops.ietf.org > Subject: Re: Issues for a bit more Discussion - Netconf Notifications > > Andy, >> The WG already decided we do not want app-level ACKs. >> They are supposed to be removed completely. > My point was that you get this for free with BEEP (like so many other > things) simply by choosing your grouping of messages and how you would > process them (e.g., not waiting for the whole page). You really need no > additional PROTOCOL support for those acknowledgments (although some > additional *application library* support on the part of the agent would > be necessary). > >> My comment (a) above is fairly clear -- we cannot create new BEEP >> features or in any way rely on BEEP features that do not exist in a >> Proposed Standard RFC. > > I agree. > > 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 Wed Oct 18 09:47:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBlh-0002Rm-7J for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:47:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBld-0001vM-Sx for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 09:47:37 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaBfw-000P5P-Vq for netconf-data@psg.com; Wed, 18 Oct 2006 13:41:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaBfw-000P54-0d for netconf@ops.ietf.org; Wed, 18 Oct 2006 13:41:40 +0000 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9IDfddR013929 for ; Wed, 18 Oct 2006 09:41:39 -0400 Received: (qmail 27037 invoked by uid 78); 18 Oct 2006 13:41:39 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 18 Oct 2006 13:41:39 -0000 Message-ID: <45362F0C.5040600@andybierman.com> Date: Wed, 18 Oct 2006 06:41:32 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Proposed Edits to Notification Draft References: <713043CE8B8E1348AF3C546DBE02C1B40B6A0837@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B6A0837@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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Sharon Chisholm wrote: > hi > > I have a clarifying question on one of the editing instructions. I had > interpreted the following to be decoupled from the subscriptionId or not > subscriptionId discussion which is listed in the issues for discussion > section. I had interpreted this to simply be that Andy is saying the > correct way to return the subscription Id is with and not . > On re-read, that sounds a bit off. What is the correct way to return a > subscription ID? I think the WG already decided we do not need or want the subscriptionId parameter at all. The rpc-reply should be used because there is no data that needs to be returned. You do not return any data with . The WG did not decide to keep the subscriptionId "in case we want it someday in the future", as you have interpreted it. Andy > > > > 1 5. In section 2.1.1, in create subscription (source Andy) > > a. This should be instead of a element containing > the subscription ID. The WG decided there is only one stream active > per session. That means there is no need for a subscription ID in the > document. > > > > > -- > to 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 Oct 18 10:37:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCYJ-00031O-V3 for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 10:37:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCYF-0001yn-Gu for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 10:37:51 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaCQu-000CAX-4u for netconf-data@psg.com; Wed, 18 Oct 2006 14:30:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaCQs-000CA2-UC for netconf@ops.ietf.org; Wed, 18 Oct 2006 14:30:11 +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 k9IEU5g21974 for ; Wed, 18 Oct 2006 10:30:05 -0400 (EDT) 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: Issues for a bit more Discussion - Netconf Notifications Date: Wed, 18 Oct 2006 10:30:02 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40B709035@zcarhxm2.corp.nortel.com> In-Reply-To: <45362E1A.5020606@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues for a bit more Discussion - Netconf Notifications Thread-Index: AcbyupaKzw7On6ZMTz+2O+q9p5iSWAABqEaQ From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi While the text in the transport mapping sections in the notification draft is not earth shattering, it does seem necessary. My take on what is necessary is currently defined in section 5. For example, section 5.1 says " Session establishment and two-way messages are based on the NETCONF over SSH transport mapping [NETCONF-SSH] One-way event messages are supported as follows: Once the session has been established and capabilities have been exchanged, the server may send complete XML documents to the NETCONF client containing notification elements. No response is expected from the NETCONF client." Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Wednesday, October 18, 2006 9:37 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications Sharon Chisholm wrote: > Hi >=20 > Ideally we will issue updates to the various transport mapping=20 > documents with any required changes in order to be able to support notifications. > Presumably we can't start that work until the documents are published=20 > as RFCs. We've been holding the text in our document for safe keeping=20 > (although I agree the BEEP text is a bit broken currently). >=20 > Are we suggesting now is the time to remove this text from the document? > Where would it go?=20 >=20 The key phrase here is 'required changes'. We don't have app-level ACKs, so there should be no text related to that. If there are any required changes to the transport documents, let's identify them now. We should decide where they go, once we know what they are. > Sharon Andy >=20 > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Monday, October 16, 2006 11:28 AM > To: Andy Bierman > Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ops.ietf.org > Subject: Re: Issues for a bit more Discussion - Netconf Notifications >=20 > Andy, >> The WG already decided we do not want app-level ACKs. >> They are supposed to be removed completely. > My point was that you get this for free with BEEP (like so many other > things) simply by choosing your grouping of messages and how you would > process them (e.g., not waiting for the whole page). You really need=20 > no additional PROTOCOL support for those acknowledgments (although=20 > some additional *application library* support on the part of the agent > would be necessary). >=20 >> My comment (a) above is fairly clear -- we cannot create new BEEP=20 >> features or in any way rely on BEEP features that do not exist in a=20 >> Proposed Standard RFC. >=20 > I agree. >=20 > Eliot >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 18 11:40:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDWh-0002eW-HL for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 11:40:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDWe-0007hD-3q for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 11:40:15 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaDP7-000Lmf-00 for netconf-data@psg.com; Wed, 18 Oct 2006 15:32:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaDP6-000Llr-3S for netconf@ops.ietf.org; Wed, 18 Oct 2006 15:32:24 +0000 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9IFWNd6011779 for ; Wed, 18 Oct 2006 11:32:23 -0400 Received: (qmail 20793 invoked by uid 78); 18 Oct 2006 15:32:22 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 18 Oct 2006 15:32:22 -0000 Message-ID: <45364900.8040409@andybierman.com> Date: Wed, 18 Oct 2006 08:32:16 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Issues for a bit more Discussion - Netconf Notifications References: <713043CE8B8E1348AF3C546DBE02C1B40B709035@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B709035@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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Sharon Chisholm wrote: > Hi > > While the text in the transport mapping sections in the notification > draft is not earth shattering, it does seem necessary. My take on what > is necessary is currently defined in section 5. > > For example, section 5.1 says > > " Session establishment and two-way messages are based on the NETCONF > over SSH transport mapping [NETCONF-SSH] > > One-way event messages are supported as follows: Once the session has > been established and capabilities have been exchanged, the server may > send complete XML documents to the NETCONF client containing > notification elements. No response is expected from the NETCONF > client." This is no different than what netconf-prot and netconf-ssh defines, except for the bit about not expecting a response. It seems to me that the SSH document is the only one that doesn't need any special text added to support notifications. Doesn't the BEEP mapping need some text adding as a top-level element? Doesn't the SOAP mapping need lots of text (and hacks) to get notifications to work? We do not need to stick to the goal of "all features the same on all transports", if current WG consensus has changed. If we do not have sufficient interest and resources to produce new transport documents for every mapping, then those mappings should probably go away. IMO, it doesn't matter if the text is in the Notifications RFC or a bunch of other RFCs. What matters is whether there is the consensus, expertise, and resources to get the job done. It's possible that we may end up in the long run with just SSH and TLS transports, and eventually just TLS. IMO, one feature of the NETCONF protocol is the decoupling of the 4 layers. As transport protocols improve over time, new mappings can be defined without touching the protocol spec. > > Sharon Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 18 12:16:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaE5X-000333-4m for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 12:16:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDuB-0005OR-Bv for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 12:04:39 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaDhC-000PKM-EM for netconf-data@psg.com; Wed, 18 Oct 2006 15:51:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaDhB-000PJp-6K for netconf@ops.ietf.org; Wed, 18 Oct 2006 15:51:06 +0000 Received: from [10.18.39.60] ([64.141.118.170]) (authenticated user tgoddard@icesoft.com) by www.icesoft.com (Kerio MailServer 6.2.0) (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 18 Oct 2006 08:51:03 -0700 In-Reply-To: <45364900.8040409@andybierman.com> References: <713043CE8B8E1348AF3C546DBE02C1B40B709035@zcarhxm2.corp.nortel.com> <45364900.8040409@andybierman.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: netconf@ops.ietf.org Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: Issues for a bit more Discussion - Netconf Notifications Date: Wed, 18 Oct 2006 09:55:10 -0600 To: Sharon Chisholm , Andy Bierman X-Mailer: Apple Mail (2.752.3) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 For SOAP we would need to describe that a separate HTTP connection is opened for notifications and that the requests for notifications may block for extended periods. (It will take more than a paragraph to describe this precisely.) However, if we allow that notifications need not be delivered while another operation is in progress and we allow empty notification responses, then a single HTTP connection could be used effectively (with HTTP pipelining). This is the technique that people are using with "Ajax Push". Ted. On 18-Oct-06, at 9:32 AM, Andy Bierman wrote: > Doesn't the SOAP mapping need lots of text (and hacks) to get > notifications to work? -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 18 14:43:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGO2-00070Z-Ou for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 14:43:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaGO0-0004w4-1n for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 14:43:30 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaGD5-00008I-2x for netconf-data@psg.com; Wed, 18 Oct 2006 18:32:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.5 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaGD3-000075-Tz for netconf@ops.ietf.org; Wed, 18 Oct 2006 18:32:10 +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 k9IIW4g28033 for ; Wed, 18 Oct 2006 14:32:04 -0400 (EDT) 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: Proposed Edits to Notification Draft Date: Wed, 18 Oct 2006 14:31:26 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40B709652@zcarhxm2.corp.nortel.com> In-Reply-To: <45362F0C.5040600@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Edits to Notification Draft Thread-Index: Acbyuye5oDuEJxXuRaSYdD0iHPkj5wABswwA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Hi I don't remember any discussion explicitly as to whether we needed this identifier which is why I added it to the list of issues to discuss.=20 Yes, it is obviously helpful for implementations which support proprietary or future capabilities that build on the base notification specification. There are a number of add-ons that could result in the one-session to one subscription ratio not being true. I know you aren't really into supporting extensibility in that way, so I just want to confirm that we don't need it to support the base specification. For implementations only supporting the base protocol specification, there is a one-to-one correspondence between session id and subscription id. In these cases the session id can be used for many of the cases where you would want subscription id. One potential case, even with the current minimal base, where you would still have more then one subscription associated with the same session is if you had a replay subscription and after it completes you start another subscription. Since these don't exist at the same time, it may not be necessary to be able to distinguish them. I guess we can live without it for the base specification and find a way to recover when supporting extended content. Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Wednesday, October 18, 2006 9:42 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ops.ietf.org Subject: Re: Proposed Edits to Notification Draft Sharon Chisholm wrote: > hi > =20 > I have a clarifying question on one of the editing instructions. I=20 > had interpreted the following to be decoupled from the subscriptionId=20 > or not subscriptionId discussion which is listed in the issues for=20 > discussion section. I had interpreted this to simply be that Andy is=20 > saying the correct way to return the subscription Id is with and not . > On re-read, that sounds a bit off. What is the correct way to return=20 > a subscription ID? I think the WG already decided we do not need or want the subscriptionId parameter at all. The rpc-reply should be used because there is no data that needs to be returned. You do not return any data with . The WG did not decide to keep the subscriptionId "in case we want it someday in the future", as you have interpreted it. Andy > =20 >=20 > > 1 5. In section 2.1.1, in create subscription (source Andy)=20 > > a. This should be instead of a element containing > the subscription ID. The WG decided there is only one stream active=20 > per session. That means there is no need for a subscription ID in the > document. >=20 > =20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 18 15:30:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaH7w-00016H-5Y for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 15:30:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaH06-0000aw-77 for netconf-archive@lists.ietf.org; Wed, 18 Oct 2006 15:22:51 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaGrE-000ASu-GH for netconf-data@psg.com; Wed, 18 Oct 2006 19:13:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.5 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaGrD-000ASe-A3 for netconf@ops.ietf.org; Wed, 18 Oct 2006 19:13:39 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9IJDQMs000643 for ; Wed, 18 Oct 2006 15:13:30 -0400 Received: (qmail 1742 invoked by uid 78); 18 Oct 2006 19:13:25 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 18 Oct 2006 19:13:25 -0000 Message-ID: <45367CCF.4030604@andybierman.com> Date: Wed, 18 Oct 2006 12:13:19 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Proposed Edits to Notification Draft References: <713043CE8B8E1348AF3C546DBE02C1B40B709652@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40B709652@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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Sharon Chisholm wrote: > Hi > > I don't remember any discussion explicitly as to whether we needed this > identifier which is why I added it to the list of issues to discuss. > > Yes, it is obviously helpful for implementations which support > proprietary or future capabilities that build on the base notification > specification. There are a number of add-ons that could result in the > one-session to one subscription ratio not being true. I know you aren't > really into supporting extensibility in that way, so I just want to > confirm that we don't need it to support the base specification. > > For implementations only supporting the base protocol specification, > there is a one-to-one correspondence between session id and subscription > id. In these cases the session id can be used for many of the cases > where you would want subscription id. One potential case, even with the > current minimal base, where you would still have more then one > subscription associated with the same session is if you had a replay > subscription and after it completes you start another subscription. > Since these don't exist at the same time, it may not be necessary to be > able to distinguish them. IMO it is bad engineering to add extra cruft because you might need it someday. The WG consensus is that we do not need this feature at all. If we ever change our minds, it is cleaner engineering to add the parameter if and when we actually need it. If you add a under-specified parameter in "1.0", it will in no way indicate that the agent supports some future multi-subscription notification capability. Then you have to specify how the real capability interacts and coexists with the "old" subscriptionID. In that case, we incur extra complexity for no benefit. Proprietary 'replacements' to the standard (e.g., use your own RPC) are somewhat out of scope. > > I guess we can live without it for the base specification and find a way > to recover when supporting extended content. Yes we can live without it. The sessionID is sufficient. > > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Wednesday, October 18, 2006 9:42 AM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ops.ietf.org > Subject: Re: Proposed Edits to Notification Draft > > Sharon Chisholm wrote: >> hi >> >> I have a clarifying question on one of the editing instructions. I >> had interpreted the following to be decoupled from the subscriptionId >> or not subscriptionId discussion which is listed in the issues for >> discussion section. I had interpreted this to simply be that Andy is >> saying the correct way to return the subscription Id is with and > not . >> On re-read, that sounds a bit off. What is the correct way to return >> a subscription ID? > > I think the WG already decided we do not need or want the subscriptionId > parameter at all. > > The rpc-reply should be used because there is no data that needs to > be returned. You do not return any data with . > > The WG did not decide to keep the subscriptionId "in case we want it > someday in the future", as you have interpreted it. > > Andy > > >> >> >> > 1 5. In section 2.1.1, in create subscription (source Andy) >> > a. This should be instead of a element containing >> the subscription ID. The WG decided there is only one stream active >> per session. That means there is no need for a subscription ID in the > >> document. >> >> >> >> >> -- >> to 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 Oct 19 07:32:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW8m-0003up-Tt for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 07:32:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaW8h-0007qI-Ez for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 07:32:48 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaW0w-000O8J-P5 for netconf-data@psg.com; Thu, 19 Oct 2006 11:24:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.5 Received: from [133.145.228.44] (helo=mail9.hitachi.co.jp) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaW0v-000O83-K0 for netconf@ops.ietf.org; Thu, 19 Oct 2006 11:24:42 +0000 Received: from mlsv4.hitachi.co.jp (unknown [133.145.228.16]) by mail9.hitachi.co.jp (Postfix) with ESMTP id DA46E37C8E for ; Thu, 19 Oct 2006 20:24:40 +0900 (JST) Received: from MFILTER-S4.hitachi.co.jp by mlsv4.hitachi.co.jp (8.12.10/8.12.10) id k9JBOe38015741; Thu, 19 Oct 2006 20:24:40 +0900 Received: from navgw6.itg.hitachi.co.jp (unverified) by MFILTER-S4.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id for ; Thu, 19 Oct 2006 20:24:40 +0900 Received: from gmml28.itg.hitachi.co.jp ([158.213.165.131]) by navgw6.itg.hitachi.co.jp with SMTP id M2006101920243909219 for ; Thu, 19 Oct 2006 20:24:39 +0900 Received: from [133.144.79.131] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id k9JBOdY6098962; Thu, 19 Oct 2006 20:24:40 +0900 Message-ID: <45376028.2050108@hitachi.com> Date: Thu, 19 Oct 2006 20:23:20 +0900 From: Tomoyuki Iijima User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Hi, Thank you, Dan. I'm the author of this draft. If time slot is available in 67th meeting, let me touch upon this draft. Regards, Romascanu, Dan (Dan) wrote: > > > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, October 18, 2006 9:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Experience of NETCONF over SOAP Implementation > Author(s) : I. Tomoyuki, et al. > Filename : > draft-iijima-netconf-soap-implementation-00.txt > Pages : 13 > Date : 2006-10-18 > > NETCONF protocol is standardized to be exchanged over SSH, SOAP, or > BEEP. We actually developed network management system based on > NETCONF protocol. For several reasons, we chose SOAP protocol as a > transport protocol of the NETCONF. This document describes why we > chose SOAP as a transport protocol and the insight gained from actual > development. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementa > tion-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-iijima-netconf-soap-implementation-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-iijima-netconf-soap-implementation-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce -- Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory 1-280, Higashi-koigakubo Kokubunji-shi, Tokyo 185-8601, Japan Tel:+81-42-323-1111 ext.3579 Fax:+81-42-327-7868 E-mail:tomoyuki.iijima.fg@hitachi.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 Oct 19 08:36:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaX8U-0004M5-J9 for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 08:36:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaX8N-0004D6-LK for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 08:36:34 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaX3A-000EBv-2F for netconf-data@psg.com; Thu, 19 Oct 2006 12:31:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaX38-000EB9-Rw for netconf@ops.ietf.org; Thu, 19 Oct 2006 12:31:03 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k9JCLit0020045 for ; Thu, 19 Oct 2006 08:21:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt Date: Thu, 19 Oct 2006 14:30:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt Thread-Index: AcbzcXXgiZaAaHRMQ2GZwA/u4f11qgACKkHg From: "Romascanu, Dan \(Dan\)" To: "Tomoyuki Iijima" , X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Hi, I forwarded the message to the netconf wg because it is an individual submission and not all netconf participants may be subscribed to the i-d-announce list. If you want to get a slot on the netconf wg meeting you need to contact the wg chairs.=20 Regards, Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Tomoyuki Iijima > Sent: Thursday, October 19, 2006 1:23 PM > To: netconf@ops.ietf.org > Subject: Re: FW: I-D=20 > ACTION:draft-iijima-netconf-soap-implementation-00.txt >=20 > Hi, >=20 > Thank you, Dan. >=20 > I'm the author of this draft. If time slot is available in=20 > 67th meeting, let me touch upon this draft. >=20 > Regards, >=20 > Romascanu, Dan (Dan) wrote: > > =20 > >=20 > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, October 18, 2006 9:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : Experience of NETCONF over SOAP Implementation > > Author(s) : I. Tomoyuki, et al. > > Filename : > > draft-iijima-netconf-soap-implementation-00.txt > > Pages : 13 > > Date : 2006-10-18 > > =09 > > NETCONF protocol is standardized to be exchanged over=20 > SSH, SOAP, or > > BEEP. We actually developed network management system based on > > NETCONF protocol. For several reasons, we chose SOAP=20 > protocol as a > > transport protocol of the NETCONF. This document=20 > describes why we > > chose SOAP as a transport protocol and the insight=20 > gained from actual > > development. > >=20 > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implemen > > ta > > tion-00.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-iijima-netconf-soap-implementation-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-iijima-netconf-soap-implementation-00.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant=20 > 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. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 > -- > Tomoyuki Iijima > Hitachi, Ltd., Central Research Laboratory 1-280,=20 > Higashi-koigakubo Kokubunji-shi, Tokyo 185-8601, Japan > Tel:+81-42-323-1111 ext.3579 > Fax:+81-42-327-7868 > E-mail:tomoyuki.iijima.fg@hitachi.com >=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 Oct 19 08:53:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXOk-0003c8-C1 for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 08:53:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXOh-0006jk-KF for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 08:53:22 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaXJ2-000HZY-7B for netconf-data@psg.com; Thu, 19 Oct 2006 12:47:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level:=20 X-Spam-Status: No, score=3D-2.6 required=3D5.0 tests=3DBAYES=5F00,UNPAR= Message-Id: From: owner-netconf@ops.ietf.org Date: Thu, 19 Oct 2006 12:47:28 +0000 X-Spam-Score: 1.7 (+) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 SEABLE=5FRELAY=20 =09autolearn=3Dham version=3D3.1.5 Received: from [133.145.228.5] (helo=3Dmail4.hitachi.co.jp) =09by psg.com with esmtp (Exim 4.63 (FreeBSD)) =09(envelope-from ) =09id 1GaRxf-000Ntl-KW =09for netconf@ops.ietf.org; Thu, 19 Oct 2006 07:05:04 +0000 Received: from mlsv2.hitachi.co.jp (unknown [133.145.228.16]) =09by mail4.hitachi.co.jp (Postfix) with ESMTP id 81B5E33CF5 =09for ; Thu, 19 Oct 2006 16:05:01 +0900 (JST) Received: from mfilter-s6.hitachi.co.jp by mlsv2.hitachi.co.jp (8.12.10= /8.12.10) id k9J751e3020389; Thu, 19 Oct 2006 16:05:01 +0900 Received: from navgw6.itg.hitachi.co.jp (unverified) by mfilter-s6.hita= chi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id for ; Thu, 19 Oct 2006 16:04:59 +0900 Received: from gmml28.itg.hitachi.co.jp ([158.213.165.131]) by navgw6.itg.hitachi.co.jp with SMTP id M2006101916045921819 for ; Thu, 19 Oct 2006 16:04:59 +0900 Received: from [133.144.79.131] by gmml28.itg.hitachi.co.jp (AIX5.2/8.1= 1.6p2/8.11.0) id k9J74xY5611636; Thu, 19 Oct 2006 16:04:59 +0900 Message-ID: <4537233E.1@hitachi.com> Date: Thu, 19 Oct 2006 16:03:26 +0900 From: Tomoyuki Iijima User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: [Fwd: I-D ACTION:draft-iijima-netconf-soap-implementation-00.t= xt] X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/mixed; boundary=3D"------------040602090304020107080901" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------040602090304020107080901 Content-Type: text/plain; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I submitted the new I-D. If time slot is available in the 67th meeting,= let me touch upon this I-D. Regards, --=20 Tomoyuki Iijima Hitachi, Ltd., Central Research Laboratory 1-280, Higashi-koigakubo Kokubunji-shi, Tokyo 185-8601, Japan Tel:+81-42-323-1111 ext.3579 Fax:+81-42-327-7868 E-mail:tomoyuki.iijima.fg@hitachi.com --------------040602090304020107080901 Content-Type: message/rfc822; name*0=3D"I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0=3D"I-D ACTION:draft-iijima-netconf-soap-implementation-00.t= xt" X-Account-Key: account4 Received: from mlsv7.hitachi.co.jp by gmml25.itg.hitachi.co.jp (AIX5.2/= 8.11.6p2/8.11.0) id k9IMtm220467800; Thu, 19 Oct 2006 07:55:48 +0900 Received: from navgw2.itg.hitachi.co.jp by mlsv7.hitachi.co.jp (8.12.11= /8.12.11) id k9IMsXLd005418; Thu, 19 Oct 2006 07:55:48 +0900 Received: from unimail4.hitachi.co.jp ([133.144.247.151]) by navgw2.itg.hitachi.co.jp with SMTP id M2006101907554810354 for ; Thu, 19 Oct 2006 07= :55:48 +0900 Received: from mailfwd.crl.hitachi.co.jp (unknown [133.144.31.140]) =09by unimail4.hitachi.co.jp (Postfix) with ESMTP id 85B7D310003 =09for ; Thu, 19 Oct 2006 07:53:56 +090= 0 (JST) Received: from mlsv4.hitachi.co.jp (mlsv.hitachi.co.jp [133.145.228.16]= ) =09by mailfwd.crl.hitachi.co.jp (8.13.7/8.13.7) with ESMTP id k9IMtmut0= 18075 =09for ; Thu, 19 Oct 2006 07:55:48 +0900 Received: from mfilter-r6.hitachi.co.jp by mlsv4.hitachi.co.jp (8.12.10= /8.12.10) id k9IMtm38025782; Thu, 19 Oct 2006 07:55:48 +0900 Received: from vshutr4.hitachi.co.jp (unverified) by mfilter-r6.hitachi= .co.jp (Clearswift SMTPRS 5.2.5) with SMTP id ; Thu, 19 Oct 2006 07:55:48 +0900 Received: from hitiij.hitachi.co.jp ([133.145.224.3]) by vshutr4.hitachi.co.jp with SMTP id M2006101907554718027 ; Thu, 19 Oct 2006 07:55:48 +0900 Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) =09by hitiij.hitachi.co.jp (Postfix) with ESMTP id 1622433CD6; =09Thu, 19 Oct 2006 07:55:47 +0900 (JST) Received: from [127.0.0.1] (helo=3Dstiedprmman1.va.neustar.com) =09by megatron.ietf.org with esmtp (Exim 4.43) =09id 1GaHS6-00031O-0k; Wed, 18 Oct 2006 15:51:46 -0400 Received: from [10.91.34.44] (helo=3Dietf-mx.ietf.org) =09by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHQU-00013I-Fl =09for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) =09by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHQR-0003nX-Cr =09for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com =09[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 50F5D26E58= =09for ; Wed, 18 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) =09id 1GaHQR-0001VC-5I =09for i-d-announce@ietf.org; Wed, 18 Oct 2006 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary=3D"NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc:=20 From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 18 Oct 2006 15:50:03 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt=20 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: = , =09 List-Archive: List-Post: List-Help: List-Subscribe: , =09 Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =09Title=09=09: Experience of NETCONF over SOAP Implementation =09Author(s)=09: I. Tomoyuki, et al. =09Filename=09: draft-iijima-netconf-soap-implementation-00.txt =09Pages=09=09: 13 =09Date=09=09: 2006-10-18 =09 NETCONF protocol is standardized to be exchanged over SSH, SOAP, or BEEP. We actually developed network management system based on NETCONF protocol. For several reasons, we chose SOAP protocol as a transport protocol of the NETCONF. This document describes why we chose SOAP as a transport protocol and the insight gained from actua= l development. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implement= ation-00.txt To remove yourself from the I-D Announcement list, send a message to=20= i-d-announce-request@ietf.org with the word unsubscribe in the body of=20= the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20= to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-iijima-netconf-soap-implementation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: =09mailserv@ietf.org. In the body type: =09"FILE /internet-drafts/draft-iijima-netconf-soap-implementation-00.t= xt". =09 NOTE:=09The mail server at ietf.org can return the document in =09MIME-encoded form by using the "mpack" utility. To use this =09feature, insert the command "ENCODING mime" before the "FILE" =09command. To decode the response(s), you will need "munpack" or =09a MIME-compliant mail reader. Different MIME-compliant mail readers= =09exhibit different behavior, especially when dealing with =09"multipart" MIME messages (i.e. documents which have been split =09up into multiple messages), so check your local documentation on =09how 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=3D"OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type=3D"mail-server"; =09server=3D"mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-18145604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iijima-netconf-soap-implementation-00.txt --OtherAccess Content-Type: Message/External-body; =09name=3D"draft-iijima-netconf-soap-implementation-00.txt"; =09site=3D"ftp.ietf.org"; access-type=3D"anon-ftp"; =09directory=3D"internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18145604.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset=3D"us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- =2E --------------040602090304020107080901-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Oct 19 18:09:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gag5J-0005gf-Ml for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 18:09:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaU73-0005ps-W0 for netconf-archive@lists.ietf.org; Thu, 19 Oct 2006 05:22:55 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaU0S-000BXb-NF for netconf-data@psg.com; Thu, 19 Oct 2006 09:16:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaU0R-000BX9-KI for netconf@ops.ietf.org; Thu, 19 Oct 2006 09:16:04 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k9J96lV4016538 for ; Thu, 19 Oct 2006 05:06:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6F35F.30F36CD8" Subject: FW: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt Date: Thu, 19 Oct 2006 11:15:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt Thread-Index: Acby75RdBZGAOtxRQXeOQV4ERCJe3gAb5PYg From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F35F.30F36CD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, October 18, 2006 9:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-iijima-netconf-soap-implementation-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Experience of NETCONF over SOAP Implementation Author(s) : I. Tomoyuki, et al. Filename : draft-iijima-netconf-soap-implementation-00.txt Pages : 13 Date : 2006-10-18 =09 NETCONF protocol is standardized to be exchanged over SSH, SOAP, or BEEP. We actually developed network management system based on NETCONF protocol. For several reasons, we chose SOAP protocol as a transport protocol of the NETCONF. This document describes why we chose SOAP as a transport protocol and the insight gained from actual development. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementa tion-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-iijima-netconf-soap-implementation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iijima-netconf-soap-implementation-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C6F35F.30F36CD8 Content-Type: application/octet-stream; name="ATT193372.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT193372.TXT Content-Disposition: attachment; filename="ATT193372.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0xMC0xODE0NTYwNC5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1paWppbWEtbmV0Y29uZi1z b2FwLWltcGxlbWVudGF0aW9uLTAwLnR4dA0K ------_=_NextPart_001_01C6F35F.30F36CD8 Content-Type: application/octet-stream; name="draft-iijima-netconf-soap-implementation-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-iijima-netconf-soap-implementation-00.URL Content-Disposition: attachment; filename="draft-iijima-netconf-soap-implementation-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1paWppbWEtbmV0Y29uZi1zb2FwLWltcGxlbWVudGF0aW9uLTAwLnR4dA0K ------_=_NextPart_001_01C6F35F.30F36CD8 Content-Type: text/plain; name="ATT193372.txt" Content-Transfer-Encoding: base64 Content-Description: ATT193372.txt Content-Disposition: attachment; filename="ATT193372.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C6F35F.30F36CD8-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Oct 22 17:29:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbkso-000184-JK for netconf-archive@lists.ietf.org; Sun, 22 Oct 2006 17:29:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbksl-00075K-5s for netconf-archive@lists.ietf.org; Sun, 22 Oct 2006 17:29:26 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gbkjl-000HsW-GE for netconf-data@psg.com; Sun, 22 Oct 2006 21:20:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gbkjk-000HrA-Ah for netconf@ops.ietf.org; Sun, 22 Oct 2006 21:20:04 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9MLDGl21745 for ; Sun, 22 Oct 2006 17:13:16 -0400 (EDT) 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: Notes on updated Notification Draft Date: Sun, 22 Oct 2006 17:19:47 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40B7CA47A@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notes on updated Notification Draft Thread-Index: Acb2H81knHnWgV45TLaPGZLtRV0LiQ== From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi We have submitted the updated Notification draft with the edits previously outlined https://ops.ietf.org/lists/netconf/netconf.2006/msg01170.html With the following two exceptions A) I still have unreferenced references for RFC2223 and RFC2026, which are both boilerplate and for Netconf Datamodel, which is still open for discussion so I just didn't bother giving it a proper hook. B) Some editing instruction squashed other instructions. For example subscription ID has been deleted, so consistently referring to it becomes moot.=20 As far as the open issue list went,=20 https://ops.ietf.org/lists/netconf/netconf.2006/msg01171.html Here is how we handled them for this updated 1. Although perhaps not the right thing to do, we have left in the transport mapping section. It has been updated with the corrections requested. It is ready to be moved elsewhere anytime now though. 2. This is also related to transport mapping. It is still open, but won't be this document's problem once moved to the SOAP document. 3. Although we had crafted a correction to this discussion of sessions and channels, it turns out this text gets deleted as a result of issue 22. 4. Did not see any further discussion on issue so left name as lastModified rather then making the suggested change. 5. Changed messagesSent to be unsignedInt, but I'm still worried we might regret that down the road. 6. Did not see any further discussion on issue, but have added text in the draft to identify the three potential timestamps of a notifications and clarified which one start time is associated with. This at least gives us something to discuss. 7. Did not see any further discussion on this issue, so have not added stopTime to draft. 8. Deleted subscriptionID. 9. Still open. No changes to draft. 10. Made change suggested by Bert since on second read this was a straight forward correction. 11. Still open. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 23 19:09:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8vG-0005HN-Ec for netconf-archive@lists.ietf.org; Mon, 23 Oct 2006 19:09:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc8vE-0005BB-RD for netconf-archive@lists.ietf.org; Mon, 23 Oct 2006 19:09:34 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gc8cN-0009cG-T6 for netconf-data@psg.com; Mon, 23 Oct 2006 22:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.6 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gc8cM-0009bk-Pf for netconf@ops.ietf.org; Mon, 23 Oct 2006 22:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E25DE328DA; Mon, 23 Oct 2006 22:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc8cL-0004Oc-Pm; Mon, 23 Oct 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-notification-04.txt Message-Id: Date: Mon, 23 Oct 2006 18:50:01 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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) : H. Trevino, S. Chisholm Filename : draft-ietf-netconf-notification-04.txt Pages : 40 Date : 2006-10-23 This document defines mechanisms which provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities, operations, transport mappings, and data models necessary to support this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-04.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-04.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-04.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-10-23153901.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-notification-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-notification-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23153901.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 Oct 23 19:37:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc9MR-00036B-FX for netconf-archive@lists.ietf.org; Mon, 23 Oct 2006 19:37:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc9MP-00038y-VW for netconf-archive@lists.ietf.org; Mon, 23 Oct 2006 19:37:39 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gc9He-000DyD-6w for netconf-data@psg.com; Mon, 23 Oct 2006 23:32:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gc9Hc-000Dxv-CM for netconf@ops.ietf.org; Mon, 23 Oct 2006 23:32:41 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9NNWd2d022533 for ; Mon, 23 Oct 2006 19:32:39 -0400 Received: (qmail 10697 invoked by uid 78); 23 Oct 2006 23:32:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 23 Oct 2006 23:32:38 -0000 Message-ID: <453D5114.4040109@andybierman.com> Date: Mon, 23 Oct 2006 16:32:36 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: [Fwd: I-D ACTION:draft-ietf-netconf-notification-04.txt] Content-Type: multipart/mixed; boundary="------------000604040601000605010701" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This is a multi-part message in MIME format. --------------000604040601000605010701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is the announcement for the new Notifications draft, in case you missed it. I want to thank Sharon and Hector for getting 2 versions out in this IETF cycle instead of 1. It really helps us from falling (more) behind in our schedule. I would like to urge the WG to read this draft ASAP and send comments to the mailing list. An 'open issues' list will be created before the San Diego meeting, for resolution at the upcoming WG meeting. thanks, Andy --------------000604040601000605010701 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-netconf-notification-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-ietf-netconf-notification-04.txt" X-Account-Key: account4 Return-Path: Delivered-To: ietf@6908.7081 Received: (qmail 2142 invoked by uid 78); 23 Oct 2006 22:58:56 -0000 Received: from unknown (HELO ns-mr17.netsolmail.com) (205.178.146.50) by mail6.lb.hosting.dc2.netsol.com with SMTP; 23 Oct 2006 22:58:56 -0000 Received: from psg.com (psg.com [147.28.0.62]) by ns-mr17.netsolmail.com (8.13.6/8.13.6) with ESMTP id k9NMwuiW003075 for ; Mon, 23 Oct 2006 18:58:56 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gc8cN-0009cG-T6 for netconf-data@psg.com; Mon, 23 Oct 2006 22:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.6 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gc8cM-0009bk-Pf for netconf@ops.ietf.org; Mon, 23 Oct 2006 22:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E25DE328DA; Mon, 23 Oct 2006 22:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc8cL-0004Oc-Pm; Mon, 23 Oct 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-notification-04.txt Message-Id: Date: Mon, 23 Oct 2006 18:50:01 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Event Notifications Author(s) : H. Trevino, S. Chisholm Filename : draft-ietf-netconf-notification-04.txt Pages : 40 Date : 2006-10-23 This document defines mechanisms which provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities, operations, transport mappings, and data models necessary to support this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-04.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-04.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-04.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-10-23153901.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-notification-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-notification-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23153901.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: --------------000604040601000605010701-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 24 11:41:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOP8-00048D-2O for netconf-archive@lists.ietf.org; Tue, 24 Oct 2006 11:41:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcOMM-0004wS-1T for netconf-archive@lists.ietf.org; Tue, 24 Oct 2006 11:38:42 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcODr-000HWT-6a for netconf-data@psg.com; Tue, 24 Oct 2006 15:29:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcODp-000HW9-IX for netconf@ops.ietf.org; Tue, 24 Oct 2006 15:29:46 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3A253EF0 for ; Tue, 24 Oct 2006 17:29:43 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 17:28:45 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 17:28:45 +0200 Message-ID: <453E312B.9000203@ericsson.com> Date: Tue, 24 Oct 2006 17:28:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification-04 comments References: <45353192.1010505@andybierman.com> <45354F56.1020300@andybierman.com> In-Reply-To: <45354F56.1020300@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 15:28:45.0299 (UTC) FILETIME=[180D1430:01C6F781] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hello, The document has improved a LOT. General) Do we really need 3 namespaces, wouldn't one or two suffice? targetNamespace="urn:ietf:params:xml:ns:netconf:subscription:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:replayNotification:1.0" and the targetnamespace in 3.2.5.3 is missing I find it confusing that we have several separate XML Schemas. I would like to see them merged, it would make the draft easier to understand. I feel the XML Schema should start with a top level element (e.g. ) and specify the containing elements all the way down. I would prefer to see examples for each and every defined message/operation/RPC. Chapter 1.4) What does the one but last requirement mean? Chapter 3.1) The capability string should be defined under it's own heading like in chapter 7.3. Chapter 3.2.5.2) Why do we need this chapter? What is the difference between this and the previous query? I propose to remove it. Chapter 3.2.5.2) Targetnamespace is missing Chapter 5) "Currently, the NETCONF family of specification allows for running NETCONF over a number of transport protocols, some of which support multiple configurations." What does it mean that they support multiple configurations. Isn't that valid for all protocols? Chapter 5) I think this example (without the ]]>]]> string) would be better placed in chapter 2.2.1 where I am really missing an example. I think all that's written in this chapter is trivial. We could live without this chapter. Chapter 7.5.2) Put here some text or remove it. Chapter 8) I feel that much of this chapter is trivial and does not contain any real new information. For me the only meaningful part is the last paragraph. I would add to the last paragraph that the security of the receiving manager application might be different for the different protocols e.g. netconf, Syslog, Snmp. Based on this it should be considered whether it is appropriate to send Snmp, Syslog, etc. information via Netconf. Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 24 11:41:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOPV-0004Gx-Bq for netconf-archive@lists.ietf.org; Tue, 24 Oct 2006 11:41:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcOI9-000494-4k for netconf-archive@lists.ietf.org; Tue, 24 Oct 2006 11:34:27 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcO7N-000Gq2-Gu for netconf-data@psg.com; Tue, 24 Oct 2006 15:23:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcO7L-000Gpj-F4 for netconf@ops.ietf.org; Tue, 24 Oct 2006 15:23:05 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED7525DC; Tue, 24 Oct 2006 17:23:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 17:23:02 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 17:23:01 +0200 Message-ID: <453E2FD3.3060301@ericsson.com> Date: Tue, 24 Oct 2006 17:22:59 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Sharon Chisholm , "Hector Trevino (htrevino)" , "Netconf (E-mail)" Subject: Notification draft 4 question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 15:23:01.0833 (UTC) FILETIME=[4B545390:01C6F780] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hello Sharon, Hector, Some questions: - Why is it really needed to be able to query the notification subscriptions as described in chapter 3.4 ? As far as I remember we can not query ongoing sessions either. The manager surely knows it's own sessions. Querying other user's sessions might even be seen as a security problem. - Why did you/we decide not to have a stop time in the replay capability? - Why did you/we decide to stop a replay subscription after the stored notifications are sent. I would find it useful to let it run and supply new notifications as usual. With the current solution if you have a restart you first have to replay the lost notifications, then kill the replay subscription. Simultaneously you have to start a normal notification session to receive new notifications and then filter out any notifications that might have arrived on both sessions. If we would have a stop time and could set it to never, all you would have to do is start a subscription and let it run. Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 24 16:45:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcT9a-0004d5-FP for netconf-archive@lists.ietf.org; Tue, 24 Oct 2006 16:45:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcT9N-0004Pt-NI for netconf-archive@lists.ietf.org; Tue, 24 Oct 2006 16:45:42 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcT3M-000Olc-A0 for netconf-data@psg.com; Tue, 24 Oct 2006 20:39:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcT3J-000OlD-Mi for netconf@ops.ietf.org; Tue, 24 Oct 2006 20:39:15 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id ECD191B8011 for ; Tue, 24 Oct 2006 22:38:59 +0200 (CEST) Date: Tue, 24 Oct 2006 22:38:49 +0200 (CEST) Message-Id: <20061024.223849.32179594.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: comments on notification draft 04 From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Hi, Some comments: o 3.2.5.1 The example rpc/rpc-reply is not correct XML. It should be: [...] Where "???" should be the namespace uri of the namespace where 'eventStreams' is defined. Currently, the schema in 3.2.5.3 is missing a targetNamespace. o section 3.2.5.2 is redundant o 3.2.5.3 the complexType under "eventStreams" should have a minOccurs="0"; otherwise the server can't return an empty list of event streams, which it should be able to do according to 3.2.5.1. (If I interpret that section correctly). o 3.4 in this schema, the messagesSent has a minOccurs="0". why? o 3.4 the element namedProfile/name should probably have a type. o 5.1 the example got the namespaces wrong. It should be: in order to match the other examples. o section 6. examples also have wrong namespaces and prefixes. I can email the details off-line. also, the xpath filter defined in the base protocol uses a "select" attribute for the xpath expression (it's in the rfc editor's list of edits I believe). o 7.3 defines a URL for the replay capability (http://ietf.org/netconf/notificationReplay/1.0) Why isn't this a URN? o 7.5.1 now states that the startTime refers to the time the event is generated. But since the generation time might not be present in the event, how can a client know which time to use? o There are quite a few new namespaces defined (and corresponding schemas). urn:ietf:params:xml:ns:netconf:capability:notification:1.0 urn:ietf:params:xml:ns:netconf:subscription:1.0 urn:ietf:params:xml:ns:netconf:notification:1.0 urn:ietf:params:xml:ns:netconf:replayNotification:1.0 http://ietf.org/netconf/notificationReplay/1.0 Are all these necessary? /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 Oct 25 05:32:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcf6P-0000hf-D6 for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 05:31:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcewe-0007eQ-29 for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 05:21:17 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcepX-0004G2-Is for netconf-data@psg.com; Wed, 25 Oct 2006 09:13:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcepT-0004FP-C2 for netconf@ops.ietf.org; Wed, 25 Oct 2006 09:13:47 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A3344108B; Wed, 25 Oct 2006 10:50:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:50:44 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:50:44 +0200 Message-ID: <453F2563.5000007@ericsson.com> Date: Wed, 25 Oct 2006 10:50:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: operation somewhat broken References: <45353192.1010505@andybierman.com> <45354F56.1020300@andybierman.com> <20061018.102009.131946487.mbj@tail-f.com> In-Reply-To: <20061018.102009.131946487.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 08:50:44.0224 (UTC) FILETIME=[A83BF800:01C6F812] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hello, Ericsson actually defined an own, non-standard capability because we need this test-only type/edit-config like operation. We often have datamodels/datastores that are not possible to validate completely because: - they are simply to big - they are divided into multiple semi-independent parts like in a sub-agent architecture. The different parts are possibly handled by completely different management systems, so validating in one step means problems. In http://ops.ietf.org/lists/netconf/netconf.2006/msg00192.html I asked for such possibility. So I would be very happy with Andy's proposal, I completely support it. I think we should fix this, but certainly not ignore it. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> Andy Bierman wrote: >>> Hi, >>> >>> IMO, the command is not actually useful for 'inline' >>> configuration validation. >>> >> I think the WG should decide what to do about this problem: >> >> 1) Ignore it >> 2) Document it >> 3) Fix it >> >> IMO, the proper engineering fix requires 2 independent changes: >> >> 1) Add a 'test-only' enumeration to the (edit-config) test-option >> parameter. (Remember that this entire parameter is only supported >> if the :validate capability is supported. This change could >> be done as a validate-2.0 capability, and not change the 1.0 capability. > > I think this would be a very useful enhancement. > >> 2) Remove configInlineType as one of the options for the 'source' >> parameter in the validate operation. (Make it the same data type >> as the getConfig source parameter). > > That means that you could only the 'candidate', 'running' > or 'startup'? I think this would be fine, b/c test-only is a much > more useful operation. [side note: does it make sense to validate > 'running'?] > > > /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: -- 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 Oct 25 10:14:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcjUa-00037L-Pj for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 10:12:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcjPa-0004w2-NY for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 10:07:27 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcjHI-0009FF-8o for netconf-data@psg.com; Wed, 25 Oct 2006 13:58:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 Received: from [152.81.144.100] (helo=mailironport.loria.fr) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcjHG-0009Ey-P2 for netconf@ops.ietf.org; Wed, 25 Oct 2006 13:58:43 +0000 Received: from sydney.loria.fr (HELO [152.81.8.136]) ([152.81.8.136]) by mailironport.loria.fr with ESMTP; 25 Oct 2006 15:58:40 +0200 X-IronPort-AV: i="4.09,356,1157320800"; d="vcf'?scan'208"; a="3452673:sNHT19082994" Message-ID: <453F6D59.8050409@loria.fr> Date: Wed, 25 Oct 2006 15:57:45 +0200 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: "'Netconf (E-mail)'" Subject: Error-option in copy-config Content-Type: multipart/mixed; boundary="------------070103030207010806060101" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. --------------070103030207010806060101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Why is there no error-option in the copy-config operation ? What should we do if an error occurs ? rollback everything, continue or just stop ? I think this information is not mentionned in the draft. Thanks, Vincent --------------070103030207010806060101 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;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 --------------070103030207010806060101-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 25 12:06:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclGd-0006aZ-7H for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 12:06:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclGV-0007AM-TB for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 12:06:11 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gcl7N-000MGu-D6 for netconf-data@psg.com; Wed, 25 Oct 2006 15:56:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gcl7K-000MGe-Hg for netconf@ops.ietf.org; Wed, 25 Oct 2006 15:56:37 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9PFuXHP024768 for ; Wed, 25 Oct 2006 11:56:33 -0400 Received: (qmail 14497 invoked by uid 78); 25 Oct 2006 15:56:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 25 Oct 2006 15:56:33 -0000 Message-ID: <453F8929.8070006@andybierman.com> Date: Wed, 25 Oct 2006 08:56:25 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Vincent Cridlig CC: "'Netconf (E-mail)'" Subject: Re: Error-option in copy-config References: <453F6D59.8050409@loria.fr> In-Reply-To: <453F6D59.8050409@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Vincent Cridlig wrote: > Hi, > > Why is there no error-option in the copy-config operation ? > What should we do if an error occurs ? rollback everything, continue or > just stop ? > I think this information is not mentionned in the draft. I don't know, but the element(s) you return the copy-config reply should reflect what actually happened. It's not clear to me that copy-config should have as many bells and whistles as edit-config. > > Thanks, > 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 Oct 25 14:15:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcnHL-0000fH-UW for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 14:15:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcnHG-0006tT-KU for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 14:15:03 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcnA4-000BD6-HF for netconf-data@psg.com; Wed, 25 Oct 2006 18:07:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.6 Received: from [194.199.18.100] (helo=mx-serv.inrialpes.fr) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcnA0-000BCn-Lr for netconf@ops.ietf.org; Wed, 25 Oct 2006 18:07:32 +0000 Received: from smtps.inrialpes.fr (smtps.inrialpes.fr [194.199.18.58]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k9PI7EdX025414; Wed, 25 Oct 2006 20:07:14 +0200 (MEST) Received: from [192.168.0.2] (4be54-1-89-80-248-137.dsl.club-internet.fr [89.80.248.137]) (authenticated bits=0) by smtps.inrialpes.fr (8.13.7/8.13.4) with ESMTP id k9PI7E4R030115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Oct 2006 20:07:15 +0200 Message-ID: <453FAA17.3010502@loria.fr> Date: Wed, 25 Oct 2006 20:16:55 +0200 From: Cridlig Vincent User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Andy Bierman CC: "'Netconf (E-mail)'" Subject: Re: Error-option in copy-config References: <453F6D59.8050409@loria.fr> <453F8929.8070006@andybierman.com> In-Reply-To: <453F8929.8070006@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Wed, 25 Oct 2006 20:07:15 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.cridlig@loria.fr Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d I ask that because we have a "MIB module"-based approach and modules sometimes reply with error during copy-config. So, for us, it is exactly the same situation as edit-config. Can you give us an advice to deal with such a case ? Regards Vincent Andy Bierman a écrit : > Vincent Cridlig wrote: >> Hi, >> >> Why is there no error-option in the copy-config operation ? >> What should we do if an error occurs ? rollback everything, continue >> or just stop ? >> I think this information is not mentionned in the draft. > > I don't know, but the element(s) you return the copy-config > reply should reflect what actually happened. It's not clear to me > that copy-config should have as many bells and whistles as edit-config. > > >> >> Thanks, >> 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: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Oct 25 15:04:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco2m-0000Hu-6P for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 15:04:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gco2k-00087k-Oy for netconf-archive@lists.ietf.org; Wed, 25 Oct 2006 15:04:04 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcnwC-000GKW-C1 for netconf-data@psg.com; Wed, 25 Oct 2006 18:57:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GcnwB-000GJE-1L for netconf@ops.ietf.org; Wed, 25 Oct 2006 18:57:15 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9PIv7wN004768 for ; Wed, 25 Oct 2006 14:57:09 -0400 Received: (qmail 29523 invoked by uid 78); 25 Oct 2006 18:57:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 25 Oct 2006 18:57:07 -0000 Message-ID: <453FB37A.5070001@andybierman.com> Date: Wed, 25 Oct 2006 11:56:58 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cridlig Vincent CC: "'Netconf (E-mail)'" Subject: Re: Error-option in copy-config References: <453F6D59.8050409@loria.fr> <453F8929.8070006@andybierman.com> <453FAA17.3010502@loria.fr> In-Reply-To: <453FAA17.3010502@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cridlig Vincent wrote: > I ask that because we have a "MIB module"-based approach and modules > sometimes reply with error during copy-config. > So, for us, it is exactly the same situation as edit-config. I have an "application parameter set" approach this is probably very similar. IMO, you can pick values for the error-option and test-option, etc. outside the standard (any way you want). Your MIB module probably defines the conceptual boundary for continue-on-error semantics. I use the parameter set as the boundary, and an application can have an arbitrary number of data types, parameter sets, RPCs, and notifications. An application is something like netconfd, security, routing, interfaces, etc. A parameter set could represent a sub-system within the application, or simply a grouping based on functionality (just like MIBs). If any errors occur within a particular parameter set in a PDU, then that set is not applied (continue-on-error), and processing skips to the next parameter set. Errors get recorded along the way. For other error-option enums, the boundary does not matter. First error during apply phase causes an early exit (stop-on-error) or a recover-and-exit (rollback-on-error). I use a multi-pass agent architecture, so any PDU is fully validated before any destructive phase is started. The continue-on-error option only matters when a parameter set 'apply' phase operation fails (no resources usually). Otherwise there is nothing to back out. Continue-on-error will allow the manager to force sections that validated okay to be applied, while skipping the sections that didn't. (Reminder: continue-on-error *never* means "apply these parameters even if they are invalid".) The 'validate' phase attempts to parse through the entire PDU and collect as many rpc-errors as it can. > > Can you give us an advice to deal with such a case ? > > Regards > Vincent Andy > > Andy Bierman a écrit : >> Vincent Cridlig wrote: >>> Hi, >>> >>> Why is there no error-option in the copy-config operation ? >>> What should we do if an error occurs ? rollback everything, continue >>> or just stop ? >>> I think this information is not mentionned in the draft. >> >> I don't know, but the element(s) you return the copy-config >> reply should reflect what actually happened. It's not clear to me >> that copy-config should have as many bells and whistles as edit-config. >> >> >>> >>> Thanks, >>> 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: > > > -- > to 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 Oct 27 11:08:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTKB-0005wB-Ks for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:08:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTJo-0001wV-VN for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:08:47 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdT5k-0008Ek-Oz for netconf-data@psg.com; Fri, 27 Oct 2006 14:53:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdT5i-0008CF-3Z for netconf@ops.ietf.org; Fri, 27 Oct 2006 14:53:51 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 652414F0001; Fri, 27 Oct 2006 16:53:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 16:53:22 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 16:53:22 +0200 Message-ID: <45421D60.2080909@ericsson.com> Date: Fri, 27 Oct 2006 16:53:20 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Andy Bierman CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> In-Reply-To: <45338A0B.8020306@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 14:53:22.0752 (UTC) FILETIME=[A6275C00:01C6F9D7] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hello, You are right, we need access control. For this reason each action defined in the data model should be defined as read/write/disturb-traffic. read: it only reads configuration and state data and doesn't effect the traffic write: it writes configuration data, but does not disturb the traffic disturb-traffic: means it can do anything. One can debate that these are the good categories for access control. Still the basic statement is that for each action defined in the data model you need to specify it's access properties in the data model as well. Balazs Andy Bierman wrote: > Your access control model should be more robust than > simply allowing user X to do anything called . > I don't see what benefit an intermediate SW component > can realize if an extra generic container is added to . > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Oct 27 11:41:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTpc-0000v7-BA for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:41:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTpT-0007cs-OC for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:41:16 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTj4-000Cpy-AP for netconf-data@psg.com; Fri, 27 Oct 2006 15:34:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTj2-000Cj6-9i for netconf@ops.ietf.org; Fri, 27 Oct 2006 15:34:29 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 85AB6128E; Fri, 27 Oct 2006 17:06:26 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:06:26 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:06:25 +0200 Message-ID: <45422071.9000907@ericsson.com> Date: Fri, 27 Oct 2006 17:06:25 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Phil Shafer CC: Martin Bjorklund , ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: action RPC I-D References: <200610161445.k9GEj8wn092718@idle.juniper.net> In-Reply-To: <200610161445.k9GEj8wn092718@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 15:06:26.0031 (UTC) FILETIME=[79063FF0:01C6F9D9] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Hello, You could just as naturally map CLI commands into actions, see below. Some of the intermediate entities might not want / not need to understand the full data model, like in the sub-agent architecture, etc. Balazs Phil Shafer wrote: > Martin Bjorklund writes: >> It's not identified differently, I wasn't clear - I meant something >> like this: >> >> >> /interfaces[ifIndex="2"]/reset >> >> >> more of an OO style I guess - execute the 'reset' action on the >> '/interface[ifIndex="2"]' object. > > We have a rich history of failed OO-ish approaches. IMHO the > key to netconf lies in leveraging the existing infrastructure > of existing CLIs. CLIs are not oriented toward this sort of > approach, but use more direct action verbs: > > reset interface 2 > ping foo.net > reboot > install new-sw.tgz > > which translate easily into direct RPCs: > > > > foo.net > > > ping /top/interfaces/interface["ifName=eth0"] foo.net > Options from the "ping" command become xml elements under the > element. Imagine trying to encode options under a > string like "/interfaces[ifIndex="2"]/reset". > > In addition, using a string loses all the specificity that > an XML schema tries to buy you. Your only tool to restrict > the content of a string is a regex, which, well, stinks when > compared with the descriptive capabilities of schema for > a element and its contents. Thats why I lifted out callingPoint. Also I agree that even for other parameters we should not encode multiple data items in one string. > >> Yes, since the argument is that it might be easier to >> design/implement/envision intermediate SW components if the structure >> of the rpc is well-known; I guess this argument can be rejected as >> being an implementation issue. > > Let the schema (or whatever your schema is generated from) drive > your intermediate SW components. If your command hierarchy (and/or > config hierarchy) drives your xml content, then the same internal > data can drive it all. XML schemas, XML parsers, and command parsers > all groking the same data will help keep the schema, API, and CLI > in sync. > > Thanks, > Phil -- 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 Fri Oct 27 11:43:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTrc-0004Uq-Pa for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:43:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTrU-000856-AR for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:43:20 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTkY-000D08-9Y for netconf-data@psg.com; Fri, 27 Oct 2006 15:36:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTkX-000CxR-2o for netconf@ops.ietf.org; Fri, 27 Oct 2006 15:36:01 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1B77F4F0001; Fri, 27 Oct 2006 17:30:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:30:57 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:30:57 +0200 Message-ID: <45422631.4010808@ericsson.com> Date: Fri, 27 Oct 2006 17:30:57 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: David B Harrington CC: 'Andy Bierman' , 'Martin Bjorklund' , phil@juniper.net, netconf@ops.ietf.org Subject: Re: action RPC I-D References: <050901c6f161$c3d22a10$0600a8c0@china.huawei.com> In-Reply-To: <050901c6f161$c3d22a10$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 15:30:57.0366 (UTC) FILETIME=[E6022760:01C6F9DC] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, David B Harrington wrote: > Hi, > > At the IAB Workshop, one of the strong points was that operators want > to be able to "read" the content on the wire. Adding such regex > formatting will make the content much less human-friendly. You do not need regexp formating for action. I put in callingPoint just to avoid this. Where do you see regular expressions in the draft? > > I think the action increases the difficulty of access control > specification, and increases the likelihood of non-interoperable > commands. I believe that there will always be vendor specific actions as there are vendor specific CLI commands today. For me the question is really just how to handle them? operation or new operation every time. If you have an operation defined in the data model then at least you have a place to put the access control information (in the DM). How does using separate new operations defined in a non machine digestible document make access control easier ? > Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Oct 27 11:44:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTsH-0004zH-4w for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:44:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTsE-0008B5-Hc for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:44:01 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTmD-000DEu-0F for netconf-data@psg.com; Fri, 27 Oct 2006 15:37:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTmC-000DEi-1R for netconf@ops.ietf.org; Fri, 27 Oct 2006 15:37:44 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9RFbYEj020351 for ; Fri, 27 Oct 2006 11:37:38 -0400 Received: (qmail 23321 invoked by uid 78); 27 Oct 2006 15:37:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 27 Oct 2006 15:37:34 -0000 Message-ID: <454227B7.8060801@andybierman.com> Date: Fri, 27 Oct 2006 08:37:27 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Balazs Lengyel CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> In-Reply-To: <45421D60.2080909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Balazs Lengyel wrote: > Hello, > You are right, we need access control. > > For this reason each action defined in the data model should be defined > as read/write/disturb-traffic. > read: it only reads configuration and state data and doesn't effect the > traffic > write: it writes configuration data, but does not disturb the traffic > disturb-traffic: means it can do anything. IMO, a clean access control model for NETCONF need to recognize the RPC model and the configuration datastore architecture. First, there is the RPC method, defined by a QName. The user must have access to invoke the RPC method. Completely independent of that is the data access control model applied to all configuration datastores. The NETCONF operations are create, delete, merge, and replace. For access control purposes, merge and replace operations are treated as a 'create' if the target data instance does not exist. The granularity could be a coarse as read/write, but that would totally defeat the purpose of create and delete operations in the edit-config method. An access control that matches the capabilities of the protocol needs to include read/write/create+delete as the 3 levels of data access (4 if you count 'none'). It makes no sense to have an 'exec' or 'disturb-traffic' access control classification in the data space. Either the user can invoke the RPC method or not. Remember, it is the PROTOCOL that needs an access control model, not blobs of XML. IMO, focusing the ACM on the XML is the wrong approach. > > One can debate that these are the good categories for access control. > Still the basic statement is that for each action defined in the data > model you need to specify it's access properties in the data model as well. > Balazs > > Andy Bierman wrote: >> Your access control model should be more robust than >> simply allowing user X to do anything called . >> I don't see what benefit an intermediate SW component >> can realize if an extra generic container is added to . >> > > 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 Oct 27 11:49:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTxi-0002og-7A for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:49:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTxg-0000tE-Tb for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:49:38 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTi5-000Chq-D1 for netconf-data@psg.com; Fri, 27 Oct 2006 15:33:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTi4-000ChV-7E for netconf@ops.ietf.org; Fri, 27 Oct 2006 15:33:29 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9RFFPs9004468 for ; Fri, 27 Oct 2006 11:15:26 -0400 Received: (qmail 8044 invoked by uid 78); 27 Oct 2006 15:15:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 27 Oct 2006 15:15:25 -0000 Message-ID: <45422285.7080605@andybierman.com> Date: Fri, 27 Oct 2006 08:15:17 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Balazs Lengyel CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> In-Reply-To: <45421D60.2080909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Balazs Lengyel wrote: > Hello, > You are right, we need access control. > > For this reason each action defined in the data model should be defined > as read/write/disturb-traffic. > read: it only reads configuration and state data and doesn't effect the > traffic > write: it writes configuration data, but does not disturb the traffic > disturb-traffic: means it can do anything. > I prefer these well-known hierarchical enumerations for max-access: read-only (read or notify) read-write (all operations except create & delete) read-create (all access) Andy > One can debate that these are the good categories for access control. > Still the basic statement is that for each action defined in the data > model you need to specify it's access properties in the data model as well. > Balazs > > Andy Bierman wrote: >> Your access control model should be more robust than >> simply allowing user X to do anything called . >> I don't see what benefit an intermediate SW component >> can realize if an extra generic container is added to . >> > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Oct 27 12:09:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH7-0008St-Qw for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 12:09:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUAD-0003Gw-UL for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 12:02:37 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTuk-000EiI-S2 for netconf-data@psg.com; Fri, 27 Oct 2006 15:46:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTuW-000EZ2-PW for netconf@ops.ietf.org; Fri, 27 Oct 2006 15:46:21 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 213664F0002; Fri, 27 Oct 2006 17:20:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:20:40 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:20:40 +0200 Message-ID: <454223C8.6090602@ericsson.com> Date: Fri, 27 Oct 2006 17:20:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Phil Shafer CC: Martin Bjorklund , ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: action RPC I-D References: <200610161649.k9GGncwn093184@idle.juniper.net> In-Reply-To: <200610161649.k9GGncwn093184@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 15:20:40.0429 (UTC) FILETIME=[764909D0:01C6F9DB] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hello, Action is just as schema-friendly as defining separate RPCs. What we gain with is a guarantee that 2 bits of data callingPoint and actionName are always present. We also gain a non-mandatory recommendation that the data model should define additional data like: access control behavior (read/write/disturb-traffic or some other values), the exact parameter types, default values etc. We believe that there are intermediate protocol handling entities that actually don't need to know more then the actionName and the callingPoint so they will not need to handle the complete data model. Action also gives the possibility to make some syntax checks on an incoming action based just on the data model without understanding what the action actually means. (parameter checks, value ranges etc.) Balazs PS. You will also make some companies (for example but not only Ericsson) happy that already use similar constructs, and you won't disturb others as they don't have to use this. Phil Shafer wrote: > Martin Bjorklund writes: >> Phil Shafer wrote: >>> Options from the "ping" command become xml elements under the >>> element. Imagine trying to encode options under a >>> string like "/interfaces[ifIndex="2"]/reset". >> This string is just to identify the action. In Balazs' draft, this >> identifier is split into two parts, the and the >> . Parameters are passed with in element in his >> draft. They would not be "encoded" into the action name. > > Okay, an action has a name, a target, and a set of parameters. > Your suggestion puts the name and the target in a string which > is uncontrolled and undocumented (as far as schema). Putting > the parameters in an element won't help you constrain them, > since the constraints need to be tied to the particular action. > > So the question is: what does a generic action buy you? > And are you trade that against what a schema-friendly RPC buys you? > > Thanks, > Phil -- 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 Fri Oct 27 12:11:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUHJ-00006H-RT for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 12:09:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdU2o-0001j6-5o for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:55:02 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTxH-000F1Q-Hh for netconf-data@psg.com; Fri, 27 Oct 2006 15:49:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTxG-000EwR-4u for netconf@ops.ietf.org; Fri, 27 Oct 2006 15:49:11 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8215B4F005F; Fri, 27 Oct 2006 17:24:27 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:24:27 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:24:26 +0200 Message-ID: <454224AA.1030609@ericsson.com> Date: Fri, 27 Oct 2006 17:24:26 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Andy Bierman CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <45422285.7080605@andybierman.com> In-Reply-To: <45422285.7080605@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 15:24:26.0760 (UTC) FILETIME=[FD306880:01C6F9DB] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 OK, I can agree with that. But still I feel that the data model is not a bad place to put this access control data. If we use individual new operations for such vendor specific actions instead of generic where do you put this data? If you put it in a document describing the related capability that will be unusable for machines. Balazs Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> You are right, we need access control. >> >> For this reason each action defined in the data model should be >> defined as read/write/disturb-traffic. >> read: it only reads configuration and state data and doesn't effect >> the traffic >> write: it writes configuration data, but does not disturb the traffic >> disturb-traffic: means it can do anything. >> > > I prefer these well-known hierarchical enumerations for max-access: > > read-only (read or notify) > read-write (all operations except create & delete) > read-create (all access) > > > Andy > > >> One can debate that these are the good categories for access control. >> Still the basic statement is that for each action defined in the data >> model you need to specify it's access properties in the data model as >> well. >> Balazs >> >> Andy Bierman wrote: >>> Your access control model should be more robust than >>> simply allowing user X to do anything called . >>> I don't see what benefit an intermediate SW component >>> can realize if an extra generic container is added to . >>> >> >> > -- 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 Fri Oct 27 12:11:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUHJ-00006H-GV for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 12:09:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdU2t-0001jy-1K for netconf-archive@lists.ietf.org; Fri, 27 Oct 2006 11:55:05 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTx3-000Exn-ES for netconf-data@psg.com; Fri, 27 Oct 2006 15:48:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.6 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdTx2-000EvP-6o for netconf@ops.ietf.org; Fri, 27 Oct 2006 15:48:57 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1C1C6110C; Fri, 27 Oct 2006 16:59:29 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 16:59:29 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 16:59:28 +0200 Message-ID: <45421ED0.4050602@ericsson.com> Date: Fri, 27 Oct 2006 16:59:28 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: action RPC I-D References: <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <20061016.161941.13773425.mbj@tail-f.com> In-Reply-To: <20061016.161941.13773425.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 14:59:28.0885 (UTC) FILETIME=[8062D250:01C6F9D8] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> In your 'restart' example, 'actionName' could just as well be >>>> the actual RPC method name, and 'callingPoint' is really >>>> just an RPC parameter, along with the entire 'parameters' sub-tree. >>> and >>> >>> Balazs Lengyel wrote: >>>> I believe handling non-standard actions is easier if we define them >>>> in the data model and not as separate operations. It particularly >>>> helps intermediate SW to handle the actions. I agree with Andy that >>>> the "end-user" of the action must always understand all new actions >>>> whatever the form used to transfer them. However there may be, there >>>> will be a number of intermediate SW blocks on the path. >>> I also agree that a data model effort should allow for operations to >>> be defined within the data model. However, how this is mapped to >>> Netconf rpcs is a different question. An operation could be mapped to >>> a generic rpc, or to a new rpc for each action. >>> >>> I agree with the "intermediate SW argument" though. >> Why? >> This seems like an implementation-specific detail to me. > > Yes, since the argument is that it might be easier to > design/implement/envision intermediate SW components if the structure > of the rpc is well-known; I guess this argument can be rejected as > being an implementation issue. > Yes it is an implementation detail, as everything else. However by ensuring that a number of data items are present in any such new RPC/action, and ensuring that they are present as separate easily recognizable bits of data we make implementation a lot easier. Imagine some RPCs carrying the calling-point in one place other in another place. Balazs -- 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 Sat Oct 28 10:23:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdp5Z-0004nt-8D for netconf-archive@lists.ietf.org; Sat, 28 Oct 2006 10:23:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdp5S-0003Bg-U9 for netconf-archive@lists.ietf.org; Sat, 28 Oct 2006 10:23:09 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gdoyt-000EF1-3C for netconf-data@psg.com; Sat, 28 Oct 2006 14:16:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gdoys-000EEm-0e for netconf@ops.ietf.org; Sat, 28 Oct 2006 14:16:14 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id 3955E1B8011; Sat, 28 Oct 2006 16:16:02 +0200 (CEST) Date: Sat, 28 Oct 2006 16:15:51 +0200 (CEST) Message-Id: <20061028.161551.53832608.mbj@tail-f.com> To: ietf@andybierman.com Cc: balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D From: Martin Bjorklund In-Reply-To: <454227B7.8060801@andybierman.com> References: <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <454227B7.8060801@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Andy Bierman wrote: > IMO, a clean access control model for NETCONF need to recognize > the RPC model and the configuration datastore architecture. > > First, there is the RPC method, defined by a QName. > The user must have access to invoke the RPC method. > > Completely independent of that is the data access control model > applied to all configuration datastores. The NETCONF operations > are create, delete, merge, and replace. For access control purposes, > merge and replace operations are treated as a 'create' if the target > data instance does not exist. > > The granularity could be a coarse as read/write, but that would > totally defeat the purpose of create and delete operations in > the edit-config method. Why? The operation 'delete' is needed in order to be able to delete stuff. The access control can still be read/write - if you have write access you're allowed to create/delete. NOTE: I'm not saying that it *should* be just read / write, I'm just questioning the logic in the argument. /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 Sat Oct 28 13:07:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdrei-0007fD-Ck for netconf-archive@lists.ietf.org; Sat, 28 Oct 2006 13:07:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdref-0001W1-0U for netconf-archive@lists.ietf.org; Sat, 28 Oct 2006 13:07:36 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdrZb-0002qV-6S for netconf-data@psg.com; Sat, 28 Oct 2006 17:02:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.57] (helo=omr7.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GdrZZ-0002qI-9N for netconf@ops.ietf.org; Sat, 28 Oct 2006 17:02:18 +0000 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9SH21wl030722 for ; Sat, 28 Oct 2006 13:02:02 -0400 Received: (qmail 25210 invoked by uid 78); 28 Oct 2006 17:01:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 28 Oct 2006 17:01:53 -0000 Message-ID: <45438CF6.5040305@andybierman.com> Date: Sat, 28 Oct 2006 10:01:42 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Bjorklund CC: balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: action RPC I-D References: <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <454227B7.8060801@andybierman.com> <20061028.161551.53832608.mbj@tail-f.com> In-Reply-To: <20061028.161551.53832608.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, a clean access control model for NETCONF need to recognize >> the RPC model and the configuration datastore architecture. >> >> First, there is the RPC method, defined by a QName. >> The user must have access to invoke the RPC method. >> >> Completely independent of that is the data access control model >> applied to all configuration datastores. The NETCONF operations >> are create, delete, merge, and replace. For access control purposes, >> merge and replace operations are treated as a 'create' if the target >> data instance does not exist. >> >> The granularity could be a coarse as read/write, but that would >> totally defeat the purpose of create and delete operations in >> the edit-config method. > > Why? The operation 'delete' is needed in order to be able to delete > stuff. The access control can still be read/write - if you have write > access you're allowed to create/delete. > delete fails if the object is not there to delete create fails if the object is already there. The point of adding these extra enums (besides the CLI style merge and replace) was to make it a bit harder to inappropriately add or delete data to the configuration. It follows that the access control model would distinguish between changing existing data and add/delete operations as well. > NOTE: I'm not saying that it *should* be just read / write, I'm just > questioning the logic in the argument. > Andy > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 30 03:12:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeSGD-0008Ch-4b for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 03:12:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeSG4-00057g-MQ for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 03:12:45 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeS6m-000HWj-CY for netconf-data@psg.com; Mon, 30 Oct 2006 08:03:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.6 Received: from [152.81.144.100] (helo=mailironport.loria.fr) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeS6k-000HW2-B1 for netconf@ops.ietf.org; Mon, 30 Oct 2006 08:02:59 +0000 Received: from sydney.loria.fr (HELO [152.81.8.136]) ([152.81.8.136]) by mailironport.loria.fr with ESMTP; 30 Oct 2006 09:02:53 +0100 X-IronPort-AV: i="4.09,370,1157320800"; d="vcf'?scan'208"; a="3651179:sNHT21350112" Message-ID: <4545B15B.9050609@loria.fr> Date: Mon, 30 Oct 2006 09:01:31 +0100 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Andy Bierman , "'Netconf (E-mail)'" Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <454227B7.8060801@andybierman.com> In-Reply-To: <454227B7.8060801@andybierman.com> Content-Type: multipart/mixed; boundary="------------070808090006040301070008" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 This is a multi-part message in MIME format. --------------070808090006040301070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Andy Bierman a écrit : > Balazs Lengyel wrote: >> Hello, >> You are right, we need access control. >> >> For this reason each action defined in the data model should be >> defined as read/write/disturb-traffic. >> read: it only reads configuration and state data and doesn't effect >> the traffic >> write: it writes configuration data, but does not disturb the traffic >> disturb-traffic: means it can do anything. > > IMO, a clean access control model for NETCONF need to recognize > the RPC model and the configuration datastore architecture. > > First, there is the RPC method, defined by a QName. > The user must have access to invoke the RPC method. > > Completely independent of that is the data access control model > applied to all configuration datastores. The NETCONF operations > are create, delete, merge, and replace. For access control purposes, > merge and replace operations are treated as a 'create' if the target > data instance does not exist. > > The granularity could be a coarse as read/write, but that would > totally defeat the purpose of create and delete operations in > the edit-config method. An access control that matches the > capabilities of the protocol needs to include read/write/create+delete > as the 3 levels of data access (4 if you count 'none'). > > It makes no sense to have an 'exec' or 'disturb-traffic' access > control classification in the data space. Either the user can > invoke the RPC method or not. Remember, it is the PROTOCOL that > needs an access control model, not blobs of XML. IMO, focusing the ACM > on the XML is the wrong approach. I don't really agree with this. When you define an access control model, you have to define permissions as a (action, resources) combination set. I think it is not possible to define permissions without a way of addressing data (XML-based or not). The ACM is usually strongly dependant on the data model. I don't understand what kind of access control policy you can specify if you don't consider the data but only the RPC ? Can you please give an example ? Also a clear distinction between Access Control Model (which specifies who can do what), and supported operations (this data is writable or readable or both, ...) must be done. These are totally different concepts and sometimes I get confused when reading the messages. IMO, a (read, write) based model is sufficient for access control. While "read" implicitely includes get, get-config, "write" implicitely includes edit-config (and its sub-operations), copy-config (write on the root node) and delete-config (write on the root node). If you define access control by RPC, you will need later to redefine access control on data: and that will be a two-levels access control which is hard to maintain and not necessary. I think the distinction between create and write is not necessary. For example, in a table, you can give create access by allowing write access on the table. You can give update access by giving access to some particular entries in the table. Regards, Vincent > > >> >> One can debate that these are the good categories for access control. >> Still the basic statement is that for each action defined in the data >> model you need to specify it's access properties in the data model as >> well. >> Balazs >> >> Andy Bierman wrote: >>> Your access control model should be more robust than >>> simply allowing user X to do anything called . >>> I don't see what benefit an intermediate SW component >>> can realize if an extra generic container is added to . >>> >> >> > > > 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: --------------070808090006040301070008 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;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 --------------070808090006040301070008-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 30 03:28:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeSV8-0000aN-41 for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 03:28:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeSV3-0007uk-QN for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 03:28:10 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeSQJ-000J6l-HE for netconf-data@psg.com; Mon, 30 Oct 2006 08:23:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 Received: from [152.81.144.100] (helo=mailironport.loria.fr) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeSQI-000J6X-Lm for netconf@ops.ietf.org; Mon, 30 Oct 2006 08:23:11 +0000 Received: from sydney.loria.fr (HELO [152.81.8.136]) ([152.81.8.136]) by mailironport.loria.fr with ESMTP; 30 Oct 2006 09:23:09 +0100 X-IronPort-AV: i="4.09,370,1157320800"; d="vcf'?scan'208"; a="3651714:sNHT24330089" Message-ID: <4545B61B.3020900@loria.fr> Date: Mon, 30 Oct 2006 09:21:47 +0100 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: "'Netconf (E-mail)'" Subject: Developper feedback Content-Type: multipart/mixed; boundary="------------070804020200040109090208" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. --------------070804020200040109090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Some weeks ago, some people here were talking about an XPath-based edit-config. Well, we are giving it a try (for fun) using the XUpdate specification which is based on XPath and allows to specify well-separated commands. I must admit that it is really easier to implement than the current edit-config for the following reasons: - there is no nested operations as it is in the current edit-config (eliminating all ambiguities at least in the developer mind), - there is a clear separation of "operation", "node selection method", and "new data", (eliminating the risk of confusing selection portion and new values to set) - command-oriented approach allows a better mapping with CLI, while being totally XML compliant. Also it makes it easier to instantiate a command design pattern with commit and rollback feature. (And even a macro-command pattern). - You can easily specify the exact position to add a node in a list. - this last item is specific to our implementation: module developers no longer have to deal with edit-config data parsing because commands generation is done at a lower level (operation). Until now, we couldn't do it because it seems that operations behaviour (merge, ...) depends on the data model. I can not say more about performances (it is too early to tell), but I bet that the standard XPath implementations (used for selecting involved data) are faster than my implementation of the current edit-config parsing. Regards, Vincent --------------070804020200040109090208 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;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 --------------070804020200040109090208-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 30 05:51:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeUjS-0002sD-6t for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 05:51:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeUjO-0008RP-Mu for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 05:51:06 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeUeF-00058O-7d for netconf-data@psg.com; Mon, 30 Oct 2006 10:45:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeUeC-00057y-WE for netconf@ops.ietf.org; Mon, 30 Oct 2006 10:45:42 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9UAjdsn020383 for ; Mon, 30 Oct 2006 05:45:40 -0500 Received: (qmail 11560 invoked by uid 78); 30 Oct 2006 10:45:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 30 Oct 2006 10:45:39 -0000 Message-ID: <4545D7CC.6000607@andybierman.com> Date: Mon, 30 Oct 2006 02:45:32 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Vincent Cridlig CC: "'Netconf (E-mail)'" Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <454227B7.8060801@andybierman.com> <4545B15B.9050609@loria.fr> In-Reply-To: <4545B15B.9050609@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Vincent Cridlig wrote: > Andy Bierman a écrit : >> Balazs Lengyel wrote: >>> Hello, >>> You are right, we need access control. >>> >>> For this reason each action defined in the data model should be >>> defined as read/write/disturb-traffic. >>> read: it only reads configuration and state data and doesn't effect >>> the traffic >>> write: it writes configuration data, but does not disturb the traffic >>> disturb-traffic: means it can do anything. >> >> IMO, a clean access control model for NETCONF need to recognize >> the RPC model and the configuration datastore architecture. >> >> First, there is the RPC method, defined by a QName. >> The user must have access to invoke the RPC method. >> >> Completely independent of that is the data access control model >> applied to all configuration datastores. The NETCONF operations >> are create, delete, merge, and replace. For access control purposes, >> merge and replace operations are treated as a 'create' if the target >> data instance does not exist. >> >> The granularity could be a coarse as read/write, but that would >> totally defeat the purpose of create and delete operations in >> the edit-config method. An access control that matches the >> capabilities of the protocol needs to include read/write/create+delete >> as the 3 levels of data access (4 if you count 'none'). >> >> It makes no sense to have an 'exec' or 'disturb-traffic' access >> control classification in the data space. Either the user can >> invoke the RPC method or not. Remember, it is the PROTOCOL that >> needs an access control model, not blobs of XML. IMO, focusing the ACM >> on the XML is the wrong approach. > > > I don't really agree with this. When you define an access control model, > you have to define permissions as a (action, resources) combination set. > I think it is not possible to define permissions without a way of > addressing data (XML-based or not). The ACM is usually strongly > dependant on the data model. I don't understand what kind of access > control policy you can specify if you don't consider the data but only > the RPC ? Can you please give an example ? or other action RPCs > > Also a clear distinction between Access Control Model (which specifies > who can do what), and supported operations (this data is writable or > readable or both, ...) must be done. These are totally different > concepts and sometimes I get confused when reading the messages. > > IMO, a (read, write) based model is sufficient for access control. While > "read" implicitely includes get, get-config, "write" implicitely > includes edit-config (and its sub-operations), copy-config (write on the > root node) and delete-config (write on the root node). If you define > access control by RPC, you will need later to redefine access control on > data: and that will be a two-levels access control which is hard to > maintain and not necessary. > > I think the distinction between create and write is not necessary. For > example, in a table, you can give create access by allowing write access > on the table. You can give update access by giving access to some > particular entries in the table. I don't think this actually works well if you have nested read-create data structures, where the instances are dynamic, and not statically assigned. But I don't mind if the model starts simple and gets refined later. > > Regards, > Vincent Andy > > > >> >> >>> >>> One can debate that these are the good categories for access control. >>> Still the basic statement is that for each action defined in the data >>> model you need to specify it's access properties in the data model as >>> well. >>> Balazs >>> >>> Andy Bierman wrote: >>>> Your access control model should be more robust than >>>> simply allowing user X to do anything called . >>>> I don't see what benefit an intermediate SW component >>>> can realize if an extra generic container is added to . >>>> >>> >>> >> >> >> Andy >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 30 09:28:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeY7x-0002I4-G7 for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 09:28:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeY7o-00069p-A2 for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 09:28:36 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeXxx-000NzI-NG for netconf-data@psg.com; Mon, 30 Oct 2006 14:18:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 Received: from [152.81.144.100] (helo=mailironport.loria.fr) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeXxv-000Nyx-Lo for netconf@ops.ietf.org; Mon, 30 Oct 2006 14:18:17 +0000 Received: from sydney.loria.fr (HELO [152.81.8.136]) ([152.81.8.136]) by mailironport.loria.fr with ESMTP; 30 Oct 2006 15:18:13 +0100 X-IronPort-AV: i="4.09,371,1157320800"; d="vcf'?scan'208"; a="3665443:sNHT36101191" Message-ID: <45460952.7070000@loria.fr> Date: Mon, 30 Oct 2006 15:16:50 +0100 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Andy Bierman , "'Netconf (E-mail)'" Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <454227B7.8060801@andybierman.com> <4545B15B.9050609@loria.fr> <4545D7CC.6000607@andybierman.com> In-Reply-To: <4545D7CC.6000607@andybierman.com> Content-Type: multipart/mixed; boundary="------------030706000602050504000409" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 This is a multi-part message in MIME format. --------------030706000602050504000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Andy Bierman a écrit : > Vincent Cridlig wrote: >> Andy Bierman a écrit : >>> Balazs Lengyel wrote: >>>> Hello, >>>> You are right, we need access control. >>>> >>>> For this reason each action defined in the data model should be >>>> defined as read/write/disturb-traffic. >>>> read: it only reads configuration and state data and doesn't effect >>>> the traffic >>>> write: it writes configuration data, but does not disturb the traffic >>>> disturb-traffic: means it can do anything. >>> >>> IMO, a clean access control model for NETCONF need to recognize >>> the RPC model and the configuration datastore architecture. >>> >>> First, there is the RPC method, defined by a QName. >>> The user must have access to invoke the RPC method. >>> >>> Completely independent of that is the data access control model >>> applied to all configuration datastores. The NETCONF operations >>> are create, delete, merge, and replace. For access control purposes, >>> merge and replace operations are treated as a 'create' if the target >>> data instance does not exist. >>> >>> The granularity could be a coarse as read/write, but that would >>> totally defeat the purpose of create and delete operations in >>> the edit-config method. An access control that matches the >>> capabilities of the protocol needs to include read/write/create+delete >>> as the 3 levels of data access (4 if you count 'none'). >>> >>> It makes no sense to have an 'exec' or 'disturb-traffic' access >>> control classification in the data space. Either the user can >>> invoke the RPC method or not. Remember, it is the PROTOCOL that >>> needs an access control model, not blobs of XML. IMO, focusing the ACM >>> on the XML is the wrong approach. >> >> >> I don't really agree with this. When you define an access control >> model, you have to define permissions as a (action, resources) >> combination set. I think it is not possible to define permissions >> without a way of addressing data (XML-based or not). The ACM is >> usually strongly dependant on the data model. I don't understand what >> kind of access control policy you can specify if you don't consider >> the data but only the RPC ? Can you please give an example ? > > > or other action RPCs Ok but these RPCs are not some of the regular operations of the Netconf draft ! To counterbalance the previous comments, it could be possible to specify an ACM with RPCs if the operations are specialized like get-interface or set-route-map. The granularity would be very large in that case but possible. But Netconf chose to have generic operations (get, edit) with parameters and therefore needs the protected resources locations as part of the ACM. Regards Vincent > >> >> Also a clear distinction between Access Control Model (which >> specifies who can do what), and supported operations (this data is >> writable or readable or both, ...) must be done. These are totally >> different concepts and sometimes I get confused when reading the >> messages. >> >> IMO, a (read, write) based model is sufficient for access control. >> While "read" implicitely includes get, get-config, "write" >> implicitely includes edit-config (and its sub-operations), >> copy-config (write on the root node) and delete-config (write on the >> root node). If you define access control by RPC, you will need later >> to redefine access control on data: and that will be a two-levels >> access control which is hard to maintain and not necessary. >> >> I think the distinction between create and write is not necessary. >> For example, in a table, you can give create access by allowing write >> access on the table. You can give update access by giving access to >> some particular entries in the table. > > I don't think this actually works well if you have > nested read-create data structures, where the instances > are dynamic, and not statically assigned. > > But I don't mind if the model starts simple and gets refined later. > >> >> Regards, >> Vincent > > Andy > >> >> >> >>> >>> >>>> >>>> One can debate that these are the good categories for access >>>> control. Still the basic statement is that for each action defined >>>> in the data model you need to specify it's access properties in the >>>> data model as well. >>>> Balazs >>>> >>>> Andy Bierman wrote: >>>>> Your access control model should be more robust than >>>>> simply allowing user X to do anything called . >>>>> I don't see what benefit an intermediate SW component >>>>> can realize if an extra generic container is added to . >>>>> >>>> >>>> >>> >>> >>> 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: >> --------------030706000602050504000409 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;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 --------------030706000602050504000409-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Oct 30 11:11:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZjj-0003uV-GH for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 11:11:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeZja-0007ef-KH for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 11:11:43 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeZZ8-00078U-8H for netconf-data@psg.com; Mon, 30 Oct 2006 16:00:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from [205.178.146.58] (helo=omr8.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeZZ6-000780-SI for netconf@ops.ietf.org; Mon, 30 Oct 2006 16:00:45 +0000 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9UG0TmW026604 for ; Mon, 30 Oct 2006 11:00:34 -0500 Received: (qmail 17915 invoked by uid 78); 30 Oct 2006 16:00:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@70.40.54.192) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 30 Oct 2006 16:00:29 -0000 Message-ID: <45462196.8020408@andybierman.com> Date: Mon, 30 Oct 2006 08:00:22 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Vincent Cridlig CC: "'Netconf (E-mail)'" Subject: Re: action RPC I-D References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <454227B7.8060801@andybierman.com> <4545B15B.9050609@loria.fr> <4545D7CC.6000607@andybierman.com> <45460952.7070000@loria.fr> In-Reply-To: <45460952.7070000@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Vincent Cridlig wrote: > Andy Bierman a écrit : >> Vincent Cridlig wrote: >>> Andy Bierman a écrit : >>>> Balazs Lengyel wrote: >>>>> Hello, >>>>> You are right, we need access control. >>>>> >>>>> For this reason each action defined in the data model should be >>>>> defined as read/write/disturb-traffic. >>>>> read: it only reads configuration and state data and doesn't effect >>>>> the traffic >>>>> write: it writes configuration data, but does not disturb the traffic >>>>> disturb-traffic: means it can do anything. >>>> >>>> IMO, a clean access control model for NETCONF need to recognize >>>> the RPC model and the configuration datastore architecture. >>>> >>>> First, there is the RPC method, defined by a QName. >>>> The user must have access to invoke the RPC method. >>>> >>>> Completely independent of that is the data access control model >>>> applied to all configuration datastores. The NETCONF operations >>>> are create, delete, merge, and replace. For access control purposes, >>>> merge and replace operations are treated as a 'create' if the target >>>> data instance does not exist. >>>> >>>> The granularity could be a coarse as read/write, but that would >>>> totally defeat the purpose of create and delete operations in >>>> the edit-config method. An access control that matches the >>>> capabilities of the protocol needs to include read/write/create+delete >>>> as the 3 levels of data access (4 if you count 'none'). >>>> >>>> It makes no sense to have an 'exec' or 'disturb-traffic' access >>>> control classification in the data space. Either the user can >>>> invoke the RPC method or not. Remember, it is the PROTOCOL that >>>> needs an access control model, not blobs of XML. IMO, focusing the ACM >>>> on the XML is the wrong approach. >>> >>> >>> I don't really agree with this. When you define an access control >>> model, you have to define permissions as a (action, resources) >>> combination set. I think it is not possible to define permissions >>> without a way of addressing data (XML-based or not). The ACM is >>> usually strongly dependant on the data model. I don't understand what >>> kind of access control policy you can specify if you don't consider >>> the data but only the RPC ? Can you please give an example ? >> >> >> or other action RPCs > > > Ok but these RPCs are not some of the regular operations of the Netconf > draft ! The protocol defines an RPC mechanism, and then later defines RPC methods in the netconf-base namespace. Just as the VACM can be used in SNMP for MIB objects defined in the enterprise OID tree, the ACM for NETCONF must work for any RPC method in any namespace. > > To counterbalance the previous comments, it could be possible to specify > an ACM with RPCs if the operations are specialized like get-interface or > set-route-map. The granularity would be very large in that case but > possible. But Netconf chose to have generic operations (get, edit) with > parameters and therefore needs the protected resources locations as part > of the ACM. Any RPC method is potentially capable of touching any configuration datastore in unknown ways. Rather than define a hard-wired ACM for 7 known RPC methods, I prefer to have a more generalized system that handles any RPC and any data. > > Regards > 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 Mon Oct 30 16:05:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeJk-0007CZ-8k for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 16:05:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeeJe-00081k-IY for netconf-archive@lists.ietf.org; Mon, 30 Oct 2006 16:05:12 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeeB0-000BaW-Ui for netconf-data@psg.com; Mon, 30 Oct 2006 20:56:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 Received: from [209.86.89.67] (helo=elasmtp-scoter.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeeAy-000BaB-6K for netconf@ops.ietf.org; Mon, 30 Oct 2006 20:56:10 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mbvM0PaqkT1MQOC/nDOYCasR6t/ZmUKRRJYxR3fkUt2bhOdJr0sdtKKHCpDC44OG; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.127] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GeeAx-00043I-8b for netconf@ops.ietf.org; Mon, 30 Oct 2006 15:56:07 -0500 Message-ID: <007f01c6fc65$d3751540$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "'Netconf \(E-mail\)'" References: <45300CC0.60203@andybierman.com> <4533466E.9080103@ericsson.com> <20061016.125830.90119364.mbj@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@ericsson.com> <454227B7.8060801@andybierman.com> <4545B15B.9050609@loria.fr> <4545D7CC.6000607@andybierman.com> <45460952.7070000@loria.fr> <45462196.8020408@andybierman.com> Subject: Re: action RPC I-D Date: Mon, 30 Oct 2006 12:56:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6241d7be6785cde8aafb62f47bcf45062350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.127 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi - > From: "Andy Bierman" > To: "Vincent Cridlig" > Cc: "'Netconf (E-mail)'" > Sent: Monday, October 30, 2006 8:00 AM > Subject: Re: action RPC I-D ... > Any RPC method is potentially capable of touching any > configuration datastore in unknown ways. Rather than > define a hard-wired ACM for 7 known RPC methods, I prefer > to have a more generalized system that handles any RPC and any data. ... From this I gather that the only way to represent the configuration (for purposes of disaster recovery, for example) of a system that supports these RPCs would be to record the sequence of RPCs over the lifetime of the box so they can be replayed into the new system. The alternative would be to retrieve the entire configuration of the managed system as some kind of checkpoint to minimuize the number RPC replays required. Neither approach sounds to me like a very good way to do real configuration management. But then, maybe I'm missing something about what edit-config and its friends really do... If one knows a system's initial configuration, and has a sequence of successful edit-config operations, is it possible to compute the final configuration state (in order to support, for example, disaster recovery) without knowing the internals of the system being configured? Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Oct 31 09:31:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeueR-0008NB-RC for netconf-archive@lists.ietf.org; Tue, 31 Oct 2006 09:31:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeueI-0006d8-TN for netconf-archive@lists.ietf.org; Tue, 31 Oct 2006 09:31:39 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeuXB-0003yO-4n for netconf-data@psg.com; Tue, 31 Oct 2006 14:24:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_PASS autolearn=ham version=3.1.6 Received: from [213.165.64.20] (helo=mail.gmx.net) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GeuXA-0003y8-3y for netconf@ops.ietf.org; Tue, 31 Oct 2006 14:24:08 +0000 Received: (qmail 9469 invoked by uid 0); 31 Oct 2006 14:24:06 -0000 Received: from 139.6.1.17 by www081.gmx.net with HTTP; Tue, 31 Oct 2006 15:24:06 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 31 Oct 2006 15:24:06 +0100 From: "Elkeir ismail" Message-ID: <20061031142406.288790@gmx.net> MIME-Version: 1.0 Subject: Send a Netconf Message To: netconf@ops.ietf.org X-Authenticated: #25225295 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi, I would like to send netconf message or build a netconf session in C from an Asterisk module to a Bandwith Broker. how can I send netconf messages from the CLI(Command Line Interface)? Does anyone have any suggestions how and where to start solving this problem? Thank you. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: