From owner-netconf@ops.ietf.org Sun Jul 01 14:17:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I53yw-0005Za-Vc for netconf-archive@lists.ietf.org; Sun, 01 Jul 2007 14:17:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I53yp-00070w-8s for netconf-archive@lists.ietf.org; Sun, 01 Jul 2007 14:17:10 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I53qc-000Gmq-Aa for netconf-data@psg.com; Sun, 01 Jul 2007 18:08:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I53qH-000GlD-GS for netconf@ops.ietf.org; Sun, 01 Jul 2007 18:08:20 +0000 Received: from diotima (localhost [127.0.0.1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id l61I8ADI016203; Sun, 1 Jul 2007 20:08:10 +0200 (CEST) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18055.60810.349360.966430@switch.ch> Date: Sun, 1 Jul 2007 20:08:10 +0200 To: netconf@ops.ietf.org Subject: Draft agenda for NETCONF session at IETF-69 X-Mailer: VM 8.0.1-465 under Emacs 22.1.1 (sparc-sun-solaris2.11) X-Face:1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Here's a draft agenda for our upcoming meeting at IETF 69 in Chicago. The chairs would like the meeting to focus on finishing up the notifications draft. Please send comments about the agenda before July 14. And if someone would like to volunteer as a scribe (Jabber or otherwise), that would be most welcome! [Note that there will be a BOF on NETCONF Extensions and Evolution (nee), see the BOF Wiki on http://www3.tools.ietf.org/bof/trac/wiki] ---------------------------------------------------------------------- Area: OPS-NM WG: Network Configuration (netconf) IETF #69 Agenda July 24, 2007 : 1740 - 1840 ============================ Chairs: Simon Leinen Andy Bierman Agenda: - Administrativia (5') - Scribes - Agenda bashing - WG status and NEE BOF - NETCONF Notifications: Final WG Review (55') - discuss WGLC mailing list comments - resolve as many identified issues as possible Internet Drafts: NETCONF Event Notifications http://tools.ietf.org/html/draft-ietf-netconf-notification ---------------------------------------------------------------------- Simon. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 01 14:17:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I53yz-0005Zw-K3 for netconf-archive@lists.ietf.org; Sun, 01 Jul 2007 14:17:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I53ys-00070z-Eu for netconf-archive@lists.ietf.org; Sun, 01 Jul 2007 14:17:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I53tB-000H6k-Fl for netconf-data@psg.com; Sun, 01 Jul 2007 18:11:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [69.147.64.89] (helo=smtp116.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I53t0-000H5W-LO for netconf@ops.ietf.org; Sun, 01 Jul 2007 18:11:08 +0000 Received: (qmail 66231 invoked from network); 1 Jul 2007 18:11:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 1 Jul 2007 18:11:02 -0000 X-YMail-OSG: mFbTyWMVM1k_UKpHkzjFSM04wMzIQsI6vQK00a3NTl07Yh6u Message-ID: <4687EDF3.1060300@andybierman.com> Date: Sun, 01 Jul 2007 11:09:55 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification Issue 6: SSH Transport 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.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi, I re-read RFC 4742 and I can only find 1 normative paragraph that is impacted by the Notifications draft: ------------------------- sec. 4, para 1: OLD: A NETCONF over SSH session consists of the manager and agent exchanging complete XML documents. Once the session has been established and capabilities have been exchanged, the manager will send complete XML documents containing elements to the server, and the agent will respond with complete XML documents containing elements. NEW: (new last sentence) A NETCONF over SSH session consists of the manager and agent exchanging complete XML documents. Once the session has been established and capabilities have been exchanged, the manager will send complete XML documents containing elements to the server, and the agent will respond with complete XML documents containing elements. In addition, complete XML documents containing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ elements may be sent from the agent to the manager. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ------------------------- There is also 1 known bug: sec 7, para 2: OLD: IANA assigned port <830> for this purpose. NEW: IANA assigned port 830 for this purpose. ^^^ ------------------------- These are the only known edits to RFC 4742 AFAIK. (Do we really have to rev the RFC for this?) Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 01 16:10:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I55l4-0005hc-U2 for netconf-archive@lists.ietf.org; Sun, 01 Jul 2007 16:10:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I55l0-0006NE-IU for netconf-archive@lists.ietf.org; Sun, 01 Jul 2007 16:10:58 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I55g8-0006oZ-6q for netconf-data@psg.com; Sun, 01 Jul 2007 20:05:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I53eH-000Fjn-TQ for netconf@ops.ietf.org; Sun, 01 Jul 2007 17:55:55 +0000 Received: (qmail 90068 invoked from network); 1 Jul 2007 17:55:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 1 Jul 2007 17:55:48 -0000 X-YMail-OSG: 2cnmnogVM1keyrQDhZox_3NDfmicK5EYI.HPDk.seObR5.cC Message-ID: <4687EA61.60505@andybierman.com> Date: Sun, 01 Jul 2007 10:54:41 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification Issue 6: SSH Transport 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.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi, I re-read RFC 4742 and I can only find 1 normative paragraph that is impacted by the Notifications draft: ------------------------- sec. 4, para 1: OLD: A NETCONF over SSH session consists of the manager and agent exchanging complete XML documents. Once the session has been established and capabilities have been exchanged, the manager will send complete XML documents containing elements to the server, and the agent will respond with complete XML documents containing elements. NEW: (new last sentence) A NETCONF over SSH session consists of the manager and agent exchanging complete XML documents. Once the session has been established and capabilities have been exchanged, the manager will send complete XML documents containing elements to the server, and the agent will respond with complete XML documents containing elements. In addition, complete XML documents containing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ elements may be sent from the agent to the manager. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ------------------------- There is also 1 known bug: sec 7, para 2: OLD: IANA assigned port <830> for this purpose. NEW: IANA assigned port 830 for this purpose. ^^^ ------------------------- These are the only known edits to RFC 4742 AFAIK. (Do we really have to rev the RFC for this?) 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 Jul 02 11:11:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5NYQ-0001sz-Pj for netconf-archive@lists.ietf.org; Mon, 02 Jul 2007 11:11:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5NXt-0000X3-8H for netconf-archive@lists.ietf.org; Mon, 02 Jul 2007 11:11:06 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5NPg-00002D-Td for netconf-data@psg.com; Mon, 02 Jul 2007 15:02:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.96] (helo=smtp123.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5NPV-000Q0F-CP for netconf@ops.ietf.org; Mon, 02 Jul 2007 15:01:59 +0000 Received: (qmail 5537 invoked from network); 2 Jul 2007 15:01:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 2 Jul 2007 15:01:52 -0000 X-YMail-OSG: 18xJ4BwVM1kiS4OP1SP2GM0s1xo85278cA9OXI1YOW_2ipsg Message-ID: <4689131C.8000609@andybierman.com> Date: Mon, 02 Jul 2007 08:00:44 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: data integrity problem with named profiles 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.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, Although NETCONF has locking, it is write locking, not read locking. If a named profile is not in a stable state (due to multiple edits), there is no way for a manager to know this, at the time the is processed. I'm not saying we need RowStatus, but it is clear that all of the design factors wrt/ data modeling have not been thought out. Setting precedence out of ignorance doesn't usually turn out so great. It should be clear to the WG (and written in the document) exactly how the data model behaves wrt/ the NETCONF protocol. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 03 11:03:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5juC-0008Qw-6p for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 11:03:04 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5juB-0004av-UR for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 11:03:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5jmC-0009sa-8Q for netconf-data@psg.com; Tue, 03 Jul 2007 14:54:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5jm1-0009rY-4l for netconf@ops.ietf.org; Tue, 03 Jul 2007 14:54:42 +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 l63EsXK10907 for ; Tue, 3 Jul 2007 14:54:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Notification Decision Point: Named Profiles Date: Tue, 3 Jul 2007 10:54:20 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FBDCB7F@zcarhxm2.corp.nortel.com> In-Reply-To: <467BDA45.6080909@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification Decision Point: Named Profiles Thread-Index: Ace02cSzOKXdPEtwQfCjfW56+yDNgAIp6ZmA References: <467BDA45.6080909@andybierman.com> From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 inline=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Friday, June 22, 2007 10:19 AM To: Netconf (E-mail) Subject: Notification Decision Point: Named Profiles =20 The use of the 'any' data type is problematic for , and there is not consensus on any deterministic algorithm for processing this operation on a data node like this, such as . Two people have strongly objected to usage of the 'any' data type at all in NETCONF data models. I think people are going to want to put filters in their own data models do it would be good to resolve the expected behaviours Proposed Consensus: * remove no-op 'stream' element =20 It is only a no-op because the stream in the create-subscription is mandatory. There are two paths to resolve this 1. Make the streams in create-subscription mutually exclusive with named profiles (like we have done with other filter parameters) and give it a min-occurs of 0. 2. Delete it from named Profiles. I think option 1 makes more sense. * declare the operation on the contents of the parameter to be 'undefined' I assume this is just for the merge operation, where the issue is? Comments? 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 Tue Jul 03 11:48:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kbw-0000LV-UW for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 11:48:16 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5kbw-0001d2-IU for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 11:48:16 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5kVe-000E16-Rt for netconf-data@psg.com; Tue, 03 Jul 2007 15:41:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.93] (helo=smtp120.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5kVT-000E0S-Tc for netconf@ops.ietf.org; Tue, 03 Jul 2007 15:41:41 +0000 Received: (qmail 58739 invoked from network); 3 Jul 2007 15:41:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 3 Jul 2007 15:41:35 -0000 X-YMail-OSG: eK3HMYcVM1lJVSjsceIBHG65a3GMz0PHU0UG7_tqY0nQ2E16 Message-ID: <468A6DE8.1010108@andybierman.com> Date: Tue, 03 Jul 2007 08:40:24 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Notification Decision Point: Named Profiles References: <467BDA45.6080909@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FBDCB7F@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FBDCB7F@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.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Sharon Chisholm wrote: > inline > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Friday, June 22, 2007 10:19 AM > To: Netconf (E-mail) > Subject: Notification Decision Point: Named Profiles > > > > The use of the 'any' data type is problematic for , and > there is not consensus on any deterministic algorithm for processing > this operation on a data node like this, such as . Two people > have strongly objected to usage of the 'any' data type at all in NETCONF > data models. > > I think people are going to want to put filters in their own data models > do it would be good to resolve the expected behaviours > > really? where are they now? I would love to hear from implementers who support on the 'any' data type now, so we can feel reassured that this is a reasonable design choice. AFAIK, many 'implementers' have expressed the opposite opinion. > > > Proposed Consensus: > * remove no-op 'stream' element > > It is only a no-op because the stream in the create-subscription is > mandatory. There are two paths to resolve this > 1. Make the streams in create-subscription mutually exclusive with > named profiles (like we have done with other filter parameters) and give > it a min-occurs of 0. > 2. Delete it from named Profiles. So the algorithm would be: 1) if namedProfiles are used, and is present in both the named profile and the RPC method, but they are different values, then generate an 'invalid-value' error 2) else use the element in the , if present 3) else use the element in the , if present 4) else use the 'NETCONF' stream. What use case does this complex option serve? The rationale for sharing filters is that they could be complex, take up lots of memory, and possibly even be generated by a 'shared application component'. The name of the stream to use hardly fits that use case. Why is the filter coupled to a stream? There is nothing in the draft (or the design) that makes this assumption. > > I think option 1 makes more sense. > > * declare the operation on the contents of the > parameter to be 'undefined' > > I assume this is just for the merge operation, where the issue is? Processing the operation attribute within the 'any' child nodes is somewhat undefined, so all the operations could be implemented in different ways, across agents. > > Comments? > > thanks, > Andy > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 03 13:22:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5m4r-0007dp-8v for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 13:22:13 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5m4r-00024f-0t for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 13:22:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5lzG-000MUx-Dm for netconf-data@psg.com; Tue, 03 Jul 2007 17:16:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [204.127.200.85] (helo=sccrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5lz5-000MU1-IC for netconf@ops.ietf.org; Tue, 03 Jul 2007 17:16:20 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007070317161401500j10abe>; Tue, 3 Jul 2007 17:16:14 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" Cc: "'Netconf \(E-mail\)'" References: <467BDA45.6080909@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FBDCB7F@zcarhxm2.corp.nortel.com> <468A6DE8.1010108@andybierman.com> Subject: RE: Notification Decision Point: Named Profiles Date: Tue, 3 Jul 2007 13:14:56 -0400 Message-ID: <053201c7bd95$b036b2e0$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 Thread-Index: Ace9iY719jAso9wYSyqXK+ng2ZixcAACxC+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <468A6DE8.1010108@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi, I think this is relevant to the question, > Why is the filter coupled to a stream? > There is nothing in the draft (or the design) that makes this > assumption. > From the minutes of the Montreal interim meeting: "h) Notification suppression filtering is data-model and stream dependent." My interpretation of this is that a filter might be (might need to be) designed to apply to a particular (type of) stream. If, for example, the SIP community developed a new stream format, then some SIP-specific filters might only make protocol-sense with that stream. Therefore, one might want to define the relevant stream as part of the namedProfile. dbh -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 03 13:59:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mex-0008S5-Oz for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 13:59:32 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5mex-0005xL-Gc for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 13:59:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5ma4-00002C-Ad for netconf-data@psg.com; Tue, 03 Jul 2007 17:54:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5mZt-000Q0D-Dg for netconf@ops.ietf.org; Tue, 03 Jul 2007 17:54:22 +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 l63HsDt14299 for ; Tue, 3 Jul 2007 17:54:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Notification Decision Point: Named Profiles Date: Tue, 3 Jul 2007 13:54:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FBDD01C@zcarhxm2.corp.nortel.com> In-Reply-To: <053201c7bd95$b036b2e0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification Decision Point: Named Profiles Thread-Index: Ace9iY719jAso9wYSyqXK+ng2ZixcAACxC+wAAGJ5gA= References: <467BDA45.6080909@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FBDCB7F@zcarhxm2.corp.nortel.com> <468A6DE8.1010108@andybierman.com> <053201c7bd95$b036b2e0$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hi Putting them in the same named profile does not make them related. It says that when applied to a subscription, that I apply some filters against the contents of the stream, just like it does when I do it directly against the create-subscription. It is a collection of stuff that allows someone to easily reproduce a particular subscription. Sharon=20 -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Tuesday, July 03, 2007 1:15 PM To: 'Andy Bierman'; Chisholm, Sharon (CAR:ZZ00) Cc: 'Netconf (E-mail)' Subject: RE: Notification Decision Point: Named Profiles Hi, I think this is relevant to the question, =20 > Why is the filter coupled to a stream? > There is nothing in the draft (or the design) that makes this=20 > assumption. >=20 From the minutes of the Montreal interim meeting: "h) Notification suppression filtering is data-model and=20 stream dependent." My interpretation of this is that a filter might be (might need to be) designed to apply to a particular (type of) stream. If, for example, the SIP community developed a new stream format, then some SIP-specific filters might only make protocol-sense with that stream. Therefore, one might want to define the relevant stream as part of the namedProfile. dbh -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 03 22:42:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5upX-0006da-VR for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 22:42:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5upT-0006SO-Dn for netconf-archive@lists.ietf.org; Tue, 03 Jul 2007 22:42:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5uhx-000FuJ-Rn for netconf-data@psg.com; Wed, 04 Jul 2007 02:35:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.89] (helo=smtp116.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I5uhm-000FtF-KE for netconf@ops.ietf.org; Wed, 04 Jul 2007 02:35:04 +0000 Received: (qmail 44238 invoked from network); 4 Jul 2007 02:34:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 4 Jul 2007 02:34:58 -0000 X-YMail-OSG: 2ZCm6OcVM1kZQEP2phaFCwPRZfH58Ksj2on7zU3rGZi4pvzk Message-ID: <468B0709.9060600@andybierman.com> Date: Tue, 03 Jul 2007 19:33:45 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: 'Sharon Chisholm' , "'Netconf (E-mail)'" Subject: Re: Notification Decision Point: Named Profiles References: <467BDA45.6080909@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FBDCB7F@zcarhxm2.corp.nortel.com> <468A6DE8.1010108@andybierman.com> <053201c7bd95$b036b2e0$0600a8c0@china.huawei.com> In-Reply-To: <053201c7bd95$b036b2e0$0600a8c0@china.huawei.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.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b David B Harrington wrote: > Hi, > > I think this is relevant to the question, > >> Why is the filter coupled to a stream? >> There is nothing in the draft (or the design) that makes this >> assumption. >> >>From the minutes of the Montreal interim meeting: > "h) Notification suppression filtering is data-model and > stream dependent." > > My interpretation of this is that a filter might be (might need to be) > designed to apply to a particular (type of) stream. If, for example, > the SIP community developed a new stream format, then some > SIP-specific filters might only make protocol-sense with that stream. > Therefore, one might want to define the relevant stream as part of the > namedProfile. Why? In XML, a QName completely identifies the content. The SIP-specific filters would be for a SIP-specific data model, which would have a targetNamespace and a top-level element. We don't need to reinvent XML. There is nothing special about a stream, such that it's name always indicates exactly one namespace and top-level element. So is this name field kind of a one word description clause? > > dbh Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 04 12:48:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I681e-0000WJ-Sj for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 12:48:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I681W-000622-HV for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 12:48:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I67u1-000DCn-6X for netconf-data@psg.com; Wed, 04 Jul 2007 16:40:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I67tq-000DAy-4v for netconf@ops.ietf.org; Wed, 04 Jul 2007 16:40:23 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l64GeBx11989; Wed, 4 Jul 2007 16:40:11 GMT 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: comments on notification-07 draft Date: Wed, 4 Jul 2007 12:39:59 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FC86977@zcarhxm2.corp.nortel.com> In-Reply-To: <20070629.094607.242464045.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on notification-07 draft Thread-Index: Ace6IZFtMxWkylZ7TNaitkFVERZwuwENvpPw References: <20070516.112746.09414354.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B40FB7BF1F@zcarhxm2.corp.nortel.com> <20070629.094607.242464045.mbj@tail-f.com> From: "Sharon Chisholm" To: "Martin Bjorklund" Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 >>=20 >> o 2.1.1 >>=20 >> The missing-element's error-info is broken: >>=20 >> Error-info: > missing. >>=20 >> I think that you should define an error-app-tag for the second >> error, i.e. replay asked for when it's not available. =20 >> >>=20 >> I believe there were previously comments to not have special error=20 >> messages. This was discussed in Prague too. It involves reving the=20 >> base protocol I think. >> > >Ok. So will you remove this text instead? And just refer to the >'missing-element' and 'operation-failed' standard error codes? I think I over-thought your comment. There is a formatting issue with the text in -07. I thought the bad formatting was a email artefact but finally checked the ASCII version of the document. If I fix that are were good? Sharon -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 04 14:10:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I69JK-0006G3-An for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 14:10:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I69JF-0006qd-Sj for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 14:10:42 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I69Dw-000LJ0-Kn for netconf-data@psg.com; Wed, 04 Jul 2007 18:05:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I69Df-000LFr-3j for netconf@ops.ietf.org; Wed, 04 Jul 2007 18:04:58 +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 l64I4kG28667; Wed, 4 Jul 2007 18:04:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Notification-07 XSD bugs in Date: Wed, 4 Jul 2007 14:04:31 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FC86B57@zcarhxm2.corp.nortel.com> In-Reply-To: <46631C34.8090200@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification-07 XSD bugs in Thread-Index: AcemGniJzAc6dqCaTomHfIx2MK1S9QYSxh5g References: <46631C34.8090200@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi Clarification on this since we seem to change this every release. I take it this is now what IANA is recommending we put? Is there a reference? Will this be the final value or is it a placeholder that will be replaced before publication? Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Sunday, June 03, 2007 3:53 PM To: Netconf (E-mail) Subject: Notification-07 XSD bugs in Hi, Two more XSD bugs: --------------------- OLD: NEW: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------------------- OLD: NEW: =20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------------------------- Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 04 14:20:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I69SL-00013T-OB for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 14:20:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I69SG-0000wo-S0 for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 14:20:01 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I69NX-000MMg-Eg for netconf-data@psg.com; Wed, 04 Jul 2007 18:15:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I69N9-000MKP-Gu for netconf@ops.ietf.org; Wed, 04 Jul 2007 18:14:45 +0000 Received: (qmail 25713 invoked from network); 4 Jul 2007 18:14:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 4 Jul 2007 18:14:33 -0000 X-YMail-OSG: 1pVEG3cVM1nHkD4e1co4ajHvqWc4GGAZw4iKxyuSgPgx3nfMuyuHSJ3PEdbTe6msQ1OeJp84L2MUdxtQRqyNzcRS Message-ID: <468BE341.3030805@andybierman.com> Date: Wed, 04 Jul 2007 11:13:21 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Notification-07 XSD bugs in References: <46631C34.8090200@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FC86B57@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FC86B57@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.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Sharon Chisholm wrote: > Hi > > Clarification on this since we seem to change this every release. I take > it this is now what IANA is recommending we put? Is there a reference? > Will this be the final value or is it a placeholder that will be > replaced before publication? We don't change this every release. It has been wrong from the start. For namespace URIs we use one format, and for capability URIs, we use another. In the import clause, the 2nd string is supposed to be a URL. Otherwise the validation tool gives an error message like "Cannot open urn:ietf:params:xml:ns:netconf:base:1.0" > > Sharon Andy > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Sunday, June 03, 2007 3:53 PM > To: Netconf (E-mail) > Subject: Notification-07 XSD bugs in > > Hi, > > Two more XSD bugs: > > --------------------- > > OLD: > > schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/> > > NEW: > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -------------------- > OLD: > > "urn:ietf:params:netconf:capability:notification:1.0" > schemaLocation= > "urn:ietf:params:netconf:capability:notification:1.0"/> > > NEW: > > "urn:ietf:params:xml:ns:netconf:notification:1.0" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > schemaLocation= > > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -------------------------- > > > 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 toij6565@yahoo.co.jp Wed Jul 04 19:27:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6EFe-0002Qz-25 for NETCONF-ARCHIVE@LISTS.IETF.ORG; Wed, 04 Jul 2007 19:27:14 -0400 Received: from [221.203.94.254] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6EFd-0007Ln-5a for NETCONF-ARCHIVE@LISTS.IETF.ORG; Wed, 04 Jul 2007 19:27:13 -0400 Received: from upejjntn4 (unknown [32.115.138.241]) by smtp88 (Coremail) with SMTP id Zi290DAd528lT5bD.1 for ; Sat, 05 Jul 2008 07:26:30 +0800 (CST) X-Originating-IP: [32.115.138.241] Subject: =?iso-2022-jp?B?GyRCJTslQyUvJTkkNyQrNj1MIyRKJDcbKEI=?= From: =?shift-jis?B?bWF5YQ==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7AF45.580252E0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C7AF45.580252E0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B0&$@$NNx$@$N$$$j$^$;$s!*(B $B$H$K$+$/3d$j@Z$j%;%C%/%9$N$_$G2q$C$F2<$5$$!#(B http://pure-love.biz/yu/?fs29 $B%$%d!*!*!*(B hosono145yuko@yahoo.co.uk ------=_NextPart_000_0008_01C7AF45.580252E0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B0&$@$NNx$@$N$$$j$^$;$s!*=1B(B
=
=1B$B$H$K$+$/3d$j@Z$j%;%C%/%9$N$_$G2q$C$F2<$5$$!#=1B(B
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$B%$%d!*!*!*=1B(B
hosono145yuko@yahoo.co.= uk =
------=_NextPart_000_0008_01C7AF45.580252E0-- From owner-netconf@ops.ietf.org Wed Jul 04 20:15:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6F0S-0008Fw-Mj for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 20:15:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6F0O-0001AX-7r for netconf-archive@lists.ietf.org; Wed, 04 Jul 2007 20:15:36 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6ErB-000Q0p-0X for netconf-data@psg.com; Thu, 05 Jul 2007 00:06:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6EqT-000Pvj-87 for netconf@ops.ietf.org; Thu, 05 Jul 2007 00:05:44 +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 l65058J29957 for ; Thu, 5 Jul 2007 00:05:08 GMT 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: review of draft-ietf-netconf-notification-07.txt Date: Wed, 4 Jul 2007 20:05:05 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FCD9A4D@zcarhxm2.corp.nortel.com> In-Reply-To: <016601c7a6bd$3e9c5110$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-netconf-notification-07.txt Thread-Index: AceXRE91A8nJ4LkHS6a1kG7s9y7K7QPZtIIABfsq0CA= References: <016601c7a6bd$3e9c5110$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington Sent: Monday, June 04, 2007 11:30 AM To: netconf@ops.ietf.org Subject: review of draft-ietf-netconf-notification-07.txt The XSD: "Named Profile" discusses the fact that it can be created, read, deleted, and modified. Should this documentation also include mention of the fact that once applied to a subscription, that instance cannot be modified, i.e., modifications will not impact the already-created subscription? No, it says the opposite. It is permissible to modify a named profile after it is applied. Hence the discussion with timestamps. Sharon -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 05 10:09:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6S1l-0004yL-Px for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 10:09:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6S1g-00025v-JQ for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 10:09:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6Rul-000LKp-N6 for netconf-data@psg.com; Thu, 05 Jul 2007 14:02:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6Rua-000LI0-Ls for netconf@ops.ietf.org; Thu, 05 Jul 2007 14:02:30 +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 l65E2Kh15808 for ; Thu, 5 Jul 2007 14:02:20 GMT 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: Begin Working Group Last Call: draft-ietf-netconf-notification-07.txt Date: Thu, 5 Jul 2007 10:01:59 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FCD9EBB@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Begin Working Group Last Call: draft-ietf-netconf-notification-07.txt Thread-Index: AceZXn0J3uaWTdLOQAOPOdOUCGhayAQj1+pABUe13uA= References: <464DC062.7090400@andybierman.com> From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) 3. There seems to be no need for [RFC2223] to be referenced. If there is a need however in order to avoid what would be a DOWNREF from a standards track to an Informational document, [RFC2223] should be included in a newly created Informational References sub-section.=20 xml2rfc does this on its own accord. I'll look into a way to turn it off, but failing that, can you think some appropriate text? -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 05 11:08:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Swr-00057Q-3F for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 11:08:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Swn-0005UA-I0 for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 11:08:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6Sog-0002l1-9a for netconf-data@psg.com; Thu, 05 Jul 2007 15:00:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [69.147.64.93] (helo=smtp120.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6SoT-0002iu-Ui for netconf@ops.ietf.org; Thu, 05 Jul 2007 15:00:15 +0000 Received: (qmail 27354 invoked from network); 5 Jul 2007 15:00:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 5 Jul 2007 15:00:09 -0000 X-YMail-OSG: hNam86oVM1mdKJ6Pbcto6oY3TJ6RX6pICiKpGCrwnL.ZxuE8 Message-ID: <468D0730.90400@andybierman.com> Date: Thu, 05 Jul 2007 07:58:56 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: stopping notifications 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.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi, If an agent was to keep track of dropped sessions, and perhaps even generate a notification, or take other action, then the design of the notification feature will be a concern. The only way to stop getting notifications is to drop the session. Unlike normal RPC mode (i.e., ), the agent has no indication that this is intentional and not a network problem. Would it be a feature or a hack to allow the agent to accept a request during 'notification delivery mode'? If a feature, should this be the mandatory mechanism to get out of notification mode and exit? (The tail -f command this is modeled after has the manager send 'control-c' in this case -- is our closest matching 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 Thu Jul 05 13:26:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6V5m-0002a0-PX for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:26:11 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6V5m-0004OK-G5 for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:26:10 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6UyS-000HoL-Tr for netconf-data@psg.com; Thu, 05 Jul 2007 17:18:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6UyD-000Hkq-P5 for netconf@ops.ietf.org; Thu, 05 Jul 2007 17:18:31 +0000 Received: from pc6 (1Cust189.tnt4.lnd4.gbr.da.uu.net [62.188.133.189]) by ranger.systems.pipex.net (Postfix) with SMTP id 85271E000876; Thu, 5 Jul 2007 18:18:17 +0100 (BST) Message-ID: <026c01c7bf1f$6f7553c0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" , "Netconf (E-mail)" References: <467BDA45.6080909@andybierman.com> Subject: Re: Notification Decision Point: Named Profiles Date: Thu, 5 Jul 2007 18:08:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 ----- Original Message ----- From: "Andy Bierman" To: "Netconf (E-mail)" Sent: Friday, June 22, 2007 4:18 PM Subject: Notification Decision Point: Named Profiles > > Let's see if we can reach some decisions on named profiles on the > mailing list. > They were originally added as a way for sessions to store and share static > filters on the agent, instead of passing the filter directly in the > RPC. > > The use of the 'any' data type is problematic for , and there > is not consensus on any deterministic algorithm for processing this > operation on a data node like this, such as . Two people > have strongly objected to usage of the 'any' data type at all > in NETCONF data models. > > Top Level Options: > > * Keep Named Profiles in this document and fix the problems > * Defer named profiles until data modeling issues with resolved > * Remove named profiles from this document > > > If decision is to keep named profiles: > > Clear Consensus: > * add a definition identifying 'name' as the index > > Proposed Consensus: > * remove no-op 'stream' element > * declare the operation on the contents of the > parameter to be 'undefined' > > Comments? Since you asked:-) I think that named profiles are good to have and that we should fix the problems now. But what are the problems? Trouble is, as your knowledge of XML has increased over the past two years - which it markedly has - so has, for me, the opacity of your comments. I do not know what problems you mean by any; I seem to recall a post about this a while back saying that probably only Martin and you would be interested - I read no further. I know of anyType as the root of the XML type hierarchy but do not know XML well enough to know if any also exists as something else or if it is anyType that you mean. And if anyType is meant, what is the problem? I imagine it is to do with coercion, the refinement of the type of a variable by its context, so that a consecutive number of characters could be a string, an array, an integer, float, struct ref etc depending on the context. I am a believer in coercion when the language has weak typing (as XML has) so I believe that such problems can be solved. But here, as yet, I am unclear what needs solving. Tom Petch > > 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 Thu Jul 05 13:28:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6V7o-0003Cb-09 for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:28:16 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6V7n-0004W1-OZ for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:28:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6V32-000IdO-Ca for netconf-data@psg.com; Thu, 05 Jul 2007 17:23:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6V2r-000IcN-4i for netconf@ops.ietf.org; Thu, 05 Jul 2007 17:23:14 +0000 Received: from diotima (localhost [127.0.0.1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id l65HN5HG020774; Thu, 5 Jul 2007 19:23:05 +0200 (CEST) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18061.10489.813453.249409@switch.ch> Date: Thu, 5 Jul 2007 19:23:05 +0200 To: netconf@ops.ietf.org Subject: Named profiles to be removed from next notifications draft X-Mailer: VM 8.0.1-465 under Emacs 22.1.1 (sparc-sun-solaris2.11) X-Face:1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Sharon will put up a snapshot of the upcoming -08 revision of draft-ietf-netconf-notifications later today for the group to review. This should give you the chance for a quick round of comments before the I-D cutoff (Monday 9 July 9 AM EST). As a heads-up: One of the changes in the upcoming version is that named profiles will be removed. The use case for these seems weak, they are more of a syntactic convenience, and we couldn't get consensus on the data model for them. We may add them back later IF someone provides a convincing use case AND we can specify them in a generally acceptable manner. As I said, this has been difficult in the last round. If you do find that removing named profiles would be an intolerable loss, please speak up soon. -- Simon. NETCONF WG co-chair -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 05 13:40:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6VK0-00048L-Fs for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:40:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6VJB-00075z-Gg for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:40:52 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VDl-000KDZ-Pr for netconf-data@psg.com; Thu, 05 Jul 2007 17:34:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VD6-000K7s-Mw for netconf@ops.ietf.org; Thu, 05 Jul 2007 17:33:50 +0000 Received: from localhost (h95n6c1o851.bredband.skanova.com [81.225.37.95]) by mail.tail-f.com (Postfix) with ESMTP id 2C6741B80C3; Thu, 5 Jul 2007 19:33:42 +0200 (CEST) Date: Thu, 05 Jul 2007 19:33:40 +0200 (CEST) Message-Id: <20070705.193340.24642927.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: stopping notifications From: Martin Bjorklund In-Reply-To: <468D0730.90400@andybierman.com> References: <468D0730.90400@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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: b19722fc8d3865b147c75ae2495625f2 Andy Bierman wrote: > Hi, > > If an agent was to keep track of dropped sessions, and perhaps even > generate a notification, or take other action, then the design of > the notification feature will be a concern. > > The only way to stop getting notifications is to drop the session. Or just open a new channel (netconf session) and send a for the notification session. > Unlike normal RPC mode (i.e., ), the agent has no > indication that this is intentional and not a network problem. > > Would it be a feature or a hack to allow the agent to accept a > request during 'notification delivery mode'? If a feature, should this > be the mandatory mechanism to get out of notification mode and exit? > (The tail -f command this is modeled after has the manager send 'control-c' > in this case -- is our closest matching operation.) This means that the agent has to poll for and parse incoming requests while sending notifications. If the request is something else, should an error be generated or should the session be terminated? If the agent has logic for this, it could very well handle any request, IMO. /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 Jul 05 13:52:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6VVG-0005yv-6g for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:52:30 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6VVF-0006yt-Pu for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:52:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VLm-000L3u-Dk for netconf-data@psg.com; Thu, 05 Jul 2007 17:42:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VLU-000Kzr-Pt for netconf@ops.ietf.org; Thu, 05 Jul 2007 17:42:32 +0000 Received: (qmail 26622 invoked from network); 5 Jul 2007 17:42:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 5 Jul 2007 17:42:23 -0000 X-YMail-OSG: ASWRpwwVM1msRZdL3molnIz43dHIUIzjlFtYHy8GVyFazEv4_mfJxi2RxvFmKCNCUP0M4SztBqEnSyJkh27PcAFN4kljsDY- Message-ID: <468D2D36.4080606@andybierman.com> Date: Thu, 05 Jul 2007 10:41:10 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" CC: "Netconf (E-mail)" Subject: Re: Notification Decision Point: Named Profiles References: <467BDA45.6080909@andybierman.com> <026c01c7bf1f$6f7553c0$0601a8c0@pc6> In-Reply-To: <026c01c7bf1f$6f7553c0$0601a8c0@pc6> 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.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 tom.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "Netconf (E-mail)" > Sent: Friday, June 22, 2007 4:18 PM > Subject: Notification Decision Point: Named Profiles > >> Let's see if we can reach some decisions on named profiles on the >> mailing list. >> They were originally added as a way for sessions to store and share static >> filters on the agent, instead of passing the filter directly in the >> RPC. >> >> The use of the 'any' data type is problematic for , and there >> is not consensus on any deterministic algorithm for processing this >> operation on a data node like this, such as . Two people >> have strongly objected to usage of the 'any' data type at all >> in NETCONF data models. >> >> Top Level Options: >> >> * Keep Named Profiles in this document and fix the problems >> * Defer named profiles until data modeling issues with resolved >> * Remove named profiles from this document >> >> >> If decision is to keep named profiles: >> >> Clear Consensus: >> * add a definition identifying 'name' as the index >> >> Proposed Consensus: >> * remove no-op 'stream' element >> * declare the operation on the contents of the >> parameter to be 'undefined' >> >> Comments? > > Since you asked:-) > > I think that named profiles are good to have and that we should fix the problems > now. But what are the problems? Trouble is, as your knowledge of XML has > increased over the past two years - which it markedly has - so has, for me, the > opacity of your comments. I do not know what problems you mean by any; I seem > to recall a post about this a while back saying that probably only Martin and > you would be interested - I read no further. > > I know of anyType as the root of the XML type hierarchy but do not know XML well > enough to know if any also exists as something else or if it is anyType that you > mean. > > And if anyType is meant, what is the problem? I imagine it is to do with > coercion, the refinement of the type of a variable by its context, so that a > consecutive number of characters could be a string, an array, an integer, float, > struct ref > etc depending on the context. I am a believer in coercion when the language has > weak typing (as XML has) so I believe that such problems can be solved. > > But here, as yet, I am unclear what needs solving. > The problem is processing the operation consistently for child nodes of the 'anyType'. For indexed data, it is clear which node is being created, deleted, merged, or replaced. Since 'any' could mean multiple unnamed instances of arbitrary nodes, all entries are different. For example, the way subtree filtering works, an agent can tell if the manager is deleting a leaf or a row, based on the data model. For 'anyType', the operations would not work the same as if the manager was doing an on the actual data model (not the filter for the data model), since there is no data model for 'anyType'. This is not what the manager wants, but that's too bad. Martin suggested treating 'anyType' special and perhaps ignoring the operation attribute within this node type. Balazs and I think NETCONF Configuration Databases should not contain data using this 'untyped type', rather than create special processing rules -- e.g., treat this as a simple type (leaf node) even though it isn't. > Tom Petch Andy > >> 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 Thu Jul 05 13:54:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6VX6-0007xn-Ty for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:54:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6VW6-0002Yl-ET for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 13:54:24 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VQp-000Ld3-Q8 for netconf-data@psg.com; Thu, 05 Jul 2007 17:47:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VQV-000Lbm-Qy for netconf@ops.ietf.org; Thu, 05 Jul 2007 17:47:41 +0000 Received: (qmail 2540 invoked from network); 5 Jul 2007 17:47:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 5 Jul 2007 17:47:32 -0000 X-YMail-OSG: fysTHt8VM1nV0M1PkY9qYsu3nbKYlVMvsFoRvBTbeaAjSmWC Message-ID: <468D2E6B.4020609@andybierman.com> Date: Thu, 05 Jul 2007 10:46:19 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: stopping notifications References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> In-Reply-To: <20070705.193340.24642927.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.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> If an agent was to keep track of dropped sessions, and perhaps even >> generate a notification, or take other action, then the design of >> the notification feature will be a concern. >> >> The only way to stop getting notifications is to drop the session. > > Or just open a new channel (netconf session) and send a > for the notification session. true, although a little more work for the manager > >> Unlike normal RPC mode (i.e., ), the agent has no >> indication that this is intentional and not a network problem. >> >> Would it be a feature or a hack to allow the agent to accept a >> request during 'notification delivery mode'? If a feature, should this >> be the mandatory mechanism to get out of notification mode and exit? >> (The tail -f command this is modeled after has the manager send 'control-c' >> in this case -- is our closest matching operation.) > > This means that the agent has to poll for and parse incoming requests > while sending notifications. If the request is something else, should > an error be generated or should the session be terminated? If the > agent has logic for this, it could very well handle any request, IMO. > The agent has to send something if a manager sends an RPC request during notification mode, even if it is a quick 'operation-failed' reply. Just letting the manager hang until it times out seems wrong. IMO, there is already code to close down the session in case it is dropped, and this is not nearly as hard to support as allowing any RPC method. However, the workaround could be good enough, and it won't require any changes. > > /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 Jul 05 14:12:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Vo9-0002wq-Fh for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 14:12:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Vn8-0004OR-HW for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 14:12:01 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VgU-000NKt-J2 for netconf-data@psg.com; Thu, 05 Jul 2007 18:04:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6VgJ-000NKO-Ll for netconf@ops.ietf.org; Thu, 05 Jul 2007 18:04:01 +0000 Received: from localhost (h95n6c1o851.bredband.skanova.com [81.225.37.95]) by mail.tail-f.com (Postfix) with ESMTP id 7E4E41B80C3; Thu, 5 Jul 2007 20:03:54 +0200 (CEST) Date: Thu, 05 Jul 2007 20:03:52 +0200 (CEST) Message-Id: <20070705.200352.199871663.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: stopping notifications From: Martin Bjorklund In-Reply-To: <468D2E6B.4020609@andybierman.com> References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> <468D2E6B.4020609@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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: 9182cfff02fae4f1b6e9349e01d62f32 Andy Bierman wrote: > The agent has to send something if a manager sends an RPC request > during notification mode, even if it is a quick 'operation-failed' reply. There's nothing in the draft that specifies this behaviour. > Just letting the manager hang until it times out seems wrong. Well it's wrong to try to send anything in notification mode... > IMO, there is already code to close down the session in case > it is dropped, and this is not nearly as hard to support as > allowing any RPC method. This is obviously implementation dependent. In my implementation, I would have to add code to detect this case and send an 'operation-failed' error instead of handling the request. /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 Jul 05 22:49:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dtP-00029j-7y for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 22:49:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6dtK-000381-LR for netconf-archive@lists.ietf.org; Thu, 05 Jul 2007 22:49:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6dlZ-0002JN-Fq for netconf-data@psg.com; Fri, 06 Jul 2007 02:41:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.198.200] (helo=smtp101.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6dlN-0002Iu-PI for netconf@ops.ietf.org; Fri, 06 Jul 2007 02:41:47 +0000 Received: (qmail 21550 invoked from network); 6 Jul 2007 02:41:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 6 Jul 2007 02:41:40 -0000 X-YMail-OSG: 7yHLxaQVM1lgzn_rTWo6lSW6r2wgQ_kERA0qVtIBMLsC6N4. Message-ID: <468DAB9A.1060508@andybierman.com> Date: Thu, 05 Jul 2007 19:40:26 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: stopping notifications References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> <468D2E6B.4020609@andybierman.com> <20070705.200352.199871663.mbj@tail-f.com> In-Reply-To: <20070705.200352.199871663.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.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Martin Bjorklund wrote: > Andy Bierman wrote: >> The agent has to send something if a manager sends an RPC request >> during notification mode, even if it is a quick 'operation-failed' reply. > > There's nothing in the draft that specifies this behaviour. > >> Just letting the manager hang until it times out seems wrong. > > Well it's wrong to try to send anything in notification mode... The agent cannot assume the manager will always send the correct PDU. The agent must always respond appropriately to an request. RFC 4741 says so. The immediate issue is whether or not the draft needs to say anything about this situation. I think it is better to just say the agent MAY allow RPC requests to be processed after , but if not, the agent MUST respond with an appropriate . (Define an error-app-tag like 'notification-exclusive-mode' for an operation-failed error-tag). > >> IMO, there is already code to close down the session in case >> it is dropped, and this is not nearly as hard to support as >> allowing any RPC method. > > This is obviously implementation dependent. In my implementation, I > would have to add code to detect this case and send an > 'operation-failed' error instead of handling the request. This argument washes out. You would need special code to know you are in notification mode so you should ignore the subsequent requests. I think my solution above allows the 'normal' code path to be utilized, allows an implementer to easily reject requests in notification mode, and allows a manager to easily tell if interlaced RPCs are supported (without needing yet another capability). > > > /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 Fri Jul 06 00:28:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6fQX-0006NY-MQ for netconf-archive@lists.ietf.org; Fri, 06 Jul 2007 00:28:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6fQT-000757-7J for netconf-archive@lists.ietf.org; Fri, 06 Jul 2007 00:28:17 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6fJj-000CMm-Jk for netconf-data@psg.com; Fri, 06 Jul 2007 04:21:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.198.206] (helo=smtp107.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6fJX-000CMA-Uk for netconf@ops.ietf.org; Fri, 06 Jul 2007 04:21:09 +0000 Received: (qmail 60196 invoked from network); 6 Jul 2007 04:21:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 6 Jul 2007 04:21:03 -0000 X-YMail-OSG: BmZw6tQVM1n.3ZGX9B748Z0_lq5KUFjkbL7hYcWIDg.T0Pvr4Yzm003W7DDL5zHB50oUwXUD59jsXFL_cOSXo6YfOQ-- Message-ID: <468DC2E5.4090907@andybierman.com> Date: Thu, 05 Jul 2007 21:19:49 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Notification-07 XSD bugs in References: <46631C34.8090200@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FC86B57@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FC86B57@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.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Sharon Chisholm wrote: > Hi > > Clarification on this since we seem to change this every release. I take > it this is now what IANA is recommending we put? Is there a reference? > Will this be the final value or is it a placeholder that will be > replaced before publication? > >... You are right about the notification.xsd schema, but the netconf.xsd file already exists. > OLD: > > schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/> > > NEW: > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -------------------- > OLD: > > "urn:ietf:params:netconf:capability:notification:1.0" > schemaLocation= > "urn:ietf:params:netconf:capability:notification:1.0"/> > > NEW: > > "urn:ietf:params:xml:ns:netconf:notification:1.0" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > schemaLocation= > > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> change 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 Jul 06 10:12:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6oXX-0006Mi-7Q for netconf-archive@lists.ietf.org; Fri, 06 Jul 2007 10:12:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6oSL-000591-KT for netconf-archive@lists.ietf.org; Fri, 06 Jul 2007 10:06:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6oK2-000OJw-As for netconf-data@psg.com; Fri, 06 Jul 2007 13:58:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I6oJr-000OHH-6G for netconf@ops.ietf.org; Fri, 06 Jul 2007 13:58:04 +0000 Received: from diotima (localhost [127.0.0.1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id l66DvuWo029775; Fri, 6 Jul 2007 15:57:56 +0200 (CEST) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18062.19044.127884.581149@switch.ch> Date: Fri, 6 Jul 2007 15:57:56 +0200 To: netconf@ops.ietf.org Subject: Snapshot of draft-ietf-netconf-notifications X-Mailer: VM 8.0.1-465 under Emacs 22.1.1 (sparc-sun-solaris2.11) X-Face:1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 There will be a new revision of the notifications draft before the submissions cutoff (next Monday). Sharon kindly provided a snapshot so that WG members can do a quick check whether your issues have been addressed. The snapshot and a diff from the current -07 version are available here: http://www.ops.ietf.org/netconf/notifications/ If you can have a quick look and still find any open issues, please send them to the list ASAP. I'd like to get as many non-controversial changes as possible into the next revision, so that we have a good basis for a constructive discussion at the IETF meeting. -- Simon. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 08 10:31:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7XnA-0005Dd-IX for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 10:31:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7Xn6-0005ei-5L for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 10:31:16 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7XfV-000Dpp-SI for netconf-data@psg.com; Sun, 08 Jul 2007 14:23:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7XfK-000Dp7-HQ for netconf@ops.ietf.org; Sun, 08 Jul 2007 14:23:16 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l68EN6g26174 for ; Sun, 8 Jul 2007 14:23:06 GMT 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: stopping notifications Date: Sun, 8 Jul 2007 10:23:04 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FD1FB85@zcarhxm2.corp.nortel.com> In-Reply-To: <468DAB9A.1060508@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: stopping notifications Thread-Index: Ace/eIw6XTXo9SOMS9SfCJCz5PBKdQB8atFQ References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> <468D2E6B.4020609@andybierman.com> <20070705.200352.199871663.mbj@tail-f.com> <468DAB9A.1060508@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Hi On this topic, the draft currently says: "A NETCONF server is not required to process RPC requests on the session associated with the subscription until the notification subscription is done and may silently discard these requests. A capability may be advertised to announce that a server is able to process RPCs while a notification stream is active on a session. The behaviour of such a capability is outside the scope of this document." Note that in Montreal it was agreed that processing messages just to produce error messages just did not make sense.=20 In some offline discussions, we have proposed the following improvement to the paragraph "A NETCONF server is will not read RPC requests, by default, on the session associated with the subscription until the notification subscription is done. A capability may be advertised to announce=20 that a server is able to process RPCs while a notification stream=20 is active on a session. The behaviour of such a capability is=20 outside the scope of this document."=20 Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, July 05, 2007 10:40 PM To: Martin Bjorklund Cc: netconf@ops.ietf.org Subject: Re: stopping notifications Martin Bjorklund wrote: > Andy Bierman wrote: >> The agent has to send something if a manager sends an RPC request=20 >> during notification mode, even if it is a quick 'operation-failed' reply. >=20 > There's nothing in the draft that specifies this behaviour. >=20 >> Just letting the manager hang until it times out seems wrong. >=20 > Well it's wrong to try to send anything in notification mode... The agent cannot assume the manager will always send the correct PDU. The agent must always respond appropriately to an request. RFC 4741 says so. The immediate issue is whether or not the draft needs to say anything about this situation. I think it is better to just say the agent MAY allow RPC requests to be processed after , but if not, the agent MUST respond with an appropriate . (Define an error-app-tag like 'notification-exclusive-mode' for an operation-failed error-tag). >=20 >> IMO, there is already code to close down the session in case it is=20 >> dropped, and this is not nearly as hard to support as allowing any=20 >> RPC method. >=20 > This is obviously implementation dependent. In my implementation, I=20 > would have to add code to detect this case and send an=20 > 'operation-failed' error instead of handling the request. This argument washes out. You would need special code to know you are in notification mode so you should ignore the subsequent requests. I think my solution above allows the 'normal' code path to be utilized, allows an implementer to easily reject requests in notification mode, and allows a manager to easily tell if interlaced RPCs are supported (without needing yet another capability). >=20 >=20 > /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 Sun Jul 08 11:02:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7YHb-0000wW-Bx for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 11:02:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7YHW-0006Jd-PV for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 11:02:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7YCQ-000GTP-3J for netconf-data@psg.com; Sun, 08 Jul 2007 14:57:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7YCE-000GSl-TS for netconf@ops.ietf.org; Sun, 08 Jul 2007 14:57:16 +0000 Received: (qmail 28864 invoked from network); 8 Jul 2007 14:57:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 8 Jul 2007 14:57:10 -0000 X-YMail-OSG: dvGIMYYVM1nY9XMyktS7KoFp3xT0oZNM_AT.nkkAHupodYgrKGeW2tXb.fKjOCN9v.IIpL4JAmL34L4GFJ8x2Ydv Message-ID: <4690FAFB.7040805@andybierman.com> Date: Sun, 08 Jul 2007 07:55:55 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: stopping notifications References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> <468D2E6B.4020609@andybierman.com> <20070705.200352.199871663.mbj@tail-f.com> <468DAB9A.1060508@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FD1FB85@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FD1FB85@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.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Sharon Chisholm wrote: > Hi > > On this topic, the draft currently says: > > "A NETCONF server is not required to process RPC requests on the > session associated with the subscription until the notification > subscription is done and may silently discard these requests. A > capability may be advertised to announce that a server is able to > process RPCs while a notification stream is active on a session. The > behaviour of such a capability is outside the scope of this > document." > The last 2 sentences are unacceptable. Multiple people (including myself) have requested that this text be removed. > Note that in Montreal it was agreed that processing messages just to > produce error messages just did not make sense. I do not remember this at all. RFC 4741, sec. 4.2 does not agree with this statement. The is expected if the is received by the agent. It does not say anything in RFC 4741 about the agent ignoring requests for any reason. So how does the manager know the difference between a wedged agent and one that is simply ignoring the request? Doesn't the Postel Principle require the agent to respond, even if the manager should not have sent a request at all? It seems the choices are respond or drop the session, but not ignore the request. > > In some offline discussions, we have proposed the following improvement > to the paragraph > > "A NETCONF server is will not read RPC requests, by default, on the > session associated with the subscription until the notification > subscription is done. A capability may be advertised to announce > that a server is able to process RPCs while a notification stream > is active on a session. The behaviour of such a capability is > outside the scope of this document." > This is not an improvement. If the entire feature is outside the scope of this document, then why/how does this document know the feature is controlled with a capability? We care first about multi-vendor interoperability. Support for unspecified proprietary features is not a high priority at all. Leaving the documentation vague and confusing (in the hope of leaving vendors more wiggle room) is not going to help in the AD review or IETF review phases. Fix it now or have it throw back at us later. > Sharon Andy > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, July 05, 2007 10:40 PM > To: Martin Bjorklund > Cc: netconf@ops.ietf.org > Subject: Re: stopping notifications > > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> The agent has to send something if a manager sends an RPC request >>> during notification mode, even if it is a quick 'operation-failed' > reply. >> There's nothing in the draft that specifies this behaviour. >> >>> Just letting the manager hang until it times out seems wrong. >> Well it's wrong to try to send anything in notification mode... > > The agent cannot assume the manager will always send the correct PDU. > The agent must always respond appropriately to an request. > RFC 4741 says so. > > The immediate issue is whether or not the draft needs to say anything > about this situation. > > I think it is better to just say the agent MAY allow RPC requests to be > processed after , but if not, the agent MUST > respond with an appropriate . > (Define an error-app-tag like 'notification-exclusive-mode' for an > operation-failed error-tag). > >>> IMO, there is already code to close down the session in case it is >>> dropped, and this is not nearly as hard to support as allowing any >>> RPC method. >> This is obviously implementation dependent. In my implementation, I >> would have to add code to detect this case and send an >> 'operation-failed' error instead of handling the request. > > This argument washes out. > You would need special code to know you are in notification mode so you > should ignore the subsequent requests. > > I think my solution above allows the 'normal' code path to be utilized, > allows an implementer to easily reject requests in notification mode, > and allows a manager to easily tell if interlaced RPCs are supported > (without needing yet another capability). > >> >> /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: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 08 14:59:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7byY-0006mS-Ny for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 14:59:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7byU-0003YQ-5o for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 14:59:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7brc-000FcK-1P for netconf-data@psg.com; Sun, 08 Jul 2007 18:52:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7brQ-000FbN-El for netconf@ops.ietf.org; Sun, 08 Jul 2007 18:52:02 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9055455DAE; Sun, 8 Jul 2007 20:51:55 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02733-09; Sun, 8 Jul 2007 20:51:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6887133A3; Sun, 8 Jul 2007 20:51:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2BD4C2C3148; Sun, 8 Jul 2007 20:51:50 +0200 (CEST) Date: Sun, 8 Jul 2007 20:51:49 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: stopping notifications Message-ID: <20070708185149.GA1707@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: Andy Bierman , Sharon Chisholm , netconf@ops.ietf.org References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> <468D2E6B.4020609@andybierman.com> <20070705.200352.199871663.mbj@tail-f.com> <468DAB9A.1060508@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FD1FB85@zcarhxm2.corp.nortel.com> <4690FAFB.7040805@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4690FAFB.7040805@andybierman.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Sun, Jul 08, 2007 at 07:55:55AM -0700, Andy Bierman wrote: >> Note that in Montreal it was agreed that processing messages just to >> produce error messages just did not make sense. > > I do not remember this at all. I do. > RFC 4741, sec. 4.2 does not agree with this statement. > The is expected if the is received > by the agent. It does not say anything in RFC 4741 about > the agent ignoring requests for any reason. Does it say that requests have to be processed within a given time interval? A single threaded implementation might just postpone processing requests... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 08 15:19:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7cHe-0006eF-57 for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 15:19:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7cHa-000413-F1 for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 15:19:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7cBp-000HMq-7P for netconf-data@psg.com; Sun, 08 Jul 2007 19:13:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.91] (helo=smtp118.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7cBe-000HM4-EB for netconf@ops.ietf.org; Sun, 08 Jul 2007 19:12:55 +0000 Received: (qmail 14135 invoked from network); 8 Jul 2007 19:12:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 8 Jul 2007 19:12:49 -0000 X-YMail-OSG: 5fezJogVM1nW0k0jrFXGBNfJziCHNsLaV76qJu_3O.mB6Ts2 Message-ID: <469136E6.5010105@andybierman.com> Date: Sun, 08 Jul 2007 12:11:34 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Andy Bierman , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: stopping notifications References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> <468D2E6B.4020609@andybierman.com> <20070705.200352.199871663.mbj@tail-f.com> <468DAB9A.1060508@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FD1FB85@zcarhxm2.corp.nortel.com> <4690FAFB.7040805@andybierman.com> <20070708185149.GA1707@elstar.local> In-Reply-To: <20070708185149.GA1707@elstar.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.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Juergen Schoenwaelder wrote: > On Sun, Jul 08, 2007 at 07:55:55AM -0700, Andy Bierman wrote: > >>> Note that in Montreal it was agreed that processing messages just to >>> produce error messages just did not make sense. >> I do not remember this at all. > > I do. > >> RFC 4741, sec. 4.2 does not agree with this statement. >> The is expected if the is received >> by the agent. It does not say anything in RFC 4741 about >> the agent ignoring requests for any reason. > > Does it say that requests have to be processed within a given time > interval? A single threaded implementation might just postpone > processing requests... No, there are no time limits for any NETCONF PDU exchanges. I suppose an implementation can be compliant by never processing the message and claiming no time limit has been exceeded. IMO, it would be a huge CLR to forbid an agent from responding to new requests, but the document should not specify that this feature is supported with some unidentified capability. In this case, if the agent drops the request, then the manager should eventually time out and drop the session (the only thing it was allowed to do in the first place). So the text does not need to say anything except perhaps that the agent is not required to respond to subsequent requests after is completed. > > /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 Sun Jul 08 15:32:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7cV2-0002Oz-5e for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 15:32:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7cUy-0004Ji-QL for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 15:32:52 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7cQZ-000KB4-6U for netconf-data@psg.com; Sun, 08 Jul 2007 19:28:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7cQL-000K9t-Kr for netconf@ops.ietf.org; Sun, 08 Jul 2007 19:28:09 +0000 Received: (qmail 26812 invoked from network); 8 Jul 2007 19:28:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 8 Jul 2007 19:28:01 -0000 X-YMail-OSG: Cbzo_LsVM1lXQKKTIXJlKyroGwu7Q1GWnAPSfxVNyj_M9Gn4 Message-ID: <46913A75.5090309@andybierman.com> Date: Sun, 08 Jul 2007 12:26:45 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Andy Bierman , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: stopping notifications References: <468D0730.90400@andybierman.com> <20070705.193340.24642927.mbj@tail-f.com> <468D2E6B.4020609@andybierman.com> <20070705.200352.199871663.mbj@tail-f.com> <468DAB9A.1060508@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40FD1FB85@zcarhxm2.corp.nortel.com> <4690FAFB.7040805@andybierman.com> <20070708185149.GA1707@elstar.local> In-Reply-To: <20070708185149.GA1707@elstar.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.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Juergen Schoenwaelder wrote: > On Sun, Jul 08, 2007 at 07:55:55AM -0700, Andy Bierman wrote: > >>> Note that in Montreal it was agreed that processing messages just to >>> produce error messages just did not make sense. >> I do not remember this at all. > > I do. > >> RFC 4741, sec. 4.2 does not agree with this statement. >> The is expected if the is received >> by the agent. It does not say anything in RFC 4741 about >> the agent ignoring requests for any reason. > > Does it say that requests have to be processed within a given time > interval? A single threaded implementation might just postpone > processing requests... So remind me why we can't just define this 'interleave' capability, instead of saying how it works, but punting it to the vendor? I don't really care that much one way or the other about any feature in this document. I only care about getting the document published quickly (i.e., IESG and IETF LC find the draft clear, complete, and believe independent interoperable implementations could be created from it). IMO, it would be better to put a stake in the ground and add the extra capability to this document, than ignore the issue completely. But the current middle ground is not interoperable. > > /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 Sun Jul 08 16:49:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7dh2-0007sO-Dt for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 16:49:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7dgx-0006cZ-Ka for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 16:49:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7dby-0003vS-2a for netconf-data@psg.com; Sun, 08 Jul 2007 20:44:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7dbm-0003uh-Mr for netconf@ops.ietf.org; Sun, 08 Jul 2007 20:44:00 +0000 Received: from localhost (h141n5c1o851.bredband.skanova.com [81.225.36.141]) by mail.tail-f.com (Postfix) with ESMTP id 2FAA51B80C3; Sun, 8 Jul 2007 22:43:52 +0200 (CEST) Date: Sun, 08 Jul 2007 22:43:51 +0200 (CEST) Message-Id: <20070708.224351.84156737.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: stopping notifications From: Martin Bjorklund In-Reply-To: <469136E6.5010105@andybierman.com> References: <4690FAFB.7040805@andybierman.com> <20070708185149.GA1707@elstar.local> <469136E6.5010105@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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: c1c65599517f9ac32519d043c37c5336 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Sun, Jul 08, 2007 at 07:55:55AM -0700, Andy Bierman wrote: > > > >>> Note that in Montreal it was agreed that processing messages just to > >>> produce error messages just did not make sense. > >> I do not remember this at all. > > > > I do. > > > >> RFC 4741, sec. 4.2 does not agree with this statement. > >> The is expected if the is received > >> by the agent. It does not say anything in RFC 4741 about > >> the agent ignoring requests for any reason. > > > > Does it say that requests have to be processed within a given time > > interval? A single threaded implementation might just postpone > > processing requests... > > No, there are no time limits for any NETCONF PDU exchanges. > I suppose an implementation can be compliant by never > processing the message and claiming no time limit has > been exceeded. > > IMO, it would be a huge CLR to forbid an agent from responding > to new requests, but the document should not specify that this > feature is supported with some unidentified capability. I think that the agent's behaviour must be clearly specified. We have seen two different interpretations of the words "not required to process RPC requests". One interpretation is that the agent does not read from the socket at all, and the other is that the agent reads, parses, and replies with an error. So obviously the current words are not clear enough. I think/hope Sharon's new words are better. > In this case, if the agent drops the request, It doesn't drop the request, it never reads it. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 08 18:23:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f9q-0002BY-2A for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 18:23:10 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7f9p-0004Oj-Pn for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 18:23:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7f5V-000C59-2w for netconf-data@psg.com; Sun, 08 Jul 2007 22:18:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7f5K-000C4G-HP for netconf@ops.ietf.org; Sun, 08 Jul 2007 22:18:35 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 08 Jul 2007 15:18:30 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l68MITO32803; Sun, 8 Jul 2007 15:18:29 -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 l68MQwjw049005; Sun, 8 Jul 2007 18:26:58 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200707082226.l68MQwjw049005@idle.juniper.net> To: "Sharon Chisholm" cc: netconf@ops.ietf.org Subject: Re: stopping notifications In-Reply-To: Your message of "Sun, 08 Jul 2007 10:23:04 EDT." <713043CE8B8E1348AF3C546DBE02C1B40FD1FB85@zcarhxm2.corp.nortel.com> Date: Sun, 08 Jul 2007 18:26:58 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f "Sharon Chisholm" writes: >"A NETCONF server is will not read RPC requests, by default, on the > session associated with the subscription until the notification > subscription is done. A capability may be advertised to announce > that a server is able to process RPCs while a notification stream > is active on a session. The behaviour of such a capability is > outside the scope of this document." Isn't this just a vague reference to a non-existent capability? Do specs normally do this sort of thing? Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 08 18:24:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7fB2-0002MV-7l for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 18:24:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7f9z-0002Dq-0I for netconf-archive@lists.ietf.org; Sun, 08 Jul 2007 18:24:24 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7f3c-000Buy-8Y for netconf-data@psg.com; Sun, 08 Jul 2007 22:16:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7f3R-000BuG-K8 for netconf@ops.ietf.org; Sun, 08 Jul 2007 22:16:38 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 08 Jul 2007 15:16:34 -0700 X-IronPort-AV: i="4.16,514,1175497200"; d="scan'208"; a="33298681:sNHT45758992" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l68MGRO32706; Sun, 8 Jul 2007 15:16:27 -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 l68MOujw048918; Sun, 8 Jul 2007 18:24:56 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200707082224.l68MOujw048918@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: stopping notifications In-Reply-To: Your message of "Sun, 08 Jul 2007 12:11:34 PDT." <469136E6.5010105@andybierman.com> Date: Sun, 08 Jul 2007 18:24:56 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Andy Bierman writes: >IMO, it would be a huge CLR to forbid an agent from responding >to new requests, but the document should not specify that this >feature is supported with some unidentified capability. But isn't it a bug to allow some agents to respond by not spelling out in the spec was is and isn't allowed? This is fall-out from turning the netconf session into this bi-modal thing. It gets even worse if the boundary conditions between the modes are not well defined. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 09 22:32:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I85Wi-0005Kx-30 for netconf-archive@lists.ietf.org; Mon, 09 Jul 2007 22:32:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I85We-00054I-Ie for netconf-archive@lists.ietf.org; Mon, 09 Jul 2007 22:32:32 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I85Oz-000Iaa-Qx for netconf-data@psg.com; Tue, 10 Jul 2007 02:24:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.8 Received: from [61.144.161.7] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I85On-000IZv-Pt for netconf@ops.ietf.org; Tue, 10 Jul 2007 02:24:28 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKX00M2VYOG7W@szxga04-in.huawei.com> for netconf@ops.ietf.org; Tue, 10 Jul 2007 10:24:16 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKX00HTVYOFB0@szxga04-in.huawei.com> for netconf@ops.ietf.org; Tue, 10 Jul 2007 10:24:16 +0800 (CST) Received: from jys5011175 (c-24-63-7-152.hsd1.ma.comcast.net [24.63.7.152]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKX0020SYO2C5@szxml01-in.huawei.com>; Tue, 10 Jul 2007 10:24:15 +0800 (CST) Date: Tue, 10 Jul 2007 10:24:05 +0800 From: Li Yan Subject: few quick comments on the snapshot of draft-ietf-netconf-notifications To: "Netconf (E-mail)" Cc: Sharon Chisholm Message-id: <010c01c7c299$69b198e0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_ThmG13RaCv7wnnFXAk0ldg)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.7 (+) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a multi-part message in MIME format. --Boundary_(ID_ThmG13RaCv7wnnFXAk0ldg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, I have a few comments on this revision of the draft. o Named profile has been removed from the draft, but there are some remains of 'profile' still in the text. For example: sec 2.1.1 Negative Response: ... if the name of a non-existent profile or stream is provided. sec 4 ... It takes as argument the name of the notification stream and filter or profile information. ... o sec 3.4 should be o sec 3.2.3 says: A NETCONF server implementation supporting the notification capability must support the "NETCONF" notification event stream. MUST the "NETCONF" notification event stream be present in the element? If so, the 'minOccurs' of element should be 1 instead of 0. o sec 4 Since the named profile was removed from the XSD for event notifications, the element is not needed. o sec 5.2 The 2nd example is wrong. The filtering criteria evaluation is not consistent with the XPATH expression in the element, and the namespace prefix is omitted. The XPath filter should be: --Boundary_(ID_ThmG13RaCv7wnnFXAk0ldg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,
I have a few comments on this revision of the draft.
 
o  Named profile has been removed from the draft, but there are some remains of 'profile' still in the text.
   For example:
   sec 2.1.1
   Negative Response:
     ... if the name of a non-existent profile or stream is provided.
   sec 4
   <xs:element name="create-subscription"
     ...    
            <xs:documentation>
                ... It takes as argument the name of the notification stream
                and filter or profile information.
            </xs:documentation>
     ...
   </xs:element>
 
o  sec 3.4
   <xs:element name="name" type="xs:string"/>
   should be
   <xs:element name="name" type="ncEvent:streamNameType"/>
 
o  sec 3.2.3 says: A NETCONF server implementation supporting the notification
   capability must support the "NETCONF" notification event stream.
   MUST the "NETCONF" notification event stream be present in the <eventStreams> element?
   If so, the 'minOccurs' of <stream> element should be 1 instead of 0.
 
o  sec 4
   Since the named profile was removed from the XSD for event notifications, the <xs:choice> element is not needed.
 
o  sec 5.2
   The 2nd example is wrong. The filtering criteria evaluation is not consistent with the XPATH expression in the <filter> element, and the namespace prefix is omitted.
   The XPath filter should be:
   <netconf:rpc message-id="101"
           xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
     <create-subscription
        xmlns="urn:ietf:params:netconf:capability:notification:1.0">
          <filter netconf:type="xpath"
                  xmlns:ex="http://example.com/event/1.0"
             select="/ex:event[
                (ex:eventClass='state' or ex:eventClass='config') and
                ((ex:eventClass='fault' and ex:severity='critical') or
                 (ex:eventClass='fault' and ex:severity='major') or
                 (ex:eventClass='fault' and ex:severity='minor') or
                 (ex:eventClass='fault' and ex:card='Ethernet0'))]"/>
    </create-subscription>
  </netconf:rpc>
  
 
--Boundary_(ID_ThmG13RaCv7wnnFXAk0ldg)-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 10 07:04:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8DVq-0003bd-4J for netconf-archive@lists.ietf.org; Tue, 10 Jul 2007 07:04:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8DVp-00005N-Vd for netconf-archive@lists.ietf.org; Tue, 10 Jul 2007 07:04:10 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8DP5-0004jh-MZ for netconf-data@psg.com; Tue, 10 Jul 2007 10:57:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8DOu-0004j4-Pz for netconf@ops.ietf.org; Tue, 10 Jul 2007 10:57:06 +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 l6AAuvf16990 for ; Tue, 10 Jul 2007 10:56:58 GMT 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: Forgot RFC-editor note in notification-08 Date: Tue, 10 Jul 2007 06:56:45 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FDDC02E@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Forgot RFC-editor note in notification-08 Thread-Index: AcfC4QHNvnQzV4YIRrukCDHAtv3txw== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hi I submitted the update to the notification draft before the deadline, but just realized that I forgot to put the RFC-editor note around the new url for notifications. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 10 15:23:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8LJB-00007f-0w for netconf-archive@lists.ietf.org; Tue, 10 Jul 2007 15:23:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8LIG-0000SL-2o for netconf-archive@lists.ietf.org; Tue, 10 Jul 2007 15:23:37 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8LB4-000DQv-7T for netconf-data@psg.com; Tue, 10 Jul 2007 19:15:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8LAt-000DOb-3N for netconf@ops.ietf.org; Tue, 10 Jul 2007 19:15:08 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F2370329E4; Tue, 10 Jul 2007 19:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8LAr-000499-Qy; Tue, 10 Jul 2007 15:15: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-08.txt Message-Id: Date: Tue, 10 Jul 2007 15:15:01 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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-08.txt Pages : 38 Date : 2007-7-10 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 and operations necessary to support this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-notification-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-notification-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10144429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-notification-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-notification-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10144429.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 Tue Jul 10 17:50:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NbI-0002gp-CW for netconf-archive@lists.ietf.org; Tue, 10 Jul 2007 17:50:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8NbD-0005Ns-Se for netconf-archive@lists.ietf.org; Tue, 10 Jul 2007 17:50:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8NVW-0005Y5-K0 for netconf-data@psg.com; Tue, 10 Jul 2007 21:44:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.8 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8NVK-0005VS-Lo for netconf@ops.ietf.org; Tue, 10 Jul 2007 21:44:24 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKZ00ETKGDQL5@szxga02-in.huawei.com> for netconf@ops.ietf.org; Wed, 11 Jul 2007 05:44:14 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKZ00JNMGDPFG@szxga02-in.huawei.com> for netconf@ops.ietf.org; Wed, 11 Jul 2007 05:44:14 +0800 (CST) Received: from jys5011175 ([10.192.21.54]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKZ00MILGDK21@szxml03-in.huawei.com> for netconf@ops.ietf.org; Wed, 11 Jul 2007 05:44:13 +0800 (CST) Date: Wed, 11 Jul 2007 05:44:07 +0800 From: Li Yan Subject: Comments on notification-08 To: netconf@ops.ietf.org Cc: Sharon Chisholm Message-id: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_sZR/r6pv8PzSwvY3B+ZUAg)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This is a multi-part message in MIME format. --Boundary_(ID_sZR/r6pv8PzSwvY3B+ZUAg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, Here are my comments. I commented the snapshot of draft-ietf-netconf-notifications yesterday. Some comments in it are still valid. o sec 4 Does it imply that a single operation can not subscribe multiple streams? o sec 5.1 says: an element at the top level that contains one or more child elements ... But the Figure 10 contains instead of element. o sec 5.1 The label 'Figure 12' is missing. o sec 5.1 and sec 5.2 There is element in the Figure 10. Ethernet0 But in the Figure 12 (its label is missing) and the Figure 14, is changed to . o sec 5.2 The Figure 14 is still wrong: 1. The filtering criteria evaluation is not consistent with the XPATH expression in the element. 2. Two '(' are missing. 3. It is hard to read due to different sequence of conditions. The XPath filter should be: Yan --Boundary_(ID_sZR/r6pv8PzSwvY3B+ZUAg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,
Here are my comments. I commented the snapshot of draft-ietf-netconf-notifications yesterday. Some comments in it are still valid.
o  sec 4
   <xs:element name="stream"
       type="streamNameType" minOccurs="0">
   Does it imply that a single <create-subscription> operation can not subscribe multiple streams?
 
o  sec 5.1 says: an <events> element at the top level that contains one or more child elements <eventEntry> ...
   But the Figure 10 contains <event> instead of <eventEntry> element.
 
o  sec 5.1
   The label 'Figure 12' is missing. 
 
o  sec 5.1 and sec 5.2
   There is <reportingEntity> element in the Figure 10.
   <reportingEntity>
     <card>Ethernet0</card>
   </reportingEntity>
   But in the Figure 12 (its label is missing) and the Figure 14, <reportingEntity> is changed to <reportingElement>.
 
o  sec 5.2
   The Figure 14 is still wrong:
   1. The filtering criteria evaluation is not consistent with the XPATH expression in the <filter> element.
   2. Two '(' are missing.
   3. It is hard to read due to different sequence of conditions.
   The XPath filter should be:
   <netconf:rpc message-id="101"
           xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
     <create-subscription
        xmlns="urn:ietf:params:netconf:capability:notification:1.0">
          <filter netconf:type="xpath"
                  xmlns:ex="http://example.com/event/1.0"
             select="/ex:event[
                (ex:eventClass='state' or ex:eventClass='config') and
                ((ex:eventClass='fault' and ex:severity='critical') or
                 (ex:eventClass='fault' and ex:severity='major') or
                 (ex:eventClass='fault' and ex:severity='minor') or
                 (ex:eventClass='fault' and
                         ex:reportingEntity/ex:card='Ethernet0'))]"/>
    </create-subscription>
  </netconf:rpc>
 
 
Yan
--Boundary_(ID_sZR/r6pv8PzSwvY3B+ZUAg)-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 11 12:52:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fQZ-0006H5-1d for netconf-archive@lists.ietf.org; Wed, 11 Jul 2007 12:52:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8fQU-0006ei-JI for netconf-archive@lists.ietf.org; Wed, 11 Jul 2007 12:52:35 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8fHY-0001B7-NX for netconf-data@psg.com; Wed, 11 Jul 2007 16:43:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.198.200] (helo=smtp101.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I8fHM-00018j-Vk for netconf@ops.ietf.org; Wed, 11 Jul 2007 16:43:11 +0000 Received: (qmail 45560 invoked from network); 11 Jul 2007 16:43:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 11 Jul 2007 16:43:03 -0000 X-YMail-OSG: tHT4vj4VM1kD2pdPPdX3uGMwTR8NX1fARrLWPY.BdFlKXROpv1ZAhJGx2gJURxUcTSQxLFQoNN.IkOt1YWw6pZnEpA-- Message-ID: <46950848.4000401@andybierman.com> Date: Wed, 11 Jul 2007 09:41:44 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Li Yan CC: netconf@ops.ietf.org, Sharon Chisholm Subject: Re: Comments on notification-08 References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> In-Reply-To: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Li Yan wrote: Thanks for your comments. I also noticed that the examples do not reflect the schema, since the top-level element is missing. (This was pointed out at least twice already). Andy > Hi, > Here are my comments. I commented the snapshot of > draft-ietf-netconf-notifications yesterday. Some comments in it are > still valid. > o sec 4 > type="streamNameType" minOccurs="0"> > Does it imply that a single operation can not > subscribe multiple streams? > > o sec 5.1 says: an element at the top level that contains one > or more child elements ... > But the Figure 10 contains instead of element. > > o sec 5.1 > The label 'Figure 12' is missing. > > o sec 5.1 and sec 5.2 > There is element in the Figure 10. > > Ethernet0 > > But in the Figure 12 (its label is missing) and the Figure 14, > is changed to . > > o sec 5.2 > The Figure 14 is still wrong: > 1. The filtering criteria evaluation is not consistent with the XPATH > expression in the element. > 2. Two '(' are missing. > 3. It is hard to read due to different sequence of conditions. > The XPath filter should be: > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > xmlns:ex="http://example.com/event/1.0" > select="/ex:event[ > (ex:eventClass='state' or ex:eventClass='config') and > ((ex:eventClass='fault' and ex:severity='critical') or > (ex:eventClass='fault' and ex:severity='major') or > (ex:eventClass='fault' and ex:severity='minor') or > (ex:eventClass='fault' and > ex:reportingEntity/ex:card='Ethernet0'))]"/> > > > > > Yan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 12 14:40:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93aS-0005mm-M8 for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 14:40:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I93aO-0000OL-3r for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 14:40:24 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I93Sj-000F2m-Q5 for netconf-data@psg.com; Thu, 12 Jul 2007 18:32:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I93SV-000F1Y-DU for netconf@ops.ietf.org; Thu, 12 Jul 2007 18:32:20 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DCEB12025A for ; Thu, 12 Jul 2007 20:32:06 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-23-469673a6e680 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BBAF120167 for ; Thu, 12 Jul 2007 20:32:06 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 20:32:06 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 20:32:06 +0200 Message-ID: <469673A6.9020100@ericsson.com> Date: Thu, 12 Jul 2007 20:32:06 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Comments on notification-08 from Balazs References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> <46950848.4000401@andybierman.com> In-Reply-To: <46950848.4000401@andybierman.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 18:32:06.0273 (UTC) FILETIME=[F2F53F10:01C7C4B2] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Major comments: --------------- Chapter 3.2 para 3) Filters are mentioned in plural, should be singular Chapter 3.3.2 and 3.3.3) The two sections contradict each other!!! In 3.3.3 the draft says: after the replayComplete is received (sent?) the subscription is terminated (by the Netconf agent???). In 3.3.2 the draft indicates that notifications might be sent even after replayComplete. Chapter 3.6) Multiple filters are mentioned. It should be just one. The second paragraph should be removed as there is only one filter. Chapter 6) I would not worry much about the security of the transport for non-netconf streams; SSH is secure enough. I think the real risk is that Netconf has a different receiving application then syslog, SNMP. The Netconf manager application might be less secure then e.g. a syslog server. Minor issues: ------------ General) Labeling text examples as figures is strange for me, I would rather label them "Example" (still I am not a native English speaker). Chapter 1.3 2nd para) The netconf server will read RPC requests (otherwise the TCP buffer will fill up :-). The text in the 07-draft was better. Chapter 3.2 para 2) The text refers to figure 2 but it should refer to figure 4 General) I would still prefer just one XSD but OK, I can live with this. Also the name netmod in the URN is strange for me, but OK I accept. Chapter 3.2.5.2.1) I would include the following sentence: "Both subtree and XPATH filtering can be used. Chapter 4) Why do we need a streamNameType? It is just a string. 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 Jul 12 15:10:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I943E-0003Pi-Cx for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:10:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9439-0001JG-Qv for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:10:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I93xC-000KM5-BI for netconf-data@psg.com; Thu, 12 Jul 2007 19:03:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I93wb-000KHD-JE for netconf@ops.ietf.org; Thu, 12 Jul 2007 19:03:23 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6F2FF207B1 for ; Thu, 12 Jul 2007 21:03:15 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-b6-46967af3af30 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 52D7E201AF for ; Thu, 12 Jul 2007 21:03:15 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 21:03:15 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 21:03:14 +0200 Message-ID: <46967AF2.4080402@ericsson.com> Date: Thu, 12 Jul 2007 21:03:14 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: stopping notifications References: <200707082226.l68MQwjw049005@idle.juniper.net> In-Reply-To: <200707082226.l68MQwjw049005@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 19:03:14.0847 (UTC) FILETIME=[4CB702F0:01C7C4B7] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hello, I think the previous text from draft-07 is quite good: "A NETCONF server is not required to process RPC requests on the session associated with the subscription until the notification subscription is done and may silently discard these requests." I also remember that in Montreal we sad we don't process requests just to report errors even though this slightly violates the base RFC. Two additional aspects: 1) We should preferably not mention capabilities that are not defined properly. If we do not forbid a specific behavior a vendor might have optional capabilities implementing it, so why speak about it? 2) I completely agree with Phil that we should very explicitly define the Netconf session being in Command-Response mode or in Notification mode. Notification mode starts at create-subscription and its response. Notification mode ends at replayComplete or session termination. replayComplete MUST only be sent if a stop-time was used in the create-subscription. This is ambiguous even in the draft-08. 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 Jul 12 15:26:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94JJ-0007oB-LN for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:26:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I94JF-0002O5-9Y for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:26:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94CW-000MT2-2X for netconf-data@psg.com; Thu, 12 Jul 2007 19:19:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94CL-000MSH-A5 for netconf@ops.ietf.org; Thu, 12 Jul 2007 19:19:38 +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 l6CJJTp07711 for ; Thu, 12 Jul 2007 19:19:30 GMT 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: Comments on notification-08 from Balazs Date: Thu, 12 Jul 2007 15:19:21 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FE7FB29@zcarhxm2.corp.nortel.com> In-Reply-To: <469673A6.9020100@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on notification-08 from Balazs Thread-Index: AcfEtHEjnGro2jvDQlanDI8xgGHc1wABOYLQ References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> <46950848.4000401@andybierman.com> <469673A6.9020100@ericsson.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 =20 -----Original Message----- Minor issues: ------------ General) Labeling text examples as figures is strange for me, I would rather label them "Example" (still I am not a native English speaker). Since I can't figure out xml2rfc, the choice was either figure numbering that was non-contiguous or labelling everything. Perhaps I should have left it as non-contiguous and just added a note to the RFC editor? Sharon -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 12 15:28:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94Kv-0008Gi-Uc for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:28:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I94Kr-0002TR-EZ for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:28:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94Go-000N4t-Pv for netconf-data@psg.com; Thu, 12 Jul 2007 19:24:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94Gd-000N3f-3U for netconf@ops.ietf.org; Thu, 12 Jul 2007 19:24:05 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1B8A021048; Thu, 12 Jul 2007 21:23:57 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-57-46967fcc7182 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC0A8201AF; Thu, 12 Jul 2007 21:23:56 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 21:23:56 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 21:23:56 +0200 Message-ID: <46967FCC.8040404@ericsson.com> Date: Thu, 12 Jul 2007 21:23:56 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Comments on notification-08 from Balazs References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> <46950848.4000401@andybierman.com> <469673A6.9020100@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B40FE7FB1C@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FE7FB1C@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 19:23:56.0547 (UTC) FILETIME=[30D36530:01C7C4BA] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 That's fine, thanks Balazs Sharon Chisholm wrote: > Hi > > On filters versus filter elements. You are right about section 3.2 para > 3). That was somehow missed. But section 3.6 should only be talking > about filter elements, which is ok. > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Balazs Lengyel > Sent: Thursday, July 12, 2007 2:32 PM > To: netconf@ops.ietf.org > Subject: Comments on notification-08 from Balazs > > Major comments: > --------------- > Chapter 3.2 para 3) Filters are mentioned in plural, should be singular > > Chapter 3.3.2 and 3.3.3) The two sections contradict each other!!! > In 3.3.3 the draft says: after the replayComplete is received (sent?) > the subscription is terminated (by the Netconf agent???). In 3.3.2 the > draft indicates that notifications might be sent even after > replayComplete. > > Chapter 3.6) Multiple filters are mentioned. It should be just one. The > second paragraph should be removed as there is only one filter. > > Chapter 6) I would not worry much about the security of the transport > for non-netconf streams; SSH is secure enough. I think the real risk is > that Netconf has a different receiving application then syslog, SNMP. > The Netconf manager application might be less secure then e.g. a syslog > server. > > > Minor issues: > ------------ > General) Labeling text examples as figures is strange for me, I would > rather label them "Example" (still I am not a native English speaker). > > Chapter 1.3 2nd para) The netconf server will read RPC requests > (otherwise the TCP buffer will fill up :-). The text in the 07-draft was > better. > > Chapter 3.2 para 2) The text refers to figure 2 but it should refer to > figure 4 > > General) I would still prefer just one XSD but OK, I can live with this. > Also the name netmod in the URN is strange for me, but OK I accept. > > Chapter 3.2.5.2.1) I would include the following sentence: "Both subtree > and XPATH filtering can be used. > > Chapter 4) Why do we need a streamNameType? It is just a string. > > 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: > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 12 15:29:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94FL-0006qG-8v for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:22:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I94Eu-00027a-Ic for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 15:22:39 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94Ai-000MHM-Gg for netconf-data@psg.com; Thu, 12 Jul 2007 19:17:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94AX-000MGf-5i for netconf@ops.ietf.org; Thu, 12 Jul 2007 19:17:46 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6CJHbU22834 for ; Thu, 12 Jul 2007 19:17:37 GMT 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: Comments on notification-08 from Balazs Date: Thu, 12 Jul 2007 15:17:36 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40FE7FB1C@zcarhxm2.corp.nortel.com> In-Reply-To: <469673A6.9020100@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on notification-08 from Balazs Thread-Index: AcfEtHEjnGro2jvDQlanDI8xgGHc1wABLG3Q References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> <46950848.4000401@andybierman.com> <469673A6.9020100@ericsson.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi On filters versus filter elements. You are right about section 3.2 para 3). That was somehow missed. But section 3.6 should only be talking about filter elements, which is ok. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel Sent: Thursday, July 12, 2007 2:32 PM To: netconf@ops.ietf.org Subject: Comments on notification-08 from Balazs Major comments: --------------- Chapter 3.2 para 3) Filters are mentioned in plural, should be singular Chapter 3.3.2 and 3.3.3) The two sections contradict each other!!! In 3.3.3 the draft says: after the replayComplete is received (sent?) the subscription is terminated (by the Netconf agent???). In 3.3.2 the draft indicates that notifications might be sent even after replayComplete. Chapter 3.6) Multiple filters are mentioned. It should be just one. The second paragraph should be removed as there is only one filter. Chapter 6) I would not worry much about the security of the transport for non-netconf streams; SSH is secure enough. I think the real risk is that Netconf has a different receiving application then syslog, SNMP. The Netconf manager application might be less secure then e.g. a syslog server. Minor issues: ------------ General) Labeling text examples as figures is strange for me, I would rather label them "Example" (still I am not a native English speaker). Chapter 1.3 2nd para) The netconf server will read RPC requests (otherwise the TCP buffer will fill up :-). The text in the 07-draft was better. Chapter 3.2 para 2) The text refers to figure 2 but it should refer to figure 4 General) I would still prefer just one XSD but OK, I can live with this. Also the name netmod in the URN is strange for me, but OK I accept. Chapter 3.2.5.2.1) I would include the following sentence: "Both subtree and XPATH filtering can be used. Chapter 4) Why do we need a streamNameType? It is just a string. 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: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 12 16:15:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I954t-0006bE-6K for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 16:15:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I954p-0003zo-PS for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 16:15:55 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94zj-000393-JR for netconf-data@psg.com; Thu, 12 Jul 2007 20:10:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.206] (helo=smtp107.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I94zY-00034Q-3W for netconf@ops.ietf.org; Thu, 12 Jul 2007 20:10:30 +0000 Received: (qmail 98730 invoked from network); 12 Jul 2007 20:10:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 12 Jul 2007 20:10:23 -0000 X-YMail-OSG: zSHvJUUVM1lbrQQuFFGkbJZdbCbQWaIzj5ETZLSXDmPn.uKL Message-ID: <46968A5F.2000601@andybierman.com> Date: Thu, 12 Jul 2007 13:09:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: access control on the data model 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.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hi, Sec. 3.2.5.1 says The returned list must only include the names of those event streams for which the NETCONF session has sufficient privileges. Yet, sec. 2.1 (on create-subscription) does not mention access control at all. It does not even mention that the RPC can fail due to access control. This requirement for puts an unreasonable burden on agent implementations to maintain special access control mechanisms for this data model. Normally, the agent only has to check if the manager has read access to the requested nodes. This text would require special code to hook into the notification subscription code to enforce this rule. It is not even clear that access control "by stream" even makes any sense. Access control by namespace and element name within the data stream makes sense. What if the same data can appear in multiple streams? It is also more robust to simply exclude restricted data from the particular subscription, rather than reject the entire subscription, because the manager has access to most (but not all) of the possible data that could be generated in a stream. This is how access control works in SNMP. If you to a getnext or getbulk, it skips restricted data, rather than rejecting the PDU with an error. IMO, the restriction in 3.2.5.1 should be removed. The only real requirement is that a session must have sufficient access rights to receive the data, or it is not delivered. 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 Jul 12 16:56:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95iT-0000Cd-O4 for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 16:56:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I95iP-00069Z-97 for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 16:56:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I95bh-0007iO-PV for netconf-data@psg.com; Thu, 12 Jul 2007 20:49:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I95bW-0007gb-RB for netconf@ops.ietf.org; Thu, 12 Jul 2007 20:49:44 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=t27mHOAqrmYJqW9rl2clBRxdce+LrIh/EkW3fzj9QzdTVF/ZdhyMKjNHeypDu1tx; 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 [64.105.136.199] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I95bU-0003ig-1q for netconf@ops.ietf.org; Thu, 12 Jul 2007 16:49:36 -0400 Message-ID: <001a01c7c4c6$44e3d8a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf \(E-mail\)" References: <46968A5F.2000601@andybierman.com> Subject: Re: access control on the data model Date: Thu, 12 Jul 2007 13:50:23 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935656cbe6518a759b29dbe362964fd04456350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.199 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi - > From: "Andy Bierman" > To: "Netconf (E-mail)" > Sent: Thursday, July 12, 2007 1:09 PM > Subject: access control on the data model ... > It is not even clear that access control "by stream" even > makes any sense. Access control by namespace and element name > within the data stream makes sense. What if the same data > can appear in multiple streams? It is also more robust > to simply exclude restricted data from the particular subscription, > rather than reject the entire subscription, because the manager > has access to most (but not all) of the possible data that > could be generated in a stream. This is how access control > works in SNMP. If you to a getnext or getbulk, it skips restricted data, > rather than rejecting the PDU with an error. .... But, FWIW, that's not how access control for notifications works in SNMP. RFC 3413 3.3 (2) Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 12 17:31:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I96Fc-0004oc-50 for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 17:31:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I96FY-0006tX-P4 for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 17:31:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I96AG-000C0t-I9 for netconf-data@psg.com; Thu, 12 Jul 2007 21:25:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [216.148.227.153] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I96A5-000Bvj-Ij for netconf@ops.ietf.org; Thu, 12 Jul 2007 21:25:27 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070712212520m130020ippe>; Thu, 12 Jul 2007 21:25:20 +0000 From: "David B Harrington" To: "'Sharon Chisholm'" , "'Netconf \(E-mail\)'" References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> <46950848.4000401@andybierman.com> <469673A6.9020100@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B40FE7FB29@zcarhxm2.corp.nortel.com> Subject: RE: Comments on notification-08 from Balazs Date: Thu, 12 Jul 2007 17:25:12 -0400 Message-ID: <034301c7c4cb$2414b310$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 Thread-Index: AcfEtHEjnGro2jvDQlanDI8xgGHc1wABOYLQAAMQwCA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40FE7FB29@zcarhxm2.corp.nortel.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi Sharon, I tried to send you some suggestions last week, especially one about asking Elwyn, who is quite proficient at xml2rfc. Your address keeps getting filtered out by filtops@nortel. I think you are missing mailings from bofchairs@ietf.org. Your filtops dept advises people who get their notice of email having been filtered to send them email to alert them if you believe the email should not be filtered, but they filter out the responses to themselves as well. Sigh. I think in the latest xml2rfc you can specify a counter name attribute for numbered sequences, like figures. I believe this is undocumented. So I recommend trying
for each of your figures (using the same variable for all figures). That might solve the numbering problem. I have not tested this. There is an xml2rfc mailing list (xml2rfc-request@lists.xml.resource.org), which is the best place to get questions answered. dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, July 12, 2007 3:19 PM > To: netconf@ops.ietf.org > Subject: RE: Comments on notification-08 from Balazs > > > > -----Original Message----- > > > > Minor issues: > ------------ > General) Labeling text examples as figures is strange for me, I would > rather label them "Example" (still I am not a native English > speaker). > > > > Since I can't figure out xml2rfc, the choice was either > figure numbering > that was non-contiguous or labelling everything. Perhaps I should have > left it as non-contiguous and just added a note to the RFC editor? > > Sharon > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 12 17:34:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I96IS-0005xv-O8 for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 17:34:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I96IO-0006yK-8y for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 17:34:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I96ES-000CSr-SY for netconf-data@psg.com; Thu, 12 Jul 2007 21:29:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.203] (helo=smtp104.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I96EH-000CRl-Nk for netconf@ops.ietf.org; Thu, 12 Jul 2007 21:29:47 +0000 Received: (qmail 95520 invoked from network); 12 Jul 2007 21:29:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 12 Jul 2007 21:29:40 -0000 X-YMail-OSG: wFVnb9IVM1m0sESVPR.Euy45bXzXsZGrQhk3TZyw4TN_wSIGPEAoi3pVCGB3P8odw_8Xr.Tx2GZL5qCRgSq6OKYyWA-- Message-ID: <46969CF4.3050300@andybierman.com> Date: Thu, 12 Jul 2007 14:28:20 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Randy Presuhn CC: "Netconf (E-mail)" Subject: Re: access control on the data model References: <46968A5F.2000601@andybierman.com> <001a01c7c4c6$44e3d8a0$6601a8c0@oemcomputer> In-Reply-To: <001a01c7c4c6$44e3d8a0$6601a8c0@oemcomputer> 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.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Netconf (E-mail)" >> Sent: Thursday, July 12, 2007 1:09 PM >> Subject: access control on the data model > ... >> It is not even clear that access control "by stream" even >> makes any sense. Access control by namespace and element name >> within the data stream makes sense. What if the same data >> can appear in multiple streams? It is also more robust >> to simply exclude restricted data from the particular subscription, >> rather than reject the entire subscription, because the manager >> has access to most (but not all) of the possible data that >> could be generated in a stream. This is how access control >> works in SNMP. If you to a getnext or getbulk, it skips restricted data, >> rather than rejecting the PDU with an error. > .... > > But, FWIW, that's not how access control for notifications works in SNMP. > RFC 3413 3.3 (2) Do you mean para 2: Notification originator applications require a mechanism for identifying the management targets to which notifications should be sent. The particular mechanism used is implementation dependent. However, if an implementation makes the configuration of management targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module described in this document. I think you mean para 4, point 2: (2) The appropriate set of variable-bindings is retrieved from local MIB instrumentation within the relevant MIB view. The relevant MIB view is determined by the securityLevel, securityModel, contextName, and securityName of the management target. To determine whether a particular object instance is within the relevant MIB view, the isAccessAllowed abstract service interface is used, in the same manner as described in the preceding section, except that the viewType indicates a Notification-Class operation. If the statusInformation returned by isAccessAllowed does not indicate accessAllowed, the notification is not sent to the management target. The difference seems to be that (on a PER-NOTIFICATION basis) the entire PDU is dropped if any data within it is restricted. This is fine -- easier on the agent than pruning the restricted data and sending the rest. But this is much different than refusing to let the manager see the name of the stream or rejecting the because individual notifications may not be delivered. > > Randy Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 12 21:03:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99ZI-00062f-61 for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 21:03:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I99ZE-0003FN-OH for netconf-archive@lists.ietf.org; Thu, 12 Jul 2007 21:03:36 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I99NN-000DSR-8e for netconf-data@psg.com; Fri, 13 Jul 2007 00:51:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I99NC-000DS0-2g for netconf@ops.ietf.org; Fri, 13 Jul 2007 00:51:11 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=X7yL8jE3NK9+7gLNd7cx9tSFAN+Sor+XBVZaCKTydQJs6HNIjx5ucHOGNjPF4U88; 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 [66.167.204.155] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I99NB-0002EO-CB for netconf@ops.ietf.org; Thu, 12 Jul 2007 20:51:05 -0400 Message-ID: <001401c7c4e8$00fbb0a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf \(E-mail\)" References: <46968A5F.2000601@andybierman.com> <001a01c7c4c6$44e3d8a0$6601a8c0@oemcomputer> <46969CF4.3050300@andybierman.com> Subject: Re: access control on the data model Date: Thu, 12 Jul 2007 17:51:52 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356c054b2c12340bcf8431304790490974b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.155 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: "Netconf (E-mail)" > Sent: Thursday, July 12, 2007 2:28 PM > Subject: Re: access control on the data model ... > > But, FWIW, that's not how access control for notifications works in SNMP. > > RFC 3413 3.3 (2) ... > I think you mean para 4, point 2: yes ... > The difference seems to be that (on a PER-NOTIFICATION basis) > the entire PDU is dropped if any data within it is restricted. > This is fine -- easier on the agent than pruning the restricted data > and sending the rest. yes, particularly in the case of SNMP where the NOTIFICATION-TYPE may specify mandatory variable bindings, but other stuff may be included by an implementation. > But this is much different than refusing to let the manager see > the name of the stream or rejecting the > because individual notifications may not be delivered. Since it's reasonable for permissions to change over time, I think it makes no sense to block creation of a subscription based on whether the notifications that could be generated in the future might be blocked at the moment. Particularly in the case of creating a subscription with respect to things that might not exist at the moment. But that having that kind of flexibility might be an SNMP-centric view of the world. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 01:01:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9DHs-0007Wh-Go for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 01:01:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9DHn-0001Mb-Ax for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 01:01:52 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9DA9-000E43-T9 for netconf-data@psg.com; Fri, 13 Jul 2007 04:53:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [69.147.64.89] (helo=smtp116.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9D9y-000E3Q-Kd for netconf@ops.ietf.org; Fri, 13 Jul 2007 04:53:48 +0000 Received: (qmail 91733 invoked from network); 13 Jul 2007 04:53:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 13 Jul 2007 04:53:42 -0000 X-YMail-OSG: ae5gN5QVM1nHxqp.9xgOYiq4gI4qBZxTUfPfJDH5BpAcSX4HJIqOx23BA7q4bx1xAUjCLb_hiGBWB22_V7Zm0_wl Message-ID: <46970506.5060806@andybierman.com> Date: Thu, 12 Jul 2007 21:52:22 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Randy Presuhn CC: "Netconf (E-mail)" Subject: Re: access control on the data model References: <46968A5F.2000601@andybierman.com> <001a01c7c4c6$44e3d8a0$6601a8c0@oemcomputer> <46969CF4.3050300@andybierman.com> <001401c7c4e8$00fbb0a0$6601a8c0@oemcomputer> In-Reply-To: <001401c7c4e8$00fbb0a0$6601a8c0@oemcomputer> 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.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: "Netconf (E-mail)" >> Sent: Thursday, July 12, 2007 2:28 PM >> Subject: Re: access control on the data model > > > ... >>> But, FWIW, that's not how access control for notifications works in SNMP. >>> RFC 3413 3.3 (2) > ... >> I think you mean para 4, point 2: > > yes > > ... >> The difference seems to be that (on a PER-NOTIFICATION basis) >> the entire PDU is dropped if any data within it is restricted. >> This is fine -- easier on the agent than pruning the restricted data >> and sending the rest. > > yes, particularly in the case of SNMP where the NOTIFICATION-TYPE > may specify mandatory variable bindings, but other stuff may be > included by an implementation. > >> But this is much different than refusing to let the manager see >> the name of the stream or rejecting the >> because individual notifications may not be delivered. > > Since it's reasonable for permissions to change over time, > I think it makes no sense to block creation of a subscription > based on whether the notifications that could be generated > in the future might be blocked at the moment. Particularly in > the case of creating a subscription with respect to things > that might not exist at the moment. But that having that kind > of flexibility might be an SNMP-centric view of the world. > not SNMP-centric. NM-centric. Common sense network management. Perhaps if there was an actual security model for NETCONF, it might be more clear that per-notification access control (send or drop decision per PDU) is all that is needed here. > Randy Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 04:47:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9GoT-0007tC-0T for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 04:47:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9GoO-0007ZQ-6v for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 04:47:44 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Ghn-000FoB-Ag for netconf-data@psg.com; Fri, 13 Jul 2007 08:40:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Ghb-000Fkx-4h for netconf@ops.ietf.org; Fri, 13 Jul 2007 08:40:45 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 01A02200C6; Fri, 13 Jul 2007 10:40:37 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-94-46973a845c54 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A769F21849; Fri, 13 Jul 2007 10:40:36 +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, 13 Jul 2007 10:40:36 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 10:40:36 +0200 Message-ID: <46973A83.6030701@ericsson.com> Date: Fri, 13 Jul 2007 10:40:35 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: access control on the data model References: <46968A5F.2000601@andybierman.com> In-Reply-To: <46968A5F.2000601@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 08:40:36.0113 (UTC) FILETIME=[7B965810:01C7C529] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hello Andy, Your proposal that access control should be on individual notification level instead of stream level is sensible. But 1) As we do not yet define access control, I would like to avoid having SHALL or MUST statements rather use MAY or SHOULD. At this point access control can reject anything. 2) I see a (not very strong) use case for stream level access control. - separate stream for security data, only available to security administrators - nodes administered by multiple administrators with separate streams While this all can be solved by a notification level access control I still assume that access control might work on stream level. I propose to change 3.2.5.1: "The Netconf server MIGHT/SHOULD omit streams from the list, if the NETCONF session does not have sufficient access control privileges to subscribe to a stream." In chapter 2.2 we should include: "Even if a subscription succeeds individual notifications are still subject to access control. If any data in a notification is restricted by access control from being delivered to the NETCONF session the sending of the whole notification SHALL/MAY be stopped." Balazs Andy Bierman wrote: > Hi, > > Sec. 3.2.5.1 says > > The returned list must only include the names of > those event streams for which the NETCONF session has sufficient > privileges. > > Yet, sec. 2.1 (on create-subscription) does not mention access > control at all. It does not even mention that the RPC can fail > due to access control. > > This requirement for puts an unreasonable burden > on agent implementations to maintain special access control > mechanisms for this data model. Normally, the agent only > has to check if the manager has read access to the requested > nodes. This text would require special code to hook into > the notification subscription code to enforce this rule. > > It is not even clear that access control "by stream" even > makes any sense. Access control by namespace and element name > within the data stream makes sense. What if the same data > can appear in multiple streams? It is also more robust > to simply exclude restricted data from the particular subscription, > rather than reject the entire subscription, because the manager > has access to most (but not all) of the possible data that > could be generated in a stream. This is how access control > works in SNMP. If you to a getnext or getbulk, it skips restricted data, > rather than rejecting the PDU with an error. > > IMO, the restriction in 3.2.5.1 should be removed. > The only real requirement is that a session must have sufficient > access rights to receive the data, or it is not delivered. > > Andy > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 04:58:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9GyR-00020c-IU for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 04:58:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9GyM-0007pS-S0 for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 04:58:03 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9GuF-000HEA-HG for netconf-data@psg.com; Fri, 13 Jul 2007 08:53:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Gu4-000HD0-4Q for netconf@ops.ietf.org; Fri, 13 Jul 2007 08:53:38 +0000 Received: from localhost (h14n1c1o851.bredband.skanova.com [81.225.32.14]) by mail.tail-f.com (Postfix) with ESMTP id 33CBB1B80C3; Fri, 13 Jul 2007 10:53:29 +0200 (CEST) Date: Fri, 13 Jul 2007 10:53:27 +0200 (CEST) Message-Id: <20070713.105327.98854475.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: access control on the data model From: Martin Bjorklund In-Reply-To: <46968A5F.2000601@andybierman.com> References: <46968A5F.2000601@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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 Andy Bierman wrote: > Hi, > > Sec. 3.2.5.1 says > > The returned list must only include the names of > those event streams for which the NETCONF session has sufficient > privileges. > > Yet, sec. 2.1 (on create-subscription) does not mention access > control at all. It does not even mention that the RPC can fail > due to access control. > > This requirement for puts an unreasonable burden > on agent implementations to maintain special access control > mechanisms for this data model. Normally, the agent only > has to check if the manager has read access to the requested > nodes. This text would require special code to hook into > the notification subscription code to enforce this rule. > > It is not even clear that access control "by stream" even > makes any sense. Access control by namespace and element name > within the data stream makes sense. What if the same data > can appear in multiple streams? It is also more robust > to simply exclude restricted data from the particular subscription, > rather than reject the entire subscription, because the manager > has access to most (but not all) of the possible data that > could be generated in a stream. This is how access control > works in SNMP. If you to a getnext or getbulk, it skips restricted data, > rather than rejecting the PDU with an error. > > IMO, the restriction in 3.2.5.1 should be removed. > The only real requirement is that a session must have sufficient > access rights to receive the data, or it is not delivered. I fully agree with Andy. (Incidentally, this is how I have currently implemented the eventStreams datamodel...) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 05:07:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9H77-0006pn-Q6 for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:07:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9H73-00083M-F7 for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:07:01 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9H1S-000K5D-7i for netconf-data@psg.com; Fri, 13 Jul 2007 09:01:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9H1H-000K4F-DI for netconf@ops.ietf.org; Fri, 13 Jul 2007 09:01:04 +0000 Received: from localhost (h14n1c1o851.bredband.skanova.com [81.225.32.14]) by mail.tail-f.com (Postfix) with ESMTP id 3EF2F1B80C3; Fri, 13 Jul 2007 11:00:58 +0200 (CEST) Date: Fri, 13 Jul 2007 11:00:57 +0200 (CEST) Message-Id: <20070713.110057.230492088.mbj@tail-f.com> To: liyan_77@huawei.com Cc: netconf@ops.ietf.org, schishol@nortel.com Subject: Re: Comments on notification-08 From: Martin Bjorklund In-Reply-To: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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 Li Yan wrote: > o sec 5.2 > The Figure 14 is still wrong: > 1. The filtering criteria evaluation is not consistent with the > XPATH expression in the element. You're right. But I think the filtering criteria evaluation is wrong, and the XPath correct. The filtering criteria says: (( state | config ) & ( fault & (...))) This can never evaluate to true, since is says that the eventClass must be 'state' or 'config' AND eventClass must be 'fault'. It should be ( state | config | ( fault & (...))) > 2. Two '(' are missing. > 3. It is hard to read due to different sequence of conditions. Agreed. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 05:11:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HB0-0008IO-SV for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:11:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9HAv-00087Q-PF for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:11:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9H6E-000LWw-O4 for netconf-data@psg.com; Fri, 13 Jul 2007 09:06:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9H61-000LVa-QG for netconf@ops.ietf.org; Fri, 13 Jul 2007 09:06:00 +0000 Received: (qmail 54752 invoked from network); 13 Jul 2007 09:05:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 13 Jul 2007 09:05:52 -0000 X-YMail-OSG: 3RyHCsQVM1n0ARJ_HlukWXOs3Sb5Wl6MOc4f4uc6sOw_t6XTM7bwspEmG1QzgTAFhqkpeShYpr63E8CDXDW9Oshn Message-ID: <46974021.1060608@andybierman.com> Date: Fri, 13 Jul 2007 02:04:33 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: notification-08 comments 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.0 (/) X-Scan-Signature: 52b2f07c128fbe337bbf87ebd50cfd46 Hi, I am leaving out bugs already identified in other comments... [I am getting as picky as I know the IESG will be when they review it.] ----------------------------------------------- 1.1 Terms: Operation: This term is used to refer to NETCONF protocol operations [NETCONF]. Specifically within this document, operation refers to NETCONF protocol operations defined in support of NETCONF notifications. 5.1, para 1: XML subtree filtering is not well suited for creating elaborate filter definitions given that it only supports equality comparisons and logical OR operations (e.g., in an event subtree give me all ^^^^^^^^^^ 6, para 4: It is recommended that care be taken to ensure the secure operation of the following commands: ^^^^^^^^^ The second sentence in the operation is not true, since it is used differently in sec. 5.1 and 6. ------------------------------------------------- 1.3, para 2: A NETCONF server is will not read ^^ extra word ------------------------------------------------- 1.4, bullet 1: o Initial release should ensure it supports notification in support of configuration operations Reword to something less mangled, but I'm not even sure what this means. perhaps remove, since the contents of a stream are internal to the agent implementation. --------------------------------------------------- 1.4, bullet 2: o Data content must not preclude the use of the same data model as used in configuration I have no idea what this means, please elaborate. -------------------------------------------------- 1.4, bullet 3: o Solution should support a reasonable message size limit (ie, not too short) NETCONF has no message size limits (except the message-id attribute), so I'm not sure why this needs to be here. There are no size limits in this document either. s/ie,/i.e.,/ (BTW) ---------------------------------------------------- 1.4, all bullets: Add period and make all bullets complete sentences. --------------------------------------------------- 2.1: This section should clearly state that a subscription is bound to a single stream for the lifetime of the subscription. ---------------------------------------------------- 2.1.1, Negative Response: If a stopTime is specified in a request without having specified a startTime the following error is returned: Previously, 'startTime' and 'stopTime' were single-quoted. Be consistent throughout the draft one way or the other. ---------------------------------------------------- 2.1.1, Negative Response: In each sub-section, clearly state which child element in the element is associated with the parameter. ---------------------------------------------------- 2.1.1, Negative Response: Error-info: : startTime ^^^^^^^^^^^^ Change to ----------------------------------------------------- 2.1.1.1: This section needs some explanatory text, and filled in with most or all of the parameters. Also the 2nd namespace URI is wrong (already mentioned in a previous email). ----------------------------------------------------- 2.2.1, para 1: An event notification is sent to the client who initiated a command asynchronously when an event of interest (i.e., meeting the specified filtering criteria) to them ^^^^^^^ has occurred. Remove extra text. ------------------------------------------------------ 2.2.1, para 2: Contains notification-specific tagged content. The content of the data tag is beyond the scope of this document. This section (on parameters) is insufficient. This document needs to clearly explain how the child node of the node is defined, similar to RFC 4741, sec 4.1. ------------------------------------------------------- 3.2: Much improved text and diagram, but needs a little more text. It should be clear that the 'central event processor' generates events and transfers them to the correct stream(s) in an inaccessible, internal format. Suggest: At some point after the 'netconf server' receives the internal event from a stream, it is converted to XML encoding by the agent, and a element is ready to send to all NETCONF sessions subscribed to that stream. After generation of the element, access control is applied by the agent. If a session does not have permission to receive the , then it is discarded for that session, and processing of the internal event is completed for that session. If the session has permission to receive the element, then the filter associated with its subscription is applied (if any), except if this is a notification. ------------------------------------------------------- 3.2, para 3: When a NETCONF client subscribes to a given event stream, user- defined filters, if applicable, are applied to the event stream and matching event notifications are forwarded to the NETCONF server for distribution to subscribed NETCONF clients. For more information on filters, see section 3.6. The end of the first sentence, especially 'forwarded to the NETCONF server', is confusing. It sounds like the 'forwarder' is the client, not the central event processor. This para should state somehow: Filters are transferred from the client to the agent during the operation and applied against each element generated by the stream. ---------------------------------------------------------- 3.2.1, para 1: may allow event stream configuration via NETCONF protocol (i.e., s/via NETCONF/via the NETCONF/ ----------------------------------------------------------- 3.2.1, para 1: established by the vendor (pre-configured) or user configurable ^ missing comma (e.g., part of the device's configuration) or both. ^ missing comma Add missing commas. ------------------------------------------------------------- 3.2.2: The contents of all event streams made available to a NETCONF client (i.e., the notification sent by the NETCONF server) must be encoded in XML. This is a round-about way to state the obvious -- the contents of the element must be encoded in XML. -------------------------------------------------------------- 3.2.3: A NETCONF server implementation supporting the notification capability must support the "NETCONF" notification event stream. Clearly state that the exact string "NETCONF" must match the contents of the element in the RPC. Also, an element will be present in the agent, with a value that matches this string. --------------------------------------------------------------- 3.2.4: (e.g., SNMP, syslog, etc.) is outside the scope of this document. ^^^^^^ Remove redundant text (use e.g., or etc, but never both). --------------------------------------------------------------- 3.2.5: NETCONF server using the RPC request. ^^^^^^^^^^^ Use 'operation' instead to be consistent. ---------------------------------------------------------------- 3.2.5.1: This section should list each child element of the element and explain its purpose and implementation requirements, instead of burying these important details in the XSD. ------------------------------------------------------------------ 3.2.5.1: Element naming is inconsistent. Plural form is and single form is . Suggest changing to . ------------------------------------------------------------------ 3.2.5.1, para 1: The returned list must only include the names of those event streams for which the NETCONF session has sufficient privileges. The NETCONF session privileges are determined via access control mechanisms which are beyond the scope of this document. An empty reply is returned if there are no available event streams. This portion of the paragraph should be removed. Access control should only be conceptually inserted after generation by the 'netconf server', and before any filters are applied. ------------------------------------------------------------------ Figure 5: Remove extra line before The element is missing. The 'xmlns' should be in that element instead. ---------------------------------------------------------------------- Figure 6: The element is also missing from the . ----------------------------------------------------------------- 3.2.5.2.1, para 1: The set of event notifications delivered in an event stream may be further refined by applying a user-specified filter at subscription creation time s/filter at/filter supplied at/ ------------------------------------------------------------------ 3.3.1, para 2: A replay of notifications is specified by including an optional parameter to the subscription command that indicates the start time of the replay. The end time is specified using the optional stopTime parameter. If not present, notifications will continue to be sent until the subscription is terminated. Use single quotes for 'startTime' and 'stopTime'. ------------------------------------------------------------------- 3.3.1, para 4: Control parameters for this aspect of the feature are outside the scope of the current document. ^^^^^^^ s/current/this/ -------------------------------------------------------------------- 3.3.1, para 5: This schema also provides the replayLogStartTime element to indicate the earliest available logged notification. Add < > to replayLogStartTime. This sentence shows why the parameter needs to be clearly defined in sec 3.2.5.1. Is this parameter the time the agent started collecting or the time the first notification was added, sometime after the agent started collecting? The spec must be clear on which one. (IMO, the former is the intuitive choice.) -------------------------------------------------------------------- 3.3.2, para 2: Note that startTime and stopTime are associated with the time an event was generated by the system. Add single quotes to 'startTime' and 'stopTime'. The phrase 'by the system' is vague. Which component in fig. 4 is the system? ---------------------------------------------------------------------- 3.3.2, para 3: A replayComplete notification is sent to indicate that all of the replay notifications have been sent. Use 'replayComplete' or . becomes a normal NETCONF session again. Indicate that the agent will now accept operations. Any requests which have been received but not processed by the agent will now be processed in the order they were received. creation will be sent followed by notifications as they arise ^ missing comma ----------------------------------------------------------------------- 3.3.3, para 1: The replayComplete notification is the last notification sent over a replay subscription. Single quote or element form of replayComplete Sentence is confusing, since more notifications can be sent after . You mean this special notification is sent after all replayed notifications have been sent. ------------------------------------------------------------------------ 3.3.3, para 2: The replayComplete can not be filtered out. It will always be sent on a relay subscription that specified a stop time. s/can not/cannot/ s/relay/replay/ ------------------------------------------------------------------------- 3.4, para 1: This Schema is used to learn about the event streams supported on the s/Schema/schema/ It also contains the definition of the replayComplete s/replayComplete/ element/ which is sent to indicate that an event replay has sent all applicable notifications." Suggest removing or make the terminology consistent. ------------------------------------------------------------------------ 3.4: XSD: much improved. Need to update some namespace URIs (use xml:ns form, not netconf:capability form). Should also add comment above the 2nd that the "http://www.iana.org/assignments/xml-registry/schema/notification.xsd" value is a placeholder and the actual value will be assigned by IANA. ------------------------------------------------------------------------- 3.5: While it may be possible to retrieve information about subscriptions via a get operation, subscriptions are not stored configuration. They are non-persistent state information and their lifetime is defined by their session. This whole section is confusing, since there is no schema in the document related to this section. This document should only focus on the standard, and the standard has no mechanism to retrieve this information. Suggest removing this section. ----------------------------------------------------------------- 3.6, para 1: When multiple filter elements are specified, they are applied collectively, so event notifications need to pass all specified filters in order to be sent to the subscriber. Need to remove this sentence. There is at most one conceptual element associated with a subscription. If a filter element is specified to look for data of a particular value, and the data item is not present within a particular event notification for its value to be checked against, the notification will be filtered out. This is not precise enough. For starters, subtree and Xpath filters return a subset of conceptual 'input node set', not a boolean expression. The output node set is returned in the or response. What does it mean to convert this mechanism to a boolean filter? Does it mean that any output at all from the filter means it 'passes', and an empty output node set means the filter 'failed'? ---------------------------------------------------------------- 3.6, para 2: The order that filter elements are applied does not matter since the resulting set of notifications is the intersection of the set of notifications that pass each filtering criteria. This sentence is confusing and should be removed. This document has no business discussing how filters defined in RFC 4741 are implemented within an agent. Also, there is only one conceptual filter per subscription. ------------------------------------------------------------------ 3.6.1: Filters only exist as parameters to the subscription. Remove or change to indicate there is only one filter element. ------------------------------------------------------------------ figure 8: This figure (or another one) should support the replay mode, and show the replayComplete notification, followed by another / sequence. This section should show the conceptual 'normal mode' and 'notification mode' transitions as well. ------------------------------------------------------------------- 3.7, para 1: stopTime in a replay subscription s/stopTime/'stopTime'/ --------------------------------------------------------------- 4.: targetNamespace URI form should be 'ns' not 'capability'. --------------------------------------------------------------- 4.: An optional parameter that indicates which subset of all possible events are of interest. The format of this parameter is the same as that of the filter parameter in the NETCONF protocol operations. If not present, all events not precluded by other parameters will be sent. See comment above on 3.6, para 1. The precise nature of notification filtering must not contradict, and should not duplicate, sec. 3.6. This definition of a filter output is not at all how filtering works for the and operations. The WG agreed at the start we are not creating a new type of filtering, just reusing the existing filtering. ---------------------------------------------------------------- 4. (and 3.4).: This XSD assigns the default namespace to the target namespace: xmlns="urn:ietf:params:netconf:capability:notification:1.0" However, the XSD in 3.4 does not use a default namespace at all: xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification" It uses the prefix 'manageEvent' instead. IMO, the XSD in sec. 3.4 should be changed to match sec 4. XSD is hard enough to read as it is without electing to make it even more verbose. It is also customary to use short prefixes (like 2 or 3 chars max). ------------------------------------------------------------------ 4. (and 3.4).: There are two missing attributes in this element in both schemas: xml:lang="en" version="1.0" ------------------------------------------------------------------ 4.: Only the 'replayLogStartTime' element has a node. All the elements in this sequence should have them. ------------------------------------------------------------------- 5. IMO, this section needs to be moved to Appendix A, and not be included in the normative part of the document. Also, the description of the assumed data model needs to be moved from 5.1 to this section, since it is used in 5.2 as well. This data model should probably have an XSD as well. --------------------------------------------------------------------- 5.1: para 2: (e.g., fault, state, config, etc.) s/config, etc.)/config) elements consisting of the event class (e.g., fault, s/// -------------------------------------------------------------------- 5.2, para 1: Should mention that the same notification data model as 5.1 is assumed. ---------------------------------------------------------------------- 6., para 2: The access control framework and the choice of transport will have a major impact on the security of the solution. What impact would that be exactly? ------------------------------------------------------------------------ 6., para 4: It is recommended that care be taken to ensure the secure operation of the following commands: o invocation o read-only data models o read-write data models o notification content Bullets 2 - 4 are not commands. NETCONF has operations, not commands, BTW. ------------------------------------------------------------------------ 6., para 5: One issue related to the notifications draft is the transport of data from non-netconf streams, s/One issue related to the notifications draft is/One issue is/ s/non-netconf/non-NETCONF/ over netconf than when being transported using the protocol normally s/netconf/NETCONF/ The NETCONF server is responsible for providing access control to stream content. s/providing/applying/ ------------------------------------------------------------------------- 6., para 6: If a user does not have permission to view content via other NETCONF operations it does not have permission to access that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. The first sentence is way out of scope and needs to be removed. The access model in use is not defined in this document. That model may not couple the configuration in this manner. --------------------------------------------------------- 7.: There are 3 registrations, not 2. 1) Capability for notification support, used in URI: urn:ietf:params:netconf:capability:notification:1.0 2) Namespace URI for the XSD in 3.4: "urn:ietf:params:xml:ns:netmod:notification" 3) Namespace URI for the XSD in 4.: "urn:ietf:params:xml:ns:netconf:notification" The 'targetNamespace' value currently in use in 4. is wrong: "urn:ietf:params:netconf:capability:notification:1.0" ------------------------------------------------------------ -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 05:30:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HUB-0000gC-7E for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:30:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9HU6-0008Ti-T2 for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:30:51 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9HPU-000ORi-U7 for netconf-data@psg.com; Fri, 13 Jul 2007 09:26:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9HPG-000OQN-8h for netconf@ops.ietf.org; Fri, 13 Jul 2007 09:25:55 +0000 Received: from localhost (h14n1c1o851.bredband.skanova.com [81.225.32.14]) by mail.tail-f.com (Postfix) with ESMTP id 080701B80C3; Fri, 13 Jul 2007 11:25:44 +0200 (CEST) Date: Fri, 13 Jul 2007 11:25:39 +0200 (CEST) Message-Id: <20070713.112539.182485561.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netconf@ops.ietf.org Subject: Re: Comments on notification-08 from Balazs From: Martin Bjorklund In-Reply-To: <469673A6.9020100@ericsson.com> References: <003e01c7c33b$7368c000$3615c00a@china.huawei.com> <46950848.4000401@andybierman.com> <469673A6.9020100@ericsson.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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: 7d33c50f3756db14428398e2bdedd581 Balazs Lengyel wrote: > Chapter 1.3 2nd para) The netconf server will read RPC requests > (otherwise the TCP buffer will fill up :-). But that's the point! > The text in the 07-draft > was better. The problem with the old text ("the server is not required to process RPC requests") is that people interpreted it differently. See http://ops.ietf.org/lists/netconf/netconf.2007/msg00314.html. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 05:37:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Haa-0001tN-Oj for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:37:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9HaW-0000C3-Df for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 05:37:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9HWF-000PC1-Lg for netconf-data@psg.com; Fri, 13 Jul 2007 09:32:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9HW3-000PBE-Me for netconf@ops.ietf.org; Fri, 13 Jul 2007 09:32:54 +0000 Received: from localhost (h14n1c1o851.bredband.skanova.com [81.225.32.14]) by mail.tail-f.com (Postfix) with ESMTP id 9BEA71B80C3; Fri, 13 Jul 2007 11:32:46 +0200 (CEST) Date: Fri, 13 Jul 2007 11:32:45 +0200 (CEST) Message-Id: <20070713.113245.45850550.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: notification-08 comments From: Martin Bjorklund In-Reply-To: <46974021.1060608@andybierman.com> References: <46974021.1060608@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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: 52e1467c2184c31006318542db5614d5 Andy Bierman wrote: > 3.6, para 1: [...] > If a filter element > is specified to look for data of a particular value, and the data > item is not present within a particular event notification for its > value to be checked against, the notification will be filtered out. > > This is not precise enough. > For starters, subtree and Xpath filters return a subset of > conceptual 'input node set', not a boolean expression. > The output node set is returned in the or response. > > What does it mean to convert this mechanism to a boolean filter? > > Does it mean that any output at all from the filter means > it 'passes', and an empty output node set means the filter 'failed'? This is already defined for XPath, we should not change that. Note that an XPath expression does not have to return a 'node set', it can also return a boolean, number or a string. The XPath spec defines how to interpret any of these as a boolean. A subtree filter, on the other hand, can only return a node set. The text in 3.6 could say that a non-empty node set means that the filter matches. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 06:30:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9IQB-0005NY-Bz for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 06:30:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9IQ6-0001z9-Pg for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 06:30:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9IIA-0004Bj-IX for netconf-data@psg.com; Fri, 13 Jul 2007 10:22:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9IHz-000495-7u for netconf@ops.ietf.org; Fri, 13 Jul 2007 10:22:25 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 86C1D20044; Fri, 13 Jul 2007 12:22:14 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-25-46975256b780 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 778B4205ED; Fri, 13 Jul 2007 12:22:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:22:14 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:22:13 +0200 Message-ID: <46975255.1010004@ericsson.com> Date: Fri, 13 Jul 2007 12:22:13 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: notification-08 comments References: <46974021.1060608@andybierman.com> In-Reply-To: <46974021.1060608@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 10:22:13.0831 (UTC) FILETIME=[AE1C4570:01C7C537] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello Andy Bierman wrote: > > 3.3.2, para 3: > > A replayComplete notification is sent to indicate that all of the > replay notifications have been sent. > > Use 'replayComplete' or . > > becomes a normal NETCONF session again. > > Indicate that the agent will now accept operations. > Any requests which have been received but not processed by > the agent will now be processed in the order they were received. [BALAZS]: Buffering earlier received operations for a potentially long time seems bad. I would prefere discarding all operations before and accepting only new operations. 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 Jul 13 10:05:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Llc-0003Qg-Vj for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:05:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9LlY-0008Qp-IX for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:05:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Leo-0000eS-Sd for netconf-data@psg.com; Fri, 13 Jul 2007 13:58:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [69.147.64.97] (helo=smtp124.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Led-0000dP-LS for netconf@ops.ietf.org; Fri, 13 Jul 2007 13:58:01 +0000 Received: (qmail 43101 invoked from network); 13 Jul 2007 13:57:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 13 Jul 2007 13:57:55 -0000 X-YMail-OSG: _lye87cVM1mOhiRksIVILGCddU.kKsItC4muAuPyFxyYBkvy Message-ID: <46978492.20600@andybierman.com> Date: Fri, 13 Jul 2007 06:56:34 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: notification-08 comments References: <46974021.1060608@andybierman.com> <46975255.1010004@ericsson.com> In-Reply-To: <46975255.1010004@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.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Balazs Lengyel wrote: > Hello > > Andy Bierman wrote: >> >> 3.3.2, para 3: >> >> A replayComplete notification is sent to indicate that all of the >> replay notifications have been sent. >> >> Use 'replayComplete' or . >> >> becomes a normal NETCONF session again. >> >> Indicate that the agent will now accept operations. >> Any requests which have been received but not processed by >> the agent will now be processed in the order they were received. > [BALAZS]: Buffering earlier received operations for a potentially > long time seems bad. I would prefere discarding all operations > before and accepting only new operations. > How does the agent know the next just arrived or has been in queue for an hour. Isn't this implementation-dependent? Wording it the other way (flush the queue) is also implementation-dependent. But the other way, the manager would get no indication the elements were dropped. It would wait for replies, and the agent would wait for a new -- and the session would hang. > Balazs > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 10:15:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Lvi-0006vF-TF for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:15:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Lve-0000Mn-2x for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:15:34 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9LqL-0001rP-NL for netconf-data@psg.com; Fri, 13 Jul 2007 14:10:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Lq9-0001ps-Pg for netconf@ops.ietf.org; Fri, 13 Jul 2007 14:09:56 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9933521265; Fri, 13 Jul 2007 16:09:47 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-f9-469787ab9880 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7BE2820122; Fri, 13 Jul 2007 16:09:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 16:09:47 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 16:09:46 +0200 Message-ID: <469787AA.30004@ericsson.com> Date: Fri, 13 Jul 2007 16:09:46 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: notification-08 comments References: <46974021.1060608@andybierman.com> <46975255.1010004@ericsson.com> <46978492.20600@andybierman.com> In-Reply-To: <46978492.20600@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 14:09:46.0958 (UTC) FILETIME=[78021EE0:01C7C557] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab See below! Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello >> >> Andy Bierman wrote: >>> >>> 3.3.2, para 3: >>> >>> A replayComplete notification is sent to indicate that all of the >>> replay notifications have been sent. >>> >>> Use 'replayComplete' or . >>> >>> becomes a normal NETCONF session again. >>> >>> Indicate that the agent will now accept operations. >>> Any requests which have been received but not processed by >>> the agent will now be processed in the order they were received. >> [BALAZS]: Buffering earlier received operations for a >> potentially long time seems bad. I would prefere discarding all >> operations before and accepting only new >> operations. >> > > How does the agent know the next just arrived or has been > in queue for an hour. Isn't this implementation-dependent? > Wording it the other way (flush the queue) is also > implementation-dependent. > > But the other way, the manager would get no indication the > elements were > dropped. It would wait for replies, and the agent would > wait for a new -- and the session would hang. > >> Balazs >> > > Andy [BALAZS]: I think the manager should assume that anything it sent before receiving replayComplete will be discarded. It should not even send anything before that in the first place. You can still have a situation when the rpc request and replayComplete are sent at the same time, but if you like to live dangerously better have a timeout on the request. On the other hand if the agent may store requests that arrived before the replayComplete was sent you end up with a lot of other questions: - how long must an agent store rpc requests? 1 year? - how many requests must it store? - if the agent is not able to store all requests, it drops some. How will the manager know how many have been dropped? As I see it discarding all requests is the best defined behavior we can prescribe. 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 Jul 13 10:37:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MHK-0004dB-5c for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:37:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9MHG-0001CO-NB for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:37:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9MCN-0004MA-Iw for netconf-data@psg.com; Fri, 13 Jul 2007 14:32:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.205] (helo=smtp106.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9MC4-0004J0-A3 for netconf@ops.ietf.org; Fri, 13 Jul 2007 14:32:33 +0000 Received: (qmail 30665 invoked from network); 13 Jul 2007 14:32:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2007 14:32:25 -0000 X-YMail-OSG: ftYKCDIVM1kCZfi7AoqLDohjr8wyR8SJ5FeOC.UPG2I8qGxH Message-ID: <46978CA9.4070104@andybierman.com> Date: Fri, 13 Jul 2007 07:31:05 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: notification-08 comments References: <46974021.1060608@andybierman.com> <46975255.1010004@ericsson.com> <46978492.20600@andybierman.com> <469787AA.30004@ericsson.com> In-Reply-To: <469787AA.30004@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.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Balazs Lengyel wrote: > See below! > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello >>> >>> Andy Bierman wrote: >>>> >>>> 3.3.2, para 3: >>>> >>>> A replayComplete notification is sent to indicate that all of the >>>> replay notifications have been sent. >>>> >>>> Use 'replayComplete' or . >>>> >>>> becomes a normal NETCONF session again. >>>> >>>> Indicate that the agent will now accept operations. >>>> Any requests which have been received but not processed by >>>> the agent will now be processed in the order they were received. >>> [BALAZS]: Buffering earlier received operations for a >>> potentially long time seems bad. I would prefere discarding all >>> operations before and accepting only new >>> operations. >>> >> >> How does the agent know the next just arrived or has been >> in queue for an hour. Isn't this implementation-dependent? >> Wording it the other way (flush the queue) is also >> implementation-dependent. >> >> But the other way, the manager would get no indication the >> elements were >> dropped. It would wait for replies, and the agent would >> wait for a new -- and the session would hang. >> >>> Balazs >>> >> >> Andy > [BALAZS]: I think the manager should assume that anything it sent before > receiving replayComplete will be discarded. It should not even send > anything before that in the first place. You can still have a situation > when the rpc request and replayComplete are sent at the same time, but > if you like to live dangerously better have a timeout on the request. > I think it is more useful to assume the more robust scenario than the most fragile one. Some agents may process RPCs during the notification replay, and this document (right now) has no way for the manager to know that. That means the manager cannot possibly know for sure if it should wait for a reply or not. > On the other hand if the agent may store requests that arrived before > the replayComplete was sent you end up with a lot of other questions: > - how long must an agent store rpc requests? 1 year? > - how many requests must it store? This is an artifact of TCP. The bytes will be there as long as the connection (and/or session) has not been dropped. > - if the agent is not able to store all requests, it drops some. How > will the manager know how many have been dropped? > > As I see it discarding all requests is the best defined behavior we can > prescribe. This is very implementation-biased. Why is this the best, especially since the spec allows an agent to process RPCs if it wants. > > Balazs Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 10:59:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9McJ-00056M-AZ for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:59:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9McE-0002Cc-VF for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 10:59:35 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9MWd-0006mB-6o for netconf-data@psg.com; Fri, 13 Jul 2007 14:53:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.198.209] (helo=smtp110.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9MWI-0006iG-Lm for netconf@ops.ietf.org; Fri, 13 Jul 2007 14:53:29 +0000 Received: (qmail 23376 invoked from network); 13 Jul 2007 14:53:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2007 14:53:21 -0000 X-YMail-OSG: TKQQePIVM1lTJ8TPVdoNDl4rvRMdX9NnYOdpk7sWzNtafuz3 Message-ID: <46979191.9070804@andybierman.com> Date: Fri, 13 Jul 2007 07:52:01 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: notification-08 comments References: <46974021.1060608@andybierman.com> <20070713.113245.45850550.mbj@tail-f.com> In-Reply-To: <20070713.113245.45850550.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.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Martin Bjorklund wrote: > Andy Bierman wrote: >> 3.6, para 1: > > [...] > >> If a filter element >> is specified to look for data of a particular value, and the data >> item is not present within a particular event notification for its >> value to be checked against, the notification will be filtered out. >> >> This is not precise enough. >> For starters, subtree and Xpath filters return a subset of >> conceptual 'input node set', not a boolean expression. >> The output node set is returned in the or response. >> >> What does it mean to convert this mechanism to a boolean filter? >> >> Does it mean that any output at all from the filter means >> it 'passes', and an empty output node set means the filter 'failed'? > > This is already defined for XPath, we should not change that. Note > that an XPath expression does not have to return a 'node set', it can > also return a boolean, number or a string. The XPath spec defines how > to interpret any of these as a boolean. > Doesn't the draft need to say the Xpath expression needs to be the boolean form? Or does it need to specify how the other forms are converted to boolean? Or is this already handled in Xpath and the draft can just say "convert to boolean"? > A subtree filter, on the other hand, can only return a node set. The > text in 3.6 could say that a non-empty node set means that the filter > matches. > > > /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 Fri Jul 13 11:26:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9N2A-0007DS-OO for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 11:26:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9N26-0003IU-DB for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 11:26:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9MxW-0009wu-Eh for netconf-data@psg.com; Fri, 13 Jul 2007 15:21:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9MxL-0009uW-Ni for netconf@ops.ietf.org; Fri, 13 Jul 2007 15:21:25 +0000 Received: (qmail 55338 invoked from network); 13 Jul 2007 15:21:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 13 Jul 2007 15:21:18 -0000 X-YMail-OSG: Q3KNMhEVM1kCyotVIuhlZ2cz9OT2LNrt7ch9gfzpqLWVANav Message-ID: <4697981E.6010301@andybierman.com> Date: Fri, 13 Jul 2007 08:19:58 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: filtering problem 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.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi, There is another problem with filtering and the examples in sec 5: (!!!) The draft must say exactly where in the element that the is applied. The current text does not say anything. All the examples in sec. 5 are broken because the 'notification type' layer is missing. The examples assume the filters can only be applied to a conceptual datastore, just like the filter. However, the most commonly needed filter is going to be on the notification type itself! Example (w/o namespaces): date-time string... fred@example.com /interfaces/interface[name='eth0'] ... For simplicity, assume the manager just wants this one notification type. The filter is going to be something like: A filter for configChange just on a specific configTarget might be: /interfaces/interface[name='eth0'] The way the draft is now does not reflect how notifications are actually structured. 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 Jul 13 11:46:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9NLW-000521-Rv for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 11:46:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9NLS-0004AC-G4 for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 11:46:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9NHR-000CHK-Vf for netconf-data@psg.com; Fri, 13 Jul 2007 15:42:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9NHG-000CFZ-UH for netconf@ops.ietf.org; Fri, 13 Jul 2007 15:42:00 +0000 Received: from localhost (h225n2c1o851.bredband.skanova.com [81.225.33.225]) by mail.tail-f.com (Postfix) with ESMTP id 1CA9A1B80C3; Fri, 13 Jul 2007 17:41:50 +0200 (CEST) Date: Fri, 13 Jul 2007 16:41:10 +0200 (CEST) Message-Id: <20070713.164110.191488841.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: notification-08 comments From: Martin Bjorklund In-Reply-To: <46979191.9070804@andybierman.com> References: <46974021.1060608@andybierman.com> <20070713.113245.45850550.mbj@tail-f.com> <46979191.9070804@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> 3.6, para 1: > > > > [...] > > > >> If a filter element > >> is specified to look for data of a particular value, and the data > >> item is not present within a particular event notification for its > >> value to be checked against, the notification will be filtered out. > >> > >> This is not precise enough. > >> For starters, subtree and Xpath filters return a subset of > >> conceptual 'input node set', not a boolean expression. > >> The output node set is returned in the or response. > >> > >> What does it mean to convert this mechanism to a boolean filter? > >> > >> Does it mean that any output at all from the filter means > >> it 'passes', and an empty output node set means the filter 'failed'? > > > > This is already defined for XPath, we should not change that. Note > > that an XPath expression does not have to return a 'node set', it can > > also return a boolean, number or a string. The XPath spec defines how > > to interpret any of these as a boolean. > > > > Doesn't the draft need to say the Xpath expression needs to > be the boolean form? Or does it need to specify how the other > forms are converted to boolean? Or is this already handled in Xpath > and the draft can just say "convert to boolean"? The latter IMO. (This is sort of underspecified in the base spec as well - it just says that the filter is an XPath expression, but it is not defined how the node-set is represented in the XML rpc-reply, and nothing is said about boolean/number/string expressions.) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 11:50:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9NP8-0001IK-LA for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 11:50:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9NP4-0004KF-9e for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 11:50:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9NJp-000CWq-HD for netconf-data@psg.com; Fri, 13 Jul 2007 15:44:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9NJe-000CVq-Gp for netconf@ops.ietf.org; Fri, 13 Jul 2007 15:44:28 +0000 Received: from localhost (h225n2c1o851.bredband.skanova.com [81.225.33.225]) by mail.tail-f.com (Postfix) with ESMTP id 8EA481B80C3; Fri, 13 Jul 2007 17:44:21 +0200 (CEST) Date: Fri, 13 Jul 2007 16:43:42 +0200 (CEST) Message-Id: <20070713.164342.74182725.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: filtering problem From: Martin Bjorklund In-Reply-To: <4697981E.6010301@andybierman.com> References: <4697981E.6010301@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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: 25620135586de10c627e3628c432b04a Andy Bierman wrote: > Hi, > > There is another problem with filtering and the examples in sec 5: (!!!) > > The draft must say exactly where in the element > that the is applied. The current text does not say anything. Agreed. > All the examples in sec. 5 are broken because the 'notification type' > layer is missing. I think it is ok. Specify that the filter is applied to the 'notificationContent' element as root (which is the abstract element). > The examples assume the filters can only be > applied to a conceptual datastore, just like the filter. > > However, the most commonly needed filter is going to be > on the notification type itself! > > Example (w/o namespaces): > > > > date-time string... > fred@example.com > /interfaces/interface[name='eth0'] > ... > > > > For simplicity, assume the manager just wants > this one notification type. The filter is going to be something like: > > > > Yes, and IMO this is consistent with the examples. /martin > A filter for configChange just on a specific configTarget might be: > > > > /interfaces/interface[name='eth0'] > > > > The way the draft is now does not reflect how notifications are > actually structured. > > > Andy > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 12:23:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Nvx-0005dN-H3 for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 12:23:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Nvq-0005cP-5d for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 12:23:57 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Nrm-000GRn-Ss for netconf-data@psg.com; Fri, 13 Jul 2007 16:19:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Nrb-000GPr-MB for netconf@ops.ietf.org; Fri, 13 Jul 2007 16:19:33 +0000 Received: (qmail 69461 invoked from network); 13 Jul 2007 16:19:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 13 Jul 2007 16:19:25 -0000 X-YMail-OSG: Cf2_DYMVM1nnFGmyMzDIyVItKVt9G71hNwIx0d1SzMZf.GtX Message-ID: <4697A5BD.7020900@andybierman.com> Date: Fri, 13 Jul 2007 09:18:05 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> In-Reply-To: <20070713.164342.74182725.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.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> There is another problem with filtering and the examples in sec 5: (!!!) >> >> The draft must say exactly where in the element >> that the is applied. The current text does not say anything. > > Agreed. > >> All the examples in sec. 5 are broken because the 'notification type' >> layer is missing. > > I think it is ok. Specify that the filter is applied to the > 'notificationContent' element as root (which is the abstract element). > Ok -- if it is explained like this, the element is renamed to , and the wrapper is shown, then I agree. 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 Jul 13 13:46:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PDb-0002Br-6H for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 13:46:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9PDX-0000Vw-H9 for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 13:46:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9P7x-000P3e-8w for netconf-data@psg.com; Fri, 13 Jul 2007 17:40:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9P7l-000P0C-OT for netconf@ops.ietf.org; Fri, 13 Jul 2007 17:40:19 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D217020FF2; Fri, 13 Jul 2007 19:40:11 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-f0-4697b8fb5440 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AEE1520FBC; Fri, 13 Jul 2007 19:40:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 19:40:11 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 19:40:10 +0200 Message-ID: <4697B8F8.90708@ericsson.com> Date: Fri, 13 Jul 2007 19:40:08 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: notification-08 comments References: <46974021.1060608@andybierman.com> <46975255.1010004@ericsson.com> <46978492.20600@andybierman.com> <469787AA.30004@ericsson.com> <46978CA9.4070104@andybierman.com> In-Reply-To: <46978CA9.4070104@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 17:40:11.0032 (UTC) FILETIME=[DC8AF180:01C7C574] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Andy Bierman wrote: >> On the other hand if the agent may store requests that arrived before >> the replayComplete was sent you end up with a lot of other questions: >> - how long must an agent store rpc requests? 1 year? >> - how many requests must it store? > > > This is an artifact of TCP. > The bytes will be there as long as the connection (and/or session) > has not been dropped. > > Andy Sadly you can not use TCP buffer to store much data because: - The maximum receive buffer for a socket on a linux system is usually (2*)87 kB. You may push that somewhat higher but a netconf manager can send you MBytes of requests. The agent's receive buffer will fill up, so it will not send ACK messages to the Manager. Then the manager's send buffer will also fill up which might block the manager program. So in notification mode the agent better read the socket and do something with any arrived data, either discard it or store it in application space. 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 Jul 13 14:15:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Pfd-0005pf-TZ for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 14:15:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9PfZ-0001TO-Ha for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 14:15:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9PZQ-0002TC-6G for netconf-data@psg.com; Fri, 13 Jul 2007 18:08:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9PZE-0002SK-C3 for netconf@ops.ietf.org; Fri, 13 Jul 2007 18:08:42 +0000 Received: (qmail 23787 invoked from network); 13 Jul 2007 18:08:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2007 18:08:35 -0000 X-YMail-OSG: _iAGaMUVM1kXY_nVZRDJdxIeAylL4fiWYSpdqDmupKgn0jjs Message-ID: <4697BF52.6070102@andybierman.com> Date: Fri, 13 Jul 2007 11:07:14 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: notification-08 comments References: <46974021.1060608@andybierman.com> <46975255.1010004@ericsson.com> <46978492.20600@andybierman.com> <469787AA.30004@ericsson.com> <46978CA9.4070104@andybierman.com> <4697B8F8.90708@ericsson.com> In-Reply-To: <4697B8F8.90708@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.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Balazs Lengyel wrote: > Andy Bierman wrote: >>> On the other hand if the agent may store requests that arrived before >>> the replayComplete was sent you end up with a lot of other questions: >>> - how long must an agent store rpc requests? 1 year? >>> - how many requests must it store? >> >> >> This is an artifact of TCP. >> The bytes will be there as long as the connection (and/or session) >> has not been dropped. >> >> Andy > > Sadly you can not use TCP buffer to store much data because: > - The maximum receive buffer for a socket on a linux system is usually > (2*)87 kB. You may push that somewhat higher but a netconf manager can > send you MBytes of requests. The agent's receive buffer will fill up, so > it will not send ACK messages to the Manager. Then the manager's send > buffer will also fill up which might block the manager program. > We are not trying to use TCP to store a lot of data for the agent, in this weird corner-case. There is clear WG consensus that the agent can process these interleaved RPC requests if it chooses, but this is not required. > So in notification mode the agent better read the socket and do > something with any arrived data, either discard it or store it in > application space. No, the client will eventually block, and stop sending. This is no different than (normal mode) where the client sends requests faster than the agent is sending replies. > > Balazs Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 15:23:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Qjb-0002d5-4d for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 15:23:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9QjX-0004EL-Ps for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 15:23:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9QeF-0009kw-1i for netconf-data@psg.com; Fri, 13 Jul 2007 19:17:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9Qe4-0009kB-9N for netconf@ops.ietf.org; Fri, 13 Jul 2007 19:17:45 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 13 Jul 2007 12:17:40 -0700 X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="36420531:sNHT31870352" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6DJHcO11675; Fri, 13 Jul 2007 12:17:38 -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 l6DJHZjw077257; Fri, 13 Jul 2007 15:17:35 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200707131917.l6DJHZjw077257@idle.juniper.net> To: Balazs Lengyel cc: Andy Bierman , "Netconf (E-mail)" Subject: Re: notification-08 comments In-Reply-To: Your message of "Fri, 13 Jul 2007 16:09:46 +0200." <469787AA.30004@ericsson.com> Date: Fri, 13 Jul 2007 15:17:35 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Balazs Lengyel writes: >[BALAZS]: I think the manager should assume that anything it sent before receiving >replayComplete will be discarded. You can't make specs out of assumptions and living dangerously. You need "MUST"s and "MUST NOT"s. Otherwise, code that works against one conforming implementation will fail against another and no one will be clearly at fault. >You can still have a situation when the rpc request and replayComplete are sent at the >same time, but if you like to live dangerously better have a timeout on the request. A timeout won't close the timing window that you've opened, it will just introduce another, possibly worse, one, since you have no idea how long any RPC will take. >As I see it discarding all requests is the best defined behavior we can prescribe. Discarding leaves you with simlar questions: - how will the server know when to stop discarding? - how will the client know what was discarded? So the facts seem to be: (a) the client can put the connection into "notification" mode (b) the server can put the connection into "rpc" mode There's no way the server can discard content from the client, since it has no idea whether the content pre-dates the switch back into "rpc" mode. So is it worth _not_ allowing the server to put the connection back into "rpc" mode? Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 15:46:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9R65-0008Hr-6U for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 15:46:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9R61-0004xk-OX for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 15:46:37 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9R2C-000CFT-NR for netconf-data@psg.com; Fri, 13 Jul 2007 19:42:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.210] (helo=smtp111.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9R21-000CEt-Mx for netconf@ops.ietf.org; Fri, 13 Jul 2007 19:42:31 +0000 Received: (qmail 25868 invoked from network); 13 Jul 2007 19:42:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2007 19:42:24 -0000 X-YMail-OSG: Gb8Ck_8VM1mhoIzBdmM1lSnrsrK..NCu6EjCx4fb84HdoFMl Message-ID: <4697D54F.80301@andybierman.com> Date: Fri, 13 Jul 2007 12:41:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Phil Shafer CC: Balazs Lengyel , "Netconf (E-mail)" Subject: Re: notification-08 comments References: <200707131917.l6DJHZjw077257@idle.juniper.net> In-Reply-To: <200707131917.l6DJHZjw077257@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.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Phil Shafer wrote: > Balazs Lengyel writes: >> [BALAZS]: I think the manager should assume that anything it sent before receiving >> replayComplete will be discarded. > > You can't make specs out of assumptions and living dangerously. You > need "MUST"s and "MUST NOT"s. Otherwise, code that works against one > conforming implementation will fail against another and no one will > be clearly at fault. > >> You can still have a situation when the rpc request and replayComplete are sent at the >> same time, but if you like to live dangerously better have a timeout on the request. > > A timeout won't close the timing window that you've opened, it will just > introduce another, possibly worse, one, since you have no idea how long > any RPC will take. > >> As I see it discarding all requests is the best defined behavior we can prescribe. > > Discarding leaves you with simlar questions: > - how will the server know when to stop discarding? > - how will the client know what was discarded? > > So the facts seem to be: > (a) the client can put the connection into "notification" mode > (b) the server can put the connection into "rpc" mode > > There's no way the server can discard content from the client, since > it has no idea whether the content pre-dates the switch back into > "rpc" mode. > > So is it worth _not_ allowing the server to put the connection > back into "rpc" mode? You have exposed both sides of the issue: 1) What must/should/may an agent do with input received while it is sending notifications? [I agree with you that the agent must not discard this input.] 2) Should the corner-case where a stop time is given be handled by transitioning (silent or otherwise) from the 'sending replayed notifications' mode back to 'normal mode', or should it be handled the same way as when stop time is not provided (tail -f mode), by waiting for the manager to close the session? [I share your concerns about this silent mode transition. I would rather decide based on use cases rather than perceived implementation complexity. If we did as you suggest, then an agent implementation is not forced to deal with any 'backed up' requests, but at some loss of functionality. This mode (get replays from time A to time B) could be viewed as just another RPC operation like .] > > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 15:54:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RDl-00072B-FP for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 15:54:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9RDh-0005DA-4b for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 15:54:33 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9R9o-000D4U-1q for netconf-data@psg.com; Fri, 13 Jul 2007 19:50:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9R9d-000D2S-7Z for netconf@ops.ietf.org; Fri, 13 Jul 2007 19:50:22 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 13 Jul 2007 12:50:17 -0700 X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="36432997:sNHT36479788" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6DJoFO18780; Fri, 13 Jul 2007 12:50:15 -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 l6DJoFjw077499; Fri, 13 Jul 2007 15:50:15 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200707131950.l6DJoFjw077499@idle.juniper.net> To: Andy Bierman cc: Balazs Lengyel , "Netconf (E-mail)" Subject: Re: notification-08 comments In-Reply-To: Your message of "Fri, 13 Jul 2007 12:41:03 PDT." <4697D54F.80301@andybierman.com> Date: Fri, 13 Jul 2007 15:50:15 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Andy Bierman writes: >This mode >(get replays from time A to time B) could be viewed as just >another RPC operation like .] Heck, all of get-notifications could be viewed as just another RPC operation ;^) Thanks, Phil P.s.: http://professional.juniper.net/phil/ietf/draft-shafer-netconf-syslog-00.txt -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 13 16:07:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RQa-0006R5-1O for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 16:07:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9RQV-0005Z7-MO for netconf-archive@lists.ietf.org; Fri, 13 Jul 2007 16:07:48 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9RMY-000Eom-MN for netconf-data@psg.com; Fri, 13 Jul 2007 20:03:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.211] (helo=smtp112.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I9MV2-0006ac-Ao for netconf@ops.ietf.org; Fri, 13 Jul 2007 14:52:10 +0000 Received: (qmail 46710 invoked from network); 13 Jul 2007 14:52:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2007 14:52:03 -0000 X-YMail-OSG: Ff0WrT4VM1lHJ0aY5RJD4uxa6wEEzW9e5QHsezCmfdXmPt5I Message-ID: <46979143.7080703@andybierman.com> Date: Fri, 13 Jul 2007 07:50:43 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: filtering problem 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.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi, There is another problem with filtering and the examples in sec 5: (!!!) The draft must say exactly where in the element that the is applied. The current text does not say anything. All the examples in sec. 5 are broken because the 'notification type' layer is missing. The examples assume the filters can only be applied to a conceptual datastore, just like the filter. However, the most commonly needed filter is going to be on the notification type itself! Example (w/o namespaces): date-time string... fred@example.com /interfaces/interface[name='eth0'] ... For simplicity, assume the manager just wants this one notification type. The filter is going to be something like: A filter for configChange just on a specific configTarget might be: /interfaces/interface[name='eth0'] The way the draft is now does not reflect how notifications are actually structured. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 15 18:17:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IACOq-0000LB-T2 for netconf-archive@lists.ietf.org; Sun, 15 Jul 2007 18:17:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IACOm-0006nL-Ee for netconf-archive@lists.ietf.org; Sun, 15 Jul 2007 18:17:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IACIS-000Bc5-KU for netconf-data@psg.com; Sun, 15 Jul 2007 22:10:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [204.127.192.84] (helo=rwcrmhc14.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IACIH-000BZ2-C2 for netconf@ops.ietf.org; Sun, 15 Jul 2007 22:10:27 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc14) with SMTP id <20070715221019m1400m2906e>; Sun, 15 Jul 2007 22:10:20 +0000 From: "David B Harrington" To: "'Phil Shafer'" , "'Andy Bierman'" Cc: "'Balazs Lengyel'" , "'Netconf \(E-mail\)'" References: Your message of "Fri, 13 Jul 2007 12:41:03 PDT." <4697D54F.80301@andybierman.com> <200707131950.l6DJoFjw077499@idle.juniper.net> Subject: replay as Date: Sun, 15 Jul 2007 18:09:49 -0400 Message-ID: <044701c7c72c$dfd16900$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 Thread-Index: AcfFh593/wMiE9UpTrSoByR+SPhbjwBldDVA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <200707131950.l6DJoFjw077499@idle.juniper.net> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi, I agree. We could eliminate the replay attributes from the notification operation, and a data model for logging unsent notifications could be defined that can be accessed using a . This way replay becomes a data-model-specific thing, not an operation extension, and the notification operation is vastly simplified. All the extra text associated with replay that we are debating would go away, and the netconf-equivalent of "end of table" would identify when replay was complete. The SNMP community didn't define a new operation feature to provide replay; they defined the NOTIFICATION LOG MIB. The MIB has the following sections: o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. In this MIB, each log is named, and has an associated filter, and an associated entry limit. In netconf terms, each "named" log of notifications for replay could be considered a separate stream. So a manager could subscribe for a replay-stream. But I like the approach. With the MIB, a manager must explicitly ask that notifications be logged (saved), and which notifications are of interest. The agent does not need to save all notifications in case some manager decides to ask for a filtered subset of the whole sometime in the future, but is only required to save the notifications explicitly requested by a manager when it requested the named log be maintained. And the maximum number of entries in each log can be specified by the manager as well. If a netconf manager was required to configure the replay log in advance, then they could request only the notifications of interest; this is similar to a subscribe. The MIB uses a "filter name" to identify a filter predefined in a different table; this is similar to the namedProfile feature of netconf-notifications. If the manager was required to provide something akin to OwnerString, then once the manager had accessed the notifications it had requested, then the agent could discard the saved notifications "stream" (and a manager could choose to delete their saved log). If no manager requests replay, then the agent does not need to consume resources saving notifications nobody wants. This seems consistent with the syslog.conf approach of allowing operators to name logs, and specifying what they want saved into those logs. Since notification replay is really all about replaying logs of notifications, it would probably be a good thing to design an approach consistent with existing widely-deployed logging mechanisms, such as syslog, so that existing admin tools and scripts would work with the netconf replay logs as well. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Friday, July 13, 2007 3:50 PM > To: Andy Bierman > Cc: Balazs Lengyel; Netconf (E-mail) > Subject: Re: notification-08 comments > > Andy Bierman writes: > >This mode > >(get replays from time A to time B) could be viewed as just > >another RPC operation like .] > > Heck, all of get-notifications could be viewed as just another RPC > operation ;^) > > Thanks, > Phil > > P.s.: > http://professional.juniper.net/phil/ietf/draft-shafer-netconf > -syslog-00.txt > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 15 19:08:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADCU-0005vU-05 for netconf-archive@lists.ietf.org; Sun, 15 Jul 2007 19:08:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IADCP-0007ud-6v for netconf-archive@lists.ietf.org; Sun, 15 Jul 2007 19:08:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAD7g-000FdR-IH for netconf-data@psg.com; Sun, 15 Jul 2007 23:03:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.208] (helo=smtp109.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAD7U-000Fce-Qt for netconf@ops.ietf.org; Sun, 15 Jul 2007 23:03:22 +0000 Received: (qmail 45527 invoked from network); 15 Jul 2007 23:03:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 15 Jul 2007 23:03:15 -0000 X-YMail-OSG: SrSeX3IVM1nBmknuk.LMnyMiH3HcR_p1Yf160jdec3K7NHgEmo_B_aCTqROiOIDujCQuFv9FEOyprvIA.7u_wznEKw-- Message-ID: <469AA761.1060201@andybierman.com> Date: Sun, 15 Jul 2007 16:01:53 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: 'Phil Shafer' , 'Balazs Lengyel' , "'Netconf (E-mail)'" Subject: Re: replay as References: Your message of "Fri, 13 Jul 2007 12:41:03 PDT." <4697D54F.80301@andybierman.com> <200707131950.l6DJoFjw077499@idle.juniper.net> <044701c7c72c$dfd16900$0600a8c0@china.huawei.com> In-Reply-To: <044701c7c72c$dfd16900$0600a8c0@china.huawei.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.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 David B Harrington wrote: > Hi, > > I agree. Agree with what? I don't think anybody suggested getting rid of replay. But it was pointed out a long time ago that replay was just a specialized function. I think the rationale is that it would be better to design this feature like this, than force a manager to read the log, and then transition to receiving live notifications. The agent has to handle that complexity instead. IMO, the replay feature is not a problem, but a logging DM as you suggest is also useful. Since the agent has to implement filtering of some sort, why not search the notification logs on the agent and just return items of interest, and do it without adding a single extra line of code or line of normative text? Nah, too easy ;-) (I supported just having a log as you suggest, but now that replay is done, and the log DM is not started yet, it is not worth changing now.) Andy > > We could eliminate the replay attributes from the notification > operation, and a data model for logging unsent notifications could be > defined that can be accessed using a . This way replay becomes a > data-model-specific thing, not an operation extension, and the > notification operation is vastly simplified. > > All the extra text associated with replay that we are debating would > go away, and the netconf-equivalent of "end of table" would identify > when replay was complete. > > The SNMP community didn't define a new operation feature to provide > replay; they defined the NOTIFICATION LOG MIB. The MIB has the > following sections: > > o Configuration -- control over how much the log can hold and > what Notifications are to be logged. > > o Statistics -- indications of logging activity. > > o Log -- the Notifications themselves. > > In this MIB, each log is named, and has an associated filter, and an > associated entry limit. In netconf terms, each "named" log of > notifications for replay could be considered a separate stream. So a > manager could subscribe for a replay-stream. But I like the > approach. > > With the MIB, a manager must explicitly ask that notifications be > logged (saved), and which notifications are of interest. The agent > does not need to save all notifications in case some manager decides > to ask for a filtered subset of the whole sometime in the future, but > is only required to save the notifications explicitly requested by a > manager when it requested the named log be maintained. And the maximum > number of entries in each log can be specified by the manager as well. > > If a netconf manager was required to configure the replay log in > advance, then they could request only the notifications of interest; > this is similar to a subscribe. The MIB uses a "filter name" to > identify a filter predefined in a different table; this is similar to > the namedProfile feature of netconf-notifications. If the manager was > required to provide something akin to OwnerString, then once the > manager had accessed the notifications it had requested, then the > agent could discard the saved notifications "stream" (and a manager > could choose to delete their saved log). If no manager requests > replay, then the agent does not need to consume resources saving > notifications nobody wants. > > This seems consistent with the syslog.conf approach of allowing > operators to name logs, and specifying what they want saved into those > logs. Since notification replay is really all about replaying logs of > notifications, it would probably be a good thing to design an approach > consistent with existing widely-deployed logging mechanisms, such as > syslog, so that existing admin tools and scripts would work with the > netconf replay logs as well. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer >> Sent: Friday, July 13, 2007 3:50 PM >> To: Andy Bierman >> Cc: Balazs Lengyel; Netconf (E-mail) >> Subject: Re: notification-08 comments >> >> Andy Bierman writes: >>> This mode >>> (get replays from time A to time B) could be viewed as just >>> another RPC operation like .] >> Heck, all of get-notifications could be viewed as just another RPC >> operation ;^) >> >> Thanks, >> Phil >> >> P.s.: >> http://professional.juniper.net/phil/ietf/draft-shafer-netconf >> -syslog-00.txt >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 15 21:54:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFmz-0004mO-9s for netconf-archive@lists.ietf.org; Sun, 15 Jul 2007 21:54:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAFmu-00030m-Uu for netconf-archive@lists.ietf.org; Sun, 15 Jul 2007 21:54:17 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAFgw-0006Zd-Pu for netconf-data@psg.com; Mon, 16 Jul 2007 01:48:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAFgm-0006XJ-4i for netconf@ops.ietf.org; Mon, 16 Jul 2007 01:47:57 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 15 Jul 2007 18:47:52 -0700 Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6G1lZO13650; Sun, 15 Jul 2007 18:47:35 -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 l6G1lWjw085416; Sun, 15 Jul 2007 21:47:32 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200707160147.l6G1lWjw085416@idle.juniper.net> To: "David B Harrington" cc: "'Andy Bierman'" , "'Balazs Lengyel'" , "'Netconf \(E-mail\)'" Subject: Re: replay as In-Reply-To: Your message of "Sun, 15 Jul 2007 18:09:49 EDT." <044701c7c72c$dfd16900$0600a8c0@china.huawei.com> Date: Sun, 15 Jul 2007 21:47:32 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c "David B Harrington" writes: >This way replay becomes a >data-model-specific thing, not an operation extension, and the >notification operation is vastly simplified. Isn't making replay data-model specific worse, since this will lead to different ways of doing it? Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 16 07:36:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOsh-00030y-H6 for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 07:36:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAOsc-0006UD-Pf for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 07:36:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAOlA-0001ND-Ey for netconf-data@psg.com; Mon, 16 Jul 2007 11:29:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAOky-0001L4-57 for netconf@ops.ietf.org; Mon, 16 Jul 2007 11:28:54 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC6CF2178C; Mon, 16 Jul 2007 13:28:40 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-98-469b5668784a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8CC0A21588; Mon, 16 Jul 2007 13:28:40 +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 Jul 2007 13:28:40 +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 Jul 2007 13:28:40 +0200 Message-ID: <469B5667.6020307@ericsson.com> Date: Mon, 16 Jul 2007 13:28:39 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer CC: Andy Bierman , "Netconf (E-mail)" Subject: Re: notification-08 comments References: <200707131917.l6DJHZjw077257@idle.juniper.net> In-Reply-To: <200707131917.l6DJHZjw077257@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 11:28:40.0199 (UTC) FILETIME=[75690170:01C7C79C] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hello, I still feel that just letting data sent by the manager to sit in the TCP buffers is a bad thing to do. These buffers will fill up and this might block the manager SW. At that point the agent actually does not accept anything from the manager. According to the Postel principle you should be liberal what you accept. Accepting nothing is not liberal. So in my view the client/agent should read the data from the connection buffers and do something with it. If not discard it then what? I agree with you on one point: we need a precise definition about when Netconf connection enters and leaves notification mode. This should be described both for the agent and the manager. Balazs Phil Shafer wrote: > Balazs Lengyel writes: >> [BALAZS]: I think the manager should assume that anything it sent before receiving >> replayComplete will be discarded. > > You can't make specs out of assumptions and living dangerously. You > need "MUST"s and "MUST NOT"s. Otherwise, code that works against one > conforming implementation will fail against another and no one will > be clearly at fault. > >> You can still have a situation when the rpc request and replayComplete are sent at the >> same time, but if you like to live dangerously better have a timeout on the request. > > A timeout won't close the timing window that you've opened, it will just > introduce another, possibly worse, one, since you have no idea how long > any RPC will take. [BALAZS]: Timeout was brought up by Andy as I remember. > >> As I see it discarding all requests is the best defined behavior we can prescribe. > > Discarding leaves you with simlar questions: > - how will the server know when to stop discarding? [BALAZS]: start discarding after the create-subscription was replied with OK. Stop discarding after the replayComplete was sent. > - how will the client know what was discarded? [BALAZS]: It should not send anything after create-subscription until the replayComplete or create-subscription-error is received. If it still does send something we are in the gray area. The client must be prepared for lost rpc-requests. > > So the facts seem to be: > (a) the client can put the connection into "notification" mode > (b) the server can put the connection into "rpc" mode > > There's no way the server can discard content from the client, since > it has no idea whether the content pre-dates the switch back into > "rpc" mode. > > So is it worth _not_ allowing the server to put the connection > back into "rpc" mode? [BALAZS]: I can live with something like a tear_down of the connection, although an unusable connection left dangling is something I would not like. > > 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 Mon Jul 16 11:58:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASxZ-0002dW-QH for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 11:58:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IASxV-0000as-4q for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 11:58:05 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IASmx-0000dw-Bv for netconf-data@psg.com; Mon, 16 Jul 2007 15:47:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.198.205] (helo=smtp106.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IASmm-0000d9-07 for netconf@ops.ietf.org; Mon, 16 Jul 2007 15:47:01 +0000 Received: (qmail 86754 invoked from network); 16 Jul 2007 15:46:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 16 Jul 2007 15:46:53 -0000 X-YMail-OSG: q3qPerIVM1nVHdRmheRb7ox5zk3QIHVU0k7GxIXvrj26z4Q. Message-ID: <469B929A.3050804@andybierman.com> Date: Mon, 16 Jul 2007 08:45:30 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Phil Shafer CC: David B Harrington , 'Balazs Lengyel' , "'Netconf (E-mail)'" Subject: Re: replay as References: <200707160147.l6G1lWjw085416@idle.juniper.net> In-Reply-To: <200707160147.l6G1lWjw085416@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.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Phil Shafer wrote: > "David B Harrington" writes: >> This way replay becomes a >> data-model-specific thing, not an operation extension, and the >> notification operation is vastly simplified. > > Isn't making replay data-model specific worse, since this will lead > to different ways of doing it? I think Dave means the WG would have to create a specific data model to represent the control knobs and the data logs. This is arguably less work than what the WG already did for the embedded replay feature within the operation. The feature in the spotlight here is the ability for a manager to start listening for live notifications 'now', but after it 'catches up' with any notifications of interest that occurred before 'now', instead of concurrently listening for new notifications and retrieving the missed notifications with . IMO, this is not the same feature as a notification log, it's better (for the manager). But a notification log would be just as interoperable. > > 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 Jul 16 12:37:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATZW-0006Na-FR for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 12:37:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IATZR-0002Cw-VH for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 12:37:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IATSl-000450-JS for netconf-data@psg.com; Mon, 16 Jul 2007 16:30:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IATSa-00043u-El for netconf@ops.ietf.org; Mon, 16 Jul 2007 16:30:14 +0000 Received: (qmail 17190 invoked from network); 16 Jul 2007 16:30:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.177.29 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 16 Jul 2007 16:30:07 -0000 X-YMail-OSG: phx2PiEVM1mVmFdVzJ_QQoUYBvE5tBnCrzaBj1fO6qPH61EpeqRD_v8MAQA7quCcrgQ- Message-ID: <469B9CBC.8060800@andybierman.com> Date: Mon, 16 Jul 2007 09:28:44 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: Phil Shafer , "Netconf (E-mail)" Subject: Re: notification-08 comments References: <200707131917.l6DJHZjw077257@idle.juniper.net> <469B5667.6020307@ericsson.com> In-Reply-To: <469B5667.6020307@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.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Balazs Lengyel wrote: > Hello, > I still feel that just letting data sent by the manager to sit in the > TCP buffers is a bad thing to do. These buffers will fill up and this > might block the manager SW. At that point the agent actually does not > accept anything from the manager. According to the Postel principle you > should be liberal what you accept. Accepting nothing is not liberal. > We need to decide this issue based on perceived features and risks to the operation of the network. The implementation argument is a wash. One implementer says it would be hard not to accept the new . Another says the opposite. A third says it's the same amount of new code either way. The manager needs a better way to tell what the agent will do in this case than to send an request and wait some unspecified time for an . There is no technical reason that interleaving of and elements to the manager should be forbidden, and at the same time, the WG does not want to require the agent to support this 'interleave mode'. However, this 'special mode' design is messy, not well documented, and some WG members don't like it much: 1) normal mode ( and only) 2) normal notification mode (live only) 3) replay notification mode (replayed notifications only, then transition to 'normal mode' after is sent) 4) tail-f mode (replay-then-live notifications only) 5) interleave notification mode (any of modes (2) - (4), except the agent will respond if the manager sends an request) The deterministic and inter-operable resolution to this issue must be part of the document. It is OK if specific behavior is optional, as long as the manager can easily know what to expect. > So in my view the client/agent should read the data from the connection > buffers and do something with it. If not discard it then what? > > I agree with you on one point: we need a precise definition about when > Netconf connection enters and leaves notification mode. This should be > described both for the agent and the manager. What exact edits are you proposing? > Balazs > Andy > Phil Shafer wrote: >> Balazs Lengyel writes: >>> [BALAZS]: I think the manager should assume that anything it sent >>> before receiving replayComplete will be discarded. >> >> You can't make specs out of assumptions and living dangerously. You >> need "MUST"s and "MUST NOT"s. Otherwise, code that works against one >> conforming implementation will fail against another and no one will >> be clearly at fault. >> >>> You can still have a situation when the rpc request and >>> replayComplete are sent at the same time, but if you like to live >>> dangerously better have a timeout on the request. >> >> A timeout won't close the timing window that you've opened, it will just >> introduce another, possibly worse, one, since you have no idea how long >> any RPC will take. > [BALAZS]: Timeout was brought up by Andy as I remember. >> >>> As I see it discarding all requests is the best defined behavior we >>> can prescribe. >> >> Discarding leaves you with simlar questions: >> - how will the server know when to stop discarding? > [BALAZS]: start discarding after the create-subscription was replied > with OK. Stop discarding after the replayComplete was sent. >> - how will the client know what was discarded? > [BALAZS]: It should not send anything after create-subscription until > the replayComplete or create-subscription-error is received. If it still > does send something we are in the gray area. The client must be prepared > for lost rpc-requests. >> >> So the facts seem to be: >> (a) the client can put the connection into "notification" mode >> (b) the server can put the connection into "rpc" mode >> There's no way the server can discard content from the client, since >> it has no idea whether the content pre-dates the switch back into >> "rpc" mode. >> >> So is it worth _not_ allowing the server to put the connection >> back into "rpc" mode? > [BALAZS]: I can live with something like a tear_down of the connection, > although an unusable connection left dangling is something I would not > like. >> >> Thanks, >> Phil > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 16 13:36:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUUb-0003IG-IC for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 13:36:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAUUW-0004IO-W0 for netconf-archive@lists.ietf.org; Mon, 16 Jul 2007 13:36:17 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAUN0-0008Nv-0F for netconf-data@psg.com; Mon, 16 Jul 2007 17:28:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAUMe-0008Li-Ku for netconf@ops.ietf.org; Mon, 16 Jul 2007 17:28:10 +0000 Received: from pc6 (1Cust54.tnt6.lnd4.gbr.da.uu.net [62.188.135.54]) by blaster.systems.pipex.net (Postfix) with SMTP id 625EBE000567; Mon, 16 Jul 2007 18:27:53 +0100 (BST) Message-ID: <047201c7c7c5$94d7bdc0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: Cc: References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> Subject: roots wasRe: filtering problem Date: Mon, 16 Jul 2007 18:16:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 This may relate to something that has been bugging me. XPath is - at times - specified in terms of a root, and an XML document has a single root element. What is on the wire is an XML document but the datastore is not - as Andy has pointed out before. So what is an XPath filter being applied to? The event as it would appear on the wire as an XML document? A conceptual document created in the datastore for the purposes of filtering? And if the latter, should we - we should! - specify a root, either for the purposes of the examples or else for everything. RFC4741 is quite discursive about roots but the notification I-D is silent; I think that this last needs to change. Tom Petch ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Friday, July 13, 2007 4:43 PM Subject: Re: filtering problem > Andy Bierman wrote: > > Hi, > > > > There is another problem with filtering and the examples in sec 5: (!!!) > > > > The draft must say exactly where in the element > > that the is applied. The current text does not say anything. > > Agreed. > > > All the examples in sec. 5 are broken because the 'notification type' > > layer is missing. > > I think it is ok. Specify that the filter is applied to the > 'notificationContent' element as root (which is the abstract element). > > > The examples assume the filters can only be > > applied to a conceptual datastore, just like the filter. > > > > However, the most commonly needed filter is going to be > > on the notification type itself! > > > > Example (w/o namespaces): > > > > > > > > date-time string... > > fred@example.com > > /interfaces/interface[name='eth0'] > > ... > > > > > > > > For simplicity, assume the manager just wants > > this one notification type. The filter is going to be something like: > > > > > > > > > > Yes, and IMO this is consistent with the examples. > > > /martin > > > > > A filter for configChange just on a specific configTarget might be: > > > > > > > > /interfaces/interface[name='eth0'] > > > > > > > > The way the draft is now does not reflect how notifications are > > actually structured. > > > > > > Andy > > > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 17 06:49:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkcu-0005bw-Um for netconf-archive@lists.ietf.org; Tue, 17 Jul 2007 06:49:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAkcq-0001YT-7I for netconf-archive@lists.ietf.org; Tue, 17 Jul 2007 06:49:56 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAkVE-000Jre-BK for netconf-data@psg.com; Tue, 17 Jul 2007 10:42:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAkV2-000Jr4-AW for netconf@ops.ietf.org; Tue, 17 Jul 2007 10:41:54 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2C94721C05 for ; Tue, 17 Jul 2007 12:41:46 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-9a-469c9ceacd55 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 120A221546 for ; Tue, 17 Jul 2007 12:41:46 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:41: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, 17 Jul 2007 12:41:45 +0200 Message-ID: <469C9CE9.5090209@ericsson.com> Date: Tue, 17 Jul 2007 12:41:45 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Questions on Confirmed commit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 10:41:45.0578 (UTC) FILETIME=[122DACA0:01C7C85F] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hello, What happens in the following sequence: 1) Operator A modifies the candidate datastore 2) Operator A successfully uses confirmed commit on candidate 3) Operator B successfully locks the running datastore 4) The confirmed commit times out 5a) The locked running datastore is reverted to the previous version even though it's locked 5b) Nothing as due to the locked the running datastore can not be changed ------------------------------------------------ When the node revert it's configuration due to an expired confirmed commit will it restore the candidate datastore. to it's previous state as well or only the running datastore? ------------------------------------------------ The base RFC state the manager can explicitly restore the configuration to its state before the confirmed commit was issued. How? 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 Jul 19 02:57:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPxX-0004rE-7H for netconf-archive@lists.ietf.org; Thu, 19 Jul 2007 02:57:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBPxV-0004Ug-Sp for netconf-archive@lists.ietf.org; Thu, 19 Jul 2007 02:57:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBPpt-000Ezs-UN for netconf-data@psg.com; Thu, 19 Jul 2007 06:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.8 Received: from [210.138.20.174] (helo=otm-mgo00.iij.ad.jp) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBPpi-000ExV-OG for netconf@ops.ietf.org; Thu, 19 Jul 2007 06:50:00 +0000 Received: OTM-MO(otm-mgo00) id l6J6nhKE096585; Thu, 19 Jul 2007 15:49:43 +0900 (JST) Received: OTM-MIX(otm-mix01) id l6J6nhcM004611; Thu, 19 Jul 2007 15:49:43 +0900 (JST) Received: from [192.168.190.102] (h102n190.iij.ad.jp [192.168.190.102]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l6J6ngKG067052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2007 15:49:43 +0900 (JST) Message-ID: <469F0987.3000506@iijlab.net> Date: Thu, 19 Jul 2007 15:49:43 +0900 From: "Ray S. Atarashi" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ngo@ietf.org, netconf@ops.ietf.org, netconfmodel@lists.nortel.com Subject: Submitted I-Ds Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi, We submitted five I-Ds related detamodel. Please read and give us comments. SOAP impementation http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementation-02.txt ACL datamodel http://www.ietf.org/internet-drafts/draft-iijima-ngo-acldatamodel-00.txt VLAN datamodel http://www.ietf.org/internet-drafts/draft-iijima-ngo-vlandatamodel-00.txt Diff-serv datamodel http://www.ietf.org/internet-drafts/draft-okita-ngo-diffservdatamodel-01.txt Consideration of Architecture http://www.ietf.org/internet-drafts/draft-atarashi-ngo-consider-architecture-01.txt See you in Chicago! Ray -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jul 19 11:23:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXr0-0004Be-IB for netconf-archive@lists.ietf.org; Thu, 19 Jul 2007 11:23:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBXqz-0001F9-3e for netconf-archive@lists.ietf.org; Thu, 19 Jul 2007 11:23:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBXi6-0008bV-5A for netconf-data@psg.com; Thu, 19 Jul 2007 15:14:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBXhl-0008YZ-Rf for netconf@ops.ietf.org; Thu, 19 Jul 2007 15:14:20 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2964F20710; Thu, 19 Jul 2007 17:14:09 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-6c-469f7fc1124a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0A482205B2; Thu, 19 Jul 2007 17:14:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 17:14:08 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 17:14:08 +0200 Message-ID: <469F7FBF.3080009@ericsson.com> Date: Thu, 19 Jul 2007 17:14:07 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "tom.petch" CC: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> In-Reply-To: <047201c7c7c5$94d7bdc0$0601a8c0@pc6> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 15:14:08.0458 (UTC) FILETIME=[741EC2A0:01C7CA17] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Hello, I think the datastore will often have multiple roots. I foresee/have heard of the following situations that as I understand are all valid in Netconf: 1) One root in one namespace, other namespaces might be mounted as subtrees 2) One root per namespace 3) One namespace but with many root elements 4) Many roots in many namespaces Case 2 can be viewed as a the single rooted case 1) where the first branching is according to the namespace. Case 3) and 4) I feel the filter should be applied to each root and the results of these combined under the element in the get/get-config reply. Comments? Balazs tom.petch wrote: > This may relate to something that has been bugging me. > > XPath is - at times - specified in terms of a root, and an XML document has a > single root element. What is on the wire is an XML document but the datastore > is not - as Andy has pointed out before. > > So what is an XPath filter being applied to? The event as it would appear on > the wire as an XML document? A conceptual document created in the datastore for > the purposes of filtering? And if the latter, should we - we should! - specify > a root, either for the purposes of the examples or else for everything. > > RFC4741 is quite discursive about roots but the notification I-D is silent; I > think that this last needs to change. > > Tom Petch > > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Friday, July 13, 2007 4:43 PM > Subject: Re: filtering problem > > >> Andy Bierman wrote: >>> Hi, >>> >>> There is another problem with filtering and the examples in sec 5: (!!!) >>> >>> The draft must say exactly where in the element >>> that the is applied. The current text does not say anything. >> Agreed. >> >>> All the examples in sec. 5 are broken because the 'notification type' >>> layer is missing. >> I think it is ok. Specify that the filter is applied to the >> 'notificationContent' element as root (which is the abstract element). >> >>> The examples assume the filters can only be >>> applied to a conceptual datastore, just like the filter. >>> >>> However, the most commonly needed filter is going to be >>> on the notification type itself! >>> >>> Example (w/o namespaces): >>> >>> >>> >>> date-time string... >>> fred@example.com >>> /interfaces/interface[name='eth0'] >>> ... >>> >>> >>> >>> For simplicity, assume the manager just wants >>> this one notification type. The filter is going to be something like: >>> >>> >>> >>> >> Yes, and IMO this is consistent with the examples. >> >> >> /martin >> >> >> >>> A filter for configChange just on a specific configTarget might be: >>> >>> >>> >>> /interfaces/interface[name='eth0'] >>> >>> >>> >>> The way the draft is now does not reflect how notifications are >>> actually structured. >>> >>> >>> Andy >>> >>> >>> >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 20 01:27:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBl1v-0006KC-BD for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 01:27:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBl1t-00050c-Rh for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 01:27:55 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBkuw-000C1f-GF for netconf-data@psg.com; Fri, 20 Jul 2007 05:20:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [204.127.192.81] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBkul-000C1D-9K for netconf@ops.ietf.org; Fri, 20 Jul 2007 05:20:36 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc11) with SMTP id <20070720052030m1100514h7e>; Fri, 20 Jul 2007 05:20:30 +0000 From: "David B Harrington" To: "'Balazs Lengyel'" , "'tom.petch'" Cc: , References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> Subject: RE: roots wasRe: filtering problem Date: Fri, 20 Jul 2007 01:20:12 -0400 Message-ID: <01fd01c7ca8d$a6c4bfe0$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 Thread-Index: AcfKGMxcEMQimu7CSOKCHIB86cVOBgAdK3OQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <469F7FBF.3080009@ericsson.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 I think we need one root, so a get-config will be able to include everything. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Thursday, July 19, 2007 11:14 AM > To: tom.petch > Cc: ietf@andybierman.com; netconf@ops.ietf.org > Subject: Re: roots wasRe: filtering problem > > Hello, > I think the datastore will often have multiple roots. I > foresee/have heard of the following > situations that as I understand are all valid in Netconf: > 1) One root in one namespace, other namespaces might be > mounted as subtrees > 2) One root per namespace > 3) One namespace but with many root elements > 4) Many roots in many namespaces > > Case 2 can be viewed as a the single rooted case 1) where the > first branching is according to > the namespace. > > Case 3) and 4) I feel the filter should be applied to each > root and the results of these > combined under the element in the get/get-config reply. > > Comments? > > Balazs > > tom.petch wrote: > > This may relate to something that has been bugging me. > > > > XPath is - at times - specified in terms of a root, and an > XML document has a > > single root element. What is on the wire is an XML > document but the datastore > > is not - as Andy has pointed out before. > > > > So what is an XPath filter being applied to? The event as > it would appear on > > the wire as an XML document? A conceptual document created > in the datastore for > > the purposes of filtering? And if the latter, should we - > we should! - specify > > a root, either for the purposes of the examples or else for > everything. > > > > RFC4741 is quite discursive about roots but the > notification I-D is silent; I > > think that this last needs to change. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Friday, July 13, 2007 4:43 PM > > Subject: Re: filtering problem > > > > > >> Andy Bierman wrote: > >>> Hi, > >>> > >>> There is another problem with filtering and the examples > in sec 5: (!!!) > >>> > >>> The draft must say exactly where in the element > >>> that the is applied. The current text does not > say anything. > >> Agreed. > >> > >>> All the examples in sec. 5 are broken because the > 'notification type' > >>> layer is missing. > >> I think it is ok. Specify that the filter is applied to the > >> 'notificationContent' element as root (which is the > abstract element). > >> > >>> The examples assume the filters can only be > >>> applied to a conceptual datastore, just like the filter. > >>> > >>> However, the most commonly needed filter is going to be > >>> on the notification type itself! > >>> > >>> Example (w/o namespaces): > >>> > >>> > >>> > >>> date-time string... > >>> fred@example.com > >>> > /interfaces/interface[name='eth0'] > >>> ... > >>> > >>> > >>> > >>> For simplicity, assume the manager just wants > >>> this one notification type. The filter is going to be > something like: > >>> > >>> > >>> > >>> > >> Yes, and IMO this is consistent with the examples. > >> > >> > >> /martin > >> > >> > >> > >>> A filter for configChange just on a specific configTarget > might be: > >>> > >>> > >>> > >>> > /interfaces/interface[name='eth0'] > >>> > >>> > >>> > >>> The way the draft is now does not reflect how notifications are > >>> actually structured. > >>> > >>> > >>> Andy > >>> > >>> > >>> > >>> > >>> -- > >>> to unsubscribe send a message to netconf-request@ops.ietf.org with > >>> the word 'unsubscribe' in a single line as the message text body. > >>> archive: > >>> > >> -- > >> to unsubscribe send a message to netconf-request@ops.ietf.org with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 20 01:44:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBlHo-0000Il-2k for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 01:44:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBlHn-0005Ip-NH for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 01:44:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBlD6-000DNn-2I for netconf-data@psg.com; Fri, 20 Jul 2007 05:39:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.89] (helo=smtp116.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBlCt-000DKy-5w for netconf@ops.ietf.org; Fri, 20 Jul 2007 05:39:22 +0000 Received: (qmail 8474 invoked from network); 20 Jul 2007 05:39:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.201.126.176 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 20 Jul 2007 05:39:13 -0000 X-YMail-OSG: uDENNd4VM1n9Vw_iTghFZZx70RawFOz_b.tkOWmJYnnftdU3 Message-ID: <46A04A2C.3030706@andybierman.com> Date: Thu, 19 Jul 2007 22:37:48 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: 'Balazs Lengyel' , "'tom.petch'" , netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <01fd01c7ca8d$a6c4bfe0$0600a8c0@china.huawei.com> In-Reply-To: <01fd01c7ca8d$a6c4bfe0$0600a8c0@china.huawei.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.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 David B Harrington wrote: > I think we need one root, so a get-config will be able to include > everything. We already have this capability. If or has no filter, then it will return everything. Since the XML document starts with and all the returned DM nodes are rooted at level 3, under , there is no XML problem. The answer XML already supports is (4) - many NS, many roots. Anything else would be a Clever Little Restriction that the WG would be inventing. But standard data models should not follow the same ad-hoc design as vendors. A manager should expect any nodes within the to use namespaces and process them correctly. In addition, the IETF might want to impose some structure on the standard conceptual data model, and perhaps even plan ahead for more data model modules in the future, developed by other WGs. > > David Harrington 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 Jul 20 05:33:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBor8-0000tP-Vq for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 05:33:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBor7-00029D-FS for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 05:33:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBoiS-00066C-8k for netconf-data@psg.com; Fri, 20 Jul 2007 09:24:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBoiG-00065P-6I for netconf@ops.ietf.org; Fri, 20 Jul 2007 09:23:58 +0000 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jul 2007 11:23:51 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFsboEaQ/uCLZmdsb2JhbACPTwsKJA X-IronPort-AV: i="4.16,562,1175464800"; d="scan'208"; a="148557064:sNHT608069596" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6K9NoDE025830; Fri, 20 Jul 2007 11:23:50 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6K9Njkt004990; Fri, 20 Jul 2007 09:23:46 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 11:23:45 +0200 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: roots wasRe: filtering problem Date: Fri, 20 Jul 2007 11:23:45 +0200 Message-ID: <991411C8E365AB4199C60DA70B3B063D06AB82@xmb-ams-33d.emea.cisco.com> In-Reply-To: <01fd01c7ca8d$a6c4bfe0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: roots wasRe: filtering problem Thread-Index: AcfKGMxcEMQimu7CSOKCHIB86cVOBgAdK3OQAAgeNSA= References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <01fd01c7ca8d$a6c4bfe0$0600a8c0@china.huawei.com> From: "Vincent Cridlig \(vcridlig\)" To: "David B Harrington" , "Balazs Lengyel" , "tom.petch" Cc: , X-OriginalArrivalTime: 20 Jul 2007 09:23:45.0809 (UTC) FILETIME=[AC0ED810:01C7CAAF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6444; t=1184923430; x=1185787430; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vcridlig@cisco.com; z=From:=20=22Vincent=20Cridlig=20\(vcridlig\)=22=20 |Subject:=20RE=3A=20roots=20wasRe=3A=20filtering=20problem |Sender:=20; bh=MRg8+95weuSQSARDqc7Dkh9VfUTiJ4A74e7iC8Xyxso=; b=g5XGMZklLkI15VbjQr6JNMoopprhkSmv1Rsu4kL5FieEUMBAzdumGxV/BzXiMY1Aa2/a0V2G jMKdO1a3p8Et28RSa0IQ2Dx/nljeWUQmWmjeiAEV2vcwHZ3OIbT4Fodu; Authentication-Results: ams-dkim-2; header.From=vcridlig@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 I also think one root including mounted subtrees for various namespaces is better than concatenated multiple roots. These multiple roots can become children of a main root in any case. Otherwise filters will have to apply to many roots, rather than one. How do you build the reply in case nodes from various roots are selected...? This can happen when namespaces are reused in various data models to include data following a generic structure. In Xpath, one missing thing IMO is how is built the reply after an Xpath get-request. Xpath result is always a node set. Is the reply a concatenation of the result nodes, or is it a reconstructed document containing the selected nodes? I don't think this is a data model dependant question. This aspect is defined in the case of subtree filtering and it should be defined also for Xpath. Regards, Vincent -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington Sent: vendredi 20 juillet 2007 7:20 To: 'Balazs Lengyel'; 'tom.petch' Cc: ietf@andybierman.com; netconf@ops.ietf.org Subject: RE: roots wasRe: filtering problem I think we need one root, so a get-config will be able to include everything. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Thursday, July 19, 2007 11:14 AM > To: tom.petch > Cc: ietf@andybierman.com; netconf@ops.ietf.org > Subject: Re: roots wasRe: filtering problem >=20 > Hello, > I think the datastore will often have multiple roots. I foresee/have=20 > heard of the following situations that as I understand are all valid=20 > in Netconf: > 1) One root in one namespace, other namespaces might be mounted as=20 > subtrees > 2) One root per namespace > 3) One namespace but with many root elements > 4) Many roots in many namespaces >=20 > Case 2 can be viewed as a the single rooted case 1) where the first=20 > branching is according to the namespace. >=20 > Case 3) and 4) I feel the filter should be applied to each root and=20 > the results of these combined under the element in the=20 > get/get-config reply. >=20 > Comments? >=20 > Balazs >=20 > tom.petch wrote: > > This may relate to something that has been bugging me. > >=20 > > XPath is - at times - specified in terms of a root, and an > XML document has a > > single root element. What is on the wire is an XML > document but the datastore > > is not - as Andy has pointed out before. > >=20 > > So what is an XPath filter being applied to? The event as > it would appear on > > the wire as an XML document? A conceptual document created > in the datastore for > > the purposes of filtering? And if the latter, should we - > we should! - specify > > a root, either for the purposes of the examples or else for > everything. > >=20 > > RFC4741 is quite discursive about roots but the > notification I-D is silent; I > > think that this last needs to change. > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Friday, July 13, 2007 4:43 PM > > Subject: Re: filtering problem > >=20 > >=20 > >> Andy Bierman wrote: > >>> Hi, > >>> > >>> There is another problem with filtering and the examples > in sec 5: (!!!) > >>> > >>> The draft must say exactly where in the element=20 > >>> that the is applied. The current text does not > say anything. > >> Agreed. > >> > >>> All the examples in sec. 5 are broken because the > 'notification type' > >>> layer is missing. > >> I think it is ok. Specify that the filter is applied to the=20 > >> 'notificationContent' element as root (which is the > abstract element). > >> > >>> The examples assume the filters can only be applied to a=20 > >>> conceptual datastore, just like the filter. > >>> > >>> However, the most commonly needed filter is going to be on the=20 > >>> notification type itself! > >>> > >>> Example (w/o namespaces): > >>> > >>> > >>> > >>> date-time string... > >>> fred@example.com > >>> =20 > /interfaces/interface[name=3D'eth0'] > >>> ... > >>> > >>> > >>> > >>> For simplicity, assume the manager just wants this one=20 > >>> notification type. The filter is going to be > something like: > >>> > >>> > >>> > >>> > >> Yes, and IMO this is consistent with the examples. > >> > >> > >> /martin > >> > >> > >> > >>> A filter for configChange just on a specific configTarget > might be: > >>> > >>> > >>> > >>> =20 > /interfaces/interface[name=3D'eth0'] > >>> > >>> > >>> > >>> The way the draft is now does not reflect how notifications are=20 > >>> actually structured. > >>> > >>> > >>> 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: > >=20 > >=20 > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with=20 > > 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: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 20 11:12:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBu9V-0003Iw-M4 for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 11:12:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBu9U-00011m-75 for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 11:12:21 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBu1q-000Kx3-IM for netconf-data@psg.com; Fri, 20 Jul 2007 15:04:26 +0000 Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBu1k-000Kvu-3l for netconf@ops.ietf.org; Fri, 20 Jul 2007 15:04:26 +0000 Received: (qmail 45078 invoked from network); 20 Jul 2007 15:04:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.201.126.176 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2007 15:04:18 -0000 X-YMail-OSG: Sm8tRf0VM1ni5nL3wc.MORylSSUv0S8FT_2Dfvu04BVk8AJ5h_Mh7haoTWy6konwAiyCtdy7aZjVJ8JO4CXCF4OfVw-- Message-ID: <46A0CE9C.1090104@andybierman.com> Date: Fri, 20 Jul 2007 08:02:52 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Vincent Cridlig (vcridlig)" CC: David B Harrington , Balazs Lengyel , "tom.petch" , netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <01fd01c7ca8d$a6c4bfe0$0600a8c0@china.huawei.com> <991411C8E365AB4199C60DA70B3B063D06AB82@xmb-ams-33d.emea.cisco.com> In-Reply-To: <991411C8E365AB4199C60DA70B3B063D06AB82@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Vincent Cridlig (vcridlig) wrote: > I also think one root including mounted subtrees for various namespaces > is better than concatenated multiple roots. These multiple roots can > become children of a main root in any case. > Otherwise filters will have to apply to many roots, rather than one. How > do you build the reply in case nodes from various roots are selected...? > This can happen when namespaces are reused in various data models to > include data following a generic structure. > Think about what this means. Let's say there is a top-level element everybody is forced to use, called , in the NETCONF base namespace. Every vendor would need to change every agent and every manager to support this change. NETCONF is supposed to be content-independent. This doesn't seem so independent. All vendor and even all IETF data model objects are going to be in different namespaces, so the child nodes of are all the nodes that would have appeared in or , accept moved down one extra XML layer. It doesn't change the filtering mechanism at all. (This is the XML equivalent of the Spinal Tap moment - "But this amp goes to 11"). The real problem that exists (if any), is the lack of a consistent XML container for output. I use the element in the NETCONF base namespace for this purpose. It doesn't matter so much what the QName value is for this top-level container, but there does need to be one. It ensures the output will be valid XML, even if multiple data models from vendors and the IETF exist in the agent. > In Xpath, one missing thing IMO is how is built the reply after an Xpath > get-request. Xpath result is always a node set. Is the reply a > concatenation of the result nodes, or is it a reconstructed document > containing the selected nodes? I don't think this is a data model > dependant question. This aspect is defined in the case of subtree > filtering and it should be defined also for Xpath. > > Regards, > Vincent Andy > > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of David B Harrington > Sent: vendredi 20 juillet 2007 7:20 > To: 'Balazs Lengyel'; 'tom.petch' > Cc: ietf@andybierman.com; netconf@ops.ietf.org > Subject: RE: roots wasRe: filtering problem > > I think we need one root, so a get-config will be able to include > everything. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel >> Sent: Thursday, July 19, 2007 11:14 AM >> To: tom.petch >> Cc: ietf@andybierman.com; netconf@ops.ietf.org >> Subject: Re: roots wasRe: filtering problem >> >> Hello, >> I think the datastore will often have multiple roots. I foresee/have >> heard of the following situations that as I understand are all valid >> in Netconf: >> 1) One root in one namespace, other namespaces might be mounted as >> subtrees >> 2) One root per namespace >> 3) One namespace but with many root elements >> 4) Many roots in many namespaces >> >> Case 2 can be viewed as a the single rooted case 1) where the first >> branching is according to the namespace. >> >> Case 3) and 4) I feel the filter should be applied to each root and >> the results of these combined under the element in the >> get/get-config reply. >> >> Comments? >> >> Balazs >> >> tom.petch wrote: >>> This may relate to something that has been bugging me. >>> >>> XPath is - at times - specified in terms of a root, and an >> XML document has a >>> single root element. What is on the wire is an XML >> document but the datastore >>> is not - as Andy has pointed out before. >>> >>> So what is an XPath filter being applied to? The event as >> it would appear on >>> the wire as an XML document? A conceptual document created >> in the datastore for >>> the purposes of filtering? And if the latter, should we - >> we should! - specify >>> a root, either for the purposes of the examples or else for >> everything. >>> RFC4741 is quite discursive about roots but the >> notification I-D is silent; I >>> think that this last needs to change. >>> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Martin Bjorklund" >>> To: >>> Cc: >>> Sent: Friday, July 13, 2007 4:43 PM >>> Subject: Re: filtering problem >>> >>> >>>> Andy Bierman wrote: >>>>> Hi, >>>>> >>>>> There is another problem with filtering and the examples >> in sec 5: (!!!) >>>>> The draft must say exactly where in the element >>>>> that the is applied. The current text does not >> say anything. >>>> Agreed. >>>> >>>>> All the examples in sec. 5 are broken because the >> 'notification type' >>>>> layer is missing. >>>> I think it is ok. Specify that the filter is applied to the >>>> 'notificationContent' element as root (which is the >> abstract element). >>>>> The examples assume the filters can only be applied to a >>>>> conceptual datastore, just like the filter. >>>>> >>>>> However, the most commonly needed filter is going to be on the >>>>> notification type itself! >>>>> >>>>> Example (w/o namespaces): >>>>> >>>>> >>>>> >>>>> date-time string... >>>>> fred@example.com >>>>> >> /interfaces/interface[name='eth0'] >>>>> ... >>>>> >>>>> >>>>> >>>>> For simplicity, assume the manager just wants this one >>>>> notification type. The filter is going to be >> something like: >>>>> >>>>> >>>>> >>>> Yes, and IMO this is consistent with the examples. >>>> >>>> >>>> /martin >>>> >>>> >>>> >>>>> A filter for configChange just on a specific configTarget >> might be: >>>>> >>>>> >>>>> >> /interfaces/interface[name='eth0'] >>>>> >>>>> >>>>> >>>>> The way the draft is now does not reflect how notifications are >>>>> actually structured. >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> to unsubscribe send a message to netconf-request@ops.ietf.org > with >>>>> the word 'unsubscribe' in a single line as the message text > body. >>>>> archive: >>>>> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org > with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the > >> word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 20 11:55:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBupJ-0007O4-63 for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 11:55:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBupH-0001vQ-TA for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 11:55:33 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBujm-0000Pv-NM for netconf-data@psg.com; Fri, 20 Jul 2007 15:49:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBuja-0000PC-Dr for netconf@ops.ietf.org; Fri, 20 Jul 2007 15:49:44 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jul 2007 17:49:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMJ2oEaQ/uCKh2dsb2JhbACPUQEBCQon X-IronPort-AV: i="4.16,563,1175464800"; d="scan'208"; a="148604606:sNHT729771356" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6KFnYn5032036; Fri, 20 Jul 2007 17:49:34 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6KFnTkt008872; Fri, 20 Jul 2007 15:49:29 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 17:49:29 +0200 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: roots wasRe: filtering problem Date: Fri, 20 Jul 2007 17:49:28 +0200 Message-ID: <991411C8E365AB4199C60DA70B3B063D06AB87@xmb-ams-33d.emea.cisco.com> In-Reply-To: <46A0CE9C.1090104@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: roots wasRe: filtering problem Thread-Index: AcfK31BzeMu2OdIORw2vVNH95/mPhwAA9fpg References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <01fd01c7ca8d$a6c4bfe0$0600a8c0@china.huawei.com> <991411C8E365AB4199C60DA70B3B063D06AB82@xmb-ams-33d.emea.cisco.com> <46A0CE9C.1090104@andybierman.com> From: "Vincent Cridlig \(vcridlig\)" To: "Andy Bierman" Cc: "David B Harrington" , "Balazs Lengyel" , "tom.petch" , X-OriginalArrivalTime: 20 Jul 2007 15:49:29.0129 (UTC) FILETIME=[8E8D3990:01C7CAE5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9316; t=1184946574; x=1185810574; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vcridlig@cisco.com; z=From:=20=22Vincent=20Cridlig=20\(vcridlig\)=22=20 |Subject:=20RE=3A=20roots=20wasRe=3A=20filtering=20problem |Sender:=20; bh=s/Hei5w91CC7ds++rvryLH99AcQ4kFMhIV1lg86H6f4=; b=Ir0AMkaF9zSkBJ8M/k0VPEXbylLE6ugQcSrqrS6bB6/50LLS+lW2kytwixGR1UM5aGwqkX6l q3cCa9tzgdr8Ehtrfc4halUctHdZCEf/EpGWHq+/HC5bjFIfx0YAAiEZ; Authentication-Results: ams-dkim-1; header.From=vcridlig@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Well, ok but=20 - if I send a get-config to your agent and I need to validate it on the manager side, or - if I build a config on the manager side and I want to validate it before sending,=20 I will also need to append a root node before validation, that in any case need to be defined in the data model schema. Now that I think about it, you can validate any individual root separately...=20 This does not seem very natural to me. A root would remove the need to append a "config" for copy-config as you pointed out. I might be wrong, but it seems to me that, in most XML implementations, creating a root node and appending multiple child subtrees from other XML documents will be a pain and very costly, because you need to change the document owner of every nodes to have a consistent document. Some API may make it easier but, IMHO, it would be so much more simple to add a root. I understand your point with the consequences of such a change. Maybe, we could just *recommend* that the data model defines a root node. This is not a killing issue. My 2 cents. Vincent -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: vendredi 20 juillet 2007 17:03 To: Vincent Cridlig (vcridlig) Cc: David B Harrington; Balazs Lengyel; tom.petch; netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem Vincent Cridlig (vcridlig) wrote: > I also think one root including mounted subtrees for various=20 > namespaces is better than concatenated multiple roots. These multiple=20 > roots can become children of a main root in any case. > Otherwise filters will have to apply to many roots, rather than one.=20 > How do you build the reply in case nodes from various roots are selected...? > This can happen when namespaces are reused in various data models to=20 > include data following a generic structure. >=20 Think about what this means. Let's say there is a top-level element everybody is forced to use, called , in the NETCONF base namespace. Every vendor would need to change every agent and every manager to support this change. NETCONF is supposed to be content-independent. This doesn't seem so independent. All vendor and even all IETF data model objects are going to be in different namespaces, so the child nodes of are all the nodes that would have appeared in or , accept moved down one extra XML layer. It doesn't change the filtering mechanism at all. (This is the XML equivalent of the Spinal Tap moment - "But this amp goes to 11"). The real problem that exists (if any), is the lack of a consistent XML container for output. I use the element in the NETCONF base namespace for this purpose. It doesn't matter so much what the QName value is for this top-level container, but there does need to be one. It ensures the output will be valid XML, even if multiple data models from vendors and the IETF exist in the agent. > In Xpath, one missing thing IMO is how is built the reply after an=20 > Xpath get-request. Xpath result is always a node set. Is the reply a=20 > concatenation of the result nodes, or is it a reconstructed document=20 > containing the selected nodes? I don't think this is a data model=20 > dependant question. This aspect is defined in the case of subtree=20 > filtering and it should be defined also for Xpath. >=20 > Regards, > Vincent Andy >=20 >=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]=20 > On Behalf Of David B Harrington > Sent: vendredi 20 juillet 2007 7:20 > To: 'Balazs Lengyel'; 'tom.petch' > Cc: ietf@andybierman.com; netconf@ops.ietf.org > Subject: RE: roots wasRe: filtering problem >=20 > I think we need one root, so a get-config will be able to include=20 > everything. >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel >> Sent: Thursday, July 19, 2007 11:14 AM >> To: tom.petch >> Cc: ietf@andybierman.com; netconf@ops.ietf.org >> Subject: Re: roots wasRe: filtering problem >> >> Hello, >> I think the datastore will often have multiple roots. I foresee/have=20 >> heard of the following situations that as I understand are all valid=20 >> in Netconf: >> 1) One root in one namespace, other namespaces might be mounted as=20 >> subtrees >> 2) One root per namespace >> 3) One namespace but with many root elements >> 4) Many roots in many namespaces >> >> Case 2 can be viewed as a the single rooted case 1) where the first=20 >> branching is according to the namespace. >> >> Case 3) and 4) I feel the filter should be applied to each root and=20 >> the results of these combined under the element in the=20 >> get/get-config reply. >> >> Comments? >> >> Balazs >> >> tom.petch wrote: >>> This may relate to something that has been bugging me. >>> >>> XPath is - at times - specified in terms of a root, and an >> XML document has a >>> single root element. What is on the wire is an XML >> document but the datastore >>> is not - as Andy has pointed out before. >>> >>> So what is an XPath filter being applied to? The event as >> it would appear on >>> the wire as an XML document? A conceptual document created >> in the datastore for >>> the purposes of filtering? And if the latter, should we - >> we should! - specify >>> a root, either for the purposes of the examples or else for >> everything. >>> RFC4741 is quite discursive about roots but the >> notification I-D is silent; I >>> think that this last needs to change. >>> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Martin Bjorklund" >>> To: >>> Cc: >>> Sent: Friday, July 13, 2007 4:43 PM >>> Subject: Re: filtering problem >>> >>> >>>> Andy Bierman wrote: >>>>> Hi, >>>>> >>>>> There is another problem with filtering and the examples >> in sec 5: (!!!) >>>>> The draft must say exactly where in the element=20 >>>>> that the is applied. The current text does not >> say anything. >>>> Agreed. >>>> >>>>> All the examples in sec. 5 are broken because the >> 'notification type' >>>>> layer is missing. >>>> I think it is ok. Specify that the filter is applied to the=20 >>>> 'notificationContent' element as root (which is the >> abstract element). >>>>> The examples assume the filters can only be applied to a=20 >>>>> conceptual datastore, just like the filter. >>>>> >>>>> However, the most commonly needed filter is going to be on the=20 >>>>> notification type itself! >>>>> >>>>> Example (w/o namespaces): >>>>> >>>>> >>>>> >>>>> date-time string... >>>>> fred@example.com >>>>> =20 >> /interfaces/interface[name=3D'eth0'] >>>>> ... >>>>> >>>>> >>>>> >>>>> For simplicity, assume the manager just wants this one=20 >>>>> notification type. The filter is going to be >> something like: >>>>> >>>>> >>>>> >>>> Yes, and IMO this is consistent with the examples. >>>> >>>> >>>> /martin >>>> >>>> >>>> >>>>> A filter for configChange just on a specific configTarget >> might be: >>>>> >>>>> >>>>> =20 >> /interfaces/interface[name=3D'eth0'] >>>>> >>>>> >>>>> >>>>> The way the draft is now does not reflect how notifications are=20 >>>>> actually structured. >>>>> >>>>> >>>>> 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=20 >>> 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=20 >> the >=20 >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >=20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org 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: >=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 Fri Jul 20 14:04:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwpr-0002w3-On for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 14:04:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBwpq-0004LX-VW for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 14:04:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBwjy-000GR0-CD for netconf-data@psg.com; Fri, 20 Jul 2007 17:58:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBwjm-000GQ8-Os for netconf@ops.ietf.org; Fri, 20 Jul 2007 17:58:04 +0000 Received: from pc6 (1Cust28.tnt30.lnd3.gbr.da.uu.net [62.188.122.28]) by astro.systems.pipex.net (Postfix) with SMTP id E3BE0E000072; Fri, 20 Jul 2007 18:57:45 +0100 (BST) Message-ID: <001801c7caee$68279440$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Balazs Lengyel" Cc: , References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> Subject: Re: roots wasRe: filtering problem Date: Fri, 20 Jul 2007 18:47:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd ----- Original Message ----- From: "Balazs Lengyel" To: "tom.petch" Cc: ; Sent: Thursday, July 19, 2007 5:14 PM Subject: Re: roots wasRe: filtering problem > Hello, > I think the datastore will often have multiple roots. I foresee/have heard of the following > situations that as I understand are all valid in Netconf: > 1) One root in one namespace, other namespaces might be mounted as subtrees > 2) One root per namespace > 3) One namespace but with many root elements > 4) Many roots in many namespaces > > Case 2 can be viewed as a the single rooted case 1) where the first branching is according to > the namespace. > > Case 3) and 4) I feel the filter should be applied to each root and the results of these > combined under the element in the get/get-config reply. > > Comments? > Mmmm - even more complex than I thought. My initial concern was whether or not the Notifications, the draft in Last Call, were regarded for filtering purposes as part of the configuration datastore at all, or whether the filter was applied to the document as it would appear on the wire were it to pass a filter. Tom Petch > Balazs > > tom.petch wrote: > > This may relate to something that has been bugging me. > > > > XPath is - at times - specified in terms of a root, and an XML document has a > > single root element. What is on the wire is an XML document but the datastore > > is not - as Andy has pointed out before. > > > > So what is an XPath filter being applied to? The event as it would appear on > > the wire as an XML document? A conceptual document created in the datastore for > > the purposes of filtering? And if the latter, should we - we should! - specify > > a root, either for the purposes of the examples or else for everything. > > > > RFC4741 is quite discursive about roots but the notification I-D is silent; I > > think that this last needs to change. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Friday, July 13, 2007 4:43 PM > > Subject: Re: filtering problem > > > > > >> Andy Bierman wrote: > >>> Hi, > >>> > >>> There is another problem with filtering and the examples in sec 5: (!!!) > >>> > >>> The draft must say exactly where in the element > >>> that the is applied. The current text does not say anything. > >> Agreed. > >> > >>> All the examples in sec. 5 are broken because the 'notification type' > >>> layer is missing. > >> I think it is ok. Specify that the filter is applied to the > >> 'notificationContent' element as root (which is the abstract element). > >> > >>> The examples assume the filters can only be > >>> applied to a conceptual datastore, just like the filter. > >>> > >>> However, the most commonly needed filter is going to be > >>> on the notification type itself! > >>> > >>> Example (w/o namespaces): > >>> > >>> > >>> > >>> date-time string... > >>> fred@example.com > >>> /interfaces/interface[name='eth0'] > >>> ... > >>> > >>> > >>> > >>> For simplicity, assume the manager just wants > >>> this one notification type. The filter is going to be something like: > >>> > >>> > >>> > >>> > >> Yes, and IMO this is consistent with the examples. > >> > >> > >> /martin > >> > >> > >> > >>> A filter for configChange just on a specific configTarget might be: > >>> > >>> > >>> > >>> /interfaces/interface[name='eth0'] > >>> > >>> > >>> > >>> The way the draft is now does not reflect how notifications are > >>> actually structured. > >>> > >>> > >>> Andy > >>> > >>> > >>> > >>> > >>> -- > >>> to unsubscribe send a message to netconf-request@ops.ietf.org with > >>> the word 'unsubscribe' in a single line as the message text body. > >>> archive: > >>> > >> -- > >> to unsubscribe send a message to netconf-request@ops.ietf.org with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 20 14:13:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwyg-00034L-Sh for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 14:13:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBwyf-0004WM-H9 for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 14:13:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBwu6-000HW9-Di for netconf-data@psg.com; Fri, 20 Jul 2007 18:08:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.97] (helo=smtp124.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBwtv-000HVM-Ih for netconf@ops.ietf.org; Fri, 20 Jul 2007 18:08:33 +0000 Received: (qmail 59679 invoked from network); 20 Jul 2007 18:08:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.201.126.176 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 20 Jul 2007 18:08:26 -0000 X-YMail-OSG: mT7rv80VM1mjVoetXTWyrgHQSnVBMSZcUTj3UfiYigWsu0jn Message-ID: <46A0F9C5.50407@andybierman.com> Date: Fri, 20 Jul 2007 11:07:01 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: ad-hoc NETCONF prep meeting 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.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hi, Some WG members will be meeting at the message board in Chicago, at 10am on Monday, 7/23, then find a meeting room at 10:05. The agenda will be the notifications draft open issues list (still TBD). Attendance is open and optional. Any decisions made will be validated at the WG meeting on Tuesday, and then again on the WG mailing list. 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 Jul 20 14:20:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx5J-0007lu-E6 for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 14:20:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBx5I-0004fV-Jf for netconf-archive@lists.ietf.org; Fri, 20 Jul 2007 14:20:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBx0j-000Iqo-Q1 for netconf-data@psg.com; Fri, 20 Jul 2007 18:15:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [69.147.64.91] (helo=smtp118.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBx0Y-000Ioi-IO for netconf@ops.ietf.org; Fri, 20 Jul 2007 18:15:24 +0000 Received: (qmail 91247 invoked from network); 20 Jul 2007 18:15:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.201.126.176 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 20 Jul 2007 18:15:17 -0000 X-YMail-OSG: 0pqeuJwVM1n93Ooreow0sh0Qqetbf08.9GrYf6bzdjohGu6_1Pfj_9RFFtuTgHYJoqgNBGsGE3yspK8Wx7nRNzPm Message-ID: <46A0FB60.8000702@andybierman.com> Date: Fri, 20 Jul 2007 11:13:52 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" CC: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <001801c7caee$68279440$0601a8c0@pc6> In-Reply-To: <001801c7caee$68279440$0601a8c0@pc6> 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.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 tom.petch wrote: > ----- Original Message ----- > From: "Balazs Lengyel" > To: "tom.petch" > Cc: ; > Sent: Thursday, July 19, 2007 5:14 PM > Subject: Re: roots wasRe: filtering problem > > >> Hello, >> I think the datastore will often have multiple roots. I foresee/have heard of > the following >> situations that as I understand are all valid in Netconf: >> 1) One root in one namespace, other namespaces might be mounted as subtrees >> 2) One root per namespace >> 3) One namespace but with many root elements >> 4) Many roots in many namespaces >> >> Case 2 can be viewed as a the single rooted case 1) where the first branching > is according to >> the namespace. >> >> Case 3) and 4) I feel the filter should be applied to each root and the > results of these >> combined under the element in the get/get-config reply. >> >> Comments? >> > > Mmmm - even more complex than I thought. My initial concern was whether or not > the Notifications, the draft in Last Call, were regarded for filtering purposes > as part of the configuration datastore at all, or whether the filter was applied > to the document as it would appear on the wire were it to pass a filter. > This is the $64 question. When a element is provided in the , does it apply to the conceptual (internal) NETCONF database, or rather an XML instance document representing the database? (no) The examples seem to contradict text that says it works like . They show the filter is for the contents, starting at its one and only child node -- e.g., . The draft needs to specify the data root for the notification . > Tom Petch > >> Balazs Andy >> >> tom.petch wrote: >>> This may relate to something that has been bugging me. >>> >>> XPath is - at times - specified in terms of a root, and an XML document has > a >>> single root element. What is on the wire is an XML document but the > datastore >>> is not - as Andy has pointed out before. >>> >>> So what is an XPath filter being applied to? The event as it would appear > on >>> the wire as an XML document? A conceptual document created in the datastore > for >>> the purposes of filtering? And if the latter, should we - we should! - > specify >>> a root, either for the purposes of the examples or else for everything. >>> >>> RFC4741 is quite discursive about roots but the notification I-D is silent; > I >>> think that this last needs to change. >>> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Martin Bjorklund" >>> To: >>> Cc: >>> Sent: Friday, July 13, 2007 4:43 PM >>> Subject: Re: filtering problem >>> >>> >>>> Andy Bierman wrote: >>>>> Hi, >>>>> >>>>> There is another problem with filtering and the examples in sec 5: (!!!) >>>>> >>>>> The draft must say exactly where in the element >>>>> that the is applied. The current text does not say anything. >>>> Agreed. >>>> >>>>> All the examples in sec. 5 are broken because the 'notification type' >>>>> layer is missing. >>>> I think it is ok. Specify that the filter is applied to the >>>> 'notificationContent' element as root (which is the abstract element). >>>> >>>>> The examples assume the filters can only be >>>>> applied to a conceptual datastore, just like the filter. >>>>> >>>>> However, the most commonly needed filter is going to be >>>>> on the notification type itself! >>>>> >>>>> Example (w/o namespaces): >>>>> >>>>> >>>>> >>>>> date-time string... >>>>> fred@example.com >>>>> /interfaces/interface[name='eth0'] >>>>> ... >>>>> >>>>> >>>>> >>>>> For simplicity, assume the manager just wants >>>>> this one notification type. The filter is going to be something like: >>>>> >>>>> >>>>> >>>>> >>>> Yes, and IMO this is consistent with the examples. >>>> >>>> >>>> /martin >>>> >>>> >>>> >>>>> A filter for configChange just on a specific configTarget might be: >>>>> >>>>> >>>>> >>>>> /interfaces/interface[name='eth0'] >>>>> >>>>> >>>>> >>>>> The way the draft is now does not reflect how notifications are >>>>> actually structured. >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>> the word 'unsubscribe' in a single line as the message text body. >>>>> archive: >>>>> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 21 03:57:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC9pr-0006V1-W1 for netconf-archive@lists.ietf.org; Sat, 21 Jul 2007 03:57:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC9pq-0002XP-K7 for netconf-archive@lists.ietf.org; Sat, 21 Jul 2007 03:57:07 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IC9jB-0009Qd-UP for netconf-data@psg.com; Sat, 21 Jul 2007 07:50:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IC9j0-0009Nh-6W for netconf@ops.ietf.org; Sat, 21 Jul 2007 07:50:08 +0000 Received: from diotima (localhost [127.0.0.1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id l6L7nx14011836; Sat, 21 Jul 2007 09:49:59 +0200 (CEST) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18081.47783.157151.406476@switch.ch> Date: Sat, 21 Jul 2007 09:49:59 +0200 To: netconf@ops.ietf.org Subject: Looking for volunteer scribes for next Tuesday's meeting X-Mailer: VM 8.0.1-465 under Emacs 22.1.1 (sparc-sun-solaris2.11) X-Face:1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f If anybody is willing to take notes at the NETCONF meeting at the Chicago IETF (Tuesday 1740-1840), please contact me by mail, Jabber, or in person. (This would save us some time and/or embarrassment at the meeting :-) Thanks in advance, and see you in Chicago!(*) -- Simon. (*) For those who cannot make it, see http://videolab.uoregon.edu/events/ietf/ http://www.ietf.org/meetings/text_conf.html about technical support for remote participation. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jul 22 14:49:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICgV0-0003Jt-Bq for netconf-archive@lists.ietf.org; Sun, 22 Jul 2007 14:49:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICgUz-0002ku-4U for netconf-archive@lists.ietf.org; Sun, 22 Jul 2007 14:49:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ICgPN-000CTv-GQ for netconf-data@psg.com; Sun, 22 Jul 2007 18:43:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ICgPC-000CSv-QD for netconf@ops.ietf.org; Sun, 22 Jul 2007 18:43:52 +0000 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-outbound.avaya.com with ESMTP; 22 Jul 2007 14:43:44 -0400 X-IronPort-AV: i="4.16,569,1175486400"; d="scan'208"; a="45587348:sNHT8158908" 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: OPS Area Office Hours Date: Sun, 22 Jul 2007 20:43:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Office Hours Thread-Index: AcfMkCKQ0tfyT6lXQmasVB8laEJ8Wg== From: "Romascanu, Dan (Dan)" To: , , "Netconf (E-mail)" , , "Aaa-Doctors (E-mail)" , "Ops-Nm" , "capwap" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 I apologize for the cross-posting, which is definitely intentional in this case.=20 We remind everybody that the OPS Area Directors will be waiting for you to come at the office hours to discuss current and future work in the area and any other IETF related business.=20 The office hours will happen in the IESG meeting room PDR-4 (standing for Private Dining Room I guess) at the 3rd floor in the Palmer House and the schedule is as follows: Monday 9:00AM to 11:30AM Wednesday 4:10PM to 5:00PM Thursday 4:10PM to 5:00PM See you there.=20 Ron and Dan =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 25 13:18:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkUy-00008w-RL for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 13:18:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDkUa-0005xX-AJ for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 13:18:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDkKl-0002ba-E4 for netconf-data@psg.com; Wed, 25 Jul 2007 17:07:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.8 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDkKV-0002aQ-JV for netconf@ops.ietf.org; Wed, 25 Jul 2007 17:07:27 +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 l6PH7Fe01764 for ; Wed, 25 Jul 2007 17:07:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7CEDE.36CE1AD9" Subject: First pre-release of -09 Notifications Date: Wed, 25 Jul 2007 13:07:01 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41016D395@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: First pre-release of -09 Notifications Thread-Index: AcfO3jeNWJ3kJN1pRFC+MyEKP+okZw== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a77dc8c5997955bff6a04ad06fce70d This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CEDE.36CE1AD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Here is a partial update of the Notification draft with change bars from -08. I think in this afternoon's editing session, I'd like to start with the examples in section 5 since this seems to historically been tricky to get right. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada ------_=_NextPart_001_01C7CEDE.36CE1AD9 Content-Type: text/html; name="rfcdiff.pyht.htm" Content-Transfer-Encoding: base64 Content-Description: rfcdiff.pyht.htm Content-Disposition: attachment; filename="rfcdiff.pyht.htm" CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LTA4LnR4dCBuZXRjb25mX2V2ZW50X3ByZXJlbGVhc2UxLnR4dDwvdGl0bGU+PC9oZWFkPjxib2R5 Pgo8cHJlPgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFMuIENoaXNob2xtCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vcnRlbApJbnRlbmRlZCBzdGF0dXM6 IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIFRyZXZpbm8K RXhwaXJlczogSmFudWFyeSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjksPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MjYsPC9mb250Pjwvc3Ryb25nPiAyMDA4 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdWx5IDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+OCw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz4yNSw8L2ZvbnQ+PC9zdHJvbmc+IDIwMDcKCiAgICAgICAgICAgICAgICAg ICAgICBORVRDT05GIEV2ZW50IE5vdGlmaWNhdGlvbnMKICAgICAgICAgICA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPmRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tMDgudHh0LnByZS1y ZWxlYXNlPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29s b3I9J2dyZWVuJz5kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLTA5LXByZXJlbGVhc2Ux LnR4dDwvZm9udD48L3N0cm9uZz4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1Ym1pdHRp bmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQog ICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNo ZSBpcyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Yg d2hpY2ggaGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFj Y29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBG b3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhh dAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBh cyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAg IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50 eHQuCgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEphbnVhcnkgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz45LDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n PjI2LDwvZm9udD48L3N0cm9uZz4gMjAwOC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdo dCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBtZWNoYW5pc21zIHdoaWNoIHByb3ZpZGUgYW4gYXN5bmNocm9ub3VzCiAgIG1lc3Nh Z2Ugbm90aWZpY2F0aW9uIGRlbGl2ZXJ5IHNlcnZpY2UgZm9yIHRoZSBORVRDT05GIHByb3RvY29s LiAgVGhpcwogICBpcyBhbiBvcHRpb25hbCBjYXBhYmlsaXR5IGJ1aWx0IG9uIHRvcCBvZiB0aGUg YmFzZSBORVRDT05GCiAgIGRlZmluaXRpb24uICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGNh cGFiaWxpdGllcyBhbmQgb3BlcmF0aW9ucwogICBuZWNlc3NhcnkgdG8gc3VwcG9ydCB0aGlzIHNl cnZpY2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAgMS4xLiAgRGVm aW5pdGlvbiBvZiBUZXJtcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NAogICAgIDEuMi4gIE1vdGl2YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDUKICAgICAxLjMuICBFdmVudCBOb3RpZmljYXRpb25zIGluIE5FVENP TkYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMS40LiAgUmVxdWlyZW1lbnRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAyLiAg Tm90aWZpY2F0aW9uLVJlbGF0ZWQgT3BlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDcKICAgICAyLjEuICBTdWJzY3JpYmluZyB0byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNh dGlvbnMgLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgICAyLjEuMS4gICZsdDtjcmVhdGUtc3Vic2Ny aXB0aW9uJmd0OyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDIuMi4g IFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDkKICAgICAgIDIuMi4xLiAgJmx0O25vdGlmaWNhdGlvbiZndDsgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgMi4zLiAgVGVybWluYXRpbmcgdGhlIFN1 YnNjcmlwdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICAzLiAgU3VwcG9y dGluZyBDb25jZXB0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTEKICAgICAzLjEuICBDYXBhYmlsaXRpZXMgRXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICAzLjEuMS4gIENhcGFiaWxpdHkgSWRlbnRpZmllciAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMy4xLjIuICBDYXBhYmls aXR5IEV4YW1wbGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICAz LjIuICBFdmVudCBTdHJlYW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDExCiAgICAgICAzLjIuMS4gIEV2ZW50IFN0cmVhbSBEZWZpbml0aW9uICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAgICAgMy4yLjIuICBFdmVudCBTdHJlYW0gQ29u dGVudCBGb3JtYXQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAgIDMuMi4zLiAg RGVmYXVsdCBFdmVudCBTdHJlYW0gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEz CiAgICAgICAzLjIuNC4gIEV2ZW50IFN0cmVhbSBTb3VyY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMwogICAgICAgMy4yLjUuICBFdmVudCBTdHJlYW0gRGlzY292ZXJ5IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAzLjMuICBOb3RpZmljYXRpb24g UmVwbGF5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgICAz LjMuMS4gIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNQogICAgICAgMy4zLjIuICBDcmVhdGluZyBhIFN1YnNjcmlwdGlvbiB3aXRoIFJlcGxh eSAgLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ My4zLjMuICBSZXBsYXkgQ29tcGxldGUgTm90aWZpY2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTY8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgMy40LiAgTm90aWZpY2F0aW9uIE1hbmFnZW1l bnQgU2NoZW1hIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgIDMuNS4gIFN1YnNj cmlwdGlvbnMgRGF0YSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkK ICAgICAzLjYuICBGaWx0ZXIgTWVjaGFuaWNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE5CiAgICAgICAzLjYuMS4gIEZpbHRlcmluZyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICAgIDMuNy4gIE1lc3NhZ2UgRmxvdyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkKICAgNC4gIFhN TCBTY2hlbWEgZm9yIEV2ZW50IE5vdGlmaWNhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIxCiAgIDUuICBGaWx0ZXJpbmcgRXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyNQogICAgIDUuMS4gIFN1YnRyZWUgRmlsdGVyaW5nICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUKICAgICA1LjIuICBYUEFUSCBm aWx0ZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4CiAg IDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAzMAogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzEKICAgOC4gIEFja25vd2xlZGdlbWVudHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyCiAgIDkuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzMwogICBBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMzQKICAgICBBLjEuICBWZXJzaW9uIC0wOCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM0CiAgICAgPHN0cm9uZz48Zm9udCBj b2xvcj0nZ3JlZW4nPkEuMi4gIFZlcnNpb24gLTA5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMzY8L2ZvbnQ+PC9zdHJvbmc+CiAgIEF1dGhvcnMnIEFkZHJl c3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPjM3PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+Mzg8L2ZvbnQ+PC9zdHJvbmc+CiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBh bmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPjM4PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bic+Mzk8L2ZvbnQ+PC9zdHJvbmc+CgoxLiAgSW50cm9kdWN0aW9uCgogICBbTkVUQ09ORl0gY2Fu IGJlIGNvbmNlcHR1YWxseSBwYXJ0aXRpb25lZCBpbnRvIGZvdXIgbGF5ZXJzOgoKICAgTGF5ZXIg ICAgICAgICAgICAgICAgICAgICAgRXhhbXBsZQogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICB8ICAgQ29udGVudCAg IHwgICAgICB8ICAgICBDb25maWd1cmF0aW9uIGRhdGEgICAgICAgICAgICAgICAgIHwKICAgICst LS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKwogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLS0t LS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKICAgIHwgT3BlcmF0aW9ucyAgfCAgICAgIHwgJmx0O2dldC1jb25maWcmZ3Q7LCAmbHQ7 ZWRpdC1jb25maWcmZ3Q7ICZsdDtub3RpZmljYXRpb24mZ3Q7fAogICAgKy0tLS0tLS0tLS0tLS0r ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg IHwKICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsgICAgICAgfAogICAgfCAgICAgUlBDICAgICB8ICAgICAgfCAgICAmbHQ7cnBjJmd0OywgJmx0 O3JwYy1yZXBseSZndDsgICAgICAgfCAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgIHwKICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0tLS0t LS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgIHwgVHJhbnNwb3J0ICAgfCAgICAgIHwgICBCRUVQLCBTU0gsIFNTTCwgY29uc29sZSAg ICAgICAgICAgICAgICB8CiAgICB8ICAgUHJvdG9jb2wgIHwgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbWVj aGFuaXNtcyB3aGljaCBwcm92aWRlIGFuIGFzeW5jaHJvbm91cwogICBtZXNzYWdlIG5vdGlmaWNh dGlvbiBkZWxpdmVyeSBzZXJ2aWNlIGZvciB0aGUgW05FVENPTkZdIHByb3RvY29sLgogICBUaGlz IGlzIGFuIG9wdGlvbmFsIGNhcGFiaWxpdHkgYnVpbHQgb24gdG9wIG9mIHRoZSBiYXNlIE5FVENP TkYKICAgZGVmaW5pdGlvbi4gIFRoaXMgbWVtbyBkZWZpbmVzIHRoZSBjYXBhYmlsaXRpZXMgYW5k IG9wZXJhdGlvbnMKICAgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgdGhpcyBzZXJ2aWNlLgoKMS4xLiAg RGVmaW5pdGlvbiBvZiBUZXJtcwoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCiAg IEVsZW1lbnQ6ICBBbiBbWE1MXSBFbGVtZW50LgoKICAgU3Vic2NyaXB0aW9uOiAgQW4gYWdyZWVt ZW50IGFuZCBtZXRob2QgdG8gcmVjZWl2ZSBldmVudCBub3RpZmljYXRpb25zCiAgICAgIG92ZXIg YSBORVRDT05GIHNlc3Npb24uICBBIGNvbmNlcHQgcmVsYXRlZCB0byB0aGUgZGVsaXZlcnkgb2YK ICAgICAgbm90aWZpY2F0aW9ucyAoaWYgYW55IHRvIHNlbmQpIGludm9sdmluZyBkZXN0aW5hdGlv biBhbmQgc2VsZWN0aW9uCiAgICAgIG9mIG5vdGlmaWNhdGlvbnMuICBJdCBpcyBib3VuZCB0byB0 aGUgbGlmZXRpbWUgb2YgYSBzZXNzaW9uLgoKICAgT3BlcmF0aW9uOiAgVGhpcyB0ZXJtIGlzIHVz ZWQgdG8gcmVmZXIgdG8gTkVUQ09ORiBwcm90b2NvbCBvcGVyYXRpb25zCiAgICAgIFtORVRDT05G XS4gIFNwZWNpZmljYWxseSB3aXRoaW4gdGhpcyBkb2N1bWVudCwgb3BlcmF0aW9uIHJlZmVycyB0 bwogICAgICBORVRDT05GIHByb3RvY29sIG9wZXJhdGlvbnMgZGVmaW5lZCBpbiBzdXBwb3J0IG9m IE5FVENPTkYKICAgICAgbm90aWZpY2F0aW9ucy4KCiAgIEV2ZW50OiAgQW4gZXZlbnQgaXMgc29t ZXRoaW5nIHRoYXQgaGFwcGVucyB3aGljaCBtYXkgYmUgb2YgaW50ZXJlc3QgLQogICAgICBhIGNv bmZpZ3VyYXRpb24gY2hhbmdlLCBhIGZhdWx0LCBhIGNoYW5nZSBpbiBzdGF0dXMsIGNyb3NzaW5n IGEKICAgICAgdGhyZXNob2xkLCBvciBhbiBleHRlcm5hbCBpbnB1dCB0byB0aGUgc3lzdGVtLCBm b3IgZXhhbXBsZS4gIE9mdGVuCiAgICAgIHRoaXMgcmVzdWx0cyBpbiBhbiBhc3luY2hyb25vdXMg bWVzc2FnZSwgc29tZXRpbWVzIHJlZmVycmVkIHRvIGFzCiAgICAgIGEgbm90aWZpY2F0aW9uIG9y IGV2ZW50IG5vdGlmaWNhdGlvbiwgYmVpbmcgc2VudCB0byBpbnRlcmVzdGVkCiAgICAgIHBhcnRp ZXMgdG8gbm90aWZ5IHRoZW0gdGhhdCB0aGlzIGV2ZW50IGhhcyBvY2N1cnJlZC4KCiAgIFJlcGxh eTogIFRoZSBhYmlsaXR5IHRvIHNlbmQvcmUtc2VuZCBwcmV2aW91c2x5IGxvZ2dlZCBub3RpZmlj YXRpb25zCiAgICAgIHVwb24gcmVxdWVzdC4gIFRoZXNlIG5vdGlmaWNhdGlvbnMgYXJlIHNlbnQg YXN5bmNocm9ub3VzbHkuICBUaGlzCiAgICAgIGZlYXR1cmUgaXMgaW1wbGVtZW50ZWQgYnkgdGhl IE5FVENPTkYgc2VydmVyIGFuZCBpbnZva2VkIGJ5IHRoZQogICAgICBORVRDT05GIGNsaWVudC4K CiAgIFN0cmVhbTogIEFuIGV2ZW50IHN0cmVhbSBpcyBhIHNldCBvZiBldmVudCBub3RpZmljYXRp b25zIG1hdGNoaW5nCiAgICAgIHNvbWUgZm9yd2FyZGluZyBjcml0ZXJpYSBhbmQgaXQgaXMgYXZh aWxhYmxlIHRvIE5FVENPTkYgY2xpZW50cwogICAgICBmb3Igc3Vic2NyaXB0aW9uLgoKICAgRmls dGVyOiAgQSBwYXJhbWV0ZXIgdGhhdCBpbmRpY2F0ZXMgd2hpY2ggc3Vic2V0IG9mIGFsbCBwb3Nz aWJsZQogICAgICBldmVudHMgYXJlIG9mIGludGVyZXN0LgoKMS4yLiAgTW90aXZhdGlvbgoKICAg VGhlIG1vdGl2YXRpb24gZm9yIHRoaXMgd29yayBpcyB0byBlbmFibGUgdGhlIHNlbmRpbmcgb2Yg YXN5bmNocm9ub3VzCiAgIG1lc3NhZ2VzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGF0 YSBtb2RlbCAoY29udGVudCkgYW5kCiAgIHNlY3VyaXR5IG1vZGVsIHVzZWQgd2l0aGluIGEgTkVU Q09ORiBpbXBsZW1lbnRhdGlvbi4KCjEuMy4gIEV2ZW50IE5vdGlmaWNhdGlvbnMgaW4gTkVUQ09O RgoKICAgVGhpcyBtZW1vIGRlZmluZXMgYSBtZWNoYW5pc20gd2hlcmVieSB0aGUgTkVUQ09ORiBj bGllbnQgaW5kaWNhdGVzCiAgIGludGVyZXN0IGluIHJlY2VpdmluZyBldmVudCBub3RpZmljYXRp b25zIGZyb20gYSBORVRDT05GIHNlcnZlciBieQogICBjcmVhdGluZyBhIHN1YnNjcmlwdGlvbiB0 byByZWNlaXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMuICBUaGUgTkVUQ09ORgogICBzZXJ2ZXIgcmVw bGllcyB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBzdWJzY3JpcHRpb24gcmVxdWVzdCB3YXMKICAg c3VjY2Vzc2Z1bCBhbmQsIGlmIGl0IHdhcyBzdWNjZXNzZnVsLCBiZWdpbnMgc2VuZGluZyB0aGUg ZXZlbnQKICAgbm90aWZpY2F0aW9ucyB0byB0aGUgTkVUQ09ORiBjbGllbnQgYXMgdGhlIGV2ZW50 cyBvY2N1ciB3aXRoaW4gdGhlCiAgIHN5c3RlbS4gIFRoZXNlIGV2ZW50IG5vdGlmaWNhdGlvbnMg d2lsbCBjb250aW51ZSB0byBiZSBzZW50IHVudGlsCiAgIGVpdGhlciB0aGUgTkVUQ09ORiBzZXNz aW9uIGlzIHRlcm1pbmF0ZWQgb3IgdGhlIHN1YnNjcmlwdGlvbgogICB0ZXJtaW5hdGVzIGZvciBz b21lIG90aGVyIHJlYXNvbi4gIFRoZSBldmVudCBub3RpZmljYXRpb24KICAgc3Vic2NyaXB0aW9u IGFsbG93cyBhIG51bWJlciBvZiBvcHRpb25zIHRvIGVuYWJsZSB0aGUgTkVUQ09ORiBjbGllbnQK ICAgdG8gc3BlY2lmeSB3aGljaCBldmVudHMgYXJlIG9mIGludGVyZXN0LiAgVGhlc2UgYXJlIHNw ZWNpZmllZCB3aGVuCiAgIHRoZSBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZC4KCiAgIEEgTkVUQ09O RiBzZXJ2ZXIgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5pczwvZm9udD48L3N0cmlrZT4gd2ls bCBub3QgcmVhZCBSUEMgcmVxdWVzdHMsIGJ5IGRlZmF1bHQsIG9uIHRoZQogICBzZXNzaW9uIGFz c29jaWF0ZWQgd2l0aCB0aGUgc3Vic2NyaXB0aW9uIHVudGlsIHRoZSBub3RpZmljYXRpb24KICAg c3Vic2NyaXB0aW9uIGlzIGRvbmUuICBBIGNhcGFiaWxpdHkgbWF5IGJlIGFkdmVydGlzZWQgdG8g YW5ub3VuY2UKICAgdGhhdCBhIHNlcnZlciBpcyBhYmxlIHRvIHByb2Nlc3MgUlBDcyB3aGlsZSBh IG5vdGlmaWNhdGlvbiBzdHJlYW0gaXMKICAgYWN0aXZlIG9uIGEgc2Vzc2lvbi4gIFRoZSBiZWhh dmlvdXIgb2Ygc3VjaCBhIGNhcGFiaWxpdHkgaXMgb3V0c2lkZQogICB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4KCjEuNC4gIFJlcXVpcmVtZW50cwoKICAgVGhlIGZvbGxvd2luZyByZXF1aXJl bWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCBieSB0aGUgc29sdXRpb246CgogICBvICBJbml0aWFs IHJlbGVhc2Ugc2hvdWxkIGVuc3VyZSBpdCBzdXBwb3J0cyBub3RpZmljYXRpb24gaW4gc3VwcG9y dAogICAgICBvZiBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMKCiAgIG8gIERhdGEgY29udGVudCBt dXN0IG5vdCBwcmVjbHVkZSB0aGUgdXNlIG9mIHRoZSBzYW1lIGRhdGEgbW9kZWwgYXMKICAgICAg dXNlZCBpbiBjb25maWd1cmF0aW9uCgogICBvICBTb2x1dGlvbiBzaG91bGQgc3VwcG9ydCBhIHJl YXNvbmFibGUgbWVzc2FnZSBzaXplIGxpbWl0IChpZSwgbm90CiAgICAgIHRvbyBzaG9ydCkKCiAg IG8gIFNvbHV0aW9uIHNob3VsZCBwcm92aWRlIHJlbGlhYmxlIGRlbGl2ZXJ5IG9mIG5vdGlmaWNh dGlvbnMKCiAgIG8gIFNvbHV0aW9uIHNob3VsZCBwcm92aWRlIGEgc3Vic2NyaXB0aW9uIG1lY2hh bmlzbSAoQSBORVRDT05GIHNlcnZlcgogICAgICBkb2VzIG5vdCBzZW5kIG5vdGlmaWNhdGlvbnMg YmVmb3JlIGJlaW5nIGFza2VkIHRvIGRvIHNvIGFuZCB0aGUKICAgICAgTkVUQ09ORiBjbGllbnQg aW5pdGlhdGVzIHRoZSBmbG93IG9mIG5vdGlmaWNhdGlvbnMpCgogICBvICBTb2x1dGlvbiBzaG91 bGQgcHJvdmlkZSBhIGZpbHRlcmluZyBtZWNoYW5pc20gd2l0aGluIHRoZSBORVRDT05GCiAgICAg IHNlcnZlcgoKICAgbyAgU29sdXRpb24gc2hvdWxkIHNlbmQgc3VmZmljaWVudCBpbmZvcm1hdGlv biBpbiBhIG5vdGlmaWNhdGlvbiBzbwogICAgICB0aGF0IGl0IGNhbiBiZSBhbmFseXplZCBpbmRl cGVuZGVudCBvZiB0aGUgdHJhbnNwb3J0IG1lY2hhbmlzbQogICAgICAoZGF0YSBjb250ZW50IGZ1 bGx5IGRlc2NyaWJlcyBhIG5vdGlmaWNhdGlvbjsgcHJvdG9jb2wgaW5mb3JtYXRpb24KICAgICAg aXMgbm90IG5lZWRlZCB0byB1bmRlcnN0YW5kIGEgbm90aWZpY2F0aW9uKQoKICAgbyAgU29sdXRp b24gc2hvdWxkIHN1cHBvcnQgcmVwbGF5IG9mIGxvY2FsbHkgbG9nZ2VkIG5vdGlmaWNhdGlvbnMK CjIuICBOb3RpZmljYXRpb24tUmVsYXRlZCBPcGVyYXRpb25zCgoyLjEuICBTdWJzY3JpYmluZyB0 byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNhdGlvbnMKCiAgIFRoZSBldmVudCBub3RpZmljYXRpb24g c3Vic2NyaXB0aW9uIGlzIGluaXRpYXRlZCBieSB0aGUgTkVUQ09ORgogICBjbGllbnQgYW5kIHJl c3BvbmRlZCB0byBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIuICA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbic+QSBzdWJzY3JpcHRpb24gaXMKICAgYm91bmQgdG8gYSBzaW5nbGUgc3RyZWFtIGZvciB0 aGUgbGlmZXRpbWUgb2YgdGhlIHN1YnNjcmlwdGlvbi48L2ZvbnQ+PC9zdHJvbmc+ICBXaGVuCiAg IHRoZSBldmVudCBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQsIHRoZSBldmVu dHMgb2YKICAgaW50ZXJlc3QgYXJlIHNwZWNpZmllZC4KCiAgIENvbnRlbnQgZm9yIGFuIGV2ZW50 IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gY2FuIGJlIHNlbGVjdGVkIGJ5CiAgIGFwcGx5aW5n IHVzZXItc3BlY2lmaWVkIGZpbHRlcnMuCgoyLjEuMS4gICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9u Jmd0OwoKICAgRGVzY3JpcHRpb246CgogICAgICBUaGlzIG9wZXJhdGlvbiBpbml0aWF0ZXMgYW4g ZXZlbnQgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiB3aGljaAogICAgICB3aWxsIHNlbmQgYXN5 bmNocm9ub3VzIGV2ZW50IG5vdGlmaWNhdGlvbnMgdG8gdGhlIGluaXRpYXRvciBvZiB0aGUKICAg ICAgY29tbWFuZCB1bnRpbCB0aGUgc3Vic2NyaXB0aW9uIHRlcm1pbmF0ZXMuCgogICBQYXJhbWV0 ZXJzOgoKICAgICAgU3RyZWFtOgoKICAgICAgICAgQW4gb3B0aW9uYWwgcGFyYW1ldGVyIHRoYXQg aW5kaWNhdGVzIHdoaWNoIHN0cmVhbSBvZiBldmVudHMgaXMKICAgICAgICAgb2YgaW50ZXJlc3Qu ICBJZiBub3QgcHJlc2VudCwgdGhlbiBldmVudHMgaW4gdGhlIGRlZmF1bHQKICAgICAgICAgTkVU Q09ORiBzdHJlYW0gd2lsbCBiZSBzZW50LgoKICAgICAgRmlsdGVyOgoKICAgICAgICAgQW4gb3B0 aW9uYWwgcGFyYW1ldGVyIHRoYXQgaW5kaWNhdGVzIHdoaWNoIHN1YnNldCBvZiBhbGwKICAgICAg ICAgcG9zc2libGUgZXZlbnRzIGFyZSBvZiBpbnRlcmVzdC4gIFRoZSBmb3JtYXQgb2YgdGhpcyBw YXJhbWV0ZXIKICAgICAgICAgaXMgdGhlIHNhbWUgYXMgdGhhdCBvZiB0aGUgZmlsdGVyIHBhcmFt ZXRlciBpbiB0aGUgTkVUQ09ORgogICAgICAgICBwcm90b2NvbCBvcGVyYXRpb25zLiAgSWYgbm90 IHByZXNlbnQsIGFsbCBldmVudHMgbm90IHByZWNsdWRlZAogICAgICAgICBieSBvdGhlciBwYXJh bWV0ZXJzIHdpbGwgYmUgc2VudC4gIFNlZSBzZWN0aW9uIDMuNiBmb3IgbW9yZQogICAgICAgICBp bmZvcm1hdGlvbiBvbiBmaWx0ZXJzLgoKICAgICAgU3RhcnQgVGltZToKCiAgICAgICAgIEEgcGFy YW1ldGVyIHVzZWQgdG8gdHJpZ2dlciB0aGUgcmVwbGF5IGZlYXR1cmUgYW5kIGluZGljYXRlCiAg ICAgICAgIHRoYXQgdGhlIHJlcGxheSBzaG91bGQgc3RhcnQgYXQgdGhlIHRpbWUgc3BlY2lmaWVk LiAgSWYKICAgICAgICAgc3RhcnRUaW1lIGlzIG5vdCBwcmVzZW50LCB0aGlzIGlzIG5vdCBhIHJl cGxheSBzdWJzY3JpcHRpb24uCiAgICAgICAgIEl0IGlzIHZhbGlkIHRvIHNwZWNpZnkgc3RhcnQg dGltZXMgdGhhdCBhcmUgbGF0ZXIgdGhhbiB0aGUKICAgICAgICAgY3VycmVudCB0aW1lLiAgSWYg dGhlIHN0YXJ0VGltZSBzcGVjaWZpZWQgaXMgZWFybGllciB0aGFuIHRoZQogICAgICAgICBsb2cg Y2FuIHN1cHBvcnQsIHRoZSByZXBsYXkgd2lsbCBiZWdpbiB3aXRoIHRoZSBlYXJsaWVzdAogICAg ICAgICBhdmFpbGFibGUgbm90aWZpY2F0aW9uLiAgVGhpcyBwYXJhbWV0ZXIgaXMgb2YgdHlwZSBk YXRlVGltZS4KCiAgICAgIFN0b3AgVGltZToKCiAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRl ciB1c2VkIHdpdGggdGhlIG9wdGlvbmFsIHJlcGxheSBmZWF0dXJlIHRvCiAgICAgICAgIGluZGlj YXRlIHRoZSBuZXdlc3Qgbm90aWZpY2F0aW9ucyBvZiBpbnRlcmVzdC4gIElmIHN0b3AgdGltZSBp cwogICAgICAgICBub3QgcHJlc2VudCwgdGhlIG5vdGlmaWNhdGlvbnMgd2lsbCBjb250aW51ZSB1 bnRpbCB0aGUKICAgICAgICAgc3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuICBNdXN0IGJlIHVz ZWQgd2l0aCBhbmQgYmUgbGF0ZXIKICAgICAgICAgdGhhbiA8c3RyaWtlPjxmb250IGNvbG9yPSdy ZWQnPidzdGFydFRpbWUnLjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl ZW4nPnN0YXJ0VGltZS48L2ZvbnQ+PC9zdHJvbmc+ICBJdCBpcyB2YWxpZCB0byBzcGVjaWZ5IHN0 b3AgdGltZXMgdGhhdCBhcmUKICAgICAgICAgbGF0ZXIgdGhhbiB0aGUgY3VycmVudCB0aW1lLiAg VGhpcyBwYXJhbWV0ZXIgaXMgb2YgdHlwZQogICAgICAgICBkYXRlVGltZS4KCiAgIFBvc2l0aXZl IFJlc3BvbnNlOgoKICAgICAgSWYgdGhlIE5FVENPTkYgc2VydmVyIGNhbiBzYXRpc2Z5IHRoZSBy ZXF1ZXN0LCB0aGUgc2VydmVyIHNlbmRzIGFuCiAgICAgICZsdDtvayZndDsgZWxlbWVudC4KCiAg IE5lZ2F0aXZlIFJlc3BvbnNlOgoKICAgICAgQW4gJmx0O3JwYy1lcnJvciZndDsgZWxlbWVudCBp cyBpbmNsdWRlZCB3aXRoaW4gdGhlICZsdDtycGMtcmVwbHkmZ3Q7IGlmIHRoZQogICAgICByZXF1 ZXN0IGNhbm5vdCBiZSBjb21wbGV0ZWQgZm9yIGFueSByZWFzb24uICBTdWJzY3JpcHRpb24gcmVx dWVzdHMKICAgICAgd2lsbCBmYWlsIGlmIGEgZmlsdGVyIHdpdGggaW52YWxpZCBzeW50YXggaXMg cHJvdmlkZWQgb3IgaWYgdGhlCiAgICAgIG5hbWUgb2YgYSBub24tZXhpc3RlbnQgPHN0cmlrZT48 Zm9udCBjb2xvcj0ncmVkJz5wcm9maWxlIG9yPC9mb250Pjwvc3RyaWtlPiBzdHJlYW0gaXMgcHJv dmlkZWQuCgogICAgICBJZiBhIHN0b3BUaW1lIGlzIHNwZWNpZmllZCBpbiBhIHJlcXVlc3Qgd2l0 aG91dCBoYXZpbmcgc3BlY2lmaWVkIGEKICAgICAgc3RhcnRUaW1lIHRoZSBmb2xsb3dpbmcgZXJy b3IgaXMgcmV0dXJuZWQ6CgogICAgICAgICBUYWc6IG1pc3NpbmctZWxlbWVudAoKICAgICAgICAg RXJyb3ItdHlwZTogcHJvdG9jb2wKCiAgICAgICAgIFNldmVyaXR5OiBlcnJvcgoKICAgICAgICAg RXJyb3ItaW5mbzogPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4mbHQ7YmFkRWxlbWVudCZndDs6 PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O2JhZC1FbGVt ZW50Jmd0Ozo8L2ZvbnQ+PC9zdHJvbmc+IHN0YXJ0VGltZQoKICAgICAgICAgRGVzY3JpcHRpb246 IEFuIGV4cGVjdGVkIGVsZW1lbnQgaXMgbWlzc2luZy4KCiAgICAgIElmIHRoZSBvcHRpb25hbCBy ZXBsYXkgZmVhdHVyZSBpcyByZXF1ZXN0ZWQgYnV0IGl0IGlzIG5vdAogICAgICBzdXBwb3J0ZWQg YnkgdGhlIE5FVENPTkYgc2VydmVyLCB0aGUgZm9sbG93aW5nIGVycm9yIGlzIHJldHVybmVkOgoK ICAgICAgICAgVGFnOiBvcGVyYXRpb24tZmFpbGVkCgogICAgICAgICBFcnJvci10eXBlOiBwcm90 b2NvbAoKICAgICAgICAgU2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiBub25l CiAgICAgICAgIERlc2NyaXB0aW9uOiBSZXF1ZXN0IGNvdWxkIG5vdCBiZSBjb21wbGV0ZWQgYmVj YXVzZSB0aGUKICAgICAgICAgcmVxdWVzdGVkIG9wZXJhdGlvbiBmYWlsZWQgZm9yIHNvbWUgcmVh c29uIG5vdCBjb3ZlcmVkIGJ5IGFueQogICAgICAgICBvdGhlciBlcnJvciBjb25kaXRpb24KCjIu MS4xLjEuICBVc2FnZSBFeGFtcGxlCgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+VGhl IGZvbGxvd2luZyBkZW1vbnN0cmF0ZXMgY3JlYXRpbmcgYSBzaW1wbGUgc3Vic2NyaXB0aW9uLiAg TW9yZQogICBjb21wbGV4IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiBzZWN0aW9uIDUuPC9mb250 Pjwvc3Ryb25nPgoKICAgJmx0O25ldGNvbmY6cnBjIG1lc3NhZ2UtaWQ9IjEwMSIKICAgICAgICAg eG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZn dDsKICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uCiAgICAgICAgICAgeG1sbnM9InVybjpp ZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAg ICAmbHQ7L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgICZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMgoKMi4yLiAgU2VuZGluZyBF dmVudCBOb3RpZmljYXRpb25zCgogICBPbmNlIHRoZSBzdWJzY3JpcHRpb24gaGFzIGJlZW4gc2V0 IHVwLCB0aGUgTkVUQ09ORiBzZXJ2ZXIgc2VuZHMgdGhlCiAgIGV2ZW50IG5vdGlmaWNhdGlvbnMg YXN5bmNocm9ub3VzbHkgb3ZlciB0aGUgY29ubmVjdGlvbi4KCjIuMi4xLiAgJmx0O25vdGlmaWNh dGlvbiZndDsKCiAgIERlc2NyaXB0aW9uOgoKICAgICAgQW4gZXZlbnQgbm90aWZpY2F0aW9uIGlz IHNlbnQgdG8gdGhlIGNsaWVudCB3aG8gaW5pdGlhdGVkIGEKICAgICAgJmx0O2NyZWF0ZS1zdWJz Y3JpcHRpb24mZ3Q7IGNvbW1hbmQgYXN5bmNocm9ub3VzbHkgd2hlbiBhbiBldmVudCBvZgogICAg ICBpbnRlcmVzdCAoaS5lLiwgbWVldGluZyB0aGUgc3BlY2lmaWVkIGZpbHRlcmluZyBjcml0ZXJp YSkgdG8gdGhlbQogICAgICBoYXMgb2NjdXJyZWQuICBBbiBldmVudCBub3RpZmljYXRpb24gaXMg YSBjb21wbGV0ZSBhbmQgd2VsbC1mb3JtZWQKICAgICAgWE1MIGRvY3VtZW50LiAgTm90ZSB0aGF0 ICZsdDtub3RpZmljYXRpb24mZ3Q7IGlzIG5vdCBhbiBSUEMgbWV0aG9kIGJ1dAogICAgICByYXRo ZXIgdGhlIHRvcCBsZXZlbCBlbGVtZW50IGlkZW50aWZ5aW5nIHRoZSBvbmUgd2F5IG1lc3NhZ2Ug YXMgYQogICAgICBub3RpZmljYXRpb24uCgogICBQYXJhbWV0ZXJzOgoKICAgICAgICAgQ29udGFp bnMgbm90aWZpY2F0aW9uLXNwZWNpZmljIHRhZ2dlZCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn PmNvbnRlbnQuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Y29u dGVudCwgaWYgYW55LjwvZm9udD48L3N0cm9uZz4gIFRoZQogICAgICAgICBjb250ZW50IG9mIHRo ZSBkYXRhIHRhZyBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICBSZXNw b25zZToKCiAgICAgIE5vIHJlc3BvbnNlLiAgTm90IGFwcGxpY2FibGUuCgoyLjMuICBUZXJtaW5h dGluZyB0aGUgU3Vic2NyaXB0aW9uCgogICBDbG9zaW5nIG9mIHRoZSBldmVudCBub3RpZmljYXRp b24gc3Vic2NyaXB0aW9uIGNhbiBiZSBkb25lIGJ5CiAgIHRlcm1pbmF0aW5nIHRoZSBORVRDT05G IHNlc3Npb24gKCAmbHQ7a2lsbC1zZXNzaW9uJmd0OyApIG9yIHRoZSB1bmRlcmx5aW5nCiAgIHRy YW5zcG9ydCBzZXNzaW9uLiAgSWYgYSBzdG9wIHRpbWUgaXMgcHJvdmlkZWQgd2hlbiB0aGUgc3Vi c2NyaXB0aW9uCiAgIGlzIGNyZWF0ZWQsIHRoZW4gdGhlIHN1YnNjcmlwdGlvbiB3aWxsIHRlcm1p bmF0ZSBhZnRlciB0aGUgc3RvcCB0aW1lCiAgIGlzIHJlYWNoZWQuICBJbiB0aGlzIGNhc2UsIHRo ZSBORVRDT05GIHNlc3Npb24gd2lsbCBzdGlsbCBiZSBhbgogICBhY3RpdmUgc2Vzc2lvbi4KCjMu ICBTdXBwb3J0aW5nIENvbmNlcHRzCgozLjEuICBDYXBhYmlsaXRpZXMgRXhjaGFuZ2UKCiAgIFRo ZSBhYmlsaXR5IHRvIHByb2Nlc3MgYW5kIHNlbmQgZXZlbnQgbm90aWZpY2F0aW9ucyBpcyBhZHZl cnRpc2VkCiAgIGR1cmluZyB0aGUgY2FwYWJpbGl0eSBleGNoYW5nZSBiZXR3ZWVuIHRoZSBORVRD T05GIGNsaWVudCBhbmQgc2VydmVyLgoKMy4xLjEuICBDYXBhYmlsaXR5IElkZW50aWZpZXIKCiAg ICJ1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAiCgoz LjEuMi4gIENhcGFiaWxpdHkgRXhhbXBsZQoKICAgJmx0O2hlbGxvIHhtbG5zPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiJmd0OwogICAgICZsdDtjYXBhYmlsaXRpZXMm Z3Q7CiAgICAgICAgJmx0O2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAgICAgIHVybjppZXRmOnBhcmFt czp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMAogICAgICAgICAgJmx0Oy9jYXBhYmlsaXR5Jmd0Owog ICAgICAgICAgJmx0O2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAgICAgIHVybjppZXRmOnBhcmFtczpu ZXRjb25mOmNhcGFiaWxpdHk6c3RhcnR1cDoxLjAKICAgICAgICAgICZsdDsvY2FwYWJpbGl0eSZn dDsKICAgICAgICAgICZsdDtjYXBhYmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJh bXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAKICAgICAgICAgICZsdDsvY2Fw YWJpbGl0eSZndDsKICAgICAgICZsdDsvY2FwYWJpbGl0aWVzJmd0OwogICAgICZsdDtzZXNzaW9u LWlkJmd0OzQmbHQ7L3Nlc3Npb24taWQmZ3Q7CiAgICZsdDsvaGVsbG8mZ3Q7CgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMwoKMy4yLiAgRXZlbnQgU3RyZWFtcwoKICAg QW4gZXZlbnQgc3RyZWFtIGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9u cyBtYXRjaGluZwogICBzb21lIGZvcndhcmRpbmcgY3JpdGVyaWEuCgogICBUaGUgZGlhZ3JhbSBk ZXBpY3RlZCBpbiBGaWd1cmUgMiBpbGx1c3RyYXRlcyB0aGUgbm90aWZpY2F0aW9uIGZsb3cKICAg YW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSBmb2xsb3dpbmcg aXMgb2JzZXJ2ZWQKICAgZnJvbSB0aGUgZGlhZ3JhbSBiZWxvdzogU3lzdGVtIGNvbXBvbmVudHMg KGMxLi5jbikgZ2VuZXJhdGUgZXZlbnQKICAgbm90aWZpY2F0aW9ucyB3aGljaCBhcmUgcGFzc2Vk IHRvIGEgY2VudHJhbCBjb21wb25lbnQgZm9yCiAgIGNsYXNzaWZpY2F0aW9uIGFuZCBkaXN0cmli dXRpb24uICBUaGUgY2VudHJhbCBjb21wb25lbnQgaW5zcGVjdHMgZWFjaAogICBldmVudCBub3Rp ZmljYXRpb24gYW5kIG1hdGNoZXMgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBhZ2FpbnN0IHRoZSBz ZXQKICAgb2Ygc3RyZWFtIGRlZmluaXRpb25zLiAgV2hlbiBhIG1hdGNoIG9jY3VycywgdGhlIGV2 ZW50IG5vdGlmaWNhdGlvbgogICBpcyBjb25zaWRlcmVkIHRvIGJlIGEgbWVtYmVyIG9mIHRoYXQg ZXZlbnQgc3RyZWFtIChzdHJlYW0gMS4uc3RyZWFtCiAgIG4pLiAgQW4gZXZlbnQgbm90aWZpY2F0 aW9uIG1heSBiZSBwYXJ0IG9mIG11bHRpcGxlIGV2ZW50IHN0cmVhbXMuCgogICBXaGVuIGEgTkVU Q09ORiBjbGllbnQgc3Vic2NyaWJlcyB0byBhIGdpdmVuIGV2ZW50IHN0cmVhbSwgdXNlci0KICAg ZGVmaW5lZCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmZpbHRlcnMsPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ZmlsdGVyIGVsZW1lbnRzLDwvZm9udD48L3N0 cm9uZz4gaWYgYXBwbGljYWJsZSwgYXJlIGFwcGxpZWQgdG8gdGhlIGV2ZW50CiAgIHN0cmVhbSBh bmQgbWF0Y2hpbmcgZXZlbnQgbm90aWZpY2F0aW9ucyBhcmUgZm9yd2FyZGVkIHRvIHRoZSBORVRD T05GCiAgIHNlcnZlciBmb3IgZGlzdHJpYnV0aW9uIHRvIHN1YnNjcmliZWQgTkVUQ09ORiBjbGll bnRzLiAgRm9yIG1vcmUKICAgaW5mb3JtYXRpb24gb24KICAgPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJz5maWx0ZXJzLDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n PmZpbHRlcmluZyw8L2ZvbnQ+PC9zdHJvbmc+IHNlZSBzZWN0aW9uIDMuNi4KCiAgIEEgbm90aWZp Y2F0aW9uIGxvZ2dpbmcgc2VydmljZSBtYXkgYWxzbyBiZSBhdmFpbGFibGUsIGluIHdoaWNoIGNh c2UsCiAgIHRoZSBjZW50cmFsIGNvbXBvbmVudCBsb2dzIG5vdGlmaWNhdGlvbnMuICBUaGUgTkVU Q09ORiBzZXJ2ZXIgbWF5CiAgIGxhdGVyIHJldHJpZXZlIGxvZ2dlZCBub3RpZmljYXRpb25zIHZp YSB0aGUgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUuCiAgIEZvciBtb3JlIGluZm9ybWF0aW9uIG9u IHJlcGxheSwgc2VlIHNlY3Rpb24gMy4zLgoKICAgKy0tLS0rCiAgIHwgYzEgfC0tLS0rICAgICAg ICAgICAgIGF2YWlsYWJsZSBzdHJlYW1zCiAgICstLS0tKyAgICB8ICAgICstLS0tLS0tLS0rCiAg ICstLS0tKyAgICB8ICAgIHxjZW50cmFsICB8LSZndDsgc3RyZWFtIDEKICAgfCBjMiB8ICAgICst LS0mZ3Q7fGV2ZW50ICAgIHwtJmd0OyBzdHJlYW0gMiAgICAgZmlsdGVyICArLS0tLS0tLSsKICAg Ky0tLS0rICAgIHwgICAgfHByb2Nlc3NvcnwtJmd0OyBORVRDT05GIHN0cmVhbSAtLS0tLSZndDt8 bmV0Y29uZnwKICAgIC4uLiAgICAgIHwgICAgfCAgICAgICAgIHwtJmd0OyBzdHJlYW0gbiAgICAg ICAgICAgICB8c2VydmVyIHwKICAgU3lzdGVtICAgIHwgICAgKy0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLSsKICAgQ29tcG9uZW50c3wgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAvXAogICAgLi4uICAgICAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHx8CiAgICstLS0tKyAgICB8ICAgICAgICB8ICAgICAg ICgtLS0tLS0tLS0tLS0pICAgICAgICAgICAgfHwKICAgfCBjbiB8LS0tLSsgICAgICAgIHwgICAg ICAgKG5vdGlmaWNhdGlvbikgICAgICAgICAgICB8fAogICArLS0tLSsgICAgICAgICAgICAgKy0t LS0tJmd0OyAoICBsb2dnaW5nICAgKSAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICggIHNlcnZpY2UgICApICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKC0tLS0tLS0tLS0tLSkgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcLwogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8bmV0Y29uZnwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxjbGll bnQgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNAoKMy4y LjEuICBFdmVudCBTdHJlYW0gRGVmaW5pdGlvbgoKICAgRXZlbnQgc3RyZWFtcyBhcmUgcHJlZGVm aW5lZCBvbiB0aGUgbWFuYWdlZCBkZXZpY2UuICBUaGUKICAgY29uZmlndXJhdGlvbiBvZiBldmVu dCBzdHJlYW1zIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCiAgIEhvd2V2 ZXIsIGl0IGlzIGVudmlzaW9uZWQgdGhhdCBldmVudCBzdHJlYW1zIGFyZSBlaXRoZXIgcHJlLQog ICBlc3RhYmxpc2hlZCBieSB0aGUgdmVuZG9yIChwcmUtY29uZmlndXJlZCkgb3IgdXNlciBjb25m aWd1cmFibGUKICAgKGUuZy4sIHBhcnQgb2YgdGhlIGRldmljZSdzIGNvbmZpZ3VyYXRpb24pIG9y IGJvdGguICBEZXZpY2UgdmVuZG9ycwogICBtYXkgYWxsb3cgZXZlbnQgc3RyZWFtIGNvbmZpZ3Vy YXRpb24gdmlhIE5FVENPTkYgcHJvdG9jb2wgKGkuZS4sCiAgIGVkaXQtY29uZmlnIG9wZXJhdGlv bikuCgozLjIuMi4gIEV2ZW50IFN0cmVhbSBDb250ZW50IEZvcm1hdAoKICAgVGhlIGNvbnRlbnRz IG9mIGFsbCBldmVudCBzdHJlYW1zIG1hZGUgYXZhaWxhYmxlIHRvIGEgTkVUQ09ORiBjbGllbnQK ICAgKGkuZS4sIHRoZSBub3RpZmljYXRpb24gc2VudCBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIpIG11 c3QgYmUgZW5jb2RlZAogICBpbiBYTUwuCgozLjIuMy4gIERlZmF1bHQgRXZlbnQgU3RyZWFtCgog ICBBIE5FVENPTkYgc2VydmVyIGltcGxlbWVudGF0aW9uIHN1cHBvcnRpbmcgdGhlIG5vdGlmaWNh dGlvbgogICBjYXBhYmlsaXR5IG11c3Qgc3VwcG9ydCB0aGUgIk5FVENPTkYiIG5vdGlmaWNhdGlv biBldmVudCBzdHJlYW0uCiAgIFRoaXMgc3RyZWFtIGNvbnRhaW5zIGFsbCBORVRDT05GIFhNTCBl dmVudCBub3RpZmljYXRpb25zIHN1cHBvcnRlZCBieQogICB0aGUgTkVUQ09ORiBzZXJ2ZXIuICBU aGUgZGVmaW5pdGlvbiBvZiB0aGUgZXZlbnQgbm90aWZpY2F0aW9ucyBhbmQKICAgdGhlaXIgY29u dGVudHMgZm9yIHRoaXMgZXZlbnQgc3RyZWFtIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMK ICAgZG9jdW1lbnQuCgozLjIuNC4gIEV2ZW50IFN0cmVhbSBTb3VyY2VzCgogICBXaXRoIHRoZSBl eGNlcHRpb24gb2YgdGhlIGRlZmF1bHQgZXZlbnQgc3RyZWFtIChORVRDT05GCiAgIG5vdGlmaWNh dGlvbnMpIHNwZWNpZmljYXRpb24gb2YgYWRkaXRpb25hbCBldmVudCBzdHJlYW0gc291cmNlcwog ICAoZS5nLiwgU05NUCwgc3lzbG9nLCBldGMuKSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50LgogICBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgbWF5IGxldmVyYWdl IGFueSBkZXNpcmVkIGV2ZW50IHN0cmVhbQogICBzb3VyY2UgaW4gdGhlIGNyZWF0aW9uIG9mIHN1 cHBvcnRlZCBldmVudCBzdHJlYW1zLgoKMy4yLjUuICBFdmVudCBTdHJlYW0gRGlzY292ZXJ5Cgog ICBBIE5FVENPTkYgY2xpZW50IHJldHJpZXZlcyB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgZXZlbnQg c3RyZWFtcyBmcm9tIGEKICAgTkVUQ09ORiBzZXJ2ZXIgdXNpbmcgdGhlICZsdDtnZXQmZ3Q7IFJQ QyByZXF1ZXN0LgoKMy4yLjUuMS4gIE5hbWUgUmV0cmlldmFsIHVzaW5nICZsdDtnZXQmZ3Q7IG9w ZXJhdGlvbgoKICAgVGhlIGxpc3Qgb2YgYXZhaWxhYmxlIGV2ZW50IHN0cmVhbXMgaXMgcmV0cmll dmVkIGJ5IHJlcXVlc3RpbmcgdGhlCiAgICZsdDtldmVudFN0cmVhbXMmZ3Q7IHN1YnRyZWUgdmlh IGEgJmx0O2dldCZndDsgb3BlcmF0aW9uLiAgQXZhaWxhYmxlIGV2ZW50CiAgIHN0cmVhbXMgZm9y IHRoZSByZXF1ZXN0aW5nIHNlc3Npb24gYXJlIHJldHVybmVkIGluIHRoZSByZXBseQogICBjb250 YWluaW5nIHRoZSAmbHQ7bmFtZSZndDsgYW5kICZsdDtkZXNjcmlwdGlvbiZndDsgZWxlbWVudHMs IHdoZXJlIHRoZSAmbHQ7bmFtZSZndDsKICAgZWxlbWVudCBpcyBtYW5kYXRvcnkgYW5kIGl0cyB2 YWx1ZSBpcyB1bmlxdWUgd2l0aGluIHRoZSBzY29wZSBvZiBhCiAgIE5FVENPTkYgc2VydmVyLiAg PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5UaGUgcmV0dXJuZWQgbGlzdCBtdXN0IG9ubHkgaW5j bHVkZSB0aGUgbmFtZXMgb2YKICAgdGhvc2UgZXZlbnQgc3RyZWFtcyBmb3Igd2hpY2ggdGhlIE5F VENPTkYgc2Vzc2lvbiBoYXMgc3VmZmljaWVudAogICBwcml2aWxlZ2VzLiAgVGhlIE5FVENPTkYg c2Vzc2lvbiBwcml2aWxlZ2VzIGFyZSBkZXRlcm1pbmVkIHZpYSBhY2Nlc3MKICAgY29udHJvbCBt ZWNoYW5pc21zIHdoaWNoIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPC9m b250Pjwvc3RyaWtlPiAgQW4gZW1wdHkgcmVwbHkgaXMgcmV0dXJuZWQgaWYgdGhlcmUgYXJlIG5v IGF2YWlsYWJsZQogICBldmVudCBzdHJlYW1zLiAgVGhlIGluZm9ybWF0aW9uIGlzIHJldHJpZXZl ZCBieSByZXF1ZXN0aW5nIHRoZQogICAmbHQ7ZXZlbnRTdHJlYW1zJmd0OyBzdWJ0cmVlIHZpYSBh ICZsdDtnZXQmZ3Q7IG9wZXJhdGlvbi4KCiAgIEV4YW1wbGU6IFJldHJpZXZpbmcgYXZhaWxhYmxl IGV2ZW50IHN0cmVhbSBsaXN0IHVzaW5nICZsdDtnZXQmZ3Q7CiAgIG9wZXJhdGlvbjoKCiAmbHQ7 cnBjIG1lc3NhZ2UtaWQ9IjEwMSIKICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5l dGNvbmY6YmFzZToxLjAiJmd0OwoKICAgJmx0O2dldCZndDsKICAgICZsdDtmaWx0ZXIgdHlwZT0i c3VidHJlZSImZ3Q7CiAgICAgICZsdDtldmVudFN0cmVhbXMgeG1sbnM9InVybjppZXRmOnBhcmFt czp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlvbiIvJmd0OwogICAgJmx0Oy9maWx0ZXImZ3Q7CiAg ICZsdDsvZ2V0Jmd0OwogJmx0Oy9ycGMmZ3Q7CgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgNQoKICAgVGhlIE5FVENPTkYgc2VydmVyIHJldHVybnMgYSBsaXN0IG9mIGV2 ZW50IHN0cmVhbXMgYXZhaWxhYmxlIGZvcgogICBzdWJzY3JpcHRpb246IE5FVENPTkYsIFNOTVAs IGFuZCBzeXNsb2ctY3JpdGljYWwgaW4gdGhpcyBleGFtcGxlLgoKJmx0O3JwYy1yZXBseSBtZXNz YWdlLWlkPSIxMDEiCiAgICAgICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6 bnM6bmV0Y29uZjpiYXNlOjEuMCImZ3Q7CiAgJmx0O2RhdGEmZ3Q7CiAgICAgJmx0O2V2ZW50U3Ry ZWFtcyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0aW9uIiZn dDsKICAgICAgICAmbHQ7c3RyZWFtJmd0OwogICAgICAgICAgICZsdDtuYW1lJmd0O05FVENPTkYm bHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgJmx0O2Rlc2NyaXB0aW9uJmd0O0RlZmF1bHQgbmV0Y29u ZiBldmVudCBzdHJlYW0KICAgICAgICAgICAmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAg ICZsdDtyZXBsYXlTdXBwb3J0Jmd0O3RydWUmbHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAg ICAgJmx0O3JlcGxheUxvZ1N0YXJ0VGltZSZndDsyMDA3LTA3LTA4VDAwOjAwOjAwWiZsdDsvcmVw bGF5TG9nU3RhcnRUaW1lJmd0OwogICAgICAgICZsdDsvc3RyZWFtJmd0OwogICAgICAgICZsdDtz dHJlYW0mZ3Q7CiAgICAgICAgICAgJmx0O25hbWUmZ3Q7U05NUCZsdDsvbmFtZSZndDsKICAgICAg ICAgICAmbHQ7ZGVzY3JpcHRpb24mZ3Q7U05NUCBub3RpZmljYXRpb25zJmx0Oy9kZXNjcmlwdGlv biZndDsKICAgICAgICAgICAmbHQ7cmVwbGF5U3VwcG9ydCZndDtmYWxzZSZsdDsvcmVwbGF5U3Vw cG9ydCZndDsKICAgICAgICAmbHQ7L3N0cmVhbSZndDsKICAgICAgICAmbHQ7c3RyZWFtJmd0Owog ICAgICAgICAgJmx0O25hbWUmZ3Q7c3lzbG9nLWNyaXRpY2FsJmx0Oy9uYW1lJmd0OwogICAgICAg ICAgJmx0O2Rlc2NyaXB0aW9uJmd0O0NyaXRpY2FsIGFuZCBoaWdoZXIgc2V2ZXJpdHkKICAgICAg ICAgICZsdDsvZGVzY3JpcHRpb24mZ3Q7CiAgICAgICAgICAmbHQ7cmVwbGF5U3VwcG9ydCZndDt0 cnVlJmx0Oy9yZXBsYXlTdXBwb3J0Jmd0OwogICAgICAgICAgJmx0O3JlcGxheUxvZ1N0YXJ0VGlt ZSZndDsyMDA3LTA3LTAxVDAwOjAwOjAwWiZsdDsvcmVwbGF5TG9nU3RhcnRUaW1lJmd0OwogICAg ICAgICZsdDsvc3RyZWFtJmd0OwogICAgICAmbHQ7L2V2ZW50U3RyZWFtcyZndDsKICAmbHQ7L2Rh dGEmZ3Q7CiZsdDsvcnBjLXJlcGx5Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgNgoKMy4yLjUuMi4gIEV2ZW50IFN0cmVhbSBTdWJzY3JpcHRpb24KCiAgIEEgTkVU Q09ORiBjbGllbnQgbWF5IHJlcXVlc3QgZnJvbSB0aGUgTkVUQ09ORiBzZXJ2ZXIgdGhlIGxpc3Qg b2YKICAgZXZlbnQgc3RyZWFtcyBhdmFpbGFibGUgdG8gdGhpcyBzZXNzaW9uIGFuZCB0aGVuIGlz c3VlIGEgJmx0O2NyZWF0ZS0KICAgc3Vic2NyaXB0aW9uJmd0OyByZXF1ZXN0IHdpdGggdGhlIGRl c2lyZWQgZXZlbnQgc3RyZWFtIG5hbWUuICBPbWl0dGluZwogICB0aGUgZXZlbnQgc3RyZWFtIG5h bWUgZnJvbSB0aGUgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IHJlcXVlc3QgcmVzdWx0cwog ICBpbiBzdWJzY3JpcHRpb24gdG8gdGhlIGRlZmF1bHQgTkVUQ09ORiBldmVudCBzdHJlYW0uCgoz LjIuNS4yLjEuICBGaWx0ZXJpbmcgRXZlbnQgU3RyZWFtIENvbnRlbnRzCgogICBUaGUgc2V0IG9m IGV2ZW50IG5vdGlmaWNhdGlvbnMgZGVsaXZlcmVkIGluIGFuIGV2ZW50IHN0cmVhbSBtYXkgYmUK ICAgZnVydGhlciByZWZpbmVkIGJ5IGFwcGx5aW5nIGEgdXNlci1zcGVjaWZpZWQgZmlsdGVyIGF0 IHN1YnNjcmlwdGlvbgogICBjcmVhdGlvbiB0aW1lICggJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24m Z3Q7ICkuICBUaGlzIGlzIGEgdHJhbnNpZW50IGZpbHRlcgogICBhc3NvY2lhdGVkIHdpdGggdGhl IGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gYW5kIGRvZXMgbm90CiAgIG1vZGlmeSB0 aGUgZXZlbnQgc3RyZWFtIGNvbmZpZ3VyYXRpb24uICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bic+RWl0aGVyIHN1YnRyZWUgb3IgWFBBVEgKICAgZmlsdGVyaW5nIGNhbiBiZSB1c2VkLjwvZm9u dD48L3N0cm9uZz4KCiAgIFhQQVRIIHN1cHBvcnQgZm9yIHRoZSBOb3RpZmljYXRpb24gY2FwYWJp bGl0eSBpcyBhZHZlcnRpc2VkIGFzIHBhcnQKICAgb2YgdGhlIG5vcm1hbCBYUEFUSCBjYXBhYmls aXR5IGFkdmVydGlzZW1lbnQuICBJZiBYUEFUSCBzdXBwb3J0IGlzCiAgIGFkdmVydGlzZWQgdmlh IHRoZSBYUEFUSCBjYXBhYmlsaXR5IHRoZW4gWFBBVEggaXMgc3VwcG9ydGVkIGZvcgogICBub3Rp ZmljYXRpb24gZmlsdGVyaW5nIGFuZCBpZiB0aGlzIGNhcGFiaWxpdHkgaXMgbm90IGFkdmVydGlz ZWQsIHRoZW4KICAgWFBBVEggaXMgbm90IHN1cHBvcnRlZCBmb3Igbm90aWZpY2F0aW9uIGZpbHRl cmluZy4KCjMuMy4gICBOb3RpZmljYXRpb24gUmVwbGF5CgozLjMuMS4gIE92ZXJ2aWV3CgogICBS ZXBsYXkgaXMgdGhlIGFiaWxpdHkgdG8gY3JlYXRlIGFuIGV2ZW50IHN1YnNjcmlwdGlvbiB0aGF0 IHdpbGwKICAgcmVzZW5kIHJlY2VudGx5IGdlbmVyYXRlZCBub3RpZmljYXRpb25zLCBvciBpbiBz b21lIGNhc2VzIHNlbmQgdGhlbQogICBmb3IgdGhlIGZpcnN0IHRpbWUgdG8gYSBwYXJ0aWN1bGFy IE5FVENPTkYgY2xpZW50LiAgVGhlc2UKICAgbm90aWZpY2F0aW9ucyBhcmUgc2VudCB0aGUgc2Ft ZSB3YXkgYXMgbm9ybWFsIG5vdGlmaWNhdGlvbnMuCgogICBBIHJlcGxheSBvZiBub3RpZmljYXRp b25zIGlzIHNwZWNpZmllZCBieSBpbmNsdWRpbmcgYW4gb3B0aW9uYWwKICAgcGFyYW1ldGVyIHRv IHRoZSBzdWJzY3JpcHRpb24gY29tbWFuZCB0aGF0IGluZGljYXRlcyB0aGUgc3RhcnQgdGltZQog ICBvZiB0aGUgcmVwbGF5LiAgVGhlIGVuZCB0aW1lIGlzIHNwZWNpZmllZCB1c2luZyB0aGUgb3B0 aW9uYWwgc3RvcFRpbWUKICAgcGFyYW1ldGVyLiAgSWYgbm90IHByZXNlbnQsIG5vdGlmaWNhdGlv bnMgd2lsbCBjb250aW51ZSB0byBiZSBzZW50CiAgIHVudGlsIHRoZSBzdWJzY3JpcHRpb24gaXMg dGVybWluYXRlZC4KCiAgIEEgbm90aWZpY2F0aW9uIHN0cmVhbSB0aGF0IHN1cHBvcnRzIHJlcGxh eSBpcyBub3QgZXhwZWN0ZWQgdG8gaGF2ZSBhbgogICB1bmxpbWl0ZWQgc3VwcGx5IG9mIHNhdmVk IG5vdGlmaWNhdGlvbnMgYXZhaWxhYmxlIHRvIGFjY29tbW9kYXRlIGFueQogICByZXBsYXkgcmVx dWVzdC4KCiAgIFRoZSBhY3R1YWwgbnVtYmVyIG9mIHN0b3JlZCBub3RpZmljYXRpb25zIGF2YWls YWJsZSBmb3IgcmV0cmlldmFsIGF0CiAgIGFueSBnaXZlbiB0aW1lIGlzIGEgTkVUQ09ORiBzZXJ2 ZXIgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgbWF0dGVyLgogICBDb250cm9sIHBhcmFtZXRlcnMg Zm9yIHRoaXMgYXNwZWN0IG9mIHRoZSBmZWF0dXJlIGFyZSBvdXRzaWRlIHRoZQogICBzY29wZSBv ZiB0aGUgY3VycmVudCBkb2N1bWVudC4KCiAgIFJlcGxheSBpcyBkZXBlbmRlbnQgb24gYSBub3Rp ZmljYXRpb24gc3RyZWFtIHN1cHBvcnRpbmcgc29tZSBmb3JtIG9mCiAgIG5vdGlmaWNhdGlvbiBs b2dnaW5nLCBhbHRob3VnaCBpdCBwdXRzIG5vIHJlc3RyaWN0aW9ucyBvbiB0aGUgc2l6ZSBvcgog ICBmb3JtIG9mIHRoZSBsb2csIG5vciB3aGVyZSBpdCByZXNpZGVzIHdpdGhpbiB0aGUgZGV2aWNl LiAgV2hldGhlciBvcgogICBub3QgYSBzdHJlYW0gc3VwcG9ydHMgcmVwbGF5IGNhbiBiZSBkaXNj b3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsKICAgb3BlcmF0aW9uIG9uIHRoZSBldmVudFN0 cmVhbXMgZWxlbWVudCBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQKICAgU2NoZW1hLiAg VGhpcyBzY2hlbWEgYWxzbyBwcm92aWRlcyB0aGUgcmVwbGF5TG9nU3RhcnRUaW1lIGVsZW1lbnQg dG8KICAgaW5kaWNhdGUgdGhlIGVhcmxpZXN0IGF2YWlsYWJsZSBsb2dnZWQgbm90aWZpY2F0aW9u LgoKMy4zLjIuICBDcmVhdGluZyBhIFN1YnNjcmlwdGlvbiB3aXRoIFJlcGxheQoKICAgVGhpcyBm ZWF0dXJlIHVzZXMgb3B0aW9uYWwgcGFyYW1ldGVycyB0byB0aGUgJmx0O2NyZWF0ZS1zdWJzY3Jp cHRpb24mZ3Q7CiAgIGNvbW1hbmQgY2FsbGVkIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+J3N0 YXJ0VGltZSc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zdGFy dFRpbWU8L2ZvbnQ+PC9zdHJvbmc+IGFuZCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPidzdG9w VGltZScuICdzdGFydFRpbWUnPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbic+c3RvcFRpbWUuIHN0YXJ0VGltZTwvZm9udD48L3N0cm9uZz4gaWRlbnRpZmllcyB0aGUK ICAgZWFybGllc3QgZGF0ZSBhbmQgdGltZSBvZiBpbnRlcmVzdCBmb3IgZXZlbnQgbm90aWZpY2F0 aW9ucyBiZWluZwogICByZXBsYXllZCBhbmQgYWxzbyBpbmRpY2F0ZXMgdGhhdCBhIHN1YnNjcmlw dGlvbiB3aWxsIGJlIHByb3ZpZGluZwogICByZXBsYXkgb2Ygbm90aWZpY2F0aW9ucy4gIEV2ZW50 cyBnZW5lcmF0ZWQgYmVmb3JlIHRoaXMgdGltZSBhcmUgbm90CiAgIG1hdGNoZWQuIDxzdHJpa2U+ PGZvbnQgY29sb3I9J3JlZCc+J3N0b3BUaW1lJzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u dCBjb2xvcj0nZ3JlZW4nPnN0b3BUaW1lPC9mb250Pjwvc3Ryb25nPiBzcGVjaWZpZXMgdGhlIGxh dGVzdCBkYXRlIGFuZCB0aW1lIG9mIGludGVyZXN0IGZvcgogICBldmVudCBub3RpZmljYXRpb25z IGJlaW5nIHJlcGxheWVkLiAgSWYgaXQgaXMgbm90IHByZXNlbnQsIHRoZW4KICAgbm90aWZpY2F0 aW9ucyB3aWxsIGNvbnRpbnVlIHRvIGJlIHNlbnQgdW50aWwgdGhlIHN1YnNjcmlwdGlvbiBpcwog ICB0ZXJtaW5hdGVkLgoKICAgTm90ZSB0aGF0IHN0YXJ0VGltZSBhbmQgc3RvcFRpbWUgYXJlIGFz c29jaWF0ZWQgd2l0aCB0aGUgdGltZSBhbgogICBldmVudCB3YXMgZ2VuZXJhdGVkIGJ5IHRoZSBz eXN0ZW0uCgogICBBIHJlcGxheUNvbXBsZXRlIG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIGluZGlj YXRlIHRoYXQgYWxsIG9mIHRoZQogICByZXBsYXkgbm90aWZpY2F0aW9ucyBoYXZlIGJlZW4gc2Vu dC4gIElmIHRoaXMgc3Vic2NyaXB0aW9uIGhhcyBhIHN0b3AKICAgdGltZSwgdGhlbiB0aGlzIHNl c3Npb24gYmVjb21lcyBhIG5vcm1hbCBORVRDT05GIHNlc3Npb24gYWdhaW4uICBJbgogICB0aGUg Y2FzZSBvZiBhIHN1YnNjcmlwdGlvbiB3aXRob3V0IGEgc3RvcCB0aW1lLCBhZnRlciB0aGUKICAg cmVwbGF5Q29tcGxldGUgbm90aWZpY2F0aW9uIGhhcyBiZWVuIHNlbnQsIGl0IGNhbiBiZSBleHBl Y3RlZCB0aGF0CiAgIGFueSBub3RpZmljYXRpb25zIGdlbmVyYXRlZCBzaW5jZSB0aGUgc3RhcnQg b2YgdGhlIHN1YnNjcmlwdGlvbgogICBjcmVhdGlvbiB3aWxsIGJlIHNlbnQgZm9sbG93ZWQgYnkg bm90aWZpY2F0aW9ucyBhcyB0aGV5IGFyaXNlCiAgIG5hdHVyYWxseSB3aXRoaW4gdGhlIHN5c3Rl bS4KCjxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+My4zLjMuICBSZXBsYXkgQ29tcGxldGUgTm90 aWZpY2F0aW9uCgogICBUaGUgcmVwbGF5Q29tcGxldGUgbm90aWZpY2F0aW9uIGlzIHRoZSBsYXN0 IG5vdGlmaWNhdGlvbiBzZW50IG92ZXIgYQogICByZXBsYXkgc3Vic2NyaXB0aW9uLiAgSXQgaW5k aWNhdGVzIHRoYXQgcmVwbGF5IGlzIGNvbXBsZXRlLiAgQWZ0ZXIKICAgdGhpcyBub3RpZmljYXRp b24gaXMgcmVjZWl2ZWQgdGhlIHN1YnNjcmlwdGlvbiBpcyB0ZXJtaW5hdGVkIGFuZCB0aGUKICAg c2Vzc2lvbiBiZWNvbWVzIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNlIE5FVENPTkYgc2Vzc2lvbi48 L2ZvbnQ+PC9zdHJpa2U+CgogICBUaGUgcmVwbGF5Q29tcGxldGUgY2FuIG5vdCBiZSBmaWx0ZXJl ZCBvdXQuICBJdCB3aWxsIGFsd2F5cyBiZSBzZW50CiAgIG9uIGEgcmVsYXkgc3Vic2NyaXB0aW9u IHRoYXQgc3BlY2lmaWVkIGEgc3RvcCB0aW1lLgoKMy40LiAgTm90aWZpY2F0aW9uIE1hbmFnZW1l bnQgU2NoZW1hCgogICBUaGlzIFNjaGVtYSBpcyB1c2VkIHRvIGxlYXJuIGFib3V0IHRoZSBldmVu dCBzdHJlYW1zIHN1cHBvcnRlZCBvbiB0aGUKICAgc3lzdGVtLiAgSXQgYWxzbyBjb250YWlucyB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUgcmVwbGF5Q29tcGxldGUsIHdoaWNoCiAgIGlzIHNlbnQgdG8g aW5kaWNhdGUgdGhhdCBhbiBldmVudCByZXBsYXkgaGFzIHNlbnQgYWxsIGFwcGxpY2FibGUKICAg bm90aWZpY2F0aW9ucy4iCgombHQ7P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/ Jmd0OwombHQ7eHM6c2NoZW1hIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNj aGVtYSIKICAgIHhtbG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpi YXNlOjEuMCIKICAgIHhtbG5zOm5jRXZlbnQ9InVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFi aWxpdHk6bm90aWZpY2F0aW9uOjEuMCIKICAgIHhtbG5zOm1hbmFnZUV2ZW50PSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOm5ldG1vZDpub3RpZmljYXRpb24iCiAgICB0YXJnZXROYW1lc3BhY2U9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlvbiIKICAgIGVsZW1lbnRGb3Jt RGVmYXVsdD0icXVhbGlmaWVkIgogICAgYXR0cmlidXRlRm9ybURlZmF1bHQ9InVucXVhbGlmaWVk IiZndDsKICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICZsdDt4czpkb2N1bWVudGF0 aW9uIHhtbDpsYW5nPSJlbiImZ3Q7CiAgICAgICAgICAgIEEgc2NoZW1hIHRoYXQgY2FuIGJlIHVz ZWQgdG8gbGVhcm4gYWJvdXQgY3VycmVudAogICAgICAgICAgICBldmVudCBzdHJlYW1zLiBJdCBh bHNvCiAgICAgICAgICAgIGNvbnRhaW5zIHRoZSByZXBsYXlDb21wbGV0ZSBub3RpZmljYXRpb24u CiAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgJmx0Oy94czphbm5vdGF0aW9u Jmd0OwoKJmx0O3hzOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4 L25hbWVzcGFjZSIKICAgICAgICBzY2hlbWFMb2NhdGlvbj0iaHR0cDovL3d3dy53My5vcmcvMjAw MS94bWwueHNkIi8mZ3Q7CiZsdDt4czppbXBvcnQgbmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICBzY2hlbWFMb2NhdGlvbj0KICAgICAiaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy94bWwtcmVnaXN0cnkvc2NoZW1hL25ldGNvbmYueHNk Ii8mZ3Q7CiZsdDt4czppbXBvcnQgbmFtZXNwYWNlPQogICAgInVybjppZXRmOnBhcmFtczpuZXRj b25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMCIKICAgICAgc2NoZW1hTG9jYXRpb249CiJo dHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbm90aWZp Y2F0aW9uLnhzZCIvJmd0OwoKJmx0O3hzOmVsZW1lbnQgbmFtZT0ibmV0Y29uZiIgdHlwZT0ibWFu YWdlRXZlbnQ6TmV0Y29uZiIvJmd0OwoKJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9Ik5ldGNvbmYi Jmd0OwogICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZXZl bnRTdHJlYW1zIiAmZ3Q7CiAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAg Jmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICBUaGUgbGlzdCBvZiBldmVudCBz dHJlYW1zIHN1cHBvcnRlZCBieSB0aGUKICAgICAgICAgICAgIHN5c3RlbS4gV2hlbiBhIHF1ZXJ5 IGlzIGlzc3VlZCwgdGhlIHJldHVybmVkCiAgICAgICAgICAgICBzZXQgb2Ygc3RyZWFtcyBpcyBk ZXRlcm1pbmVkIGJhc2VkIG9uIHVzZXIKICAgICAgICAgICAgIHByaXZpbGVnZXMuCiAgICAgICAg ICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24m Z3Q7CiAgICAgICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgICAgICAmbHQ7eHM6c2Vx dWVuY2UgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5taW5PY2N1cnM9IjAiPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+bWluT2NjdXJzPSIxIjwvZm9udD48L3N0 cm9uZz4gbWF4T2NjdXJzPSJ1bmJvdW5kZWQiJmd0OwogICAgICAgICAgICAgJmx0O3hzOmVsZW1l bnQgbmFtZT0ic3RyZWFtIiZndDsKICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAg ICAgICAgICBTdHJlYW0gbmFtZSBhbmQgZGVzY3JpcHRpb24uCiAgICAgICAgICAgICAgICAgICZs dDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICZsdDsveHM6YW5ub3RhdGlv biZndDsKICAgICAgICAgICAgICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgICAgICAg ICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDt4czplbGVt ZW50IG5hbWU9Im5hbWUiIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+dHlwZT0ieHM6c3RyaW5n Ii8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPnR5cGU9Im5jRXZlbnQ6c3RyZWFtTmFtZVR5cGUiLyZndDs8 L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0i ZGVzY3JpcHRpb24iCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBl PSJ4czpzdHJpbmciLyZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1l PSJyZXBsYXlTdXBwb3J0IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dHlwZT0ieHM6Ym9vbGVhbiIvJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDt4czplbGVtZW50 IG5hbWU9InJlcGxheUxvZ1N0YXJ0VGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAgICAgICAgICAg ICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7 eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHN0YXJ0 IHRpbWUgb2YgdGhlIGxvZyB1c2VkIHRvCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1cHBv cnQgdGhlIHJlcGxheSBmdW5jdGlvbi4gVGhpcwogICAgICAgICAgICAgICAgICAgICAgICAgICBv YmplY3QgTVVTVCBiZSBwcmVzZW50IGlmIHJlcGxheSBpcwogICAgICAgICAgICAgICAgICAgICAg ICAgICBzdXBwb3J0ZWQuCiAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50 YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0Owog ICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAgICAgICAgICAgICAg ICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgICAgICAgICAgICAgICZsdDsveHM6Y29tcGxleFR5 cGUmZ3Q7CiAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAgICZs dDsveHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAg ICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAgICZs dDsveHM6Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9IlJlcGxh eUNvbXBsZXRlTm90aWZpY2F0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOmNvbXBsZXhDb250 ZW50Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9Im5jRXZlbnQ6Tm90aWZp Y2F0aW9uQ29udGVudFR5cGUiLyZndDsKICAgICAgICAmbHQ7L3hzOmNvbXBsZXhDb250ZW50Jmd0 OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJy ZXBsYXlDb21wbGV0ZSIKICAgICAgICB0eXBlPSJtYW5hZ2VFdmVudDpSZXBsYXlDb21wbGV0ZU5v dGlmaWNhdGlvblR5cGUiCiAgICAgICAgc3Vic3RpdHV0aW9uR3JvdXA9Im5jRXZlbnQ6bm90aWZp Y2F0aW9uQ29udGVudCImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsK ICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICBUaGlzIG5vdGlm aWNhdGlvbiBpcyBzZW50IHRvIHNpZ25hbCB0aGUgZW5kIG9mIGEgcmVwbGF5CiAgICAgICAgICAg IHBvcnRpb24gb2YgYSBzdWJzY3JpcHRpb24uCiAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRp b24mZ3Q7CiAgICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwoKICAgICAgICAmbHQ7L3hzOmVs ZW1lbnQmZ3Q7CiZsdDsveHM6c2NoZW1hJmd0OwoKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRmlndXJlIDcKCjMuNS4gIFN1YnNjcmlwdGlvbnMgRGF0YQoKICAgV2hpbGUgaXQgbWF5 IGJlIHBvc3NpYmxlIHRvIHJldHJpZXZlIGluZm9ybWF0aW9uIGFib3V0IHN1YnNjcmlwdGlvbnMK ICAgdmlhIGEgZ2V0IG9wZXJhdGlvbiwgc3Vic2NyaXB0aW9ucyBhcmUgbm90IHN0b3JlZCBjb25m aWd1cmF0aW9uLgogICBUaGV5IGFyZSBub24tcGVyc2lzdGVudCBzdGF0ZSBpbmZvcm1hdGlvbiBh bmQgdGhlaXIgbGlmZXRpbWUgaXMKICAgZGVmaW5lZCBieSB0aGVpciBzZXNzaW9uLgoKMy42LiAg RmlsdGVyIE1lY2hhbmljcwoKICAgV2hlbiBtdWx0aXBsZSBmaWx0ZXIgZWxlbWVudHMgYXJlIHNw ZWNpZmllZCwgdGhleSBhcmUgYXBwbGllZAogICBjb2xsZWN0aXZlbHksIHNvIGV2ZW50IG5vdGlm aWNhdGlvbnMgbmVlZCB0byBwYXNzIGFsbCBzcGVjaWZpZWQKICAgZmlsdGVycyBpbiBvcmRlciB0 byBiZSBzZW50IHRvIHRoZSBzdWJzY3JpYmVyLiAgSWYgYSBmaWx0ZXIgZWxlbWVudAogICBpcyBz cGVjaWZpZWQgdG8gbG9vayBmb3IgZGF0YSBvZiBhIHBhcnRpY3VsYXIgdmFsdWUsIGFuZCB0aGUg ZGF0YQogICBpdGVtIGlzIG5vdCBwcmVzZW50IHdpdGhpbiBhIHBhcnRpY3VsYXIgZXZlbnQgbm90 aWZpY2F0aW9uIGZvciBpdHMKICAgdmFsdWUgdG8gYmUgY2hlY2tlZCBhZ2FpbnN0LCB0aGUgbm90 aWZpY2F0aW9uIHdpbGwgYmUgZmlsdGVyZWQgb3V0LgogICBGb3IgZXhhbXBsZSwgaWYgb25lIHdl cmUgdG8gY2hlY2sgZm9yICdzZXZlcml0eT1jcml0aWNhbCcgaW4gYQogICBjb25maWd1cmF0aW9u IGV2ZW50IG5vdGlmaWNhdGlvbiB3aGVyZSB0aGlzIGZpZWxkIHdhcyBub3Qgc3VwcG9ydGVkLAog ICB0aGVuIHRoZSBub3RpZmljYXRpb24gd291bGQgYmUgZmlsdGVyZWQgb3V0LgoKICAgVGhlIG9y ZGVyIHRoYXQgZmlsdGVyIGVsZW1lbnRzIGFyZSBhcHBsaWVkIGRvZXMgbm90IG1hdHRlciBzaW5j ZSB0aGUKICAgcmVzdWx0aW5nIHNldCBvZiBub3RpZmljYXRpb25zIGlzIHRoZSBpbnRlcnNlY3Rp b24gb2YgdGhlIHNldCBvZgogICBub3RpZmljYXRpb25zIHRoYXQgcGFzcyBlYWNoIGZpbHRlcmlu ZyBjcml0ZXJpYS4KCjMuNi4xLiAgRmlsdGVyaW5nCgogICBGaWx0ZXJpbmcgaXMgZXhwbGljaXRs eSBzdGF0ZWQgd2hlbiB0aGUgZXZlbnQgbm90aWZpY2F0aW9uCiAgIHN1YnNjcmlwdGlvbiBpcyBj cmVhdGVkLiAgVGhpcyBpcyBzcGVjaWZpZWQgdmlhIHRoZSAnZmlsdGVyJwogICBwYXJhbWV0ZXIu ICBGaWx0ZXJzIG9ubHkgZXhpc3QgYXMgcGFyYW1ldGVycyB0byB0aGUgc3Vic2NyaXB0aW9uLgoK My43LiAgTWVzc2FnZSBGbG93CiAgIFRoZSBmb2xsb3dpbmcgZmlndXJlIGRlcGljdHMgbWVzc2Fn ZSBmbG93IGJldHdlZW4gYSBORVRDT05GIGNsaWVudAogICAoQykgYW5kIE5FVENPTkYgc2VydmVy IChTKSBpbiBvcmRlciBjcmVhdGUgYSBzdWJzY3JpcHRpb24gYW5kIGJlZ2luCiAgIHRoZSBmbG93 IG9mIG5vdGlmaWNhdGlvbnMuICBJdCBpcyBwb3NzaWJsZSB0aGF0IG1hbnkgcnBjL3JwYy1yZXBs eQogICBzZXF1ZW5jZXMgb2NjdXIgYmVmb3JlIHRoZSBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCBv ciBhZnRlciBhCiAgIHN0b3BUaW1lIGluIGEgcmVwbGF5IHN1YnNjcmlwdGlvbiwgYnV0IHRoaXMg aXMgbm90IGRlcGljdGVkIGluIHRoZQogICBmaWd1cmUuCgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEMgICAgICAgICAgICAgICAgICAgICAgICAgICBTCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICBjYXBhYmlsaXR5IGV4Y2hhbmdlICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0 OyAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJmd0O3wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICZsdDty cGMtcmVwbHkmZ3Q7ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZn dDsgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSA4Cgo0LiAgWE1MIFNjaGVtYSBmb3IgRXZlbnQgTm90aWZpY2F0aW9ucwoKICAgVGhlIGZv bGxvd2luZyBbWE1MIFNjaGVtYV0gZGVmaW5lcyBORVRDT05GIEV2ZW50IE5vdGlmaWNhdGlvbnMu CgombHQ7P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwogICZsdDt4czpz Y2hlbWEgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgICAg IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjox LjAiCiAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25m OmJhc2U6MS4wIgogICAgICAgIHRhcmdldE5hbWVzcGFjZT0KICAgICAgICAgICJ1cm46aWV0Zjpw YXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAiCiAgICAgICAgZWxlbWVu dEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiCiAgICAgICAgYXR0cmlidXRlRm9ybURlZmF1bHQ9InVu cXVhbGlmaWVkIgogICAgICAgICAgICB4bWw6bGFuZz0iZW4iJmd0OwoKICAgICZsdDshLS0gaW1w b3J0IHN0YW5kYXJkIFhNTCBkZWZpbml0aW9ucyAtLSZndDsKCiAgICAgJmx0O3hzOmltcG9ydCBu YW1lc3BhY2U9Imh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZSIKICAgICAgICAg ICAgICAgIHNjaGVtYUxvY2F0aW9uPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL3htbC54c2QiJmd0 OwogICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICZsdDt4czpkb2N1bWVudGF0 aW9uJmd0OwogICAgICAgICAgIFRoaXMgaW1wb3J0IGFjY2Vzc2VzIHRoZSB4bWw6IGF0dHJpYnV0 ZSBncm91cHMgZm9yIHRoZQogICAgICAgICAgIHhtbDpsYW5nIGFzIGRlY2xhcmVkIG9uIHRoZSBl cnJvci1tZXNzYWdlIGVsZW1lbnQuCiAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAmbHQ7L3hzOmltcG9ydCZndDsKCiAg ICAgJmx0OyEtLSBpbXBvcnQgYmFzZSBuZXRjb25mIGRlZmluaXRpb25zIC0tJmd0OwogICAgICZs dDt4czppbXBvcnQgbmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFz ZToxLjAiCiAgICAgICBzY2hlbWFMb2NhdGlvbj0KICAgICAiaHR0cDovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy94bWwtcmVnaXN0cnkvc2NoZW1hL25ldGNvbmYueHNkIi8mZ3Q7CgombHQ7IS0t ICoqKioqKioqKioqKioqIFN5bW1ldHJpY2FsIE9wZXJhdGlvbnMgICoqKioqKioqKioqKioqKioq KioqLS0mZ3Q7CgogICAgICZsdDshLS0gJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IG9wZXJh dGlvbiAtLSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iY3JlYXRlU3Vic2NyaXB0 aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOmNvbXBsZXhDb250ZW50Jmd0OwogICAgICAgICAg ICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9Im5ldGNvbmY6cnBjT3BlcmF0aW9uVHlwZSImZ3Q7CiAg ICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0 O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIgogICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJz dHJlYW1OYW1lVHlwZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAgICAgICAgICAgICAgICAgICAg Jmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6 ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuIG9wdGlv bmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgd2hpY2ggc3RyZWFtIG9mIGV2ZW50cyBpcyBvZiBpbnRlcmVzdC4gSWYKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG5vdCBwcmVzZW50LCB0aGVuIGV2ZW50cyBpbiB0aGUgZGVmYXVs dAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkVUQ09ORiBzdHJlYW0gd2lsbCBiZSBz ZW50LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAm bHQ7eHM6ZWxlbWVudCBuYW1lPSJmaWx0ZXIiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 eXBlPSJuZXRjb25mOmZpbHRlcklubGluZVR5cGUiCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBtaW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFu bm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3Vt ZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuIG9wdGlv bmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB3aGljaCBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlIGV2ZW50cwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBhcmUgb2YgaW50ZXJlc3QuIFRoZSBmb3JtYXQgb2YgdGhp cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJhbWV0ZXIgaXMgdGhlIHNh bWUgYXMgdGhhdCBvZiB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmls dGVyIHBhcmFtZXRlciBpbiB0aGUgTkVUQ09ORgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBwcm90b2NvbCBvcGVyYXRpb25zLiBJZiBub3QgcHJlc2VudCwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYWxsIGV2ZW50cyBub3QgcHJlY2x1ZGVkIGJ5IG90aGVy CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlcnMgd2lsbCBiZSBz ZW50LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsK ICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAg ICAgICAgICZsdDt4czplbGVtZW50IG5hbWU9InN0YXJ0VGltZSIgdHlwZT0ieHM6ZGF0ZVRpbWUi CiAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgJmd0OwogICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEEgcGFyYW1ldGVyIHVzZWQgdG8gdHJpZ2dlciB0aGUgcmVwbGF5CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZmVhdHVyZSBhbmQgaW5kaWNhdGVzIHRoYXQgdGhlIHJlcGxheQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBzdGFydCBhdCB0aGUgdGltZSBz cGVjaWZpZWQuIElmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RhcnQgdGltZSBp cyBub3QgcHJlc2VudCwgdGhpcyBpcyBub3QgYQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHJlcGxheSBzdWJzY3JpcHRpb24uCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7 L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6YW5u b3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAg ICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RvcFRpbWUiIHR5cGU9InhzOmRh dGVUaW1lIgogICAgICAgICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiICZndDsKICAgICAg ICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBbiBvcHRpb25hbCBwYXJhbWV0ZXIgdXNlZCB3aXRoIHRoZQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsIHJlcGxheSBmZWF0dXJlIHRvIGluZGljYXRl IHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5ld2VzdCBub3RpZmljYXRpb25z IG9mIGludGVyZXN0LiBJZgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0b3AgdGlt ZSBpcyBub3QgcHJlc2VudCwgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90 aWZpY2F0aW9ucyB3aWxsIGNvbnRpbnVlIHVudGlsIHRoZQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN1YnNjcmlwdGlvbiBpcyB0ZXJtaW5hdGVkLiBNdXN0IGJlIHVzZWQKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ J3N0YXJ0VGltZScuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ c3RhcnRUaW1lLjwvZm9udD48L3N0cm9uZz4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZs dDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czph bm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAg ICAgICAgICAgICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICZsdDsveHM6ZXh0 ZW5zaW9uJmd0OwogICAgICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAmbHQ7L3hz OmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4czpzaW1wbGVUeXBlIG5hbWU9InN0cmVhbU5hbWVU eXBlIiZndDsKICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgJmx0O3hz OmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICBUaGUgbmFtZSBvZiBhbiBldmVudCBz dHJlYW0uCiAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAmbHQ7 L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0O3hzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0 cmluZyIvJmd0OwogICAgJmx0Oy94czpzaW1wbGVUeXBlJmd0OwoKICAgICZsdDt4czplbGVtZW50 IG5hbWU9ImNyZWF0ZS1zdWJzY3JpcHRpb24iCiAgICAgICAgdHlwZT0iY3JlYXRlU3Vic2NyaXB0 aW9uVHlwZSIKICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmV0Y29uZjpycGNPcGVyYXRpb24i Jmd0OwogICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAmbHQ7eHM6ZG9j dW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgIFRoZSBjb21tYW5kIHRvIGNyZWF0ZSBhIG5v dGlmaWNhdGlvbiBzdWJzY3JpcHRpb24uIEl0CiAgICAgICAgICAgICAgICB0YWtlcyBhcyBhcmd1 bWVudCB0aGUgbmFtZSBvZiB0aGUgbm90aWZpY2F0aW9uIHN0cmVhbQogICAgICAgICAgICAgICAg YW5kICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmZpbHRlciBvciBwcm9maWxlIGluZm9ybWF0 aW9uLjwvZm9udD48L3N0cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5maWx0ZXIu PC9mb250Pjwvc3Ryb25nPiBBbGwgb2YgdGhvc2Ugb3B0aW9ucwogICAgICAgICAgICAgICAgbGlt aXQgdGhlIGNvbnRlbnQgb2YgdGhlIHN1YnNjcmlwdGlvbi4gSW4gYWRkaXRpb24sCiAgICAgICAg ICAgICAgICB0aGVyZSBhcmUgdHdvIHRpbWUtcmVsYXRlZCBwYXJhbWV0ZXJzIHN0YXJ0VGltZSBh bmQKICAgICAgICAgICAgICAgIHN0b3BUaW1lIHdoaWNoIGNhbiBiZSB1c2VkIHRvIHNlbGVjdCB0 aGUgdGltZSBpbnRlcnZhbAogICAgICAgICAgICAgICAgb2YgaW50ZXJlc3QuCiAgICAgICAgICAg ICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7 CiAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CgombHQ7IS0tICoqKioqKioqKioqKioqIE9uZS13YXkg T3BlcmF0aW9ucyAgKioqKioqKioqKioqKioqKioqLS0mZ3Q7CgogICAgICZsdDshLS0gJmx0O05v dGlmaWNhdGlvbiZndDsgb3BlcmF0aW9uIC0tJmd0OwogICAgICZsdDt4czpjb21wbGV4VHlwZSBu YW1lPSJOb3RpZmljYXRpb25Db250ZW50VHlwZSIvJmd0OwoKICAgICZsdDt4czplbGVtZW50IG5h bWU9Im5vdGlmaWNhdGlvbkNvbnRlbnQiCiAgICAgICAgdHlwZT0iTm90aWZpY2F0aW9uQ29udGVu dFR5cGUiIGFic3RyYWN0PSJ0cnVlIi8mZ3Q7CgogICAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9 Ik5vdGlmaWNhdGlvblR5cGUiJmd0OwogICAgICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAg ICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJub3RpZmljYXRpb25Db250ZW50Ii8mZ3Q7CiAgICAg ICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CgogICAg Jmx0O3hzOmVsZW1lbnQgbmFtZT0ibm90aWZpY2F0aW9uIiB0eXBlPSJOb3RpZmljYXRpb25UeXBl Ii8mZ3Q7CiAgJmx0Oy94czpzY2hlbWEmZ3Q7CgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgOQoKNS4gIEZpbHRlcmluZyBFeGFtcGxlcwoKICAgVGhlIGZvbGxvd2luZyBz ZWN0aW9uIHByb3ZpZGVzIGV4YW1wbGVzIHRvIGlsbHVzdHJhdGUgdGhlIHZhcmlvdXMKICAgbWV0 aG9kcyBvZiBmaWx0ZXJpbmcgY29udGVudCBvbiBhbiBldmVudCBub3RpZmljYXRpb24gc3Vic2Ny aXB0aW9uLgoKNS4xLiAgU3VidHJlZSBGaWx0ZXJpbmcKCiAgIFhNTCBzdWJ0cmVlIGZpbHRlcmlu ZyBpcyBub3Qgd2VsbCBzdWl0ZWQgZm9yIGNyZWF0aW5nIGVsYWJvcmF0ZQogICBmaWx0ZXIgZGVm aW5pdGlvbnMgZ2l2ZW4gdGhhdCBpdCBvbmx5IHN1cHBvcnRzIGVxdWFsaXR5IGNvbXBhcmlzb25z CiAgIGFuZCA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+YXBwbGljYXRpb24gb2YgdGhlPC9m b250Pjwvc3Ryb25nPiBsb2dpY2FsIE9SIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+b3BlcmF0 aW9uczwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPm9wZXJhdG9y czwvZm9udD48L3N0cm9uZz4gKGUuZy4sIGluIGFuIGV2ZW50CiAgIHN1YnRyZWUgZ2l2ZSBtZSBh bGwgZXZlbnQgbm90aWZpY2F0aW9ucyB3aGljaCBoYXZlIHNldmVyaXR5PWNyaXRpY2FsCiAgIG9y IHNldmVyaXR5PW1ham9yIG9yIHNldmVyaXR5PW1pbm9yKS4gIE5ldmVydGhlbGVzcywgaXQgbWF5 IGJlIHVzZWQKICAgZm9yIGRlZmluaW5nIHNpbXBsZSBldmVudCBub3RpZmljYXRpb24gZm9yd2Fy ZGluZyBmaWx0ZXJzIGFzIHNob3duCiAgIGJlbG93LgoKICAgSW4gb3JkZXIgdG8gaWxsdXN0cmF0 ZSB0aGUgdXNlIG9mIGZpbHRlciBleHByZXNzaW9ucyBpdCBpcyBuZWNlc3NhcnkKICAgdG8gYXNz dW1lIHNvbWUgb2YgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBjb250ZW50LiAgVGhlIGV4YW1wbGVz CiAgIGhlcmVpbiBhc3N1bWUgdGhhdCB0aGUgZXZlbnQgbm90aWZpY2F0aW9uIHNjaGVtYSBkZWZp bml0aW9uIGhhcyBhbgogICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPiZsdDtldmVudHMmZ3Q7 PC9mb250Pjwvc3RyaWtlPgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O2V2ZW50 Jmd0OzwvZm9udD48L3N0cm9uZz4gZWxlbWVudCBhdCB0aGUgdG9wIGxldmVsIDxzdHJpa2U+PGZv bnQgY29sb3I9J3JlZCc+dGhhdCBjb250YWlucyBvbmUgb3IgbW9yZSBjaGlsZAogICBlbGVtZW50 cyAmbHQ7ZXZlbnRFbnRyeSZndDs8L2ZvbnQ+PC9zdHJpa2U+IGNvbnNpc3Rpbmcgb2YgdGhlIGV2 ZW50IGNsYXNzIChlLmcuLAogICBmYXVsdCwgc3RhdGUsIGNvbmZpZywgZXRjLikgcmVwb3J0aW5n IGVudGl0eSBhbmQgZWl0aGVyIHNldmVyaXR5IG9yCiAgIG9wZXJhdGlvbmFsIHN0YXRlLgoKICAg U2FtcGxlIGV2ZW50IGxpc3QKCiAgICAgICAgICAgICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJo dHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgICAgICAgICAgICZs dDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgICAgICAg ICAgICAgJmx0O3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0 O2NhcmQmZ3Q7RXRoZXJuZXQwJmx0Oy9jYXJkJmd0OwogICAgICAgICAgICAgICAgICAgICAgJmx0 Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAmbHQ7c2V2ZXJpdHkm Z3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsvZXZlbnQm Z3Q7CgogICAgICAgICAgICAgICAgICAgICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUu Y29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZn dDtmYXVsdCZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgICAgICAgICAgICAgICZsdDtyZXBv cnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVy bmV0MiZsdDsvY2FyZCZndDsKICAgICAgICAgICAgICAgICAgICAgICZsdDsvcmVwb3J0aW5nRW50 aXR5Jmd0OwogICAgICAgICAgICAgICAgICAgICAgJmx0O3NldmVyaXR5Jmd0O2NyaXRpY2FsJmx0 Oy9zZXZlcml0eSZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7L2V2ZW50Jmd0OwoKICAgICAg ICAgICAgICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8x LjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7 L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5 Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7Y2FyZCZndDtBVE0xJmx0Oy9jYXJkJmd0 OwogICAgICAgICAgICAgICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWlub3ImbHQ7L3NldmVyaXR5Jmd0OwogICAg ICAgICAgICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CgogICAgICAgICAgICAgICAgICAgICZsdDtl dmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAg ICAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtzdGF0ZSZsdDsvZXZlbnRDbGFzcyZndDsKICAg ICAgICAgICAgICAgICAgICAgICZsdDtyZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAg ICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgICAg ICAgICAgICAgICZsdDsvcmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAgICAgICAgICAg Jmx0O29wZXJTdGF0ZSZndDtlbmFibGVkJmx0Oy9vcGVyU3RhdGUmZ3Q7CiAgICAgICAgICAgICAg ICAgICAgJmx0Oy9ldmVudCZndDsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSAxMAoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIHNlbGVjdGluZyBl dmVudHMgd2hpY2ggaGF2ZQogICBzZXZlcml0aWVzIG9mIGNyaXRpY2FsLCBtYWpvciwgb3IgbWlu b3IgKHByZXN1bWFibHkgZmF1bHQgZXZlbnRzKS4KICAgVGhlIGZpbHRlcmluZyBjcml0ZXJpYSBl dmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoKHNldmVyaXR5PWNyaXRpY2FsKSB8IChzZXZl cml0eT1tYWpvcikgfCAoc2V2ZXJpdHk9bWlub3IpKQogICAgICAmbHQ7bmV0Y29uZjpycGMgbmV0 Y29uZjptZXNzYWdlLWlkPSIxMDEiCiAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmll dGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRl LXN1YnNjcmlwdGlvbgogICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6 Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIiZndDsKICAgICAgICAgICZsdDtmaWx0ZXIgbmV0 Y29uZjp0eXBlPSJzdWJ0cmVlIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRw Oi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgICAmbHQ7ZXZlbnRDbGFz cyZndDtmYXVsdCZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgICAgICAmbHQ7c2V2ZXJpdHkm Z3Q7Y3JpdGljYWwmbHQ7L3NldmVyaXR5Jmd0OwogICAgICAgICAgICAmbHQ7L2V2ZW50Jmd0Owog ICAgICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAi Jmd0OwogICAgICAgICAgICAgICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNz Jmd0OwogICAgICAgICAgICAgICZsdDtzZXZlcml0eSZndDttYWpvciZsdDsvc2V2ZXJpdHkmZ3Q7 CiAgICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICAgICAgICAgICZsdDtldmVudCB4bWxucz0i aHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAgICAgJmx0O2V2ZW50 Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAgICAgJmx0O3NldmVy aXR5Jmd0O21pbm9yJmx0Oy9zZXZlcml0eSZndDsKICAgICAgICAgICAgJmx0Oy9ldmVudCZndDsK ICAgICAgICAgICZsdDsvZmlsdGVyJmd0OwogICAgICAgICZsdDsvY3JlYXRlLXN1YnNjcmlwdGlv biZndDsKICAgICAgJmx0Oy9uZXRjb25mOnJwYyZndDsKCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAxMQoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVz IHNlbGVjdGluZyBzdGF0ZSBvciBjb25maWcKICAgRXZlbnRDbGFzc2VzIG9yIGZhdWx0IGV2ZW50 cyB0aGF0IGFyZSByZWxhdGVkIHRvIGNhcmQgRXRoZXJuZXQwLiAgVGhlCiAgIGZpbHRlcmluZyBj cml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoIHN0YXRlIHwgY29uZmlnIHwg ZmF1bHQgJmFtcDsgY2FyZD1FdGhlcm5ldDApCiAgICAmbHQ7bmV0Y29uZjpycGMgbmV0Y29uZjpt ZXNzYWdlLWlkPSIxMDEiCiAgICAgICAgICAgICAgICB4bWxuczpuZXRjb25mPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiJmd0OwogICAgICAmbHQ7Y3JlYXRlLXN1YnNj cmlwdGlvbgogICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxp dHk6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9 InN1YnRyZWUiJmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5j b20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7 L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICAgJmx0O2V2 ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAg Jmx0O2V2ZW50Q2xhc3MmZ3Q7c3RhdGUmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAmbHQ7 L2V2ZW50Jmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20v ZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7Y29uZmlnJmx0Oy9l dmVudENsYXNzJmd0OwogICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAgICZsdDtldmVu dCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAgICZs dDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPiZsdDtyZXBvcnRpbmdFbGVtZW50Jmd0OzwvZm9udD48L3N0 cmlrZT4KICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiZsdDtyZXBvcnRp bmdFbnRpdHkmZ3Q7PC9mb250Pjwvc3Ryb25nPgogICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0 aGVybmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz4mbHQ7L3JlcG9ydGluZ0VsZW1lbnQmZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7PC9mb250 Pjwvc3Ryb25nPgogICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAmbHQ7L2ZpbHRlciZn dDsKICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwogICAgJmx0Oy9uZXRjb25mOnJw YyZndDsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29s b3I9J2dyZWVuJz5GaWd1cmUgMTI8L2ZvbnQ+PC9zdHJvbmc+Cgo1LjIuICBYUEFUSCBmaWx0ZXJz CgogICBUaGUgZm9sbG93aW5nIFtYUEFUSF0gZXhhbXBsZSBpbGx1c3RyYXRlcyBzZWxlY3Rpbmcg ZmF1bHQgRXZlbnRDbGFzcwogICBub3RpZmljYXRpb25zIHRoYXQgaGF2ZSBzZXZlcml0aWVzIG9m IGNyaXRpY2FsLCBtYWpvciwgb3IgbWlub3IuICBUaGUKICAgZmlsdGVyaW5nIGNyaXRlcmlhIGV2 YWx1YXRpb24gaXMgYXMgZm9sbG93czoKCiAgICgoZmF1bHQpICZhbXA7ICgoc2V2ZXJpdHk9Y3Jp dGljYWwpIHwgKHNldmVyaXR5PW1ham9yKSB8IChzZXZlcml0eSA9CiAgIG1pbm9yKSkpCgogICAg Jmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgogICAgICAgICAgICAgIHht bG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCImZ3Q7 CiAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uCiAgICAgICAgICAgIHhtbG5zPSJ1cm46aWV0 ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAiJmd0OwogICAgICAg ICZsdDtmaWx0ZXIgbmV0Y29uZjp0eXBlPSJ4cGF0aCIKICAgICAgICAgICAgICAgIHhtbG5zOmV4 PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIgogICAgICAgICAgIHNlbGVjdD0iL2V4OmV2 ZW50W2V4OmV2ZW50Q2xhc3M9J2ZhdWx0JyBhbmQKICAgICAgICAgICAgICAgIChleDpzZXZlcml0 eT0nbWlub3InIG9yIGV4OnNldmVyaXR5PSdtYWpvcicKICAgICAgICAgICAgICAgICAgICAgb3Ig ZXg6c2V2ZXJpdHk9J2NyaXRpY2FsJyldIi8mZ3Q7CiAgICAgICZsdDsvY3JlYXRlLXN1YnNjcmlw dGlvbiZndDsKICAgICZsdDsvbmV0Y29uZjpycGMmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAxMwoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVz IHNlbGVjdGluZyBzdGF0ZSBhbmQgY29uZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVu dHMgdGhhdCBoYXZlIHNldmVyaXRpZXMgb2YgY3JpdGljYWwsIG1ham9yLAogICBvciBtaW5vciBv ciBjb21lIGZyb20gY2FyZCBFdGhlcm5ldDAuICBUaGUgZmlsdGVyaW5nIGNyaXRlcmlhCiAgIGV2 YWx1YXRpb24gaXMgYXMgZm9sbG93czoKCiAgICgoIHN0YXRlIHwgY29uZmlnKSAmYW1wOyAoKGZh dWx0ICZhbXA7IHNldmVyaXR5PWNyaXRpY2FsKSB8IChmYXVsdCAmYW1wOwogICBzZXZlcml0eT1t YWpvcikgfCAoZmF1bHQgJmFtcDsgc2V2ZXJpdHkgPSBtaW5vcikgfCAoZmF1bHQgJmFtcDsKICAg Y2FyZD1FdGhlcm5ldDApKSkKCiAgICZsdDtuZXRjb25mOnJwYyBuZXRjb25mOm1lc3NhZ2UtaWQ9 IjEwMSIKICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24KICAgICAgICAg ICAgeG1sbnM9InVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9u OjEuMCImZ3Q7CiAgICAgICAgICZsdDtmaWx0ZXIgbmV0Y29uZjp0eXBlPSJ4cGF0aCIKICAgICAg ICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIgogICAgICAg ICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbCiAgICAgICAgICAgICAgICAgICAgZXg6ZXZlbnRD bGFzcz0nZmF1bHQnIGFuZCBleDpzZXZlcml0eT0nbWlub3InKSBvcgogICAgICAgICAgICAgICAg ICAgIChleDpldmVudENsYXNzPSdmYXVsdCcgYW5kIGV4OnNldmVyaXR5PSdtYWpvcicpIG9yCiAg ICAgICAgICAgICAgICAgICAgZXg6ZXZlbnRDbGFzcz0nZmF1bHQnIGFuZCBleDpzZXZlcml0eT0n Y3JpdGljYWwnKSBvcgogICAgICAgICAgICAgICAgICAgIChleDpldmVudENsYXNzPSdmYXVsdCcg YW5kCiAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5leDpyZXBv cnRpbmdFbGVtZW50L2V4OmNhcmQ9J0V0aGVybmV0MCcpPC9mb250Pjwvc3RyaWtlPgogICAgICAg ICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5leDpyZXBvcnRpbmdFbnRp dHkvZXg6Y2FyZD0nRXRoZXJuZXQwJyk8L2ZvbnQ+PC9zdHJvbmc+IG9yCiAgICAgICAgICAgICAg ICAgICAgZXg6ZXZlbnRDbGFzcz0nc3RhdGUnIG9yCiAgICAgICAgICAgICAgICAgICAgZXg6ZXZl bnRDbGFzcz0nY29uZmlnJ10iLyZndDsKICAgICAmbHQ7L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7 CiAgICZsdDsvbmV0Y29uZjpycGMmZ3Q7CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgMTQKCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIGZyb20gdGhlIGJhc2UgW05FVENPTkZdIGRvY3VtZW50IGFwcGx5CiAg IGFsc28gdG8gdGhlIE5vdGlmaWNhdGlvbiBjYXBhYmlsaXR5LgoKICAgVGhlIGFjY2VzcyBjb250 cm9sIGZyYW1ld29yayBhbmQgdGhlIGNob2ljZSBvZiB0cmFuc3BvcnQgd2lsbCBoYXZlIGEKICAg bWFqb3IgaW1wYWN0IG9uIHRoZSBzZWN1cml0eSBvZiB0aGUgc29sdXRpb24uCgogICBUaGUgJmx0 O25vdGlmaWNhdGlvbiZndDsgZWxlbWVudHMgYXJlIG5ldmVyIHNlbnQgYmVmb3JlIHRoZSB0cmFu c3BvcnQgbGF5ZXIKICAgYW5kIHRoZSBuZXRjb25mIGxheWVyIChjYXBhYmlsaXRpZXMgZXhjaGFu Z2UpIGhhdmUgYmVlbiBlc3RhYmxpc2hlZCwKICAgYW5kIHRoZSBtYW5hZ2VyIGhhcyBiZWVuIGlk ZW50aWZpZWQgYW5kIGF1dGhlbnRpY2F0ZWQuCgogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGNh cmUgYmUgdGFrZW4gdG8gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5lbnN1cmUgdGhlPC9mb250 Pjwvc3RyaWtlPiBzZWN1cmUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5vcGVyYXRpb24KICAg b2YgdGhlIGZvbGxvd2luZyBjb21tYW5kczo8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz5leGVjdXRpb246PC9mb250Pjwvc3Ryb25nPgoKICAgbyAgJmx0O2NyZWF0 ZS1zdWJzY3JpcHRpb24mZ3Q7IGludm9jYXRpb24KCiAgIG8gIHJlYWQtb25seSBkYXRhIG1vZGVs cwoKICAgbyAgcmVhZC13cml0ZSBkYXRhIG1vZGVscwoKICAgbyAgbm90aWZpY2F0aW9uIGNvbnRl bnQKCiAgIE9uZSBpc3N1ZSByZWxhdGVkIHRvIHRoZSBub3RpZmljYXRpb25zIGRyYWZ0IGlzIHRo ZSB0cmFuc3BvcnQgb2YgZGF0YQogICBmcm9tIG5vbi1uZXRjb25mIHN0cmVhbXMsIHN1Y2ggYXMg c3lzbG9nIGFuZCBTTk1QLiAgVGhpcyBkYXRhIG1heSBiZQogICBtb3JlIHZ1bG5lcmFibGUgKG9y IGlzIG5vdCBtb3JlIHZ1bG5lcmFibGUpIHdoZW4gYmVpbmcgdHJhbnNwb3J0ZWQKICAgb3ZlciBu ZXRjb25mIHRoYW4gd2hlbiBiZWluZyB0cmFuc3BvcnRlZCB1c2luZyB0aGUgcHJvdG9jb2wgbm9y bWFsbHkKICAgdXNlZCBmb3IgdHJhbnNwb3J0aW5nIGl0LCBkZXBlbmRpbmcgb24gdGhlIHNlY3Vy aXR5IGNyZWRlbnRpYWxzIG9mCiAgIHRoZSB0d28gc3Vic3lzdGVtcy4gIFRoZSBORVRDT05GIHNl cnZlciBpcyByZXNwb25zaWJsZSBmb3IgcHJvdmlkaW5nCiAgIGFjY2VzcyBjb250cm9sIHRvIHN0 cmVhbSBjb250ZW50LgoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPlRoZSBjb250ZW50 cyBvZiBub3RpZmljYXRpb25zIGFzIHdlbGwgYXMgdGhlIG5hbWUgb2YgZXZlbnQgc3RyZWFtcwog ICBtYXkgY29udGFpbiBzZW5zaXRpdmUgaW5mb3JtYXRpb24gYW5kIGNhcmUgc2hvdWxkIGJlIHRh a2VuIHRvIGVuc3VyZQogICB0aGF0IGl0IGlzIHZpZXdlZCBvbmx5IGJ5IGF1dGhvcml6ZWQgdXNl cnMuPC9mb250Pjwvc3Ryb25nPiAgSWYgYSB1c2VyIGRvZXMgbm90IGhhdmUKICAgcGVybWlzc2lv biB0byB2aWV3IGNvbnRlbnQgdmlhIG90aGVyIE5FVENPTkYgb3BlcmF0aW9ucyBpdCBkb2VzIG5v dAogICBoYXZlIHBlcm1pc3Npb24gdG8gYWNjZXNzIHRoYXQgY29udGVudCB2aWEgTm90aWZpY2F0 aW9ucy4gIElmIGEgdXNlcgogICBpcyBub3QgcGVybWl0dGVkIHRvIHZpZXcgb25lIGVsZW1lbnQg aW4gdGhlIGNvbnRlbnQgb2YgdGhlCiAgIG5vdGlmaWNhdGlvbiwgdGhlIG5vdGlmaWNhdGlvbiBp cyBub3Qgc2VudCB0byB0aGF0IHVzZXIuCgogICBJZiBhIHN1YnNjcmlwdGlvbiBpcyBjcmVhdGVk IHdpdGggYSBzdG9wVGltZSwgdGhlIE5FVENPTkYgc2Vzc2lvbgogICB3aWxsIHJldHVybiB0byBi ZWluZyBhIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNlIE5FVENPTkYgc2Vzc2lvbiB3aGVuCiAgIHRo ZSByZXBsYXkgaXMgY29tcGxldGVkLiAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBO RVRDT05GCiAgIGNsaWVudCB0byBjbG9zZSBvZmYgdGhpcyBzZXNzaW9uIHdoZW4gaXQgaXMgbm8g bG9uZ2VyIG9mIHVzZS4KCjcuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50 IHJlZ2lzdGVycyB0d28gVVJJcyBmb3IgdGhlIE5FVENPTkYgWE1MIG5hbWVzcGFjZSBpbiB0aGUK ICAgSUVURiBYTUwgcmVnaXN0cnkgW1JGQzM2ODhdLgoKICAgRm9sbG93aW5nIHRoZSBmb3JtYXQg aW4gUkZDIDM2ODgsIElBTkEgaGFzIG1hZGUgdGhlIGZvbGxvd2luZwogICByZWdpc3RyYXRpb24u CgogICBVUkk6IHVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9u OjEuMAoKICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldG1vZDpub3RpZmljYXRpb24K CiAgIFJlZ2lzdHJhbnQgQ29udGFjdDogVGhlIElFU0cuCgogICBYTUw6IE4vQSwgdGhlIHJlcXVl c3RlZCBVUkkgaXMgYW4gWE1MIG5hbWVzcGFjZS4KCjguICBBY2tub3dsZWRnZW1lbnRzCgogICBU aGFua3MgdG8gR2lsYmVydCBHYWdub24sIEdyZWcgV2lsYnVyIGFuZCBLaW0gQ3VycmFuIGZvciBw cm92aWRpbmcKICAgdGhlaXIgaW5wdXQgaW50byB0aGUgZWFybHkgd29yayBvbiB0aGlzIGRvY3Vt ZW50LiAgSW4gYWRkaXRpb24sIHRoZQogICBlZGl0b3JzIHdvdWxkIGxpa2UgdG8gYWNrbm93bGVk Z2UgaW5wdXQgYXQgdGhlIFZhbmNvdXZlciBlZGl0aW5nCiAgIHNlc3Npb24gZnJvbSB0aGUgZm9s bG93aW5nIHBlb3BsZTogT3JseSBOaWNrbGFzcywgSmFtZXMgQmFsZXN0cmllcmUsCiAgIFlvc2hp ZnVtaSBBdGFyYXNoaSwgR2xlbm4gV2F0ZXJzLCBBbGV4YW5kZXIgQ2xlbW0sIERhdmUgSGFycmlu Z3RvbiwKICAgRGF2ZSBQYXJ0YWluLCBSYXkgQXRhcmFzaGkgYW5kIERhdmUgUGVya2lucyBhbmQg dGhlIGZvbGxvd2luZwogICBhZGRpdGlvbmFsIHBlb3BsZSBmcm9tIHRoZSBNb250cmVhbCBlZGl0 aW5nIHNlc3Npb246IEJhbGF6cyBMZW5neWVsLAogICBQaGlsIFNoYWZlciwgUm9iIEVubnMsIEFu ZHkgQmllcm1hbiwgRGFuIFJvbWFzY2FudSwgQmVydCBXaWpuZW4sCiAgIFNpbW9uIExlaW5lbiwg SnVlcmdlbiBTY2hvZW53YWVsZGVyLCBIaWRla2kgT2tpdGEsIFZpbmNlbnQgQ3JpZGxpZywKICAg TWFydGluIEJqb3JrbHVuZCwgT2xpdmllciBGZXN0b3IsIFJhZHUgU3RhdGUsIEJyaWFuIFRyYW1t ZWxsLCBXaWxsaWFtCiAgIENob3cuICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+V2Ugd291 bGQgYWxzbyBsaWtlIHRvIHRoYW5rIExpIFlhbiBmb3IgaGlzIG51bWVyb3VzIHJldmlld3MuPC9m b250Pjwvc3Ryb25nPgoKOS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbTkVUQ09ORl0gIEVu bnMsIFIuLCAiTkVUQ09ORiBDb25maWd1cmF0aW9uIFByb3RvY29sIiwgUkZDIDQ3NDEsCiAgICAg ICAgICAgICAgRGVjZW1iZXIgMjAwNi4KCiAgIFtSRkMyMDI2XSAgQnJhZG5lciwgUy4sICJUaGUg SW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nlc3MgLS0gUmV2aXNpb24KICAgICAgICAgICAgICAzIiwg UkZDIDIwMjYsIEJDUCA5LCBPY3RvYmVyIDE5OTYuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIHMu LCAiS2V5IHdvcmRzIGZvciBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50cwogICAgICAgICAg ICAgIExldmVscyIsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzIyMjNdICBQb3N0ZWws IEouIGFuZCBKLiBSZXlub2xkcywgIkluc3RydWN0aW9ucyB0byBSRkMgQXV0aG9ycyIsCiAgICAg ICAgICAgICAgUkZDIDIyMjMsIE9jdG9iZXIgMTk5Ny4KCiAgIFtSRkMzNjg4XSAgQnJhZG5lciwg cy4sICJUaGUgSUVURiBYTUwgUmVnaXN0cnkiLCBSRkMgMzY4OCwgSmFudWFyeQogICAgICAgICAg ICAgICAyMDA0LgoKICAgW1hNTF0gICAgICBXb3JsZCBXaWRlIFdlYiBDb25zb3J0aXVtLCAiRXh0 ZW5zaWJsZSBNYXJrdXAgTGFuZ3VhZ2UKICAgICAgICAgICAgICAoWE1MKSAxLjAiLCBXM0MgWE1M LCBGZWJydWFyeSAxOTk4LAogICAgICAgICAgICAgICZsdDtodHRwOi8vd3d3LnczLm9yZy9UUi8x OTk4L1JFQy14bWwtMTk5ODAyMTAmZ3Q7LgoKICAgW1hNTCBTY2hlbWFdCiAgICAgICAgICAgICAg RmFsbHNpZGUsIEQuIGFuZCBQLiBXYWxtc2xleSwgIlhNTCBTY2hlbWEgUGFydCAwOiBQcmltZXIK ICAgICAgICAgICAgICBTZWNvbmQgRWRpdGlvbiIsIFczQyBYTUwgU2NoZW1hLCBPY3RvYmVyIDIw MDQuCgogICBbWFBBVEhdICAgIENsYXJrLCBKLiBhbmQgUy4gRGVSb3NlLCAiWE1MIFBhdGggTGFu Z3VhZ2UgKFhQYXRoKQogICAgICAgICAgICAgIFZlcnNpb24gMS4wIiwKICAgICAgICAgICAgICBX M0MgaHR0cDovL3d3dy53My5vcmcvVFIvMTk5OS9SRUMteHBhdGgtMTk5OTExMTYsCiAgICAgICAg ICAgICAgTm92ZW1iZXIgMTk5OS4KCkFwcGVuZGl4IEEuICBDaGFuZ2UgTG9nCgpBLjEuICBWZXJz aW9uIC0wOAoKICAgMS4gICBSZW1vdmVkIG5hbWVkIHByb2ZpbGVzCgogICAyLiAgIFJlbW92ZWQg ZXZlbnRDbGFzcyB0aGF0IHdhcyBhY2NpZGVudGFsbHkgaW5jbHVkZWQgaW4gdGhlCiAgICAgICAg ZGVmaW5pdGlvbiBvZiB0aGUgcmVwbGF5Q29tcGxldGUgbm90aWZpY2F0aW9uCgogICAzLiAgIERl bGV0ZWQgZGF0YSB3cmFwcGVyIGZyb20gbm90aWZpY2F0aW9uCgogICA0LiAgIENoYW5nZWQgcmVw bGF5TG9nU3RhcnRUaW1lIHRvIGhhdmUgYSBtaW5PY2N1cnMgb2YgMC4gIEl0IHdpbGwKICAgICAg ICBvbmx5IGJlIHRoZXJlIHdoZW4gcmVwbGF5IGlzIHN1cHBvcnRlZC4gIFZlcmlmeSBleGFtcGxl cyBpbgogICAgICAgIHNlY3Rpb24gMy4yLjUuMSBhcmUgY29ycmVjdCB3aXRoIHJlc3BlY3QgdG8g dGhpcyBlbGVtZW50LgoKICAgNS4gICBFcnJvciBjb2RlcyBpbiBzZWN0aW9uIDIuMS4xLCBmaXhl ZCBmb3JtYXR0aW5nIGlzc3VlCgogICA2LiAgIE1vdmVkIHJlcGxheUNvbXBsZXRlIHRvIG5vdCBi ZSB1bmRlciAmbHQ7bmV0Y29uZiZndDsKCiAgIDcuICAgU2VjdGlvbiAyLjEsIGZpeGVkIGNhcGl0 YWxpemF0aW9uCgogICA4LiAgIEluIGZpZ3VyZSA0LCB0aGUgbGluZSB3YXMgcHVzaGVkIG91dCBi eSAnc3lzdGVtIGNvbXBvbmVudHMnLAogICAgICAgIGZpeGVkIHRoaXMuCgogICA5LiAgIE9uIHBh Z2UgOCwgcmVwbGFjZWQgIklmIHRoZSBzdGFydFRpbWUgc3BlY2lmaWVkIGlzIGVhcmxpZXIgdGhl bgogICAgICAgIHRoZSIgd2l0aCAnSWYgdGhlIHN0YXJ0VGltZSBzcGVjaWZpZWQgaXMgZWFybGll ciB0aGFuIHRoZSIKCiAgIDEwLiAgVXBkYXRlZCBzb21lIG5hbWUgc3BhY2VzIGFuZCBzY2hlbWFM b2NhdGlvbnMgYXMgcGVyIEFuZHkncyBKdW5lCiAgICAgICAgM3JkIGVtYWlsLgoKICAgMTEuICBB ZGRlZCBkaXNjdXNzaW9uIG9mIHJlcGxheUxvZ1N0YXJ0VGltZSB0byBkcmFmdCBpbiBzZWN0aW9u IDMuMy4xCiAgICAgICAgYXMgZm9sbG93cyAiV2hldGhlciBvciBub3QgYSBzdHJlYW0gc3VwcG9y dHMgcmVwbGF5IGNhbiBiZQogICAgICAgIGRpc2NvdmVyZWQgYnkgZG9pbmcgYSAmbHQ7Z2V0Jmd0 OyBvcGVyYXRpb24gb24gdGhlIGV2ZW50U3RyZWFtcwogICAgICAgIGVsZW1lbnRzIG9mIHRoZSBO b3RpZmljYXRpb24gTWFuYWdlbWVudCBTY2hlbWEuICBUaGlzIHNjaGVtYQogICAgICAgIGFsc28g cHJvdmlkZXMgdGhlIHJlcGxheUxvZ1N0YXJ0VGltZSBlbGVtZW50IHRvIGluZGljYXRlIHRoZQog ICAgICAgIGVhcmxpZXN0IGF2YWlsYWJsZSBsb2dnZWQgbm90aWZpY2F0aW9uLiIKCiAgIDEyLiAg UmVtb3ZlZCBtb3N0IG9mIHRoZSB1c2VzIG9mIHRoZSBwaHJhc2UgJ05vdGUgdGhhdCcuICBJIGtl cHQgdHdvCiAgICAgICAgdXNlcyB0aGF0IHByZXZlbnQgc2VudGVuY2VzIGZyb20gc3RhcnRpbmcg d2l0aCBlaXRoZXIgYSBsb3dlcgogICAgICAgIGNhc2UgbGV0dGVyIG9yIGFuIGFuZ2xlIGJyYWNr ZXQuCgogICAxMy4gIEluIHNlY3Rpb24gMy42IHJlcGxhY2VkICJpdCB3aWxsIGJlIGZpbHRlcmVk IG91dCIgd2l0aCAidGhlCiAgICAgICAgbm90aWZpY2F0aW9uIHdpbGwgYmUgZmlsdGVyZWQgb3V0 IgoKICAgMTQuICBJbiBzZWN0aW9uIDMuNCwgcmVwbGFjZWQgImFuZCB0aGUgcXVlcnkiIHdpdGgg ImFuZCB0byBxdWVyeSIKCiAgIDE1LiAgUmVwbGFjZWQgMyBpbnN0YW5jZXMgb2YgInJlcGxheSBj b21wbGV0ZSBub3RpZmljYXRpb24iIHdpdGgKICAgICAgICAicmVwbGF5Q29tcGxldGUgbm90aWZp Y2F0aW9uIgogICAxNi4gIEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJub3JtYWwgTkVUQ09O RiBzZXNzaW9uIiB3aXRoICJub3JtYWwKICAgICAgICBjb21tYW5kLXJlc3BvbnNlIE5FVENPTkYg c2Vzc2lvbiIKCiAgIDE3LiAgSW4gc2VjdGlvbiAzLjMuMSwgcmVwbGFjZWQgImNyZWF0ZSBhbiBl dmVudCBzdWJzY3JpcHRpb24gdGhhdAogICAgICAgIHdpbGwgcmVzZW5kIHJlY2VudGx5IGdlbmVy YXRlZCBub3RpZmljYXRpb24iIHdpdGggImNyZWF0ZSBhbgogICAgICAgIGV2ZW50IHN1YnNjcmlw dGlvbiB0aGF0IHdpbGwgcmVzZW5kIHJlY2VudGx5IGdlbmVyYXRlZAogICAgICAgIG5vdGlmaWNh dGlvbiwgb3IgaXMgc29tZSBjYXNlcyBzZW5kIHRoZW0gZm9yIHRoZSBmaXJzdCB0aW1lIHRvIGEK ICAgICAgICBwYXJ0aWN1bGFyIE5FVENPTkYgY2xpZW50LiIKCiAgIDE4LiAgSW4gc2VjdGlvbiAz LjIuNS4yLCBzL2F2YWlsYWJsZSBldmVudCBzdHJlYW1zIHRvL2V2ZW50IHN0cmVhbXMKICAgICAg ICBhdmFpbGFibGUgdG8vCgogICAxOS4gIEluIG9uZSBzcG90LCBjaGFuZ2VkIHNubXAgdG8gU05N UCAodGhlIG90aGVyIGdldHMgZGVsZXRlZCkKCiAgIDIwLiAgSW4gc2VjdGlvbiAzLjIuNS4xIHMv d2hlcmUgJmx0O25hbWUmZ3Q7IGVsZW1lbnQgaXMvd2hlcmUgdGhlICZsdDtuYW1lJmd0OwogICAg ICAgIGVsZW1lbnQgaXMvCgogICAyMS4gIEluIHNlY3Rpb24gMy4yLjUuMSwgY2xhcmlmaWVkIHRo YXQgInZhbHVlIGlzIHVuaXF1ZSIgLSB3aXRoaW4KICAgICAgICB0aGUgc2NvcGUgb2YgYSBORVRD T05GIHNlcnZlci4KCiAgIDIyLiAgSW4gc2VjdGlvbiAyLjEuMSwgY2xhcmlmaWVkIHRoYXQgc3Rv cFRpbWUgY2Fubm90IHByZWNlZGVkIHN0YXJ0CiAgICAgICAgdGltZS4KCiAgIDIzLiAgSW4gc2Vj dGlvbiAyLjEuMSwgaW4gU3RhcnQgVGltZSBzL2luZGljYXRlcy9pbmRpY2F0ZS8KCiAgIDI0LiAg SW4gc2VjdGlvbiAyLjEuMSwgaW4gRmlsdGVyOiBzL1RoaXMgaXMgbXV0dWFsbHkgZXhjbHVzaXZl L1RoZQogICAgICAgIGZpbHRlciBwYXJhbWV0ZXIgaXMgbXV0dWFsbHkgZXhjbHVzaXZlLyAoInRo aXMiIGNvdWxkIHJlZmVyIHRvCiAgICAgICAgdGhlIGJlaGF2aW9yIGRlc2NyaWJlZCBpbiB0aGUg cHJldmlvdXMgc2VudGVuY2UuKQoKICAgMjUuICBJbiBzZWN0aW9uIDEuNCwgdGhpcmQgYnVsbGV0 LCByZXBsYWNlZCAic3lzbG9nIGFuZCBTTk1QIGFyZQogICAgICAgIHJhdGhlciBjb25zdHJhaW5l ZCBpbiB0ZXJtcyBvZiBtZXNzYWdlIHNpemVzKSIgd2l0aCAoaWUsIG5vdCB0b28KICAgICAgICBz aG9ydCkKCiAgIDI2LiAgSW4gc2VjdGlvbiAxLjQsIG1hZGUgYWxsIGJ1bGxldHMgc3RhcnQgd2l0 aCBjYXBpdGFsIGxldGVycy4KCiAgIDI3LiAgQWRkZWQgZGVmaW5pdGlvbiBvZiBGaWx0ZXIgdG8g c2VjdGlvbiAxLjEKCiAgIDI4LiAgSW4gc2VjdGlvbiAxLjEsIGltcHJvdmVkIHRoZSBkZWZpbml0 aW9uIG9mIHN1YnNjcmlwdGlvbiB3aXRoICJBbgogICAgICAgIGFncmVlbWVudCBhbmQgbWV0aG9k IHRvIHJlY2VpdmUgZXZlbnQgbm90aWZpY2F0aW9ucyBvdmVyIGEKICAgICAgICBORVRDT05GIHNl c3Npb24uIgoKICAgMjkuICBJbiBzZWN0aW9uIDEuMSwgaW4gdGhlIGRlZmluaXRpb24gb2Ygb3Bl cmF0aW9uLCBhZGRlZCBhCiAgICAgICAgcmVmZXJlbmNlIHRvIFtORVRDT05GXS4KCiAgIDMwLiAg Q3JlYXRlZCBhIGNoYW5nZSBsb2cgc2VjdGlvbgoKICAgMzEuICBGaXhlZCByZWZlcmVuY2UgdG8g SUVURiBYTUwgUmVnaXN0cnkgaW4gSUFOQSBDb25zaWRlcmF0aW9ucwogICAgICAgIHNlY3Rpb24u CgogICAzMi4gIEluIHNlY3Rpb24gMy4zLjMsIGRlbGV0ZWQgIlRoaXMgbm90aWZpY2F0aW9uIHdp bGwgb25seSBiZSBzZW50CiAgICAgICAgaWYgYSAnc3RvcFRpbWUnIHdhcyBzcGVjaWZpZWQgd2hl biB0aGUgcmVwbGF5IHN1YnNjcmlwdGlvbiB3YXMKICAgICAgICBjcmVhdGVkLiIKCiAgIDMzLiAg QWRkZWQgdGV4dCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IHNh eXMgIklmCiAgICAgICAgYSBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCB3aXRoIGEgc3RvcFRpbWUs IHRoZSBORVRDT05GIHNlc3Npb24KICAgICAgICB3aWxsIHJldHVybiB0byBiZWluZyBhIG5vcm1h bCBjb21tYW5kLXJlc3BvbnNlIE5FVENPTkYgc2Vzc2lvbgogICAgICAgIHdoZW4gdGhlIHJlcGxh eSBpcyBjb21wbGV0ZWQuICBJdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlCiAgICAgICAg TkVUQ09ORiBjbGllbnQgdG8gY2xvc2Ugb2ZmIHRoaXMgc2Vzc2lvbiB3aGVuIGl0IGlzIG5vIGxv bmdlciBvZgogICAgICAgIHVzZSIuCgogICAzNC4gIFVwZGF0ZSBleGFtcGxlcyBpbiBzZWN0aW9u IDUgdG8gZ2V0IHJpZCBvZiBleHRyYSB3cmFwcGVyIHRhZy4KCiAgIDM1LiAgSW4gc2VjdGlvbiAy LjEsIHJlcGxhY2UgIkEgTkVUQ09ORiBzZXJ2ZXIgaXMgbm90IHJlcXVpcmVkIHRvCiAgICAgICAg cHJvY2VzcyBSUEMgcmVxdWVzdHMgb24gdGhlIHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoIHRoZQog ICAgICAgIHN1YnNjcmlwdGlvbiB1bnRpbCB0aGUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBp cyBkb25lIGFuZCBtYXkKICAgICAgICBzaWxlbnRseSBkaXNjYXJkIHRoZXNlIHJlcXVlc3RzLiIg d2l0aCAiQSBORVRDT05GIHNlcnZlciBpcyB3aWxsCiAgICAgICAgbm90IHJlYWQgUlBDIHJlcXVl c3RzLCBieSBkZWZhdWx0LCBvbiB0aGUgc2Vzc2lvbiBhc3NvY2lhdGVkCiAgICAgICAgd2l0aCB0 aGUgc3Vic2NyaXB0aW9uIHVudGlsIHRoZSBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzCiAg ICAgICAgZG9uZS4KCiAgIDM2LiAgVXBkYXRlZCB0aGUgbm90aWZpY2F0aW9uIGRlZmluaXRpb24g YW5kIHRoZSByZXBseUNvbXBsZXRlCiAgICAgICAgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gdG8g dXNlIGEgc3Vic3RpdHV0aW9uIGdyb3VwLgoKPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPkEu Mi4gIFZlcnNpb24gLTA5CgogICBJbiBzZWN0aW9uIDUuMSAibG9naWNhbCBPUiBvcGVyYXRpb24i IC0mZ3Q7ICJhcHBsaWNhdGlvbiBvZiB0aGUgbG9naWNhbAogICBPUiBvcGVyYXRvciIKCiAgIElu IHNlY3Rpb24gNiAiZW5zdXJlIHRoZSBzZWN1cmUgb3BlcmF0aW9uIG9mIHRoZSBmb2xsb3dpbmcg Y29tbWFuZHMiCiAgIC0mZ3Q7ICJzZWN1cmUgZXhlY3V0aW9uIgoKICAgUmVtb3ZlZCBhIGNvdXBs ZSByZW1haW5pbmcgcmVmZXJlbmNlcyB0byBuYW1lZCBwcm9maWxlcy4KCiAgIFVwZGF0ZWQgbmFt ZSBkYXRhdHlwZSBpbiBldmVudFN0cmVhbXMgZWxlbWVudC4KCiAgIE1vZGlmaWVkIHRoZSBjYXJk aW5hbGl0eSBvZiBldmVudFN0cmVhbXMgdG8gcmVmbGVjdCB0aGF0IHRoZXJlIHdpbGwKICAgYWx3 YXlzIGJlIGF0IGxlYXN0IG9uZSBldmVudCBzdHJlYW0uCgogICBGaXhlZCBkZXNjcmlwdGlvbiBv ZiBleGFtcGxlcyB0byByZW1vdmUgcmVmZXJlbmNlIHRvIGV2ZW50RW50cnksCiAgIHdoaWNoIGlz IG5vIGxvbmdlciBwYXJ0IG9mIHRoZSBhY3R1YWwgZXhhbXBsZS4KCiAgIEluIGV4YW1wbGVzLCBm b3IgY29uc2lzdGVuY3kgY2hhbmdlZCBzb21lIHJlZmVyZW5jZXMgdG8KICAgcmVwb3J0aW5nRWxl bWVudCB0byBiZSByZXBvcnRpbmdFbnRpdHkKCiAgIEZpeGVkIHNlY3Rpb24gMy4yLCB0aGlyZCBw YXJhcmFwaCB0byB0YWxrIGFib3V0IGZpbHRlciBlbGVtZW50cwogICBpbnN0ZWFkIG9mIGZpbHRl cnMuCgogICBNZXJnZSBzZWN0aW9uIDMuMy4yIGFuZCBzZWN0aW9uIDMuMy4zLiAgRGVsZXRlIHRo ZSBmaXJzdCBwYXJhZ3JhcGggaW4KICAgKG9sZCkgc2VjdGlvbiAzLjMuMyBzaW5jZSBpdCBib3Ro IGR1cGxpY2F0ZXMgYW5kIGNvbnRyYWRpY3RzIHRleHQgaW4KICAgc2VjdGlvbiAzLjMuMgoKICAg SW4gc2VjdGlvbiAzLjIuNS4yLjEsIGFkZGVkIGNsYXJpZmljYXRpb24gdG8gZmlyc3QgcGFyYWdy YXBoIHRoYXQKICAgIkVpdGhlciBzdWJ0cmVlIG9yIFhQQVRIIGZpbHRlcmluZyBjYW4gYmUgdXNl ZC4gICIKCiAgIFJlbW92ZWQgZGlzY3Vzc2lvbiBvZiBub3QgYWxsb3dpbmcgdGhlIHJldHVybiBv ZiBzdHJlYW0gbmFtZXMgZm9yCiAgIHdoaWNoIHRoZSB1c2VyIGRvZXMgbm90IGhhdmUgcGVybWlz c2lvbnMgZnJvbSB0aGUgYm9keSBvZiB0aGUKICAgZG9jdW1lbnQgdG8gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24uCgogICBGaXhlZCB0eXBvcy4KCiAgIEluIHNlY3Rpb24gMi4x LCBleHBsaWNpdGx5IHN0YXRlZCB0aGF0IGEgc3Vic2NyaXB0aW9uIGlzIGJvdW5kIHRvIGEKICAg c2luZ2xlIHN0cmVhbSBmb3IgdGhlIGxpZmV0aW1lIG9mIHRoZSBzdWJzY3JpcHRpb24uCgogICBy ZW1vdmVkIHNpbmdsZSBxdW90ZXMgYXJvdW5kIHNvbWUgaW5zdGFuY2VzIG9mIHN0b3BUaW1lIGFu ZCBzdGFydFRpbWUKICAgZm9yIGNvbnNpc3RlbmN5LgoKICAgSW4gc2VjdGlvbiAyLjEuMSwgY2hh bmdlZCAiRXJyb3ItaW5mbzogJmx0O2JhZEVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUiIHRvCiAgIHVz ZSBiYWQtZWxlbWVudC4KCiAgIEluIHNlY3Rpb24gMi4yLjEsIHVuZGVyIHRoZSBwYXJhbWV0ZXIg dGFnLCByZXBsYWNlZCAiQ29udGFpbnMKICAgbm90aWZpY2F0aW9uLXNwZWNpZmljIHRhZ2dlZCBj b250ZW50LiIgd2l0aCAiQ29udGFpbnMgbm90aWZpY2F0aW9uLQogICBzcGVjaWZpYyB0YWdnZWQg Y29udGVudCwgaWYgYW55LiAgIjwvZm9udD48L3N0cm9uZz4KCkF1dGhvcnMnIEFkZHJlc3NlcwoK ICAgU2hhcm9uIENoaXNob2xtCiAgIE5vcnRlbAogICAzNTAwIENhcmxpbmcgQXZlCiAgIE5lcGVh biwgT250YXJpbyAgSzJIIDhFOQogICBDYW5hZGEKCiAgIEVtYWlsOiBzY2hpc2hvbEBub3J0ZWwu Y29tCgogICBIZWN0b3IgVHJldmlubwogICBDaXNjbwogICBTdWl0ZSA0MDAKICAgOTE1NSBFLiBO aWNob2xzIEF2ZQogICBFbmdsZXdvb2QsIENPICA4MDExMgogICBVU0EKCiAgIEVtYWlsOiBodHJl dmlub0BjaXNjby5jb20KCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChD KSBUaGUgSUVURiBUcnVzdCAoMjAwNykuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g dGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucwogICBjb250YWluZWQgaW4gQkNQ IDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycwogICByZXRh aW4gYWxsIHRoZWlyIHJpZ2h0cy4KCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMKICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElF VEYgVFJVU1QgQU5ECiAgIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NM QUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQg Tk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRgogICBUSEUgSU5GT1JN QVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQK ICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UuCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkKCiAgIFRoZSBJRVRGIHRha2VzIG5v IHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55CiAgIEludGVs bGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xh aW1lZCB0bwogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRl Y2hub2xvZ3kgZGVzY3JpYmVkIGluCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3 aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cwogICBtaWdodCBvciBtaWdodCBub3Qg YmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMKICAgbWFkZSBh bnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9y bWF0aW9uCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZD IGRvY3VtZW50cyBjYW4gYmUKICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBDb3Bp ZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFu eQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUg cmVzdWx0IG9mIGFuCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ug b3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZgogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBi eSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBv YnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQKICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pcHIuCgogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBh cnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBhdGVudHMg b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgcmlnaHRzIHRo YXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50 CiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhl IElFVEYgYXQKICAgaWV0Zi1pcHJAaWV0Zi5vcmcuCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGlu ZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYKICAg QWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuCjwvcHJlPgo8L2JvZHk+PC9o dG1sPgo= ------_=_NextPart_001_01C7CEDE.36CE1AD9-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 25 16:10:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnBa-0007a6-3m for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 16:10:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDnBY-0003JZ-KQ for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 16:10:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDn51-000GEt-TY for netconf-data@psg.com; Wed, 25 Jul 2007 20:03:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDn4n-000GDR-Lk for netconf@ops.ietf.org; Wed, 25 Jul 2007 20:03:25 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8CC46205DA for ; Wed, 25 Jul 2007 22:03:14 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-b8-46a7ac82049d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F179203D4 for ; Wed, 25 Jul 2007 22:03:14 +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 Jul 2007 22:03:14 +0200 Received: from [153.88.21.6] ([153.88.21.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 22:03:13 +0200 From: David Partain Organization: Ericsson AB To: netconf@ops.ietf.org Subject: Purely editorial changes to the notification draft Date: Wed, 25 Jul 2007 22:03:21 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_Jy6pGcQvOq51Bvs" Message-Id: <200707252203.21439.david.partain@ericsson.com> X-OriginalArrivalTime: 25 Jul 2007 20:03:13.0839 (UTC) FILETIME=[D5405BF0:01C7CEF6] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b --Boundary-00=_Jy6pGcQvOq51Bvs Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, The attached diff includes suggested textual changes to the notification draft (version dated July 8, 2007). I hope these improve readability. netconf -> NETCONF throughout the text... Should the "must" in 3.2.2 be "MUST"? I believe so but didn't change it. I have only rudimentarily touched Section 1.4 (Requirements) since it is getting a rewrite anyway. I think it would be better to use startTime and stopTime (and other similar "keywords") throughout rather than using "start time" sometimes and "startTime" in others. I have, however, not made this change. I would be happy to make changes to startTime and stopTime if others think this is a good idea. Cheers, David --Boundary-00=_Jy6pGcQvOq51Bvs Content-Type: text/x-diff; charset="us-ascii"; name="draft-ietf-netconf-notification-08.txt.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-netconf-notification-08.txt.diff" --- draft-ietf-netconf-notification-08.txt.orig 2007-07-23 14:38:49.000000000 +0200 +++ draft-ietf-netconf-notification-08.txt 2007-07-25 21:58:19.000000000 +0200 @@ -209,11 +209,11 @@ Subscription: An agreement and method to receive event notifications over a NETCONF session. A concept related to the delivery of - notifications (if any to send) involving destination and selection + notifications (if there are any to send) involving destination and selection of notifications. It is bound to the lifetime of a session. Operation: This term is used to refer to NETCONF protocol operations - [NETCONF]. Specifically within this document, operation refers to + [NETCONF]. Within this document, operation refers to NETCONF protocol operations defined in support of NETCONF notifications. @@ -264,9 +264,9 @@ to specify which events are of interest. These are specified when the subscription is created. - A NETCONF server is will not read RPC requests, by default, on the + A NETCONF server will, by default, not read RPC requests on the session associated with the subscription until the notification - subscription is done. A capability may be advertised to announce + subscription is completed. A capability may be advertised to announce that a server is able to process RPCs while a notification stream is active on a session. The behaviour of such a capability is outside the scope of this document. @@ -284,18 +284,18 @@ The following requirements have been addressed by the solution: - o Initial release should ensure it supports notification in support + o Initial release should ensure it supports notifications in support of configuration operations o Data content must not preclude the use of the same data model as used in configuration - o Solution should support a reasonable message size limit (ie, not + o Solution should support a reasonable message size limit (i.e., not too short) o Solution should provide reliable delivery of notifications - o Solution should provide a subscription mechanism (A NETCONF server + o Solution should provide a subscription mechanism (a NETCONF server does not send notifications before being asked to do so and the NETCONF client initiates the flow of notifications) @@ -361,13 +361,13 @@ Stream: An optional parameter that indicates which stream of events is - of interest. If not present, then events in the default + of interest. If not present, events in the default NETCONF stream will be sent. Filter: An optional parameter that indicates which subset of all - possible events are of interest. The format of this parameter + possible events is of interest. The format of this parameter is the same as that of the filter parameter in the NETCONF protocol operations. If not present, all events not precluded by other parameters will be sent. See section 3.6 for more @@ -410,12 +410,12 @@ Negative Response: An element is included within the if the - request cannot be completed for any reason. Subscription requests + request cannot be completed for some reason. Subscription requests will fail if a filter with invalid syntax is provided or if the name of a non-existent profile or stream is provided. If a stopTime is specified in a request without having specified a - startTime the following error is returned: + startTime, the following error is returned: Tag: missing-element @@ -473,12 +473,12 @@ Description: - An event notification is sent to the client who initiated a - command asynchronously when an event of - interest (i.e., meeting the specified filtering criteria) to them - has occurred. An event notification is a complete and well-formed + When an event of interest occurs (i.e., matches the specified + filtering criteria), an event notification is sent asynchronously + to client(s) that initiated a command + for the event. An event notification is a complete and well-formed XML document. Note that is not an RPC method but - rather the top level element identifying the one way message as a + rather the top level element identifying the one-way message as a notification. Parameters: @@ -490,7 +490,7 @@ Response: - No response. Not applicable. + This is not applicable as there is no response. @@ -509,7 +509,7 @@ Closing of the event notification subscription can be done by terminating the NETCONF session ( ) or the underlying transport session. If a stop time is provided when the subscription - is created, then the subscription will terminate after the stop time + is created, the subscription will terminate after the stop time is reached. In this case, the NETCONF session will still be an active session. @@ -597,7 +597,7 @@ An event stream is defined as a set of event notifications matching some forwarding criteria. - The diagram depicted in Figure 2 illustrates the notification flow + Figure 2 illustrates the notification flow and concepts identified in this document. The following is observed from the diagram below: System components (c1..cn) generate event notifications which are passed to a central component for @@ -633,7 +633,7 @@ +----+ | +---------+ +----+ | |central |-> stream 1 | c2 | +--->|event |-> stream 2 filter +-------+ - +----+ | |processor|-> NETCONF stream ----->|netconf| + +----+ | |processor|-> NETCONF stream ----->|NETCONF| ... | | |-> stream n |server | System | +---------+ +-------+ Components| | /\ @@ -647,7 +647,7 @@ || \/ +-------+ - |netconf| + |NETCONF| |client | +-------+ @@ -690,7 +690,7 @@ 3.2.4. Event Stream Sources With the exception of the default event stream (NETCONF - notifications) specification of additional event stream sources + notifications), specification of additional event stream sources (e.g., SNMP, syslog, etc.) is outside the scope of this document. NETCONF server implementations may leverage any desired event stream source in the creation of supported event streams. @@ -706,7 +706,7 @@ subtree via a operation. Available event streams for the requesting session are returned in the reply containing the and elements, where the - element is mandatory and its value is unique within the scope of a + element is mandatory, and its value is unique within the scope of a NETCONF server. The returned list must only include the names of those event streams for which the NETCONF session has sufficient privileges. The NETCONF session privileges are determined via access @@ -728,7 +728,7 @@ Internet-Draft NETCONF Event Notifications July 2007 - Example: Retrieving available event stream list using + Example: Retrieving the list of available event streams using the operation: @@ -755,7 +755,7 @@ NETCONF - Default netconf event stream + Default NETCONF event stream true 2007-07-08T00:00:00Z @@ -788,9 +788,9 @@ 3.2.5.2. Event Stream Subscription - A NETCONF client may request from the NETCONF server the list of - event streams available to this session and then issue a request with the desired event stream name. Omitting + A NETCONF client may request the list of event streams available to + this session from the NETCONF server and issue a + request with the desired event stream name. Omitting the event stream name from the request results in subscription to the default NETCONF event stream. @@ -802,10 +802,10 @@ associated with the event notification subscription and does not modify the event stream configuration. - XPATH support for the Notification capability is advertised as part + XPATH support for the notification capability is advertised as part of the normal XPATH capability advertisement. If XPATH support is - advertised via the XPATH capability then XPATH is supported for - notification filtering and if this capability is not advertised, then + advertised via the XPATH capability, XPATH is supported for + notification filtering. If XPATH support is not advertised, XPATH is not supported for notification filtering. 3.3. Notification Replay @@ -818,7 +818,7 @@ notifications are sent the same way as normal notifications. A replay of notifications is specified by including an optional - parameter to the subscription command that indicates the start time + parameter (startTime) in the subscription command that indicates the start time of the replay. The end time is specified using the optional stopTime parameter. If not present, notifications will continue to be sent until the subscription is terminated. @@ -842,7 +842,7 @@ Replay is dependent on a notification stream supporting some form of notification logging, although it puts no restrictions on the size or - form of the log, nor where it resides within the device. Whether or + form of the log, or where it resides within the device. Whether or not a stream supports replay can be discovered by doing a operation on the eventStreams element of the Notification Management Schema. This schema also provides the replayLogStartTime element to @@ -865,12 +865,11 @@ A replayComplete notification is sent to indicate that all of the replay notifications have been sent. If this subscription has a stop - time, then this session becomes a normal NETCONF session again. In - the case of a subscription without a stop time, after the - replayComplete notification has been sent, it can be expected that - any notifications generated since the start of the subscription - creation will be sent followed by notifications as they arise - naturally within the system. + time, then this session becomes a normal NETCONF session again. If + the subscription has no stop time, it can be expected that any + notifications generated since the start of the subscription creation + will be sent after the replayComplete notification has been sent, + followed by notifications as they arise naturally within the system. 3.3.3. Replay Complete Notification @@ -880,14 +879,14 @@ session becomes normal command-response NETCONF session. The replayComplete can not be filtered out. It will always be sent - on a relay subscription that specified a stop time. + on a replay subscription that specified a stop time. 3.4. Notification Management Schema - This Schema is used to learn about the event streams supported on the - system. It also contains the definition of the replayComplete, which + This schema is used to learn about the event streams supported on the + system. It also contains the definition of replayComplete, which is sent to indicate that an event replay has sent all applicable - notifications." + notifications. @@ -1012,7 +1011,7 @@ While it may be possible to retrieve information about subscriptions via a get operation, subscriptions are not stored configuration. - They are non-persistent state information and their lifetime is + They are non-persistent state information, and their lifetime is defined by their session. 3.6. Filter Mechanics @@ -1065,7 +1064,7 @@ The following figure depicts message flow between a NETCONF client - (C) and NETCONF server (S) in order create a subscription and begin + (C) and NETCONF server (S) in order to create a subscription and begin the flow of notifications. It is possible that many rpc/rpc-reply sequences occur before the subscription is created or after a stopTime in a replay subscription, but this is not depicted in the @@ -1189,7 +1188,7 @@ An optional parameter that indicates which subset of all possible events - are of interest. The format of this + is of interest. The format of this parameter is the same as that of the filter parameter in the NETCONF protocol operations. If not present, @@ -1255,7 +1254,7 @@ The command to create a notification subscription. It takes as argument the name of the notification stream - and filter or profile information. All of those options + and filter or profile information. All of those options limit the content of the subscription. In addition, there are two time-related parameters startTime and stopTime which can be used to select the time interval @@ -1351,14 +1350,14 @@ 5.1. Subtree Filtering - XML subtree filtering is not well suited for creating elaborate + XML subtree filtering is not well-suited for creating elaborate filter definitions given that it only supports equality comparisons and logical OR operations (e.g., in an event subtree give me all event notifications which have severity=critical or severity=major or severity=minor). Nevertheless, it may be used for defining simple event notification forwarding filters as shown below. - In order to illustrate the use of filter expressions it is necessary + In order to illustrate the use of filter expressions, it is necessary to assume some of the event notification content. The examples herein assume that the event notification schema definition has an element at the top level that contains one or more child @@ -1438,7 +1437,7 @@ Figure 10 - The following example illustrates selecting events which have + The following example illustrates how to select events which have severities of critical, major, or minor (presumably fault events). The filtering criteria evaluation is as follows: @@ -1481,7 +1480,7 @@ Figure 11 - The following example illustrates selecting state or config + The following example illustrates how to select state or config EventClasses or fault events that are related to card Ethernet0. The filtering criteria evaluation is as follows: @@ -1539,7 +1538,7 @@ 5.2. XPATH filters - The following [XPATH] example illustrates selecting fault EventClass + The following [XPATH] example illustrates how to select fault EventClass notifications that have severities of critical, major, or minor. The filtering criteria evaluation is as follows: @@ -1570,7 +1569,7 @@ Figure 13 - The following example illustrates selecting state and config + The following example illustrates how to select state and config EventClasses or fault events that have severities of critical, major, or minor or come from card Ethernet0. The filtering criteria evaluation is as follows: @@ -1626,14 +1625,14 @@ 6. Security Considerations - The security considerations from the base [NETCONF] document apply - also to the Notification capability. + The security considerations from the base [NETCONF] document also + apply to the Notification capability. The access control framework and the choice of transport will have a major impact on the security of the solution. The elements are never sent before the transport layer - and the netconf layer (capabilities exchange) have been established, + and the NETCONF layer (capabilities exchange) have been established, and the manager has been identified and authenticated. It is recommended that care be taken to ensure the secure operation @@ -1647,24 +1646,24 @@ o notification content - One issue related to the notifications draft is the transport of data - from non-netconf streams, such as syslog and SNMP. This data may be + One issue related to NETCONF event notifications is the transport of data + from non-NETCONF streams, such as syslog and SNMP. This data may be more vulnerable (or is not more vulnerable) when being transported - over netconf than when being transported using the protocol normally + over NETCONF than when being transported using the protocol normally used for transporting it, depending on the security credentials of the two subsystems. The NETCONF server is responsible for providing access control to stream content. If a user does not have permission to view content via other NETCONF - operations it does not have permission to access that content via - Notifications. If a user is not permitted to view one element in the + operations, the user does not have permission to access that content via + notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. If a subscription is created with a stopTime, the NETCONF session will return to being a normal command-response NETCONF session when the replay is completed. It is the responsibility of the NETCONF - client to close off this session when it is no longer of use. + client to close this session when it is no longer of use. @@ -1743,7 +1742,7 @@ editors would like to acknowledge input at the Vancouver editing session from the following people: Orly Nicklass, James Balestriere, Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, - Dave Partain, Ray Atarashi and Dave Perkins and the following + David Partain, Ray Atarashi and Dave Perkins and the following additional people from the Montreal editing session: Balazs Lengyel, Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen, Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, --Boundary-00=_Jy6pGcQvOq51Bvs-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 25 16:43:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnhT-00014d-EL for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 16:43:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDnhS-00040b-Nn for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 16:43:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDncJ-000Kip-LM for netconf-data@psg.com; Wed, 25 Jul 2007 20:37:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDnc7-000Ki4-Fq for netconf@ops.ietf.org; Wed, 25 Jul 2007 20:37:50 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F339820541 for ; Wed, 25 Jul 2007 22:37:36 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-d0-46a7b4903f7a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D5729204F4 for ; Wed, 25 Jul 2007 22:37:36 +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 Jul 2007 22:37:36 +0200 Received: from [153.88.21.6] ([153.88.21.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 22:37:36 +0200 From: David Partain Organization: Ericsson AB To: netconf@ops.ietf.org Subject: Re: Purely editorial changes to the notification draft Date: Wed, 25 Jul 2007 22:37:47 +0200 User-Agent: KMail/1.9.7 References: <200707252203.21439.david.partain@ericsson.com> In-Reply-To: <200707252203.21439.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_bS7pGiw+LUS028q" Message-Id: <200707252237.47104.david.partain@ericsson.com> X-OriginalArrivalTime: 25 Jul 2007 20:37:36.0511 (UTC) FILETIME=[A2B320F0:01C7CEFB] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d --Boundary-00=_bS7pGiw+LUS028q Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello again, On Wednesday 25 July 2007 22:03:21 David Partain wrote: > I think it would be better to use startTime and stopTime (and other > similar "keywords") throughout rather than using "start time" sometimes > and "startTime" in others. I have, however, not made this change. I would > be happy to make changes to startTime and stopTime if others think this is > a good idea. The attached diff shows what I mean... David --Boundary-00=_bS7pGiw+LUS028q Content-Type: text/x-diff; charset="utf-8"; name="start-stopTime-diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="start-stopTime-diff" --- draft-ietf-netconf-notification-08.txt.orig2 2007-07-25 22:25:23.000000000 +0200 +++ draft-ietf-netconf-notification-08.txt 2007-07-25 22:34:07.000000000 +0200 @@ -373,12 +373,12 @@ by other parameters will be sent. See section 3.6 for more information on filters. - Start Time: + startTime: A parameter used to trigger the replay feature and indicate that the replay should start at the time specified. If startTime is not present, this is not a replay subscription. - It is valid to specify start times that are later than the + It is valid to specify a startTime that is later than the current time. If the startTime specified is earlier than the log can support, the replay will begin with the earliest available notification. This parameter is of type dateTime. @@ -392,13 +392,13 @@ Internet-Draft NETCONF Event Notifications July 2007 - Stop Time: + stopTime: An optional parameter used with the optional replay feature to - indicate the newest notifications of interest. If stop time is + indicate the newest notifications of interest. If stopTime is not present, the notifications will continue until the subscription is terminated. Must be used with and be later - than 'startTime'. It is valid to specify stop times that are + than startTime. It is valid to specify a stopTime that is later than the current time. This parameter is of type dateTime. @@ -508,8 +508,8 @@ Closing of the event notification subscription can be done by terminating the NETCONF session ( ) or the underlying - transport session. If a stop time is provided when the subscription - is created, the subscription will terminate after the stop time + transport session. If stopTime is provided when the subscription + is created, the subscription will terminate after stopTime is reached. In this case, the NETCONF session will still be an active session. @@ -851,11 +851,11 @@ 3.3.2. Creating a Subscription with Replay This feature uses optional parameters to the - command called 'startTime' and 'stopTime'. 'startTime' identifies the + command called startTime and stopTime. The startTime identifies the earliest date and time of interest for event notifications being replayed and also indicates that a subscription will be providing replay of notifications. Events generated before this time are not - matched. 'stopTime' specifies the latest date and time of interest + matched. The stopTime specifies the latest date and time of interest for event notifications being replayed. If it is not present, then notifications will continue to be sent until the subscription is terminated. @@ -864,9 +864,9 @@ event was generated by the system. A replayComplete notification is sent to indicate that all of the - replay notifications have been sent. If this subscription has a stop - time, then this session becomes a normal NETCONF session again. If - the subscription has no stop time, it can be expected that any + replay notifications have been sent. If this subscription has a stopTime, + then this session becomes a normal NETCONF session again. If + the subscription has no stopTime, it can be expected that any notifications generated since the start of the subscription creation will be sent after the replayComplete notification has been sent, followed by notifications as they arise naturally within the system. @@ -879,7 +879,7 @@ session becomes normal command-response NETCONF session. The replayComplete can not be filtered out. It will always be sent - on a replay subscription that specified a stop time. + on a replay subscription that specified a stopTime. 3.4. Notification Management Schema @@ -1204,7 +1204,7 @@ A parameter used to trigger the replay feature and indicates that the replay should start at the time specified. If - start time is not present, this is not a + startTime is not present, this is not a replay subscription. @@ -1216,10 +1216,10 @@ An optional parameter used with the optional replay feature to indicate the newest notifications of interest. If - stop time is not present, the + stopTime is not present, the notifications will continue until the subscription is terminated. Must be used - with 'startTime'. + with startTime. --Boundary-00=_bS7pGiw+LUS028q-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jul 25 20:02:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDqol-0008N6-MZ for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 20:02:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDqok-0007dN-Cb for netconf-archive@lists.ietf.org; Wed, 25 Jul 2007 20:02:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDqii-0009ZU-Gm for netconf-data@psg.com; Wed, 25 Jul 2007 23:56:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDqiQ-0009Y3-I3 for netconf@ops.ietf.org; Wed, 25 Jul 2007 23:56:35 +0000 Received: from localhost (unknown [67.97.210.2]) by mail.tail-f.com (Postfix) with ESMTP id C74B11B80C3; Thu, 26 Jul 2007 01:56:23 +0200 (CEST) Date: Thu, 26 Jul 2007 01:56:13 +0200 (CEST) Message-Id: <20070726.015613.253916049.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: First pre-release of -09 Notifications From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41016D395@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B41016D395@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / 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: 0ff9c467ad7f19c2a6d058acd7faaec8 Hi, Here's my list of suggested edits to the draft: ---------------------- 3.2.5.1 example: is missing the netconf top-level node, and should be and the reply should be: NETCONF Default netconf event stream true 2007-07-08T00:00:00Z SNMP SNMP notifications false syslog-critical Critical and higher severity true 2007-07-01T00:00:00Z ----------------------- second example in 5.2: weird example, since it always evaluates to false. a better example might be: ( state | config | ( fault & ( severity=critical | severity=major | severity = minor | card=Ethernet0))) /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 Jul 26 00:21:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDuqb-0002av-Nj for netconf-archive@lists.ietf.org; Thu, 26 Jul 2007 00:21:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDuqb-0003Ar-1l for netconf-archive@lists.ietf.org; Thu, 26 Jul 2007 00:21:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDukJ-0004rR-UD for netconf-data@psg.com; Thu, 26 Jul 2007 04:14:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [194.9.94.111] (helo=s87.loopia.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDrAo-000Bs3-KZ for netconf@ops.ietf.org; Thu, 26 Jul 2007 00:25:52 +0000 Received: (qmail 45014 invoked from network); 25 Jul 2007 15:25:42 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 25 Jul 2007 15:25:42 -0000 Received: (qmail 24213 invoked from network); 25 Jul 2007 15:25:43 -0000 Received: from mail.verismo.se (HELO [192.168.99.223]) ([213.115.45.46]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with SMTP for ; 25 Jul 2007 15:25:43 -0000 Message-ID: <46A76B84.6030102@edgeware.tv> Date: Wed, 25 Jul 2007 17:25:56 +0200 From: Johan Rydberg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: Questions on Confirmed commit References: <469C9CE9.5090209@ericsson.com> In-Reply-To: <469C9CE9.5090209@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.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Balazs Lengyel skrev: > The base RFC state the manager can explicitly restore the configuration > to its state before the confirmed commit was issued. How? As I understand the RFC, this is done by keeping a copy of the running configuration, as before the confirmed commit. If the manager wants to cancel a confirmed commit he/she has to load the candidate with the old running configuration and issue a confirming commit. Others do different interpretations: From [1] : To delay the rollback again (past the original rollback deadline), emit the tag (enclosed in the tag element) again before the deadline passes. Include the tag element to specify how long to delay the next rollback, or omit that tag element to use the default of 10 minutes. The rollback can be delayed repeatedly in this way. So using that you could do another new commit with a timeout of zero seconds, to revert the state. But I think that contradicts 8.4.1: Note that any commit operation, including a commit which introduces additional changes to the configuration, will serve as a confirming commit. I interpret that as every configuration will copy to , even if there already is a pending confirmed commit. [1] https://www.juniper.net/techpubs/software/junos/junos80/netconf80-guide/html/summary-netconf-tags4.html#1350982 ~j -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 27 00:17:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEHGW-0000ZO-GL for netconf-archive@lists.ietf.org; Fri, 27 Jul 2007 00:17:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEHGW-0008Tq-4p for netconf-archive@lists.ietf.org; Fri, 27 Jul 2007 00:17:24 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEHAU-0002WR-Fs for netconf-data@psg.com; Fri, 27 Jul 2007 04:11:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEBdV-000E9i-F7 for netconf@ops.ietf.org; Thu, 26 Jul 2007 22:16:50 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEBdT-0000WE-TQ; Fri, 27 Jul 2007 00:16:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Thu, 26 Jul 2007 22:16:43 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #2: error-option for test-only X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/2 Message-ID: <070.9c05e08359345afa247e08ba8ea2fa7c@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 IzI6IGVycm9yLW9wdGlvbiBmb3IgdGVzdC1vbmx5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVw b3J0ZXI6ICBpZXRmQGFuZHliaWVybWFuLmNvbSAgfCAgICAgICBPd25lcjogICAgIA0KICAgICBU eXBlOiAgZW5oYW5jZW1lbnQgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0 eTogIG1pbm9yICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgDQpDb21wb25lbnQ6 ICBSRkM0NzQxICAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAg ICAgICAgICAgICAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFRoZSBlcnJv ci1vcHRpb24gcGFyYW1ldGVyIGZvciB0aGUgZWRpdC1jb25maWcgb3BlcmF0aW9uDQogbmVlZHMg YSBuZXcgZW51bWF0aW9uIGNhbGxlZCAndGVzdC1vbmx5JywgdG8gYWxsb3cNCiB2YWxpZGF0aW9u IG9mIGEgcGFydGlhbCBjb25maWd1cmF0aW9uLiAgVGhlIHZhbGlkYXRlDQogb3BlcmF0aW9uIGNh biBvbmx5IGJlIHVzZWQgZm9yIGEgY29tcGxldGUgY29uZmlndXJhdGlvbg0KIGRhdGFiYXNlLiAg VGhlcmUgaXMgYSBuZWVkIHRvIHRlc3QgaWYgYSBzcGVjaWZpYyBlZGl0LWNvbmZpZw0KIG9wZXJh dGlvbiB3b3VsZCBiZSBhY2NlcHRlZCwgd2l0aG91dCBhY3R1YWxseSBoYXZpbmcNCiB0aGUgY2hh bmdlcyBiZSBtYWRlIGJ5IHRoZSBhZ2VudC4gIEEgbmV3IGVycm9yLW9wdGlvbg0KIHBhcmFtZXRl ciB3aWxsIHNvbHZlIHRoaXMgcHJvYmxlbS4NCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cDovL3Rv b2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy90aWNrZXQvMj4NCk5ldGNvbmYgPGh0dHA6Ly90 b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvPg0KSXNzdWUgdHJhY2tlciBmb3IgdGhlIE5F VENPTkYgV29ya2luZyBHcm91cA== -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 27 00:17:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEHGY-0000Zb-P7 for netconf-archive@lists.ietf.org; Fri, 27 Jul 2007 00:17:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEHGY-0008Tw-Ec for netconf-archive@lists.ietf.org; Fri, 27 Jul 2007 00:17:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEHCe-0002iu-GL for netconf-data@psg.com; Fri, 27 Jul 2007 04:13:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEBi2-000EYS-KJ for netconf@ops.ietf.org; Thu, 26 Jul 2007 22:21:32 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEBi0-0004aO-01; Fri, 27 Jul 2007 00:21:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Thu, 26 Jul 2007 22:21:23 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #3: with-defaults attribute X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/3 Message-ID: <070.ed067114be0b32ab6149a90adb300dc0@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 IzM6IHdpdGgtZGVmYXVsdHMgYXR0cmlidXRlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0 ZXI6ICBpZXRmQGFuZHliaWVybWFuLmNvbSAgfCAgICAgICBPd25lcjogICAgIA0KICAgICBUeXBl OiAgZW5oYW5jZW1lbnQgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTog IG1ham9yICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgDQpDb21wb25lbnQ6ICBS RkM0NzQxICAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgZGVm YXVsdHMgICAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFRoZSBORVRDT05G IGdldCBhbmQgZ2V0LWNvbmZpZyBvcGVyYXRpb25zIGFsd2F5cyByZXR1cm4NCiBhbGwgbm9kZXMg ZnJvbSBhbiBhZ2VudCB0aGF0IGhhdmUgYSB2YWx1ZS4gIEhvd2V2ZXIsDQogaXQgaXMgb2Z0ZW4g ZGVzaXJhYmxlIHRvIHN1cHByZXNzIGdlbmVyYXRpb24gb2YgdGhlc2UNCiB2YWx1ZXMgZm9yIGRh dGEgbm9kZXMgd2hpY2ggY29udGFpbiB0aGUgYWdlbnQtc3VwcGxpZWQNCiBkZWZhdWx0IHZhbHVl LiAgVGhpcyBzYXZlcyBiYW5kd2lkdGggYW5kIE5WLXN0b3JhZ2UNCiByZXF1aXJlbWVudHMuDQoN CiBBIG1lY2hhbmlzbSBpcyBuZWVkZWQgdG8gaW5kaWNhdGUgdG8gdGhlIGFnZW50IHRoYXQNCiBu b2RlcyBjb250YWluaW5nIGFnZW50LXN1cHBsaWVkIGRlZmF1bHQgdmFsdWVzIHNob3VsZA0KIGJl IGluY2x1ZGVkIG9yIHN1cHByZXNzZWQgaW4gZ2V0IG9yIGdldC1jb25maWcgb3V0cHV0Lg0KDQot LSANClRpY2tldCBVUkw6IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFjL3Rp Y2tldC8zPg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+ DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jul 27 00:17:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEHGZ-0000Zo-FJ for netconf-archive@lists.ietf.org; Fri, 27 Jul 2007 00:17:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEHGY-0008Tv-8z for netconf-archive@lists.ietf.org; Fri, 27 Jul 2007 00:17:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEHA9-0002VB-NB for netconf-data@psg.com; Fri, 27 Jul 2007 04:10:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEBYe-000DlE-4X for netconf@ops.ietf.org; Thu, 26 Jul 2007 22:11:49 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEBYc-0000LI-5V; Fri, 27 Jul 2007 00:11:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Thu, 26 Jul 2007 22:11:42 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #1: message-id attribute not used X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/1 Message-ID: <070.9ed95934849d897ed0367b0bccb57aa6@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab IzE6IG1lc3NhZ2UtaWQgYXR0cmlidXRlIG5vdCB1c2VkDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog UmVwb3J0ZXI6ICBpZXRmQGFuZHliaWVybWFuLmNvbSAgfCAgICAgICBPd25lcjogICAgICAgICAg ICANCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3 ICAgICAgIA0KIFByaW9yaXR5OiAgbWlub3IgICAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6 ICBtaWxlc3RvbmUxDQpDb21wb25lbnQ6ICBSRkM0NzQxICAgICAgICAgICAgICAgfCAgICAgVmVy c2lvbjogIDEuMCAgICAgICANCiBLZXl3b3JkczogIG1lc3NhZ2UtaWQgICAgICAgICAgICB8ICAN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBUaGUgbWVzc2FnZS1pZCBhdHRyaWJ1dGUgaXMgcmVxdWly ZWQgdG8gYmUgcHJlc2VudCBpbg0KIGFuIDxycGM+IHJlcXVlc3Qgb24gdGhlIGFnZW50IG11c3Qg cmV0dXJuIGFuIGVycm9yLg0KIEhvd2V2ZXIsIHRoaXMgYXR0cmlidXRlIGlzIG5vdCBhY3R1YWxs eSB1c2VkIGluIE5FVENPTkYsDQogYW5kIHRoZXJlIGlzIG5vIHJlYXNvbiB0byByZXR1cm4gYW4g ZXJyb3IgaWYgdGhpcw0KIGF0dHJpYnV0ZSBpcyBtaXNzaW5nLg0KDQotLSANClRpY2tldCBVUkw6 IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFjL3RpY2tldC8xPg0KTmV0Y29u ZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0cmFja2Vy IGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 03:48:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEh2n-0002OL-68 for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 03:48:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEh2m-0005sO-RN for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 03:48:57 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEgwW-000AHY-ML for netconf-data@psg.com; Sat, 28 Jul 2007 07:42:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEgwL-000AGL-EB for netconf@ops.ietf.org; Sat, 28 Jul 2007 07:42:23 +0000 Received: (qmail 90080 invoked from network); 28 Jul 2007 07:42:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 28 Jul 2007 07:42:16 -0000 X-YMail-OSG: v9UzpmIVM1n3xaEGgfoMxQZVsSoa8WCou.C9nI8gAMbmwMcZgW8f34B9dksp5kfl8EnRJlFwyh0- Message-ID: <46AAF304.2030701@andybierman.com> Date: Sat, 28 Jul 2007 00:40:52 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: NETCONF Issue Tracker 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.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi, The WG now has an issue tracker (better late than never), thanks to David Partain. http://tools.ietf.org/wg/netconf/trac/report/1 David has agreed to help administer the list, so please ask him how it works ;-) We are still working out the kinks, but there are 5 components in the NETCONF project: - RFC4741 - RFC4742 - RFC4743 - RFC4744 - draft-ietf-netconf-notification I have already filed 3 tickets for feature enhancements to RFC4741. Each of the reviewers who raised issed with notification-08 should click on the 'Get Passwd' button, and then login and enter a ticket for each issue (with component == draft-ietf-netconf-notification). 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 Sat Jul 28 03:57:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEhBF-0007y5-JD for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 03:57:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEhBF-00062n-4G for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 03:57:41 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEh79-000B6U-89 for netconf-data@psg.com; Sat, 28 Jul 2007 07:53:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEh6y-000B5f-3C for netconf@ops.ietf.org; Sat, 28 Jul 2007 07:53:21 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEh6v-00053N-Dt; Sat, 28 Jul 2007 09:53:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Sat, 28 Jul 2007 07:53:13 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #4: bad-namespace wrong data type X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/4 Message-ID: <070.90a52f1bffdd0c73307a5b60337daeb9@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 IzQ6IGJhZC1uYW1lc3BhY2Ugd3JvbmcgZGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog UmVwb3J0ZXI6ICBpZXRmQGFuZHliaWVybWFuLmNvbSAgfCAgICAgICBPd25lcjogICAgIA0KICAg ICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlv cml0eTogIG1ham9yICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgDQpDb21wb25l bnQ6ICBSRkM0NzQxICAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRz OiAgZGF0YSB0eXBlICAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIEZyb20g TWFydGluIEJqb3JrbHVuZDoNCiBodHRwOi8vcHNnLmNvbS9saXN0cy9uZXRjb25mL25ldGNvbmYu MjAwNy9tc2cwMDAyMy5odG1sDQoNCiBUaGUgZWxlbWVudCAnYmFkLW5hbWVzcGFjZScgaXMgZGVm aW5lZCBhcyBhIFFOYW1lLCBidXQgaXQNCiBzaG91bGQgYmUgYSBzdHJpbmcgb3IgdG9rZW4uICBG b3IgZXhhbXBsZSwNCiAiaHR0cDovL2V4YW1wbGUuY29tL2JhZC9uYW1lc3BhY2UiOyBpcyBub3Qg YSB2YWxpZCBRTmFtZS4NCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cDovL3Rvb2xzLmlldGYub3Jn L3dnL25ldGNvbmYvdHJhYy90aWNrZXQvND4NCk5ldGNvbmYgPGh0dHA6Ly90b29scy5pZXRmLm9y Zy93Zy9uZXRjb25mL3RyYWMvPg0KSXNzdWUgdHJhY2tlciBmb3IgdGhlIE5FVENPTkYgV29ya2lu ZyBHcm91cA== -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 03:59:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEhDP-0001Mg-6E for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 03:59:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEhDO-00064y-Qo for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 03:59:55 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEh9h-000BO6-1R for netconf-data@psg.com; Sat, 28 Jul 2007 07:56:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEh9W-000BMP-5s for netconf@ops.ietf.org; Sat, 28 Jul 2007 07:55:59 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEh9U-0005Cu-Pg; Sat, 28 Jul 2007 09:55:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Sat, 28 Jul 2007 07:55:52 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #5: error-app-tag should have QName data type X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/5 Message-ID: <070.1d9f49a4dfc724d0ee78531ee17c5893@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab IzU6IGVycm9yLWFwcC10YWcgc2hvdWxkIGhhdmUgUU5hbWUgZGF0YSB0eXBlDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBpZXRmQGFuZHliaWVybWFuLmNvbSAgfCAgICAgICBPd25l cjogICAgIA0KICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICAgICAgIHwgICAgICBTdGF0dXM6 ICBuZXcNCiBQcmlvcml0eTogIG1pbm9yICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAg ICAgDQpDb21wb25lbnQ6ICBSRkM0NzQxICAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjogICAg IA0KIEtleXdvcmRzOiAgZGF0YS1tb2RlbCAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KIEZyb20gTWFydGluIEJqb3JrbHVuZDoNCiBodHRwOi8vcHNnLmNvbS9saXN0cy9uZXRj b25mL25ldGNvbmYuMjAwNy9tc2cwMDAyMy5odG1sDQoNCiBUaGUgZXJyb3ItYXBwLXRhZyBzaG91 bGQgaGF2ZSBiZWVuIGRlZmluZWQgYXMgYQ0KIFFOYW1lIGluc3RlYWQgb2YgYXMgYSBzdHJpbmcs IHNpbmNlIHRoYXQgd291bGQgaGF2ZSBtYWRlIGl0IHBvc3NpYmxlDQogdG8gZGVmaW5lIGRhdGEt bW9kZWwvaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgdGFncyBpbiBuYW1lc3BhY2VzLCB0aHVzDQog YXZvaWRpbmcgdGhlIHJpc2sgb2YgY29sbGlzaW9ucy4NCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0 cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy90aWNrZXQvNT4NCk5ldGNvbmYgPGh0 dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvPg0KSXNzdWUgdHJhY2tlciBmb3Ig dGhlIE5FVENPTkYgV29ya2luZyBHcm91cA== -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 04:07:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEhKK-0006GE-D5 for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:07:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEhKK-0006P9-2M for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:07:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhGH-000Bt8-H1 for netconf-data@psg.com; Sat, 28 Jul 2007 08:02:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhG6-000BsU-Ld for netconf@ops.ietf.org; Sat, 28 Jul 2007 08:02:48 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEhG5-0005X4-5O; Sat, 28 Jul 2007 10:02:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Sat, 28 Jul 2007 08:02:41 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #6: documentation clarifications X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/6 Message-ID: <070.0da6f27118396d143a8b8a5c6b50cc80@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 IzY6IGRvY3VtZW50YXRpb24gY2xhcmlmaWNhdGlvbnMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBS ZXBvcnRlcjogIGlldGZAYW5keWJpZXJtYW4uY29tICAgICAgICAgICAgIHwgICAgICAgT3duZXI6 ICAgICANCiAgICAgVHlwZTogIGVuaGFuY2VtZW50ICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1pbm9yICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICBNaWxlc3RvbmU6ICAgICANCkNvbXBvbmVudDogIGRyYWZ0LWlldGYtbmV0Y29uZi1u b3RpZmljYXRpb24gIHwgICAgIFZlcnNpb246ICAgICANCiBLZXl3b3JkczogIGNsYXJpZmljYXRp b24gICAgICAgICAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIEZyb20gQW5k eSBCaWVybWFuOg0KIGh0dHA6Ly9wc2cuY29tL2xpc3RzL25ldGNvbmYvbmV0Y29uZi4yMDA3L21z ZzAwMzM2Lmh0bWwNCg0KIFdpbGwgd29yayB3aXRoIGF1dGhvcnMgYXMgbmVlZGVkIHRvIGlkZW50 aWZ5IG5lZWRlZCBlZGl0cw0KIGZvdW5kIGluIHRoZSBpbmRpY2F0ZWQgZW1haWwuDQoNCi0tIA0K VGlja2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0 LzY+DQpOZXRjb25mIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFjLz4NCklz c3VlIHRyYWNrZXIgZm9yIHRoZSBORVRDT05GIFdvcmtpbmcgR3JvdXA= -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 04:09:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEhN2-0007vf-T6 for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:09:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEhN1-0006Rc-M7 for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:09:52 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhJ3-000C7X-0Y for netconf-data@psg.com; Sat, 28 Jul 2007 08:05:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhIs-000C5y-0a for netconf@ops.ietf.org; Sat, 28 Jul 2007 08:05:39 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEhIq-0005iS-IF; Sat, 28 Jul 2007 10:05:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Sat, 28 Jul 2007 08:05:32 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #7: URI assignments for IANA X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/7 Message-ID: <070.38ba5063d4a22174ac6dfb88de1c5f98@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Izc6IFVSSSBhc3NpZ25tZW50cyBmb3IgSUFOQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9y dGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5jb20gICAgICAgICAgICAgfCAgICAgICBPd25lcjogICAg IA0KICAgICBUeXBlOiAgdGFzayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgIE1pbGVzdG9uZTogICAgIA0KQ29tcG9uZW50OiAgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlm aWNhdGlvbiAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogRnJvbSBBbmR5IEJp ZXJtYW46DQogaHR0cDovL3BzZy5jb20vbGlzdHMvbmV0Y29uZi9uZXRjb25mLjIwMDcvbXNnMDAz MzYuaHRtbA0KDQogMSkgQ2FwYWJpbGl0eSBmb3Igbm90aWZpY2F0aW9uIHN1cHBvcnQsIHVzZWQg aW4gPGhlbGxvPg0KDQogICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5 Om5vdGlmaWNhdGlvbjoxLjANCg0KIDIpIE5hbWVzcGFjZSBVUkkgZm9yIHRoZSBYU0QgaW4gMy40 Og0KDQogICAgInVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlvbiINCg0K IDMpIE5hbWVzcGFjZSBVUkkgZm9yIHRoZSBYU0QgaW4gNC46DQoNCiAgICAidXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbiINCg0KDQogVGhlICd0YXJnZXROYW1lc3Bh Y2UnIHZhbHVlIGN1cnJlbnRseSBpbiB1c2UgaW4gNC4gaXMgd3Jvbmc6DQoNCiAgICAidXJuOmll dGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIg0KDQotLSANClRp Y2tldCBVUkw6IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFjL3RpY2tldC83 Pg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1 ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 04:14:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEhRm-0002FO-OQ for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:14:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEhRm-0006WY-9d for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:14:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhNm-000CVD-AP for netconf-data@psg.com; Sat, 28 Jul 2007 08:10:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhNb-000CT1-4v for netconf@ops.ietf.org; Sat, 28 Jul 2007 08:10:32 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEhNZ-0006bJ-Nx; Sat, 28 Jul 2007 10:10:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Sat, 28 Jul 2007 08:10:25 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #8: URL assignments for IANA X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/8 Message-ID: <070.d007e813d32e6abb6593993afae85207@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Izg6IFVSTCBhc3NpZ25tZW50cyBmb3IgSUFOQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9y dGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5jb20gICAgICAgICAgICAgfCAgICAgICBPd25lcjogICAg IA0KICAgICBUeXBlOiAgdGFzayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgIE1pbGVzdG9uZTogICAgIA0KQ29tcG9uZW50OiAgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlm aWNhdGlvbiAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogRnJvbSBBbmR5IEJp ZXJtYW46DQogaHR0cDovL3BzZy5jb20vbGlzdHMvbmV0Y29uZi9uZXRjb25mLjIwMDcvbXNnMDAz MzYuaHRtbA0KDQogTmVlZCBJQU5BIHRvIGFzc2lnbiBVUkxzIGZvciBlYWNoIG9mIHRoZSAyIFhT RHMgaW4gdGhlIGRyYWZ0LA0KIGFuZCBlYWNoIFhTRCBleHRyYWN0ZWQgYW5kIG1hZGUgYXZhaWxh YmxlIG9ubGluZS4NCg0KIEZvciBleGFtcGxlLA0KICJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbm90aWZpY2F0aW9uLnhzZCI7DQoNCi0tIA0KVGlj a2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0Lzg+ DQpOZXRjb25mIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFjLz4NCklzc3Vl IHRyYWNrZXIgZm9yIHRoZSBORVRDT05GIFdvcmtpbmcgR3JvdXA= -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 04:23:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEhaC-0000mj-LS for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:23:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEhaC-0006h2-AB for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:23:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhVq-000D70-DZ for netconf-data@psg.com; Sat, 28 Jul 2007 08:18:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhVf-000D69-Fo for netconf@ops.ietf.org; Sat, 28 Jul 2007 08:18:52 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEhVd-0006Xs-BE; Sat, 28 Jul 2007 10:18:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Sat, 28 Jul 2007 08:18:45 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #9: notification replay in the future X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/9 Message-ID: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Izk6IG5vdGlmaWNhdGlvbiByZXBsYXkgaW4gdGhlIGZ1dHVyZQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KIFJlcG9ydGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5jb20gICAgICAgICAgICAgfCAgICAgICBP d25lcjogICAgIA0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgIA0KQ29tcG9uZW50OiAgZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbiAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgbm90aWZp Y2F0aW9uIHJlcGxheSAgICAgICAgICAgICAgfCAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogVGhl IHN0YXJ0VGltZSBhbmQvb3Igc3RvcFRpbWUgcGFyYW1ldGVycyB0byB0aGUgY3JlYXRlLXN1YnNj cmlwdGlvbg0KIG9wZXJhdGlvbiBjYW4gYmUgaW4gdGhlIGZ1dHVyZS4gIFRoaXMgaXMgdW5pbnRl bmRlZCBiZWhhdmlvciB0aGF0DQogaXMgbm90IHBhcnQgb2YgdGhlIG9yaWdpbmFsIHVzZSBjYXNl cyBmb3IgdGhpcyBmZWF0dXJlLg0KDQogUmVxdWlyaW5nIHRoZSBhZ2VudCB0byByZXBsYXkgbm90 aWZpY2F0aW9ucyB0aGF0IGhhdmUgbm90DQogaGFwcGVuZWQgeWV0IGlzIG5vbi1pbnR1aXRpdmUs IGFuZCB0aGVyZSBpcyBzb21lIGFtYmlndWl0eQ0KIHdpdGggdGhlIG1lYW5pbmcgb2YgdGhlIDxy ZXBsYXlDb21wbGV0ZT4gbm90aWZpY2F0aW9uLA0KIGFuZCB3aGVuIGl0IHNob3VsZCBiZSBzZW50 Lg0KDQogVGhlIHRleHQgc2hvdWxkIGJlIGNsZWFyIHRoYXQgdGhlIGFnZW50IE1BWSBOT1Qgc3Vw cG9ydA0KIHN0YXJ0VGltZSBhbmQvb3Igc3RvcFRpbWUgdmFsdWVzIGluIHRoZSBmdXR1cmUuDQoN Ci0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMv dGlja2V0Lzk+DQpOZXRjb25mIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFj Lz4NCklzc3VlIHRyYWNrZXIgZm9yIHRoZSBORVRDT05GIFdvcmtpbmcgR3JvdXA= -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 04:27:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEhdl-0002va-26 for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:27:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEhdj-0006lt-Qo for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 04:27:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhZy-000DTI-RY for netconf-data@psg.com; Sat, 28 Jul 2007 08:23:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEhZn-000DR9-W3 for netconf@ops.ietf.org; Sat, 28 Jul 2007 08:23:09 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IEhZm-0005cy-JY; Sat, 28 Jul 2007 10:23:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Sat, 28 Jul 2007 08:23:02 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #10: replayLogStartTime clarification X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/10 Message-ID: <070.e28fad73e1d98416e8be788c4d268321@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 IzEwOiByZXBsYXlMb2dTdGFydFRpbWUgY2xhcmlmaWNhdGlvbg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KIFJlcG9ydGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5jb20gICAgICAgICAgICAgfCAgICAgICBP d25lcjogICAgIA0KICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICAgICAgICAgICAgICAgICAg fCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgIA0KQ29tcG9uZW50OiAgZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbiAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogQ2xh cmlmaWNhdGlvbiBvZiB0aGUgcmVwbGF5TG9nU3RhcnRUaW1lIGlzIG5lZWRlZC4NCiBUaGUgZXhh Y3QgYmVoYXZpb3IgdGhlIG1hbmFnZXIgc2hvdWxkIGV4cGVjdCBuZWVkcyB0bw0KIGJlIHNwZWNp ZmllZC4NCg0KIFRoZXJlIGlzIGEgYnVnIHdpdGggdGhlIGN1cnJlbnQgdGV4dCwgYmVjYXVzZQ0K IHRoaXMgZWxlbWVudCBpcyBtYW5kYXRvcnkuDQoNCiBFaXRoZXIgdGhlIHN0YXJ0IHRpbWUgY2Fu IHJlcHJlc2VudCB0aGUgdGltZSB0aGUgbG9nDQogd2FzIGNyZWF0ZWQsIG9yIGl0IGNhbiByZXBy ZXNlbnQgdGhlIHRpbWUgb2YgdGhlIGVhcmxpZXN0DQogbm90aWZpY2F0aW9uIGluIHRoZSBsb2cg KG1vcmUgdXNlZnVsKSwgaWYgYW55LCBidXQgbm90IGJvdGguDQoNCi0tIA0KVGlja2V0IFVSTDog PGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzEwPg0KTmV0Y29u ZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0cmFja2Vy IGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 14:35:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEr8J-00077N-6Y for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 14:35:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEr8I-0008BK-M2 for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 14:35:19 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEr1b-000IHV-E4 for netconf-data@psg.com; Sat, 28 Jul 2007 18:28:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.229.101] (helo=smtp104.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEr1P-000IFF-T7 for netconf@ops.ietf.org; Sat, 28 Jul 2007 18:28:17 +0000 Received: (qmail 24653 invoked from network); 28 Jul 2007 18:28:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp104.sbc.mail.re2.yahoo.com with SMTP; 28 Jul 2007 18:28:10 -0000 X-YMail-OSG: tBkhyEIVM1mM2GOHkUV2easiLBT_LiRYVoRCADTT28ij67t5LRgB9Rb.MvmfuoH2uqAF8yv8FfPx.mwIJte60nVycLkYd_lAC5XIw32Bf59zv2wrpw8iEQ-- Message-ID: <46AB8A66.90800@andybierman.com> Date: Sat, 28 Jul 2007 11:26:46 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: NETCONF Issue Tracker References: <46AAF304.2030701@andybierman.com> In-Reply-To: <46AAF304.2030701@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.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Andy Bierman wrote: > Hi, > > The WG now has an issue tracker (better late than never), > thanks to David Partain. > > http://tools.ietf.org/wg/netconf/trac/report/1 > I noticed the tracker assigned ticket numbers from 1 to N across all components. It would be better if the numbering was per component. The WG does not need to resolve the RFC4741 tickets to complete the Notifications deliverable. A flat numbering scheme like the arbitrary and scattered RFC numbers is not very user-friendly either. These are not software components within an application, they are independent drafts. Is there another numbering scheme available in trac? Andy > David has agreed to help administer the list, > so please ask him how it works ;-) We are still working > out the kinks, but there are 5 components in the NETCONF project: > > - RFC4741 > - RFC4742 > - RFC4743 > - RFC4744 > - draft-ietf-netconf-notification > > I have already filed 3 tickets for feature enhancements to RFC4741. > Each of the reviewers who raised issed with notification-08 should > click on the 'Get Passwd' button, and then login and enter a ticket > for each issue (with component == draft-ietf-netconf-notification). > > 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 Sat Jul 28 16:29:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEsug-0002K4-8t for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 16:29:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEsuf-0002sF-Q2 for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 16:29:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEsnB-0006mK-2N for netconf-data@psg.com; Sat, 28 Jul 2007 20:21:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.99] (helo=smtp106.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEsn0-0006lo-0T for netconf@ops.ietf.org; Sat, 28 Jul 2007 20:21:31 +0000 Received: (qmail 1527 invoked from network); 28 Jul 2007 20:21:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp106.sbc.mail.re2.yahoo.com with SMTP; 28 Jul 2007 20:21:24 -0000 X-YMail-OSG: LmCUzdEVM1nKIGpNxJ9h0g4lY6dW3I7RNPnQgoaUH2j.ydBfVU1Wfa7s5Q9Y2Z8J.4k68F8gBh0b0UYJZszh2zb8W5TpXSCVtI1CYkPvnTJdjJlHoQJHFA-- Message-ID: <46ABA4F0.5000808@andybierman.com> Date: Sat, 28 Jul 2007 13:20:00 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: "'Netconf (E-mail)'" Subject: Re: NETCONF Issue Tracker References: <46AAF304.2030701@andybierman.com> <46AB8A66.90800@andybierman.com> <023a01c7d14b$391b95d0$79aa1cac@china.huawei.com> In-Reply-To: <023a01c7d14b$391b95d0$79aa1cac@china.huawei.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.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 David B Harrington wrote: > Hi, > > If you click on the "component" title, it will sort the issues by > component. > > I think I'm enough of an angineer to be able to figure out this > system, even if the numbers for each component are not separate. > You are right. It is good enough. We should try using it as intended, which is to enter comments directly into the tracker instead of sending an email to the mailing directly. The tracker will send the email announcing the new ticket. > dbh Andy > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >> Sent: Saturday, July 28, 2007 1:27 PM >> To: Andy Bierman >> Cc: Netconf (E-mail) >> Subject: Re: NETCONF Issue Tracker >> >> Andy Bierman wrote: >>> Hi, >>> >>> The WG now has an issue tracker (better late than never), >>> thanks to David Partain. >>> >>> http://tools.ietf.org/wg/netconf/trac/report/1 >>> >> I noticed the tracker assigned ticket numbers from 1 to N >> across all components. It would be better if the numbering >> was per component. The WG does not need to resolve the >> RFC4741 tickets to complete the Notifications deliverable. >> A flat numbering scheme like the arbitrary and scattered RFC numbers >> is not very user-friendly either. These are not software >> components within an application, they are independent drafts. >> >> >> Is there another numbering scheme available in trac? >> >> >> Andy >> >> >> >>> David has agreed to help administer the list, >>> so please ask him how it works ;-) We are still working >>> out the kinks, but there are 5 components in the NETCONF project: >>> >>> - RFC4741 >>> - RFC4742 >>> - RFC4743 >>> - RFC4744 >>> - draft-ietf-netconf-notification >>> >>> I have already filed 3 tickets for feature enhancements to > RFC4741. >>> Each of the reviewers who raised issed with notification-08 should >>> click on the 'Get Passwd' button, and then login and enter a > ticket >>> for each issue (with component == > draft-ietf-netconf-notification). >>> thanks, >>> Andy >>> >>> >>> >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >>> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jul 28 22:05:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEy9c-00080q-2Q for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 22:05:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEy9a-0002lW-Nf for netconf-archive@lists.ietf.org; Sat, 28 Jul 2007 22:05:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEy2b-0007CX-TO for netconf-data@psg.com; Sun, 29 Jul 2007 01:57:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [206.18.177.52] (helo=alnrmhc12.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEy2Q-0007Bq-Pf for netconf@ops.ietf.org; Sun, 29 Jul 2007 01:57:48 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070728191227b1200dd6mre>; Sat, 28 Jul 2007 19:12:29 +0000 From: "David B Harrington" To: "'Andy Bierman'" Cc: "'Netconf \(E-mail\)'" References: <46AAF304.2030701@andybierman.com> <46AB8A66.90800@andybierman.com> Subject: RE: NETCONF Issue Tracker Date: Sat, 28 Jul 2007 14:12:17 -0500 Message-ID: <023a01c7d14b$391b95d0$79aa1cac@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.3138 Thread-Index: AcfRRgxxO47XCuMoQqSPZ2ryZ1HlfgABN+4g In-Reply-To: <46AB8A66.90800@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi, If you click on the "component" title, it will sort the issues by component. I think I'm enough of an angineer to be able to figure out this system, even if the numbers for each component are not separate. dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Saturday, July 28, 2007 1:27 PM > To: Andy Bierman > Cc: Netconf (E-mail) > Subject: Re: NETCONF Issue Tracker > > Andy Bierman wrote: > > Hi, > > > > The WG now has an issue tracker (better late than never), > > thanks to David Partain. > > > > http://tools.ietf.org/wg/netconf/trac/report/1 > > > > I noticed the tracker assigned ticket numbers from 1 to N > across all components. It would be better if the numbering > was per component. The WG does not need to resolve the > RFC4741 tickets to complete the Notifications deliverable. > A flat numbering scheme like the arbitrary and scattered RFC numbers > is not very user-friendly either. These are not software > components within an application, they are independent drafts. > > > Is there another numbering scheme available in trac? > > > Andy > > > > > David has agreed to help administer the list, > > so please ask him how it works ;-) We are still working > > out the kinks, but there are 5 components in the NETCONF project: > > > > - RFC4741 > > - RFC4742 > > - RFC4743 > > - RFC4744 > > - draft-ietf-netconf-notification > > > > I have already filed 3 tickets for feature enhancements to RFC4741. > > Each of the reviewers who raised issed with notification-08 should > > click on the 'Get Passwd' button, and then login and enter a ticket > > for each issue (with component == draft-ietf-netconf-notification). > > > > thanks, > > Andy > > > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 08:16:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUAq-0008R5-La for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 08:16:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFUAp-0004SK-Ab for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 08:16:32 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFU3n-000CAR-7n for netconf-data@psg.com; Mon, 30 Jul 2007 12:09:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFU3c-000C9Q-9m for netconf@ops.ietf.org; Mon, 30 Jul 2007 12:09:09 +0000 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-outbound.avaya.com with ESMTP; 30 Jul 2007 08:09:03 -0400 X-IronPort-AV: i="4.19,198,1183348800"; d="scan'208"; a="48079941:sNHT8407482" 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: Proposed text for Section 1.2 of the notifications draft Date: Mon, 30 Jul 2007 14:08:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed text for Section 1.2 of the notifications draft Thread-Index: AcfSolFJU81q6QZ4TpqwG2VIRZeiOQ== From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" Cc: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Following the discussions in Chicago, here is my action item including the proposed text of section 1.2 of the Notifications Draft.=20 - Section 1.4 in draft-08 will disappear.=20 - Proposed text for new Section 1.2 1.2 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. The scope of the work aims meeting the following operational needs:=20 o The initial release should ensure support for notifications in support of configuration operations o It should be possible to use the same data model for notifications as=20 for configuration operations.=20 o There will be a limit for the message size at a reasonable value (ie, not too short)=20 o The notifications should be carried over a connection-oriented delivery=20 mechanism o A subscription mechanism for notifications should be provided. This=20 takes into account that a NETCONF server does not send notifications=20 before being asked to do so and that it is the NETCONF client who initiates the flow of notifications o A filtering mechanism for sending notifications should be put in place within the NETCONF server o The information contained in a notification should be sufficient=20 so that it can be analyzed independent of the transport mechanism. In other words the data content fully describes a notification;=20 protocol information is not needed to understand a notification, o The server should have the capability to replay locally logged=20 notifications Let me know if this looks OK.=20 Dan =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 12:12:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXqr-0005i2-BH for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:12:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXqq-0001at-0c for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:12:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXjL-00075G-TQ for netconf-data@psg.com; Mon, 30 Jul 2007 16:04:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXjA-000747-PZ for netconf@ops.ietf.org; Mon, 30 Jul 2007 16:04:18 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFXj8-0000cs-PM; Mon, 30 Jul 2007 18:04:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Mon, 30 Jul 2007 16:04:10 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: Re: [Netconf] #1: message-id attribute not used X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/1#comment:1 Message-ID: <079.c98cbd8132a0b9ea6c8ce37ef1c67164@tools.ietf.org> References: <070.9ed95934849d897ed0367b0bccb57aa6@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <070.9ed95934849d897ed0367b0bccb57aa6@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: balazs.lengyel@ericsson.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 IzE6IG1lc3NhZ2UtaWQgYXR0cmlidXRlIG5vdCB1c2VkDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog IFJlcG9ydGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5jb20gIHwgICAgICAgT3duZXI6ICAgICAgICAg ICAgDQogICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBu ZXcgICAgICAgDQogIFByaW9yaXR5OiAgbWlub3IgICAgICAgICAgICAgICAgIHwgICBNaWxlc3Rv bmU6ICBtaWxlc3RvbmUxDQogQ29tcG9uZW50OiAgUkZDNDc0MSAgICAgICAgICAgICAgIHwgICAg IFZlcnNpb246ICAxLjAgICAgICAgDQpSZXNvbHV0aW9uOiAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgS2V5d29yZHM6ICBtZXNzYWdlLWlkDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDb21tZW50 IChieSBiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20pOg0KDQogV2UgZG8gd2FudCB0byB1c2Ug aXQuIFdlIHdhbnQgdG8gc2VuZCBub3RpZmljYXRpb25zIGFib3V0IGxvbmcgcnVubmluZw0KIG9w ZXJhdGlvbnMgbGlrZSBiYWNrdXAuIFdlIHdpbGwgaWRlbnRpZnkgdGhlIG9yaWdpbmFsIG9wZXJh dGlvbiB1c2luZyB0aGUNCiBtZXNzYWdlLWlkLg0KIEl0IGNvdWxkIGFsc28gYmUgdXNlZnVsIGZv ciBsb2dnaW5nLCB0byBwYWlyIHRoZSByZXF1ZXN0IGFuZCB0aGUgYW5zd2VyLg0KIFtbQlJdXQ0K IFBsZWFzZSBkbyBub3QgcmVtb3ZlIGl0Lg0KIFtbQlJdXQ0KIEJhbGF6cyBMZW5neWVsDQoNCi0t IA0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlj a2V0LzEjY29tbWVudDoxPg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNv bmYvdHJhYy8+DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 12:13:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXsP-0006Bs-RT for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:13:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXsO-0001cx-KR for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:13:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXnR-0007Xw-67 for netconf-data@psg.com; Mon, 30 Jul 2007 16:08:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXnG-0007Wl-9B for netconf@ops.ietf.org; Mon, 30 Jul 2007 16:08:31 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFXnE-0000uU-PZ; Mon, 30 Jul 2007 18:08:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Mon, 30 Jul 2007 16:08:24 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: Re: [Netconf] #9: notification replay in the future X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/9#comment:1 Message-ID: <079.2387c158ec8829ed1895aafb925c4adc@tools.ietf.org> References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: balazs.lengyel@ericsson.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Izk6IG5vdGlmaWNhdGlvbiByZXBsYXkgaW4gdGhlIGZ1dHVyZQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICBSZXBvcnRlcjogIGlldGZAYW5keWJpZXJtYW4uY29tICAgICAgICAgICAgIHwgICAgICAg T3duZXI6ICAgICAgICAgICAgICAgICAgICAgDQogICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldyAgICAgICAgICAgICAgICANCiAg UHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25l OiAgICAgICAgICAgICAgICAgICAgIA0KIENvbXBvbmVudDogIGRyYWZ0LWlldGYtbmV0Y29uZi1u b3RpZmljYXRpb24gIHwgICAgIFZlcnNpb246ICAgICAgICAgICAgICAgICAgICAgDQpSZXNvbHV0 aW9uOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBLZXl3b3JkczogIG5v dGlmaWNhdGlvbiByZXBsYXkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNvbW1lbnQgKGJ5IGJhbGF6 cy5sZW5neWVsQGVyaWNzc29uLmNvbSk6DQoNCiBXZSBzaG91bGQgdXNlIE1VU1QgTk9UIGluc3Rl YWQgb2YgTUFZIE5PVC4gV2UgbmV2ZXIgd2FudCBhIHJlcGxheSBvZiB0aGUNCiBmdXR1cmUuDQoN Ci0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMv dGlja2V0LzkjY29tbWVudDoxPg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25l dGNvbmYvdHJhYy8+DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 12:24:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFY34-0004LK-KK for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:24:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFY33-0001tI-Dp for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:24:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXuv-0008Rh-GR for netconf-data@psg.com; Mon, 30 Jul 2007 16:16:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXuk-0008Qe-L4 for netconf@ops.ietf.org; Mon, 30 Jul 2007 16:16:16 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFXuj-0008JV-1h; Mon, 30 Jul 2007 18:16:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Mon, 30 Jul 2007 16:16:08 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #11: NETCONF base clarifications X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/11 Message-ID: <077.32d6c3d8f73c4e9770958f8980a14aa0@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: balazs.lengyel@ericsson.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 IzExOiBORVRDT05GIGJhc2UgY2xhcmlmaWNhdGlvbnMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBS ZXBvcnRlcjogIGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSAgfCAgICAgICBPd25lcjogICAg IA0KICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVz OiAgbmV3DQogUHJpb3JpdHk6ICBtaW5vciAgICAgICAgICAgICAgICAgICAgICAgIHwgICBNaWxl c3RvbmU6ICAgICANCkNvbXBvbmVudDogIFJGQzQ3NDEgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBBIG51bWJlciBvZiBpc3N1ZXMgc2hvdWxkIGJl IGNsYXJpZmllZCBpbiBSRkM0NzQxOltbQlJdXQ0KIDEpIEhvdyB0byBoYW5kbGUgPGVkaXQtY29u ZmlnPiBpZiBtdWx0aXBsZSBvcGVyYXRpb24gcGFyYW1ldGVycyBhcmUNCiBwcmVzZW50P1tbQlJd XQ0KIDIpIEhvdyBtYW55IHJvb3RzIGNhbiBhIGRhdGFzdG9yZSBoYXZlPyAob25lLCBvbmUgcGVy IG5hbWVzcGFjZSwNCiBtYW55KVtbQlJdXQ0KIDMpIEhvdyB0byBhcHBseSBmaWx0ZXJzIG9uIG11 bHRpLXJvb3RlZCBkYXRhc3RvcmVzPyAoQXBwbHkgdGhlIGZpbHRlciBvbg0KIGVhY2ggcm9vdCBh bmQgcHV0IGFsbCByZXN1bHRzIGludG8gdGhlIGRhdGEgZWxlbWVudD8pDQoNCi0tIA0KVGlja2V0 IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzExPg0K TmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0 cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 12:28:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFY6k-0006Vo-Kq for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:28:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFY6j-0001y2-EF for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:28:34 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFY1I-00095K-MK for netconf-data@psg.com; Mon, 30 Jul 2007 16:22:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFY17-00094G-Rg for netconf@ops.ietf.org; Mon, 30 Jul 2007 16:22:51 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFY16-0000xw-9E; Mon, 30 Jul 2007 18:22:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Mon, 30 Jul 2007 16:22:44 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #12: Update SSH-Transport for Notifications X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/12 Message-ID: <077.6346c7511ef750db53823e8dd78a9307@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: balazs.lengyel@ericsson.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 IzEyOiBVcGRhdGUgU1NILVRyYW5zcG9ydCBmb3IgTm90aWZpY2F0aW9ucw0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIFJlcG9ydGVyOiAgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tICB8ICAgICAg IE93bmVyOiAgICAgDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1pbm9yICAgICAgICAgICAgICAgICAgICAg ICAgfCAgIE1pbGVzdG9uZTogICAgIA0KQ29tcG9uZW50OiAgUkZDNDc0MiAgICAgICAgICAgICAg ICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAgDQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIEFkZCB0aGF0IG5vdCBvbmx5 IDxycGM+IGFuZCA8cnBjLXJlcGx5PiBlbGVtZW50cyBhcmUgc2VudCBvdmVyIFNTSCBidXQNCiBu b3RpZmljYXRpb25zIGFzIHdlbGwuDQoNCiBNZW50aW9uIHRoYXQgdGhlIF1dPl1dPiBjaGFyYWN0 ZXIgc2VxdWVuY2UgY2FuIGFwcGVhciBpbiBYTUwgY29tbWVudHMuDQoNCi0tIA0KVGlja2V0IFVS TDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzEyPg0KTmV0 Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0cmFj a2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 12:40:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYIl-0004fT-NC for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:40:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYIk-0002Ep-CJ for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 12:40:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFYAo-000AKN-QL for netconf-data@psg.com; Mon, 30 Jul 2007 16:32:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFYAc-000AIJ-2G for netconf@ops.ietf.org; Mon, 30 Jul 2007 16:32:41 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB0F421061; Mon, 30 Jul 2007 18:32:31 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-7d-46ae129f11fc Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 964E12022C; Mon, 30 Jul 2007 18:32:31 +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, 30 Jul 2007 18:32:31 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 18:32:31 +0200 Message-ID: <46AE129E.5000705@ericsson.com> Date: Mon, 30 Jul 2007 18:32:30 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "tom.petch" , netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <001801c7caee$68279440$0601a8c0@pc6> <46A0FB60.8000702@andybierman.com> In-Reply-To: <46A0FB60.8000702@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 16:32:31.0430 (UTC) FILETIME=[39DA9660:01C7D2C7] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Hello, I think a filter that works on the content of the notification (as it would be sent) is needed. People usually filter on things like severity or eventType. E.g. severity is not even part of the data model. I think the filter should work on the notification content. Balazs Andy Bierman wrote: > tom.petch wrote: >> ----- Original Message ----- >> From: "Balazs Lengyel" >> To: "tom.petch" >> Cc: ; >> Sent: Thursday, July 19, 2007 5:14 PM >> Subject: Re: roots wasRe: filtering problem >> >> >>> Hello, >>> I think the datastore will often have multiple roots. I foresee/have >>> heard of >> the following >>> situations that as I understand are all valid in Netconf: >>> 1) One root in one namespace, other namespaces might be mounted as >>> subtrees >>> 2) One root per namespace >>> 3) One namespace but with many root elements >>> 4) Many roots in many namespaces >>> >>> Case 2 can be viewed as a the single rooted case 1) where the first >>> branching >> is according to >>> the namespace. >>> >>> Case 3) and 4) I feel the filter should be applied to each root and the >> results of these >>> combined under the element in the get/get-config reply. >>> >>> Comments? >>> >> >> Mmmm - even more complex than I thought. My initial concern was >> whether or not >> the Notifications, the draft in Last Call, were regarded for filtering >> purposes >> as part of the configuration datastore at all, or whether the filter >> was applied >> to the document as it would appear on the wire were it to pass a filter. >> > > > This is the $64 question. > When a element is provided in the , > does it apply to the conceptual (internal) NETCONF database, > or rather an XML instance document representing the database? (no) > > The examples seem to contradict text that says it works like . > They show the filter is for the contents, > starting at its one and only child node -- e.g., . > > The draft needs to specify the data root for the notification . > >> Tom Petch >> >>> Balazs > > Andy > >>> >>> tom.petch wrote: >>>> This may relate to something that has been bugging me. >>>> >>>> XPath is - at times - specified in terms of a root, and an XML >>>> document has >> a >>>> single root element. What is on the wire is an XML document but the >> datastore >>>> is not - as Andy has pointed out before. >>>> >>>> So what is an XPath filter being applied to? The event as it would >>>> appear >> on >>>> the wire as an XML document? A conceptual document created in the >>>> datastore >> for >>>> the purposes of filtering? And if the latter, should we - we should! - >> specify >>>> a root, either for the purposes of the examples or else for everything. >>>> >>>> RFC4741 is quite discursive about roots but the notification I-D is >>>> silent; >> I >>>> think that this last needs to change. >>>> >>>> Tom Petch >>>> >>>> ----- Original Message ----- >>>> From: "Martin Bjorklund" >>>> To: >>>> Cc: >>>> Sent: Friday, July 13, 2007 4:43 PM >>>> Subject: Re: filtering problem >>>> >>>> >>>>> Andy Bierman wrote: >>>>>> Hi, >>>>>> >>>>>> There is another problem with filtering and the examples in sec 5: >>>>>> (!!!) >>>>>> >>>>>> The draft must say exactly where in the element >>>>>> that the is applied. The current text does not say >>>>>> anything. >>>>> Agreed. >>>>> >>>>>> All the examples in sec. 5 are broken because the 'notification type' >>>>>> layer is missing. >>>>> I think it is ok. Specify that the filter is applied to the >>>>> 'notificationContent' element as root (which is the abstract element). >>>>> >>>>>> The examples assume the filters can only be >>>>>> applied to a conceptual datastore, just like the filter. >>>>>> >>>>>> However, the most commonly needed filter is going to be >>>>>> on the notification type itself! >>>>>> >>>>>> Example (w/o namespaces): >>>>>> >>>>>> >>>>>> >>>>>> date-time string... >>>>>> fred@example.com >>>>>> >>>>>> /interfaces/interface[name='eth0'] >>>>>> ... >>>>>> >>>>>> >>>>>> >>>>>> For simplicity, assume the manager just wants >>>>>> this one notification type. The filter is going to be something like: >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Yes, and IMO this is consistent with the examples. >>>>> >>>>> >>>>> /martin >>>>> >>>>> >>>>> >>>>>> A filter for configChange just on a specific configTarget might be: >>>>>> >>>>>> >>>>>> >>>>>> /interfaces/interface[name='eth0'] >>>>>> >>>>>> >>>>>> >>>>>> The way the draft is now does not reflect how notifications are >>>>>> actually structured. >>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>>> the word 'unsubscribe' in a single line as the message text body. >>>>>> archive: >>>>>> >>>>> -- >>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>> the word 'unsubscribe' in a single line as the message text body. >>>>> archive: >>>> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> >> -- >> to 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 Mon Jul 30 15:07:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFaaF-0001J7-4a for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 15:07:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFaaD-0006Uk-Sv for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 15:07:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFaTa-0002uX-KV for netconf-data@psg.com; Mon, 30 Jul 2007 19:00:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.229.91] (helo=smtp114.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFaTP-0002tc-E2 for netconf@ops.ietf.org; Mon, 30 Jul 2007 19:00:13 +0000 Received: (qmail 84419 invoked from network); 30 Jul 2007 19:00:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp114.sbc.mail.re2.yahoo.com with SMTP; 30 Jul 2007 19:00:06 -0000 X-YMail-OSG: LXvRZo0VM1k4mVbx.95DpltCW5xT7OSRoGolA4j.BhceQwQcnFJgaygF9G8ulsN70q8FKKABO3K9iGr28UttINNPUxgbR4Y2G.kMfu4uIfLUw.7b3j9KNg-- Message-ID: <46AE34DF.9060406@andybierman.com> Date: Mon, 30 Jul 2007 11:58:39 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 CC: netconf@ops.ietf.org Subject: Re: [Netconf] #1: message-id attribute not used References: <070.9ed95934849d897ed0367b0bccb57aa6@tools.ietf.org> <079.c98cbd8132a0b9ea6c8ce37ef1c67164@tools.ietf.org> In-Reply-To: <079.c98cbd8132a0b9ea6c8ce37ef1c67164@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Netconf wrote: > #1: message-id attribute not used > -----------------------------------+---------------------------------------- > Reporter: ietf@andybierman.com | Owner: > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: RFC4741 | Version: 1.0 > Resolution: | Keywords: message-id > -----------------------------------+---------------------------------------- > Comment (by balazs.lengyel@ericsson.com): > > We do want to use it. We want to send notifications about long running > operations like backup. We will identify the original operation using the > message-id. > It could also be useful for logging, to pair the request and the answer. > [[BR]] > Please do not remove it. You misunderstand. I did not make the ticket clear enough. The 'message-id' attribute is not being removed. The requirement to generate an error and reject the request if it is missing is being removed. The agent is already required to return every attribute in unchanged in the anyway. The message-id rule is redundant. (Phil already explained it all to us, remember?) > [[BR]] > Balazs Lengyel > 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 Jul 30 17:52:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdAE-0001ZC-Cr for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 17:52:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdAD-00032H-5l for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 17:52:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFd49-000Isa-LS for netconf-data@psg.com; Mon, 30 Jul 2007 21:46:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [206.18.177.55] (helo=alnrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFd3y-000Is9-O8 for netconf@ops.ietf.org; Mon, 30 Jul 2007 21:46:08 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070730214601b1500j2vu1e>; Mon, 30 Jul 2007 21:46:02 +0000 From: "David B Harrington" To: Cc: References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> Subject: RE: [Netconf] #9: notification replay in the future Date: Mon, 30 Jul 2007 17:45:33 -0400 Message-ID: <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfQ8JL7XGeU3HlnRbqXQ3t+WVBNtwCAks8Q Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi, MAY NOT or MUST NOT? David Harrington dbharrington@comcast.net ietfdbh@comcast.net =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Netconf > Sent: Saturday, July 28, 2007 4:19 AM > Cc: netconf@ops.ietf.org > Subject: [Netconf] #9: notification replay in the future >=20 > #9: notification replay in the future > ---------------------------------------------+---------------- > -------------- > Reporter: ietf@andybierman.com | Owner: =20 > Type: defect | Status: new > Priority: major | Milestone: =20 > Component: draft-ietf-netconf-notification | Version: =20 > Keywords: notification replay | =20 > ---------------------------------------------+---------------- > -------------- > The startTime and/or stopTime parameters to the create-subscription > operation can be in the future. This is unintended behavior that > is not part of the original use cases for this feature. >=20 > Requiring the agent to replay notifications that have not > happened yet is non-intuitive, and there is some ambiguity > with the meaning of the notification, > and when it should be sent. >=20 > The text should be clear that the agent MAY NOT support > startTime and/or stopTime values in the future. >=20 > --=20 > Ticket URL: > Netconf > Issue tracker for the NETCONF Working Grouprzuzz?????rz))=17z?w&r=18z=1B??w >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 17:58:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdFv-0004TT-73 for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 17:58:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdFu-0003OI-Ob for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 17:58:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdBX-000L5y-8v for netconf-data@psg.com; Mon, 30 Jul 2007 21:53:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,UNPARSEABLE_RELAY autolearn=ham version=3.1.8 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdBL-000L3n-1F for netconf@ops.ietf.org; Mon, 30 Jul 2007 21:53:45 +0000 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.6017444; Mon, 30 Jul 2007 17:53:20 -0400 Received: from mail pickup service by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC; Mon, 30 Jul 2007 17:53:13 -0400 Received: from PACDCEXCSMTP03.cable.comcast.com ([24.40.15.92]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 12:28:53 -0400 Received: from cable.comcast.com ([24.40.8.142]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 12:26:45 -0400 Received: from ([24.40.8.143]) by PACDCIMI01.cable.comcast.com with ESMTP id KP-NTD71.27046844; Mon, 30 Jul 2007 12:26:25 -0400 Received: from ([147.28.0.62]) by pacdcedge01.cable.comcast.com with ESMTP with TLS id 5302275.EDGE; Mon, 30 Jul 2007 12:26:24 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXuv-0008Rh-GR for netconf-data@psg.com; Mon, 30 Jul 2007 16:16:21 +0000 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFXuk-0008Qe-L4 for netconf@ops.ietf.org; Mon, 30 Jul 2007 16:16:16 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFXuj-0008JV-1h; Mon, 30 Jul 2007 18:16:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Mon, 30 Jul 2007 16:16:08 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #11: NETCONF base clarifications X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/11 Message-ID: <077.32d6c3d8f73c4e9770958f8980a14aa0@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: balazs.lengyel@ericsson.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-ESP: ESP<-4>=RBL:<-7> SHA:<0> UHA:<0> BAYES:<0> SenderID:<0> Spam Dictionary (TRU10):<0> embed_spam:<0> scam_spam:<0> Obscenities Dictionary (TRU10):<0> Scam Dictionary (TRU10):<0> lotto_spam:<0> Adult Dictionary (TRU10):<0> Embed HTML Dictionary (TRU10):<0> stock_spam:<0> watch_spam:<0> Float Dictionary (TRU10):<0> html_image_spam:<0> money_spam:<0> HTML Dictionary (TRU10):<3> URL Real-Time Signatures:<0> Spam Dictionary 2 (TRU10):<0> SIG: X-OriginalArrivalTime: 30 Jul 2007 16:26:45.0191 (UTC) FILETIME=[6B7AB570:01C7D2C6] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 IzExOiBORVRDT05GIGJhc2UgY2xhcmlmaWNhdGlvbnMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBS ZXBvcnRlcjogIGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSAgfCAgICAgICBPd25lcjogICAg IA0KICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVz OiAgbmV3DQogUHJpb3JpdHk6ICBtaW5vciAgICAgICAgICAgICAgICAgICAgICAgIHwgICBNaWxl c3RvbmU6ICAgICANCkNvbXBvbmVudDogIFJGQzQ3NDEgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBBIG51bWJlciBvZiBpc3N1ZXMgc2hvdWxkIGJl IGNsYXJpZmllZCBpbiBSRkM0NzQxOltbQlJdXQ0KIDEpIEhvdyB0byBoYW5kbGUgPGVkaXQtY29u ZmlnPiBpZiBtdWx0aXBsZSBvcGVyYXRpb24gcGFyYW1ldGVycyBhcmUNCiBwcmVzZW50P1tbQlJd XQ0KIDIpIEhvdyBtYW55IHJvb3RzIGNhbiBhIGRhdGFzdG9yZSBoYXZlPyAob25lLCBvbmUgcGVy IG5hbWVzcGFjZSwNCiBtYW55KVtbQlJdXQ0KIDMpIEhvdyB0byBhcHBseSBmaWx0ZXJzIG9uIG11 bHRpLXJvb3RlZCBkYXRhc3RvcmVzPyAoQXBwbHkgdGhlIGZpbHRlciBvbg0KIGVhY2ggcm9vdCBh bmQgcHV0IGFsbCByZXN1bHRzIGludG8gdGhlIGRhdGEgZWxlbWVudD8pDQoNCi0tIA0KVGlja2V0 IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzExPg0K TmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0 cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 18:01:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdJB-0006FQ-Ep for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:01:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdJA-0003TO-JV for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:01:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdEZ-000Lpp-2y for netconf-data@psg.com; Mon, 30 Jul 2007 21:56:59 +0000 Received: from [206.18.177.53] (helo=alnrmhc13.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdET-000LpH-Fi for netconf@ops.ietf.org; Mon, 30 Jul 2007 21:56:58 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070730215652b13006jejqe>; Mon, 30 Jul 2007 21:56:52 +0000 From: "David B Harrington" To: "'Andy Bierman'" Cc: "'Netconf \(E-mail\)'" References: <46AAF304.2030701@andybierman.com> <46AB8A66.90800@andybierman.com> Subject: RE: NETCONF Issue Tracker Date: Mon, 30 Jul 2007 17:56:45 -0400 Message-ID: <00cb01c7d2f4$87ea9760$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: <46AB8A66.90800@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfRRgxxO47XCuMoQqSPZ2ryZ1HlfgBrTI9Q X-Spam-Score: -1.9 (-) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hi, I notice the version# has not been entered on the notifications draft. It would be good to have the version# present in the tracker. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Saturday, July 28, 2007 2:27 PM > To: Andy Bierman > Cc: Netconf (E-mail) > Subject: Re: NETCONF Issue Tracker > > Andy Bierman wrote: > > Hi, > > > > The WG now has an issue tracker (better late than never), > > thanks to David Partain. > > > > http://tools.ietf.org/wg/netconf/trac/report/1 > > > > I noticed the tracker assigned ticket numbers from 1 to N > across all components. It would be better if the numbering > was per component. The WG does not need to resolve the > RFC4741 tickets to complete the Notifications deliverable. > A flat numbering scheme like the arbitrary and scattered RFC numbers > is not very user-friendly either. These are not software > components within an application, they are independent drafts. > > > Is there another numbering scheme available in trac? > > > Andy > > > > > David has agreed to help administer the list, > > so please ask him how it works ;-) We are still working > > out the kinks, but there are 5 components in the NETCONF project: > > > > - RFC4741 > > - RFC4742 > > - RFC4743 > > - RFC4744 > > - draft-ietf-netconf-notification > > > > I have already filed 3 tickets for feature enhancements to RFC4741. > > Each of the reviewers who raised issed with notification-08 should > > click on the 'Get Passwd' button, and then login and enter a ticket > > for each issue (with component == draft-ietf-netconf-notification). > > > > thanks, > > Andy > > > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 18:08:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdPT-0002CX-JB for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:08:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdPT-0003bl-5e for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:08:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdKg-000MPf-AK for netconf-data@psg.com; Mon, 30 Jul 2007 22:03:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.96] (helo=smtp109.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdKS-000MOw-Pl for netconf@ops.ietf.org; Mon, 30 Jul 2007 22:03:12 +0000 Received: (qmail 50600 invoked from network); 30 Jul 2007 22:02:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp109.sbc.mail.re2.yahoo.com with SMTP; 30 Jul 2007 22:02:59 -0000 X-YMail-OSG: gdRk08EVM1nnnxX2.Ud6XZXJDyh2dUurtFHL97wN6pjTKbUfi789.dFpWqezspwNUoXqjlmhIQJ9jDp0u4z5QZ8RnOeN_d4HJodCALPv5vTjyvXFFGSEBw-- Message-ID: <46AE5FBC.3060704@andybierman.com> Date: Mon, 30 Jul 2007 15:01:32 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> In-Reply-To: <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.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.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da David B Harrington wrote: > Hi, > > MAY NOT or MUST NOT? MAY NOT (IMO). That's why it's an open issue ;-) Andy > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Netconf >> Sent: Saturday, July 28, 2007 4:19 AM >> Cc: netconf@ops.ietf.org >> Subject: [Netconf] #9: notification replay in the future >> >> #9: notification replay in the future >> ---------------------------------------------+---------------- >> -------------- >> Reporter: ietf@andybierman.com | Owner: >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-ietf-netconf-notification | Version: >> Keywords: notification replay | >> ---------------------------------------------+---------------- >> -------------- >> The startTime and/or stopTime parameters to the create-subscription >> operation can be in the future. This is unintended behavior that >> is not part of the original use cases for this feature. >> >> Requiring the agent to replay notifications that have not >> happened yet is non-intuitive, and there is some ambiguity >> with the meaning of the notification, >> and when it should be sent. >> >> The text should be clear that the agent MAY NOT support >> startTime and/or stopTime values in the future. >> >> -- >> Ticket URL: >> Netconf >> Issue tracker for the NETCONF Working > Grouprzuzz?????rz))z?w&rz??w > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 18:09:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdQR-0002Hs-Ug for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:09:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdQR-0003cy-1H for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:09:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdLr-000MWE-Og for netconf-data@psg.com; Mon, 30 Jul 2007 22:04:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=unavailable version=3.1.8 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdLf-000MV8-C2 for netconf@ops.ietf.org; Mon, 30 Jul 2007 22:04:26 +0000 Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.45131258; Mon, 30 Jul 2007 18:03:58 -0400 Received: from mail pickup service by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC; Mon, 30 Jul 2007 18:03:57 -0400 Received: from PACDCEXCSMTP03.cable.comcast.com ([24.40.15.92]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 12:43:45 -0400 Received: from cable.comcast.com ([24.40.8.137]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 12:43:40 -0400 Received: from ([24.40.8.144]) by pacdcimi03.cable.comcast.com with ESMTP id KP-NTF27.29761273; Mon, 30 Jul 2007 12:43:18 -0400 Received: from ([147.28.0.62]) by pacdcedge02.cable.comcast.com with ESMTP with TLS id 5302274.EDGE; Mon, 30 Jul 2007 12:43:18 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFYAo-000AKN-QL for netconf-data@psg.com; Mon, 30 Jul 2007 16:32:46 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFYAc-000AIJ-2G for netconf@ops.ietf.org; Mon, 30 Jul 2007 16:32:41 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB0F421061; Mon, 30 Jul 2007 18:32:31 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-7d-46ae129f11fc Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 964E12022C; Mon, 30 Jul 2007 18:32:31 +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, 30 Jul 2007 18:32:31 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 18:32:31 +0200 Message-ID: <46AE129E.5000705@ericsson.com> Date: Mon, 30 Jul 2007 18:32:30 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "tom.petch" , netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <001801c7caee$68279440$0601a8c0@pc6> <46A0FB60.8000702@andybierman.com> In-Reply-To: <46A0FB60.8000702@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 16:32:31.0430 (UTC) FILETIME=[39DA9660:01C7D2C7] X-Brightmail-Tracker: AAAAAA== X-ESP: ESP<-7>=RBL:<-7> SHA:<0> UHA:<0> BAYES:<0> SenderID:<0> Spam Dictionary (TRU10):<0> embed_spam:<0> scam_spam:<0> Obscenities Dictionary (TRU10):<0> Scam Dictionary (TRU10):<0> lotto_spam:<0> Adult Dictionary (TRU10):<0> Embed HTML Dictionary (TRU10):<0> stock_spam:<0> watch_spam:<0> Float Dictionary (TRU10):<0> html_image_spam:<0> money_spam:<0> HTML Dictionary (TRU10):<0> URL Real-Time Signatures:<0> Spam Dictionary 2 (TRU10):<0> SIG: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Hello, I think a filter that works on the content of the notification (as it would be sent) is needed. People usually filter on things like severity or eventType. E.g. severity is not even part of the data model. I think the filter should work on the notification content. Balazs Andy Bierman wrote: > tom.petch wrote: >> ----- Original Message ----- >> From: "Balazs Lengyel" >> To: "tom.petch" >> Cc: ; >> Sent: Thursday, July 19, 2007 5:14 PM >> Subject: Re: roots wasRe: filtering problem >> >> >>> Hello, >>> I think the datastore will often have multiple roots. I foresee/have >>> heard of >> the following >>> situations that as I understand are all valid in Netconf: >>> 1) One root in one namespace, other namespaces might be mounted as >>> subtrees >>> 2) One root per namespace >>> 3) One namespace but with many root elements >>> 4) Many roots in many namespaces >>> >>> Case 2 can be viewed as a the single rooted case 1) where the first >>> branching >> is according to >>> the namespace. >>> >>> Case 3) and 4) I feel the filter should be applied to each root and the >> results of these >>> combined under the element in the get/get-config reply. >>> >>> Comments? >>> >> >> Mmmm - even more complex than I thought. My initial concern was >> whether or not >> the Notifications, the draft in Last Call, were regarded for filtering >> purposes >> as part of the configuration datastore at all, or whether the filter >> was applied >> to the document as it would appear on the wire were it to pass a filter. >> > > > This is the $64 question. > When a element is provided in the , > does it apply to the conceptual (internal) NETCONF database, > or rather an XML instance document representing the database? (no) > > The examples seem to contradict text that says it works like . > They show the filter is for the contents, > starting at its one and only child node -- e.g., . > > The draft needs to specify the data root for the notification . > >> Tom Petch >> >>> Balazs > > Andy > >>> >>> tom.petch wrote: >>>> This may relate to something that has been bugging me. >>>> >>>> XPath is - at times - specified in terms of a root, and an XML >>>> document has >> a >>>> single root element. What is on the wire is an XML document but the >> datastore >>>> is not - as Andy has pointed out before. >>>> >>>> So what is an XPath filter being applied to? The event as it would >>>> appear >> on >>>> the wire as an XML document? A conceptual document created in the >>>> datastore >> for >>>> the purposes of filtering? And if the latter, should we - we should! - >> specify >>>> a root, either for the purposes of the examples or else for everything. >>>> >>>> RFC4741 is quite discursive about roots but the notification I-D is >>>> silent; >> I >>>> think that this last needs to change. >>>> >>>> Tom Petch >>>> >>>> ----- Original Message ----- >>>> From: "Martin Bjorklund" >>>> To: >>>> Cc: >>>> Sent: Friday, July 13, 2007 4:43 PM >>>> Subject: Re: filtering problem >>>> >>>> >>>>> Andy Bierman wrote: >>>>>> Hi, >>>>>> >>>>>> There is another problem with filtering and the examples in sec 5: >>>>>> (!!!) >>>>>> >>>>>> The draft must say exactly where in the element >>>>>> that the is applied. The current text does not say >>>>>> anything. >>>>> Agreed. >>>>> >>>>>> All the examples in sec. 5 are broken because the 'notification type' >>>>>> layer is missing. >>>>> I think it is ok. Specify that the filter is applied to the >>>>> 'notificationContent' element as root (which is the abstract element). >>>>> >>>>>> The examples assume the filters can only be >>>>>> applied to a conceptual datastore, just like the filter. >>>>>> >>>>>> However, the most commonly needed filter is going to be >>>>>> on the notification type itself! >>>>>> >>>>>> Example (w/o namespaces): >>>>>> >>>>>> >>>>>> >>>>>> date-time string... >>>>>> fred@example.com >>>>>> >>>>>> /interfaces/interface[name='eth0'] >>>>>> ... >>>>>> >>>>>> >>>>>> >>>>>> For simplicity, assume the manager just wants >>>>>> this one notification type. The filter is going to be something like: >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Yes, and IMO this is consistent with the examples. >>>>> >>>>> >>>>> /martin >>>>> >>>>> >>>>> >>>>>> A filter for configChange just on a specific configTarget might be: >>>>>> >>>>>> >>>>>> >>>>>> /interfaces/interface[name='eth0'] >>>>>> >>>>>> >>>>>> >>>>>> The way the draft is now does not reflect how notifications are >>>>>> actually structured. >>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>>> the word 'unsubscribe' in a single line as the message text body. >>>>>> archive: >>>>>> >>>>> -- >>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>>> the word 'unsubscribe' in a single line as the message text body. >>>>> archive: >>>> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> >> -- >> to 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: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jul 30 18:25:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdg8-00025L-9q for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:25:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdg6-0003xN-So for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 18:25:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdbL-000O6M-3H for netconf-data@psg.com; Mon, 30 Jul 2007 22:20:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [206.18.177.55] (helo=alnrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFdbA-000O4N-4X for netconf@ops.ietf.org; Mon, 30 Jul 2007 22:20:25 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070730222019b1500j39n1e>; Mon, 30 Jul 2007 22:20:19 +0000 From: "David B Harrington" To: "'Andy Bierman'" Cc: , References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> Subject: RE: [Netconf] #9: notification replay in the future Date: Mon, 30 Jul 2007 18:20:15 -0400 Message-ID: <00d301c7d2f7$ce331dc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46AE5FBC.3060704@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfS9WzyCUdLrZeySEeK3QRzaJZILgAAUGTg Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi, If the reason this is being discussed is=20 > >> Requiring the agent to replay notifications that have not > >> happened yet is non-intuitive, and there is some ambiguity > >> with the meaning of the notification, > >> and when it should be sent. Then won't the same problem exist if some implementation supports this? Won't it be potentially more ambiguous if different implementations do it differently?=20 I think the WG should clarify how it is done, or make it an error to specify a StartTime in the future.=20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Monday, July 30, 2007 6:02 PM > To: David B Harrington > Cc: trac@tools.ietf.org; netconf@ops.ietf.org > Subject: Re: [Netconf] #9: notification replay in the future >=20 > David B Harrington wrote: > > Hi, > >=20 > > MAY NOT or MUST NOT? >=20 > MAY NOT (IMO). > That's why it's an open issue ;-) >=20 > Andy >=20 > >=20 > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > =20 > >=20 > >> -----Original Message----- > >> From: owner-netconf@ops.ietf.org=20 > >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Netconf > >> Sent: Saturday, July 28, 2007 4:19 AM > >> Cc: netconf@ops.ietf.org > >> Subject: [Netconf] #9: notification replay in the future > >> > >> #9: notification replay in the future > >> ---------------------------------------------+---------------- > >> -------------- > >> Reporter: ietf@andybierman.com | Owner: =20 > >> Type: defect | Status: new > >> Priority: major | Milestone: =20 > >> Component: draft-ietf-netconf-notification | Version: =20 > >> Keywords: notification replay | =20 > >> ---------------------------------------------+---------------- > >> -------------- > >> The startTime and/or stopTime parameters to the=20 > create-subscription > >> operation can be in the future. This is unintended behavior that > >> is not part of the original use cases for this feature. > >> > >> Requiring the agent to replay notifications that have not > >> happened yet is non-intuitive, and there is some ambiguity > >> with the meaning of the notification, > >> and when it should be sent. > >> > >> The text should be clear that the agent MAY NOT support > >> startTime and/or stopTime values in the future. > >> > >> --=20 > >> Ticket URL: > >> Netconf > >> Issue tracker for the NETCONF Working > > Grouprzuzz?????rz))=17z?w&r=18z=1B??w > >=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 >=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 Mon Jul 30 19:19:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFeWd-00066H-F9 for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 19:19:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFeWc-0005bv-Tw for netconf-archive@lists.ietf.org; Mon, 30 Jul 2007 19:19:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFeOZ-0002e1-Bu for netconf-data@psg.com; Mon, 30 Jul 2007 23:11:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.101] (helo=smtp104.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFeOO-0002dQ-62 for netconf@ops.ietf.org; Mon, 30 Jul 2007 23:11:18 +0000 Received: (qmail 37254 invoked from network); 30 Jul 2007 23:11:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp104.sbc.mail.re2.yahoo.com with SMTP; 30 Jul 2007 23:11:11 -0000 X-YMail-OSG: Nlsv8CYVM1kO7rfU_yo91afYoSDVBMyHMQzB6kHKH.oWWvlzv4joP2jMEqjmrEZeh9rpe9A6XSWf7r.RtlTwM4Z8aJSix8gYGfPJ1HUiI6oXSSLiDjkKSQ-- Message-ID: <46AE6FB8.5060800@andybierman.com> Date: Mon, 30 Jul 2007 16:09:44 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> <00d301c7d2f7$ce331dc0$0600a8c0@china.huawei.com> In-Reply-To: <00d301c7d2f7$ce331dc0$0600a8c0@china.huawei.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.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 David B Harrington wrote: > Hi, > > If the reason this is being discussed is >>>> Requiring the agent to replay notifications that have not >>>> happened yet is non-intuitive, and there is some ambiguity >>>> with the meaning of the notification, >>>> and when it should be sent. > > Then won't the same problem exist if some implementation supports > this? > Won't it be potentially more ambiguous if different implementations do > it differently? > > I think the WG should clarify how it is done, or make it an error to > specify a StartTime in the future. > What? You don't want to let me punt on third down? ;-) Of those very legitimate choices, I think it must be an error if startTime is in the future, according to the agent's notion of time. > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 02:34:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlJL-0003Nz-Gc for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 02:34:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFlJK-00023v-VH for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 02:34:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFlCx-000LFM-Bv for netconf-data@psg.com; Tue, 31 Jul 2007 06:27:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,UNPARSEABLE_RELAY autolearn=ham version=3.1.8 Received: from [133.145.228.5] (helo=mail4.hitachi.co.jp) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFlCl-000LE5-Iz for netconf@ops.ietf.org; Tue, 31 Jul 2007 06:27:45 +0000 Received: from mlsv12.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id B584533CCF for ; Tue, 31 Jul 2007 15:27:37 +0900 (JST) Received: from mfilter-s1.hitachi.co.jp by mlsv12.hitachi.co.jp (8.13.1/8.13.1) id l6V6RbME027936; Tue, 31 Jul 2007 15:27:37 +0900 Received: from vshuts3.hitachi.co.jp (unverified) by mfilter-s1.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id for ; Tue, 31 Jul 2007 15:27:37 +0900 Received: from gmml28.itg.hitachi.co.jp ([158.213.165.131]) by vshuts3.hitachi.co.jp with SMTP id M2007073115273624153 for ; Tue, 31 Jul 2007 15:27:36 +0900 Received: from localhost by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id l6V6RaU5017720; Tue, 31 Jul 2007 15:27:36 +0900 Date: Tue, 31 Jul 2007 15:27:36 +0900 (JST) Message-Id: <20070731.152736.127866256.hideki.okita.pf@hitachi.com> To: netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future From: OKITA Hideki In-Reply-To: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> Organization: Central Research Lab., Hitachi Ltd., Japan X-Mailer: Mew version 5.2 on Emacs 22.0.90 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 SGksDQoNCg0KRm9yIHRoZSBjbGFyaWZpY2F0aW9uIG9mIHRoZSByZXBsYXkgZmVhdHVyZSwNCkkg c2VuZCBteSB1bmRlcnN0YW5kaW5nIG9mIGV4cGVjdGVkIGJlaGF2aW9yIGZvcg0KZWFjaCBhdmFp bGFibGUgc2V0IG9mIHN0YXJ0VGltZS9zdG9wVGltZS4NCg0KICAgI3wgc3RhcnRUaW1lIHwgc3Rv cFRpbWUgfCBleHBlY3RlZCBiZWhhdmlvciBvZiBkZXZpY2VzDQogICAtKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAxfCBmdXR1cmUg ICAgfCBmdXR1cmUgICB8IFJlc2VydmUgcmVwbGF5Lg0KICAgMnwgZnV0dXJlICAgIHwgbm9uZSAg ICAgfCBSZXNlcnZlIGNvbnRpbnVvdXMgcmVwbGF5Lg0KICAgM3wgcGFzdCAgICAgIHwgZnV0dXJl ICAgfCBTdGFydCBhdCBvbmNlLCBzdG9wIGF0IGZ1dHVyZS4NCiAgIDR8IHBhc3QgICAgICB8IG5v bmUgICAgIHwgU3RhcnQgY29udGludW91cyByZXBsYXkgYXQgb25jZS4NCiAgIDV8IHBhc3QgICAg ICB8IHBhc3QgICAgIHwgU3RhcnQgcmVwbGF5Lg0KICAgNnwgbm9uZSAgICAgIHwgKiAgICAgICAg fCBOb3QgdmFsaWQuIElnbm9yZWQuDQoNCklmIHdlIHJlbW92ZSAicmVzZXJ2YXRpb24iIGZyb20g dGhlIHJlcGxheSBmZWF0dXJlLA0KYSBzdGFydFRpbWU6ZnV0dXJlIHN1YnNjcmlwdGlvbiBzaG91 bGQgYmUgZXJyb3IuDQoNCg0KUmVnYXJkcywNCg0KSGlkZWtpIE9raXRhDQoNCg0KRnJvbTogIk5l dGNvbmYiIDx0cmFjQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogW05ldGNvbmZdICM5OiBub3Rp ZmljYXRpb24gcmVwbGF5IGluIHRoZSBmdXR1cmUNCkRhdGU6IFNhdCwgMjggSnVsIDIwMDcgMDg6 MTg6NDUgLTAwMDANCg0KPiDvu78jOTogbm90aWZpY2F0aW9uIHJlcGxheSBpbiB0aGUgZnV0dXJl DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIFJlcG9ydGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5j b20gICAgICAgICAgICAgfCAgICAgICBPd25lcjogICAgIA0KPiAgICAgIFR5cGU6ICBkZWZlY3Qg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQo+ICBQcmlvcml0 eTogIG1ham9yICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICAN Cj4gQ29tcG9uZW50OiAgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbiAgfCAgICAgVmVy c2lvbjogICAgIA0KPiAgS2V5d29yZHM6ICBub3RpZmljYXRpb24gcmVwbGF5ICAgICAgICAgICAg ICB8ICANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgVGhlIHN0YXJ0VGltZSBhbmQvb3Igc3Rv cFRpbWUgcGFyYW1ldGVycyB0byB0aGUgY3JlYXRlLXN1YnNjcmlwdGlvbg0KPiAgb3BlcmF0aW9u IGNhbiBiZSBpbiB0aGUgZnV0dXJlLiAgVGhpcyBpcyB1bmludGVuZGVkIGJlaGF2aW9yIHRoYXQN Cj4gIGlzIG5vdCBwYXJ0IG9mIHRoZSBvcmlnaW5hbCB1c2UgY2FzZXMgZm9yIHRoaXMgZmVhdHVy ZS4NCj4gDQo+ICBSZXF1aXJpbmcgdGhlIGFnZW50IHRvIHJlcGxheSBub3RpZmljYXRpb25zIHRo YXQgaGF2ZSBub3QNCj4gIGhhcHBlbmVkIHlldCBpcyBub24taW50dWl0aXZlLCBhbmQgdGhlcmUg aXMgc29tZSBhbWJpZ3VpdHkNCj4gIHdpdGggdGhlIG1lYW5pbmcgb2YgdGhlIDxyZXBsYXlDb21w bGV0ZT4gbm90aWZpY2F0aW9uLA0KPiAgYW5kIHdoZW4gaXQgc2hvdWxkIGJlIHNlbnQuDQo+IA0K PiAgVGhlIHRleHQgc2hvdWxkIGJlIGNsZWFyIHRoYXQgdGhlIGFnZW50IE1BWSBOT1Qgc3VwcG9y dA0KPiAgc3RhcnRUaW1lIGFuZC9vciBzdG9wVGltZSB2YWx1ZXMgaW4gdGhlIGZ1dHVyZS4NCg0K DQpUaWNrZXQgVVJMOiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy90aWNr ZXQvOT4NCk5ldGNvbmYgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvPg0K SXNzdWUgdHJhY2tlciBmb3IgdGhlIE5FVENPTkYgV29ya2luZyBHcm91cA0K -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 03:47:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFmS5-0007sH-4S for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 03:47:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFmS3-0003wN-Vp for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 03:47:32 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFmM8-0001U1-8E for netconf-data@psg.com; Tue, 31 Jul 2007 07:41:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFmLv-0001Sw-Rt for netconf@ops.ietf.org; Tue, 31 Jul 2007 07:41:18 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7ADD62104F for ; Tue, 31 Jul 2007 09:41:09 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-8e-46aee795eba8 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 51955204EC for ; Tue, 31 Jul 2007 09:41:09 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:41:09 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:41:09 +0200 Message-ID: <46AEE794.6020400@ericsson.com> Date: Tue, 31 Jul 2007 09:41:08 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <20070731.152736.127866256.hideki.okita.pf@hitachi.com> In-Reply-To: <20070731.152736.127866256.hideki.okita.pf@hitachi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 31 Jul 2007 07:41:09.0076 (UTC) FILETIME=[28E73140:01C7D346] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Hello, I thought we are designing a replay function not a scheduled notification delivery function. I do not see the usecase for scheduling notification sending and putting the burden of the scheduling on the agent. I would rather go for a simple solution. startTime in future -> error stopTime in future -> error stopTime =< StartTime -> error stopTime present and startTime absent -> error The startTime must be in the past or must be absent. The stopTime must be in the past, or just Now, or absent. Balazs OKITA Hideki wrote: > Hi, > > > For the clarification of the replay feature, > I send my understanding of expected behavior for > each available set of startTime/stopTime. > > #| startTime | stopTime | expected behavior of devices > -+-----------+----------+--------------------------------- > 1| future | future | Reserve replay. > 2| future | none | Reserve continuous replay. > 3| past | future | Start at once, stop at future. > 4| past | none | Start continuous replay at once. > 5| past | past | Start replay. > 6| none | * | Not valid. Ignored. > > If we remove "reservation" from the replay feature, > a startTime:future subscription should be error. > > > Regards, > > Hideki Okita > > > From: "Netconf" > Subject: [Netconf] #9: notification replay in the future > Date: Sat, 28 Jul 2007 08:18:45 -0000 > >> #9: notification replay in the future >> ---------------------------------------------+------------------------------ >> Reporter: ietf@andybierman.com | Owner: >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-ietf-netconf-notification | Version: >> Keywords: notification replay | >> ---------------------------------------------+------------------------------ >> The startTime and/or stopTime parameters to the create-subscription >> operation can be in the future. This is unintended behavior that >> is not part of the original use cases for this feature. >> >> Requiring the agent to replay notifications that have not >> happened yet is non-intuitive, and there is some ambiguity >> with the meaning of the notification, >> and when it should be sent. >> >> The text should be clear that the agent MAY NOT support >> startTime and/or stopTime values in the future. > > > Ticket URL: > Netconf > Issue tracker for the NETCONF Working Group > ������r��zǧu���Ơz�'z�(��ު笶�l��_��0��m��(�ۧ���r��z)ڲ)��b�欶�z���^���w&�r�zm���Ȟ��+��b��?��\�w� -- 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 Tue Jul 31 03:49:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFmU8-0000W0-5N for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 03:49:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFmU7-0003zI-JH for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 03:49:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFmQ3-0001rE-Gp for netconf-data@psg.com; Tue, 31 Jul 2007 07:45:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFmPr-0001oy-Nq for netconf@ops.ietf.org; Tue, 31 Jul 2007 07:45:21 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B483420533; Tue, 31 Jul 2007 09:45:13 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-75-46aee889cb84 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 962AF204AD; Tue, 31 Jul 2007 09:45:13 +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, 31 Jul 2007 09:45:13 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:45:12 +0200 Message-ID: <46AEE888.5000405@ericsson.com> Date: Tue, 31 Jul 2007 09:45:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: David B Harrington , trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> In-Reply-To: <46AE5FBC.3060704@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 07:45:13.0157 (UTC) FILETIME=[BA62FF50:01C7D346] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Hello, I vote for MUST NOT. Why complicate things. Will it bring us anything? I submitted the same comment as Dave in trac, but it seems that there is no email about updates to trac issues. Balazs Andy Bierman wrote: > David B Harrington wrote: >> Hi, >> >> MAY NOT or MUST NOT? > > MAY NOT (IMO). > That's why it's an open issue ;-) > > Andy > >> >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net >> >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>> On Behalf Of Netconf >>> Sent: Saturday, July 28, 2007 4:19 AM >>> Cc: netconf@ops.ietf.org >>> Subject: [Netconf] #9: notification replay in the future >>> >>> #9: notification replay in the future >>> ---------------------------------------------+---------------- >>> -------------- >>> Reporter: ietf@andybierman.com | Owner: >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: draft-ietf-netconf-notification | Version: >>> Keywords: notification replay | >>> ---------------------------------------------+---------------- >>> -------------- >>> The startTime and/or stopTime parameters to the create-subscription >>> operation can be in the future. This is unintended behavior that >>> is not part of the original use cases for this feature. >>> >>> Requiring the agent to replay notifications that have not >>> happened yet is non-intuitive, and there is some ambiguity >>> with the meaning of the notification, >>> and when it should be sent. >>> >>> The text should be clear that the agent MAY NOT support >>> startTime and/or stopTime values in the future. >>> >>> -- >>> Ticket URL: >>> Netconf >>> Issue tracker for the NETCONF Working >> Grouprzuzz?????rz))z?w&rz??w >> >> >> >> -- >> to 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: -- 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 Tue Jul 31 05:31:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFo4T-0005xU-MI for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:31:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFo4S-0006y9-VE for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:31:17 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFnyb-000ARA-4c for netconf-data@psg.com; Tue, 31 Jul 2007 09:25:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [204.127.225.96] (helo=alnrmhc16.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFnyP-000AOc-Q5 for netconf@ops.ietf.org; Tue, 31 Jul 2007 09:25:07 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070731091959b1600pigfse>; Tue, 31 Jul 2007 09:20:00 +0000 From: "David B Harrington" To: "'Balazs Lengyel'" , "'Andy Bierman'" Cc: , References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> <46AEE888.5000405@ericsson.com> Subject: Netconf Issue Tracker - features Date: Tue, 31 Jul 2007 05:19:34 -0400 Message-ID: <011c01c7d353$f5f83820$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46AEE888.5000405@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfTR1lwo7Mce9tTTEe7HyBvKst1mQACs6cA Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Hi, Just so people on this list understand about trac... I had assumed that my email comments would be recorded in trac, since trac was included in the To: list of my email; apparently that does not happen. If I understand Balacz's comment, entering comments directly into the trac page records the comment in trac, but does not send an email to the WG showing the comment was made. I am getting a number of trac emails that have no content, just the title of the issue. I notice that Balacz responded to a previous message from Hideki, but I never saw a non-empty email from Hideki and his comment does not seem to be logged within trac. Maybe trac has some settings that can be modified to make sure comments are sent to the list, or the trac@ address logs comments.=20 Until we can learn about how to configure the tool better, to make sure the chairs have a clear record of comments, I recommend that everybody explicitly send their comments to the mailing list, and not count on trac to send the email for you. If you want your comment tracked in trac, then you should **also** go to the trac page and enter your comment using the web input tool. that's my suggestion. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Tuesday, July 31, 2007 3:45 AM > To: Andy Bierman > Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org > Subject: Re: [Netconf] #9: notification replay in the future >=20 > Hello, > I vote for MUST NOT. Why complicate things. Will it bring us anything? >=20 > I submitted the same comment as Dave in trac, but it seems=20 > that there is no email about updates=20 > to trac issues. >=20 > Balazs >=20 >=20 > Andy Bierman wrote: > > David B Harrington wrote: > >> Hi, > >> > >> MAY NOT or MUST NOT? > >=20 > > MAY NOT (IMO). > > That's why it's an open issue ;-) > >=20 > > Andy > >=20 > >> > >> David Harrington > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> =20 > >> > >>> -----Original Message----- > >>> From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org]=20 > >>> On Behalf Of Netconf > >>> Sent: Saturday, July 28, 2007 4:19 AM > >>> Cc: netconf@ops.ietf.org > >>> Subject: [Netconf] #9: notification replay in the future > >>> > >>> #9: notification replay in the future > >>> ---------------------------------------------+---------------- > >>> -------------- > >>> Reporter: ietf@andybierman.com | =20 > Owner: =20 > >>> Type: defect | Status: new > >>> Priority: major | Milestone: =20 > >>> Component: draft-ietf-netconf-notification | Version: =20 > >>> Keywords: notification replay | =20 > >>> ---------------------------------------------+---------------- > >>> -------------- > >>> The startTime and/or stopTime parameters to the=20 > create-subscription > >>> operation can be in the future. This is unintended behavior that > >>> is not part of the original use cases for this feature. > >>> > >>> Requiring the agent to replay notifications that have not > >>> happened yet is non-intuitive, and there is some ambiguity > >>> with the meaning of the notification, > >>> and when it should be sent. > >>> > >>> The text should be clear that the agent MAY NOT support > >>> startTime and/or stopTime values in the future. > >>> > >>> --=20 > >>> Ticket URL: > >>> Netconf > >>> Issue tracker for the NETCONF Working > >> Grouprzuzz?????rz))=17z?w&r=18z=1B??w > >> > >> > >> > >> --=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 > > --=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 > 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 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 05:38:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFoBS-0000qw-3N for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:38:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFoBQ-0007AR-OG for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:38:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFo6i-000B9F-Sd for netconf-data@psg.com; Tue, 31 Jul 2007 09:33:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFo6Y-000B7S-13 for netconf@ops.ietf.org; Tue, 31 Jul 2007 09:33:31 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFo6V-0002Bz-2I; Tue, 31 Jul 2007 11:33:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Tue, 31 Jul 2007 09:33:23 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #13: testing ML notification X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/13 Message-ID: <074.b5f6888311ed7cbfffc50ebbb49a4aa1@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dbharrington@comcast.net, netconf@ietf.org, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 IzEzOiB0ZXN0aW5nIE1MIG5vdGlmaWNhdGlvbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9y dGVyOiAgZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0ICB8ICAgICAgIE93bmVyOiAgICAgDQogICAg IFR5cGU6ICB0YXNrICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQ cmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgIA0K Q29tcG9uZW50OiAgUkZDNDc0MSAgICAgICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAg DQogS2V5d29yZHM6ICB0ZXN0ICAgICAgICAgICAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIFRoaXMgaXMgYW4gaXRlbSBmb3IgdGVzdGluZyB0aGUgbm90aWZpY2F0aW9uIGNh cGFiaWxpdGllcyBvZiB0cmFjLiBQbGVhc2UNCiBmZWVsIGZyZWUgdG8gY29tbWVudCwgc28gd2Ug Y2FuIHNlZSBpZiB5b3VyIGNvbW1lbnRzIGFyZSByZWZsZWN0ZWQgdG90aGUNCiBsaXN0IGFuZCBy ZWNvcmRlZCBpbiB0cmFjLg0KDQotLSANClRpY2tldCBVUkw6IDxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvd2cvbmV0Y29uZi90cmFjL3RpY2tldC8xMz4NCk5ldGNvbmYgPGh0dHA6Ly90b29scy5pZXRm Lm9yZy93Zy9uZXRjb25mL3RyYWMvPg0KSXNzdWUgdHJhY2tlciBmb3IgdGhlIE5FVENPTkYgV29y a2luZyBHcm91cA== -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 05:50:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFoMz-0007KL-5H for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:50:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFoMy-0007TR-RH for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:50:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFoIP-000CBT-R7 for netconf-data@psg.com; Tue, 31 Jul 2007 09:45:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFoIF-000C9p-14 for netconf@ops.ietf.org; Tue, 31 Jul 2007 09:45:36 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFoIC-00037h-Ro; Tue, 31 Jul 2007 11:45:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Tue, 31 Jul 2007 09:45:28 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: Re: [Netconf] #13: testing ML notification X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/13#comment:1 Message-ID: <083.696363b2e6a84cdbc9ddbec584dcc3ed@tools.ietf.org> References: <074.b5f6888311ed7cbfffc50ebbb49a4aa1@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <074.b5f6888311ed7cbfffc50ebbb49a4aa1@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dbharrington@comcast.net, netconf@ietf.org, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 IzEzOiB0ZXN0aW5nIE1MIG5vdGlmaWNhdGlvbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBv cnRlcjogIGRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCAgfCAgICAgICBPd25lcjogICAgICANCiAg ICAgIFR5cGU6ICB0YXNrICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcg DQogIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAg ICAgIA0KIENvbXBvbmVudDogIFJGQzQ3NDEgICAgICAgICAgICAgICAgICAgfCAgICAgVmVyc2lv bjogICAgICANClJlc29sdXRpb246ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgS2V5 d29yZHM6ICB0ZXN0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDb21tZW50IChieSBkYmhhcnJpbmd0 b25AY29tY2FzdC5uZXQpOg0KDQogdGhpcyBpcyBhIGNoYW5nZSBhZGRlZCB2aWEgdGhlIHdlYiBp bnRlcmZhY2UNCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25l dGNvbmYvdHJhYy90aWNrZXQvMTMjY29tbWVudDoxPg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmll dGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBX b3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 05:53:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFoQO-0008VX-JR for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:53:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFoQO-0007i4-7z for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 05:53:56 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFoM6-000CWP-FO for netconf-data@psg.com; Tue, 31 Jul 2007 09:49:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME autolearn=ham version=3.1.8 Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFoLv-000CVT-L8 for netconf@ops.ietf.org; Tue, 31 Jul 2007 09:49:25 +0000 Received: from localhost ([127.0.0.1] helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFoLt-0003Gu-NR; Tue, 31 Jul 2007 11:49:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Tue, 31 Jul 2007 09:49:17 -0000 Reply-To: trac@tools.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: Re: [Netconf] #13: testing ML notification X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/13#comment:2 Message-ID: <083.93303182ea5e97fe68c9871797da3669@tools.ietf.org> References: <074.b5f6888311ed7cbfffc50ebbb49a4aa1@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <074.b5f6888311ed7cbfffc50ebbb49a4aa1@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dbharrington@comcast.net, netconf@ietf.org, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 IzEzOiB0ZXN0aW5nIE1MIG5vdGlmaWNhdGlvbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBv cnRlcjogIGRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCAgfCAgICAgICBPd25lcjogIGRiaGFycmlu Z3RvbkBjb21jYXN0Lm5ldA0KICAgICAgVHlwZTogIHRhc2sgICAgICAgICAgICAgICAgICAgICAg fCAgICAgIFN0YXR1czogIGFzc2lnbmVkICAgICAgICAgICAgICAgIA0KICBQcmlvcml0eTogIHRy aXZpYWwgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgICAgICAgICAgICAgICAg ICAgICAgIA0KIENvbXBvbmVudDogIFJGQzQ3NDEgICAgICAgICAgICAgICAgICAgfCAgICAgVmVy c2lvbjogICAgICAgICAgICAgICAgICAgICAgICAgIA0KUmVzb2x1dGlvbjogICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICBLZXl3b3JkczogIHRlc3QgICAgICAgICAgICAgICAgICAgIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2hhbmdlcyAoYnkgZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0 KToNCg0KICAqIG93bmVyOiAgPT4gZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0DQogICogcHJpb3Jp dHk6ICBtYWpvciA9PiB0cml2aWFsDQogICogc3RhdHVzOiAgbmV3ID0+IGFzc2lnbmVkDQoNCi0t IA0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlj a2V0LzEzI2NvbW1lbnQ6Mj4NCk5ldGNvbmYgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRj b25mL3RyYWMvPg0KSXNzdWUgdHJhY2tlciBmb3IgdGhlIE5FVENPTkYgV29ya2luZyBHcm91cA== -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 07:11:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpdp-0000p6-S1 for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 07:11:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFpdp-0002Zd-1O for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 07:11:53 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFpXO-000MDL-5s for netconf-data@psg.com; Tue, 31 Jul 2007 11:05:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [206.18.177.53] (helo=alnrmhc13.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFpXC-000M6l-Ll for netconf@ops.ietf.org; Tue, 31 Jul 2007 11:05:08 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070731093435b13006hshae>; Tue, 31 Jul 2007 09:34:36 +0000 From: "David B Harrington" To: "'David B Harrington'" , "'Balazs Lengyel'" , "'Andy Bierman'" Cc: , References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> <46AEE888.5000405@ericsson.com> Subject: RE: Netconf Issue Tracker - followup Date: Tue, 31 Jul 2007 05:34:17 -0400 Message-ID: <011d01c7d356$004ad1a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfTR1lwo7Mce9tTTEe7HyBvKst1mQACs6cAAADKe6A= Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Hi, It appears to me that netconf@ietf.org could be put into the CC: field when creating a new ticket, and then changes will be sent to the netconf list. I will add an item so we can experiment with it to see if this works. dbh > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net]=20 > Sent: Tuesday, July 31, 2007 5:20 AM > To: 'Balazs Lengyel'; 'Andy Bierman' > Cc: 'trac@tools.ietf.org'; 'netconf@ops.ietf.org' > Subject: Netconf Issue Tracker - features >=20 > Hi, >=20 > Just so people on this list understand about trac... >=20 > I had assumed that my email comments would be recorded in=20 > trac, since trac was included in the To: list of my email;=20 > apparently that does not happen. >=20 > If I understand Balacz's comment, entering comments directly=20 > into the trac page records the comment in trac, but does not=20 > send an email to the WG showing the comment was made. >=20 > I am getting a number of trac emails that have no content,=20 > just the title of the issue. I notice that Balacz responded=20 > to a previous message from Hideki, but I never saw a=20 > non-empty email from Hideki and his comment does not seem to=20 > be logged within trac. >=20 > Maybe trac has some settings that can be modified to make=20 > sure comments are sent to the list, or the trac@ address logs=20 > comments.=20 >=20 > Until we can learn about how to configure the tool better, to=20 > make sure the chairs have a clear record of comments, I=20 > recommend that everybody explicitly send their comments to=20 > the mailing list, and not count on trac to send the email for=20 > you. If you want your comment tracked in trac, then you=20 > should **also** go to the trac page and enter your comment=20 > using the web input tool. >=20 > that's my suggestion. >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: owner-netconf@ops.ietf.org=20 > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > > Sent: Tuesday, July 31, 2007 3:45 AM > > To: Andy Bierman > > Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org > > Subject: Re: [Netconf] #9: notification replay in the future > >=20 > > Hello, > > I vote for MUST NOT. Why complicate things. Will it bring=20 > us anything? > >=20 > > I submitted the same comment as Dave in trac, but it seems=20 > > that there is no email about updates=20 > > to trac issues. > >=20 > > Balazs > >=20 > >=20 > > Andy Bierman wrote: > > > David B Harrington wrote: > > >> Hi, > > >> > > >> MAY NOT or MUST NOT? > > >=20 > > > MAY NOT (IMO). > > > That's why it's an open issue ;-) > > >=20 > > > Andy > > >=20 > > >> > > >> David Harrington > > >> dbharrington@comcast.net > > >> ietfdbh@comcast.net > > >> =20 > > >> > > >>> -----Original Message----- > > >>> From: owner-netconf@ops.ietf.org=20 > > [mailto:owner-netconf@ops.ietf.org]=20 > > >>> On Behalf Of Netconf > > >>> Sent: Saturday, July 28, 2007 4:19 AM > > >>> Cc: netconf@ops.ietf.org > > >>> Subject: [Netconf] #9: notification replay in the future > > >>> > > >>> #9: notification replay in the future > > >>> ---------------------------------------------+---------------- > > >>> -------------- > > >>> Reporter: ietf@andybierman.com | =20 > > Owner: =20 > > >>> Type: defect | Status: new > > >>> Priority: major | Milestone: > > >>> Component: draft-ietf-netconf-notification | Version: > > >>> Keywords: notification replay | =20 > > >>> ---------------------------------------------+---------------- > > >>> -------------- > > >>> The startTime and/or stopTime parameters to the=20 > > create-subscription > > >>> operation can be in the future. This is unintended=20 > behavior that > > >>> is not part of the original use cases for this feature. > > >>> > > >>> Requiring the agent to replay notifications that have not > > >>> happened yet is non-intuitive, and there is some ambiguity > > >>> with the meaning of the notification, > > >>> and when it should be sent. > > >>> > > >>> The text should be clear that the agent MAY NOT support > > >>> startTime and/or stopTime values in the future. > > >>> > > >>> --=20 > > >>> Ticket URL: > > >>> Netconf > > >>> Issue tracker for the NETCONF Working > > >> Grouprzuzz?????rz))=17z?w&r=18z=1B??w > > >> > > >> > > >> > > >> --=20 > > >> to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with > > >> the word 'unsubscribe' in a single line as the message text body. > > >> archive: > > >> > > >> > > >=20 > > >=20 > > > --=20 > > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: > >=20 > > --=20 > > 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 > >=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 Tue Jul 31 08:27:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFqoh-00019g-EF for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 08:27:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFqog-0006AL-EI for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 08:27:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFqiY-00072p-0N for netconf-data@psg.com; Tue, 31 Jul 2007 12:20:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [204.127.225.91] (helo=alnrmhc11.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFqiM-00070f-B1 for netconf@ops.ietf.org; Tue, 31 Jul 2007 12:20:44 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070731094332b11000lr49e>; Tue, 31 Jul 2007 09:43:33 +0000 From: "David B Harrington" To: "'Balazs Lengyel'" , "'Andy Bierman'" Cc: "'tom.petch'" , References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <001801c7caee$68279440$0601a8c0@pc6> <46A0FB60.8000702@andybierman.com> <46AE129E.5000705@ericsson.com> Subject: RE: roots wasRe: filtering problem Date: Tue, 31 Jul 2007 05:43:28 -0400 Message-ID: <011e01c7d357$406f4d00$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: <46AE129E.5000705@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfS9kS3nLr4iXp4TXWzQr9h69dT2AAX8c0g Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Hi, SNMPv3 provides two types of filtering of notifications: 1) access control (where the "filters" are defined by the admin), and 2) customized filtering (where the user filters out uninteresting data) Do I understand correctly that you are proposing adding the second type of filtering to netconf notifications? Where does one find severity in a netconf notification? Is that part of the netconf data model, i.e. part of the netconf stream? IIRC, in Montreal we talked about filters being specific to the stream type, so a syslog stream might be filtered on severity and facility (or priority), but it would be hard to filter an SNMP stream on those properties. Are you proposing some type of netconf-specific classes for filtering on these types of properties? How would you map to these for the SNMP stream? David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Monday, July 30, 2007 12:33 PM > To: Andy Bierman > Cc: tom.petch; netconf@ops.ietf.org > Subject: Re: roots wasRe: filtering problem > > Hello, > I think a filter that works on the content of the > notification (as it would be sent) is needed. > People usually filter on things like severity or eventType. > E.g. severity is not even part of > the data model. > > I think the filter should work on the notification content. > > Balazs > > Andy Bierman wrote: > > tom.petch wrote: > >> ----- Original Message ----- > >> From: "Balazs Lengyel" > >> To: "tom.petch" > >> Cc: ; > >> Sent: Thursday, July 19, 2007 5:14 PM > >> Subject: Re: roots wasRe: filtering problem > >> > >> > >>> Hello, > >>> I think the datastore will often have multiple roots. I > foresee/have > >>> heard of > >> the following > >>> situations that as I understand are all valid in Netconf: > >>> 1) One root in one namespace, other namespaces might be > mounted as > >>> subtrees > >>> 2) One root per namespace > >>> 3) One namespace but with many root elements > >>> 4) Many roots in many namespaces > >>> > >>> Case 2 can be viewed as a the single rooted case 1) where > the first > >>> branching > >> is according to > >>> the namespace. > >>> > >>> Case 3) and 4) I feel the filter should be applied to > each root and the > >> results of these > >>> combined under the element in the get/get-config reply. > >>> > >>> Comments? > >>> > >> > >> Mmmm - even more complex than I thought. My initial concern was > >> whether or not > >> the Notifications, the draft in Last Call, were regarded > for filtering > >> purposes > >> as part of the configuration datastore at all, or whether > the filter > >> was applied > >> to the document as it would appear on the wire were it to > pass a filter. > >> > > > > > > This is the $64 question. > > When a element is provided in the , > > does it apply to the conceptual (internal) NETCONF database, > > or rather an XML instance document representing the database? (no) > > > > The examples seem to contradict text that says it works like . > > They show the filter is for the contents, > > starting at its one and only child node -- e.g., . > > > > The draft needs to specify the data root for the > notification . > > > >> Tom Petch > >> > >>> Balazs > > > > Andy > > > >>> > >>> tom.petch wrote: > >>>> This may relate to something that has been bugging me. > >>>> > >>>> XPath is - at times - specified in terms of a root, and an XML > >>>> document has > >> a > >>>> single root element. What is on the wire is an XML > document but the > >> datastore > >>>> is not - as Andy has pointed out before. > >>>> > >>>> So what is an XPath filter being applied to? The event > as it would > >>>> appear > >> on > >>>> the wire as an XML document? A conceptual document > created in the > >>>> datastore > >> for > >>>> the purposes of filtering? And if the latter, should we > - we should! - > >> specify > >>>> a root, either for the purposes of the examples or else > for everything. > >>>> > >>>> RFC4741 is quite discursive about roots but the > notification I-D is > >>>> silent; > >> I > >>>> think that this last needs to change. > >>>> > >>>> Tom Petch > >>>> > >>>> ----- Original Message ----- > >>>> From: "Martin Bjorklund" > >>>> To: > >>>> Cc: > >>>> Sent: Friday, July 13, 2007 4:43 PM > >>>> Subject: Re: filtering problem > >>>> > >>>> > >>>>> Andy Bierman wrote: > >>>>>> Hi, > >>>>>> > >>>>>> There is another problem with filtering and the > examples in sec 5: > >>>>>> (!!!) > >>>>>> > >>>>>> The draft must say exactly where in the element > >>>>>> that the is applied. The current text does not say > >>>>>> anything. > >>>>> Agreed. > >>>>> > >>>>>> All the examples in sec. 5 are broken because the > 'notification type' > >>>>>> layer is missing. > >>>>> I think it is ok. Specify that the filter is applied to the > >>>>> 'notificationContent' element as root (which is the > abstract element). > >>>>> > >>>>>> The examples assume the filters can only be > >>>>>> applied to a conceptual datastore, just like the filter. > >>>>>> > >>>>>> However, the most commonly needed filter is going to be > >>>>>> on the notification type itself! > >>>>>> > >>>>>> Example (w/o namespaces): > >>>>>> > >>>>>> > >>>>>> > >>>>>> date-time > string... > >>>>>> fred@example.com > >>>>>> > >>>>>> /interfaces/interface[name='eth0'] > >>>>>> ... > >>>>>> > >>>>>> > >>>>>> > >>>>>> For simplicity, assume the manager just wants > >>>>>> this one notification type. The filter is going to be > something like: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> Yes, and IMO this is consistent with the examples. > >>>>> > >>>>> > >>>>> /martin > >>>>> > >>>>> > >>>>> > >>>>>> A filter for configChange just on a specific > configTarget might be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > /interfaces/interface[name='eth0'] > >>>>>> > >>>>>> > >>>>>> > >>>>>> The way the draft is now does not reflect how notifications are > >>>>>> actually structured. > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> to unsubscribe send a message to > netconf-request@ops.ietf.org with > >>>>>> the word 'unsubscribe' in a single line as the message > text body. > >>>>>> archive: > >>>>>> > >>>>> -- > >>>>> to unsubscribe send a message to > netconf-request@ops.ietf.org with > >>>>> the word 'unsubscribe' in a single line as the message > text body. > >>>>> archive: > >>>> > >>>> -- > >>>> to unsubscribe send a message to > netconf-request@ops.ietf.org with > >>>> the word 'unsubscribe' in a single line as the message text body. > >>>> archive: > >>> > >>> -- > >>> to unsubscribe send a message to netconf-request@ops.ietf.org with > >>> the word 'unsubscribe' in a single line as the message text body. > >>> archive: > >> > >> > >> -- > >> to 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: > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 12:34:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFugI-00041Z-TH for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 12:34:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFugH-0006iL-F0 for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 12:34:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFuXL-000Acm-5B for netconf-data@psg.com; Tue, 31 Jul 2007 16:25:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [68.142.229.104] (helo=smtp101.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFuX9-000AbA-8e for netconf@ops.ietf.org; Tue, 31 Jul 2007 16:25:25 +0000 Received: (qmail 76785 invoked from network); 31 Jul 2007 16:25:18 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp101.sbc.mail.re2.yahoo.com with SMTP; 31 Jul 2007 16:25:18 -0000 X-YMail-OSG: iCvvNUwVM1lCjgwhy8AzAe9SCygdtPBj458JokJg_2xKlE9XXR2wvnFTapC_iutC8F1AcVu4cesuMtspSvvSNCQIPHLYBSPlaOcev7y8csAGFdSgQrIF4A-- Message-ID: <46AF621B.5070007@andybierman.com> Date: Tue, 31 Jul 2007 09:23:55 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Henrik Levkowetz CC: David B Harrington , 'Balazs Lengyel' , trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: Netconf Issue Tracker - followup References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> <46AEE888.5000405@ericsson.com> <011d01c7d356$004ad1a0$0600a8c0@china.huawei.com> <46AF3F82.90403@levkowetz.com> In-Reply-To: <46AF3F82.90403@levkowetz.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.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Henrik Levkowetz wrote: > Hi all, > > Regarding configuration of Trac, I can set it up so that all issue > changes is sent to the list without you needing to add the list to > the Cc: field. > > There is however an issue at the IETF mail-server end also, which > have to be resolved -- at least 2 of the mails from Trac has > resulted in a delivery failure. I'm going to try to find out exactly > why, and fix. > > Assuming that's sorted out, should I configure the tracker to send > notification for all issue changes to the list? > I think people misinterpreted my original comment about using the tracker as intended. I meant that instead of reviewing a draft by submitting a long email to the WG mailing list, enter the issues one at a time into the tracker. IMO, the WG should discuss the issues on the mailing list and then the ticket updated by a WG member or the administrator as needed. > > Regards, > > Henrik Andy > > > On 2007-07-31 04:34 David B Harrington said the following: >> Hi, >> >> It appears to me that netconf@ietf.org could be put into the CC: field >> when creating a new ticket, and then changes will be sent to the >> netconf list. >> >> I will add an item so we can experiment with it to see if this works. >> >> dbh >> >>> -----Original Message----- >>> From: David B Harrington [mailto:dbharrington@comcast.net] >>> Sent: Tuesday, July 31, 2007 5:20 AM >>> To: 'Balazs Lengyel'; 'Andy Bierman' >>> Cc: 'trac@tools.ietf.org'; 'netconf@ops.ietf.org' >>> Subject: Netconf Issue Tracker - features >>> >>> Hi, >>> >>> Just so people on this list understand about trac... >>> >>> I had assumed that my email comments would be recorded in >>> trac, since trac was included in the To: list of my email; >>> apparently that does not happen. >>> >>> If I understand Balacz's comment, entering comments directly >>> into the trac page records the comment in trac, but does not >>> send an email to the WG showing the comment was made. >>> >>> I am getting a number of trac emails that have no content, >>> just the title of the issue. I notice that Balacz responded >>> to a previous message from Hideki, but I never saw a >>> non-empty email from Hideki and his comment does not seem to >>> be logged within trac. >>> >>> Maybe trac has some settings that can be modified to make >>> sure comments are sent to the list, or the trac@ address logs >>> comments. >>> >>> Until we can learn about how to configure the tool better, to >>> make sure the chairs have a clear record of comments, I >>> recommend that everybody explicitly send their comments to >>> the mailing list, and not count on trac to send the email for >>> you. If you want your comment tracked in trac, then you >>> should **also** go to the trac page and enter your comment >>> using the web input tool. >>> >>> that's my suggestion. >>> >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> >>> >>>> -----Original Message----- >>>> From: owner-netconf@ops.ietf.org >>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel >>>> Sent: Tuesday, July 31, 2007 3:45 AM >>>> To: Andy Bierman >>>> Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org >>>> Subject: Re: [Netconf] #9: notification replay in the future >>>> >>>> Hello, >>>> I vote for MUST NOT. Why complicate things. Will it bring >>> us anything? >>>> I submitted the same comment as Dave in trac, but it seems >>>> that there is no email about updates >>>> to trac issues. >>>> >>>> Balazs >>>> >>>> >>>> Andy Bierman wrote: >>>>> David B Harrington wrote: >>>>>> Hi, >>>>>> >>>>>> MAY NOT or MUST NOT? >>>>> MAY NOT (IMO). >>>>> That's why it's an open issue ;-) >>>>> >>>>> Andy >>>>> >>>>>> David Harrington >>>>>> dbharrington@comcast.net >>>>>> ietfdbh@comcast.net >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-netconf@ops.ietf.org >>>> [mailto:owner-netconf@ops.ietf.org] >>>>>>> On Behalf Of Netconf >>>>>>> Sent: Saturday, July 28, 2007 4:19 AM >>>>>>> Cc: netconf@ops.ietf.org >>>>>>> Subject: [Netconf] #9: notification replay in the future >>>>>>> >>>>>>> #9: notification replay in the future >>>>>>> ---------------------------------------------+---------------- >>>>>>> -------------- >>>>>>> Reporter: ietf@andybierman.com | >>>> Owner: >>>>>>> Type: defect | Status: new >>>>>>> Priority: major | Milestone: >>>>>>> Component: draft-ietf-netconf-notification | Version: >>>>>>> Keywords: notification replay | >>>>>>> ---------------------------------------------+---------------- >>>>>>> -------------- >>>>>>> The startTime and/or stopTime parameters to the >>>> create-subscription >>>>>>> operation can be in the future. This is unintended >>> behavior that >>>>>>> is not part of the original use cases for this feature. >>>>>>> >>>>>>> Requiring the agent to replay notifications that have not >>>>>>> happened yet is non-intuitive, and there is some ambiguity >>>>>>> with the meaning of the notification, >>>>>>> and when it should be sent. >>>>>>> >>>>>>> The text should be clear that the agent MAY NOT support >>>>>>> startTime and/or stopTime values in the future. >>>>>>> >>>>>>> -- >>>>>>> Ticket URL: >>>>>>> Netconf >>>>>>> Issue tracker for the NETCONF Working >>>>>> Grouprzuzz?????rz))z?w&rz??w >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> to 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: >>>> -- >>>> 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: >>>> >> >> > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 12:46:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuru-00042D-R6 for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 12:46:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFurt-00077j-HA for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 12:46:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFunS-000Cxg-3M for netconf-data@psg.com; Tue, 31 Jul 2007 16:42:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) 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.8 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFunG-000CwL-RA for netconf@ops.ietf.org; Tue, 31 Jul 2007 16:42:04 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6VGfsO20322 for ; Tue, 31 Jul 2007 16:41:54 GMT 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 text for Section 1.2 of the notifications draft Date: Tue, 31 Jul 2007 12:41:38 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4102CCD80@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed text for Section 1.2 of the notifications draft Thread-Index: AcfSolFJU81q6QZ4TpqwG2VIRZeiOQA7y0iQ References: From: "Sharon Chisholm" To: "Romascanu, Dan (Dan)" Cc: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi Looks good, except the third bullet. o There will be a limit for the message size at a reasonable value (i.e., not too short)=20 The intension was to ensure that there was either no limit or a reasonably long limit. The working group went with no limit. Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, July 30, 2007 8:08 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: Netconf (E-mail) Subject: Proposed text for Section 1.2 of the notifications draft Following the discussions in Chicago, here is my action item including the proposed text of section 1.2 of the Notifications Draft.=20 - Section 1.4 in draft-08 will disappear.=20 - Proposed text for new Section 1.2 1.2 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. The scope of the work aims meeting the following operational needs:=20 o The initial release should ensure support for notifications in support of configuration operations o It should be possible to use the same data model for notifications as=20 for configuration operations.=20 o There will be a limit for the message size at a reasonable value (ie, not too short)=20 o The notifications should be carried over a connection-oriented delivery=20 mechanism o A subscription mechanism for notifications should be provided. This=20 takes into account that a NETCONF server does not send notifications=20 before being asked to do so and that it is the NETCONF client who initiates the flow of notifications o A filtering mechanism for sending notifications should be put in place within the NETCONF server o The information contained in a notification should be sufficient=20 so that it can be analyzed independent of the transport mechanism. In other words the data content fully describes a notification;=20 protocol information is not needed to understand a notification, o The server should have the capability to replay locally logged=20 notifications Let me know if this looks OK.=20 Dan =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 13:02:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFv7Q-0008OE-0V for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 13:02:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFv7O-0007bj-Id for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 13:02:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFv1T-000EhQ-1r for netconf-data@psg.com; Tue, 31 Jul 2007 16:56:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.97] (helo=smtp108.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFv1E-000Eei-Uz for netconf@ops.ietf.org; Tue, 31 Jul 2007 16:56:33 +0000 Received: (qmail 52795 invoked from network); 31 Jul 2007 16:56:24 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp108.sbc.mail.re2.yahoo.com with SMTP; 31 Jul 2007 16:56:23 -0000 X-YMail-OSG: f9fHw7wVM1leGvXBc83v17YFW2PAQ.wQp7U.VCzmtqvdgWSB9xlSGel0gscPDSEmG6PzlkpgbR.qeu8R7GT6wH8n1y5f4mM5LKLAfqP_P88txNqfbgWFyA-- Message-ID: <46AF6964.4090809@andybierman.com> Date: Tue, 31 Jul 2007 09:55:00 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David B Harrington CC: 'Balazs Lengyel' , "'tom.petch'" , netconf@ops.ietf.org Subject: Re: roots wasRe: filtering problem References: <4697981E.6010301@andybierman.com> <20070713.164342.74182725.mbj@tail-f.com> <047201c7c7c5$94d7bdc0$0601a8c0@pc6> <469F7FBF.3080009@ericsson.com> <001801c7caee$68279440$0601a8c0@pc6> <46A0FB60.8000702@andybierman.com> <46AE129E.5000705@ericsson.com> <011e01c7d357$406f4d00$0600a8c0@china.huawei.com> In-Reply-To: <011e01c7d357$406f4d00$0600a8c0@china.huawei.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.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf David B Harrington wrote: > Hi, > > SNMPv3 provides two types of filtering of notifications: > 1) access control (where the "filters" are defined by the admin), and > 2) customized filtering (where the user filters out uninteresting > data) > > Do I understand correctly that you are proposing adding the second > type of filtering to netconf notifications? NETCONF has always have several custom filtering mechanisms, and vendors are adding more all the time (e.g., with-defaults). Whatever makes it easiest on the operator will most likely get done. The filtering in Notifications is different for 2 reasons, as Martin has described in hallway BoFs... 1) the filter applies to the notification message, not the conceptual NETCONF configuration database, so the agent code may need significant modification to support notification filtering. If the agent supports the #xpath capability and the #notification capability, then it must support xpath filtering of notifications. (This is what the current draft implies.) 2) Instead of pruning data, like for responses, the notification filter returns true or false, and determines whether the entire filter is dropped or not on a particular session. > > Where does one find severity in a netconf notification? Is that part > of the netconf data model, i.e. part of the netconf stream? It is part of a data model for the notification content, written by some vendor or SDO. The WG did not reach agreement on a generic (same say reinvented) event classification system. More standards work is needed on the structure of content in the NETCONF stream. (People will submit proposals I think ;-) > > IIRC, in Montreal we talked about filters being specific to the stream > type, so a syslog stream might be filtered on severity and facility > (or priority), but it would be hard to filter an SNMP stream on those > properties. Are you proposing some type of netconf-specific classes > for filtering on these types of properties? How would you map to these > for the SNMP stream? This would be a new kind of filtering. We are trying to reuse the existing mechanisms as much as possible. Access control on a stream? Filter on a stream? IMO, this is not relevant to the NETCONF protocol. NETCONF says that the filters work on XML, not conceptual streams. That can only mean the individual notification elements which contain an eventType from a particular namespace. There is no restriction that the same QName could not be used in a different stream (especially combo-streams). So it may seem like a nit, but let's try to keep the XML stuff straight. For our purposes, the agent must construct (at least conceptually) an XML instance document to compare against the filter, and interpret the output and process it according to what RFC 4741 or the Notification draft expects to happen. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net Andy > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel >> Sent: Monday, July 30, 2007 12:33 PM >> To: Andy Bierman >> Cc: tom.petch; netconf@ops.ietf.org >> Subject: Re: roots wasRe: filtering problem >> >> Hello, >> I think a filter that works on the content of the >> notification (as it would be sent) is needed. >> People usually filter on things like severity or eventType. >> E.g. severity is not even part of >> the data model. >> >> I think the filter should work on the notification content. >> >> Balazs >> >> Andy Bierman wrote: >>> tom.petch wrote: >>>> ----- Original Message ----- >>>> From: "Balazs Lengyel" >>>> To: "tom.petch" >>>> Cc: ; >>>> Sent: Thursday, July 19, 2007 5:14 PM >>>> Subject: Re: roots wasRe: filtering problem >>>> >>>> >>>>> Hello, >>>>> I think the datastore will often have multiple roots. I >> foresee/have >>>>> heard of >>>> the following >>>>> situations that as I understand are all valid in Netconf: >>>>> 1) One root in one namespace, other namespaces might be >> mounted as >>>>> subtrees >>>>> 2) One root per namespace >>>>> 3) One namespace but with many root elements >>>>> 4) Many roots in many namespaces >>>>> >>>>> Case 2 can be viewed as a the single rooted case 1) where >> the first >>>>> branching >>>> is according to >>>>> the namespace. >>>>> >>>>> Case 3) and 4) I feel the filter should be applied to >> each root and the >>>> results of these >>>>> combined under the element in the get/get-config reply. >>>>> >>>>> Comments? >>>>> >>>> Mmmm - even more complex than I thought. My initial concern was >>>> whether or not >>>> the Notifications, the draft in Last Call, were regarded >> for filtering >>>> purposes >>>> as part of the configuration datastore at all, or whether >> the filter >>>> was applied >>>> to the document as it would appear on the wire were it to >> pass a filter. >>> >>> This is the $64 question. >>> When a element is provided in the , >>> does it apply to the conceptual (internal) NETCONF database, >>> or rather an XML instance document representing the database? > (no) >>> The examples seem to contradict text that says it works like > . >>> They show the filter is for the contents, >>> starting at its one and only child node -- e.g., . >>> >>> The draft needs to specify the data root for the >> notification . >>>> Tom Petch >>>> >>>>> Balazs >>> Andy >>> >>>>> tom.petch wrote: >>>>>> This may relate to something that has been bugging me. >>>>>> >>>>>> XPath is - at times - specified in terms of a root, and an XML >>>>>> document has >>>> a >>>>>> single root element. What is on the wire is an XML >> document but the >>>> datastore >>>>>> is not - as Andy has pointed out before. >>>>>> >>>>>> So what is an XPath filter being applied to? The event >> as it would >>>>>> appear >>>> on >>>>>> the wire as an XML document? A conceptual document >> created in the >>>>>> datastore >>>> for >>>>>> the purposes of filtering? And if the latter, should we >> - we should! - >>>> specify >>>>>> a root, either for the purposes of the examples or else >> for everything. >>>>>> RFC4741 is quite discursive about roots but the >> notification I-D is >>>>>> silent; >>>> I >>>>>> think that this last needs to change. >>>>>> >>>>>> Tom Petch >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Martin Bjorklund" >>>>>> To: >>>>>> Cc: >>>>>> Sent: Friday, July 13, 2007 4:43 PM >>>>>> Subject: Re: filtering problem >>>>>> >>>>>> >>>>>>> Andy Bierman wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> There is another problem with filtering and the >> examples in sec 5: >>>>>>>> (!!!) >>>>>>>> >>>>>>>> The draft must say exactly where in the > element >>>>>>>> that the is applied. The current text does not say >>>>>>>> anything. >>>>>>> Agreed. >>>>>>> >>>>>>>> All the examples in sec. 5 are broken because the >> 'notification type' >>>>>>>> layer is missing. >>>>>>> I think it is ok. Specify that the filter is applied to the >>>>>>> 'notificationContent' element as root (which is the >> abstract element). >>>>>>>> The examples assume the filters can only be >>>>>>>> applied to a conceptual datastore, just like the > filter. >>>>>>>> However, the most commonly needed filter is going to be >>>>>>>> on the notification type itself! >>>>>>>> >>>>>>>> Example (w/o namespaces): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> date-time >> string... >>>>>>>> fred@example.com >>>>>>>> >>>>>>>> > /interfaces/interface[name='eth0'] >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For simplicity, assume the manager just wants >>>>>>>> this one notification type. The filter is going to be >> something like: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Yes, and IMO this is consistent with the examples. >>>>>>> >>>>>>> >>>>>>> /martin >>>>>>> >>>>>>> >>>>>>> >>>>>>>> A filter for configChange just on a specific >> configTarget might be: >>>>>>>> >>>>>>>> >>>>>>>> >> /interfaces/interface[name='eth0'] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The way the draft is now does not reflect how notifications > are >>>>>>>> actually structured. >>>>>>>> >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> to unsubscribe send a message to >> netconf-request@ops.ietf.org with >>>>>>>> the word 'unsubscribe' in a single line as the message >> text body. >>>>>>>> archive: >>>>>>>> >>>>>>> -- >>>>>>> to unsubscribe send a message to >> netconf-request@ops.ietf.org with >>>>>>> the word 'unsubscribe' in a single line as the message >> text body. >>>>>>> archive: >>>>>> -- >>>>>> to unsubscribe send a message to >> netconf-request@ops.ietf.org with >>>>>> the word 'unsubscribe' in a single line as the message text > body. >>>>>> archive: >>>>> -- >>>>> to unsubscribe send a message to netconf-request@ops.ietf.org > with >>>>> the word 'unsubscribe' in a single line as the message text > body. >>>>> archive: >>>> >>>> -- >>>> to 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: >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jul 31 16:55:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFykr-0003Lx-Hd for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 16:55:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFykq-0005PK-68 for netconf-archive@lists.ietf.org; Tue, 31 Jul 2007 16:55:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFydv-000DPG-Jh for netconf-data@psg.com; Tue, 31 Jul 2007 20:48:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.96] (helo=smtp109.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IFydk-000DN8-7H for netconf@ops.ietf.org; Tue, 31 Jul 2007 20:48:30 +0000 Received: (qmail 54134 invoked from network); 31 Jul 2007 20:48:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp109.sbc.mail.re2.yahoo.com with SMTP; 31 Jul 2007 20:48:23 -0000 X-YMail-OSG: QdNiBj0VM1nobfN7.FpBFiOZwfGFQCQPmTm0C50Cv1o50SxWsutJVrZmLPB4d56q7q79HFq_V5V63muKkIUaSEqrrw-- Message-ID: <46AF9FBF.1040301@andybierman.com> Date: Tue, 31 Jul 2007 13:46:55 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: NETCONF Goes On , "Netconf (E-mail)" Subject: [Fwd: I-D ACTION:draft-bierman-ncx-smi-00.txt] Content-Type: multipart/mixed; boundary="------------080500060401070507090804" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff This is a multi-part message in MIME format. --------------080500060401070507090804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, This draft attempts to document the data modeling framework I have implemented, along with security and interoperability guidelines for NETCONF. thanks, Andy --------------080500060401070507090804 Content-Type: message/rfc822; name="I-D ACTION:draft-bierman-ncx-smi-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-bierman-ncx-smi-00.txt" X-Account-Key: account4 Return-Path: Delivered-To: ietf@6908.7081 Received: (qmail 25399 invoked by uid 78); 31 Jul 2007 16:16:00 -0000 Received: from unknown (HELO ns-mr18.netsolmail.com) (205.178.146.50) by 0 with SMTP; 31 Jul 2007 16:16:00 -0000 Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145]) by ns-mr18.netsolmail.com (8.13.6/8.13.6) with ESMTP id l6VGFx8L026821 for ; Tue, 31 Jul 2007 12:15:59 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuNL-0007i4-S1; Tue, 31 Jul 2007 12:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuND-0007ca-D2 for i-d-announce@ietf.org; Tue, 31 Jul 2007 12:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFuNC-0005eK-Uo for i-d-announce@ietf.org; Tue, 31 Jul 2007 12:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A03E32AB6F for ; Tue, 31 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IFuNC-0001b1-7V for i-d-announce@ietf.org; Tue, 31 Jul 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 31 Jul 2007 12:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: I-D ACTION:draft-bierman-ncx-smi-00.txt 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Configuration Extensions : Structure of Management Information Author(s) : A. Bierman Filename : draft-bierman-ncx-smi-00.txt Pages : 51 Date : 2007-7-31 The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured data modeling environment which promotes human usability, multi-vendor interoperability, and reuse of existing IETF data models written in SMIv2. The Network Configuration Extensions (NCX) are a set of specifications intended to address NETCONF data modeling issues. This document defines a Structure of Management Information (SMI) suitable for use with the NETCONF protocol, intended to promote a more consistent, manageable, and interoperable infra-structure for ongoing development of NETCONF- based management interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bierman-ncx-smi-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-bierman-ncx-smi-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-bierman-ncx-smi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-31113909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bierman-ncx-smi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bierman-ncx-smi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-31113909.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------080500060401070507090804-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: