From owner-netconf@ops.ietf.org Wed Aug 01 10:56: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 1IGFcX-0002xM-69 for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 10:56:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGFcW-0000ce-Q5 for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 10:56:17 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGFUN-000I8h-Jw for netconf-data@psg.com; Wed, 01 Aug 2007 14:47: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 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 1IGFUB-000I6O-Sw for netconf@ops.ietf.org; Wed, 01 Aug 2007 14:47:46 +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 1IGFU9-0000Tc-Ep; Wed, 01 Aug 2007 16:47:37 +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: Wed, 01 Aug 2007 14:47:37 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #14: notification termination mechanism considered dangerous X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netconf/trac/ticket/14 Message-ID: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> X-Trac-Ticket-ID: 14 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: 52e1467c2184c31006318542db5614d5 IzE0OiBub3RpZmljYXRpb24gdGVybWluYXRpb24gbWVjaGFuaXNtIGNvbnNpZGVyZWQgZGFuZ2Vy b3VzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBpZXRmQGFuZHliaWVybWFuLmNv bSAgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAgICAgDQogICAgIFR5cGU6ICBkZWZlY3QgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBt YWpvciAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgDQpDb21w b25lbnQ6ICBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uICB8ICAgICBWZXJzaW9uOiAg ICAgDQogS2V5d29yZHM6ICBub3RpZmljYXRpb24tMDggICAgICAgICAgICAgICAgICB8ICANCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiBUaGVyZSBuZWVkcyB0byBiZSBhIHNhZmUgbWVjaGFuaXNtIHRv IHRlcm1pbmF0ZQ0KIGEgc2Vzc2lvbiB0aGF0IGlzIGluIG5vdGlmaWNhdGlvbiBkZWxpdmVyeSBt b2RlLg0KIFRoZSBtYW5hZ2VyIG11c3QgYmUgYWJsZSB0byBpbnZva2UgPGNsb3NlLXNlc3Npb24+ DQogaW4gdGhpcyBtb2RlLCByYXRoZXIgdGhhbiB0ZXJtaW5hdGluZyB0aGUNCiBzZXNzaW9uIGJ5 IG90aGVyIG1lYW5zLg0KDQogQ3VycmVudGx5IGEgbWFuYWdlciBtdXN0IHN0YXJ0IGFub3RoZXIg c2Vzc2lvbiwNCiBkZXRlcm1pbmUgdGhlIGNvcnJlY3Qgc2Vzc2lvbiBudW1iZXIgdGhlIGtpbGws DQogKGRvbid0IGdldCB0aGF0IHdyb25nISkgYW5kIGludm9rZSB0aGUgPGtpbGwtc2Vzc2lvbj4N CiBvcGVyYXRpb24sIHRoZW4gY2xvc2UgdGhlIG5ldyBzZXNzaW9uLg0KDQogVGhlIGN1cnJlbnQg JzxraWxsLXNlc3Npb24+IG1ldGhvZCcsIGFzIHRoZSBzdGFuZGFyZCBtZWNoYW5pc20NCiB0byB0 ZXJtaW5hdGUgbm90aWZpY2F0aW9ucywgaXMgZGFuZ2Vyb3VzLiAgSW1hZ2luZSBhIHVuaXgNCiBw cm9ncmFtIHRoYXQgY291bGQgb25seSBiZSB0dXJuZWQgb2ZmIHdpdGggYSAna2lsbCAtOSBwaWQn DQogY29tbWFuZC4gIFRoYXQgaXMgYSByZWFsbHkgZGFuZ2Vyb3VzIHN5c2FkbWluIHByYWN0aWNl Lg0KIFRoZSA8a2lsbC1zZXNzaW9uPiBzaG91bGQgYmUgdXNlZCBzcGFyaW5nbHksIGp1c3QgbGlr ZQ0KIHRoZSB1bml4ICdraWxsJyBjb21tYW5kLg0KDQogVGhlIG90aGVyIHN0YW5kYXJkIHdheSB0 byB0ZXJtaW5hdGUgbm90aWZpY2F0aW9ucyBpcyBmb3INCiB0aGUgbWFuYWdlciB0byBjbG9zZSB0 aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gKHVuZXhwZWN0ZWRseQ0KIGluIHRoZSBhZ2VudCdzIFBP VikuICBUaGlzIGlzIGV2ZW4gd29yc2UgdGhhbiA8a2lsbC1zZXNzaW9uPg0KIGJlY2F1c2UgdGhl IGFnZW50IG1pZ2h0IChpbmNvcnJlY3RseSkgZ2VuZXJhdGUgZXZlbnQNCiBub3RpZmljYXRpb25z IGFib3V0IGEgbmV0d29yayBwcm9ibGVtIChsb3N0IHNlc3Npb24pLg0KDQotLSANClRpY2tldCBV Ukw6IDxodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzE0 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 Wed Aug 01 11:04: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 1IGFku-0004JX-Nd for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:04:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGFku-0000oP-AW for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:04:56 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGFfS-000KKF-Sd for netconf-data@psg.com; Wed, 01 Aug 2007 14:59: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.98] (helo=smtp107.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGFfH-000KJD-W8 for netconf@ops.ietf.org; Wed, 01 Aug 2007 14:59:13 +0000 Received: (qmail 81684 invoked from network); 1 Aug 2007 14:59:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp107.sbc.mail.re2.yahoo.com with SMTP; 1 Aug 2007 14:59:07 -0000 X-YMail-OSG: K15q6wcVM1k_s7ZHpOnppJDZA2Fv4mEJd33DKW4Qp.E1zvpi Message-ID: <46B09F61.6060005@andybierman.com> Date: Wed, 01 Aug 2007 07:57:37 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel 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> <46AEE888.5000405@ericsson.com> In-Reply-To: <46AEE888.5000405@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: 7aafa0432175920a4b3e118e16c5cb64 Balazs Lengyel wrote: > Hello, > I vote for MUST NOT. Why complicate things. Will it bring us anything? > Things are complicated either way. First, what are the choices? 1) require interleaving MUST be supported by the agent 2) allow interleaving to be supported by the agent, but just warn that the manager SHOULD NOT interleave and the agent MAY NOT accept interleaved requests. 3) allow interleaving to be supported by the agent, based on the '#interleave' capability, and also warn that the manager SHOULD NOT interleave and the agent MAY NOT accept interleaved requests. 4) require interleaving MUST NOT be supported by the agent - what happens when the manager sends an anyway? a) close session b) ignore request c) send operation-failed response What are the benefits? There obvious benefit from allowing interleaving, if you believe sessions are expensive -- it saves an extra session on both the manager and the agent. The real benefit is that is a the cleanest way to terminate sessions, and it should be used in all modes. The and drop connection methods are both bad ideas. It would also be a HUGE CLR to forbid interleaving completely. In the future, some new feature will come up that will make it clear the agent should never be in a mode it MUST stop listening to all input from the client. It will be clear then (if not now) that this is a really bad idea. So what are the benefits of forbidding interleaving completely, and what happens if the manager sends an anyway? > I submitted the same comment as Dave in trac, but it seems that there is > no email about updates to trac issues. > > 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 Wed Aug 01 11:11: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 1IGFqm-00020a-KG for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:11:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGFqm-0000xD-2j for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:11:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGFkR-000LjI-5N for netconf-data@psg.com; Wed, 01 Aug 2007 15:04: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.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGFkF-000Li2-3s for netconf@ops.ietf.org; Wed, 01 Aug 2007 15:04:21 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BF290213A4; Wed, 1 Aug 2007 17:03:54 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-23-46b0a0daf023 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9239A20188; Wed, 1 Aug 2007 17:03:54 +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, 1 Aug 2007 17:03:54 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 17:03:54 +0200 Message-ID: <46B0A0D9.6000307@ericsson.com> Date: Wed, 01 Aug 2007 17:03:53 +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> <46AEE888.5000405@ericsson.com> <46B09F61.6060005@andybierman.com> In-Reply-To: <46B09F61.6060005@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 15:03:54.0371 (UTC) FILETIME=[2D774530:01C7D44D] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hello Andy, My mail was about replay in the future not interleaving. There I vote for "the client MUST NOT" support replay in the future. And yes interleaving is complicated. Balazs Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> I vote for MUST NOT. Why complicate things. Will it bring us anything? >> > > Things are complicated either way. > First, what are the choices? > > 1) require interleaving MUST be supported by the agent > 2) allow interleaving to be supported by the agent, > but just warn that the manager SHOULD NOT interleave > and the agent MAY NOT accept interleaved requests. > 3) allow interleaving to be supported by the agent, > based on the '#interleave' capability, > and also warn that the manager SHOULD NOT interleave > and the agent MAY NOT accept interleaved requests. > 4) require interleaving MUST NOT be supported by the agent > - what happens when the manager sends an anyway? > a) close session > b) ignore request > c) send operation-failed response > > What are the benefits? > > There obvious benefit from allowing interleaving, > if you believe sessions are expensive -- it saves an extra session > on both the manager and the agent. > > The real benefit is that is a the cleanest way > to terminate sessions, and it should be used in all modes. > The and drop connection methods are both bad ideas. > > It would also be a HUGE CLR to forbid interleaving completely. > In the future, some new feature will come up that will make it > clear the agent should never be in a mode it MUST stop listening > to all input from the client. It will be clear then (if not now) > that this is a really bad idea. > > So what are the benefits of forbidding interleaving completely, > and what happens if the manager sends an anyway? > > >> I submitted the same comment as Dave in trac, but it seems that there >> is no email about updates to trac issues. >> >> Balazs >> > > Andy -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 01 11:19: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 1IGFyt-0000VQ-DY for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:19:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGFys-00018f-6S for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:19:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGFqz-000NcC-5J for netconf-data@psg.com; Wed, 01 Aug 2007 15: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=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.93] (helo=smtp112.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGFqo-000NbI-9F for netconf@ops.ietf.org; Wed, 01 Aug 2007 15:11:07 +0000 Received: (qmail 7188 invoked from network); 1 Aug 2007 15:11:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp112.sbc.mail.re2.yahoo.com with SMTP; 1 Aug 2007 15:11:00 -0000 X-YMail-OSG: _Ns2mj4VM1nq9Ccy9Vgq0uxuzYhB5.ZFKfmrVy0B5NdeYmfYzxaMvTz_fhASgc4C6PQ5E5inKjIUov9aD2SNhzxxblT.B0Md6PpWAnR_cPvpBBXzYfXk Message-ID: <46B0A22C.40403@andybierman.com> Date: Wed, 01 Aug 2007 08:09:32 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel 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> <46AEE888.5000405@ericsson.com> <46B09F61.6060005@andybierman.com> <46B0A0D9.6000307@ericsson.com> In-Reply-To: <46B0A0D9.6000307@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: 25620135586de10c627e3628c432b04a Balazs Lengyel wrote: > Hello Andy, > My mail was about replay in the future not interleaving. There I vote > for "the client MUST NOT" support replay in the future. oops. I agree that startTime in the future MUST be an error. > And yes interleaving is complicated. wrong ticket number... grrrr > Balazs Andy > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello, >>> I vote for MUST NOT. Why complicate things. Will it bring us anything? >>> >> >> Things are complicated either way. >> First, what are the choices? >> >> 1) require interleaving MUST be supported by the agent >> 2) allow interleaving to be supported by the agent, >> but just warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 3) allow interleaving to be supported by the agent, >> based on the '#interleave' capability, >> and also warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 4) require interleaving MUST NOT be supported by the agent >> - what happens when the manager sends an anyway? >> a) close session >> b) ignore request >> c) send operation-failed response >> >> What are the benefits? >> >> There obvious benefit from allowing interleaving, >> if you believe sessions are expensive -- it saves an extra session >> on both the manager and the agent. >> >> The real benefit is that is a the cleanest way >> to terminate sessions, and it should be used in all modes. >> The and drop connection methods are both bad ideas. >> >> It would also be a HUGE CLR to forbid interleaving completely. >> In the future, some new feature will come up that will make it >> clear the agent should never be in a mode it MUST stop listening >> to all input from the client. It will be clear then (if not now) >> that this is a really bad idea. >> >> So what are the benefits of forbidding interleaving completely, >> and what happens if the manager sends an anyway? >> >> >>> I submitted the same comment as Dave in trac, but it seems that there >>> is no email about updates to trac issues. >>> >>> 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 Wed Aug 01 11:40: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 1IGGIx-00059U-AG for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:40:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGGIw-0001lP-P2 for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 11:40:07 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGGDK-000Prg-AJ for netconf-data@psg.com; Wed, 01 Aug 2007 15:34: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.93] (helo=smtp112.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGGD9-000Pr0-Au for netconf@ops.ietf.org; Wed, 01 Aug 2007 15:34:12 +0000 Received: (qmail 54400 invoked from network); 1 Aug 2007 15:34:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.187.99 with plain) by smtp112.sbc.mail.re2.yahoo.com with SMTP; 1 Aug 2007 15:34:06 -0000 X-YMail-OSG: dKK8zQoVM1kxR.Cr8Wv4NKYE9jHKREDYTufKUSMxTzCOa73x Message-ID: <46B0A795.7030802@andybierman.com> Date: Wed, 01 Aug 2007 08:32:37 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel 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> <46AEE888.5000405@ericsson.com> <46B09F61.6060005@andybierman.com> <46B0A0D9.6000307@ericsson.com> In-Reply-To: <46B0A0D9.6000307@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: 0fa76816851382eb71b0a882ccdc29ac Balazs Lengyel wrote: > Hello Andy, > My mail was about replay in the future not interleaving. There I vote > for "the client MUST NOT" support replay in the future. > And yes interleaving is complicated. IMO, there is WG consensus that startTime in the future MUST be an error. The alternative is to rewrite major portions of the document to support a 'cron' like feature, added at the last minute. The current replay feature needs to be as simple as possible so it will be more inter-operable. There needs to be complete and precise definitions of as much behavior as we can anticipate. > Balazs Andy > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello, >>> I vote for MUST NOT. Why complicate things. Will it bring us anything? >>> >> >> Things are complicated either way. >> First, what are the choices? >> >> 1) require interleaving MUST be supported by the agent >> 2) allow interleaving to be supported by the agent, >> but just warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 3) allow interleaving to be supported by the agent, >> based on the '#interleave' capability, >> and also warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 4) require interleaving MUST NOT be supported by the agent >> - what happens when the manager sends an anyway? >> a) close session >> b) ignore request >> c) send operation-failed response >> >> What are the benefits? >> >> There obvious benefit from allowing interleaving, >> if you believe sessions are expensive -- it saves an extra session >> on both the manager and the agent. >> >> The real benefit is that is a the cleanest way >> to terminate sessions, and it should be used in all modes. >> The and drop connection methods are both bad ideas. >> >> It would also be a HUGE CLR to forbid interleaving completely. >> In the future, some new feature will come up that will make it >> clear the agent should never be in a mode it MUST stop listening >> to all input from the client. It will be clear then (if not now) >> that this is a really bad idea. >> >> So what are the benefits of forbidding interleaving completely, >> and what happens if the manager sends an anyway? >> >> >>> I submitted the same comment as Dave in trac, but it seems that there >>> is no email about updates to trac issues. >>> >>> 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 Wed Aug 01 12:21:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGxE-0003nj-VH for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 12:21:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGGxD-0002r6-HQ for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 12:21:44 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGGqV-00042K-0K for netconf-data@psg.com; Wed, 01 Aug 2007 16:14: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.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 1IGGqA-00040B-SA for netconf@ops.ietf.org; Wed, 01 Aug 2007 16:14:33 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070801161425b1200dcep0e>; Wed, 1 Aug 2007 16:14:26 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Balazs Lengyel'" Cc: , References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> <46AEE888.5000405@ericsson.com> <46B09F61.6060005@andybierman.com> Subject: interleaving Date: Wed, 1 Aug 2007 12:14:14 -0400 Message-ID: <007f01c7d457$0e390690$6702a8c0@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: <46B09F61.6060005@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcfUTVLLDkc9c5KRSdqQKjcKT2N57gABkkfw Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi, (Andy, do you plan to put interleaving into trac?) For what it's worth, ISMS supports interleaving over its SSH connections; the tunnel is a tunnel, and traffic is traffic. If an operator prefers to NOT interleave the ISMS traffic, for example to ensure notifications aren't held up by large response messages, they can configure their notifications to go over a different SSH session by specifying a different port in the TARGET-MIB. ISMS doesn't have subscriptions and replay and other niceties as an extension of the protocol; in SNMP such things would be handled through data model manipulations rather than protocol extensions. 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: Wednesday, August 01, 2007 10:58 AM > To: Balazs Lengyel > Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org > Subject: Re: [Netconf] #9: notification replay in the future > > Balazs Lengyel wrote: > > Hello, > > I vote for MUST NOT. Why complicate things. Will it bring > us anything? > > > > Things are complicated either way. > First, what are the choices? > > 1) require interleaving MUST be supported by the agent > 2) allow interleaving to be supported by the agent, > but just warn that the manager SHOULD NOT interleave > and the agent MAY NOT accept interleaved requests. > 3) allow interleaving to be supported by the agent, > based on the '#interleave' capability, > and also warn that the manager SHOULD NOT interleave > and the agent MAY NOT accept interleaved requests. > 4) require interleaving MUST NOT be supported by the agent > - what happens when the manager sends an anyway? > a) close session > b) ignore request > c) send operation-failed response > > What are the benefits? > > There obvious benefit from allowing interleaving, > if you believe sessions are expensive -- it saves an extra session > on both the manager and the agent. > > The real benefit is that is a the cleanest way > to terminate sessions, and it should be used in all modes. > The and drop connection methods are both bad ideas. > > It would also be a HUGE CLR to forbid interleaving completely. > In the future, some new feature will come up that will make it > clear the agent should never be in a mode it MUST stop listening > to all input from the client. It will be clear then (if not now) > that this is a really bad idea. > > So what are the benefits of forbidding interleaving completely, > and what happens if the manager sends an anyway? > > > > I submitted the same comment as Dave in trac, but it seems > that there is > > no email about updates to trac issues. > > > > 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: > -- to unsubscribe send a message to netconf-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 Aug 01 13:42: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 1IGID1-0003nx-A2 for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 13:42:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGICz-0004qw-TQ for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 13:42:07 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGI5x-000CYa-8f for netconf-data@psg.com; Wed, 01 Aug 2007 17:34: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=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 1IGI5l-000CXb-To for netconf@ops.ietf.org; Wed, 01 Aug 2007 17:34:43 +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 1IGHa1-00058K-7o; Wed, 01 Aug 2007 19:01:50 +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: Wed, 01 Aug 2007 17:01:49 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #15: interleaving during notification delivery mode X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netconf/trac/ticket/15 Message-ID: <070.2056b840a4a56890c0fa794778ef5bcd@tools.ietf.org> X-Trac-Ticket-ID: 15 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: 0a7aa2e6e558383d84476dc338324fab IzE1OiA8cnBjPiBpbnRlcmxlYXZpbmcgZHVyaW5nIG5vdGlmaWNhdGlvbiBkZWxpdmVyeSBtb2Rl DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBpZXRmQGFuZHliaWVybWFuLmNvbSAg ICAgICAgICAgICB8ICAgICAgIE93bmVyOiAgICAgDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpv ciAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgDQpDb21wb25l bnQ6ICBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uICB8ICAgICBWZXJzaW9uOiAgICAg DQogS2V5d29yZHM6ICBub3RpZmljYXRpb24tMDggICAgICAgICAgICAgICAgICB8ICANCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiBUaGVyZSBhcmUgc29tZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBy ZWxhdGVkDQogdG8gaW50ZXJsZWF2aW5nIG9mIDxycGM+IHJlcXVlc3RzLiAgVGhpcyBtZWFucw0K IHRoYXQgdGhlIGFnZW50IGhhcyBhbHJlYWR5IHByb2Nlc3NlZCB0aGUgPGNyZWF0ZS1zdWJzY3Jp cHRpb24+DQogb3BlcmF0aW9uLCBhbmQgaXMgZGVsaXZlcmluZyBub3RpZmljYXRpb25zLg0KDQog VGhpcyBub3RpZmljYXRpb24gZGVsaXZlcnkgbW9kZSBjb250aW51ZXMgdW50aWwNCiBlaXRoZXIg YSBzdG9wVGltZSBpcyByZWFjaGVkIG9yIHRoZSBzZXNzaW9uIGlzIHRlcm1pbmF0ZWQuDQogSWYg dGhlIHN0b3BUaW1lIGlzIHJlYWNoZWQsIHRoZSBzZXNzaW9uIHJldmVydHMgYmFjayB0bw0KIHRo ZSBub3JtYWwgbW9kZSAoYWNjZXB0aW5nIDxycGM+IHJlcXVlc3RzKS4NCg0KIElzc3VlIGEpIHdo YXQgTVVTVCwgU0hPVUxELCBNQVkgYW4gYWdlbnQgZG8gd2l0aCBpbnB1dA0KIHJlY2VpdmVkIG9u IHRoZSBzZXNzaW9uLCBhZnRlciB0aGUgPGNyZWF0ZS1zdWJzY3JpcHRpb24+IFJQQywNCiB3aGVu IGl0IHRyYW5zaXRpb25zIGJhY2sgdG8gbm9ybWFsIG1vZGU/DQoNCiAtLS0tLS0NCg0KIFRoZSBj dXJyZW50IHByb3Bvc2FsIGlzIHRoYXQgdGhlIHRleHQgd2lsbCBzYXkNCiB0aGUgbWFuYWdlciBT SE9VTEQgTk9UIHNlbmQgPHJwYz4gYWZ0ZXIgcmVxdWVzdGluZw0KIG5vdGlmaWNhdGlvbnMsIGFu ZCB0aGUgYWdlbnQgTUFZIE5PVCBwcm9jZXNzIDxycGM+DQogYWZ0ZXIgaXQgc3RhcnRzIHNlbmRp bmcgbm90aWZpY2F0aW9ucy4NCg0KIC0tLS0tLQ0KDQogY29tbWVudHM6DQoNCiBGaXJzdCwgd2hh dCBhcmUgdGhlIGNob2ljZXM/DQoNCiAgIDEpIHJlcXVpcmUgaW50ZXJsZWF2aW5nIE1VU1QgYmUg c3VwcG9ydGVkIGJ5IHRoZSBhZ2VudA0KICAgMikgYWxsb3cgaW50ZXJsZWF2aW5nIHRvIGJlIHN1 cHBvcnRlZCBieSB0aGUgYWdlbnQsDQogICAgICBidXQganVzdCB3YXJuIHRoYXQgdGhlIG1hbmFn ZXIgU0hPVUxEIE5PVCBpbnRlcmxlYXZlDQogICAgICBhbmQgdGhlIGFnZW50IE1BWSBOT1QgYWNj ZXB0IGludGVybGVhdmVkIHJlcXVlc3RzLg0KICAgMykgYWxsb3cgaW50ZXJsZWF2aW5nIHRvIGJl IHN1cHBvcnRlZCBieSB0aGUgYWdlbnQsDQogICAgICBiYXNlZCBvbiB0aGUgJyNpbnRlcmxlYXZl JyBjYXBhYmlsaXR5LA0KICAgICAgYW5kIGFsc28gd2FybiB0aGF0IHRoZSBtYW5hZ2VyIFNIT1VM RCBOT1QgaW50ZXJsZWF2ZQ0KICAgICAgYW5kIHRoZSBhZ2VudCBNQVkgTk9UIGFjY2VwdCBpbnRl cmxlYXZlZCByZXF1ZXN0cy4NCiAgIDQpIHJlcXVpcmUgaW50ZXJsZWF2aW5nIE1VU1QgTk9UIGJl IHN1cHBvcnRlZCBieSB0aGUgYWdlbnQNCiAgICAgIC0gd2hhdCBoYXBwZW5zIHdoZW4gdGhlIG1h bmFnZXIgc2VuZHMgYW4gPHJwYz4gYW55d2F5Pw0KICAgICAgICBhKSBjbG9zZSBzZXNzaW9uDQog ICAgICAgIGIpIGlnbm9yZSByZXF1ZXN0DQogICAgICAgIGMpIHNlbmQgb3BlcmF0aW9uLWZhaWxl ZCByZXNwb25zZQ0KDQogV2hhdCBhcmUgdGhlIGJlbmVmaXRzPw0KDQogVGhlcmUgb2J2aW91cyBi ZW5lZml0IGZyb20gYWxsb3dpbmcgaW50ZXJsZWF2aW5nLA0KIGlmIHlvdSBiZWxpZXZlIHNlc3Np b25zIGFyZSBleHBlbnNpdmUgLS0gaXQgc2F2ZXMgYW4gZXh0cmEgc2Vzc2lvbg0KIG9uIGJvdGgg dGhlIG1hbmFnZXIgYW5kIHRoZSBhZ2VudC4NCg0KIFRoZSByZWFsIGJlbmVmaXQgaXMgdGhhdCA8 Y2xvc2Utc2Vzc2lvbj4gaXMgYSB0aGUgY2xlYW5lc3Qgd2F5DQogdG8gdGVybWluYXRlIHNlc3Np b25zLCBhbmQgaXQgc2hvdWxkIGJlIHVzZWQgaW4gYWxsIG1vZGVzLg0KIFRoZSA8a2lsbC1zZXNz aW9uPiBhbmQgZHJvcCBjb25uZWN0aW9uIG1ldGhvZHMgYXJlIGJvdGggYmFkIGlkZWFzLg0KDQog SXQgd291bGQgYWxzbyBiZSBhIEhVR0UgQ0xSIHRvIGZvcmJpZCBpbnRlcmxlYXZpbmcgY29tcGxl dGVseS4NCiBJbiB0aGUgZnV0dXJlLCBzb21lIG5ldyBmZWF0dXJlIHdpbGwgY29tZSB1cCB0aGF0 IHdpbGwgbWFrZSBpdA0KIGNsZWFyIHRoZSBhZ2VudCBzaG91bGQgbmV2ZXIgYmUgaW4gYSBtb2Rl IGl0IE1VU1Qgc3RvcCBsaXN0ZW5pbmcNCiB0byBhbGwgaW5wdXQgZnJvbSB0aGUgY2xpZW50LiAg SXQgd2lsbCBiZSBjbGVhciB0aGVuIChpZiBub3Qgbm93KQ0KIHRoYXQgdGhpcyBpcyBhIHJlYWxs eSBiYWQgaWRlYS4NCg0KIFNvIHdoYXQgYXJlIHRoZSBiZW5lZml0cyBvZiBmb3JiaWRkaW5nIGlu dGVybGVhdmluZyBjb21wbGV0ZWx5LA0KIGFuZCB3aGF0IGhhcHBlbnMgaWYgdGhlIG1hbmFnZXIg c2VuZHMgYW4gPHJwYz4gYW55d2F5Pw0KDQotLSANClRpY2tldCBVUkw6IDxodHRwOi8vd3d3My50 b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzE1Pg0KTmV0Y29uZiA8aHR0cDov L3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUg TkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-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 Aug 01 14:06: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 1IGIai-0002Uu-Us for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:06:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGIah-0005b9-NW for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:06:36 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGIUW-000FBs-54 for netconf-data@psg.com; Wed, 01 Aug 2007 18:00:12 +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, DATE_IN_PAST_03_06 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 1IGIUK-000F8z-Iq for netconf@ops.ietf.org; Wed, 01 Aug 2007 18:00:06 +0000 Received: from pc6 (1Cust128.tnt108.lnd4.gbr.da.uu.net [62.188.170.128]) by ranger.systems.pipex.net (Postfix) with SMTP id 9221DE000450 for ; Wed, 1 Aug 2007 18:59:46 +0100 (BST) Message-ID: <023601c7d45c$a393ca40$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: References: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> Subject: Re: [Netconf] #14: notification termination mechanism considered dangerous Date: Wed, 1 Aug 2007 16:47:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: 1.4 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 A different approach would be to make the subscription soft so that it must be refreshed every hour or so and in the absence of a re-subscription, it is closed. Tom Petch ----- Original Message ----- From: "Netconf" Cc: Sent: Wednesday, August 01, 2007 4:47 PM Subject: [Netconf] #14: notification termination mechanism considered dangerous > #14: notification termination mechanism considered dangerous > ---------------------------------------------+------------------------------ > Reporter: ietf@andybierman.com | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-ietf-netconf-notification | Version: > Keywords: notification-08 | > ---------------------------------------------+------------------------------ > There needs to be a safe mechanism to terminate > a session that is in notification delivery mode. > The manager must be able to invoke > in this mode, rather than terminating the > session by other means. > > Currently a manager must start another session, > determine the correct session number the kill, > (don't get that wrong!) and invoke the > operation, then close the new session. > > The current ' method', as the standard mechanism > to terminate notifications, is dangerous. Imagine a unix > program that could only be turned off with a 'kill -9 pid' > command. That is a really dangerous sysadmin practice. > The should be used sparingly, just like > the unix 'kill' command. > > The other standard way to terminate notifications is for > the manager to close the transport connection (unexpectedly > in the agent's POV). This is even worse than > because the agent might (incorrectly) generate event > notifications about a network problem (lost session). > > -- > Ticket URL: > Netconf > Issue tracker for the NETCONF Working Group rzǧuƠz'z ( 笶l_뢸0m؅( rz)ڲ) b欶zˁ^ w&rzm Ȟ+ b?۝\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: From owner-netconf@ops.ietf.org Wed Aug 01 14:18: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 1IGImO-000833-2M for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:18:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGImM-0005qp-SM for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:18:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGIgz-000GWR-D8 for netconf-data@psg.com; Wed, 01 Aug 2007 18:13: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=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 1IGIgo-000GUC-9d for netconf@ops.ietf.org; Wed, 01 Aug 2007 18:12: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 1IGIgm-0002v2-E8; Wed, 01 Aug 2007 20:12: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: Wed, 01 Aug 2007 18:12:52 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #16: notification replay stopTime synch problem X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netconf/trac/ticket/16 Message-ID: <070.c729ac2300cd71183ad674d0d5cfeda1@tools.ietf.org> X-Trac-Ticket-ID: 16 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: ea4ac80f790299f943f0a53be7e1a21a IzE2OiBub3RpZmljYXRpb24gcmVwbGF5IHN0b3BUaW1lIHN5bmNoIHByb2JsZW0NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGlldGZAYW5keWJpZXJtYW4uY29tICAgICAgICAgICAg IHwgICAgICAgT3duZXI6ICAgICANCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICANCkNvbXBvbmVudDogIGRyYWZ0 LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24gIHwgICAgIFZlcnNpb246ICAgICANCiBLZXl3b3Jk czogIG5vdGlmaWNhdGlvbi0wOCAgICAgICAgICAgICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KIEhpLA0KIFRoaXMgd2FzIHJhaXNlZCBvZmZsaW5lIGJ5IFJhbmR5IFByZXN1aG4uDQog VGhlIG1hbmFnZXIgbXVzdCBwcm92aWRlIGEgc3RvcFRpbWUgaWYNCiBpdCB3YW50cyB0byBnZXQg dGhlIGxvZ2dlZCBub3RpZmljYXRpb25zDQogYW5kIHRoZW4gcmV2ZXJ0IHRoZSBzZXNzaW9uIHRv IG5vcm1hbCBtb2RlLg0KDQogSG93ZXZlciwgaXQgaXMgZGlmZmljdWx0IGZvciB0aGUgbWFuYWdl ciBhbmQNCiB0aGUgYWdlbnQgdG8gYmUgaW4gcGVyZmVjdCB0aW1lIHN5bmNoLCBhbmQNCiB0aGUg dmFsdWUgZm9yICdub3cnIGlzIGxpa2VseSB0byBiZSBkaWZmZXJlbnQNCiBvbiBib3RoIHN5c3Rl bXMuDQoNCiBBIHNwZWNpYWwgdmFsdWUgZm9yIHRoZSBzdG9wVGltZSBwYXJhbWV0ZXIgaXMgbmVl ZGVkLA0KICh0aGUgc3RyaW5nICdub3cnKSB0byBpbmRpY2F0ZSB0byB0aGUgYWdlbnQgdGhhdA0K IHRoZSBhZ2VudCBzaG91bGQgZGVyaXZlIHRoZSBhY3R1YWwgc3RvcFRpbWUgdmFsdWUNCiBmcm9t IHRoZSBpdHMgY3VycmVudCBzeXN0ZW0gdGltZS4NCg0KIFRoaXMgaW1wYWN0cyB0aGUgWFNELg0K IEluc3RlYWQgb2YgdGhlICd4czpkYXRlVGltZScgZGF0YSB0eXBlLCB0aGUNCiBzdG9wVGltZSBl bGVtZW50IHdpbGwgbmVlZCBhIG5ldyBkYXRhIHR5cGUNCiB3aGljaCBpcyBhIHVuaW9uIG9mIHRo ZSBmaXhlZCBzdHJpbmcgJ25vdycgYW5kIGEgZGF0ZVRpbWUgc3RyaW5nLg0KDQotLSANClRpY2tl dCBVUkw6IDxodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0 LzE2Pg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJ c3N1ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-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 Aug 01 14:27: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 1IGIul-0005Tu-Bs for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:27:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGIuk-00061m-2o for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:27:19 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGIoY-000HHy-Gl for netconf-data@psg.com; Wed, 01 Aug 2007 18:20: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 [68.142.229.101] (helo=smtp104.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGIoL-000HGf-Rg for netconf@ops.ietf.org; Wed, 01 Aug 2007 18:20:48 +0000 Received: (qmail 28473 invoked from network); 1 Aug 2007 18:20:40 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp104.sbc.mail.re2.yahoo.com with SMTP; 1 Aug 2007 18:20:40 -0000 X-YMail-OSG: cM.OFZAVM1nslDt1QNbcl8yIvJzPYd8jfpsVET6uAPfiSVa05YuF0SmTe343jj.TTz61jANy6esZRhsNCsakpfOG Message-ID: <46B0CEA4.7090007@andybierman.com> Date: Wed, 01 Aug 2007 11:19:16 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" CC: netconf@ops.ietf.org Subject: Re: [Netconf] #14: notification termination mechanism considered dangerous References: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> <023601c7d45c$a393ca40$0601a8c0@pc6> In-Reply-To: <023601c7d45c$a393ca40$0601a8c0@pc6> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b tom.petch wrote: > A different approach would be to make the subscription soft so that it must be > refreshed every hour or so and in the absence of a re-subscription, it is > closed. The NETCONF protocol has no 'refresh' mechanism. The notifications draft has to make it to the finish line without requiring a single edit to RFC 4741. (so far, so good.) One really valid option, raised by Phil, is to just close the session normally (as if the was followed by a ) after replay w/stopTime is complete. Problem solved. The agent never 'sees' any new because the is implicitly ahead of it in the queue. I like this approach the best myself, rather than coming to some technically lame solution, to reach WG consensus, on what to do with any that might have been sent by the manager during replay delivery mode. > > Tom Petch Andy > > > ----- Original Message ----- > From: "Netconf" > Cc: > Sent: Wednesday, August 01, 2007 4:47 PM > Subject: [Netconf] #14: notification termination mechanism considered dangerous > > >> #14: notification termination mechanism considered dangerous >> ---------------------------------------------+------------------------------ >> Reporter: ietf@andybierman.com | Owner: >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-ietf-netconf-notification | Version: >> Keywords: notification-08 | >> ---------------------------------------------+------------------------------ >> There needs to be a safe mechanism to terminate >> a session that is in notification delivery mode. >> The manager must be able to invoke >> in this mode, rather than terminating the >> session by other means. >> >> Currently a manager must start another session, >> determine the correct session number the kill, >> (don't get that wrong!) and invoke the >> operation, then close the new session. >> >> The current ' method', as the standard mechanism >> to terminate notifications, is dangerous. Imagine a unix >> program that could only be turned off with a 'kill -9 pid' >> command. That is a really dangerous sysadmin practice. >> The should be used sparingly, just like >> the unix 'kill' command. >> >> The other standard way to terminate notifications is for >> the manager to close the transport connection (unexpectedly >> in the agent's POV). This is even worse than >> because the agent might (incorrectly) generate event >> notifications about a network problem (lost session). >> >> -- >> Ticket URL: >> Netconf >> Issue tracker for the NETCONF Working Group rzǧuƠz'z ( 笶l_뢸0m؅( rz)ڲ) b欶zˁ^ > w&rzm Ȟ+ b?۝\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 Wed Aug 01 14:31: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 1IGIyy-0001x4-8T for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:31:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGIyx-0006Dz-1F for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 14:31:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGItM-000HkK-Nu for netconf-data@psg.com; Wed, 01 Aug 2007 18:25: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.229.97] (helo=smtp108.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGItB-000HjE-Uv for netconf@ops.ietf.org; Wed, 01 Aug 2007 18:25:47 +0000 Received: (qmail 49694 invoked from network); 1 Aug 2007 18:25:41 -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; 1 Aug 2007 18:25:41 -0000 X-YMail-OSG: rRq493MVM1kD.Unw3cX__k6oh66585MJ7JmLPY3FeYTLn0p8 Message-ID: <46B0CFD1.6020609@andybierman.com> Date: Wed, 01 Aug 2007 11:24:17 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Partain , Henrik Levkowetz CC: "Netconf (E-mail)" Subject: tracker version field 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: d6b246023072368de71562c0ab503126 Hi, How do we change the fixed labels on the version field? Does it have to be a fixed field? The 'new ticket' form gives an option of 1.0' and '2.0'. The real choice is -08, since this is an Internet draft, not a C source file. Can we get the numbering changed, so the version field shows the current I-D version if the component is an I-D? Or just a string? thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 01 15:42: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 1IGK5m-0006cF-WB for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 15:42:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGK5l-00007B-Ka for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 15:42:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGJy5-0003L3-Vo for netconf-data@psg.com; Wed, 01 Aug 2007 19:34: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 [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGJxu-0003KF-BZ for netconf@ops.ietf.org; Wed, 01 Aug 2007 19:34:44 +0000 Received: from localhost (h217n1c1o851.bredband.skanova.com [81.225.32.217]) by mail.tail-f.com (Postfix) with ESMTP id 8E4461B80C3 for ; Wed, 1 Aug 2007 21:34:34 +0200 (CEST) Date: Wed, 01 Aug 2007 21:34:22 +0200 (CEST) Message-Id: <20070801.213422.77686746.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: Re: [Netconf] #15: interleaving during notification delivery mode From: Martin Bjorklund In-Reply-To: <070.2056b840a4a56890c0fa794778ef5bcd@tools.ietf.org> References: <070.2056b840a4a56890c0fa794778ef5bcd@tools.ietf.org> 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.7 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac "Netconf" wrote: > #15: interleaving during notification delivery mode > ---------------------------------------------+------------------------------ > Reporter: ietf@andybierman.com | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-ietf-netconf-notification | Version: > Keywords: notification-08 | > ---------------------------------------------+------------------------------ > There are some interoperability issues related > to interleaving of requests. This means > that the agent has already processed the > operation, and is delivering notifications. > > This notification delivery mode continues until > either a stopTime is reached or the session is terminated. > If the stopTime is reached, the session reverts back to > the normal mode (accepting requests). > > Issue a) what MUST, SHOULD, MAY an agent do with input > received on the session, after the RPC, > when it transitions back to normal mode? > > ------ > > The current proposal is that the text will say > the manager SHOULD NOT send after requesting > notifications, and the agent MAY NOT process > after it starts sending notifications. > > ------ > > comments: > > First, what are the choices? > > 1) require interleaving MUST be supported by the agent > 2) allow interleaving to be supported by the agent, > but just warn that the manager SHOULD NOT interleave > and the agent MAY NOT accept interleaved requests. > 3) allow interleaving to be supported by the agent, > based on the '#interleave' capability, > and also warn that the manager SHOULD NOT interleave > and the agent MAY NOT accept interleaved requests. > 4) require interleaving MUST NOT be supported by the agent > - what happens when the manager sends an anyway? > a) close session > b) ignore request > c) send operation-failed response > > What are the benefits? > > There obvious benefit from allowing interleaving, > if you believe sessions are expensive -- it saves an extra session > on both the manager and the agent. > > The real benefit is that is a the cleanest way > to terminate sessions, and it should be used in all modes. > The and drop connection methods are both bad ideas. I agree to this. And another benefit is that we would have one single way all agents will behave, no extra capabilities or anything. A manager will know how things work. So, if I recall correctly, it was Andy and Phil that were most vocal against interleaving in Monteral. But I might remember wrong. Andy now seems to think interleaving is ok. We also know that there are at least two implementations that support interleaving currently. So can the WG agree to make interleaving the only option? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 01 16:26: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 1IGKlo-0006Is-C2 for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 16:26:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGKlm-00015i-K0 for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 16:26:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGKfg-0007xk-Pe for netconf-data@psg.com; Wed, 01 Aug 2007 20:19: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 [68.142.229.92] (helo=smtp113.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGKfV-0007vr-Ew for netconf@ops.ietf.org; Wed, 01 Aug 2007 20:19:47 +0000 Received: (qmail 2862 invoked from network); 1 Aug 2007 20:19:38 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp113.sbc.mail.re2.yahoo.com with SMTP; 1 Aug 2007 20:19:38 -0000 X-YMail-OSG: BPlZdlAVM1mbb7_rFvW844lqAjmpBphiEKT2HJxqJxJxEV43mKEkp1y6Q1RNrByRqOw- Message-ID: <46B0EA85.3050107@andybierman.com> Date: Wed, 01 Aug 2007 13:18:13 -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: [Netconf] #15: interleaving during notification delivery mode References: <070.2056b840a4a56890c0fa794778ef5bcd@tools.ietf.org> <20070801.213422.77686746.mbj@tail-f.com> In-Reply-To: <20070801.213422.77686746.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: 932cba6e0228cc603da43d861a7e09d8 Hi Martin, I do not want to forbid interleaving, but I also want a capability to control it in an inter-operable manner. I want the RPC to be an exception that must be supported by every agent. We need a couple pictures to clear things up in our discussions: Use Case 1) No replay mode (interval (B) is zero) Replay mode, with no stopTime t(0) t(1) t(2) t(3) | (A) | (B) | (C) | -------+-----------+-------------+---------------------+ normal | | replay mode | live mode | mode At time t(0) the is received. At time t(1) notification delivery starts. There may be replay notifications to deliver first, which ceases at time t(2), when live notification delivery starts, and continues to time t(3) when the session is terminated. --> Issue: An agent could possibly receive new requests any time during time intervals (A), (B), and (C). What MUST, SHOULD, MAY be done with them =============================================== Use Case 2) Replay mode, with a stopTime t(0) t(1) t(2) t(3) | (A) | (B) | (C) | -------+-----------+-------------+-------------------+ normal | | replay mode | normal mode | mode At time t(0) the is received. At time t(1) notification delivery starts. The replay notifications are delivered during time interval (B). When the replay is complete at time t(2), the agent reverts to normal mode, and continues accepting requests until the session is terminated at time t(3). --> Issue: An agent could possibly receive new requests any time during time intervals (A) and (B). What MUST, SHOULD, MAY be done with them during interval (B)? What MUST, SHOULD, MAY be done with them at time t(2)? --> Issue: Should the agent automatically terminate the session for use case 2 at time t(2)? What MUST, SHOULD, MAY language is needed? > "Netconf" wrote: >> #15: interleaving during notification delivery mode >> ---------------------------------------------+------------------------------ >> Reporter: ietf@andybierman.com | Owner: >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-ietf-netconf-notification | Version: >> Keywords: notification-08 | >> ---------------------------------------------+------------------------------ >> There are some interoperability issues related >> to interleaving of requests. This means >> that the agent has already processed the >> operation, and is delivering notifications. >> >> This notification delivery mode continues until >> either a stopTime is reached or the session is terminated. >> If the stopTime is reached, the session reverts back to >> the normal mode (accepting requests). >> >> Issue a) what MUST, SHOULD, MAY an agent do with input >> received on the session, after the RPC, >> when it transitions back to normal mode? >> >> ------ >> >> The current proposal is that the text will say >> the manager SHOULD NOT send after requesting >> notifications, and the agent MAY NOT process >> after it starts sending notifications. >> >> ------ >> >> comments: >> >> First, what are the choices? >> >> 1) require interleaving MUST be supported by the agent >> 2) allow interleaving to be supported by the agent, >> but just warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 3) allow interleaving to be supported by the agent, >> based on the '#interleave' capability, >> and also warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 4) require interleaving MUST NOT be supported by the agent >> - what happens when the manager sends an anyway? >> a) close session >> b) ignore request >> c) send operation-failed response >> >> What are the benefits? >> >> There obvious benefit from allowing interleaving, >> if you believe sessions are expensive -- it saves an extra session >> on both the manager and the agent. >> >> The real benefit is that is a the cleanest way >> to terminate sessions, and it should be used in all modes. >> The and drop connection methods are both bad ideas. > > I agree to this. And another benefit is that we would have one single > way all agents will behave, no extra capabilities or anything. A > manager will know how things work. > > So, if I recall correctly, it was Andy and Phil that were most vocal > against interleaving in Monteral. But I might remember wrong. Andy > now seems to think interleaving is ok. We also know that there are at > least two implementations that support interleaving currently. So can > the WG agree to make interleaving the only option? > > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 01 17:23: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 1IGLfg-00032x-Ns for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 17:23:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGLff-0002Q6-Gl for netconf-archive@lists.ietf.org; Wed, 01 Aug 2007 17:23:56 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGLZ9-000DbX-Eb for netconf-data@psg.com; Wed, 01 Aug 2007 21:17: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 [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGLYy-000Daa-Jo for netconf@ops.ietf.org; Wed, 01 Aug 2007 21:17:06 +0000 Received: from localhost (h217n1c1o851.bredband.skanova.com [81.225.32.217]) by mail.tail-f.com (Postfix) with ESMTP id 0E4CF1B80C3; Wed, 1 Aug 2007 23:16:59 +0200 (CEST) Date: Wed, 01 Aug 2007 23:16:58 +0200 (CEST) Message-Id: <20070801.231658.257682174.mbj@tail-f.com> To: ietf@andybierman.com Cc: balazs.lengyel@ericsson.com, dbharrington@comcast.net, trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future From: Martin Bjorklund In-Reply-To: <46B0A795.7030802@andybierman.com> References: <46B09F61.6060005@andybierman.com> <46B0A0D9.6000307@ericsson.com> <46B0A795.7030802@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.7 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Andy Bierman wrote: > Balazs Lengyel wrote: > > Hello Andy, > > My mail was about replay in the future not interleaving. There I vote > > for "the client MUST NOT" support replay in the future. > > And yes interleaving is complicated. > > IMO, there is WG consensus that startTime in the future MUST be > an error. The alternative is to rewrite major portions of > the document to support a 'cron' like feature, added at the > last minute. I don't know about WG consensus, but I think it's a good idea to forbid a startTime in the future, to make things simpler. /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 Aug 02 04:11: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 1IGVmP-0006Fb-Un for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 04:11:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGVmP-0007pe-5N for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 04:11:33 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGVXe-000Ffu-Tl for netconf-data@psg.com; Thu, 02 Aug 2007 07:56: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 [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGVXS-000FeE-Iu for netconf@ops.ietf.org; Thu, 02 Aug 2007 07:56:13 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2EB6F21448; Thu, 2 Aug 2007 09:56:04 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-aa-46b18e14b0db Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 01F6B20087; Thu, 2 Aug 2007 09:56:04 +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, 2 Aug 2007 09:56:03 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 09:56:03 +0200 Message-ID: <46B18E12.4000802@ericsson.com> Date: Thu, 02 Aug 2007 09:56:02 +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: [Netconf] #14: notification termination mechanism considered dangerous References: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> <023601c7d45c$a393ca40$0601a8c0@pc6> <46B0CEA4.7090007@andybierman.com> In-Reply-To: <46B0CEA4.7090007@andybierman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Aug 2007 07:56:03.0331 (UTC) FILETIME=[92BF2D30:01C7D4DA] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Hello, How does this handle the case when you want to close the notification session before stopTime or in the absence of stopTime ? As I understand the agent might not read anything until stopTime. Balazs Andy Bierman wrote: > tom.petch wrote: >> A different approach would be to make the subscription soft so that it >> must be >> refreshed every hour or so and in the absence of a re-subscription, it is >> closed. > > The NETCONF protocol has no 'refresh' mechanism. > The notifications draft has to make it to the > finish line without requiring a single edit to RFC 4741. > (so far, so good.) > > One really valid option, raised by Phil, is to just > close the session normally (as if the > was followed by a ) after replay w/stopTime is > complete. Problem solved. The agent never 'sees' any new > because the is implicitly ahead of it in the queue. > > I like this approach the best myself, rather than coming > to some technically lame solution, to reach WG consensus, > on what to do with any that might have been sent > by the manager during replay delivery mode. > >> >> Tom Petch > > Andy > >> >> >> ----- Original Message ----- >> From: "Netconf" >> Cc: >> Sent: Wednesday, August 01, 2007 4:47 PM >> Subject: [Netconf] #14: notification termination mechanism considered >> dangerous >> >> >>> #14: notification termination mechanism considered dangerous >>> ---------------------------------------------+------------------------------ >>> >>> Reporter: ietf@andybierman.com | Owner: >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: draft-ietf-netconf-notification | Version: >>> Keywords: notification-08 | >>> ---------------------------------------------+------------------------------ >>> >>> There needs to be a safe mechanism to terminate >>> a session that is in notification delivery mode. >>> The manager must be able to invoke >>> in this mode, rather than terminating the >>> session by other means. >>> >>> Currently a manager must start another session, >>> determine the correct session number the kill, >>> (don't get that wrong!) and invoke the >>> operation, then close the new session. >>> >>> The current ' method', as the standard mechanism >>> to terminate notifications, is dangerous. Imagine a unix >>> program that could only be turned off with a 'kill -9 pid' >>> command. That is a really dangerous sysadmin practice. >>> The should be used sparingly, just like >>> the unix 'kill' command. >>> >>> The other standard way to terminate notifications is for >>> the manager to close the transport connection (unexpectedly >>> in the agent's POV). This is even worse than >>> because the agent might (incorrectly) generate event >>> notifications about a network problem (lost session). >>> >>> -- >>> Ticket URL: >>> Netconf >>> Issue tracker for the NETCONF Working Group rzǧuƠz'z ( 笶l_뢸0m؅ >>> ( rz)ڲ) b欶zˁ^ >> w&rzm Ȟ+ b?۝\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 Thu Aug 02 04:41: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 1IGWF0-0004Mf-Ts for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 04:41:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGWEz-00009U-VI for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 04:41:06 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGW2B-000IKg-Er for netconf-data@psg.com; Thu, 02 Aug 2007 08: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [203.200.1.48] (helo=mail.tataelxsi.co.in) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGW1z-000IJo-T2 for netconf@ops.ietf.org; Thu, 02 Aug 2007 08:27:45 +0000 Received: from shilpab (59.160.207.5.ill-bgl.static.vsnl.net.in [59.160.207.5] (may be forged)) by mail.tataelxsi.co.in (MOS 3.8.4-GA) with ESMTP id ACD58055 (AUTH shilpab); Thu, 2 Aug 2007 13:57:34 +0530 (IST) Reply-To: Shilpa Jayantilal Bharkhada From: Shilpa Jayantilal Bharkhada To: Subject: Clarification in implementing netconf over ssh Date: Thu, 2 Aug 2007 13:59:21 +0530 Message-ID: <007201c7d4df$3aabed90$a021320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090205.46B19576.019E,ss=1,fgs=0, ip=59.160.207.5, so=2007-03-13 10:31:19, dmn=5.3.14/2007-05-31 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi All, Just wanted one more clarification for this if you could help. Both the client and agent code are written in java and JSCH is the ssh client api that we are using. Steps followed : Initially we are establishing one ssh session and creating a channel of type "subsystem" with that session object and connecting to the server which will start the subsystem.(so netconf agent will be listening on port 830) Then we are creating a channel of type "direct-tcpip" with the same ssh session object and we are setting the inputstream of channel as fileinputstream(request.xml) ,outputstream of that channel as fileoutputstream(response.xml) and port as 830. This works fine for a single client. The problem comes when we go for multiple client connecting to a single server. Through the "direct-tcpip" channel contents of the request.xml file is reaching the server side and netconf agent program was able to parse the request and produce the response.But when the agent program sends the response back through its standard output stream the response contents are always reaching the outputsream of the first client which connected to it. Is it a right way of doing it and please let me know how to proceed. Any help in this regards from others will also be appreciated. Regards, Shilpa -- to unsubscribe send a message to netconf-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 Aug 02 10:01:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbFO-00005o-3I for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 10:01:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGbFM-0000TC-SC for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 10:01:50 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGb4e-0003eP-GQ for netconf-data@psg.com; Thu, 02 Aug 2007 13:50: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 [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGb4S-0003dX-TM for netconf@ops.ietf.org; Thu, 02 Aug 2007 13:50:39 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C1DB209FD; Thu, 2 Aug 2007 15:50:30 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-95-46b1e126c7e5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 60A64520002; Thu, 2 Aug 2007 15:50:30 +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, 2 Aug 2007 15:50:30 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 15:50:30 +0200 Message-ID: <46B1E125.3090603@ericsson.com> Date: Thu, 02 Aug 2007 15:50:29 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund CC: ietf@andybierman.com, dbharrington@comcast.net, trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <46B09F61.6060005@andybierman.com> <46B0A0D9.6000307@ericsson.com> <46B0A795.7030802@andybierman.com> <20070801.231658.257682174.mbj@tail-f.com> In-Reply-To: <20070801.231658.257682174.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2007 13:50:30.0104 (UTC) FILETIME=[16BB3580:01C7D50C] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hello, I proposed the simple rules: 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. I think Andy's special value NOW for stopTime is a good idea. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello Andy, >>> My mail was about replay in the future not interleaving. There I vote >>> for "the client MUST NOT" support replay in the future. >>> And yes interleaving is complicated. >> IMO, there is WG consensus that startTime in the future MUST be >> an error. The alternative is to rewrite major portions of >> the document to support a 'cron' like feature, added at the >> last minute. > > I don't know about WG consensus, but I think it's a good idea to > forbid a startTime in the future, to make things simpler. > > > /martin -- 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 Aug 02 14:07: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 1IGf5I-0004Ud-PF for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 14:07:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGf5H-0006nZ-Er for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 14:07:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGexV-0002fP-0M for netconf-data@psg.com; Thu, 02 Aug 2007 17:59: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=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 1IGexK-0002ej-9r for netconf@ops.ietf.org; Thu, 02 Aug 2007 17:59:31 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 02 Aug 2007 10:59:26 -0700 X-IronPort-AV: i="4.19,214,1183359600"; d="scan'208"; a="48592401:sNHT30817098" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l72HxOO80328; Thu, 2 Aug 2007 10:59:24 -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 l72HxGTp068240; Thu, 2 Aug 2007 13:59:19 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200708021759.l72HxGTp068240@idle.juniper.net> To: Balazs Lengyel cc: Martin Bjorklund , ietf@andybierman.com, dbharrington@comcast.net, trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future In-Reply-To: Your message of "Thu, 02 Aug 2007 15:50:29 +0200." <46B1E125.3090603@ericsson.com> Date: Thu, 02 Aug 2007 13:59:16 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Balazs Lengyel writes: >I think Andy's special value NOW for stopTime is a good idea. IMHO it's generally better to make a new element than to overload an existing one. In JUNOS, we use the element to indicate that we match on only recorded messages, ending the RPC as soon as we see the end of recorded messages. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 02 14:18: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 1IGfFR-0007Dp-3z for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 14:18:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGfFP-00072b-Th for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 14:18:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGf9c-0003mt-2L for netconf-data@psg.com; Thu, 02 Aug 2007 18:12: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=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 1IGf9R-0003m3-67 for netconf@ops.ietf.org; Thu, 02 Aug 2007 18:12:02 +0000 Received: (qmail 17553 invoked from network); 2 Aug 2007 18:11:56 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp109.sbc.mail.re2.yahoo.com with SMTP; 2 Aug 2007 18:11:56 -0000 X-YMail-OSG: hw8djkUVM1kzTBTkTG6IQZz359TlIauNVSqXvC6XWZRbtl72 Message-ID: <46B21E18.40301@andybierman.com> Date: Thu, 02 Aug 2007 11:10:32 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Phil Shafer CC: Balazs Lengyel , Martin Bjorklund , dbharrington@comcast.net, trac@tools.ietf.org, netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <200708021759.l72HxGTp068240@idle.juniper.net> In-Reply-To: <200708021759.l72HxGTp068240@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: bb8f917bb6b8da28fc948aeffb74aa17 Phil Shafer wrote: > Balazs Lengyel writes: >> I think Andy's special value NOW for stopTime is a good idea. > > IMHO it's generally better to make a new element than to > overload an existing one. In JUNOS, we use the > element to indicate that we match on only recorded messages, > ending the RPC as soon as we see the end of recorded messages. > But our data model doesn't work that way (yet). This doesn't affect the startTime. Wouldn't the flag match everything in the notification log? What if the RPC used a 'choice' instead of a 'union' for this parameter? A choice of or can be used. If the choice is used, the agent will generate the from the current system time. We ruled that the element was part of the notification data model, just 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 Thu Aug 02 16:46: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 1IGhZH-0003jV-U4 for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 16:46:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGhZG-0002A7-Kq for netconf-archive@lists.ietf.org; Thu, 02 Aug 2007 16:46:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGhT1-000HXN-MN for netconf-data@psg.com; Thu, 02 Aug 2007 20:40: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 [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 1IFsDX-000HEC-NB for netconf@ops.ietf.org; Tue, 31 Jul 2007 13:57:01 +0000 Received: from localhost ([127.0.0.1] helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IFsCx-0005KV-Eg; Tue, 31 Jul 2007 15:56:19 +0200 Message-ID: <46AF3F82.90403@levkowetz.com> Date: Tue, 31 Jul 2007 08:56:18 -0500 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: David B Harrington CC: 'Balazs Lengyel' , 'Andy Bierman' , 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> In-Reply-To: <011d01c7d356$004ad1a0$0600a8c0@china.huawei.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dbharrington@comcast.net, balazs.lengyel@ericsson.com, ietf@andybierman.com, trac@tools.ietf.org, netconf@ops.ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com 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: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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? Regards, Henrik 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 Fri Aug 03 08:11:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGw0I-00084N-GG for netconf-archive@lists.ietf.org; Fri, 03 Aug 2007 08:11:38 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGw0H-0000P6-U2 for netconf-archive@lists.ietf.org; Fri, 03 Aug 2007 08:11:38 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGvrI-00037A-R9 for netconf-data@psg.com; Fri, 03 Aug 2007 12:02: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 [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 1IGvqy-00033r-NA for netconf@ops.ietf.org; Fri, 03 Aug 2007 12:02:09 +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 l73C1uu18127 for ; Fri, 3 Aug 2007 12:01:56 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: Issue 75 - namespace prefix in source versus in other schema Date: Fri, 3 Aug 2007 08:01:55 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4103774D9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 75 - namespace prefix in source versus in other schema Thread-Index: AcfVxhXYRmI+8hRNRqi5nCh9RuO21g== From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi I'm make decent progress on the update, but there are a few issues that remain unresolved. Here is one where I think what is in the current version needs no modification. Two points here. First off, I think readability is served by meaningful names, not short cryptic ones. Second, I think the design pattern we are using is fine. 4. (and 3.4).: This XSD assigns the default namespace to the target namespace: xmlns=3D"urn:ietf:params:netconf:capability:notification:1.0" However, the XSD in 3.4 does not use a default namespace at all: xmlns:manageEvent=3D"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). Here are the headers from the various places for comparison: Section 3.4 Section 4 RFC 4741 http://www.w3.org/2001/XMLSchema.xsd 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 Fri Aug 03 09:42:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGxQC-0002Us-8Q for netconf-archive@lists.ietf.org; Fri, 03 Aug 2007 09:42:28 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGxQB-0002vY-N2 for netconf-archive@lists.ietf.org; Fri, 03 Aug 2007 09:42:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGxIc-000Ash-VB for netconf-data@psg.com; Fri, 03 Aug 2007 13:34: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.229.91] (helo=smtp114.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IGxIR-000Arg-CD for netconf@ops.ietf.org; Fri, 03 Aug 2007 13:34:33 +0000 Received: (qmail 31031 invoked from network); 3 Aug 2007 13:34:26 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp114.sbc.mail.re2.yahoo.com with SMTP; 3 Aug 2007 13:34:26 -0000 X-YMail-OSG: nJ41tUwVM1ls1aWdTZ_BGEBojLZKfW9pUrujIwvCKZgaCrNgp49e_MxFR5d2sgPQ_jts6i94UwQ_Mp0EeozV2HTlLRUb8o.x3KS8_Hw0Lt1qfq7iN.7Xojg6u5NwIMFX Message-ID: <46B32E8D.7020103@andybierman.com> Date: Fri, 03 Aug 2007 06:33:01 -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: Issue 75 - namespace prefix in source versus in other schema References: <713043CE8B8E1348AF3C546DBE02C1B4103774D9@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4103774D9@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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Sharon Chisholm wrote: > Hi > > I'm make decent progress on the update, but there are a few issues that > remain unresolved. Here is one where I think what is in the current > version needs no modification. Two points here. First off, I think > readability is served by meaningful names, not short cryptic ones. > Second, I think the design pattern we are using is fine. > If you think making XML as verbose as possible serves readability, then we disagree and what readability means. Since very few people actually attempt to read the XSD anyway, maybe it doesn't matter. The URI string used for the NAMESPACE IDENTIFIER is not the same format as the URI string used for the CAPABILITY IDENTIFIER. These are 2 different URI formats, as identified in RFC 4741. Andy > > 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). > > > Here are the headers from the various places for comparison: > > Section 3.4 > > > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:ncEvent="urn:ietf:params:netconf:capability:notification:1.0" > xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification" > targetNamespace="urn:ietf:params:xml:ns:netmod:notification" > elementFormDefault="qualified" > attributeFormDefault="unqualified" > xml:lang="en" version="1.0"> > > Section 4 > > > xmlns="urn:ietf:params:netconf:capability:notification:1.0" > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" > targetNamespace= > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd" > elementFormDefault="qualified" > attributeFormDefault="unqualified" > xml:lang="en"> > > RFC 4741 > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0" > elementFormDefault="qualified" > attributeFormDefault="unqualified" > xml:lang="en"> > > http://www.w3.org/2001/XMLSchema.xsd > > blockDefault="#all" elementFormDefault="qualified" version="1.0" > xml:lang="EN"> > > Sharon Chisholm > Nortel > 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: > > -- to unsubscribe send a message to netconf-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 Aug 06 19:47:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IICIV-0004hX-4G for netconf-archive@lists.ietf.org; Mon, 06 Aug 2007 19:47:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IICIT-0006r5-Px for netconf-archive@lists.ietf.org; Mon, 06 Aug 2007 19:47:39 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIC9M-000OP5-3s for netconf-data@psg.com; Mon, 06 Aug 2007 23:38:12 +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 1IIC9A-000OOK-Pw for netconf@ops.ietf.org; Mon, 06 Aug 2007 23:38:06 +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 1IIC97-0007Tq-M6; Tue, 07 Aug 2007 01:37:57 +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, 06 Aug 2007 23:37:57 -0000 Reply-To: netconf@ops.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://www3.tools.ietf.org/wg/netconf/trac/ticket/9#comment:2 Message-ID: <079.36ac35193ecab8b39506b14d2e8a4ade@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, schishol@nortel.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 Izk6IG5vdGlmaWNhdGlvbiByZXBsYXkgaW4gdGhlIGZ1dHVyZQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICBSZXBvcnRlcjogIGlldGZAYW5keWJpZXJtYW4uY29tICAgICAgICAgICAgIHwgICAgICAg T3duZXI6ICAgICAgICAgICAgICAgICAgICAgDQogICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldyAgICAgICAgICAgICAgICANCiAg UHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25l OiAgICAgICAgICAgICAgICAgICAgIA0KIENvbXBvbmVudDogIGRyYWZ0LWlldGYtbmV0Y29uZi1u b3RpZmljYXRpb24gIHwgICAgIFZlcnNpb246ICAgICAgICAgICAgICAgICAgICAgDQpSZXNvbHV0 aW9uOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBLZXl3b3JkczogIG5v dGlmaWNhdGlvbiByZXBsYXkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNvbW1lbnQgKGJ5IHNjaGlz aG9sQG5vcnRlbC5jb20pOg0KDQogVGhlIHdvcmtpbmcgZ3JvdXAgcHJldmlvdXNseSBkaXNjdXNz ZWQgYW5kIGRlY2lkZWQgdGhhdCByZXBsYXkgaW4gdGhlDQogZnV0dXJlIHdhcyBhIHVzZWZ1bCBm ZWF0dXJlLiBUaGlzIHVzZWZ1bG5lc3Mgd2FzIGNvbmZpcm1lZCBpbiBvZmZsaW5lDQogZGlzY3Vz c2lvbnMgaW4gQ2hpY2Fnby4gVGhlIG9ubHkgaXNzdWVzIHdhcyB0aGF0IHRoZSBuYW1lIG5vIGxv bmdlciBmaXQuDQogV2hlcmUgZG9lcyB0aGlzIGNvbWUgZnJvbT8NCg0KLS0gDQpUaWNrZXQgVVJM OiA8aHR0cDovL3d3dzMudG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFjL3RpY2tldC85I2Nv bW1lbnQ6Mj4NCk5ldGNvbmYgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMv Pg0KSXNzdWUgdHJhY2tlciBmb3IgdGhlIE5FVENPTkYgV29ya2luZyBHcm91cA== -- to unsubscribe send a message to netconf-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 Aug 06 21:03: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 1IIDTS-0003AC-Aa for netconf-archive@lists.ietf.org; Mon, 06 Aug 2007 21:03:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIDTR-00082v-SM for netconf-archive@lists.ietf.org; Mon, 06 Aug 2007 21:03:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIDKX-0004ck-2o for netconf-data@psg.com; Tue, 07 Aug 2007 00:53: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 [68.142.229.94] (helo=smtp111.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIDKL-0004bB-OA for netconf@ops.ietf.org; Tue, 07 Aug 2007 00:53:43 +0000 Received: (qmail 54096 invoked from network); 7 Aug 2007 00:53:37 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp111.sbc.mail.re2.yahoo.com with SMTP; 7 Aug 2007 00:53:36 -0000 X-YMail-OSG: 8KCb1mQVM1kSwQSCpNN1EmokEW9Nu7mbe2S5omoguiUFewmv Message-ID: <46B7C239.8080506@andybierman.com> Date: Mon, 06 Aug 2007 17:52:09 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <079.36ac35193ecab8b39506b14d2e8a4ade@tools.ietf.org> In-Reply-To: <079.36ac35193ecab8b39506b14d2e8a4ade@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: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Netconf wrote: > #9: notification replay in the future > ----------------------------------------------+----------------------------- > Reporter: ietf@andybierman.com | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-ietf-netconf-notification | Version: > Resolution: | Keywords: notification replay > ----------------------------------------------+----------------------------- > Comment (by schishol@nortel.com): > > The working group previously discussed and decided that replay in the > future was a useful feature. This usefulness was confirmed in offline > discussions in Chicago. The only issues was that the name no longer fit. > Where does this come from? > The issue was not really understood before the latest WG meeting. - There is concern that this is a different feature than getting notifications from the internal notification log, and turning into something more like the 'cron' or 'at' command. - There is a concern that this forces the agent to treat notifications in the future as if they were replayed. - There is confusion about when to send the notification. Is is sent after the last buffered notification (at the time the is received) or is it sent after the last live (replayed) notification that occurs around the ? - There is concern that asking for replay notifications that have not happened yet is confusing. - There is concern that this document is already a year late and the extra time it would take to get this new feature correctly documented is not worth the effort. - There is concern that the 'replay in the future' feature is just a by-product of the data model design, and not a real feature at all. There does not seem to be a real use case for this feature. Why wouldn't the manager just wait an hour to send the , rather than say "send me the replay notifications, but wait an hour before starting". Why would the manager tie up a session (which cannot do anything for an hour)? 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 Aug 07 04:34: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 1IIKWp-0005br-Kk for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 04:34:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIKWo-0008A2-5p for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 04:34:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIKM8-0000Vr-Rf for netconf-data@psg.com; Tue, 07 Aug 2007 08:23: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.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 1IIKLw-0000V2-B6 for netconf@ops.ietf.org; Tue, 07 Aug 2007 08:23:51 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A8E4B548069 for ; Tue, 7 Aug 2007 10:23:37 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-4f-46b82c09f056 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 894D7520001 for ; Tue, 7 Aug 2007 10:23:37 +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, 7 Aug 2007 10:23:37 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 10:23:37 +0200 Message-ID: <46B82C08.6010408@ericsson.com> Date: Tue, 07 Aug 2007 10:23:36 +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] #15: interleaving during notification delivery mode References: <070.2056b840a4a56890c0fa794778ef5bcd@tools.ietf.org> <20070801.213422.77686746.mbj@tail-f.com> In-Reply-To: <20070801.213422.77686746.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 08:23:37.0490 (UTC) FILETIME=[40C48F20:01C7D8CC] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Hello, As I remember Phil also complained about that now we have two "modes" of the Netconf session: normal mode and notification mode, when something special happens with incoming requests (e.g. discard them). A big benefit of an interleaving-only solution would be that we do not have this modality. The manager application can still dedicate the session to notifications simply by not sending any RPC. Balazs PS. I wanted interleaving in Montreal. Martin Bjorklund wrote: > "Netconf" wrote: >> #15: interleaving during notification delivery mode >> ---------------------------------------------+------------------------------ >> Reporter: ietf@andybierman.com | Owner: >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-ietf-netconf-notification | Version: >> Keywords: notification-08 | >> ---------------------------------------------+------------------------------ >> There are some interoperability issues related >> to interleaving of requests. This means >> that the agent has already processed the >> operation, and is delivering notifications. >> >> This notification delivery mode continues until >> either a stopTime is reached or the session is terminated. >> If the stopTime is reached, the session reverts back to >> the normal mode (accepting requests). >> >> Issue a) what MUST, SHOULD, MAY an agent do with input >> received on the session, after the RPC, >> when it transitions back to normal mode? >> >> ------ >> >> The current proposal is that the text will say >> the manager SHOULD NOT send after requesting >> notifications, and the agent MAY NOT process >> after it starts sending notifications. >> >> ------ >> >> comments: >> >> First, what are the choices? >> >> 1) require interleaving MUST be supported by the agent >> 2) allow interleaving to be supported by the agent, >> but just warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 3) allow interleaving to be supported by the agent, >> based on the '#interleave' capability, >> and also warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 4) require interleaving MUST NOT be supported by the agent >> - what happens when the manager sends an anyway? >> a) close session >> b) ignore request >> c) send operation-failed response >> >> What are the benefits? >> >> There obvious benefit from allowing interleaving, >> if you believe sessions are expensive -- it saves an extra session >> on both the manager and the agent. >> >> The real benefit is that is a the cleanest way >> to terminate sessions, and it should be used in all modes. >> The and drop connection methods are both bad ideas. > > I agree to this. And another benefit is that we would have one single > way all agents will behave, no extra capabilities or anything. A > manager will know how things work. > > So, if I recall correctly, it was Andy and Phil that were most vocal > against interleaving in Monteral. But I might remember wrong. Andy > now seems to think interleaving is ok. We also know that there are at > least two implementations that support interleaving currently. So can > the WG agree to make interleaving the only option? > > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Aug 07 07:54: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 1IINeI-0004zk-5L for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 07:54:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IINeG-0005Th-Py for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 07:54:54 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IINVT-000GMu-GN for netconf-data@psg.com; Tue, 07 Aug 2007 11:45: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.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 1IINVI-000GMG-Iw for netconf@ops.ietf.org; Tue, 07 Aug 2007 11:45:42 +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 1IINVF-0004fM-QT; Tue, 07 Aug 2007 13:45:33 +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, 07 Aug 2007 11:45:33 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: Re: [Netconf] #2: error-option for test-only X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netconf/trac/ticket/2#comment:1 Message-ID: <079.8be67ca8ab19e6c6a4688e29935d5648@tools.ietf.org> References: <070.9c05e08359345afa247e08ba8ea2fa7c@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <070.9c05e08359345afa247e08ba8ea2fa7c@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mbj@tail-f.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 IzI6IGVycm9yLW9wdGlvbiBmb3IgdGVzdC1vbmx5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIFJl cG9ydGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5jb20gIHwgICAgICAgT3duZXI6ICAgICANCiAgICAg IFR5cGU6ICBlbmhhbmNlbWVudCAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KICBQcmlv cml0eTogIG1pbm9yICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgDQogQ29tcG9u ZW50OiAgUkZDNDc0MSAgICAgICAgICAgICAgIHwgICAgIFZlcnNpb246ICAgICANClJlc29sdXRp b246ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBLZXl3b3JkczogICAgIA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KQ29tbWVudCAoYnkgbWJqQHRhaWwtZi5jb20pOg0KDQogVGhlIHVzZWZ1bGVu c3Mgb2YgdmFsaWRhdGluZyBpbmxpbmUgYW5kIHVybCBjb25maWcgaGFzIGJlZW4gZGlzY3Vzc2Vk IG9uDQogdGhlIGxpc3QgKHNlZQ0KIGh0dHA6Ly9vcHMuaWV0Zi5vcmcvbGlzdHMvbmV0Y29uZi9u ZXRjb25mLjIwMDYvbXNnMDEyMDcuaHRtbCkuICBUaGlzDQogc2hvdWxkIGJlIHJlbW92ZWQgKG9y IGNsYXJpZmllZCkuDQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly93d3czLnRvb2xzLmlldGYu b3JnL3dnL25ldGNvbmYvdHJhYy90aWNrZXQvMiNjb21tZW50OjE+DQpOZXRjb25mIDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvd2cvbmV0Y29uZi90cmFjLz4NCklzc3VlIHRyYWNrZXIgZm9yIHRoZSBO RVRDT05GIFdvcmtpbmcgR3JvdXA= -- to unsubscribe send a message to netconf-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 Aug 07 08:45: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 1IIORX-0000JA-LL for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 08:45:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIORV-00073Y-QY for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 08:45:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIOI4-000NKn-Su for netconf-data@psg.com; Tue, 07 Aug 2007 12:36: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 [68.142.229.93] (helo=smtp112.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIOHt-000NJj-Lb for netconf@ops.ietf.org; Tue, 07 Aug 2007 12:35:55 +0000 Received: (qmail 77256 invoked from network); 7 Aug 2007 12:35:48 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp112.sbc.mail.re2.yahoo.com with SMTP; 7 Aug 2007 12:35:48 -0000 X-YMail-OSG: ek0MPuAVM1ly9s6.sr00_hvrf9IO4gFC8fsv3Qm8UWgD8FQYRwjzU16NvaYCZS9bfNVYK37FIBk8o1sok.bz7cDsFw-- Message-ID: <46B866CC.1020705@andybierman.com> Date: Tue, 07 Aug 2007 05:34:20 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Andy Bierman CC: netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <079.36ac35193ecab8b39506b14d2e8a4ade@tools.ietf.org> <46B7C239.8080506@andybierman.com> In-Reply-To: <46B7C239.8080506@andybierman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Andy Bierman wrote: > Netconf wrote: >> #9: notification replay in the future >> ----------------------------------------------+----------------------------- >> >> Reporter: ietf@andybierman.com | >> Owner: Type: >> defect | Status: new >> Priority: major | >> Milestone: Component: >> draft-ietf-netconf-notification | Version: >> Resolution: | Keywords: >> notification replay >> ----------------------------------------------+----------------------------- >> >> Comment (by schishol@nortel.com): >> >> The working group previously discussed and decided that replay in the >> future was a useful feature. This usefulness was confirmed in offline >> discussions in Chicago. The only issues was that the name no longer fit. >> Where does this come from? >> > I think the issue is what the agent actually does when it gets startTime and/or stopTime in the future. If the agent simply uses these timestamps to determine which notifications CURRENTLY IN ITS REPLAY BUFFER apply to the request. If the manager asks for notifications from time A to time B, (at time C) then the only thing that matters are the notifications in the internal buffer at time C. So asking for replays from the future would immediately return the since there are none in the log at time C that match the search criteria. Andy > The issue was not really understood before the latest WG meeting. > - There is concern that this is a different feature than > getting notifications from the internal notification log, > and turning into something more like the 'cron' or 'at' command. > - There is a concern that this forces the agent to treat notifications > in the future as if they were replayed. > - There is confusion about when to send the notification. > Is is sent after the last buffered notification (at the time the > is received) or is it sent after the last live > (replayed) notification that occurs around the ? > - There is concern that asking for replay notifications that have not > happened yet is confusing. > - There is concern that this document is already a year late and > the extra time it would take to get this new feature correctly > documented is not worth the effort. > - There is concern that the 'replay in the future' feature is > just a by-product of the data model design, and not a real feature at > all. > There does not seem to be a real use case for this feature. > Why wouldn't the manager just wait an hour to send the > , rather than say "send me the replay > notifications, > but wait an hour before starting". Why would the manager tie up > a session (which cannot do anything for an hour)? > > > > 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 Aug 07 08:49:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOV9-0005IL-Lp for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 08:49:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIOV7-0007BV-PC for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 08:49:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIOL7-000Nch-CG for netconf-data@psg.com; Tue, 07 Aug 2007 12:39: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=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 1IIOKw-000Nbm-19 for netconf@ops.ietf.org; Tue, 07 Aug 2007 12:39:03 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 659FA1B80C5; Tue, 7 Aug 2007 14:38:55 +0200 (CEST) Date: Tue, 07 Aug 2007 14:39:34 +0200 (CEST) Message-Id: <20070807.143934.117405102.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netconf@ops.ietf.org Subject: Re: Questions on Confirmed commit From: Martin Bjorklund In-Reply-To: <469C9CE9.5090209@ericsson.com> References: <469C9CE9.5090209@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: 8b30eb7682a596edff707698f4a80f7d Balazs Lengyel wrote: > 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 I think you found an interesting case, and this should be clarified if we ever see a rfc4741bis. Anyway, I think that 5a must not happen - if the db is locked it cannot be modified. And 5b must not happen either, since it contradicts the semantics of confirmed commit. So, I think that 3 should not be allowed. Essentially this would mean that when a user invokes a confirmed commit it takes an (implicit) lock. > ------------------------------------------------ > > 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? Just running. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Aug 07 09:09: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 1IIOoj-0000kd-Tb for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 09:09:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIOoi-0000gH-JW for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 09:09:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIOeG-000Pg3-VK for netconf-data@psg.com; Tue, 07 Aug 2007 12:58: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=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 1IIOe5-000Pe6-PC for netconf@ops.ietf.org; Tue, 07 Aug 2007 12:58: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 1IIOe4-000088-6n; Tue, 07 Aug 2007 14:58: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: Tue, 07 Aug 2007 12:58:44 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #17: Unspecified aspects of confirmed commit X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/17 Message-ID: <077.0bce561053d9b569744953911caef06c@tools.ietf.org> X-Trac-Ticket-ID: 17 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f IzE3OiBVbnNwZWNpZmllZCBhc3BlY3RzIG9mIGNvbmZpcm1lZCBjb21taXQNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiBSZXBvcnRlcjogIGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSAgfCAgICAg ICBPd25lcjogICAgIA0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgICAg ICAgIHwgICBNaWxlc3RvbmU6ICAgICANCkNvbXBvbmVudDogIFJGQzQ3NDEgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgY29uZmlybWVkIGNvbW1p dCBsb2NraW5nICAgICB8ICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBXaGF0IGhhcHBlbnMgaW4g dGhlIGZvbGxvd2luZyBzZXF1ZW5jZTpbW0JSXV0NCiAxKSBPcGVyYXRvciBBIG1vZGlmaWVzIHRo ZSBjYW5kaWRhdGUgZGF0YXN0b3JlW1tCUl1dDQogMikgT3BlcmF0b3IgQSBzdWNjZXNzZnVsbHkg dXNlcyBjb25maXJtZWQgY29tbWl0IG9uIGNhbmRpZGF0ZVtbQlJdXQ0KIDMpIE9wZXJhdG9yIEIg c3VjY2Vzc2Z1bGx5IGxvY2tzIHRoZSBydW5uaW5nIGRhdGFzdG9yZVtbQlJdXQ0KIDQpIFRoZSBj b25maXJtZWQgY29tbWl0IHRpbWVzIG91dFtbQlJdXQ0KIFtbQlJdXQ0KIDVhKSBUaGUgbG9ja2Vk IHJ1bm5pbmcgZGF0YXN0b3JlIGlzIHJldmVydGVkIHRvIHRoZSBwcmV2aW91cyB2ZXJzaW9uDQog ZXZlbiB0aG91Z2ggaXQncyBsb2NrZWQgW1tCUl1dDQogW1tCUl1dDQogNWIpIE5vdGhpbmcgYXMg ZHVlIHRvIHRoZSBsb2NrIHRoZSBydW5uaW5nIGRhdGFzdG9yZSBjYW4gbm90IGJlDQogY2hhbmdl ZFtbQlJdXQ0KDQogLS0tLQ0KDQogUHJvcG9zZWQgYW5zd2VyOltbQlJdXQ0KIDVhKSBtdXN0IG5v dCBoYXBwZW4gLSBpZiB0aGUgZGIgaXMgbG9ja2VkIGl0IGNhbm5vdCBiZSBtb2RpZmllZC4gW1tC Ul1dDQogNWIpIG11c3Qgbm90IGhhcHBlbiBlaXRoZXIsIHNpbmNlIGl0IGNvbnRyYWRpY3RzIHRo ZSBzZW1hbnRpY3Mgb2YNCiBjb25maXJtZWQgY29tbWl0LiAgW1tCUl1dDQogMykgc2hvdWxkIG5v dCBiZSBhbGxvd2VkLiAgRXNzZW50aWFsbHkgdGhpcyB3b3VsZCBtZWFuIHRoYXQgd2hlbiBhIHVz ZXINCiBpbnZva2VzIGEgY29uZmlybWVkIGNvbW1pdCBpdCB0YWtlcyBhbiAoaW1wbGljaXQpIGxv Y2suW1tCUl1dDQoNCiAtLS0tDQoNCiBXaGVuIHRoZSBub2RlIHJldmVydCBpdCdzIGNvbmZpZ3Vy YXRpb24gZHVlIHRvIGFuIGV4cGlyZWQgY29uZmlybWVkDQogY29tbWl0IHdpbGwgaXQgcmVzdG9y ZSB0aGUgY2FuZGlkYXRlIGRhdGFzdG9yZSB0byBpdCdzIHByZXZpb3VzDQogc3RhdGUgYXMgd2Vs bCBvciBvbmx5IHRoZSBydW5uaW5nIGRhdGFzdG9yZT9bW0JSXV0NCg0KIC0tLS0NCg0KIFByb3Bv c2VkIGFuc3dlcjpbW0JSXV0NCiBPbmx5IHRoZSBydW5uaW5nIGRhdGFzdG9yZSBpcyByZXZlcnRl ZCwgdGhlIGNhbmRpZGF0ZSBpcyBub3QuDQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29s cy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzE3Pg0KTmV0Y29uZiA8aHR0cDovL3Rv b2xzLmlldGYub3JnL3dnL25ldGNvbmYvdHJhYy8+DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUgTkVU Q09ORiBXb3JraW5nIEdyb3Vw -- to unsubscribe send a message to netconf-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 Aug 07 13:12: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 1IISbx-0007mt-T1 for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 13:12:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISbw-0004Qs-9b for netconf-archive@lists.ietf.org; Tue, 07 Aug 2007 13:12:49 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IISQZ-000PgG-Ia for netconf-data@psg.com; Tue, 07 Aug 2007 17:01: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 [68.142.229.97] (helo=smtp108.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IISQL-000PfE-1Z for netconf@ops.ietf.org; Tue, 07 Aug 2007 17:00:58 +0000 Received: (qmail 92161 invoked from network); 7 Aug 2007 17:00:43 -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; 7 Aug 2007 17:00:43 -0000 X-YMail-OSG: fzkkxocVM1m0AtnYt2EEwIhlTFCIenxXW_wzJCi1aFGwBIRMMCU8wxIamNtkKle4lqFo6rwTdbKpf3lfMGGP0ZNXiA-- Message-ID: <46B8A4E2.20101@andybierman.com> Date: Tue, 07 Aug 2007 09:59:14 -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-ext-00.txt] Content-Type: multipart/mixed; boundary="------------020704080703020907010405" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------020704080703020907010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, This draft contains the protocol extensions that the WG has discussed, such as test-only and with-defaults. Andy --------------020704080703020907010405 Content-Type: message/rfc822; name="I-D ACTION:draft-bierman-ncx-ext-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-bierman-ncx-ext-00.txt" X-Account-Key: account4 Return-Path: Delivered-To: ietf@6908.7081 Received: (qmail 17581 invoked by uid 78); 7 Aug 2007 14:16:22 -0000 Received: from unknown (HELO ns-mr1.netsolmail.com) (10.49.16.160) by 0 with SMTP; 7 Aug 2007 14:16:22 -0000 Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145]) by ns-mr1.netsolmail.com (8.13.6/8.13.6) with ESMTP id l77EGMWK010599 for ; Tue, 7 Aug 2007 10:16:22 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPqD-0001mr-Vp; Tue, 07 Aug 2007 10:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPpx-0001ht-DI for i-d-announce@ietf.org; Tue, 07 Aug 2007 10:15:05 -0400 Received: from ns1.neustar.com ([156.154.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIPpv-0002tS-MD for i-d-announce@ietf.org; Tue, 07 Aug 2007 10:15:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 08D9326ECE for ; Tue, 7 Aug 2007 14:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IIPpu-0003yA-R0 for i-d-announce@ietf.org; Tue, 07 Aug 2007 10: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, 07 Aug 2007 10:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: I-D ACTION:draft-bierman-ncx-ext-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 : Protocol Extensions Author(s) : A. Bierman Filename : draft-bierman-ncx-ext-00.txt Pages : 19 Date : 2007-8-7 The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured data modeling environment which promotes human usability and multi-vendor interoperability. The Network Configuration Extensions (NCX) are a set of specifications intended to address NETCONF data modeling issues. This document defines some NETCONF protocol extensions for improving the functionality of some existing protocol operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bierman-ncx-ext-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-ext-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-ext-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-8-7095342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bierman-ncx-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bierman-ncx-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-7095342.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-- --------------020704080703020907010405-- -- to unsubscribe send a message to netconf-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 Aug 08 05:11: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 1IIhZJ-0006YS-O2 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 05:11:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIhZI-0002kX-Fy for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 05:11:05 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIhNl-000Eci-IS for netconf-data@psg.com; Wed, 08 Aug 2007 08:59: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=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 1IIhNZ-000Ebc-Uv for netconf@ops.ietf.org; Wed, 08 Aug 2007 08:59:04 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 43E571B80C5 for ; Wed, 8 Aug 2007 10:58:46 +0200 (CEST) Date: Wed, 08 Aug 2007 10:59:27 +0200 (CEST) Message-Id: <20070808.105927.95679929.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: Re: Questions on Confirmed commit From: Martin Bjorklund In-Reply-To: <46A76B84.6030102@edgeware.tv> References: <469C9CE9.5090209@ericsson.com> <46A76B84.6030102@edgeware.tv> 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: 00e94c813bef7832af255170dca19e36 [resent] Johan Rydberg wrote: > 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. But it also says: The confirming commit can itself include a parameter. I.e. a confirming commit can at the same time be a confirmed commit. Note that the way it's defined is that running is reverted _unless_ a confirming commit is sent, not that the changes are made persistent when a confirming commit is sent. So I think that the text in the rfc is consistent with the junos interpretation. Thus, a confirming confirmed commit with a zero timeout will explicitly revert running. But unfortunately, zero is not allowed, so you have to use a 1 second delay: 1 In any case this is not IMO crystal clear from the text. So the question is if the behaviour described above was the intention? Otherwise I'm sure we can find an interpretation of the current text which is consistent with the intention ;) /martin > 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 Wed Aug 08 11:45: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 1IInjQ-00085C-2C for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 11:45:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IInjO-0003Vb-M2 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 11:45:56 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IInVa-0006wX-UX for netconf-data@psg.com; Wed, 08 Aug 2007 15:31: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=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.98] (helo=smtp107.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IInVP-0006uR-Mg for netconf@ops.ietf.org; Wed, 08 Aug 2007 15:31:33 +0000 Received: (qmail 68067 invoked from network); 8 Aug 2007 15:31:26 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp107.sbc.mail.re2.yahoo.com with SMTP; 8 Aug 2007 15:31:26 -0000 Message-ID: <46B9E175.8020200@andybierman.com> Date: Wed, 08 Aug 2007 08:29:57 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification #9: replay in the future consensus point 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, I would like people to speak up about the startTime and/or stopTime parameters in the future issue. Do you favor: A) return an error if parameters are in the future B) return whatever the agent has in its reply log that matches the search criteria (at the time the request is made). Parameters only refer to the timestamps of entries in the log. C) treat as a request to start returning notifications some time in the future, according to the parameters. Parameters refer to the 'time window' that notification delivery is desired. 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 Aug 08 12:18:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIoFA-0003kQ-JB for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 12:18:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIoF4-0004XV-Ca for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 12:18:44 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIo5y-000AjQ-G7 for netconf-data@psg.com; Wed, 08 Aug 2007 16:09: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.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 1IIo5k-000AiM-Hd for netconf@ops.ietf.org; Wed, 08 Aug 2007 16:09:06 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1F180206B9; Wed, 8 Aug 2007 18:08:58 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-7e-46b9ea9a225c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F2735205C4; Wed, 8 Aug 2007 18:08:57 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 18:08:57 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 18:08:57 +0200 Message-ID: <46B9EA99.3050602@ericsson.com> Date: Wed, 08 Aug 2007 18:08:57 +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 #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> In-Reply-To: <46B9E175.8020200@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 16:08:57.0443 (UTC) FILETIME=[6CC50B30:01C7D9D6] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hello, A) yes B) yes C) no I proposed a set of simple rules. Balazs Andy Bierman wrote: > Hi, > > I would like people to speak up about the startTime and/or > stopTime parameters in the future issue. > > Do you favor: > > A) return an error if parameters are in the future > > B) return whatever the agent has in its reply log > that matches the search criteria (at the time the > request is made). Parameters only refer to the > timestamps of entries in the log. > > C) treat as a request to start returning notifications > some time in the future, according to the parameters. > Parameters refer to the 'time window' that notification > delivery is desired. > > 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 Wed Aug 08 12:44: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 1IIodp-0002PM-Bg for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 12:44:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIodo-0005Nn-4W for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 12:44:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIoTw-000DEA-TH for netconf-data@psg.com; Wed, 08 Aug 2007 16:34: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 [68.142.229.91] (helo=smtp114.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIoTl-000DD8-DQ for netconf@ops.ietf.org; Wed, 08 Aug 2007 16:33:55 +0000 Received: (qmail 69689 invoked from network); 8 Aug 2007 16:33:48 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp114.sbc.mail.re2.yahoo.com with SMTP; 8 Aug 2007 16:33:47 -0000 X-YMail-OSG: cSxj1jIVM1kDfC9XjJZQ_UAiKMjU6IrNsfs4MhpIo0ey67xPBV3YM16NxQt51I_cbSJjPxsnYsfEay.zNRHx7kjhcw-- Message-ID: <46B9F012.8090209@andybierman.com> Date: Wed, 08 Aug 2007 09:32:18 -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 #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <46B9EA99.3050602@ericsson.com> In-Reply-To: <46B9EA99.3050602@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: 52f7a77164458f8c7b36b66787c853da Balazs Lengyel wrote: > Hello, > A) yes > B) yes > C) no > > I proposed a set of simple rules. A B C D +----------+-----------+------------+----------- Log opens at time (A) First log entry at time (B) Second log entry at time (C) at time (D) The actual values of startTime and stopTime are just filter parameters. Any startTime <= (B) will return both logged entries. If the stopTime is any time > (C) then both entries are returned -- even if it > (D). My concern (also raised by Randy) is that the agent and manager clock skew will make it difficult for the manager to give a value <= (D). > Balazs Andy > > Andy Bierman wrote: >> Hi, >> >> I would like people to speak up about the startTime and/or >> stopTime parameters in the future issue. >> >> Do you favor: >> >> A) return an error if parameters are in the future >> >> B) return whatever the agent has in its reply log >> that matches the search criteria (at the time the >> request is made). Parameters only refer to the >> timestamps of entries in the log. >> >> C) treat as a request to start returning notifications >> some time in the future, according to the parameters. >> Parameters refer to the 'time window' that notification >> delivery is desired. >> >> 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 Aug 08 12:46: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 1IIofa-0005Fz-I2 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 12:46:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIofa-0005Q3-3p for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 12:46:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIoXZ-000DZX-Cx for netconf-data@psg.com; Wed, 08 Aug 2007 16:37: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.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 1IIoXO-000DXD-1H for netconf@ops.ietf.org; Wed, 08 Aug 2007 16:37:39 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2F372026D; Wed, 8 Aug 2007 18:37:31 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-1a-46b9f14bf157 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9CE7520202; Wed, 8 Aug 2007 18:37:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 18:37:31 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 18:37:30 +0200 Message-ID: <46B9F14A.4000704@ericsson.com> Date: Wed, 08 Aug 2007 18:37:30 +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 #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <46B9EA99.3050602@ericsson.com> <46B9F012.8090209@andybierman.com> In-Reply-To: <46B9F012.8090209@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 16:37:30.0992 (UTC) FILETIME=[6A1FDF00:01C7D9DA] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> A) yes >> B) yes >> C) no >> >> I proposed a set of simple rules. > > A B C D > +----------+-----------+------------+----------- > > Log opens at time (A) > First log entry at time (B) > Second log entry at time (C) > at time (D) > > The actual values of startTime and stopTime are just > filter parameters. Any startTime <= (B) will return > both logged entries. If the stopTime is any time > (C) > then both entries are returned -- even if it > (D). > > My concern (also raised by Randy) is that the agent > and manager clock skew will make it difficult for the > manager to give a value <= (D). > In this case better have a special value NOW. If C and D are very close due to the skew the manager might want to specify NOW, but might send down a stopTime < C. 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 Wed Aug 08 14:18: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 1IIq7H-0007BI-Hv for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 14:18:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIq7G-0007nF-2x for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 14:18:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIpwr-000NHX-0v for netconf-data@psg.com; Wed, 08 Aug 2007 18:07: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.92] (helo=smtp113.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIpwf-000NGb-C0 for netconf@ops.ietf.org; Wed, 08 Aug 2007 18:07:51 +0000 Received: (qmail 54086 invoked from network); 8 Aug 2007 18:07:44 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp113.sbc.mail.re2.yahoo.com with SMTP; 8 Aug 2007 18:07:44 -0000 X-YMail-OSG: OOlCiNkVM1mHqsEi1Kns6PJxxWLKDfTPBr9PWEj1YKdzeSPY Message-ID: <46BA0617.5040100@andybierman.com> Date: Wed, 08 Aug 2007 11:06:15 -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 #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <46B9EA99.3050602@ericsson.com> <46B9F012.8090209@andybierman.com> <46B9F14A.4000704@ericsson.com> In-Reply-To: <46B9F14A.4000704@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: 50a516d93fd399dc60588708fd9a3002 Balazs Lengyel wrote: > > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello, >>> A) yes >>> B) yes >>> C) no >>> >>> I proposed a set of simple rules. >> >> A B C D >> +----------+-----------+------------+----------- >> >> Log opens at time (A) >> First log entry at time (B) >> Second log entry at time (C) >> at time (D) >> >> The actual values of startTime and stopTime are just >> filter parameters. Any startTime <= (B) will return >> both logged entries. If the stopTime is any time > (C) >> then both entries are returned -- even if it > (D). >> >> My concern (also raised by Randy) is that the agent >> and manager clock skew will make it difficult for the >> manager to give a value <= (D). >> > In this case better have a special value NOW. If C and D are very close > due to the skew the manager might want to specify NOW, but might send > down a stopTime < C. I agree with you. If there was a option, then it would be okay to treat startTime and/or stopTime > 'now' as an error. > 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 Wed Aug 08 15:19: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 1IIr3g-0006zd-U4 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 15:19:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIr3f-0000ZR-HC for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 15:19:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIqtT-0004Rh-Eo for netconf-data@psg.com; Wed, 08 Aug 2007 19:08: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 [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIqtG-0004PV-QC for netconf@ops.ietf.org; Wed, 08 Aug 2007 19:08:26 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 47D031B80C5; Wed, 8 Aug 2007 21:08:15 +0200 (CEST) Date: Wed, 08 Aug 2007 21:08:06 +0200 (CEST) Message-Id: <20070808.210806.33045977.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point From: Martin Bjorklund In-Reply-To: <46B9E175.8020200@andybierman.com> References: <46B9E175.8020200@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: a7d6aff76b15f3f56fcb94490e1052e4 Andy Bierman wrote: > Hi, > > I would like people to speak up about the startTime and/or > stopTime parameters in the future issue. > > Do you favor: > > A) return an error if parameters are in the future Better than B. > B) return whatever the agent has in its reply log > that matches the search criteria (at the time the > request is made). Parameters only refer to the > timestamps of entries in the log. No, this seems very confusing. > C) treat as a request to start returning notifications > some time in the future, according to the parameters. > Parameters refer to the 'time window' that notification > delivery is desired. I can live with it, but I don't prefer it. I'd prefer: D) treat startTime in the future as an error, but stopTime in the future is ok (it's like giving a startTime w/o a stopTime, but let the agent stop the notifications at a certain time.) A special "now" value for the stopTime seems useful - it's like a 'cat' on the file. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 08 15:35: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 1IIrJV-0007Ma-Na for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 15:35:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIrJS-0000rS-T4 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 15:35:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIr92-00066q-S1 for netconf-data@psg.com; Wed, 08 Aug 2007 19:24: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,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.1.8 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIr8k-000652-Gc for netconf@ops.ietf.org; Wed, 08 Aug 2007 19:24:28 +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 l78JOEW10317 for ; Wed, 8 Aug 2007 19:24:14 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_01C7D9F1.B45FF95A" Subject: Pre-release 2 of Notification Update Date: Wed, 8 Aug 2007 15:24:13 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Pre-release 2 of Notification Update Thread-Index: AcfZ8bP3a2yFirsfTMCFBbw5xcP4Ww== From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: af1cf0f266abc960bbfe44794c1876f0 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D9F1.B45FF95A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I'm almost done the update (hopefully). Attached is a pre-release. Please let me know if anything was incorrectly executed. <>=20 Disclaimers: 1. I have not validated much of the schema or examples 2. I got a bit confused in the updates to section 5.2. These may still have issues. 3. I have not done anything about replays in the future. The text remains unchanged in this area. 4. I need to double check that I have not missed updates. 5. There were a few changes (mainly editorial) that I did not make for specific reasons which I need to send an email to discuss. 6. Not sure if using correct namespace in section 2.1.1.1. Andy said what was there was wrong, but it validates for me and there was no suggestions. I tried something else, but it didn't validate. 7. There was a request to add description of how to define notification instances, which has not been added, but there are now two examples (one in replayComplete and one in the examples in section 5). Is this sufficient? 8. I have not validate that I am always using the correct The URI string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) Sharon Chisholm Nortel=20 Ottawa, Ontario Canada ------_=_NextPart_001_01C7D9F1.B45FF95A Content-Type: text/html; name="rfcdiff.pyht_two.htm" Content-Transfer-Encoding: base64 Content-Description: rfcdiff.pyht_two.htm Content-Disposition: attachment; filename="rfcdiff.pyht_two.htm" CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LTA4LnR4dCBuZXRjb25mX2V2ZW50LnR4dDwvdGl0bGU+PC9oZWFkPjxib2R5Pgo8cHJlPgoKTmV0 d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFMuIENoaXNob2xtCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5vcnRlbApJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIFRyZXZpbm8KRXhwaXJlczogPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5KYW51YXJ5PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+RmVicnVhcnk8L2ZvbnQ+PC9zdHJvbmc+IDksIDIwMDggICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPkp1bHk8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbic+QXVndXN0PC9mb250Pjwvc3Ryb25nPiA4LCAyMDA3CgogICAgICAgICAgICAgICAgICAg ICAgTkVUQ09ORiBFdmVudCBOb3RpZmljYXRpb25zCiAgICAgICAgICAgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLTA4LnR4dC5wcmUtcmVs ZWFzZTwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi0wOS50eHQucHJlcmVsZWFz ZTI8L2ZvbnQ+PC9zdHJvbmc+CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5n IHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAg YXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUg aXMgYXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdo aWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2Nv cmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUg d29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9y Y2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQK ICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMg SW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0 aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUg YWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 LgoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBi ZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn PkphbnVhcnk8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5GZWJy dWFyeTwvZm9udD48L3N0cm9uZz4gOSwgMjAwOC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHly aWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBtZWNoYW5pc21zIHdoaWNoIHByb3ZpZGUgYW4gYXN5bmNocm9ub3VzCiAgIG1l c3NhZ2Ugbm90aWZpY2F0aW9uIGRlbGl2ZXJ5IHNlcnZpY2UgZm9yIHRoZSBORVRDT05GIHByb3Rv Y29sLiAgVGhpcwogICBpcyBhbiBvcHRpb25hbCBjYXBhYmlsaXR5IGJ1aWx0IG9uIHRvcCBvZiB0 aGUgYmFzZSBORVRDT05GCiAgIGRlZmluaXRpb24uICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhl IGNhcGFiaWxpdGllcyBhbmQgb3BlcmF0aW9ucwogICBuZWNlc3NhcnkgdG8gc3VwcG9ydCB0aGlz IHNlcnZpY2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAgMS4xLiAg RGVmaW5pdGlvbiBvZiBUZXJtcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNAogICAgIDEuMi4gIE1vdGl2YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICAxLjMuICBFdmVudCBOb3RpZmljYXRpb25zIGluIE5F VENPTkYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3RyaWtlPjxmb250IGNvbG9yPSdy ZWQnPjUKICAgICAxLjQuICBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuPC9mb250Pjwvc3RyaWtlPiAgNgogICAyLiAgTm90aWZpY2F0aW9u LVJlbGF0ZWQgT3BlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAg ICAyLjEuICBTdWJzY3JpYmluZyB0byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNhdGlvbnMgLiAuIC4g LiAuIC4gLiAuICA3CiAgICAgICAyLjEuMS4gICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDIuMi4gIFNlbmRpbmcgRXZl bnQgTm90aWZpY2F0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICAg IDIuMi4xLiAgJmx0O25vdGlmaWNhdGlvbiZndDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA5CiAgICAgMi4zLiAgVGVybWluYXRpbmcgdGhlIFN1YnNjcmlwdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICAzLiAgU3VwcG9ydGluZyBDb25jZXB0 cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICAzLjEu ICBDYXBhYmlsaXRpZXMgRXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDExCiAgICAgICAzLjEuMS4gIENhcGFiaWxpdHkgSWRlbnRpZmllciAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMy4xLjIuICBDYXBhYmlsaXR5IEV4YW1wbGUg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICAzLjIuICBFdmVudCBT dHJlYW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAg ICAgICAzLjIuMS4gIEV2ZW50IFN0cmVhbSBEZWZpbml0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjEyPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MTM8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAzLjIu Mi4gIEV2ZW50IFN0cmVhbSBDb250ZW50IEZvcm1hdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMwogICAgICAgMy4yLjMuICBEZWZhdWx0IEV2ZW50IFN0cmVhbSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAgIDMuMi40LiAgRXZlbnQgU3RyZWFtIFNvdXJjZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICAzLjIuNS4gIEV2ZW50 IFN0cmVhbSBEaXNjb3ZlcnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAg IDMuMy4gIE5vdGlmaWNhdGlvbiBSZXBsYXkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4xNTwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjE2PC9mb250Pjwvc3Ryb25nPgogICAgICAgMy4zLjEu ICBPdmVydmlldyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4xNTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u dCBjb2xvcj0nZ3JlZW4nPjE2PC9mb250Pjwvc3Ryb25nPgogICAgICAgMy4zLjIuICBDcmVhdGlu ZyBhIFN1YnNjcmlwdGlvbiB3aXRoIFJlcGxheSAgLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICAg IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+My4zLjMuICBSZXBsYXkgQ29tcGxldGUgTm90aWZp Y2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTY8L2ZvbnQ+PC9zdHJpa2U+CiAgICAg My40LiAgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQgU2NoZW1hIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjE2PC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+MTc8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgMy41LiAgU3Vi c2NyaXB0aW9ucyBEYXRhIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjE5PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+MjA8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgMy42LiAgRmlsdGVyIE1lY2hh bmljcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnPjE5PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbic+MjA8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAzLjYuMS4gIEZpbHRlcmluZyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnPjE5PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MjA8 L2ZvbnQ+PC9zdHJvbmc+CiAgICAgMy43LiAgTWVzc2FnZSBGbG93IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjE5 PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MjA8L2ZvbnQ+PC9z dHJvbmc+CiAgIDQuICBYTUwgU2NoZW1hIGZvciBFdmVudCBOb3RpZmljYXRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjIxPC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MjM8L2ZvbnQ+PC9zdHJvbmc+CiAg IDUuICBGaWx0ZXJpbmcgRXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjI1PC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Mjc8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNS4xLiAg U3VidHJlZSBGaWx0ZXJpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjI1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+MzA8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNS4yLiAgWFBBVEggZmls dGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPjI4PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+MzE8L2ZvbnQ+PC9zdHJvbmc+CiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNv bG9yPSdyZWQnPjMwPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ MzM8L2ZvbnQ+PC9zdHJvbmc+CiAgIDcuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn PjMxPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+ PC9zdHJvbmc+CiAgIDguICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjMyPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzU8L2ZvbnQ+PC9zdHJvbmc+ CiAgIDkuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjMzPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzY8L2ZvbnQ+PC9zdHJvbmc+CiAgIEFwcGVu ZGl4IEEuICBDaGFuZ2UgTG9nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjM0PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+Mzc8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgQS4xLiAgVmVyc2lv biAtMDggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPjM0PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+MzcKICAgICBBLjIuICBWZXJzaW9uIC0wOSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM5PC9mb250Pjwvc3Ryb25nPgogICBBdXRob3Jz JyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPjQyPC9mb250Pjwvc3Ryb25nPgogICBJbnRlbGxlY3R1YWwgUHJv cGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz4zODwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0nZ3JlZW4nPjQzPC9mb250Pjwvc3Ryb25nPgoKMS4gIEludHJvZHVjdGlvbgoKICAgW05FVENP TkZdIGNhbiBiZSBjb25jZXB0dWFsbHkgcGFydGl0aW9uZWQgaW50byBmb3VyIGxheWVyczoKCiAg IExheWVyICAgICAgICAgICAgICAgICAgICAgIEV4YW1wbGUKICAgICstLS0tLS0tLS0tLS0tKyAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgfCAgIENv bnRlbnQgICB8ICAgICAgfCAgICAgQ29uZmlndXJhdGlvbiBkYXRhICAgICAgICAgICAgICAgICB8 CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCiAgICB8IE9wZXJhdGlvbnMgIHwgICAgICB8ICZsdDtnZXQtY29uZmlnJmd0 OywgJmx0O2VkaXQtY29uZmlnJmd0OyAmbHQ7bm90aWZpY2F0aW9uJmd0O3wKICAgICstLS0tLS0t LS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KwogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rICAgICAgIHwKICAgIHwgICAgIFJQQyAgICAgfCAgICAgIHwgICAgJmx0O3JwYyZn dDssICZsdDtycGMtcmVwbHkmZ3Q7ICAgICAgIHwgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0r ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICB8CiAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwKICAg ICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgICB8IFRyYW5zcG9ydCAgIHwgICAgICB8ICAgQkVFUCwgU1NILCBTU0wsIGNv bnNvbGUgICAgICAgICAgICAgICAgfAogICAgfCAgIFByb3RvY29sICB8ICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstLS0tLS0tLS0tLS0tKyAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMQoKICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIG1lY2hhbmlzbXMgd2hpY2ggcHJvdmlkZSBhbiBhc3luY2hyb25vdXMKICAgbWVzc2FnZSBu b3RpZmljYXRpb24gZGVsaXZlcnkgc2VydmljZSBmb3IgdGhlIFtORVRDT05GXSBwcm90b2NvbC4K ICAgVGhpcyBpcyBhbiBvcHRpb25hbCBjYXBhYmlsaXR5IGJ1aWx0IG9uIHRvcCBvZiB0aGUgYmFz ZSBORVRDT05GCiAgIGRlZmluaXRpb24uICBUaGlzIG1lbW8gZGVmaW5lcyB0aGUgY2FwYWJpbGl0 aWVzIGFuZCBvcGVyYXRpb25zCiAgIG5lY2Vzc2FyeSB0byBzdXBwb3J0IHRoaXMgc2VydmljZS4K CjEuMS4gIERlZmluaXRpb24gb2YgVGVybXMKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVT VCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJT SE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMK ICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjEx OV0uCgogICBFbGVtZW50OiAgQW4gW1hNTF0gRWxlbWVudC4KCiAgIFN1YnNjcmlwdGlvbjogIEFu IGFncmVlbWVudCBhbmQgbWV0aG9kIHRvIHJlY2VpdmUgZXZlbnQgbm90aWZpY2F0aW9ucwogICAg ICBvdmVyIGEgTkVUQ09ORiBzZXNzaW9uLiAgQSBjb25jZXB0IHJlbGF0ZWQgdG8gdGhlIGRlbGl2 ZXJ5IG9mCiAgICAgIG5vdGlmaWNhdGlvbnMgKGlmIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz50aGVyZSBhcmU8L2ZvbnQ+PC9zdHJvbmc+IGFueSB0byBzZW5kKSBpbnZvbHZpbmcgZGVzdGlu YXRpb24gYW5kCiAgICAgIHNlbGVjdGlvbiBvZiBub3RpZmljYXRpb25zLiAgSXQgaXMgYm91bmQg dG8gdGhlIGxpZmV0aW1lIG9mIGEKICAgICAgc2Vzc2lvbi4KCiAgIE9wZXJhdGlvbjogIFRoaXMg dGVybSBpcyB1c2VkIHRvIHJlZmVyIHRvIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucwogICAg ICBbTkVUQ09ORl0uICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPlNwZWNpZmljYWxseSB3aXRo aW48L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+V2l0aGluPC9m b250Pjwvc3Ryb25nPiB0aGlzIGRvY3VtZW50LCBvcGVyYXRpb24gcmVmZXJzIHRvIE5FVENPTkYK ICAgICAgcHJvdG9jb2wgb3BlcmF0aW9ucyBkZWZpbmVkIGluIHN1cHBvcnQgb2YgTkVUQ09ORiBu b3RpZmljYXRpb25zLgoKICAgRXZlbnQ6ICBBbiBldmVudCBpcyBzb21ldGhpbmcgdGhhdCBoYXBw ZW5zIHdoaWNoIG1heSBiZSBvZiBpbnRlcmVzdCAtCiAgICAgIGEgY29uZmlndXJhdGlvbiBjaGFu Z2UsIGEgZmF1bHQsIGEgY2hhbmdlIGluIHN0YXR1cywgY3Jvc3NpbmcgYQogICAgICB0aHJlc2hv bGQsIG9yIGFuIGV4dGVybmFsIGlucHV0IHRvIHRoZSBzeXN0ZW0sIGZvciBleGFtcGxlLiAgT2Z0 ZW4KICAgICAgdGhpcyByZXN1bHRzIGluIGFuIGFzeW5jaHJvbm91cyBtZXNzYWdlLCBzb21ldGlt ZXMgcmVmZXJyZWQgdG8gYXMKICAgICAgYSBub3RpZmljYXRpb24gb3IgZXZlbnQgbm90aWZpY2F0 aW9uLCBiZWluZyBzZW50IHRvIGludGVyZXN0ZWQKICAgICAgcGFydGllcyB0byBub3RpZnkgdGhl bSB0aGF0IHRoaXMgZXZlbnQgaGFzIG9jY3VycmVkLgoKICAgUmVwbGF5OiAgVGhlIGFiaWxpdHkg dG8gc2VuZC9yZS1zZW5kIHByZXZpb3VzbHkgbG9nZ2VkIG5vdGlmaWNhdGlvbnMKICAgICAgdXBv biByZXF1ZXN0LiAgVGhlc2Ugbm90aWZpY2F0aW9ucyBhcmUgc2VudCBhc3luY2hyb25vdXNseS4g IFRoaXMKICAgICAgZmVhdHVyZSBpcyBpbXBsZW1lbnRlZCBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIg YW5kIGludm9rZWQgYnkgdGhlCiAgICAgIE5FVENPTkYgY2xpZW50LgoKICAgU3RyZWFtOiAgQW4g ZXZlbnQgc3RyZWFtIGlzIGEgc2V0IG9mIGV2ZW50IG5vdGlmaWNhdGlvbnMgbWF0Y2hpbmcKICAg ICAgc29tZSBmb3J3YXJkaW5nIGNyaXRlcmlhIGFuZCBpdCBpcyBhdmFpbGFibGUgdG8gTkVUQ09O RiBjbGllbnRzCiAgICAgIGZvciBzdWJzY3JpcHRpb24uCgogICBGaWx0ZXI6ICBBIHBhcmFtZXRl ciB0aGF0IGluZGljYXRlcyB3aGljaCBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlCiAgICAgIGV2ZW50 cyBhcmUgb2YgaW50ZXJlc3QuICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+QSBmaWx0ZXIg aXMgZGVmaW5lZCBhcyBvbmUgb3IgbW9yZSBmaWx0ZXIKICAgICAgZWxlbWVudCBbTkVUQ09ORl0s IHdoaWNoIGVhY2ggaWRlbnRpZmllcyBhIHBvcnRpb25zIG9mIHRoZSBvdmVyYWxsCiAgICAgIGZp bHRlci48L2ZvbnQ+PC9zdHJvbmc+CgoxLjIuICBNb3RpdmF0aW9uCgogICBUaGUgbW90aXZhdGlv biBmb3IgdGhpcyB3b3JrIGlzIHRvIGVuYWJsZSB0aGUgc2VuZGluZyBvZiBhc3luY2hyb25vdXMK ICAgbWVzc2FnZXMgdGhhdCBhcmUgY29uc2lzdGVudCB3aXRoIHRoZSBkYXRhIG1vZGVsIChjb250 ZW50KSBhbmQKICAgc2VjdXJpdHkgbW9kZWwgdXNlZCB3aXRoaW4gYSBORVRDT05GIGltcGxlbWVu dGF0aW9uLgoKPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4xLjMuICBFdmVudCBOb3RpZmljYXRp b25zIGluIE5FVENPTkYKCiAgIFRoaXMgbWVtbyBkZWZpbmVzIGEgbWVjaGFuaXNtIHdoZXJlYnk8 L2ZvbnQ+PC9zdHJpa2U+CgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+VGhlIHNjb3Bl IG9mPC9mb250Pjwvc3Ryb25nPiB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5ORVRDT05G IGNsaWVudCBpbmRpY2F0ZXMKICAgaW50ZXJlc3Q8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJz53b3JrIGFpbXMgbWVldGluZyB0aGUgZm9sbG93aW5nIG9wZXJhdGlv bmFsIG5lZWRzOgoKICAgbyAgSW5pdGlhbCByZWxlYXNlIHNob3VsZCBlbnN1cmUgaXQgc3VwcG9y dHMgbm90aWZpY2F0aW9uczwvZm9udD48L3N0cm9uZz4gaW4gPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJz5yZWNlaXZpbmcgZXZlbnQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz5zdXBwb3J0CiAgICAgIG9mIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucy4KCiAgIG8g IEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byB1c2UgdGhlIHNhbWUgZGF0YSBtb2RlbCBmb3I8L2Zv bnQ+PC9zdHJvbmc+IG5vdGlmaWNhdGlvbnMgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5mcm9t PC9mb250Pjwvc3RyaWtlPgogICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+YXMgZm9y IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucy4KCiAgIG8gIFNvbHV0aW9uIHNob3VsZCBzdXBwb3J0 PC9mb250Pjwvc3Ryb25nPiBhIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+TkVUQ09ORiBzZXJ2 ZXIgYnkKICAgY3JlYXRpbmc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJz5yZWFzb25hYmxlIG1lc3NhZ2Ugc2l6ZSBsaW1pdCAoaS5lLiwgbm90CiAgICAgIHRvbyBz aG9ydCkKCiAgIG8gIFRoZSBub3RpZmljYXRpb25zIHNob3VsZCBiZSBjYXJyaWVkIG92ZXI8L2Zv bnQ+PC9zdHJvbmc+IGEgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmNvbm5lY3Rpb24tb3Jp ZW50ZWQKICAgICAgZGVsaXZlcnkgbWVjaGFuaXNtLgoKICAgbyAgQTwvZm9udD48L3N0cm9uZz4g c3Vic2NyaXB0aW9uIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+dG8gcmVjZWl2ZSBldmVudCBu b3RpZmljYXRpb25zLiAgVGhlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbic+bWVjaGFuaXNtIGZvciBub3RpZmljYXRpb25zIHNob3VsZCBiZSBwcm92aWRlZC4KICAg ICAgVGhpcyB0YWtlcyBpbnRvIGFjY291bnQgdGhhdCBhPC9mb250Pjwvc3Ryb25nPiBORVRDT05G IHNlcnZlciA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnJlcGxpZXMgdG8gaW5kaWNhdGUgd2hl dGhlciB0aGUgc3Vic2NyaXB0aW9uIHJlcXVlc3Qgd2FzCiAgIHN1Y2Nlc3NmdWwgYW5kLCBpZiBp dCB3YXMgc3VjY2Vzc2Z1bCwgYmVnaW5zIHNlbmRpbmcgdGhlIGV2ZW50PC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ZG9lcyBub3Qgc2VuZDwvZm9udD48L3N0cm9u Zz4KICAgICAgbm90aWZpY2F0aW9ucyA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+YmVmb3Jl IGJlaW5nIGFza2VkPC9mb250Pjwvc3Ryb25nPiB0byA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bic+ZG8gc28gYW5kIHRoYXQgaXQgaXM8L2ZvbnQ+PC9zdHJvbmc+IHRoZQogICAgICBORVRDT05G IGNsaWVudCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmFzIHRoZSBldmVudHMgb2NjdXIgd2l0 aGluPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+d2hvIGluaXRp YXRlczwvZm9udD48L3N0cm9uZz4gdGhlCiAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c3lz dGVtLiAgVGhlc2UgZXZlbnQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJz5mbG93IG9mIG5vdGlmaWNhdGlvbnMuCgogICBvICBBIGZpbHRlcmluZyBtZWNoYW5pc20g Zm9yIHNlbmRpbmc8L2ZvbnQ+PC9zdHJvbmc+IG5vdGlmaWNhdGlvbnMgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz53aWxsIGNvbnRpbnVlIHRvPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+c2hvdWxkPC9mb250Pjwvc3Ryb25nPiBiZSA8c3RyaWtlPjxmb250IGNv bG9yPSdyZWQnPnNlbnQgdW50aWwKICAgZWl0aGVyPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+cHV0IGluCiAgICAgIHBsYWNlIHdpdGhpbiB0aGUgTkVUQ09ORiBz ZXJ2ZXIuCgogICBvICBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIGEgbm90aWZpY2F0aW9u IHNob3VsZCBiZSBzdWZmaWNpZW50CiAgICAgIHNvIHRoYXQgaXQgY2FuIGJlIGFuYWx5emVkIGlu ZGVwZW5kZW50IG9mIHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtLgogICAgICBJbiBvdGhlciB3b3Jk cyB0aGUgZGF0YSBjb250ZW50IGZ1bGx5IGRlc2NyaWJlcyBhIG5vdGlmaWNhdGlvbjsKICAgICAg cHJvdG9jb2wgaW5mb3JtYXRpb24gaXMgbm90IG5lZWRlZCB0byB1bmRlcnN0YW5kIGEgbm90aWZp Y2F0aW9uLgoKICAgbyAgVGhlIHNlcnZlciBzaG91bGQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBy ZXBsYXkgbG9jYWxseSBsb2dnZWQKICAgICAgbm90aWZpY2F0aW9ucy4KCjEuMy4gIEV2ZW50IE5v dGlmaWNhdGlvbnMgaW4gTkVUQ09ORgoKICAgVGhpcyBtZW1vIGRlZmluZXMgYSBtZWNoYW5pc20g d2hlcmVieSB0aGUgTkVUQ09ORiBjbGllbnQgaW5kaWNhdGVzCiAgIGludGVyZXN0IGluIHJlY2Vp dmluZyBldmVudCBub3RpZmljYXRpb25zIGZyb20gYSBORVRDT05GIHNlcnZlciBieQogICBjcmVh dGluZyBhIHN1YnNjcmlwdGlvbiB0byByZWNlaXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMuICBUaGUg TkVUQ09ORgogICBzZXJ2ZXIgcmVwbGllcyB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBzdWJzY3Jp cHRpb24gcmVxdWVzdCB3YXMKICAgc3VjY2Vzc2Z1bCBhbmQsIGlmIGl0IHdhcyBzdWNjZXNzZnVs LCBiZWdpbnMgc2VuZGluZyB0aGUgZXZlbnQKICAgbm90aWZpY2F0aW9ucyB0byB0aGUgTkVUQ09O RiBjbGllbnQgYXMgdGhlIGV2ZW50cyBvY2N1ciB3aXRoaW4gdGhlCiAgIHN5c3RlbS4gIFRoZXNl IGV2ZW50IG5vdGlmaWNhdGlvbnMgd2lsbCBjb250aW51ZSB0byBiZSBzZW50IHVudGlsCiAgIGVp dGhlcjwvZm9udD48L3N0cm9uZz4gdGhlIE5FVENPTkYgc2Vzc2lvbiBpcyB0ZXJtaW5hdGVkIG9y IHRoZSBzdWJzY3JpcHRpb24KICAgdGVybWluYXRlcyBmb3Igc29tZSBvdGhlciByZWFzb24uICBU aGUgZXZlbnQgbm90aWZpY2F0aW9uCiAgIHN1YnNjcmlwdGlvbiBhbGxvd3MgYSBudW1iZXIgb2Yg b3B0aW9ucyB0byBlbmFibGUgdGhlIE5FVENPTkYgY2xpZW50CiAgIHRvIHNwZWNpZnkgd2hpY2gg ZXZlbnRzIGFyZSBvZiBpbnRlcmVzdC4gIFRoZXNlIGFyZSBzcGVjaWZpZWQgd2hlbgogICB0aGUg c3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQuCgogICBBIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ TkVUQ09ORiBzZXJ2ZXIgaXMgd2lsbCBub3QgcmVhZCBSUEMgcmVxdWVzdHMsIGJ5IGRlZmF1bHQs IG9uIHRoZQogICBzZXNzaW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3Vic2NyaXB0aW9uIHVudGls IHRoZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmNsaWVudCBT SE9VTEQgTk9UIHNlbmQgcmVxdWVzdHMgd2hpbGUgYTwvZm9udD48L3N0cm9uZz4gbm90aWZpY2F0 aW9uIHN1YnNjcmlwdGlvbgogICBpcyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmRvbmUuICBB IGNhcGFiaWxpdHkgbWF5IGJlIGFkdmVydGlzZWQgdG8gYW5ub3VuY2UKICAgdGhhdCBhPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+YWN0aXZlLCBiZWNhdXNlIHRo ZTwvZm9udD48L3N0cm9uZz4gc2VydmVyIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+aXMgYWJs ZSB0bzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPk1BWSBOT1Q8 L2ZvbnQ+PC9zdHJvbmc+IHByb2Nlc3MgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5SUENzIHdo aWxlIGEgbm90aWZpY2F0aW9uIHN0cmVhbSBpcwogICBhY3RpdmUgb24gYSBzZXNzaW9uLiAgVGhl IGJlaGF2aW91cjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnRo ZW0uICBBbiBleGFtcGxlPC9mb250Pjwvc3Ryb25nPiBvZiA8c3RyaWtlPjxmb250IGNvbG9yPSdy ZWQnPnN1Y2g8L2ZvbnQ+PC9zdHJpa2U+CiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz53 aGVuIHRoZSBub3RpZmljYXRpb25zIHdvdWxkIGJlIHByb2Nlc3MgaXMgaWY8L2ZvbnQ+PC9zdHJv bmc+IGEgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnNlcGFyYXRlPC9mb250Pjwvc3Ryb25n PiBjYXBhYmlsaXR5IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+aXMgb3V0c2lkZQogICB0aGUg c2NvcGU8L2ZvbnQ+PC9zdHJpa2U+CiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz53YXMg YWR2ZXJ0aXNlZCBpbmRpY2F0aW5nIHN1cHBvcnQ8L2ZvbnQ+PC9zdHJvbmc+IG9mIHRoaXMgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5kb2N1bWVudC4KCjEuNC4gIFJlcXVpcmVtZW50czwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmZ1bmN0aW9uYWxpdHkuCgoy LiAgTm90aWZpY2F0aW9uLVJlbGF0ZWQgT3BlcmF0aW9ucwoKMi4xLiAgU3Vic2NyaWJpbmcgdG8g UmVjZWl2ZSBFdmVudCBOb3RpZmljYXRpb25zPC9mb250Pjwvc3Ryb25nPgoKICAgVGhlIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCc+Zm9sbG93aW5nIHJlcXVpcmVtZW50cyBoYXZlIGJlZW4gYWRk cmVzc2VkPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ZXZlbnQg bm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcyBpbml0aWF0ZWQ8L2ZvbnQ+PC9zdHJvbmc+IGJ5 IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnNvbHV0aW9uOgoKICAgbyAgSW5pdGlhbCBy ZWxlYXNlIHNob3VsZCBlbnN1cmUgaXQgc3VwcG9ydHMgbm90aWZpY2F0aW9uIGluIHN1cHBvcnQK ICAgICAgb2YgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zCgogICBvICBEYXRhIGNvbnRlbnQgbXVz dCBub3QgcHJlY2x1ZGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz5ORVRDT05GCiAgIGNsaWVudCBhbmQgcmVzcG9uZGVkIHRvIGJ5PC9mb250Pjwvc3Ryb25nPiB0 aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz51c2U8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz5ORVRDT05GIHNlcnZlci4gIEEgc3Vic2NyaXB0aW9uIGlzCiAg IGJvdW5kIHRvIGEgc2luZ2xlIHN0cmVhbSBmb3IgdGhlIGxpZmV0aW1lPC9mb250Pjwvc3Ryb25n PiBvZiB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zYW1lIGRhdGEgbW9kZWwgYXMKICAg ICAgdXNlZCBpbiBjb25maWd1cmF0aW9uCgogICBvICBTb2x1dGlvbiBzaG91bGQgc3VwcG9ydCBh IHJlYXNvbmFibGUgbWVzc2FnZSBzaXplIGxpbWl0IChpZSwgbm90CiAgICAgIHRvbyBzaG9ydCkK CiAgIG8gIFNvbHV0aW9uIHNob3VsZCBwcm92aWRlIHJlbGlhYmxlIGRlbGl2ZXJ5IG9mIG5vdGlm aWNhdGlvbnMKCiAgIG8gIFNvbHV0aW9uIHNob3VsZCBwcm92aWRlIGEgc3Vic2NyaXB0aW9uIG1l Y2hhbmlzbSAoQSBORVRDT05GIHNlcnZlcgogICAgICBkb2VzIG5vdCBzZW5kIG5vdGlmaWNhdGlv bnMgYmVmb3JlIGJlaW5nIGFza2VkIHRvIGRvIHNvIGFuZCB0aGUKICAgICAgTkVUQ09ORiBjbGll bnQgaW5pdGlhdGVzIHRoZSBmbG93IG9mIG5vdGlmaWNhdGlvbnMpCgogICBvICBTb2x1dGlvbiBz aG91bGQgcHJvdmlkZSBhIGZpbHRlcmluZyBtZWNoYW5pc20gd2l0aGluIHRoZSBORVRDT05GCiAg ICAgIHNlcnZlcgoKICAgbyAgU29sdXRpb24gc2hvdWxkIHNlbmQgc3VmZmljaWVudCBpbmZvcm1h dGlvbiBpbiBhIG5vdGlmaWNhdGlvbiBzbwogICAgICB0aGF0IGl0IGNhbiBiZSBhbmFseXplZCBp bmRlcGVuZGVudCBvZiB0aGUgdHJhbnNwb3J0IG1lY2hhbmlzbQogICAgICAoZGF0YSBjb250ZW50 IGZ1bGx5IGRlc2NyaWJlcyBhIG5vdGlmaWNhdGlvbjsgcHJvdG9jb2wgaW5mb3JtYXRpb24KICAg ICAgaXMgbm90IG5lZWRlZCB0byB1bmRlcnN0YW5kIGEgbm90aWZpY2F0aW9uKQoKICAgbyAgU29s dXRpb24gc2hvdWxkIHN1cHBvcnQgcmVwbGF5IG9mIGxvY2FsbHkgbG9nZ2VkIG5vdGlmaWNhdGlv bnMKCjIuICBOb3RpZmljYXRpb24tUmVsYXRlZCBPcGVyYXRpb25zCgoyLjEuICBTdWJzY3JpYmlu ZyB0byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNhdGlvbnMKCiAgIFRoZSBldmVudCBub3RpZmljYXRp b24gc3Vic2NyaXB0aW9uIGlzIGluaXRpYXRlZCBieSB0aGUgTkVUQ09ORgogICBjbGllbnQgYW5k IHJlc3BvbmRlZCB0byBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIuPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+c3Vic2NyaXB0aW9uLjwvZm9udD48L3N0cm9uZz4gIFdo ZW4KICAgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCwgdGhl IGV2ZW50cyBvZgogICBpbnRlcmVzdCBhcmUgc3BlY2lmaWVkLgoKICAgQ29udGVudCBmb3IgYW4g ZXZlbnQgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBjYW4gYmUgc2VsZWN0ZWQgYnkKICAgYXBw bHlpbmcgdXNlci1zcGVjaWZpZWQgZmlsdGVycy4KCjIuMS4xLiAgJmx0O2NyZWF0ZS1zdWJzY3Jp cHRpb24mZ3Q7CgogICBEZXNjcmlwdGlvbjoKCiAgICAgIFRoaXMgb3BlcmF0aW9uIGluaXRpYXRl cyBhbiBldmVudCBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIHdoaWNoCiAgICAgIHdpbGwgc2Vu ZCBhc3luY2hyb25vdXMgZXZlbnQgbm90aWZpY2F0aW9ucyB0byB0aGUgaW5pdGlhdG9yIG9mIHRo ZQogICAgICBjb21tYW5kIHVudGlsIHRoZSBzdWJzY3JpcHRpb24gdGVybWluYXRlcy4KCiAgIFBh cmFtZXRlcnM6CgogICAgICBTdHJlYW06CgogICAgICAgICBBbiBvcHRpb25hbCA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnPnBhcmFtZXRlcjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0nZ3JlZW4nPnBhcmFtZXRlciwgJmx0O3N0cmVhbSZndDssPC9mb250Pjwvc3Ryb25nPiB0 aGF0IGluZGljYXRlcyB3aGljaCBzdHJlYW0gb2YKICAgICAgICAgZXZlbnRzIGlzIG9mIGludGVy ZXN0LiAgSWYgbm90IHByZXNlbnQsIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+dGhlbjwvZm9u dD48L3N0cmlrZT4gZXZlbnRzIGluIHRoZSBkZWZhdWx0CiAgICAgICAgIE5FVENPTkYgc3RyZWFt IHdpbGwgYmUgc2VudC4KCiAgICAgIEZpbHRlcjoKCiAgICAgICAgIEFuIG9wdGlvbmFsIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCc+cGFyYW1ldGVyPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+cGFyYW1ldGVyLCAmbHQ7ZmlsdGVyJmd0Oyw8L2ZvbnQ+PC9zdHJv bmc+IHRoYXQgaW5kaWNhdGVzIHdoaWNoIHN1YnNldCBvZgogICAgICAgICBhbGwgcG9zc2libGUg ZXZlbnRzIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+YXJlPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+aXM8L2ZvbnQ+PC9zdHJvbmc+IG9mIGludGVyZXN0LiAg VGhlIGZvcm1hdCBvZiB0aGlzCiAgICAgICAgIHBhcmFtZXRlciBpcyB0aGUgc2FtZSBhcyB0aGF0 IG9mIHRoZSBmaWx0ZXIgcGFyYW1ldGVyIGluIHRoZQogICAgICAgICBORVRDT05GIHByb3RvY29s IG9wZXJhdGlvbnMuICBJZiBub3QgcHJlc2VudCwgYWxsIGV2ZW50cyBub3QKICAgICAgICAgcHJl Y2x1ZGVkIGJ5IG90aGVyIHBhcmFtZXRlcnMgd2lsbCBiZSBzZW50LiAgU2VlIHNlY3Rpb24gMy42 CiAgICAgICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIGZpbHRlcnMuCgogICAgICBTdGFydCBU aW1lOgoKICAgICAgICAgQSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnBhcmFtZXRlcjwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnBhcmFtZXRlciwgJmx0O3N0 YXJ0VGltZSZndDssPC9mb250Pjwvc3Ryb25nPiB1c2VkIHRvIHRyaWdnZXIgdGhlIHJlcGxheSBm ZWF0dXJlCiAgICAgICAgIGFuZCBpbmRpY2F0ZSB0aGF0IHRoZSByZXBsYXkgc2hvdWxkIHN0YXJ0 IGF0IHRoZSB0aW1lCiAgICAgICAgIHNwZWNpZmllZC4gIElmCiAgICAgICAgIDxzdHJpa2U+PGZv bnQgY29sb3I9J3JlZCc+c3RhcnRUaW1lPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+Jmx0O3N0YXJ0VGltZSZndDs8L2ZvbnQ+PC9zdHJvbmc+IGlzIG5vdCBwcmVz ZW50LCB0aGlzIGlzIG5vdCBhIHJlcGxheQogICAgICAgICBzdWJzY3JpcHRpb24uICBJdCBpcyB2 YWxpZCB0byBzcGVjaWZ5IHN0YXJ0IHRpbWVzIHRoYXQgYXJlCiAgICAgICAgIGxhdGVyIHRoYW4g dGhlIGN1cnJlbnQgdGltZS4gIElmIHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnN0YXJ0 VGltZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiZsdDtzdGFy dFRpbWUmZ3Q7PC9mb250Pjwvc3Ryb25nPiBzcGVjaWZpZWQgaXMKICAgICAgICAgZWFybGllciB0 aGFuIHRoZSBsb2cgY2FuIHN1cHBvcnQsIHRoZSByZXBsYXkgd2lsbCBiZWdpbiB3aXRoCiAgICAg ICAgIHRoZSBlYXJsaWVzdCBhdmFpbGFibGUgbm90aWZpY2F0aW9uLiAgVGhpcyBwYXJhbWV0ZXIg aXMgb2YgdHlwZQogICAgICAgICBkYXRlVGltZS4KCiAgICAgIFN0b3AgVGltZToKCiAgICAgICAg IEFuIG9wdGlvbmFsIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+cGFyYW1ldGVyPC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+cGFyYW1ldGVyLCAmbHQ7c3RvcFRp bWUmZ3Q7LDwvZm9udD48L3N0cm9uZz4gdXNlZCB3aXRoIHRoZSBvcHRpb25hbAogICAgICAgICBy ZXBsYXkgZmVhdHVyZSB0byBpbmRpY2F0ZSB0aGUgbmV3ZXN0IG5vdGlmaWNhdGlvbnMgb2YKICAg ICAgICAgaW50ZXJlc3QuICBJZiBzdG9wIHRpbWUgaXMgbm90IHByZXNlbnQsIHRoZSBub3RpZmlj YXRpb25zIHdpbGwKICAgICAgICAgY29udGludWUgdW50aWwgdGhlIHN1YnNjcmlwdGlvbiBpcyB0 ZXJtaW5hdGVkLiAgTXVzdCBiZSB1c2VkCiAgICAgICAgIHdpdGggYW5kIGJlIGxhdGVyIHRoYW4g PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4nc3RhcnRUaW1lJy48L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7c3RhcnRUaW1lJmd0Oy48L2ZvbnQ+PC9zdHJv bmc+ICBJdCBpcyB2YWxpZCB0byBzcGVjaWZ5CiAgICAgICAgIHN0b3AgdGltZXMgdGhhdCBhcmUg bGF0ZXIgdGhhbiB0aGUgY3VycmVudCB0aW1lLiAgVGhpcwogICAgICAgICBwYXJhbWV0ZXIgaXMg b2YgdHlwZSBkYXRlVGltZS4KCiAgIFBvc2l0aXZlIFJlc3BvbnNlOgoKICAgICAgSWYgdGhlIE5F VENPTkYgc2VydmVyIGNhbiBzYXRpc2Z5IHRoZSByZXF1ZXN0LCB0aGUgc2VydmVyIHNlbmRzIGFu CiAgICAgICZsdDtvayZndDsgZWxlbWVudC4KCiAgIE5lZ2F0aXZlIFJlc3BvbnNlOgoKICAgICAg QW4gJmx0O3JwYy1lcnJvciZndDsgZWxlbWVudCBpcyBpbmNsdWRlZCB3aXRoaW4gdGhlICZsdDty cGMtcmVwbHkmZ3Q7IGlmIHRoZQogICAgICByZXF1ZXN0IGNhbm5vdCBiZSBjb21wbGV0ZWQgZm9y IGFueSByZWFzb24uICBTdWJzY3JpcHRpb24gcmVxdWVzdHMKICAgICAgd2lsbCBmYWlsIGlmIGEg ZmlsdGVyIHdpdGggaW52YWxpZCBzeW50YXggaXMgcHJvdmlkZWQgb3IgaWYgdGhlCiAgICAgIG5h bWUgb2YgYSBub24tZXhpc3RlbnQgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5wcm9maWxlIG9y PC9mb250Pjwvc3RyaWtlPiBzdHJlYW0gaXMgcHJvdmlkZWQuCgogICAgICBJZiBhIDxzdHJpa2U+ PGZvbnQgY29sb3I9J3JlZCc+c3RvcFRpbWU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz4mbHQ7c3RvcFRpbWUmZ3Q7PC9mb250Pjwvc3Ryb25nPiBpcyBzcGVjaWZp ZWQgaW4gYSByZXF1ZXN0IHdpdGhvdXQgaGF2aW5nIHNwZWNpZmllZAogICAgICBhCiAgICAgIDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c3RhcnRUaW1lPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+Jmx0O3N0YXJ0VGltZSZndDssPC9mb250Pjwvc3Ryb25nPiB0 aGUgZm9sbG93aW5nIGVycm9yIGlzIHJldHVybmVkOgoKICAgICAgICAgVGFnOiBtaXNzaW5nLWVs ZW1lbnQKCiAgICAgICAgIEVycm9yLXR5cGU6IHByb3RvY29sCgogICAgICAgICBTZXZlcml0eTog ZXJyb3IKCiAgICAgICAgIEVycm9yLWluZm86IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+Jmx0 O2JhZEVsZW1lbnQmZ3Q7OjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl ZW4nPiZsdDtiYWQtZWxlbWVudCZndDs6PC9mb250Pjwvc3Ryb25nPiBzdGFydFRpbWUKCiAgICAg ICAgIERlc2NyaXB0aW9uOiBBbiBleHBlY3RlZCBlbGVtZW50IGlzIG1pc3NpbmcuCgogICAgICBJ ZiB0aGUgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgaXMgcmVxdWVzdGVkIGJ1dCBpdCBpcyBub3QK ICAgICAgc3VwcG9ydGVkIGJ5IHRoZSBORVRDT05GIHNlcnZlciwgdGhlIGZvbGxvd2luZyBlcnJv ciBpcyByZXR1cm5lZDoKCiAgICAgICAgIFRhZzogb3BlcmF0aW9uLWZhaWxlZAoKICAgICAgICAg RXJyb3ItdHlwZTogcHJvdG9jb2wKCiAgICAgICAgIFNldmVyaXR5OiBlcnJvcgoKICAgICAgICAg RXJyb3ItaW5mbzogbm9uZQogICAgICAgICBEZXNjcmlwdGlvbjogUmVxdWVzdCBjb3VsZCBub3Qg YmUgY29tcGxldGVkIGJlY2F1c2UgdGhlCiAgICAgICAgIHJlcXVlc3RlZCBvcGVyYXRpb24gZmFp bGVkIGZvciBzb21lIHJlYXNvbiBub3QgY292ZXJlZCBieSBhbnkKICAgICAgICAgb3RoZXIgZXJy b3IgY29uZGl0aW9uCgoyLjEuMS4xLiAgVXNhZ2UgRXhhbXBsZQoKICAgPHN0cm9uZz48Zm9udCBj b2xvcj0nZ3JlZW4nPlRoZSBmb2xsb3dpbmcgZGVtb25zdHJhdGVzIGNyZWF0aW5nIGEgc2ltcGxl IHN1YnNjcmlwdGlvbi4gIE1vcmUKICAgY29tcGxleCBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4g c2VjdGlvbiA1LjwvZm9udD48L3N0cm9uZz4KCiAgICZsdDtuZXRjb25mOnJwYyBtZXNzYWdlLWlk PSIxMDEiCiAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+eG1sbnM6bmV0Y29uZj0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDs8L2ZvbnQ+PC9zdHJp a2U+CiAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz54bWxuczpuZXRjb25mPSJ1 cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiXCZndDs8L2ZvbnQ+PC9zdHJv bmc+CiAgICAgICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbgogICAgICAgICAgIHhtbG5zPSJ1cm46 aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAiJmd0OwogICAg ICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwogICAmbHQ7L25ldGNvbmY6cnBjJmd0OwoK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz5GaWd1cmUgMjwvZm9udD48L3N0cmlrZT4KCjIuMi4gIFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0 aW9ucwoKICAgT25jZSB0aGUgc3Vic2NyaXB0aW9uIGhhcyBiZWVuIHNldCB1cCwgdGhlIE5FVENP TkYgc2VydmVyIHNlbmRzIHRoZQogICBldmVudCBub3RpZmljYXRpb25zIGFzeW5jaHJvbm91c2x5 IG92ZXIgdGhlIGNvbm5lY3Rpb24uCgoyLjIuMS4gICZsdDtub3RpZmljYXRpb24mZ3Q7CgogICBE ZXNjcmlwdGlvbjoKCiAgICAgIEFuIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIHRoZSBj bGllbnQgd2hvIGluaXRpYXRlZCBhCiAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyBj b21tYW5kIGFzeW5jaHJvbm91c2x5IHdoZW4gYW4gZXZlbnQgb2YKICAgICAgaW50ZXJlc3QgKGku ZS4sIG1lZXRpbmcgdGhlIHNwZWNpZmllZCBmaWx0ZXJpbmcgY3JpdGVyaWEpIDxzdHJpa2U+PGZv bnQgY29sb3I9J3JlZCc+dG8gdGhlbTwvZm9udD48L3N0cmlrZT4gaGFzCiAgICAgIG9jY3VycmVk LiAgQW4gZXZlbnQgbm90aWZpY2F0aW9uIGlzIGEgY29tcGxldGUgYW5kIHdlbGwtZm9ybWVkIFhN TAogICAgICBkb2N1bWVudC4gIE5vdGUgdGhhdCAmbHQ7bm90aWZpY2F0aW9uJmd0OyBpcyBub3Qg YW4gUlBDIG1ldGhvZCBidXQKICAgICAgcmF0aGVyIHRoZSB0b3AgbGV2ZWwgZWxlbWVudCBpZGVu dGlmeWluZyB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5vbmUgd2F5PC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+b25lLXdheTwvZm9udD48L3N0cm9uZz4g bWVzc2FnZSBhcyBhCiAgICAgIG5vdGlmaWNhdGlvbi4KCiAgIFBhcmFtZXRlcnM6CgogICAgICAg ICBDb250YWlucyBub3RpZmljYXRpb24tc3BlY2lmaWMgdGFnZ2VkIDxzdHJpa2U+PGZvbnQgY29s b3I9J3JlZCc+Y29udGVudC48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJz5jb250ZW50LCBpZiBhbnkuPC9mb250Pjwvc3Ryb25nPiAgVGhlCiAgICAgICAgIGNvbnRl bnQgb2YgdGhlIGRhdGEgdGFnIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4K CiAgIFJlc3BvbnNlOgoKICAgICAgTm8gcmVzcG9uc2UuICBOb3QgYXBwbGljYWJsZS4KCjIuMy4g IFRlcm1pbmF0aW5nIHRoZSBTdWJzY3JpcHRpb24KCiAgIENsb3Npbmcgb2YgdGhlIGV2ZW50IG5v dGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gY2FuIGJlIGRvbmUgYnkKICAgdGVybWluYXRpbmcgdGhl IE5FVENPTkYgc2Vzc2lvbiAoICZsdDtraWxsLXNlc3Npb24mZ3Q7ICkgb3IgdGhlIHVuZGVybHlp bmcKICAgdHJhbnNwb3J0IHNlc3Npb24uICBJZiBhIHN0b3AgdGltZSBpcyBwcm92aWRlZCB3aGVu IHRoZSBzdWJzY3JpcHRpb24KICAgaXMgY3JlYXRlZCwgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz50aGVuPC9mb250Pjwvc3RyaWtlPiB0aGUgc3Vic2NyaXB0aW9uIHdpbGwgdGVybWluYXRlIGFm dGVyIHRoZSBzdG9wIHRpbWUgaXMKICAgcmVhY2hlZC4gIEluIHRoaXMgY2FzZSwgdGhlIE5FVENP TkYgc2Vzc2lvbiB3aWxsIHN0aWxsIGJlIGFuIGFjdGl2ZQogICBzZXNzaW9uLgoKMy4gIFN1cHBv cnRpbmcgQ29uY2VwdHMKCjMuMS4gIENhcGFiaWxpdGllcyBFeGNoYW5nZQoKICAgVGhlIGFiaWxp dHkgdG8gcHJvY2VzcyBhbmQgc2VuZCBldmVudCBub3RpZmljYXRpb25zIGlzIGFkdmVydGlzZWQK ICAgZHVyaW5nIHRoZSBjYXBhYmlsaXR5IGV4Y2hhbmdlIGJldHdlZW4gdGhlIE5FVENPTkYgY2xp ZW50IGFuZCBzZXJ2ZXIuCgozLjEuMS4gIENhcGFiaWxpdHkgSWRlbnRpZmllcgoKICAgInVybjpp ZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMCIKCjMuMS4yLiAg Q2FwYWJpbGl0eSBFeGFtcGxlCgogICAmbHQ7aGVsbG8geG1sbnM9InVybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCImZ3Q7CiAgICAgJmx0O2NhcGFiaWxpdGllcyZndDsKICAg ICAgICAmbHQ7Y2FwYWJpbGl0eSZndDsKICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOnhtbDpu czpuZXRjb25mOmJhc2U6MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAg ICAmbHQ7Y2FwYWJpbGl0eSZndDsKICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6 Y2FwYWJpbGl0eTpzdGFydHVwOjEuMAogICAgICAgICAgJmx0Oy9jYXBhYmlsaXR5Jmd0OwogICAg ICAgICAgJmx0O2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAgICAgIHVybjppZXRmOnBhcmFtczpuZXRj b25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMAogICAgICAgICAgJmx0Oy9jYXBhYmlsaXR5 Jmd0OwogICAgICAgJmx0Oy9jYXBhYmlsaXRpZXMmZ3Q7CiAgICAgJmx0O3Nlc3Npb24taWQmZ3Q7 NCZsdDsvc2Vzc2lvbi1pZCZndDsKICAgJmx0Oy9oZWxsbyZndDsKCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+RmlndXJlIDM8L2ZvbnQ+ PC9zdHJpa2U+CgozLjIuICBFdmVudCBTdHJlYW1zCgogICBBbiBldmVudCBzdHJlYW0gaXMgZGVm aW5lZCBhcyBhIHNldCBvZiBldmVudCBub3RpZmljYXRpb25zIG1hdGNoaW5nCiAgIHNvbWUgZm9y d2FyZGluZyBjcml0ZXJpYS4KCiAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+VGhlIGRpYWdy YW0gZGVwaWN0ZWQgaW48L2ZvbnQ+PC9zdHJpa2U+CgogICBGaWd1cmUgMiBpbGx1c3RyYXRlcyB0 aGUgbm90aWZpY2F0aW9uIGZsb3cgYW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4KICAgdGhpcyBk b2N1bWVudC4gIFRoZSBmb2xsb3dpbmcgaXMgb2JzZXJ2ZWQgZnJvbSB0aGUgZGlhZ3JhbSBiZWxv dzoKICAgU3lzdGVtIGNvbXBvbmVudHMgKGMxLi5jbikgZ2VuZXJhdGUgZXZlbnQgbm90aWZpY2F0 aW9ucyB3aGljaCBhcmUKICAgcGFzc2VkIHRvIGEgY2VudHJhbCBjb21wb25lbnQgZm9yIGNsYXNz aWZpY2F0aW9uIGFuZCBkaXN0cmlidXRpb24uCiAgIFRoZSBjZW50cmFsIGNvbXBvbmVudCBpbnNw ZWN0cyBlYWNoIGV2ZW50IG5vdGlmaWNhdGlvbiBhbmQgbWF0Y2hlcwogICB0aGUgZXZlbnQgbm90 aWZpY2F0aW9uIGFnYWluc3QgdGhlIHNldCBvZiBzdHJlYW0gZGVmaW5pdGlvbnMuICBXaGVuIGEK ICAgbWF0Y2ggb2NjdXJzLCB0aGUgZXZlbnQgbm90aWZpY2F0aW9uIGlzIGNvbnNpZGVyZWQgdG8g YmUgYSBtZW1iZXIgb2YKICAgdGhhdCBldmVudCBzdHJlYW0gKHN0cmVhbSAxLi5zdHJlYW0gbiku ICBBbiBldmVudCBub3RpZmljYXRpb24gbWF5IGJlCiAgIHBhcnQgb2YgbXVsdGlwbGUgZXZlbnQg c3RyZWFtcy4KCiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5BdCBzb21lIHBvaW50IGFm dGVyIHRoZSAnTkVUQ09ORiBzZXJ2ZXInIHJlY2VpdmVzIHRoZSBpbnRlcm5hbCBldmVudAogICBm cm9tIGEgc3RyZWFtLCBpdCBpcyBjb252ZXJ0ZWQgdG8gYW4gYXBwcm9wcmlhdGUgWE1MIGVuY29k aW5nIGJ5IHRoZQogICBhZ2VudCwgYW5kIGEgJmx0OyZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1l bnQgaXMgcmVhZHkgdG8gc2VuZCB0byBhbGwgTkVUQ09ORgogICBzZXNzaW9ucyBzdWJzY3JpYmVk IHRvIHRoYXQgc3RyZWFtLgoKICAgQWZ0ZXIgZ2VuZXJhdGlvbiBvZiB0aGUgJmx0O25vdGlmaWNh dGlvbiZndDsgZWxlbWVudCwgYWNjZXNzIGNvbnRyb2wgaXMKICAgYXBwbGllZCBieSB0aGUgYWdl bnQuICBJZiBhIHNlc3Npb24gZG9lcyBub3QgaGF2ZSBwZXJtaXNzaW9uIHRvCiAgIHJlY2VpdmUg dGhlICZsdDtub3RpZmljYXRpb24mZ3Q7LCB0aGVuIGl0IGlzIGRpc2NhcmRlZCBmb3IgdGhhdCBz ZXNzaW9uLAogICBhbmQgcHJvY2Vzc2luZyBvZiB0aGUgaW50ZXJuYWwgZXZlbnQgaXMgY29tcGxl dGVkIGZvciB0aGF0IHNlc3Npb24uPC9mb250Pjwvc3Ryb25nPgoKICAgV2hlbiBhIE5FVENPTkYg Y2xpZW50IHN1YnNjcmliZXMgdG8gYSBnaXZlbiBldmVudCBzdHJlYW0sIHVzZXItCiAgIGRlZmlu ZWQgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5maWx0ZXJzLDwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmZpbHRlciBlbGVtZW50cyw8L2ZvbnQ+PC9zdHJvbmc+ IGlmIGFwcGxpY2FibGUsIGFyZSBhcHBsaWVkIHRvIHRoZSBldmVudAogICBzdHJlYW0gYW5kIG1h dGNoaW5nIGV2ZW50IG5vdGlmaWNhdGlvbnMgYXJlIGZvcndhcmRlZCB0byB0aGUgTkVUQ09ORgog ICBzZXJ2ZXIgZm9yIGRpc3RyaWJ1dGlvbiB0byBzdWJzY3JpYmVkIE5FVENPTkYgY2xpZW50cy4g IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+Rm9yIG1vcmUgaW5mb3JtYXRpb24gb24KICAgZmls dGVycywgc2VlIHNlY3Rpb24gMy42LjwvZm9udD48L3N0cmlrZT4gIEEgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5ub3RpZmljYXRpb24gbG9nZ2luZyBzZXJ2aWNlIG1heSBhbHNvIGJlIGF2YWls YWJsZSwgaW4gd2hpY2ggY2FzZSwKICAgdGhlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+ZmlsdGVyIGlzCiAgIHRyYW5zZmVycmVkIGZyb20gdGhlIGNsaWVudCB0 byB0aGUgYWdlbnQgZHVyaW5nIHRoZSAmbHQ7Y3JlYXRlLQogICBzdWJzY3JpcHRpb24mZ3Q7IG9w ZXJhdGlvbiBhbmQgYXBwbGllZCBhZ2FpbnN0IGVhY2ggJmx0O25vdGlmaWNhdGlvbiZndDsKICAg ZWxlbWVudCBnZW5lcmF0ZWQgYnkgdGhlIHN0cmVhbS4gIEZvciBtb3JlIGluZm9ybWF0aW9uIG9u IGZpbHRlcmluZywKICAgc2VlIHNlY3Rpb24gMy42LgoKICAgQSBub3RpZmljYXRpb24gbG9nZ2lu ZyBzZXJ2aWNlIG1heSBhbHNvIGJlIGF2YWlsYWJsZSwgaW4gd2hpY2ggY2FzZSwKICAgdGhlPC9m b250Pjwvc3Ryb25nPiBjZW50cmFsIGNvbXBvbmVudCBsb2dzIG5vdGlmaWNhdGlvbnMuICBUaGUg TkVUQ09ORiBzZXJ2ZXIgbWF5CiAgIGxhdGVyIHJldHJpZXZlIGxvZ2dlZCBub3RpZmljYXRpb25z IHZpYSB0aGUgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUuCiAgIEZvciBtb3JlIGluZm9ybWF0aW9u IG9uIHJlcGxheSwgc2VlIHNlY3Rpb24gMy4zLgoKICAgKy0tLS0rCiAgIHwgYzEgfC0tLS0rICAg ICAgICAgICAgIGF2YWlsYWJsZSBzdHJlYW1zCiAgICstLS0tKyAgICB8ICAgICstLS0tLS0tLS0r CiAgICstLS0tKyAgICB8ICAgIHxjZW50cmFsICB8LSZndDsgc3RyZWFtIDEKICAgfCBjMiB8ICAg ICstLS0mZ3Q7fGV2ZW50ICAgIHwtJmd0OyBzdHJlYW0gMiAgICAgZmlsdGVyICArLS0tLS0tLSsK ICAgKy0tLS0rICAgIHwgICAgfHByb2Nlc3NvcnwtJmd0OyBORVRDT05GIHN0cmVhbSA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPi0tLS0tJmd0O3xuZXRjb25mfDwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPi0tLS0tJmd0O3xORVRDT05GfDwvZm9udD48L3N0cm9u Zz4KICAgIC4uLiAgICAgIHwgICAgfCAgICAgICAgIHwtJmd0OyBzdHJlYW0gbiAgICAgICAgICAg ICB8c2VydmVyIHwKICAgU3lzdGVtICAgIHwgICAgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLSsKICAgQ29tcG9uZW50c3wgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAvXAogICAgLi4uICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHx8CiAgICstLS0tKyAgICB8ICAgICAgICB8ICAgICAgICgtLS0t LS0tLS0tLS0pICAgICAgICAgICAgfHwKICAgfCBjbiB8LS0tLSsgICAgICAgIHwgICAgICAgKG5v dGlmaWNhdGlvbikgICAgICAgICAgICB8fAogICArLS0tLSsgICAgICAgICAgICAgKy0tLS0tJmd0 OyAoICBsb2dnaW5nICAgKSAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICggIHNlcnZpY2UgICApICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKC0tLS0tLS0tLS0tLSkgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcLwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNv bG9yPSdyZWQnPnxuZXRjb25mfDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz58TkVUQ09ORnw8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8Y2xpZW50IHwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tKwoKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRmlndXJlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+NDwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjI8L2ZvbnQ+PC9zdHJvbmc+Cgoz LjIuMS4gIEV2ZW50IFN0cmVhbSBEZWZpbml0aW9uCgogICBFdmVudCBzdHJlYW1zIGFyZSBwcmVk ZWZpbmVkIG9uIHRoZSBtYW5hZ2VkIGRldmljZS4gIFRoZQogICBjb25maWd1cmF0aW9uIG9mIGV2 ZW50IHN0cmVhbXMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KICAgSG93 ZXZlciwgaXQgaXMgZW52aXNpb25lZCB0aGF0IGV2ZW50IHN0cmVhbXMgYXJlIGVpdGhlciBwcmUt CiAgIGVzdGFibGlzaGVkIGJ5IHRoZSB2ZW5kb3IgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4o cHJlLWNvbmZpZ3VyZWQpIG9yPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdn cmVlbic+KHByZS1jb25maWd1cmVkKSw8L2ZvbnQ+PC9zdHJvbmc+IHVzZXIgY29uZmlndXJhYmxl IChlLmcuLAogICBwYXJ0IG9mIHRoZSBkZXZpY2UncyBjb25maWd1cmF0aW9uKSBvciBib3RoLiAg RGV2aWNlIHZlbmRvcnMgbWF5CiAgIGFsbG93IGV2ZW50IHN0cmVhbSBjb25maWd1cmF0aW9uIHZp YSA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+dGhlPC9mb250Pjwvc3Ryb25nPiBORVRDT05G IHByb3RvY29sIChpLmUuLAogICBlZGl0LWNvbmZpZyBvcGVyYXRpb24pLgoKMy4yLjIuICBFdmVu dCBTdHJlYW0gQ29udGVudCBGb3JtYXQKCiAgIFRoZSBjb250ZW50cyBvZiBhbGwgZXZlbnQgc3Ry ZWFtcyBtYWRlIGF2YWlsYWJsZSB0byBhIE5FVENPTkYgY2xpZW50CiAgIChpLmUuLCB0aGUgbm90 aWZpY2F0aW9uIHNlbnQgYnkgdGhlIE5FVENPTkYgc2VydmVyKSBtdXN0IGJlIGVuY29kZWQKICAg aW4gWE1MLgoKMy4yLjMuICBEZWZhdWx0IEV2ZW50IFN0cmVhbQoKICAgQSBORVRDT05GIHNlcnZl ciBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0aW5nIHRoZSBub3RpZmljYXRpb24KICAgY2FwYWJpbGl0 eSBtdXN0IHN1cHBvcnQgdGhlICJORVRDT05GIiBub3RpZmljYXRpb24gZXZlbnQgc3RyZWFtLgog ICBUaGlzIHN0cmVhbSBjb250YWlucyBhbGwgTkVUQ09ORiBYTUwgZXZlbnQgbm90aWZpY2F0aW9u cyBzdXBwb3J0ZWQgYnkKICAgdGhlIE5FVENPTkYgc2VydmVyLiAgVGhlIDxzdHJpa2U+PGZvbnQg Y29sb3I9J3JlZCc+ZGVmaW5pdGlvbjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0nZ3JlZW4nPmV4YWN0IHN0cmluZyAiTkVUQ09ORiIgaXMgdXNlZCB0byBkdXJpbmcKICAgYWR2 ZXJ0aXNlbWVudCBvZiBzdHJlYW0gc3VwcG9ydCBkdXJpbmcgJmx0O2dldCZndDsgb3BlcmF0aW9u IG9uICZsdDtzdHJlYW1zJmd0OwogICBhbmQgZHVyaW5nIHRoZSAmbHQ7Y3JlYXRlLXN1YnNjcmlw dGlvbiZndDsgb3BlcmF0aW9uLiAgRGVmaW5pdGlvbjwvZm9udD48L3N0cm9uZz4gb2YgdGhlCiAg IGV2ZW50IG5vdGlmaWNhdGlvbnMgYW5kIHRoZWlyIGNvbnRlbnRzIGZvciB0aGlzIGV2ZW50IHN0 cmVhbSBpcwogICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgoKMy4yLjQuICBF dmVudCBTdHJlYW0gU291cmNlcwoKICAgV2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBkZWZhdWx0 IGV2ZW50IHN0cmVhbSAoTkVUQ09ORgogICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPm5vdGlm aWNhdGlvbnMpPC9mb250Pjwvc3RyaWtlPgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ bm90aWZpY2F0aW9ucyksPC9mb250Pjwvc3Ryb25nPiBzcGVjaWZpY2F0aW9uIG9mIGFkZGl0aW9u YWwgZXZlbnQgc3RyZWFtIHNvdXJjZXMKICAgKGUuZy4sIFNOTVAsIDxzdHJpa2U+PGZvbnQgY29s b3I9J3JlZCc+c3lzbG9nLCBldGMuKTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0nZ3JlZW4nPnN5c2xvZyk8L2ZvbnQ+PC9zdHJvbmc+IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgZG9jdW1lbnQuICBORVRDT05GCiAgIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgbWF5IGxl dmVyYWdlIGFueSBkZXNpcmVkIGV2ZW50IHN0cmVhbSBzb3VyY2UKICAgaW4gdGhlIGNyZWF0aW9u IG9mIHN1cHBvcnRlZCBldmVudCBzdHJlYW1zLgoKMy4yLjUuICBFdmVudCBTdHJlYW0gRGlzY292 ZXJ5CgogICBBIE5FVENPTkYgY2xpZW50IHJldHJpZXZlcyB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQg ZXZlbnQgc3RyZWFtcyBmcm9tIGEKICAgTkVUQ09ORiBzZXJ2ZXIgdXNpbmcgdGhlICZsdDtnZXQm Z3Q7IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+UlBDIHJlcXVlc3QuPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+b3BlcmF0aW9uLjwvZm9udD48L3N0cm9uZz4K CjMuMi41LjEuICBOYW1lIFJldHJpZXZhbCB1c2luZyAmbHQ7Z2V0Jmd0OyBvcGVyYXRpb24KCiAg IFRoZSBsaXN0IG9mIGF2YWlsYWJsZSBldmVudCBzdHJlYW1zIGlzIHJldHJpZXZlZCBieSByZXF1 ZXN0aW5nIHRoZQogICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPiZsdDtldmVudFN0cmVhbXMm Z3Q7PC9mb250Pjwvc3RyaWtlPgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O3N0 cmVhbXMmZ3Q7PC9mb250Pjwvc3Ryb25nPiBzdWJ0cmVlIHZpYSBhICZsdDtnZXQmZ3Q7IG9wZXJh dGlvbi4gIEF2YWlsYWJsZSBldmVudCBzdHJlYW1zIGZvcgogICB0aGUgcmVxdWVzdGluZyBzZXNz aW9uIGFyZSByZXR1cm5lZCBpbiB0aGUgcmVwbHkgY29udGFpbmluZyB0aGUKICAgJmx0O25hbWUm Z3Q7IGFuZCAmbHQ7ZGVzY3JpcHRpb24mZ3Q7IGVsZW1lbnRzLCB3aGVyZSB0aGUgJmx0O25hbWUm Z3Q7IGVsZW1lbnQgaXMgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5tYW5kYXRvcnk8L2ZvbnQ+ PC9zdHJpa2U+CiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5tYW5kYXRvcnksPC9mb250 Pjwvc3Ryb25nPiBhbmQgaXRzIHZhbHVlIGlzIHVuaXF1ZSB3aXRoaW4gdGhlIHNjb3BlIG9mIGEg TkVUQ09ORgogICBzZXJ2ZXIuICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPlRoZSByZXR1cm5l ZCBsaXN0IG11c3Qgb25seSBpbmNsdWRlIHRoZSBuYW1lcyBvZgogICB0aG9zZSBldmVudCBzdHJl YW1zIGZvciB3aGljaCB0aGUgTkVUQ09ORiBzZXNzaW9uIGhhcyBzdWZmaWNpZW50CiAgIHByaXZp bGVnZXMuICBUaGUgTkVUQ09ORiBzZXNzaW9uIHByaXZpbGVnZXMgYXJlIGRldGVybWluZWQgdmlh IGFjY2VzcwogICBjb250cm9sIG1lY2hhbmlzbXMgd2hpY2ggYXJlIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC48L2ZvbnQ+PC9zdHJpa2U+ICBBbiBlbXB0eSByZXBseSBpcyByZXR1 cm5lZCBpZiB0aGVyZSBhcmUgbm8gYXZhaWxhYmxlIGV2ZW50CiAgIHN0cmVhbXMuICA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPlRoZTwvZm9udD48L3N0cmlrZT4KCiAgIDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz5BZGRpdGlvbmFsPC9mb250Pjwvc3Ryb25nPiBpbmZvcm1hdGlvbiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+YXZhaWxhYmxlIGFib3V0IGEgc3RyZWFtIGluY2x1ZGUg d2hldGhlcgogICBub3RpZmljYXRpb24gcmVwbGF5PC9mb250Pjwvc3Ryb25nPiBpcyA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPnJldHJpZXZlZCBieSByZXF1ZXN0aW5nPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+YXZhaWxhYmxlIGFuZCBpZiBzbyw8L2ZvbnQ+ PC9zdHJvbmc+IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPiZsdDtldmVudFN0cmVhbXMm Z3Q7IHN1YnRyZWUgdmlhCiAgIGEgJmx0O2dldCZndDsgb3BlcmF0aW9uLjwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnRpbWVzdGFtcCBpZiB0aGUKICAgZWFybGll c3QgcG9zc2libGUgbm90aWZpY2F0aW9uIHRvIHJlcGxheS48L2ZvbnQ+PC9zdHJvbmc+CgogICBF eGFtcGxlOiBSZXRyaWV2aW5nIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz50aGUgbGlzdCBv ZjwvZm9udD48L3N0cm9uZz4gYXZhaWxhYmxlIGV2ZW50IHN0cmVhbSBsaXN0IHVzaW5nCiAgICZs dDtnZXQmZ3Q7IG9wZXJhdGlvbjoKCiAgICZsdDtycGMgbWVzc2FnZS1pZD0iMTAxIgogICAgICB4 bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAm bHQ7Z2V0Jmd0OwogICAgICAmbHQ7ZmlsdGVyIHR5cGU9InN1YnRyZWUiJmd0OwogICAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPiZsdDtldmVudFN0cmVhbXMgeG1sbnM9InVybjppZXRmOnBh cmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlvbiIvJmd0OzwvZm9udD48L3N0cmlrZT4KICAg ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O25ldGNvbmYgeG1sbnM9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlvbiImZ3Q7CiAgICAgICAgICAgJmx0 O3N0cmVhbXMvJmd0OwogICAgICAgICAmbHQ7bmV0Y29uZiZndDs8L2ZvbnQ+PC9zdHJvbmc+CiAg ICAgICZsdDsvZmlsdGVyJmd0OwogICAgICZsdDsvZ2V0Jmd0OwogICAmbHQ7L3JwYyZndDsKCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ RmlndXJlIDU8L2ZvbnQ+PC9zdHJpa2U+CiAgIFRoZSBORVRDT05GIHNlcnZlciByZXR1cm5zIGEg bGlzdCBvZiBldmVudCBzdHJlYW1zIGF2YWlsYWJsZSBmb3IKICAgc3Vic2NyaXB0aW9uOiBORVRD T05GLCBTTk1QLCBhbmQgc3lzbG9nLWNyaXRpY2FsIGluIHRoaXMgZXhhbXBsZS4KCiZsdDtycGMt cmVwbHkgbWVzc2FnZS1pZD0iMTAxIgogICAgICAgICAgICAgICAgIHhtbG5zPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiJmd0OwogICZsdDtkYXRhJmd0OwogICAgIDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+Jmx0O2V2ZW50U3RyZWFtczwvZm9udD48L3N0cmlrZT4K ICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7bmV0Y29uZjwvZm9udD48L3N0cm9u Zz4gIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldG1vZDpub3RpZmljYXRpb24iJmd0 OwogICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7c3RyZWFtcyZndDs8L2ZvbnQ+ PC9zdHJvbmc+CiAgICAgICAgJmx0O3N0cmVhbSZndDsKICAgICAgICAgICAmbHQ7bmFtZSZndDtO RVRDT05GJmx0Oy9uYW1lJmd0OwogICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ Jmx0O2Rlc2NyaXB0aW9uJmd0O0RlZmF1bHQgbmV0Y29uZjwvZm9udD48L3N0cmlrZT4KICAgICAg ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O2Rlc2NyaXB0aW9uJmd0O2RlZmF1 bHQgTkVUQ09ORjwvZm9udD48L3N0cm9uZz4gZXZlbnQgc3RyZWFtCiAgICAgICAgICAgJmx0Oy9k ZXNjcmlwdGlvbiZndDsKICAgICAgICAgICAmbHQ7cmVwbGF5U3VwcG9ydCZndDt0cnVlJmx0Oy9y ZXBsYXlTdXBwb3J0Jmd0OwogICAgICAgICAgICZsdDtyZXBsYXlMb2dTdGFydFRpbWUmZ3Q7MjAw Ny0wNy0wOFQwMDowMDowMFombHQ7L3JlcGxheUxvZ1N0YXJ0VGltZSZndDsKICAgICAgICAmbHQ7 L3N0cmVhbSZndDsKICAgICAgICAmbHQ7c3RyZWFtJmd0OwogICAgICAgICAgICZsdDtuYW1lJmd0 O1NOTVAmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgJmx0O2Rlc2NyaXB0aW9uJmd0O1NOTVAgbm90 aWZpY2F0aW9ucyZsdDsvZGVzY3JpcHRpb24mZ3Q7CiAgICAgICAgICAgJmx0O3JlcGxheVN1cHBv cnQmZ3Q7ZmFsc2UmbHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgJmx0Oy9zdHJlYW0mZ3Q7 CiAgICAgICAgJmx0O3N0cmVhbSZndDsKICAgICAgICAgICZsdDtuYW1lJmd0O3N5c2xvZy1jcml0 aWNhbCZsdDsvbmFtZSZndDsKICAgICAgICAgICZsdDtkZXNjcmlwdGlvbiZndDtDcml0aWNhbCBh bmQgaGlnaGVyIHNldmVyaXR5CiAgICAgICAgICAmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAg ICAgJmx0O3JlcGxheVN1cHBvcnQmZ3Q7dHJ1ZSZsdDsvcmVwbGF5U3VwcG9ydCZndDsKICAgICAg ICAgICZsdDtyZXBsYXlMb2dTdGFydFRpbWUmZ3Q7MjAwNy0wNy0wMVQwMDowMDowMFombHQ7L3Jl cGxheUxvZ1N0YXJ0VGltZSZndDsKICAgICAgICAgJmx0Oy9zdHJlYW0mZ3Q7CiAgICAgIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCc+Jmx0Oy9ldmVudFN0cmVhbXMmZ3Q7PC9mb250Pjwvc3RyaWtl PgogICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7L3N0cmVhbXMmZ3Q7CiAg ICAgICZsdDsvbmV0Y29uZiZndDs8L2ZvbnQ+PC9zdHJvbmc+CiAgJmx0Oy9kYXRhJmd0OwombHQ7 L3JwYy1yZXBseSZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48 Zm9udCBjb2xvcj0ncmVkJz5GaWd1cmUgNjwvZm9udD48L3N0cmlrZT4KCjMuMi41LjIuICBFdmVu dCBTdHJlYW0gU3Vic2NyaXB0aW9uCgogICBBIE5FVENPTkYgY2xpZW50IG1heSByZXF1ZXN0IGZy b20gdGhlIE5FVENPTkYgc2VydmVyIHRoZSBsaXN0IG9mCiAgIGV2ZW50IHN0cmVhbXMgYXZhaWxh YmxlIHRvIHRoaXMgc2Vzc2lvbiBhbmQgdGhlbiBpc3N1ZSBhICZsdDtjcmVhdGUtCiAgIHN1YnNj cmlwdGlvbiZndDsgcmVxdWVzdCB3aXRoIHRoZSBkZXNpcmVkIGV2ZW50IHN0cmVhbSBuYW1lLiAg T21pdHRpbmcKICAgdGhlIGV2ZW50IHN0cmVhbSBuYW1lIGZyb20gdGhlICZsdDtjcmVhdGUtc3Vi c2NyaXB0aW9uJmd0OyByZXF1ZXN0IHJlc3VsdHMKICAgaW4gc3Vic2NyaXB0aW9uIHRvIHRoZSBk ZWZhdWx0IE5FVENPTkYgZXZlbnQgc3RyZWFtLgoKMy4yLjUuMi4xLiAgRmlsdGVyaW5nIEV2ZW50 IFN0cmVhbSBDb250ZW50cwoKICAgVGhlIHNldCBvZiBldmVudCBub3RpZmljYXRpb25zIGRlbGl2 ZXJlZCBpbiBhbiBldmVudCBzdHJlYW0gbWF5IGJlCiAgIGZ1cnRoZXIgcmVmaW5lZCBieSBhcHBs eWluZyBhIHVzZXItc3BlY2lmaWVkIGZpbHRlciA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ c3VwcGxpZWQ8L2ZvbnQ+PC9zdHJvbmc+IGF0CiAgIHN1YnNjcmlwdGlvbiBjcmVhdGlvbiB0aW1l ICggJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICkuICBUaGlzIGlzIGEKICAgdHJhbnNpZW50 IGZpbHRlciBhc3NvY2lhdGVkIHdpdGggdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRp b24KICAgYW5kIGRvZXMgbm90IG1vZGlmeSB0aGUgZXZlbnQgc3RyZWFtIGNvbmZpZ3VyYXRpb24u ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+RWl0aGVyIHN1YnRyZWUKICAgb3IgWFBBVEgg ZmlsdGVyaW5nIGNhbiBiZSB1c2VkLjwvZm9udD48L3N0cm9uZz4KCiAgIFhQQVRIIHN1cHBvcnQg Zm9yIHRoZSBOb3RpZmljYXRpb24gY2FwYWJpbGl0eSBpcyBhZHZlcnRpc2VkIGFzIHBhcnQKICAg b2YgdGhlIG5vcm1hbCBYUEFUSCBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQuICBJZiBYUEFUSCBz dXBwb3J0IGlzCiAgIGFkdmVydGlzZWQgdmlhIHRoZSBYUEFUSCBjYXBhYmlsaXR5IHRoZW4gWFBB VEggaXMgc3VwcG9ydGVkIGZvcgogICBub3RpZmljYXRpb24gZmlsdGVyaW5nIGFuZCBpZiB0aGlz IGNhcGFiaWxpdHkgaXMgbm90IGFkdmVydGlzZWQsIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ dGhlbjwvZm9udD48L3N0cmlrZT4KICAgWFBBVEggaXMgbm90IHN1cHBvcnRlZCBmb3Igbm90aWZp Y2F0aW9uIGZpbHRlcmluZy4KCjMuMy4gICBOb3RpZmljYXRpb24gUmVwbGF5CgozLjMuMS4gIE92 ZXJ2aWV3CgogICBSZXBsYXkgaXMgdGhlIGFiaWxpdHkgdG8gY3JlYXRlIGFuIGV2ZW50IHN1YnNj cmlwdGlvbiB0aGF0IHdpbGwKICAgcmVzZW5kIHJlY2VudGx5IGdlbmVyYXRlZCBub3RpZmljYXRp b25zLCBvciBpbiBzb21lIGNhc2VzIHNlbmQgdGhlbQogICBmb3IgdGhlIGZpcnN0IHRpbWUgdG8g YSBwYXJ0aWN1bGFyIE5FVENPTkYgY2xpZW50LiAgVGhlc2UKICAgbm90aWZpY2F0aW9ucyBhcmUg c2VudCB0aGUgc2FtZSB3YXkgYXMgbm9ybWFsIG5vdGlmaWNhdGlvbnMuCgogICBBIHJlcGxheSBv ZiBub3RpZmljYXRpb25zIGlzIHNwZWNpZmllZCBieSBpbmNsdWRpbmcgYW4gb3B0aW9uYWwKICAg cGFyYW1ldGVyIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4oJmx0O3N0YXJ0VGltZSZndDsp PC9mb250Pjwvc3Ryb25nPiB0byB0aGUgc3Vic2NyaXB0aW9uIGNvbW1hbmQgdGhhdCBpbmRpY2F0 ZXMKICAgdGhlIHN0YXJ0IHRpbWUgb2YgdGhlIHJlcGxheS4gIFRoZSBlbmQgdGltZSBpcyBzcGVj aWZpZWQgdXNpbmcgdGhlCiAgIG9wdGlvbmFsIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c3Rv cFRpbWU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7c3Rv cFRpbWUmZ3Q7PC9mb250Pjwvc3Ryb25nPiBwYXJhbWV0ZXIuICBJZiBub3QgcHJlc2VudCwgbm90 aWZpY2F0aW9ucyB3aWxsCiAgIGNvbnRpbnVlIHRvIGJlIHNlbnQgdW50aWwgdGhlIHN1YnNjcmlw dGlvbiBpcyB0ZXJtaW5hdGVkLgoKICAgQSBub3RpZmljYXRpb24gc3RyZWFtIHRoYXQgc3VwcG9y dHMgcmVwbGF5IGlzIG5vdCBleHBlY3RlZCB0byBoYXZlIGFuCiAgIHVubGltaXRlZCBzdXBwbHkg b2Ygc2F2ZWQgbm90aWZpY2F0aW9ucyBhdmFpbGFibGUgdG8gYWNjb21tb2RhdGUgYW55CiAgIHJl cGxheSByZXF1ZXN0LgoKICAgVGhlIGFjdHVhbCBudW1iZXIgb2Ygc3RvcmVkIG5vdGlmaWNhdGlv bnMgYXZhaWxhYmxlIGZvciByZXRyaWV2YWwgYXQKICAgYW55IGdpdmVuIHRpbWUgaXMgYSBORVRD T05GIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBtYXR0ZXIuCiAgIENvbnRyb2wgcGFy YW1ldGVycyBmb3IgdGhpcyBhc3BlY3Qgb2YgdGhlIGZlYXR1cmUgYXJlIG91dHNpZGUgdGhlCiAg IHNjb3BlIG9mIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+dGhlIGN1cnJlbnQ8L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz50aGlzPC9mb250Pjwvc3Ryb25nPiBk b2N1bWVudC4KCiAgIFJlcGxheSBpcyBkZXBlbmRlbnQgb24gYSBub3RpZmljYXRpb24gc3RyZWFt IHN1cHBvcnRpbmcgc29tZSBmb3JtIG9mCiAgIG5vdGlmaWNhdGlvbiBsb2dnaW5nLCBhbHRob3Vn aCBpdCBwdXRzIG5vIHJlc3RyaWN0aW9ucyBvbiB0aGUgc2l6ZSBvcgogICBmb3JtIG9mIHRoZSBs b2csIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+bm9yPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+b3I8L2ZvbnQ+PC9zdHJvbmc+IHdoZXJlIGl0IHJlc2lkZXMg d2l0aGluIHRoZSBkZXZpY2UuICBXaGV0aGVyIG9yCiAgIG5vdCBhIHN0cmVhbSBzdXBwb3J0cyBy ZXBsYXkgY2FuIGJlIGRpc2NvdmVyZWQgYnkgZG9pbmcgYSAmbHQ7Z2V0Jmd0OwogICBvcGVyYXRp b24gb24gdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZXZlbnRTdHJlYW1zPC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O3N0cmVhbXMmZ3Q7PC9mb250 Pjwvc3Ryb25nPiBlbGVtZW50IG9mIHRoZSBOb3RpZmljYXRpb24gTWFuYWdlbWVudAogICBTY2hl bWEuICBUaGlzIHNjaGVtYSBhbHNvIHByb3ZpZGVzIHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdy ZWQnPnJlcGxheUxvZ1N0YXJ0VGltZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0nZ3JlZW4nPiZsdDtyZXBsYXlMb2dTdGFydFRpbWUmZ3Q7PC9mb250Pjwvc3Ryb25nPiBlbGVt ZW50CiAgIHRvIGluZGljYXRlIHRoZSBlYXJsaWVzdCBhdmFpbGFibGUgbG9nZ2VkIG5vdGlmaWNh dGlvbi4KCjMuMy4yLiAgQ3JlYXRpbmcgYSBTdWJzY3JpcHRpb24gd2l0aCBSZXBsYXkKCiAgIFRo aXMgZmVhdHVyZSB1c2VzIG9wdGlvbmFsIHBhcmFtZXRlcnMgdG8gdGhlICZsdDtjcmVhdGUtc3Vi c2NyaXB0aW9uJmd0OwogICBjb21tYW5kIGNhbGxlZCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn PidzdGFydFRpbWUnPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ Jmx0O3N0YXJ0VGltZSZndDs8L2ZvbnQ+PC9zdHJvbmc+IGFuZCA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnPidzdG9wVGltZScuICdzdGFydFRpbWUnPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+Jmx0O3N0b3BUaW1lJmd0Oy4gJmx0O3N0YXJ0VGltZSZndDs8L2Zv bnQ+PC9zdHJvbmc+IGlkZW50aWZpZXMgdGhlCiAgIGVhcmxpZXN0IGRhdGUgYW5kIHRpbWUgb2Yg aW50ZXJlc3QgZm9yIGV2ZW50IG5vdGlmaWNhdGlvbnMgYmVpbmcKICAgcmVwbGF5ZWQgYW5kIGFs c28gaW5kaWNhdGVzIHRoYXQgYSBzdWJzY3JpcHRpb24gd2lsbCBiZSBwcm92aWRpbmcKICAgcmVw bGF5IG9mIG5vdGlmaWNhdGlvbnMuICBFdmVudHMgZ2VuZXJhdGVkIGJlZm9yZSB0aGlzIHRpbWUg YXJlIG5vdAogICBtYXRjaGVkLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPidzdG9wVGltZSc8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7c3RvcFRpbWUm Z3Q7PC9mb250Pjwvc3Ryb25nPiBzcGVjaWZpZXMgdGhlIGxhdGVzdCBkYXRlIGFuZCB0aW1lIG9m IGludGVyZXN0CiAgIGZvciBldmVudCBub3RpZmljYXRpb25zIGJlaW5nIHJlcGxheWVkLiAgSWYg aXQgaXMgbm90IHByZXNlbnQsIHRoZW4KICAgbm90aWZpY2F0aW9ucyB3aWxsIGNvbnRpbnVlIHRv IGJlIHNlbnQgdW50aWwgdGhlIHN1YnNjcmlwdGlvbiBpcwogICB0ZXJtaW5hdGVkLgoKICAgTm90 ZSB0aGF0IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c3RhcnRUaW1lPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O3N0YXJ0VGltZSZndDs8L2ZvbnQ+PC9z dHJvbmc+IGFuZCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnN0b3BUaW1lPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O3N0b3BUaW1lJmd0OzwvZm9udD48 L3N0cm9uZz4gYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgdGltZSBhbgogICBldmVudCB3YXMgZ2Vu ZXJhdGVkIGJ5IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnN5c3RlbS48L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5ldmVudCBzb3VyY2UuPC9mb250Pjwv c3Ryb25nPgoKICAgQSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnJlcGxheUNvbXBsZXRlPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O3JlcGxheUNvbXBs ZXRlJmd0OzwvZm9udD48L3N0cm9uZz4gbm90aWZpY2F0aW9uIGlzIHNlbnQgdG8gaW5kaWNhdGUg dGhhdCBhbGwgb2YgdGhlCiAgIHJlcGxheSBub3RpZmljYXRpb25zIGhhdmUgYmVlbiBzZW50LiAg SWYgdGhpcyBzdWJzY3JpcHRpb24gaGFzIGEgc3RvcAogICB0aW1lLCB0aGVuIHRoaXMgc2Vzc2lv biBiZWNvbWVzIGEgbm9ybWFsIE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz5UaGUKICAgTkVUQ09ORiBzZXJ2ZXIgd2lsbCB0aGVuIGFjY2VwdCAmbHQ7 cnBjJmd0OyBvcGVyYXRpb25zLjwvZm9udD48L3N0cm9uZz4gIEluIHRoZSBjYXNlIG9mIGEKICAg c3Vic2NyaXB0aW9uIHdpdGhvdXQgYSBzdG9wIHRpbWUsIGFmdGVyIHRoZQogICA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnPnJlcGxheUNvbXBsZXRlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+Jmx0O3JlcGxheUNvbXBsZXRlJmd0OzwvZm9udD48L3N0cm9uZz4K ICAgbm90aWZpY2F0aW9uIGhhcyBiZWVuIHNlbnQsIGl0IGNhbiBiZSBleHBlY3RlZCB0aGF0IGFu eSBub3RpZmljYXRpb25zCiAgIGdlbmVyYXRlZCBzaW5jZSB0aGUgc3RhcnQgb2YgdGhlIHN1YnNj cmlwdGlvbiBjcmVhdGlvbiB3aWxsIGJlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c2VudDwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnNlbnQsPC9mb250Pjwv c3Ryb25nPgogICBmb2xsb3dlZCBieSBub3RpZmljYXRpb25zIGFzIHRoZXkgYXJpc2UgbmF0dXJh bGx5IHdpdGhpbiB0aGUgc3lzdGVtLgoKPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zLjMuMy4g IFJlcGxheSBDb21wbGV0ZSBOb3RpZmljYXRpb248L2ZvbnQ+PC9zdHJpa2U+CgogICBUaGUgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5yZXBsYXlDb21wbGV0ZSBub3RpZmljYXRpb24gaXMgdGhl IGxhc3Qgbm90aWZpY2F0aW9uIHNlbnQgb3ZlciBhCiAgIHJlcGxheSBzdWJzY3JpcHRpb24uICBJ dCBpbmRpY2F0ZXMgdGhhdCByZXBsYXkgaXMgY29tcGxldGUuICBBZnRlcgogICB0aGlzPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Jmx0O3JlcGxheUNvbXBsZXRl Jmd0OzwvZm9udD48L3N0cm9uZz4gbm90aWZpY2F0aW9uIDxzdHJpa2U+PGZvbnQgY29sb3I9J3Jl ZCc+aXMgcmVjZWl2ZWQgdGhlIHN1YnNjcmlwdGlvbiBpcyB0ZXJtaW5hdGVkIGFuZCB0aGUKICAg c2Vzc2lvbiBiZWNvbWVzIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNlIE5FVENPTkYgc2Vzc2lvbi4K CiAgIFRoZSByZXBsYXlDb21wbGV0ZSBjYW4gbm90PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+Y2Fubm90PC9mb250Pjwvc3Ryb25nPiBiZSBmaWx0ZXJlZCBvdXQu ICBJdCB3aWxsCiAgIGFsd2F5cyBiZSBzZW50IG9uIGEgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz5yZWxheTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnJlcGxh eTwvZm9udD48L3N0cm9uZz4gc3Vic2NyaXB0aW9uIHRoYXQgc3BlY2lmaWVkIGEgc3RvcCB0aW1l LgoKMy40LiAgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQgU2NoZW1hCgogICBUaGlzIFNjaGVtYSBp cyB1c2VkIHRvIGxlYXJuIGFib3V0IHRoZSBldmVudCBzdHJlYW1zIHN1cHBvcnRlZCBvbiB0aGUK ICAgc3lzdGVtLiAgSXQgYWxzbyBjb250YWlucyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz5yZXBsYXlDb21wbGV0ZSw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7CiAgIG5vdGlmaWNh dGlvbiw8L2ZvbnQ+PC9zdHJvbmc+IHdoaWNoIGlzIHNlbnQgdG8gaW5kaWNhdGUgdGhhdCBhbiBl dmVudCByZXBsYXkgaGFzIHNlbnQKICAgYWxsIGFwcGxpY2FibGUKICAgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5ub3RpZmljYXRpb25zLiI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz5ub3RpZmljYXRpb25zLjwvZm9udD48L3N0cm9uZz4KCiZsdDs/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiZsdDt4czpzY2hlbWEgeG1sbnM6eHM9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgeG1sbnM6bmV0Y29uZj0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIgogICAgeG1sbnM6bmNFdmVudD0i dXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIgogICAg eG1sbnM6bWFuYWdlRXZlbnQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNh dGlvbiIKICAgIHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6 bm90aWZpY2F0aW9uIgogICAgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiCiAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPmF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCIm Z3Q7PC9mb250Pjwvc3RyaWtlPgogICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmF0dHJp YnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCIKICAgIHhtbDpsYW5nPSJlbiIgdmVyc2lvbj0i MS4wIiZndDs8L2ZvbnQ+PC9zdHJvbmc+CiAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAg ICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiB4bWw6bGFuZz0iZW4iJmd0OwogICAgICAgICAgICBBIHNj aGVtYSB0aGF0IGNhbiBiZSB1c2VkIHRvIGxlYXJuIGFib3V0IGN1cnJlbnQKICAgICAgICAgICAg ZXZlbnQgc3RyZWFtcy4gSXQgYWxzbwogICAgICAgICAgICBjb250YWlucyB0aGUgcmVwbGF5Q29t cGxldGUgbm90aWZpY2F0aW9uLgogICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAg ICZsdDsveHM6YW5ub3RhdGlvbiZndDsKCiZsdDt4czppbXBvcnQgbmFtZXNwYWNlPSJodHRwOi8v d3d3LnczLm9yZy9YTUwvMTk5OC9uYW1lc3BhY2UiCiAgICAgICAgc2NoZW1hTG9jYXRpb249Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEveG1sLnhzZCIvJmd0OwoKJmx0O3hzOmltcG9ydCBuYW1lc3Bh Y2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgIHNjaGVtYUxv Y2F0aW9uPQogICAgICJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3Ry eS9zY2hlbWEvbmV0Y29uZi54c2QiLyZndDsKJmx0O3hzOmltcG9ydCBuYW1lc3BhY2U9CiAgICAi dXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIgogICAg ICBzY2hlbWFMb2NhdGlvbj0KImh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJl Z2lzdHJ5L3NjaGVtYS9ub3RpZmljYXRpb24ueHNkIi8mZ3Q7CjxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz4mbHQ7IS0tIFRoZSBhYm92ZSAgc2NoZW1hTG9jYXRpb24gdmFsdWUgaXMgYSBwbGFj ZWhvbGRlciBhbmQgdGhlIGFjdHVhbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHZhbHVlIHdpbGwgYmUgYXNzaWduZWQgYnkgSUFOQSAtLSZndDs8L2ZvbnQ+PC9zdHJvbmc+ CgombHQ7eHM6ZWxlbWVudCBuYW1lPSJuZXRjb25mIiB0eXBlPSJtYW5hZ2VFdmVudDpOZXRjb25m Ii8mZ3Q7CgombHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iTmV0Y29uZiImZ3Q7CiAgJmx0O3hzOnNl cXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn Pm5hbWU9ImV2ZW50U3RyZWFtcyI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz5uYW1lPSJzdHJlYW1zIjwvZm9udD48L3N0cm9uZz4gJmd0OwogICAgICAgICZsdDt4 czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAg ICAgICAgICAgVGhlIGxpc3Qgb2YgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgYnkgdGhlCiAgICAg ICAgICAgICBzeXN0ZW0uIFdoZW4gYSBxdWVyeSBpcyBpc3N1ZWQsIHRoZSByZXR1cm5lZAogICAg ICAgICAgICAgc2V0IG9mIHN0cmVhbXMgaXMgZGV0ZXJtaW5lZCBiYXNlZCBvbiB1c2VyCiAgICAg ICAgICAgICBwcml2aWxlZ2VzLgogICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAmbHQ7eHM6Y29tcGxleFR5 cGUmZ3Q7CiAgICAgICAgICAgJmx0O3hzOnNlcXVlbmNlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3Jl ZCc+bWluT2NjdXJzPSIwIjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl ZW4nPm1pbk9jY3Vycz0iMSI8L2ZvbnQ+PC9zdHJvbmc+IG1heE9jY3Vycz0idW5ib3VuZGVkIiZn dDsKICAgICAgICAgICAgICZsdDt4czplbGVtZW50IG5hbWU9InN0cmVhbSImZ3Q7CiAgICAgICAg ICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgJmx0O3hzOmRv Y3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgU3RyZWFtIG5hbWUgYW5kIGRlc2Ny aXB0aW9uLgogICAgICAgICAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6 Y29tcGxleFR5cGUmZ3Q7CiAgICAgICAgICAgICAgICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAg ICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJuYW1lIiA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPnR5cGU9InhzOnN0cmluZyIvJmd0OwogICAgICAgICAgICAgICAgICAgICZs dDt4czplbGVtZW50IG5hbWU9ImRlc2NyaXB0aW9uIgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIi8mZ3Q7CiAgICAgICAgICAgICAgICAgICAg Jmx0O3hzOmVsZW1lbnQgbmFtZT0icmVwbGF5U3VwcG9ydCIKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOmJvb2xlYW4iLyZndDsKICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBsYXlMb2dTdGFydFRpbWUiCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6ZGF0ZVRpbWUiIG1pbk9jY3Vycz0iMCIm Z3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPnR5cGU9Im5jRXZlbnQ6c3RyZWFtTmFtZVR5cGUiJmd0OzwvZm9u dD48L3N0cm9uZz4KICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsK ICAgICAgICAgICAgICAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAg ICAgICAgICAgICAgICAgICAgICBUaGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zdGFydCB0 aW1lPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+bmFtZTwvZm9u dD48L3N0cm9uZz4gb2YgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+bG9nIHVzZWQgdG8K ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydDwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPmV2ZW50IHN0cmVhbS4gSWYgdGhpcyBpczwvZm9udD48L3N0 cm9uZz4KICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9 J3JlZCc+cmVwbGF5IGZ1bmN0aW9uLiBUaGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgIG9i amVjdCBNVVNUIGJlIHByZXNlbnQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz5kZWZhdWx0IE5FVENPTkYgc3RyZWFtLCB0aGlzIG11c3QgaGF2ZQogICAgICAgICAg ICAgICAgICAgICAgICAgICB0aGUgdmFsdWUgIk5FVENPTkYiLgogICAgICAgICAgICAgICAgICAg ICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZs dDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQm Z3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZGVzY3JpcHRpb24i CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJ4czpzdHJpbmci Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAg ICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAg ICAgICAgICAgICAgIEEgZGVzY3JpcHRpb24gb2YgdGhlIGV2ZW50IHN0cmVhbSwgaW5jbHVkaW5n CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2ggaW5mb3JtYXRpb24gYXMgdGhlIHR5cGUg b2YgZXZlbnRzIHRoYXQKICAgICAgICAgICAgICAgICAgICAgICAgICAgYXJlIHNlbnQgb3ZlciB0 aGlzIHN0cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICZs dDt4czplbGVtZW50IG5hbWU9InJlcGxheVN1cHBvcnQiCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB0eXBlPSJ4czpib29sZWFuIiZndDsKICAgICAgICAgICAgICAgICAg ICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6 ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgQW4gaW5kaWNhdGlv biBvZiB3aGV0aGVyIG9yIG5vdCBldmVudCByZXBsYXkKICAgICAgICAgICAgICAgICAgICAgICAg ICAgaXMgYXZhaWxhYmxlIG9uIHRoaXMgc3RyZWFtLgogICAgICAgICAgICAgICAgICAgICAgICAg Jmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6 YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAg ICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0icmVwbGF5TG9nU3RhcnRUaW1l IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOmRhdGVUaW1lIiBt aW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24m Z3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAg ICAgICAgICAgICAgICAgICAgICAgICBUaGUgdGltZXN0YW1wIG9mIHRoZSBlYXJsaWVzdCBhdmFp bGFibGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIGluIHRoZSBsb2cg dXNlZCB0bwogICAgICAgICAgICAgICAgICAgICAgICAgICBzdXBwb3J0IHRoZSByZXBsYXkgZnVu Y3Rpb24uIFRoaXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0IE1VU1QgYmUgcHJl c2VudDwvZm9udD48L3N0cm9uZz4gaWYgcmVwbGF5IGlzCiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHN1cHBvcnRlZC4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRh dGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAgICAgICAg ICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgJmx0Oy94czpjb21wbGV4VHlw ZSZndDsKICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgJmx0 Oy94czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICAg ICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0 Oy94czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iUmVwbGF5 Q29tcGxldGVOb3RpZmljYXRpb25UeXBlIiZndDsKICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRl bnQmZ3Q7CiAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmlj YXRpb25Db250ZW50VHlwZSIvJmd0OwogICAgICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7 CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4czplbGVtZW50IG5hbWU9InJl cGxheUNvbXBsZXRlIgogICAgICAgIHR5cGU9Im1hbmFnZUV2ZW50OlJlcGxheUNvbXBsZXRlTm90 aWZpY2F0aW9uVHlwZSIKICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmlj YXRpb25Db250ZW50IiZndDsKICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0Owog ICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgIFRoaXMgbm90aWZp Y2F0aW9uIGlzIHNlbnQgdG8gc2lnbmFsIHRoZSBlbmQgb2YgYSByZXBsYXkKICAgICAgICAgICAg cG9ydGlvbiBvZiBhIHN1YnNjcmlwdGlvbi4KCiAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRp b24mZ3Q7CiAgICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwoKICAgICAgICAmbHQ7L3hzOmVs ZW1lbnQmZ3Q7CiZsdDsveHM6c2NoZW1hJmd0OwoKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5GaWd1cmUgNzwvZm9udD48L3N0cmlrZT4K CjMuNS4gIFN1YnNjcmlwdGlvbnMgRGF0YQoKICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5X aGlsZSBpdCBtYXkgYmUgcG9zc2libGUgdG8gcmV0cmlldmUgaW5mb3JtYXRpb24gYWJvdXQgc3Vi c2NyaXB0aW9ucwogICB2aWEgYSBnZXQgb3BlcmF0aW9uLCBzdWJzY3JpcHRpb25zIGFyZSBub3Qg c3RvcmVkIGNvbmZpZ3VyYXRpb24uCiAgIFRoZXk8L2ZvbnQ+PC9zdHJpa2U+CgogICA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+U3Vic2NyaXB0aW9uczwvZm9udD48L3N0cm9uZz4gYXJlIG5v bi1wZXJzaXN0ZW50IHN0YXRlIGluZm9ybWF0aW9uIGFuZCB0aGVpciBsaWZldGltZQogICBpcyBk ZWZpbmVkIGJ5IHRoZWlyIHNlc3Npb24uCgozLjYuICBGaWx0ZXIgTWVjaGFuaWNzCgogICBXaGVu IG11bHRpcGxlIGZpbHRlciBlbGVtZW50cyBhcmUgc3BlY2lmaWVkLCB0aGV5IGFyZSBhcHBsaWVk CiAgIGNvbGxlY3RpdmVseSwgc28gZXZlbnQgbm90aWZpY2F0aW9ucyBuZWVkIHRvIHBhc3MgYWxs IHNwZWNpZmllZAogICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmZpbHRlcnM8L2ZvbnQ+PC9z dHJpa2U+CiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5maWx0ZXIgZWxlbWVudHM8L2Zv bnQ+PC9zdHJvbmc+IGluIG9yZGVyIHRvIGJlIHNlbnQgdG8gdGhlIHN1YnNjcmliZXIuICBJZiBh IGZpbHRlcgogICBlbGVtZW50IGlzIHNwZWNpZmllZCB0byBsb29rIGZvciBkYXRhIG9mIGEgcGFy dGljdWxhciB2YWx1ZSwgYW5kIHRoZQogICBkYXRhIGl0ZW0gaXMgbm90IHByZXNlbnQgd2l0aGlu IGEgcGFydGljdWxhciBldmVudCBub3RpZmljYXRpb24gZm9yCiAgIGl0cyB2YWx1ZSB0byBiZSBj aGVja2VkIGFnYWluc3QsIHRoZSBub3RpZmljYXRpb24gd2lsbCBiZSBmaWx0ZXJlZAogICBvdXQu ICBGb3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8gY2hlY2sgZm9yICdzZXZlcml0eT1jcml0aWNh bCcgaW4gYQogICBjb25maWd1cmF0aW9uIGV2ZW50IG5vdGlmaWNhdGlvbiB3aGVyZSB0aGlzIGZp ZWxkIHdhcyBub3Qgc3VwcG9ydGVkLAogICB0aGVuIHRoZSBub3RpZmljYXRpb24gd291bGQgYmUg ZmlsdGVyZWQgb3V0LgoKICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5UaGUgb3JkZXI8L2Zv bnQ+PC9zdHJpa2U+CgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Rm9yIHN1YnRyZWUg ZmlsdGVyaW5nLCBhIG5vbi1lbXB0eSBub2RlIHNldCBtZWFuczwvZm9udD48L3N0cm9uZz4gdGhh dCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmZpbHRlciBlbGVtZW50cyBhcmUgYXBwbGllZCBk b2VzIG5vdCBtYXR0ZXIgc2luY2U8L2ZvbnQ+PC9zdHJpa2U+IHRoZQogICA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPnJlc3VsdGluZyBzZXQgb2Ygbm90aWZpY2F0aW9ucyBpczwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmZpbHRlcgogICBtYXRjaGVzLiAgRm9y IFhQYXRoIGZpdGxlcmluZyw8L2ZvbnQ+PC9zdHJvbmc+IHRoZSA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnPmludGVyc2VjdGlvbiBvZjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0nZ3JlZW4nPm1lY2hhbmlzbXMgZGVmaW5lZCBpbiBbWFBBVEhdCiAgIHNob3VsZCBiZSB1c2Vk IHRvIGNvbnZlcnQ8L2ZvbnQ+PC9zdHJvbmc+IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn PnNldCBvZgogICBub3RpZmljYXRpb25zIHRoYXQgcGFzcyBlYWNoIGZpbHRlcmluZyBjcml0ZXJp YS48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5yZXR1cm5lZCB2 YWx1ZSB0byBib29sZWFuLjwvZm9udD48L3N0cm9uZz4KCjMuNi4xLiAgRmlsdGVyaW5nCgogICBG aWx0ZXJpbmcgaXMgZXhwbGljaXRseSBzdGF0ZWQgd2hlbiB0aGUgZXZlbnQgbm90aWZpY2F0aW9u CiAgIHN1YnNjcmlwdGlvbiBpcyBjcmVhdGVkLiAgVGhpcyBpcyBzcGVjaWZpZWQgdmlhIHRoZSAn ZmlsdGVyJwogICBwYXJhbWV0ZXIuICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPkZpbHRlcnM8 L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+QSBGaWx0ZXI8L2Zv bnQ+PC9zdHJvbmc+IG9ubHkgZXhpc3QgYXMgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5wYXJh bWV0ZXJzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+cGFyYW1l dGVyPC9mb250Pjwvc3Ryb25nPiB0byB0aGUgc3Vic2NyaXB0aW9uLgoKMy43LiAgTWVzc2FnZSBG bG93CiAgIFRoZSBmb2xsb3dpbmcgZmlndXJlIGRlcGljdHMgbWVzc2FnZSBmbG93IGJldHdlZW4g YSBORVRDT05GIGNsaWVudAogICAoQykgYW5kIE5FVENPTkYgc2VydmVyIChTKSBpbiBvcmRlciA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+dG88L2ZvbnQ+PC9zdHJvbmc+IGNyZWF0ZSBhIHN1 YnNjcmlwdGlvbiBhbmQKICAgYmVnaW4gdGhlIGZsb3cgb2Ygbm90aWZpY2F0aW9ucy4gIDxzdHJv bmc+PGZvbnQgY29sb3I9J2dyZWVuJz5UaGlzIHN1YnNjcmlwdGlvbiBzcGVjaWZpZWQgYQogICAm bHQ7c3RhcnRUaW1lJmd0Oywgc28gaXQgc3RhcnRzIGJ5IHJlcGxheWluZyBsb2dnZWQgbm90aWZp Y2F0aW9ucy48L2ZvbnQ+PC9zdHJvbmc+ICBJdCBpcwogICBwb3NzaWJsZSB0aGF0IG1hbnkgcnBj L3JwYy1yZXBseSBzZXF1ZW5jZXMgb2NjdXIgYmVmb3JlIHRoZQogICBzdWJzY3JpcHRpb24gaXMg PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5jcmVhdGVkIG9yIGFmdGVyIGEKICAgc3RvcFRpbWUg aW4gYSByZXBsYXkgc3Vic2NyaXB0aW9uLDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0nZ3JlZW4nPmNyZWF0ZWQsPC9mb250Pjwvc3Ryb25nPiBidXQgdGhpcyBpcyBub3QgZGVw aWN0ZWQgaW4gdGhlIGZpZ3VyZS4KCiAgICAgICAgICAgICAgICAgICAgICAgICAgQyAgICAgICAg ICAgICAgICAgICAgICAgICAgIFMKICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgIHwgIGNhcGFiaWxp dHkgZXhjaGFuZ2UgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fAogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgJmx0 O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICB8 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fAogICAgICAgICAgICAgICAgICAgICAgICAg IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgJmx0O3JwYy1yZXBseSZndDsgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICZsdDtub3RpZmljYXRpb24mZ3Q7ICAgICAgICB8CiAgICAgICAgICAgICAg ICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICZsdDtub3RpZmljYXRpb24mZ3Q7ICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiZs dDtub3RpZmljYXRpb24mZ3Q7ICAgICAgIHwgKHJlcGxheUNvbXBsZXRlKQogICAgICAgICAgICAg ICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICAgICAgIHw8L2ZvbnQ+PC9zdHJvbmc+ICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJz4mbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAg ICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICAgICAgICAgICAgICAgICAg ICAgICAgfDwvZm9udD48L3N0cm9uZz4gICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18 CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAoK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDxzdHJpa2U+PGZvbnQgY29s b3I9J3JlZCc+OAoKNC4gIFhNTCBTY2hlbWEgZm9yIEV2ZW50IE5vdGlmaWNhdGlvbnM8L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4zPC9mb250Pjwvc3Ryb25nPgog ICBUaGUgZm9sbG93aW5nIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+W1hNTCBTY2hlbWFdIGRl ZmluZXM8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5maWd1cmUg ZGVwaWN0cyBtZXNzYWdlIGZsb3cgYmV0d2VlbiBhPC9mb250Pjwvc3Ryb25nPiBORVRDT05GIDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+RXZlbnQgTm90aWZpY2F0aW9ucy4KCiZsdDs/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiAgJmx0O3hzOnNjaGVtYSB4bWxuczp4 cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiCiAgICAgICAgeG1sbnM9InVybjpp ZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMCIKICAgICAgICB4 bWxuczpuZXRjb25mPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAg ICAgICAgdGFyZ2V0TmFtZXNwYWNlPQogICAgICAgICAgInVybjppZXRmOnBhcmFtczpuZXRjb25m OmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMCIKICAgICAgICBlbGVtZW50Rm9ybURlZmF1bHQ9 InF1YWxpZmllZCIKICAgICAgICBhdHRyaWJ1dGVGb3JtRGVmYXVsdD0idW5xdWFsaWZpZWQiCiAg ICAgICAgICAgIHhtbDpsYW5nPSJlbiImZ3Q7CgogICAgJmx0OyEtLSBpbXBvcnQgc3RhbmRhcmQg WE1MIGRlZmluaXRpb25zIC0tJmd0OwoKICAgICAmbHQ7eHM6aW1wb3J0IG5hbWVzcGFjZT0iaHR0 cDovL3d3dy53My5vcmcvWE1MLzE5OTgvbmFtZXNwYWNlIgogICAgICAgICAgICAgICAgc2NoZW1h TG9jYXRpb249Imh0dHA6Ly93d3cudzMub3JnLzIwMDEveG1sLnhzZCImZ3Q7CiAgICAgICAmbHQ7 eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAg ICAgICAgVGhpcyBpbXBvcnQgYWNjZXNzZXMgdGhlIHhtbDogYXR0cmlidXRlIGdyb3VwcyBmb3Ig dGhlCiAgICAgICAgICAgeG1sOmxhbmcgYXMgZGVjbGFyZWQgb248L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5jbGllbnQKICAgKEMpIGFuZCBORVRDT05GIHNlcnZl ciAoUykgaW4gb3JkZXIgdG8gY3JlYXRlIGEgc3Vic2NyaXB0aW9uIGFuZAogICBiZWdpbjwvZm9u dD48L3N0cm9uZz4gdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZXJyb3ItbWVzc2FnZSBl bGVtZW50LgogICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAmbHQ7L3hz OmFubm90YXRpb24mZ3Q7CiAgICAgJmx0Oy94czppbXBvcnQmZ3Q7CgogICAgICZsdDshLS0gaW1w b3J0IGJhc2U8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5mbG93 IG9mIG5vdGlmaWNhdGlvbnMuICBUaGlzIHN1YnNjcmlwdGlvbiBzcGVjaWZpZWQgYQogICAmbHQ7 c3RhcnRUaW1lJmd0OyBhbmQgJmx0O3N0b3BUaW1lJmd0OyBzbyBpdCBzdGFydHMgYnkgcmVwbGF5 aW5nIGxvZ2dlZAogICBub3RpZmljYXRpb25zIGFuZCB0aGVuIHJldHVybnMgdG8gYmUgYSBub3Jt YWwgY29tbWFuZC1yZXNwb25zZQogICBORVRDT05GIHNlc3Npb24gYWZ0ZXIgdGhlICZsdDtyZXBs YXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzIHNlbnQgYW5kCiAgIGlzIGF2YWlsYWJsZSB0 byBwcm9jZXNzICZsdDtycGMmZ3Q7IHJlcXVlc3RzLiAgSXQgaXMgcG9zc2libGUgdGhhdCBtYW55 CiAgIHJwYy9ycGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0aGUgc3Vic2NyaXB0aW9u IGlzIGNyZWF0ZWQsIGJ1dAogICB0aGlzIGlzIG5vdCBkZXBpY3RlZCBpbiB0aGUgZmlndXJlLgoK ICAgICAgICAgICAgICAgICAgICAgICAgICBDICAgICAgICAgICAgICAgICAgICAgICAgICAgUwog ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fAog ICAgICAgICAgICAgICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZn dDt8CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZn dDsgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLXwKICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7cnBjLXJlcGx5 Jmd0OyAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlm aWNhdGlvbiZndDsgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0 O25vdGlmaWNhdGlvbiZndDsgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICB8Jmx0 Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICB8IChyZXBsYXlDb21wbGV0ZSkKICAgICAg ICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgJmx0O3JwYyZndDsgICAgICAgICAgICB8CiAg ICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wK ICAgICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t fAogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgJmx0O3JwYy1yZXBseSZndDsgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA0Cgo0LiAgWE1M IFNjaGVtYSBmb3IgRXZlbnQgTm90aWZpY2F0aW9ucwoKICAgVGhlIGZvbGxvd2luZyBbWE1MIFNj aGVtYV0gZGVmaW5lcyBORVRDT05GIEV2ZW50IE5vdGlmaWNhdGlvbnMuCgombHQ7P3htbCB2ZXJz aW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwogICZsdDt4czpzY2hlbWEgeG1sbnM6eHM9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgIHhtbG5zPSJ1cm46aWV0Zjpw YXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAiCiAgICAgeG1sbnM6bmV0 Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIgogICAgIHRhcmdl dE5hbWVzcGFjZT0KICAgICAgICAidXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpu b3RpZmljYXRpb246MS4wIgogICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIgogICAg IGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCIKICAgICAgIHhtbDpsYW5nPSJlbiIm Z3Q7CgogICAgJmx0OyEtLSBpbXBvcnQgc3RhbmRhcmQgWE1MIGRlZmluaXRpb25zIC0tJmd0OwoK ICAgICAmbHQ7eHM6aW1wb3J0IG5hbWVzcGFjZT0iaHR0cDovL3d3dy53My5vcmcvWE1MLzE5OTgv bmFtZXNwYWNlIgogICAgICAgICAgICAgICAgc2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cudzMu b3JnLzIwMDEveG1sLnhzZCImZ3Q7CiAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAg ICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgVGhpcyBpbXBvcnQgYWNjZXNz ZXMgdGhlIHhtbDogYXR0cmlidXRlIGdyb3VwcyBmb3IgdGhlCiAgICAgICAgICAgeG1sOmxhbmcg YXMgZGVjbGFyZWQgb24gdGhlIGVycm9yLW1lc3NhZ2UgZWxlbWVudC4KICAgICAgICAgJmx0Oy94 czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICZs dDsveHM6aW1wb3J0Jmd0OwoKICAgICAmbHQ7IS0tIGltcG9ydCBiYXNlPC9mb250Pjwvc3Ryb25n PiBuZXRjb25mIGRlZmluaXRpb25zIC0tJmd0OwogICAgICZsdDt4czppbXBvcnQgbmFtZXNwYWNl PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICAgICBzY2hlbWFM b2NhdGlvbj0KICAgICAiaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy94bWwtcmVnaXN0 cnkvc2NoZW1hL25ldGNvbmYueHNkIi8mZ3Q7CgombHQ7IS0tICoqKioqKioqKioqKioqIFN5bW1l dHJpY2FsIE9wZXJhdGlvbnMgICoqKioqKioqKioqKioqKioqKioqLS0mZ3Q7CgogICAgICZsdDsh LS0gJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IG9wZXJhdGlvbiAtLSZndDsKCiAgICAmbHQ7 eHM6Y29tcGxleFR5cGUgbmFtZT0iY3JlYXRlU3Vic2NyaXB0aW9uVHlwZSImZ3Q7CiAgICAgICAg Jmx0O3hzOmNvbXBsZXhDb250ZW50Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJh c2U9Im5ldGNvbmY6cnBjT3BlcmF0aW9uVHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6 c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3Ry ZWFtIgogICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJzdHJlYW1OYW1lVHlwZSIgbWluT2Nj dXJzPSIwIiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGlu ZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggc3RyZWFtIG9mIGV2 ZW50cyBpcyBvZiBpbnRlcmVzdC4gSWYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5v dCBwcmVzZW50LCB0aGVuIGV2ZW50cyBpbiB0aGUgZGVmYXVsdAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTkVUQ09ORiBzdHJlYW0gd2lsbCBiZSBzZW50LgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpl bGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJm aWx0ZXIiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJuZXRjb25mOmZpbHRlcklu bGluZVR5cGUiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiJmd0Owog ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGlu ZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaCBzdWJzZXQg b2YgYWxsIHBvc3NpYmxlIGV2ZW50cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmFyZTwvZm9udD48L3N0cmlrZT4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmlz PC9mb250Pjwvc3Ryb25nPiBvZiBpbnRlcmVzdC4gVGhlIGZvcm1hdCBvZiB0aGlzCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciBpcyB0aGUgc2FtZSBhcyB0aGF0 IG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXIgcGFyYW1l dGVyIGluIHRoZSBORVRDT05GCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBy b3RvY29sIG9wZXJhdGlvbnMuIElmIG5vdCBwcmVzZW50LAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBhbGwgZXZlbnRzIG5vdCBwcmVjbHVkZWQgYnkgb3RoZXIKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVycyB3aWxsIGJlIHNlbnQuCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0 O3hzOmVsZW1lbnQgbmFtZT0ic3RhcnRUaW1lIiB0eXBlPSJ4czpkYXRlVGltZSIKICAgICAgICAg ICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiAmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAg ICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hz OmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQSBwYXJh bWV0ZXIgdXNlZCB0byB0cmlnZ2VyIHRoZSByZXBsYXkKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBmZWF0dXJlIGFuZCBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVwbGF5CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIHN0YXJ0IGF0IHRoZSB0aW1lIHNwZWNpZmllZC4g SWYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFydCB0aW1lIGlzIG5vdCBwcmVz ZW50LCB0aGlzIGlzIG5vdCBhCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVwbGF5 IHN1YnNjcmlwdGlvbi4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1l bnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzdG9wVGltZSIgdHlwZT0ieHM6ZGF0ZVRpbWUiCiAg ICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEFuIG9wdGlvbmFsIHBhcmFtZXRlciB1c2VkIHdpdGggdGhlCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgdG8gaW5kaWNhdGUgdGhlCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3ZXN0IG5vdGlmaWNhdGlvbnMgb2YgaW50ZXJl c3QuIElmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RvcCB0aW1lIGlzIG5vdCBw cmVzZW50LCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3RpZmljYXRpb25z IHdpbGwgY29udGludWUgdW50aWwgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuIE11c3QgYmUgdXNlZAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHdpdGggPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4nc3RhcnRUaW1l Jy48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zdGFydFRpbWUu PC9mb250Pjwvc3Ryb25nPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1 bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24m Z3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAg ICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAgJmx0Oy94czpleHRlbnNpb24mZ3Q7 CiAgICAgICAgJmx0Oy94czpjb21wbGV4Q29udGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5 cGUmZ3Q7CgogICAgJmx0O3hzOnNpbXBsZVR5cGUgbmFtZT0ic3RyZWFtTmFtZVR5cGUiJmd0Owog ICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRh dGlvbiZndDsKICAgICAgICAgICAgICAgIFRoZSBuYW1lIG9mIGFuIGV2ZW50IHN0cmVhbS4KICAg ICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3Rh dGlvbiZndDsKICAgICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIi8mZ3Q7 CiAgICAmbHQ7L3hzOnNpbXBsZVR5cGUmZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY3Jl YXRlLXN1YnNjcmlwdGlvbiIKICAgICAgICB0eXBlPSJjcmVhdGVTdWJzY3JpcHRpb25UeXBlIgog ICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuZXRjb25mOnJwY09wZXJhdGlvbiImZ3Q7CiAgICAg ICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9u Jmd0OwogICAgICAgICAgICAgICAgVGhlIGNvbW1hbmQgdG8gY3JlYXRlIGEgbm90aWZpY2F0aW9u IHN1YnNjcmlwdGlvbi4gSXQKICAgICAgICAgICAgICAgIHRha2VzIGFzIGFyZ3VtZW50IHRoZSBu YW1lIG9mIHRoZSBub3RpZmljYXRpb24gc3RyZWFtCiAgICAgICAgICAgICAgICBhbmQgIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCc+ZmlsdGVyIG9yIHByb2ZpbGUgaW5mb3JtYXRpb24uPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ZmlsdGVyLjwvZm9udD48L3N0 cm9uZz4gQWxsIG9mIHRob3NlIG9wdGlvbnMKICAgICAgICAgICAgICAgIGxpbWl0IHRoZSBjb250 ZW50IG9mIHRoZSBzdWJzY3JpcHRpb24uIEluIGFkZGl0aW9uLAogICAgICAgICAgICAgICAgdGhl cmUgYXJlIHR3byB0aW1lLXJlbGF0ZWQgcGFyYW1ldGVycyBzdGFydFRpbWUgYW5kCiAgICAgICAg ICAgICAgICBzdG9wVGltZSB3aGljaCBjYW4gYmUgdXNlZCB0byBzZWxlY3QgdGhlIHRpbWUgaW50 ZXJ2YWwKICAgICAgICAgICAgICAgIG9mIGludGVyZXN0LgogICAgICAgICAgICAmbHQ7L3hzOmRv Y3VtZW50YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgJmx0Oy94 czplbGVtZW50Jmd0OwoKJmx0OyEtLSAqKioqKioqKioqKioqKiBPbmUtd2F5IE9wZXJhdGlvbnMg ICoqKioqKioqKioqKioqKioqKi0tJmd0OwoKICAgICAmbHQ7IS0tICZsdDtOb3RpZmljYXRpb24m Z3Q7IG9wZXJhdGlvbiAtLSZndDsKICAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iTm90aWZp Y2F0aW9uQ29udGVudFR5cGUiLyZndDsKCiAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJub3RpZmlj YXRpb25Db250ZW50IgogICAgICAgIHR5cGU9Ik5vdGlmaWNhdGlvbkNvbnRlbnRUeXBlIiBhYnN0 cmFjdD0idHJ1ZSIvJmd0OwoKICAgICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJOb3RpZmljYXRp b25UeXBlIiZndDsKICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICZsdDt4 czplbGVtZW50IHJlZj0ibm90aWZpY2F0aW9uQ29udGVudCIvJmd0OwogICAgICAgICZsdDsveHM6 c2VxdWVuY2UmZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4czplbGVt ZW50IG5hbWU9Im5vdGlmaWNhdGlvbiIgdHlwZT0iTm90aWZpY2F0aW9uVHlwZSIvJmd0OwogICZs dDsveHM6c2NoZW1hJmd0OwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz5GaWd1cmUgOTwvZm9udD48L3N0cmlrZT4KCjUuICBGaWx0ZXJp bmcgRXhhbXBsZXMKCiAgIFRoZSBmb2xsb3dpbmcgc2VjdGlvbiBwcm92aWRlcyBleGFtcGxlcyB0 byBpbGx1c3RyYXRlIHRoZSB2YXJpb3VzCiAgIG1ldGhvZHMgb2YgZmlsdGVyaW5nIGNvbnRlbnQg b24gYW4gZXZlbnQgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4KCjxzdHJpa2U+PGZvbnQgY29s b3I9J3JlZCc+NS4xLiAgU3VidHJlZSBGaWx0ZXJpbmcKCiAgIFhNTCBzdWJ0cmVlIGZpbHRlcmlu ZyBpcyBub3Qgd2VsbCBzdWl0ZWQgZm9yIGNyZWF0aW5nIGVsYWJvcmF0ZQogICBmaWx0ZXIgZGVm aW5pdGlvbnMgZ2l2ZW4gdGhhdCBpdCBvbmx5IHN1cHBvcnRzIGVxdWFsaXR5IGNvbXBhcmlzb25z CiAgIGFuZCBsb2dpY2FsIE9SIG9wZXJhdGlvbnMgKGUuZy4sIGluIGFuIGV2ZW50IHN1YnRyZWUg Z2l2ZSBtZSBhbGwKICAgZXZlbnQgbm90aWZpY2F0aW9ucyB3aGljaCBoYXZlIHNldmVyaXR5PWNy aXRpY2FsIG9yIHNldmVyaXR5PW1ham9yIG9yCiAgIHNldmVyaXR5PW1pbm9yKS4gIE5ldmVydGhl bGVzcywgaXQgbWF5IGJlIHVzZWQgZm9yIGRlZmluaW5nIHNpbXBsZQogICBldmVudCBub3RpZmlj YXRpb24gZm9yd2FyZGluZyBmaWx0ZXJzIGFzIHNob3duIGJlbG93LjwvZm9udD48L3N0cmlrZT4K CiAgIEluIG9yZGVyIHRvIGlsbHVzdHJhdGUgdGhlIHVzZSBvZiBmaWx0ZXIgPHN0cmlrZT48Zm9u dCBjb2xvcj0ncmVkJz5leHByZXNzaW9uczwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0nZ3JlZW4nPmV4cHJlc3Npb25zLDwvZm9udD48L3N0cm9uZz4gaXQgaXMgbmVjZXNzYXJ5 CiAgIHRvIGFzc3VtZSBzb21lIG9mIHRoZSBldmVudCBub3RpZmljYXRpb24gY29udGVudC4gIFRo ZSBleGFtcGxlcwogICBoZXJlaW4gYXNzdW1lIHRoYXQgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBz Y2hlbWEgZGVmaW5pdGlvbiBoYXMgYW4KICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4mbHQ7 ZXZlbnRzJmd0OzwvZm9udD48L3N0cmlrZT4KICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n PiZsdDtldmVudCZndDs8L2ZvbnQ+PC9zdHJvbmc+IGVsZW1lbnQgYXQgdGhlIHRvcCBsZXZlbCA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnRoYXQgY29udGFpbnMgb25lIG9yIG1vcmUgY2hpbGQK ICAgZWxlbWVudHMgJmx0O2V2ZW50RW50cnkmZ3Q7PC9mb250Pjwvc3RyaWtlPiBjb25zaXN0aW5n IG9mIHRoZSBldmVudCBjbGFzcyAoZS5nLiwKICAgZmF1bHQsIHN0YXRlLCA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPmNvbmZpZywgZXRjLik8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz5jb25maWcpPC9mb250Pjwvc3Ryb25nPiByZXBvcnRpbmcgZW50aXR5IGFu ZCBlaXRoZXIgc2V2ZXJpdHkgb3IKICAgb3BlcmF0aW9uYWwgc3RhdGUuCgogICA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnPlNhbXBsZSBldmVudCBsaXN0CgogICAgICAgICAgICAgICAgICAgICZs dDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtmYXVsdCZsdDsvZXZlbnRDbGFzcyZndDsK ICAgICAgICAgICAgICAgICAgICAgICZsdDtyZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAg ICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAg ICAgICAgICAgICAgICZsdDsvcmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAgICAgICAg ICAgJmx0O3NldmVyaXR5Jmd0O21ham9yJmx0Oy9zZXZlcml0eSZndDsKICAgICAgICAgICAgICAg ICAgICAmbHQ7L2V2ZW50Jmd0OwoKICAgICAgICAgICAgICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9 Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAg Jmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAgICAg ICAgICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAm bHQ7Y2FyZCZndDtFdGhlcm5ldDImbHQ7L2NhcmQmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAm bHQ7L3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAgICAgICAgICAgICZsdDtzZXZlcml0 eSZndDtjcml0aWNhbCZsdDsvc2V2ZXJpdHkmZ3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0Oy9l dmVudCZndDsKCiAgICAgICAgICAgICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhh bXBsZS5jb20vZXZlbnQvMS4wIiZndDs8L2ZvbnQ+PC9zdHJpa2U+CgogICA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+RXhhbXBsZXMgaW4gdGhpcyBzZWN0aW9uIGFyZSBnZW5lcmF0ZWQgZnJv bSB0aGUgZm9sbG93aW5nIGZpY3Rpb25hbAogICBTY2hlbWEuCgogJmx0Oz94bWwgdmVyc2lvbj0i MS4wIiBlbmNvZGluZz0iVVRGLTgiPyZndDsKJmx0O3hzOnNjaGVtYSB0YXJnZXROYW1lc3BhY2U9 Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiCiAgICB4bWxucz0iaHR0cDovL2V4YW1wbGUu Y29tL2V2ZW50LzEuMCIKICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIgogICAgeG1s bnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgeG1sbnM6bmNFdmVu dD0idXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIiZn dDsKCiAgICAmbHQ7eHM6aW1wb3J0IG5hbWVzcGFjZT0KICAgICAgICAidXJuOmlldGY6cGFyYW1z Om5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIgogICAgICAgIHNjaGVtYUxvY2F0 aW9uPQoiaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy94bWwtcmVnaXN0cnkvc2NoZW1h L25vdGlmaWNhdGlvbi54c2QiLyZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iZXZl bnRUeXBlIiZndDsKICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAgICAgICAg ICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmljYXRpb25Db250ZW50VHlwZSIm Z3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAg ICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZXZlbnRDbGFzcyIgLyZndDsKICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBvcnRpbmdFbnRpdHkiJmd0OwogICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJmx0O3hzOmFueSBuYW1lc3BhY2U9IiMjYW55IgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHByb2Nlc3NDb250ZW50cz0ibGF4Ii8mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hz OmNvbXBsZXhUeXBlJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsK ICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6Y2hvaWNlJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXZlcml0eSIvJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJvcGVyU3RhdGUiLyZndDsKICAgICAgICAgICAg ICAgICAgICAmbHQ7L3hzOmNob2ljZSZndDsKICAgICAgICAgICAgICAgICZsdDsveHM6c2VxdWVu Y2UmZ3Q7CiAgICAgICAgICAgICZsdDsveHM6ZXh0ZW5zaW9uJmd0OwogICAgICAgICZsdDsveHM6 Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4 czplbGVtZW50IG5hbWU9ImV2ZW50IgogICAgICAgIHR5cGU9ImV2ZW50VHlwZSIKICAgICAgICBz dWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmljYXRpb25Db250ZW50Ii8mZ3Q7CgombHQ7 L3hzOnNjaGVtYSZndDsKICAgVGhlIGFib3ZlIGZpY3Rpb25hbCBub3RpZmljYXRpb24gZGVmaW5p dGlvbiBjb3VsZCByZXN1bHRzIGZvbGxvd2luZwogICBpcyBhIHNhbXBsZSBub3RpZmljYXRpb24g bGlzdCB1c2VkIGluIHRoZSBleGFtcGxlcyBpbiB0aGlzIHNlY3Rpb24uCgogICAmbHQ7bm90aWZp Y2F0aW9uCiAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5v dGlmaWNhdGlvbjoxLjAiJmd0OwogICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxl LmNvbS9ldmVudC8xLjAiJmd0OwogICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtmYXVsdCZsdDsv ZXZlbnRDbGFzcyZndDsKICAgICAgICAgJmx0O3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAg ICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgJmx0Oy9yZXBv cnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICZsdDtzZXZlcml0eSZndDttYWpvciZsdDsvc2V2ZXJp dHkmZ3Q7CiAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAmbHQ7L25vdGlmaWNhdGlvbiZndDsKCiAg ICZsdDtub3RpZmljYXRpb24KICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2Fw YWJpbGl0eTpub3RpZmljYXRpb246MS4wIiZndDsKICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRw Oi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICZsdDtldmVudENsYXNzJmd0 O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0O3JlcG9ydGluZ0VudGl0eSZn dDsKICAgICAgICAgICAgICAmbHQ7Y2FyZCZndDtFdGhlcm5ldDImbHQ7L2NhcmQmZ3Q7CiAgICAg ICAgICAmbHQ7L3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICZsdDtzZXZlcml0eSZndDtj cml0aWNhbCZsdDsvc2V2ZXJpdHkmZ3Q7CiAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAmbHQ7L25v dGlmaWNhdGlvbiZndDsKCiAgICZsdDtub3RpZmljYXRpb24KICAgICB4bWxucz0idXJuOmlldGY6 cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIiZndDsKICAgICAgJmx0 O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDs8L2ZvbnQ+PC9z dHJvbmc+CiAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtmYXVsdCZsdDsvZXZlbnRDbGFzcyZn dDsKICAgICAgICAgICZsdDtyZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAgICZsdDtj YXJkJmd0O0FUTTEmbHQ7L2NhcmQmZ3Q7CiAgICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkm Z3Q7CiAgICAgICAgICAgJmx0O3NldmVyaXR5Jmd0O21pbm9yJmx0Oy9zZXZlcml0eSZndDsKICAg ICAgJmx0Oy9ldmVudCZndDsKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiZsdDsvbm90 aWZpY2F0aW9uJmd0OwoKICAgJmx0O25vdGlmaWNhdGlvbgogICAgIHhtbG5zPSJ1cm46aWV0Zjpw YXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAiJmd0OzwvZm9udD48L3N0 cm9uZz4KICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAi Jmd0OwogICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtzdGF0ZSZsdDsvZXZlbnRDbGFzcyZndDsK ICAgICAgICAgJmx0O3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAgICZsdDtjYXJkJmd0 O0V0aGVybmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7 CiAgICAgICAgICZsdDtvcGVyU3RhdGUmZ3Q7ZW5hYmxlZCZsdDsvb3BlclN0YXRlJmd0OwogICAg ICAmbHQ7L2V2ZW50Jmd0OwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz5GaWd1cmUgMTA8L2ZvbnQ+PC9zdHJpa2U+CiAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7L25vdGlmaWNhdGlvbiZndDsKCjUuMS4gIFN1YnRyZWUg RmlsdGVyaW5nCgogICBYTUwgc3VidHJlZSBmaWx0ZXJpbmcgaXMgbm90IHdlbGwtc3VpdGVkIGZv ciBjcmVhdGluZyBlbGFib3JhdGUKICAgZmlsdGVyIGRlZmluaXRpb25zIGdpdmVuIHRoYXQgaXQg b25seSBzdXBwb3J0cyBlcXVhbGl0eSBjb21wYXJpc29ucwogICBhbmQgYXBwbGljYXRpb24gb2Yg dGhlIGxvZ2ljYWwgT1Igb3BlcmF0b3JzIChlLmcuLCBpbiBhbiBldmVudAogICBzdWJ0cmVlIGdp dmUgbWUgYWxsIGV2ZW50IG5vdGlmaWNhdGlvbnMgd2hpY2ggaGF2ZSBzZXZlcml0eT1jcml0aWNh bAogICBvciBzZXZlcml0eT1tYWpvciBvciBzZXZlcml0eT1taW5vcikuICBOZXZlcnRoZWxlc3Ms IGl0IG1heSBiZSB1c2VkCiAgIGZvciBkZWZpbmluZyBzaW1wbGUgZXZlbnQgbm90aWZpY2F0aW9u IGZvcndhcmRpbmcgZmlsdGVycyBhcyBzaG93bgogICBiZWxvdy48L2ZvbnQ+PC9zdHJvbmc+Cgog ICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgaWxsdXN0cmF0ZXMgPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJz5zZWxlY3Rpbmc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz5ob3cgdG8gc2VsZWN0PC9mb250Pjwvc3Ryb25nPiBldmVudHMgd2hpY2ggaGF2ZQogICBzZXZl cml0aWVzIG9mIGNyaXRpY2FsLCBtYWpvciwgb3IgbWlub3IgKHByZXN1bWFibHkgZmF1bHQgZXZl bnRzKS4KICAgVGhlIGZpbHRlcmluZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6 CgogICAoKHNldmVyaXR5PWNyaXRpY2FsKSB8IChzZXZlcml0eT1tYWpvcikgfCAoc2V2ZXJpdHk9 bWlub3IpKQoKICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgog ICAgICAgICAgICAgIHhtbG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29u ZjpiYXNlOjEuMCImZ3Q7CiAgICAgICAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24KICAgICAgICAg ICAgeG1sbnM9InVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9u OjEuMCImZ3Q7CiAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlwZT0ic3VidHJlZSImZ3Q7 CiAgICAgICAgICAgICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEu MCImZ3Q7CiAgICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xh c3MmZ3Q7CiAgICAgICAgICAgICAgJmx0O3NldmVyaXR5Jmd0O2NyaXRpY2FsJmx0Oy9zZXZlcml0 eSZndDsKICAgICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAgICAgJmx0O2V2ZW50IHht bG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgICAmbHQ7 ZXZlbnRDbGFzcyZndDtmYXVsdCZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgICAgICAmbHQ7 c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAgICAgICAmbHQ7L2V2ZW50 Jmd0OwogICAgICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVu dC8xLjAiJmd0OwogICAgICAgICAgICAgICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVu dENsYXNzJmd0OwogICAgICAgICAgICAgICZsdDtzZXZlcml0eSZndDttaW5vciZsdDsvc2V2ZXJp dHkmZ3Q7CiAgICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICAgICAgICAmbHQ7L2ZpbHRlciZn dDsKICAgICAgICAmbHQ7L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgICAgICZsdDsvbmV0Y29u ZjpycGMmZ3Q7CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPkZpZ3VyZSAxMTwvZm9udD48L3N0cmlrZT4KCiAgIFRoZSBmb2xsb3dpbmcg ZXhhbXBsZSBpbGx1c3RyYXRlcyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnNlbGVjdGluZzwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmhvdyB0byBzZWxlY3Q8 L2ZvbnQ+PC9zdHJvbmc+IHN0YXRlIG9yIGNvbmZpZwogICBFdmVudENsYXNzZXMgb3IgZmF1bHQg ZXZlbnRzIHRoYXQgYXJlIHJlbGF0ZWQgdG8gY2FyZCBFdGhlcm5ldDAuICBUaGUKICAgZmlsdGVy aW5nIGNyaXRlcmlhIGV2YWx1YXRpb24gaXMgYXMgZm9sbG93czoKCiAgICggc3RhdGUgfCBjb25m aWcgfCA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+KDwvZm9udD48L3N0cm9uZz4gZmF1bHQg JmFtcDsgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5jYXJkPUV0aGVybmV0MCk8L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4oIHNldmVyaXR5PWNyaXRpY2FsIHwg c2V2ZXJpdHk9bWFqb3IgfAogICBzZXZlcml0eSA9IG1pbm9yIHwgY2FyZD1FdGhlcm5ldDApKSk8 L2ZvbnQ+PC9zdHJvbmc+CiAgICZsdDtuZXRjb25mOnJwYyBuZXRjb25mOm1lc3NhZ2UtaWQ9IjEw MSIKICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25m OmJhc2U6MS4wIiZndDsKICAgICAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24KICAgICAgICAgICAg eG1sbnM9InVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEu MCImZ3Q7CiAgICAgICAgICZsdDtmaWx0ZXIgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5uZXRj b25mOnR5cGU9InN1YnRyZWUiJmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8v ZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7 ZmF1bHQmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAg ICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAg ICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7c3RhdGUmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAg ICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhh bXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7Y29u ZmlnJmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAg ICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAg ICAgICAgICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAg ICAgICAmbHQ7cmVwb3J0aW5nRWxlbWVudCZndDsKICAgICAgICAgICAgICAmbHQ7Y2FyZCZndDtF dGhlcm5ldDAmbHQ7L2NhcmQmZ3Q7CiAgICAgICAgICAgICZsdDsvcmVwb3J0aW5nRWxlbWVudCZn dDsKICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICAgICAgJmx0Oy9maWx0ZXImZ3Q7PC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+bmV0Y29uZjp0eXBlPSJ4cGF0 aCIKICAgICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4w IgogICAgICAgICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbCiAgICAgICAgICAgICAgICAgICAg KGV4OmV2ZW50Q2xhc3M9J3N0YXRlJyBvcgogICAgICAgICAgICAgICAgICAgICBleDpldmVudENs YXNzPSdjb25maWcnIG9yCiAgICAgICAgICAgICAgICAgICAgIGV4OmV2ZW50Q2xhc3M9J2ZhdWx0 JykgYW5kCiAgICAgICAgICAgICAgICAgICAgICAgKGV4OnNldmVyaXR5PSdtaW5vcicgb3IKICAg ICAgICAgICAgICAgICAgICAgICAgZXg6c2V2ZXJpdHk9J21ham9yJyBvcgogICAgICAgICAgICAg ICAgICAgICAgICBleDpzZXZlcml0eT0nY3JpdGljYWwnIG9yCiAgICAgICAgICAgICAgICAgICAg ICAgIGV4OnJlcG9ydGluZ0VudGl0eS9leDpjYXJkPSdFdGhlcm5ldDAnKV0vJmd0OzwvZm9udD48 L3N0cm9uZz4KICAgICAmbHQ7L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgICZsdDsvbmV0Y29u ZjpycGMmZ3Q7Cgo1LjIuICBYUEFUSCBmaWx0ZXJzCgogICBUaGUgZm9sbG93aW5nIFtYUEFUSF0g ZXhhbXBsZSBpbGx1c3RyYXRlcyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnNlbGVjdGluZzwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmhvdyB0byBzZWxlY3Q8 L2ZvbnQ+PC9zdHJvbmc+IGZhdWx0CiAgIEV2ZW50Q2xhc3Mgbm90aWZpY2F0aW9ucyB0aGF0IGhh dmUgc2V2ZXJpdGllcyBvZiBjcml0aWNhbCwgbWFqb3IsIG9yCiAgIG1pbm9yLiAgVGhlIGZpbHRl cmluZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoKGZhdWx0KSAmYW1w OyAoKHNldmVyaXR5PWNyaXRpY2FsKSB8IChzZXZlcml0eT1tYWpvcikgfCAoc2V2ZXJpdHkgPQog ICBtaW5vcikpKQoKICAgICZsdDtuZXRjb25mOnJwYyBuZXRjb25mOm1lc3NhZ2UtaWQ9IjEwMSIK ICAgICAgICAgICAgICB4bWxuczpuZXRjb25mPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6YmFzZToxLjAiJmd0OwogICAgICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbgogICAgICAgICAg ICB4bWxucz0idXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246 MS4wIiZndDsKICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiCiAgICAgICAg ICAgICAgICB4bWxuczpleD0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCIKICAgICAgICAg ICBzZWxlY3Q9Ii9leDpldmVudFtleDpldmVudENsYXNzPSdmYXVsdCcgYW5kCiAgICAgICAgICAg ICAgICAoZXg6c2V2ZXJpdHk9J21pbm9yJyBvciBleDpzZXZlcml0eT0nbWFqb3InCiAgICAgICAg ICAgICAgICAgICAgIG9yIGV4OnNldmVyaXR5PSdjcml0aWNhbCcpXSIvJmd0OwogICAgICAmbHQ7 L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgICAmbHQ7L25ldGNvbmY6cnBjJmd0OwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPkZpZ3Vy ZSAxMzwvZm9udD48L3N0cmlrZT4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3RyYXRl cyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnNlbGVjdGluZzwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmhvdyB0byBzZWxlY3Q8L2ZvbnQ+PC9zdHJvbmc+IHN0 YXRlIGFuZCBjb25maWcKICAgRXZlbnRDbGFzc2VzIG9yIGZhdWx0IGV2ZW50cyB0aGF0IGhhdmUg c2V2ZXJpdGllcyBvZiBjcml0aWNhbCwgbWFqb3IsCiAgIG9yIG1pbm9yIG9yIGNvbWUgZnJvbSBj YXJkIEV0aGVybmV0MC4gIFRoZSBmaWx0ZXJpbmcgY3JpdGVyaWEKICAgZXZhbHVhdGlvbiBpcyBh cyBmb2xsb3dzOgoKICAgKCggc3RhdGUgfCBjb25maWcpICZhbXA7ICgoZmF1bHQgJmFtcDsgc2V2 ZXJpdHk9Y3JpdGljYWwpIHwgKGZhdWx0ICZhbXA7CiAgIHNldmVyaXR5PW1ham9yKSB8IChmYXVs dCAmYW1wOyBzZXZlcml0eSA9IG1pbm9yKSB8IChmYXVsdCAmYW1wOwogICBjYXJkPUV0aGVybmV0 MCkpKQoKICAgICAmbHQ7bmV0Y29uZjpycGMgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5uZXRj b25mOm1lc3NhZ2UtaWQ9IjEwMSI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz5tZXNzYWdlLWlkPSIxMDEiPC9mb250Pjwvc3Ryb25nPgogICAgICAgICAgICAgeG1s bnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsK ICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uCiAgICAgICAgICB4bWxucz0idXJuOmlldGY6 cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIiZndDsKICAgICAgICAg ICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9InhwYXRoIgogICAgICAgICAgICAgICAgICAgIHht bG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIgogICAgICAgICAgICAgICBzZWxl Y3Q9Ii9leDpldmVudFsKICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSdy ZWQnPmV4OmV2ZW50Q2xhc3M9J2ZhdWx0JzwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAg ICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPihleDpldmVudENsYXNzPSdzdGF0ZScgb3Ig ZXg6ZXZlbnRDbGFzcz0nY29uZmlnJyk8L2ZvbnQ+PC9zdHJvbmc+IGFuZCA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPmV4OnNldmVyaXR5PSdtaW5vcicpPC9mb250Pjwvc3RyaWtlPgogICAgICAg ICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+KChleDpldmVudENsYXNzPSdm YXVsdCcgYW5kIGV4OnNldmVyaXR5PSdjcml0aWNhbCcpPC9mb250Pjwvc3Ryb25nPiBvcgogICAg ICAgICAgICAgICAgICAgKGV4OmV2ZW50Q2xhc3M9J2ZhdWx0JyBhbmQgZXg6c2V2ZXJpdHk9J21h am9yJykgb3IKICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmV4 OmV2ZW50Q2xhc3M9J2ZhdWx0JzwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICAgIDxz dHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4oZXg6ZXZlbnRDbGFzcz0nZmF1bHQnPC9mb250Pjwv c3Ryb25nPiBhbmQgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5leDpzZXZlcml0eT0nY3JpdGlj YWwnKTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmV4OnNldmVy aXR5PSdtaW5vcicpPC9mb250Pjwvc3Ryb25nPiBvcgogICAgICAgICAgICAgICAgICAgKGV4OmV2 ZW50Q2xhc3M9J2ZhdWx0JyBhbmQKICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNv bG9yPSdyZWQnPmV4OnJlcG9ydGluZ0VsZW1lbnQvZXg6Y2FyZD0nRXRoZXJuZXQwJykgb3IKICAg ICAgICAgICAgICAgICAgICBleDpldmVudENsYXNzPSdzdGF0ZScgb3IKICAgICAgICAgICAgICAg ICAgICBleDpldmVudENsYXNzPSdjb25maWcnXSIvJmd0OzwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPmV4OmNhcmQ9J0V0aGVybmV0MCcpKV0iLyZndDs8L2ZvbnQ+ PC9zdHJvbmc+CiAgICAgICZsdDsvY3JlYXRlLXN1YnNjcmlwdGlvbiZndDsKICAgICZsdDsvbmV0 Y29uZjpycGMmZ3Q7CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxm b250IGNvbG9yPSdyZWQnPkZpZ3VyZSAxNDwvZm9udD48L3N0cmlrZT4KCjYuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucwoKICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZyb20gdGhlIGJh c2UgW05FVENPTkZdIGRvY3VtZW50IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+YXBwbHk8L2Zv bnQ+PC9zdHJpa2U+IGFsc28KICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmFwcGx5PC9m b250Pjwvc3Ryb25nPiB0byB0aGUgTm90aWZpY2F0aW9uIGNhcGFiaWxpdHkuCgogICBUaGUgYWNj ZXNzIGNvbnRyb2wgZnJhbWV3b3JrIGFuZCB0aGUgY2hvaWNlIG9mIHRyYW5zcG9ydCB3aWxsIGhh dmUgYQogICBtYWpvciBpbXBhY3Qgb24gdGhlIHNlY3VyaXR5IG9mIHRoZSBzb2x1dGlvbi4KCiAg IFRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyBlbGVtZW50cyBhcmUgbmV2ZXIgc2VudCBiZWZvcmUg dGhlIHRyYW5zcG9ydCBsYXllcgogICBhbmQgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ bmV0Y29uZjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPk5FVENP TkY8L2ZvbnQ+PC9zdHJvbmc+IGxheWVyIChjYXBhYmlsaXRpZXMgZXhjaGFuZ2UpIGhhdmUgYmVl biBlc3RhYmxpc2hlZCwKICAgYW5kIHRoZSBtYW5hZ2VyIGhhcyBiZWVuIGlkZW50aWZpZWQgYW5k IGF1dGhlbnRpY2F0ZWQuCgogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGNhcmUgYmUgdGFrZW4g dG8gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5lbnN1cmUgdGhlPC9mb250Pjwvc3RyaWtlPiBz ZWN1cmUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5vcGVyYXRpb24KICAgb2YgdGhlIGZvbGxv d2luZyBjb21tYW5kczo8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz5leGVjdXRpb246PC9mb250Pjwvc3Ryb25nPgoKICAgbyAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRp b24mZ3Q7IGludm9jYXRpb24KCiAgIG8gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4mbHQ7 Z2V0Jmd0OyBvbjwvZm9udD48L3N0cm9uZz4gcmVhZC1vbmx5IGRhdGEgbW9kZWxzCgogICBvICA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnJlYWQtd3JpdGUgZGF0YSBtb2RlbHMKCiAgIG8gIG5v dGlmaWNhdGlvbjwvZm9udD48L3N0cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4m bHQ7bm90aWZpY2F0aW9uJmd0OzwvZm9udD48L3N0cm9uZz4gY29udGVudAoKICAgT25lIGlzc3Vl IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+cmVsYXRlZCB0byB0aGUgbm90aWZpY2F0aW9ucyBk cmFmdDwvZm9udD48L3N0cmlrZT4gaXMgdGhlIHRyYW5zcG9ydCBvZiBkYXRhIGZyb20gPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz5ub24tbmV0Y29uZjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPm5vbi1ORVRDT05GPC9mb250Pjwvc3Ryb25nPiBzdHJlYW1zLCBz dWNoIGFzCiAgIHN5c2xvZyBhbmQgU05NUC4gIFRoaXMgZGF0YSBtYXkgYmUgbW9yZSB2dWxuZXJh YmxlIChvciBpcyBub3QgbW9yZQogICB2dWxuZXJhYmxlKSB3aGVuIGJlaW5nIHRyYW5zcG9ydGVk IG92ZXIgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5uZXRjb25mPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+TkVUQ09ORjwvZm9udD48L3N0cm9uZz4gdGhhbiB3 aGVuIGJlaW5nCiAgIHRyYW5zcG9ydGVkIHVzaW5nIHRoZSBwcm90b2NvbCBub3JtYWxseSB1c2Vk IGZvciB0cmFuc3BvcnRpbmcgaXQsCiAgIGRlcGVuZGluZyBvbiB0aGUgc2VjdXJpdHkgY3JlZGVu dGlhbHMgb2YgdGhlIHR3byBzdWJzeXN0ZW1zLiAgVGhlCiAgIE5FVENPTkYgc2VydmVyIGlzIHJl c3BvbnNpYmxlIGZvciA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnByb3ZpZGluZzwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmFwcGx5aW5nPC9mb250Pjwvc3Ry b25nPiBhY2Nlc3MgY29udHJvbCB0byBzdHJlYW0KICAgY29udGVudC4KCiAgIDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJz5UaGUgY29udGVudHMgb2Ygbm90aWZpY2F0aW9ucyBhcyB3ZWxsIGFz IHRoZSBuYW1lIG9mIGV2ZW50IHN0cmVhbXMKICAgbWF5IGNvbnRhaW4gc2Vuc2l0aXZlIGluZm9y bWF0aW9uIGFuZCBjYXJlIHNob3VsZCBiZSB0YWtlbiB0byBlbnN1cmUKICAgdGhhdCBpdCBpcyB2 aWV3ZWQgb25seSBieSBhdXRob3JpemVkIHVzZXJzLjwvZm9udD48L3N0cm9uZz4gIElmIGEgdXNl ciBkb2VzIG5vdCBoYXZlCiAgIHBlcm1pc3Npb24gdG8gdmlldyBjb250ZW50IHZpYSBvdGhlciBO RVRDT05GCiAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+b3BlcmF0aW9uczwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPm9wZXJhdGlvbnMsPC9mb250Pjwvc3Ry b25nPiBpdCBkb2VzIG5vdAogICBoYXZlIHBlcm1pc3Npb24gdG8gYWNjZXNzIHRoYXQgY29udGVu dCB2aWEgTm90aWZpY2F0aW9ucy4gIElmIGEgdXNlcgogICBpcyBub3QgcGVybWl0dGVkIHRvIHZp ZXcgb25lIGVsZW1lbnQgaW4gdGhlIGNvbnRlbnQgb2YgdGhlCiAgIG5vdGlmaWNhdGlvbiwgdGhl IG5vdGlmaWNhdGlvbiBpcyBub3Qgc2VudCB0byB0aGF0IHVzZXIuCgogICBJZiBhIHN1YnNjcmlw dGlvbiBpcyBjcmVhdGVkIHdpdGggYSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnN0b3BUaW1l LDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiZsdDtzdG9wVGlt ZSZndDssPC9mb250Pjwvc3Ryb25nPiB0aGUgTkVUQ09ORiBzZXNzaW9uCiAgIHdpbGwgcmV0dXJu IHRvIGJlaW5nIGEgbm9ybWFsIGNvbW1hbmQtcmVzcG9uc2UgTkVUQ09ORiBzZXNzaW9uIHdoZW4K ICAgdGhlIHJlcGxheSBpcyBjb21wbGV0ZWQuICBJdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2Yg dGhlIE5FVENPTkYKICAgY2xpZW50IHRvIGNsb3NlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ b2ZmPC9mb250Pjwvc3RyaWtlPiB0aGlzIHNlc3Npb24gd2hlbiBpdCBpcyBubyBsb25nZXIgb2Yg dXNlLgoKNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJz IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+dHdvPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+dGhyZWU8L2ZvbnQ+PC9zdHJvbmc+IFVSSXMgZm9yIHRoZSBORVRD T05GIFhNTCBuYW1lc3BhY2UgaW4KICAgdGhlIElFVEYgWE1MIHJlZ2lzdHJ5IFtSRkMzNjg4XS4K CiAgIEZvbGxvd2luZyB0aGUgZm9ybWF0IGluIFJGQyAzNjg4LCBJQU5BIGhhcyBtYWRlIHRoZSBm b2xsb3dpbmcKICAgcmVnaXN0cmF0aW9uLgoKICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6bmV0Y29u ZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjAKCiAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnht bDpuczpuZXRtb2Q6bm90aWZpY2F0aW9uCgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ VVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uPC9mb250Pjwv c3Ryb25nPgoKICAgUmVnaXN0cmFudCBDb250YWN0OiBUaGUgSUVTRy4KCiAgIFhNTDogTi9BLCB0 aGUgcmVxdWVzdGVkIFVSSSBpcyBhbiBYTUwgbmFtZXNwYWNlLgoKOC4gIEFja25vd2xlZGdlbWVu dHMKCiAgIFRoYW5rcyB0byBHaWxiZXJ0IEdhZ25vbiwgR3JlZyBXaWxidXIgYW5kIEtpbSBDdXJy YW4gZm9yIHByb3ZpZGluZwogICB0aGVpciBpbnB1dCBpbnRvIHRoZSBlYXJseSB3b3JrIG9uIHRo aXMgZG9jdW1lbnQuICBJbiBhZGRpdGlvbiwgdGhlCiAgIGVkaXRvcnMgd291bGQgbGlrZSB0byBh Y2tub3dsZWRnZSBpbnB1dCBhdCB0aGUgVmFuY291dmVyIGVkaXRpbmcKICAgc2Vzc2lvbiBmcm9t IHRoZSBmb2xsb3dpbmcgcGVvcGxlOiBPcmx5IE5pY2tsYXNzLCBKYW1lcyBCYWxlc3RyaWVyZSwK ICAgWW9zaGlmdW1pIEF0YXJhc2hpLCBHbGVubiBXYXRlcnMsIEFsZXhhbmRlciBDbGVtbSwgRGF2 ZSBIYXJyaW5ndG9uLAogICBEYXZlIFBhcnRhaW4sIFJheSBBdGFyYXNoaSBhbmQgPHN0cmlrZT48 Zm9udCBjb2xvcj0ncmVkJz5EYXZlPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+RGF2aWQ8L2ZvbnQ+PC9zdHJvbmc+IFBlcmtpbnMgYW5kIHRoZSBmb2xsb3dpbmcK ICAgYWRkaXRpb25hbCBwZW9wbGUgZnJvbSB0aGUgTW9udHJlYWwgZWRpdGluZyBzZXNzaW9uOiBC YWxhenMgTGVuZ3llbCwKICAgUGhpbCBTaGFmZXIsIFJvYiBFbm5zLCBBbmR5IEJpZXJtYW4sIERh biBSb21hc2NhbnUsIEJlcnQgV2lqbmVuLAogICBTaW1vbiBMZWluZW4sIEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciwgSGlkZWtpIE9raXRhLCBWaW5jZW50IENyaWRsaWcsCiAgIE1hcnRpbiBCam9ya2x1 bmQsIE9saXZpZXIgRmVzdG9yLCBSYWR1IFN0YXRlLCBCcmlhbiBUcmFtbWVsbCwgV2lsbGlhbQog ICBDaG93LiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPldlIHdvdWxkIGFsc28gbGlrZSB0 byB0aGFuayBMaSBZYW4gZm9yIGhpcyBudW1lcm91cyByZXZpZXdzLjwvZm9udD48L3N0cm9uZz4K CjkuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW05FVENPTkZdICBFbm5zLCBSLiwgIk5FVENP TkYgQ29uZmlndXJhdGlvbiBQcm90b2NvbCIsIFJGQyA0NzQxLAogICAgICAgICAgICAgIERlY2Vt YmVyIDIwMDYuCgogICBbUkZDMjAyNl0gIEJyYWRuZXIsIFMuLCAiVGhlIEludGVybmV0IFN0YW5k YXJkcyBQcm9jZXNzIC0tIFJldmlzaW9uCiAgICAgICAgICAgICAgMyIsIFJGQyAyMDI2LCBCQ1Ag OSwgT2N0b2JlciAxOTk2LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBzLiwgIktleSB3b3JkcyBm b3IgUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudHMKICAgICAgICAgICAgICBMZXZlbHMiLCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMyMjIzXSAgUG9zdGVsLCBKLiBhbmQgSi4gUmV5 bm9sZHMsICJJbnN0cnVjdGlvbnMgdG8gUkZDIEF1dGhvcnMiLAogICAgICAgICAgICAgIFJGQyAy MjIzLCBPY3RvYmVyIDE5OTcuCgogICBbUkZDMzY4OF0gIEJyYWRuZXIsIHMuLCAiVGhlIElFVEYg WE1MIFJlZ2lzdHJ5IiwgUkZDIDM2ODgsIEphbnVhcnkKICAgICAgICAgICAgICAgMjAwNC4KCiAg IFtYTUxdICAgICAgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSwgIkV4dGVuc2libGUgTWFya3Vw IExhbmd1YWdlCiAgICAgICAgICAgICAgKFhNTCkgMS4wIiwgVzNDIFhNTCwgRmVicnVhcnkgMTk5 OCwKICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy53My5vcmcvVFIvMTk5OC9SRUMteG1sLTE5 OTgwMjEwJmd0Oy4KCiAgIFtYTUwgU2NoZW1hXQogICAgICAgICAgICAgIEZhbGxzaWRlLCBELiBh bmQgUC4gV2FsbXNsZXksICJYTUwgU2NoZW1hIFBhcnQgMDogUHJpbWVyCiAgICAgICAgICAgICAg U2Vjb25kIEVkaXRpb24iLCBXM0MgWE1MIFNjaGVtYSwgT2N0b2JlciAyMDA0LgoKICAgW1hQQVRI XSAgICBDbGFyaywgSi4gYW5kIFMuIERlUm9zZSwgIlhNTCBQYXRoIExhbmd1YWdlIChYUGF0aCkK ICAgICAgICAgICAgICBWZXJzaW9uIDEuMCIsCiAgICAgICAgICAgICAgVzNDIGh0dHA6Ly93d3cu dzMub3JnL1RSLzE5OTkvUkVDLXhwYXRoLTE5OTkxMTE2LAogICAgICAgICAgICAgIE5vdmVtYmVy IDE5OTkuCgpBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZwoKQS4xLiAgVmVyc2lvbiAtMDgKCiAgIDEu ICAgUmVtb3ZlZCBuYW1lZCBwcm9maWxlcwoKICAgMi4gICBSZW1vdmVkIGV2ZW50Q2xhc3MgdGhh dCB3YXMgYWNjaWRlbnRhbGx5IGluY2x1ZGVkIGluIHRoZQogICAgICAgIGRlZmluaXRpb24gb2Yg dGhlIHJlcGxheUNvbXBsZXRlIG5vdGlmaWNhdGlvbgoKICAgMy4gICBEZWxldGVkIGRhdGEgd3Jh cHBlciBmcm9tIG5vdGlmaWNhdGlvbgoKICAgNC4gICBDaGFuZ2VkIHJlcGxheUxvZ1N0YXJ0VGlt ZSB0byBoYXZlIGEgbWluT2NjdXJzIG9mIDAuICBJdCB3aWxsCiAgICAgICAgb25seSBiZSB0aGVy ZSB3aGVuIHJlcGxheSBpcyBzdXBwb3J0ZWQuICBWZXJpZnkgZXhhbXBsZXMgaW4KICAgICAgICBz ZWN0aW9uIDMuMi41LjEgYXJlIGNvcnJlY3Qgd2l0aCByZXNwZWN0IHRvIHRoaXMgZWxlbWVudC4K CiAgIDUuICAgRXJyb3IgY29kZXMgaW4gc2VjdGlvbiAyLjEuMSwgZml4ZWQgZm9ybWF0dGluZyBp c3N1ZQoKICAgNi4gICBNb3ZlZCByZXBsYXlDb21wbGV0ZSB0byBub3QgYmUgdW5kZXIgJmx0O25l dGNvbmYmZ3Q7CgogICA3LiAgIFNlY3Rpb24gMi4xLCBmaXhlZCBjYXBpdGFsaXphdGlvbgoKICAg OC4gICBJbiBmaWd1cmUgNCwgdGhlIGxpbmUgd2FzIHB1c2hlZCBvdXQgYnkgJ3N5c3RlbSBjb21w b25lbnRzJywKICAgICAgICBmaXhlZCB0aGlzLgoKICAgOS4gICBPbiBwYWdlIDgsIHJlcGxhY2Vk ICJJZiB0aGUgc3RhcnRUaW1lIHNwZWNpZmllZCBpcyBlYXJsaWVyIHRoZW4KICAgICAgICB0aGUi IHdpdGggJ0lmIHRoZSBzdGFydFRpbWUgc3BlY2lmaWVkIGlzIGVhcmxpZXIgdGhhbiB0aGUiCgog ICAxMC4gIFVwZGF0ZWQgc29tZSBuYW1lIHNwYWNlcyBhbmQgc2NoZW1hTG9jYXRpb25zIGFzIHBl ciBBbmR5J3MgSnVuZQogICAgICAgIDNyZCBlbWFpbC4KCiAgIDExLiAgQWRkZWQgZGlzY3Vzc2lv biBvZiByZXBsYXlMb2dTdGFydFRpbWUgdG8gZHJhZnQgaW4gc2VjdGlvbiAzLjMuMQogICAgICAg IGFzIGZvbGxvd3MgIldoZXRoZXIgb3Igbm90IGEgc3RyZWFtIHN1cHBvcnRzIHJlcGxheSBjYW4g YmUKICAgICAgICBkaXNjb3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsgb3BlcmF0aW9uIG9u IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmV2ZW50U3RyZWFtczwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiZsdDtzdHJlYW1zJmd0OzwvZm9udD48L3N0 cm9uZz4gZWxlbWVudHMKICAgICAgICBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQgU2No ZW1hLiAgVGhpcyBzY2hlbWEgYWxzbwogICAgICAgIHByb3ZpZGVzIHRoZSByZXBsYXlMb2dTdGFy dFRpbWUgZWxlbWVudCB0byBpbmRpY2F0ZSB0aGUgZWFybGllc3QKICAgICAgICBhdmFpbGFibGUg bG9nZ2VkIG5vdGlmaWNhdGlvbi4iCgogICAxMi4gIFJlbW92ZWQgbW9zdCBvZiB0aGUgdXNlcyBv ZiB0aGUgcGhyYXNlICdOb3RlIHRoYXQnLiAgSSBrZXB0IHR3bwogICAgICAgIHVzZXMgdGhhdCBw cmV2ZW50IHNlbnRlbmNlcyBmcm9tIHN0YXJ0aW5nIHdpdGggZWl0aGVyIGEgbG93ZXIKICAgICAg ICBjYXNlIGxldHRlciBvciBhbiBhbmdsZSBicmFja2V0LgoKICAgMTMuICBJbiBzZWN0aW9uIDMu NiByZXBsYWNlZCAiaXQgd2lsbCBiZSBmaWx0ZXJlZCBvdXQiIHdpdGggInRoZQogICAgICAgIG5v dGlmaWNhdGlvbiB3aWxsIGJlIGZpbHRlcmVkIG91dCIKCiAgIDE0LiAgSW4gc2VjdGlvbiAzLjQs IHJlcGxhY2VkICJhbmQgdGhlIHF1ZXJ5IiB3aXRoICJhbmQgdG8gcXVlcnkiCgogICAxNS4gIFJl cGxhY2VkIDMgaW5zdGFuY2VzIG9mICJyZXBsYXkgY29tcGxldGUgbm90aWZpY2F0aW9uIiB3aXRo CiAgICAgICAgInJlcGxheUNvbXBsZXRlIG5vdGlmaWNhdGlvbiIKICAgMTYuICBJbiBzZWN0aW9u IDMuMy4yLCByZXBsYWNlZCAibm9ybWFsIE5FVENPTkYgc2Vzc2lvbiIgd2l0aCAibm9ybWFsCiAg ICAgICAgY29tbWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24iCgogICAxNy4gIEluIHNlY3Rp b24gMy4zLjEsIHJlcGxhY2VkICJjcmVhdGUgYW4gZXZlbnQgc3Vic2NyaXB0aW9uIHRoYXQKICAg ICAgICB3aWxsIHJlc2VuZCByZWNlbnRseSBnZW5lcmF0ZWQgbm90aWZpY2F0aW9uIiB3aXRoICJj cmVhdGUgYW4KICAgICAgICBldmVudCBzdWJzY3JpcHRpb24gdGhhdCB3aWxsIHJlc2VuZCByZWNl bnRseSBnZW5lcmF0ZWQKICAgICAgICBub3RpZmljYXRpb24sIG9yIGlzIHNvbWUgY2FzZXMgc2Vu ZCB0aGVtIGZvciB0aGUgZmlyc3QgdGltZSB0byBhCiAgICAgICAgcGFydGljdWxhciBORVRDT05G IGNsaWVudC4iCgogICAxOC4gIEluIHNlY3Rpb24gMy4yLjUuMiwgcy9hdmFpbGFibGUgZXZlbnQg c3RyZWFtcyB0by9ldmVudCBzdHJlYW1zCiAgICAgICAgYXZhaWxhYmxlIHRvLwoKICAgMTkuICBJ biBvbmUgc3BvdCwgY2hhbmdlZCBzbm1wIHRvIFNOTVAgKHRoZSBvdGhlciBnZXRzIGRlbGV0ZWQp CgogICAyMC4gIEluIHNlY3Rpb24gMy4yLjUuMSBzL3doZXJlICZsdDtuYW1lJmd0OyBlbGVtZW50 IGlzL3doZXJlIHRoZSAmbHQ7bmFtZSZndDsKICAgICAgICBlbGVtZW50IGlzLwoKICAgMjEuICBJ biBzZWN0aW9uIDMuMi41LjEsIGNsYXJpZmllZCB0aGF0ICJ2YWx1ZSBpcyB1bmlxdWUiIC0gd2l0 aGluCiAgICAgICAgdGhlIHNjb3BlIG9mIGEgTkVUQ09ORiBzZXJ2ZXIuCgogICAyMi4gIEluIHNl Y3Rpb24gMi4xLjEsIGNsYXJpZmllZCB0aGF0IHN0b3BUaW1lIGNhbm5vdCBwcmVjZWRlZCBzdGFy dAogICAgICAgIHRpbWUuCgogICAyMy4gIEluIHNlY3Rpb24gMi4xLjEsIGluIFN0YXJ0IFRpbWUg cy9pbmRpY2F0ZXMvaW5kaWNhdGUvCgogICAyNC4gIEluIHNlY3Rpb24gMi4xLjEsIGluIEZpbHRl cjogcy9UaGlzIGlzIG11dHVhbGx5IGV4Y2x1c2l2ZS9UaGUKICAgICAgICBmaWx0ZXIgcGFyYW1l dGVyIGlzIG11dHVhbGx5IGV4Y2x1c2l2ZS8gKCJ0aGlzIiBjb3VsZCByZWZlciB0bwogICAgICAg IHRoZSBiZWhhdmlvciBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzIHNlbnRlbmNlLikKCiAgIDI1 LiAgSW4gc2VjdGlvbiAxLjQsIHRoaXJkIGJ1bGxldCwgcmVwbGFjZWQgInN5c2xvZyBhbmQgU05N UCBhcmUKICAgICAgICByYXRoZXIgY29uc3RyYWluZWQgaW4gdGVybXMgb2YgbWVzc2FnZSBzaXpl cykiIHdpdGggKGllLCBub3QgdG9vCiAgICAgICAgc2hvcnQpCgogICAyNi4gIEluIHNlY3Rpb24g MS40LCBtYWRlIGFsbCBidWxsZXRzIHN0YXJ0IHdpdGggY2FwaXRhbCBsZXRlcnMuCgogICAyNy4g IEFkZGVkIGRlZmluaXRpb24gb2YgRmlsdGVyIHRvIHNlY3Rpb24gMS4xCgogICAyOC4gIEluIHNl Y3Rpb24gMS4xLCBpbXByb3ZlZCB0aGUgZGVmaW5pdGlvbiBvZiBzdWJzY3JpcHRpb24gd2l0aCAi QW4KICAgICAgICBhZ3JlZW1lbnQgYW5kIG1ldGhvZCB0byByZWNlaXZlIGV2ZW50IG5vdGlmaWNh dGlvbnMgb3ZlciBhCiAgICAgICAgTkVUQ09ORiBzZXNzaW9uLiIKCiAgIDI5LiAgSW4gc2VjdGlv biAxLjEsIGluIHRoZSBkZWZpbml0aW9uIG9mIG9wZXJhdGlvbiwgYWRkZWQgYQogICAgICAgIHJl ZmVyZW5jZSB0byBbTkVUQ09ORl0uCgogICAzMC4gIENyZWF0ZWQgYSBjaGFuZ2UgbG9nIHNlY3Rp b24KCiAgIDMxLiAgRml4ZWQgcmVmZXJlbmNlIHRvIElFVEYgWE1MIFJlZ2lzdHJ5IGluIElBTkEg Q29uc2lkZXJhdGlvbnMKICAgICAgICBzZWN0aW9uLgoKICAgMzIuICBJbiBzZWN0aW9uIDMuMy4z LCBkZWxldGVkICJUaGlzIG5vdGlmaWNhdGlvbiB3aWxsIG9ubHkgYmUgc2VudAogICAgICAgIGlm IGEgJ3N0b3BUaW1lJyB3YXMgc3BlY2lmaWVkIHdoZW4gdGhlIHJlcGxheSBzdWJzY3JpcHRpb24g d2FzCiAgICAgICAgY3JlYXRlZC4iCgogICAzMy4gIEFkZGVkIHRleHQgdG8gdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBzYXlzICJJZgogICAgICAgIGEgc3Vic2NyaXB0 aW9uIGlzIGNyZWF0ZWQgd2l0aCBhIHN0b3BUaW1lLCB0aGUgTkVUQ09ORiBzZXNzaW9uCiAgICAg ICAgd2lsbCByZXR1cm4gdG8gYmVpbmcgYSBub3JtYWwgY29tbWFuZC1yZXNwb25zZSBORVRDT05G IHNlc3Npb24KICAgICAgICB3aGVuIHRoZSByZXBsYXkgaXMgY29tcGxldGVkLiAgSXQgaXMgdGhl IHJlc3BvbnNpYmlsaXR5IG9mIHRoZQogICAgICAgIE5FVENPTkYgY2xpZW50IHRvIGNsb3NlIG9m ZiB0aGlzIHNlc3Npb24gd2hlbiBpdCBpcyBubyBsb25nZXIgb2YKICAgICAgICB1c2UiLgoKICAg MzQuICBVcGRhdGUgZXhhbXBsZXMgaW4gc2VjdGlvbiA1IHRvIGdldCByaWQgb2YgZXh0cmEgd3Jh cHBlciB0YWcuCgogICAzNS4gIEluIHNlY3Rpb24gMi4xLCByZXBsYWNlICJBIE5FVENPTkYgc2Vy dmVyIGlzIG5vdCByZXF1aXJlZCB0bwogICAgICAgIHByb2Nlc3MgUlBDIHJlcXVlc3RzIG9uIHRo ZSBzZXNzaW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUKICAgICAgICBzdWJzY3JpcHRpb24gdW50aWwg dGhlIG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gaXMgZG9uZSBhbmQgbWF5CiAgICAgICAgc2ls ZW50bHkgZGlzY2FyZCB0aGVzZSByZXF1ZXN0cy4iIHdpdGggIkEgTkVUQ09ORiBzZXJ2ZXIgaXMg d2lsbAogICAgICAgIG5vdCByZWFkIFJQQyByZXF1ZXN0cywgYnkgZGVmYXVsdCwgb24gdGhlIHNl c3Npb24gYXNzb2NpYXRlZAogICAgICAgIHdpdGggdGhlIHN1YnNjcmlwdGlvbiB1bnRpbCB0aGUg bm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcwogICAgICAgIGRvbmUuCgogICAzNi4gIFVwZGF0 ZWQgdGhlIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIGFuZCB0aGUgcmVwbHlDb21wbGV0ZQogICAg ICAgIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIHRvIHVzZSBhIHN1YnN0aXR1dGlvbiBncm91cC4K CjxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5BLjIuICBWZXJzaW9uIC0wOQoKICAgMS4gICBJ biBzZWN0aW9uIDUuMSAibG9naWNhbCBPUiBvcGVyYXRpb24iIC0mZ3Q7ICJhcHBsaWNhdGlvbiBv ZiB0aGUKICAgICAgICBsb2dpY2FsIE9SIG9wZXJhdG9yIgoKICAgMi4gICBJbiBzZWN0aW9uIDYg ImVuc3VyZSB0aGUgc2VjdXJlIG9wZXJhdGlvbiBvZiB0aGUgZm9sbG93aW5nCiAgICAgICAgY29t bWFuZHMiIC0mZ3Q7ICJzZWN1cmUgZXhlY3V0aW9uIgoKICAgMy4gICBSZW1vdmVkIGEgY291cGxl IHJlbWFpbmluZyByZWZlcmVuY2VzIHRvIG5hbWVkIHByb2ZpbGVzLgoKICAgNC4gICBVcGRhdGVk IG5hbWUgZGF0YXR5cGUgaW4gZXZlbnRTdHJlYW1zIGVsZW1lbnQuCgogICA1LiAgIE1vZGlmaWVk IHRoZSBjYXJkaW5hbGl0eSBvZiBldmVudFN0cmVhbXMgdG8gcmVmbGVjdCB0aGF0IHRoZXJlCiAg ICAgICAgd2lsbCBhbHdheXMgYmUgYXQgbGVhc3Qgb25lIGV2ZW50IHN0cmVhbS4KCiAgIDYuICAg Rml4ZWQgZGVzY3JpcHRpb24gb2YgZXhhbXBsZXMgdG8gcmVtb3ZlIHJlZmVyZW5jZSB0byBldmVu dEVudHJ5LAogICAgICAgIHdoaWNoIGlzIG5vIGxvbmdlciBwYXJ0IG9mIHRoZSBhY3R1YWwgZXhh bXBsZS4KCiAgIDcuICAgSW4gZXhhbXBsZXMsIGZvciBjb25zaXN0ZW5jeSBjaGFuZ2VkIHNvbWUg cmVmZXJlbmNlcyB0bwogICAgICAgIHJlcG9ydGluZ0VsZW1lbnQgdG8gYmUgcmVwb3J0aW5nRW50 aXR5CgogICA4LiAgIEZpeGVkIHNlY3Rpb24gMy4yLCB0aGlyZCBwYXJhcmFwaCB0byB0YWxrIGFi b3V0IGZpbHRlciBlbGVtZW50cwogICAgICAgIGluc3RlYWQgb2YgZmlsdGVycy4KCiAgIDkuICAg TWVyZ2Ugc2VjdGlvbiAzLjMuMiBhbmQgc2VjdGlvbiAzLjMuMy4gIERlbGV0ZSB0aGUgZmlyc3QK ICAgICAgICBwYXJhZ3JhcGggaW4gKG9sZCkgc2VjdGlvbiAzLjMuMyBzaW5jZSBpdCBib3RoIGR1 cGxpY2F0ZXMgYW5kCiAgICAgICAgY29udHJhZGljdHMgdGV4dCBpbiBzZWN0aW9uIDMuMy4yCgog ICAxMC4gIEluIHNlY3Rpb24gMy4yLjUuMi4xLCBhZGRlZCBjbGFyaWZpY2F0aW9uIHRvIGZpcnN0 IHBhcmFncmFwaAogICAgICAgIHRoYXQgIkVpdGhlciBzdWJ0cmVlIG9yIFhQQVRIIGZpbHRlcmlu ZyBjYW4gYmUgdXNlZC4gICIKCiAgIDExLiAgUmVtb3ZlZCBkaXNjdXNzaW9uIG9mIG5vdCBhbGxv d2luZyB0aGUgcmV0dXJuIG9mIHN0cmVhbSBuYW1lcwogICAgICAgIGZvciB3aGljaCB0aGUgdXNl ciBkb2VzIG5vdCBoYXZlIHBlcm1pc3Npb25zIGZyb20gdGhlIGJvZHkgb2YKICAgICAgICB0aGUg ZG9jdW1lbnQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uCgogICAxMi4g IEZpeGVkIHR5cG9zIGFuZCBkaWQgd29yZHNtaXRoaW5nIGluIHZhcmlvdXMgcGFydHMgb2YgdGhl CiAgICAgICAgZG9jdW1lbnQuCgogICAxMy4gIEluIHNlY3Rpb24gMi4xLCBleHBsaWNpdGx5IHN0 YXRlZCB0aGF0IGEgc3Vic2NyaXB0aW9uIGlzIGJvdW5kCiAgICAgICAgdG8gYSBzaW5nbGUgc3Ry ZWFtIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlIHN1YnNjcmlwdGlvbi4KCiAgIDE0LiAgcmVtb3Zl ZCBzaW5nbGUgcXVvdGVzIGFyb3VuZCBzb21lIGluc3RhbmNlcyBvZiBzdG9wVGltZSBhbmQKICAg ICAgICBzdGFydFRpbWUgZm9yIGNvbnNpc3RlbmN5LiAgV2hlbiBhcHByb3ByaWF0ZSwgcHV0IGJl dHdlZW4gYW5nbGUKICAgICAgICBicmFja2V0cy4KCiAgIDE1LiAgSW4gc2VjdGlvbiAyLjEuMSwg Y2hhbmdlZCAiRXJyb3ItaW5mbzogJmx0O2JhZEVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUiCiAgICAg ICAgdG8gdXNlIGJhZC1lbGVtZW50LgoKICAgMTYuICBJbiBzZWN0aW9uIDIuMi4xLCB1bmRlciB0 aGUgcGFyYW1ldGVyIHRhZywgcmVwbGFjZWQgIkNvbnRhaW5zCiAgICAgICAgbm90aWZpY2F0aW9u LXNwZWNpZmljIHRhZ2dlZCBjb250ZW50LiIgd2l0aCAiQ29udGFpbnMKICAgICAgICBub3RpZmlj YXRpb24tc3BlY2lmaWMgdGFnZ2VkIGNvbnRlbnQsIGlmIGFueS4gICIKCiAgIDE3LiAgQ2xhcmlm aWVkIHNvbWUgdGV4dCBpbiBzZWN0aW9uIDMuMiwgcGFyYWdyYXBoIDMgYXJvdW5kIHNlbmRpbmcK ICAgICAgICBvZiBmaWx0ZXJzIGZyb20gY2xpZW50IGFuZCB0aGUgZml0bGVycyBsYXRlciBiZWlu ZyBhcHBsaWVkIHRvCiAgICAgICAgdGhlIG5vdGlmaWNhdGlvbnMuCgogICAxOC4gIEZpeGVkIHRh cmdldCBuYW1lc3BhY2UgaW4gc2VjdGlvbiA0LgoKICAgMTkuICBBZGRlZCBtaXNzaW5nIGxhbmcg YW5kIHZlcnNpb24gaW5mb3JtYXRpb24gdG8gc2NoZW1hIGluIHNlY3Rpb24KICAgICAgICAzLjQK CiAgIDIwLiAgQ2xhcmlmaWVkIHRoYXQgdGhlIGV4YW1wbGVzIGluIHNlY3Rpb24gNSBhbGwgdXNl ZCB0aGUgc2FtZQogICAgICAgIGV4YW1wbGUgZXZlbnQgbGlzdC4KCiAgIDIxLiAgQ2xlYW5lZCB1 cCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLgoKICAgMjIuICBJbiBzZWN0aW9uIDMu NCwgY2xhcmlmaWVkIHRoZSBkZWZpbml0aW9uIG9mIHJlcGxheUxvZ1N0YXJ0IHRpbWUKICAgICAg ICB0byBiZSB0aGUgdGltZXN0YW1wIG9mIHRoZSBlYXJsaWVzdCBhdmFpbGFibGUgbm90aWZpY2F0 aW9uIGluCiAgICAgICAgdGhlIGxvZyB1c2VkIHRvIHN1cHBvcnQgdGhlIHJlcGxheSBmdW5jdGlv biBpbiB0aGUgZGVzY3JpcHRpb24KICAgICAgICB0YWcgZm9yIHRoZSBvYmplY3QgZGVmaW5pdGlv bi4KCiAgIDIzLiAgSW4gc2VjdGlvbiAzLjMuMiwgY2xhcmlmaWVkIHRoYXQgdGhlIHRpbWUgYW4g ZXZlbnQgd2FzIGdlbmVyYXRlZAogICAgICAgIGJ5IHRoZSBzeXN0ZW0gbWVhbnMgdGltZSBhbiBl dmVudCB3YXMgZ2VuZXJhdGVkIGJ5IHRoZSBldmVudAogICAgICAgIHNvdXJjZS4KCiAgIDI0LiAg SW4gc2VjdGlvbiAzLjUsIGRlbGV0ZWQgZGlzY3Vzc2lvbiBhYm91dCBwb3NzaWJseSBkZWZpbmlu ZwogICAgICAgIHN1YnNjcmlwdGlvbnMgaW4gWE1MIFNjaGVtYS4KCiAgIDI1LiAgSW4gc2VjdGlv biAzLjYsIGRlbGV0ZWQgZGlzY3Vzc2lvbiBhYm91dCBmaWx0ZXIgZWxlbWVudAogICAgICAgIGV4 ZWN1dGlvbiBvcmRlciBub3QgbWF0dGVyaW5nLgoKICAgMjYuICBGaXhlZCBleGFtcGxlcyBpbiBz ZWN0aW9uIDUgdG8gYWRkICZsdDtuZXRjb25mJmd0OyB0YWcgYW5kIHRvIG1ha2UKICAgICAgICBv dGhlciBjb3JyZWN0aW9ucwoKICAgMjcuICBBZGRlZCBYTUwgU2NoZW1hIGRlZmluaXRpb24gZm9y IGV4YW1wbGVzIGluIHNlY3Rpb24gNSBhbmQgc2hvd2VkCiAgICAgICAgdGhlIGV2ZW50IGxpc3Qg d2l0aCAmbHQ7bm90aWZpY2F0aW9uJmd0OyB3cmFwcGVycy48L2ZvbnQ+PC9zdHJvbmc+CgpBdXRo b3JzJyBBZGRyZXNzZXMKCiAgIFNoYXJvbiBDaGlzaG9sbQogICBOb3J0ZWwKICAgMzUwMCBDYXJs aW5nIEF2ZQogICBOZXBlYW4sIE9udGFyaW8gIEsySCA4RTkKICAgQ2FuYWRhCgogICBFbWFpbDog c2NoaXNob2xAbm9ydGVsLmNvbQoKICAgSGVjdG9yIFRyZXZpbm8KICAgQ2lzY28KICAgU3VpdGUg NDAwCiAgIDkxNTUgRS4gTmljaG9scyBBdmUKICAgRW5nbGV3b29kLCBDTyAgODAxMTIKICAgVVNB CgogICBFbWFpbDogaHRyZXZpbm9AY2lzY28uY29tCgpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQK CiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLgoKICAgVGhpcyBkb2N1bWVu dCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMKICAg Y29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhl IGF1dGhvcnMKICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuCgogICBUaGlzIGRvY3VtZW50IGFu ZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4KICAg IkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NI RSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVU IFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORAogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcg VEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUwogICBPUiBJTVBMSUVE LCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0Ug T0YKICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRT IE9SIEFOWSBJTVBMSUVECiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5CgogICBU aGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3Bl IG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0 aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24g b3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3VtZW50IG9y IHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMKICAgbWln aHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQg aXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3Vj aCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3Qg dG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQg QkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNl Y3JldGFyaWF0IGFuZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2 YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEg Z2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAgc3VjaCBwcm9w cmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMKICAgc3BlY2lm aWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0 b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYgaW52aXRlcyBh bnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQogICBjb3B5 cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0 YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVp cmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGlu Zm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoKQWNrbm93bGVk Z21lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHByb3ZpZGVk IGJ5IHRoZSBJRVRGCiAgIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkgKElBU0EpLgo8 L3ByZT4KPC9ib2R5PjwvaHRtbD4K ------_=_NextPart_001_01C7D9F1.B45FF95A-- -- to unsubscribe send a message to netconf-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 Aug 08 15:39:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIrNm-0005Vk-5E for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 15:39:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIrNl-0000x5-F0 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 15:39:50 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIrEP-0006jx-0k for netconf-data@psg.com; Wed, 08 Aug 2007 19:30: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 [68.142.229.104] (helo=smtp101.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIrEE-0006hH-0r for netconf@ops.ietf.org; Wed, 08 Aug 2007 19:30:03 +0000 Received: (qmail 55610 invoked from network); 8 Aug 2007 19:29:57 -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; 8 Aug 2007 19:29:56 -0000 X-YMail-OSG: 8XU4VM8VM1mtw2z4nXUgINFvbMfdS4Cfy1hK_7laShaPPm4EILI_WDj3Ih7DABeTrv4rzUf2_c4qo7sQ82zES1AN5ahzRJe_UZXgo.2qEn9uw325ppJw Message-ID: <46BA195C.60308@andybierman.com> Date: Wed, 08 Aug 2007 12:28:28 -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 #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> In-Reply-To: <20070808.210806.33045977.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: 41c17b4b16d1eedaa8395c26e9a251c4 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I would like people to speak up about the startTime and/or >> stopTime parameters in the future issue. >> >> Do you favor: >> >> A) return an error if parameters are in the future > > Better than B. > >> B) return whatever the agent has in its reply log >> that matches the search criteria (at the time the >> request is made). Parameters only refer to the >> timestamps of entries in the log. > > No, this seems very confusing. > >> C) treat as a request to start returning notifications >> some time in the future, according to the parameters. >> Parameters refer to the 'time window' that notification >> delivery is desired. > > I can live with it, but I don't prefer it. > > I'd prefer: > > D) treat startTime in the future as an error, but stopTime in the > future is ok (it's like giving a startTime w/o a stopTime, but let > the agent stop the notifications at a certain time.) > This really puts the "mode changes" issue front and center. So stopTime in the future means "just stop sending notifications". Does the session hang (waiting for session termination) or does it silently revert to "normal mode" at the stopTime? I've got to say, I've seen cleaner designs in my career. This whole replay/live/termination/interleaving design is really a mess. The interleaving seems to be a big concern to some people. IMO, the manager MUST be able to send at least a operation. I don't care as much about interleaving because sessions are not that expensive. But the termination mechanism and silent transitions back into "normal" node or "hang" mode (like (D) above) are really a problem. > A special "now" value for the stopTime seems useful - it's like a > 'cat' on the file. It also supports the use case where the manager has code that is designed to start listening to live notifications 'now', and back-fill via a notification log (ala SNMP). (What? Use 2 sessions!) Andy > > > /martin > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 08 16:06: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 1IIrn8-0003Gp-7m for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 16:06:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIrn7-0001U0-01 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 16:06:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIrbu-0009Sa-Lu for netconf-data@psg.com; Wed, 08 Aug 2007 19:54: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.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 1IIrbj-0009RH-1F for netconf@ops.ietf.org; Wed, 08 Aug 2007 19:54:21 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 3B02B1B80C5; Wed, 8 Aug 2007 21:54:13 +0200 (CEST) Date: Wed, 08 Aug 2007 21:54:03 +0200 (CEST) Message-Id: <20070808.215403.98541459.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point From: Martin Bjorklund In-Reply-To: <46BA195C.60308@andybierman.com> References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> <46BA195C.60308@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: 3002fc2e661cd7f114cb6bae92fe88f1 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> I would like people to speak up about the startTime and/or > >> stopTime parameters in the future issue. > >> > >> Do you favor: > >> > >> A) return an error if parameters are in the future > > > > Better than B. > > > >> B) return whatever the agent has in its reply log > >> that matches the search criteria (at the time the > >> request is made). Parameters only refer to the > >> timestamps of entries in the log. > > > > No, this seems very confusing. > > > >> C) treat as a request to start returning notifications > >> some time in the future, according to the parameters. > >> Parameters refer to the 'time window' that notification > >> delivery is desired. > > > > I can live with it, but I don't prefer it. > > > > I'd prefer: > > > > D) treat startTime in the future as an error, but stopTime in the > > future is ok (it's like giving a startTime w/o a stopTime, but let > > the agent stop the notifications at a certain time.) > > > > This really puts the "mode changes" issue front and center. > So stopTime in the future means "just stop sending notifications". > Does the session hang (waiting for session termination) or > does it silently revert to "normal mode" at the stopTime? We already have the mode switch thing -- you always get a mode switch if you use startTime and stopTime. > I've got to say, I've seen cleaner designs in my career. > This whole replay/live/termination/interleaving design is > really a mess. I agree. > The interleaving seems to be a big concern > to some people. To who??? I think most people are in favor of interleaving. /martin > IMO, the manager MUST be able to send > at least a operation. I don't care as much > about interleaving because sessions are not that expensive. > But the termination mechanism and silent transitions > back into "normal" node or "hang" mode (like (D) above) are really a problem. > > > > A special "now" value for the stopTime seems useful - it's like a > > 'cat' on the file. > > It also supports the use case where the manager has code > that is designed to start listening to live notifications 'now', > and back-fill via a notification log (ala SNMP). (What? Use 2 sessions!) > > Andy > > > > > > > /martin > > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 08 16:28: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 1IIs8k-0004MC-EP for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 16:28:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIs8j-0001s0-72 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 16:28:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIs00-000CLJ-GO for netconf-data@psg.com; Wed, 08 Aug 2007 20:19: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=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.100] (helo=smtp105.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIrzo-000CKY-Qm for netconf@ops.ietf.org; Wed, 08 Aug 2007 20:19:14 +0000 Received: (qmail 53505 invoked from network); 8 Aug 2007 20:19:08 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp105.sbc.mail.re2.yahoo.com with SMTP; 8 Aug 2007 20:19:07 -0000 X-YMail-OSG: ansXMK8VM1mnpNxGpgf7I6ydDvsYL0LliuOHbtBxP3EGxj8rRMXFyuvflSOZZwBcWfBbcqGHSaW5e1FbxKg4XWtZ Message-ID: <46BA24E3.9000900@andybierman.com> Date: Wed, 08 Aug 2007 13:17:39 -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 #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> In-Reply-To: <20070808.210806.33045977.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: 00e94c813bef7832af255170dca19e36 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I would like people to speak up about the startTime and/or >> stopTime parameters in the future issue. >> >> Do you favor: >> >> A) return an error if parameters are in the future > > Better than B. > >> B) return whatever the agent has in its reply log >> that matches the search criteria (at the time the >> request is made). Parameters only refer to the >> timestamps of entries in the log. > > No, this seems very confusing. > >> C) treat as a request to start returning notifications >> some time in the future, according to the parameters. >> Parameters refer to the 'time window' that notification >> delivery is desired. > > I can live with it, but I don't prefer it. > > I'd prefer: > > D) treat startTime in the future as an error, but stopTime in the > future is ok (it's like giving a startTime w/o a stopTime, but let > the agent stop the notifications at a certain time.) > IMO, this filter is not special. It is no different than retrieving all the log entries from sequence ID 'X' to sequence ID 'Y', via some Xpath filter, The filter applies to the data in the log, not notifications that have not happened yet. I don't want to let the Engineers introduce more features into this release. The "must-haves" for this feature are: 1) retrieve the logged notifications with start and stop parameters (if requested) 2) transition to live notification delivery after replay (if requested) 3) terminate the session cleanly w/ Everything else is redundant, and therefore not a "must-have" feature. > A special "now" value for the stopTime seems useful - it's like a > 'cat' on the file. > > > /martin Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 08 16:55: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 1IIsZ7-0007im-7R for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 16:55:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIsZ5-0002MG-Vt for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 16:55:37 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIsLO-000Ed9-Rw for netconf-data@psg.com; Wed, 08 Aug 2007 20:41: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.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 1IIsLD-000Ec0-Nc for netconf@ops.ietf.org; Wed, 08 Aug 2007 20:41:21 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id C8C5B1B80C5; Wed, 8 Aug 2007 22:41:14 +0200 (CEST) Date: Wed, 08 Aug 2007 22:41:06 +0200 (CEST) Message-Id: <20070808.224106.192363477.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point From: Martin Bjorklund In-Reply-To: <46BA24E3.9000900@andybierman.com> References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> <46BA24E3.9000900@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: 92df29fa99cf13e554b84c8374345c17 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> I would like people to speak up about the startTime and/or > >> stopTime parameters in the future issue. > >> > >> Do you favor: > >> > >> A) return an error if parameters are in the future > > > > Better than B. > > > >> B) return whatever the agent has in its reply log > >> that matches the search criteria (at the time the > >> request is made). Parameters only refer to the > >> timestamps of entries in the log. > > > > No, this seems very confusing. > > > >> C) treat as a request to start returning notifications > >> some time in the future, according to the parameters. > >> Parameters refer to the 'time window' that notification > >> delivery is desired. > > > > I can live with it, but I don't prefer it. > > > > I'd prefer: > > > > D) treat startTime in the future as an error, but stopTime in the > > future is ok (it's like giving a startTime w/o a stopTime, but let > > the agent stop the notifications at a certain time.) > > > > > IMO, this filter is not special. > It is no different than retrieving all the log entries > from sequence ID 'X' to sequence ID 'Y', via some Xpath filter, This filter *is* different, because: 1) if a start time is present, the agent should look in the log 2) if a stop time is present, notification delivery is terminated by the agent and the session becomes normal again. [But it didn't have to be different - if every event had a timestamp (as in Sharon's original spec), you could have used the normal filter mechanism, and let the agent implementor worry about optimizing away the log search if the timestamp in the filter was late enough. But if it was a normal filter, the agent would have to check the stored notifications _unless_ the filter contained the timestamp/sequenceID. This is different from today where the default (no start/stop time) means subscribe to live notifications only. You would never get back to "normal mode" though.] > The filter applies to the data in the log, not notifications > that have not happened yet. This also makes it different - the other filter applies to all notifications, logged or live. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 08 17:16: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 1IIstA-0007pS-7b for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 17:16:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIst8-00031h-Nk for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 17:16:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIsmQ-000HeP-OP for netconf-data@psg.com; Wed, 08 Aug 2007 21:09: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 [68.142.229.96] (helo=smtp109.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIsmF-000Hdc-Ls for netconf@ops.ietf.org; Wed, 08 Aug 2007 21:09:17 +0000 Received: (qmail 78551 invoked from network); 8 Aug 2007 21:09:10 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp109.sbc.mail.re2.yahoo.com with SMTP; 8 Aug 2007 21:09:10 -0000 X-YMail-OSG: CMCkMqAVM1kyQ6y3o1_2G3ukrYS5TXzmvjzQ0TcP9coFokLw Message-ID: <46BA309D.2090807@andybierman.com> Date: Wed, 08 Aug 2007 14:07:41 -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 #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> In-Reply-To: <20070808.224106.192363477.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: 2857c5c041d6c02d7181d602c22822c8 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> I would like people to speak up about the startTime and/or >>>> stopTime parameters in the future issue. >>>> >>>> Do you favor: >>>> >>>> A) return an error if parameters are in the future >>> Better than B. >>> >>>> B) return whatever the agent has in its reply log >>>> that matches the search criteria (at the time the >>>> request is made). Parameters only refer to the >>>> timestamps of entries in the log. >>> No, this seems very confusing. >>> >>>> C) treat as a request to start returning notifications >>>> some time in the future, according to the parameters. >>>> Parameters refer to the 'time window' that notification >>>> delivery is desired. >>> I can live with it, but I don't prefer it. >>> >>> I'd prefer: >>> >>> D) treat startTime in the future as an error, but stopTime in the >>> future is ok (it's like giving a startTime w/o a stopTime, but let >>> the agent stop the notifications at a certain time.) >>> >> >> IMO, this filter is not special. >> It is no different than retrieving all the log entries >> from sequence ID 'X' to sequence ID 'Y', via some Xpath filter, > > This filter *is* different, because: > > 1) if a start time is present, the agent should look in the log > 2) if a stop time is present, notification delivery is terminated by > the agent and the session becomes normal again. > It started out simple enough, just trying to model the "tail" and "tail -f" modes of reading a log file. The design seems to keep straying away from that model. > [But it didn't have to be different - if every event had a timestamp > (as in Sharon's original spec), you could have used the normal filter > mechanism, and let the agent implementor worry about optimizing away > the log search if the timestamp in the filter was late enough. > IMO, this is part of a more general problem, that should be solved by a separate RFC. The 'eventClass', 'eventSeverity', and 'eventTime' fields are meta-data which could be encoded as XML attributes in the element. This should be required, even if the proprietary has some or all of these fields already. This is why I keep asking the WG: Are you SURE you want to forbid all XML attributes, forever, from being included in the element? Are you SURE this is not going to ever come up again as an issue, because this is the only place we can really put inter-operable meta-data into the notification message? (All we need is an 'anyAttribute' clause in the definition...) > But if it was a normal filter, the agent would have to check the > stored notifications _unless_ the filter contained the > timestamp/sequenceID. This is different from today where the default > (no start/stop time) means subscribe to live notifications only. > > You would never get back to "normal mode" though.] > >> The filter applies to the data in the log, not notifications >> that have not happened yet. > > This also makes it different - the other filter applies to all > notifications, logged or live. What if the stopTime in the future happens before the agent is done sending the replay notifications? Does the agent stop, hang, revert to normal mode, transition to a new mode? That's why I want to keep it simple. I guess I never liked the stopTime transition back to normal mode, and it doesn't matter if it happens when the reply buffer is empty or at some specified time 'X', after that. > > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 08 17:34: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 1IItAW-0006gg-TA for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 17:34:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IItAV-0003MY-Lm for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 17:34:16 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIt4A-000LYk-Ch for netconf-data@psg.com; Wed, 08 Aug 2007 21:27: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=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 1IIt3z-000LWJ-JU for netconf@ops.ietf.org; Wed, 08 Aug 2007 21:27:37 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 923021B80C5; Wed, 8 Aug 2007 23:27:30 +0200 (CEST) Date: Wed, 08 Aug 2007 23:27:18 +0200 (CEST) Message-Id: <20070808.232718.66373367.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point From: Martin Bjorklund In-Reply-To: <46BA309D.2090807@andybierman.com> References: <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@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: cf4fa59384e76e63313391b70cd0dd25 Andy Bierman wrote: > What if the stopTime in the future happens before the agent > is done sending the replay notifications? Nothing special, since the stopTime just means that the agent is supposed to send all notifications that were generated before that time. When that's done (whenever that happens) it reverts to normal mode. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 08 21:50: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 1IIxAJ-0007tj-M6 for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 21:50:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIxAI-0006xW-AY for netconf-archive@lists.ietf.org; Wed, 08 Aug 2007 21:50:19 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIx0A-000KYm-2k for netconf-data@psg.com; Thu, 09 Aug 2007 01:39: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 [68.142.229.104] (helo=smtp101.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIwzy-000KY1-Mo for netconf@ops.ietf.org; Thu, 09 Aug 2007 01:39:44 +0000 Received: (qmail 31675 invoked from network); 9 Aug 2007 01:39:34 -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; 9 Aug 2007 01:39:34 -0000 X-YMail-OSG: fZLN7uEVM1lVJLUrkL8LVzWjW0rTsLWJTxFuzRLuur42h0s0RRVRkS9UY7xi1MOltHAcPWLv63bXm.xxNbfMroZDb3CkZYvHmQLw43WJe5NaNoW1Kbk9bQ-- Message-ID: <46BA6FFD.30004@andybierman.com> Date: Wed, 08 Aug 2007 18:38: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: Notification #9: replay in the future consensus point References: <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@andybierman.com> <20070808.232718.66373367.mbj@tail-f.com> In-Reply-To: <20070808.232718.66373367.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: 769a46790fb42fbb0b0cc700c82f7081 Martin Bjorklund wrote: > Andy Bierman wrote: >> What if the stopTime in the future happens before the agent >> is done sending the replay notifications? > > Nothing special, since the stopTime just means that the agent is > supposed to send all notifications that were generated before that > time. When that's done (whenever that happens) it reverts to normal > mode. > This seems like more trouble to implement than it is worth. I think I am not the only one that does not see a need to expand the replay feature into something that requires the agent to treat each corner case differently. The simple case -- the start to stop interval represents log entries -- seems to be getting WG consensus. I have not heard much support for applying stopTime-in-the-future as an additional mechanism to transition to live notifications but stop after some of them. I think WG consensus is converging on the idea that the replay feature applies only to logged entries that exist when the is received. I also think WG consensus is converging towards allowing interleaving. I do not know yet if there is consensus that an agent MUST support in notification mode, even if no other operations are supported. I think only one person wants to make sure the agent MUST NOT accept any interleaved RPCs. There seems to be consensus that this option is not what the WG wants. I think the "manager SHOULD NOT send, and the agent MAY NOT process" language is not inter-operable and does not allow for . This is very important text, so we have to keep working on it until it is right. > > /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 Aug 09 03:45: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 1IJ2hf-0000CO-HE for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 03:45:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ2he-0003YD-92 for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 03:45:07 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ2Y3-0004nH-Nf for netconf-data@psg.com; Thu, 09 Aug 2007 07:35: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 [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ2Xs-0004kM-AU for netconf@ops.ietf.org; Thu, 09 Aug 2007 07:35:06 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D0CA45483B2; Thu, 9 Aug 2007 09:34:29 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-cc-46bac38505f2 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB76C520001; Thu, 9 Aug 2007 09:34:29 +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, 9 Aug 2007 09:34:29 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 09:34:28 +0200 Message-ID: <46BAC385.1050607@ericsson.com> Date: Thu, 09 Aug 2007 09:34:29 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@andybierman.com> In-Reply-To: <46BA309D.2090807@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 07:34:28.0838 (UTC) FILETIME=[B80F7860:01C7DA57] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hello, As we see it 'eventClass', 'eventSeverity','eventTime' and 'eventSender' are not meta-data but real data, they are essential and mandatory parts of every notification. I would really prefer them as elements instead of attributes. I can even foresee someone extending eventClass with a vendor specific evntSubClass. On the other hand extensibility is good, so an anyAttribute does no harm. Balazs Andy Bierman wrote: > > The 'eventClass', 'eventSeverity', and 'eventTime' fields > are meta-data which could be encoded as XML attributes > in the element. This should be > required, even if the proprietary has > some or all of these fields already. > > This is why I keep asking the WG: > Are you SURE you want to forbid all XML attributes, forever, > from being included in the element? > > Are you SURE this is not going to ever come up again > as an issue, because this is the only place we can > really put inter-operable meta-data into the notification message? > > (All we need is an 'anyAttribute' clause in the > definition...) > -- to unsubscribe send a message to netconf-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 Aug 09 07:26:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ6A3-0003rv-HI for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 07:26:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ6A2-0007o0-5t for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 07:26:39 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ60P-00053G-PO for netconf-data@psg.com; Thu, 09 Aug 2007 11:16: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=BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.93] (helo=smtp112.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ60E-00050j-LS for netconf@ops.ietf.org; Thu, 09 Aug 2007 11:16:36 +0000 Received: (qmail 24838 invoked from network); 9 Aug 2007 11:16:26 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp112.sbc.mail.re2.yahoo.com with SMTP; 9 Aug 2007 11:16:26 -0000 X-YMail-OSG: kjrE9qoVM1l7KIux07LzOur8dgsXxLEn8yYh_YuHEOMaoRJ6tGuyz2xiBqXoz29aDYg7PtDHZ2fu2M21dlV_6FsV_7XbnNHbbflmViv8TWvOXSwtj2KRzw-- Message-ID: <46BAF731.5000609@andybierman.com> Date: Thu, 09 Aug 2007 04:14:57 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Balazs Lengyel CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@andybierman.com> <46BAC385.1050607@ericsson.com> In-Reply-To: <46BAC385.1050607@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: 4d87d2aa806f79fed918a62e834505ca Balazs Lengyel wrote: > Hello, > As we see it 'eventClass', 'eventSeverity','eventTime' and 'eventSender' > are not meta-data but real data, they are essential and mandatory parts > of every notification. I would really prefer them as elements instead of > attributes. I can even foresee someone extending eventClass with a > vendor specific evntSubClass. Think about this statement. If a vendor was to extend the standard definitions, they would no longer be standard. From an XML-PoV, these extensions belong in the standard or vendor-defined , in a different namespace. The value of 'fixed' standard fields is that they are fixed, and a manager can count on them meaning what they are supposed to mean across all agent implementations. Andy > On the other hand extensibility is good, so an anyAttribute does no harm. > Balazs > > Andy Bierman wrote: >> >> The 'eventClass', 'eventSeverity', and 'eventTime' fields >> are meta-data which could be encoded as XML attributes >> in the element. This should be >> required, even if the proprietary has >> some or all of these fields already. >> >> This is why I keep asking the WG: >> Are you SURE you want to forbid all XML attributes, forever, >> from being included in the element? >> >> Are you SURE this is not going to ever come up again >> as an issue, because this is the only place we can >> really put inter-operable meta-data into the notification message? >> >> (All we need is an 'anyAttribute' clause in the >> definition...) >> > > > -- to unsubscribe send a message to netconf-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 Aug 09 07:59: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 1IJ6fu-0005S2-IY for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 07:59:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ6ft-0008Vi-AU for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 07:59:34 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ6Xb-0008O3-Tz for netconf-data@psg.com; Thu, 09 Aug 2007 11:50: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 [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ6XQ-0008N9-Ep for netconf@ops.ietf.org; Thu, 09 Aug 2007 11:50:54 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1AB5E204D1 for ; Thu, 9 Aug 2007 13:50:44 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-40-46baff9325db Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E80862020E for ; Thu, 9 Aug 2007 13:50:43 +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, 9 Aug 2007 13:50:43 +0200 Received: from selic023.ki.sw.ericsson.se ([147.214.88.125]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 13:50:43 +0200 From: David Partain Organization: Ericsson AB To: "'Netconf \(E-mail\)'" Subject: Re: NETCONF Issue Tracker Date: Thu, 9 Aug 2007 13:50:44 +0200 User-Agent: KMail/1.9.7 References: <46AAF304.2030701@andybierman.com> <46AB8A66.90800@andybierman.com> <00cb01c7d2f4$87ea9760$0600a8c0@china.huawei.com> In-Reply-To: <00cb01c7d2f4$87ea9760$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708091350.44931.david.partain@ericsson.com> X-OriginalArrivalTime: 09 Aug 2007 11:50:43.0486 (UTC) FILETIME=[841093E0:01C7DA7B] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Monday 30 July 2007 23:56:45 David B Harrington wrote: > 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. Hi, I don't agree. If an issue is raised on the document, it needs to be addressed and closed. We shouldn't have to raise a new issue just 'cause the document has been revised. Presumably, if it hasn't been closed, it's still relevant to the new rev or should be closed. Cheers, David -- to unsubscribe send a message to netconf-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 Aug 09 08:27:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ76x-0004nL-6L for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 08:27:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ76v-0000av-UB for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 08:27:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ6yK-000BAE-JI for netconf-data@psg.com; Thu, 09 Aug 2007 12: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [68.142.229.92] (helo=smtp113.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ6y9-000B7Z-M7 for netconf@ops.ietf.org; Thu, 09 Aug 2007 12:18:31 +0000 Received: (qmail 39758 invoked from network); 9 Aug 2007 12:18:21 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp113.sbc.mail.re2.yahoo.com with SMTP; 9 Aug 2007 12:18:21 -0000 X-YMail-OSG: bKK9picVM1mEvaM4UWL5kso4Z_W0cfmUIWoBI8yDImhUM4N7 Message-ID: <46BB05B4.70902@andybierman.com> Date: Thu, 09 Aug 2007 05:16:52 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Partain CC: "'Netconf (E-mail)'" Subject: Re: NETCONF Issue Tracker References: <46AAF304.2030701@andybierman.com> <46AB8A66.90800@andybierman.com> <00cb01c7d2f4$87ea9760$0600a8c0@china.huawei.com> <200708091350.44931.david.partain@ericsson.com> In-Reply-To: <200708091350.44931.david.partain@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: e5ba305d0e64821bf3d8bc5d3bb07228 David Partain wrote: > On Monday 30 July 2007 23:56:45 David B Harrington wrote: >> 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. > > Hi, > > I don't agree. If an issue is raised on the document, it needs to be > addressed and closed. We shouldn't have to raise a new issue just 'cause the > document has been revised. Presumably, if it hasn't been closed, it's still > relevant to the new rev or should be closed. > The field is supposed to mean the version the defect was discovered. It should not change, but it is good to track this info, as well as the version that supposedly fixes the defect. > Cheers, > > David > 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 Aug 09 10:03: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 1IJ8bZ-0001MU-9Q for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 10:03:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ8bX-0002TD-V5 for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 10:03:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ8Tb-0000wX-Pl for netconf-data@psg.com; Thu, 09 Aug 2007 13:54: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=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 1IJ8TQ-0000vg-G3 for netconf@ops.ietf.org; Thu, 09 Aug 2007 13:54:54 +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 l79DsiS22630 for ; Thu, 9 Aug 2007 13:54:44 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: Notifications: Proposed edits not included and why Date: Thu, 9 Aug 2007 09:54:06 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41049EBE2@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notifications: Proposed edits not included and why Thread-Index: AcfajMC5JMTEy/RNRKKMcEOImeMQ9A== From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Hi The following are suggested edits that I did not execute and my reasoning. 1. Misc. changes that got overwritten by subsequent changes or wg agreement. 2. Chapter 4) Why do we need a streamNameType? It is just a string. A-> People wanted everything to be a type in order to enable extensibility. 3. In section 3.2.2 it says: 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." A-> I think the current text is fine. 4. Didn't s/Schema/schema/ since it seems appropriate to capitalize. 5. There was a suggestion that since filtering was explained in the base protocol specification, we don't need to explain it again in the notification context. I don't agree. I think saying it is the same and then confirming what that means in this context will ensure better interoperability. 6. Didn't move section 5 to an appendix. This has been discussed before, and I believe there is agreement to keep it where it is. 7. In section 6., para 2 it says: 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?" A-> I think the current text, while vague is fine for the security considerations section. Can we access the impact without making assumptions about the access control framework? 8. @@ -410,12 +410,12 @@ Negative Response: =20 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. A-> I believe the original text is better. 9. @@ -473,12 +473,12 @@ =20 Description: =20 - 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 A->I believe the original text is better. 10. @@ -490,7 +490,7 @@ =20 Response: =20 - No response. Not applicable. + This is not applicable as there is no response. A-> I believe the original text is better. Note that this text is not in a paragraph. 11. - XPATH support for the Notification capability is advertised as part + XPATH support for the notification capability is advertised as part A-> Again, I believe capitalization is appropriate. 12. 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. A-> I added the comma, but I believe the original text was better otherwise. 13. @@ -1012,7 +1011,7 @@ =20 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. A-> I don't actually think there is suppose to be a comma there, or at least one is not required. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 09 10:36:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ97m-0003vr-9j for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 10:36:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ97j-0003Cb-V7 for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 10:36:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ8wf-0004ZX-Jp for netconf-data@psg.com; Thu, 09 Aug 2007 14:25: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 [68.142.229.104] (helo=smtp101.sbc.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJ8wO-0004WP-6O for netconf@ops.ietf.org; Thu, 09 Aug 2007 14:24:53 +0000 Received: (qmail 43924 invoked from network); 9 Aug 2007 14:24:43 -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; 9 Aug 2007 14:24:41 -0000 X-YMail-OSG: Lq.gHzMVM1lF59UZnIiAxZvOz2CCL9izkbsh0OKWvAvdfrCA7SlZsOCrCit0lNUMizFfw9XMrBuwpU12Kna2HjegIXvsk50pOtwJB772mqcVsatOx1BbfZt.eDZwYVA- Message-ID: <46BB2350.7090106@andybierman.com> Date: Thu, 09 Aug 2007 07:23:12 -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: Pre-release 2 of Notification Update References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@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: f78a477504af065c5dcd07c0a5a2b344 Sharon Chisholm wrote: > Hi > > I'm almost done the update (hopefully). Attached is a pre-release. > Please let me know if anything was incorrectly executed. > <> > It's hard for me to read through all the diff formatting, but this looks really good, from what I can tell. Andy > Disclaimers: > > 1. I have not validated much of the schema or examples > 2. I got a bit confused in the updates to section 5.2. These may still > have issues. > 3. I have not done anything about replays in the future. The text > remains unchanged in this area. > 4. I need to double check that I have not missed updates. > 5. There were a few changes (mainly editorial) that I did not make for > specific reasons which I need to send an email to discuss. > 6. Not sure if using correct namespace in section 2.1.1.1. Andy said > what was there was wrong, but it validates for me and there was no > suggestions. I tried something else, but it didn't validate. > 7. There was a request to add description of how to define notification > instances, which has not been added, but there are now two examples (one > in replayComplete and one in the examples in section 5). Is this > sufficient? > 8. I have not validate that I am always using the correct The URI > string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > > > ------------------------------------------------------------------------ > > > Network Working Group S. Chisholm > Internet-Draft Nortel > Intended status: Standards Track H. Trevino > Expires: January *February* 9, 2008 Cisco > July > *August* 8, 2007 > > NETCONF Event Notifications > draft-ietf-netconf-notification-08.txt.pre-release > *draft-ietf-netconf-notification-09.txt.prerelease2* > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January *February* 9, 2008. > > Copyright Notice > > Copyright (C) The IETF Trust (2007). > > Abstract > > 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. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 > 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 > 1.3. Event Notifications in NETCONF . . . . . . . . . . . . . . 5 > 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 > 2. Notification-Related Operations . . . . . . . . . . . . . . . 7 > 2.1. Subscribing to Receive Event Notifications . . . . . . . . 7 > 2.1.1. . . . . . . . . . . . . . . . . 7 > 2.2. Sending Event Notifications . . . . . . . . . . . . . . . 9 > 2.2.1. . . . . . . . . . . . . . . . . . . . . 9 > 2.3. Terminating the Subscription . . . . . . . . . . . . . . . 10 > 3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 11 > 3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 11 > 3.1.1. Capability Identifier . . . . . . . . . . . . . . . . 11 > 3.1.2. Capability Example . . . . . . . . . . . . . . . . . . 11 > 3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 11 > 3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 12 *13* > 3.2.2. Event Stream Content Format . . . . . . . . . . . . . 13 > 3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 13 > 3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 13 > 3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 13 > 3.3. Notification Replay . . . . . . . . . . . . . . . . . . . 15 *16* > 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15 *16* > 3.3.2. Creating a Subscription with Replay . . . . . . . . . 16 > 3.3.3. Replay Complete Notification . . . . . . . . . . . . . 16 > 3.4. Notification Management Schema . . . . . . . . . . . . . . 16 *17* > 3.5. Subscriptions Data . . . . . . . . . . . . . . . . . . . . 19 *20* > 3.6. Filter Mechanics . . . . . . . . . . . . . . . . . . . . . 19 *20* > 3.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 19 *20* > 3.7. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 19 *20* > 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 21 *23* > 5. Filtering Examples . . . . . . . . . . . . . . . . . . . . . . 25 *27* > 5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 25 *30* > 5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 28 *31* > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 *33* > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 *34* > 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 *35* > 9. Normative References . . . . . . . . . . . . . . . . . . . . . 33 *36* > Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 34 *37* > A.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 34 *37 > A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 39* > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 *42* > Intellectual Property and Copyright Statements . . . . . . . . . . 38 *43* > > 1. Introduction > > [NETCONF] can be conceptually partitioned into four layers: > > Layer Example > +-------------+ +----------------------------------------+ > | Content | | Configuration data | > +-------------+ +----------------------------------------+ > | | > +-------------+ +-------------------------------------------+ > | Operations | | , | > +-------------+ +-------------------------------------------+ > | | | > +-------------+ +-----------------------------+ | > | RPC | | , | | > +-------------+ +-----------------------------+ | > | | | > +-------------+ +------------------------------------------+ > | Transport | | BEEP, SSH, SSL, console | > | Protocol | | | > +-------------+ +------------------------------------------+ > > Figure 1 > > 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 memo defines the capabilities and operations > necessary to support this service. > > 1.1. Definition of Terms > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > Element: An [XML] Element. > > Subscription: An agreement and method to receive event notifications > over a NETCONF session. A concept related to the delivery of > 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 *Within* this document, operation refers to NETCONF > protocol operations defined in support of NETCONF notifications. > > Event: An event is something that happens which may be of interest - > a configuration change, a fault, a change in status, crossing a > threshold, or an external input to the system, for example. Often > this results in an asynchronous message, sometimes referred to as > a notification or event notification, being sent to interested > parties to notify them that this event has occurred. > > Replay: The ability to send/re-send previously logged notifications > upon request. These notifications are sent asynchronously. This > feature is implemented by the NETCONF server and invoked by the > NETCONF client. > > Stream: An event stream is a set of event notifications matching > some forwarding criteria and it is available to NETCONF clients > for subscription. > > Filter: A parameter that indicates which subset of all possible > events are of interest. *A filter is defined as one or more filter > element [NETCONF], which each identifies a portions of the overall > filter.* > > 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. > > 1.3. Event Notifications in NETCONF > > This memo defines a mechanism whereby > > *The scope of* the NETCONF client indicates > interest *work aims meeting the following operational needs: > > o Initial release should ensure it supports notifications* in receiving event *support > of configuration operations. > > o It should be possible to use the same data model for* notifications from > *as for configuration operations. > > o Solution should support* a NETCONF server by > creating *reasonable message size limit (i.e., not > too short) > > o The notifications should be carried over* a *connection-oriented > delivery mechanism. > > o A* subscription to receive event notifications. The *mechanism for notifications should be provided. > This takes into account that a* NETCONF server replies to indicate whether the subscription request was > successful and, if it was successful, begins sending the event *does not send* > notifications *before being asked* to *do so and that it is* the > NETCONF client as the events occur within *who initiates* the > system. These event *flow of notifications. > > o A filtering mechanism for sending* notifications will continue to *should* be sent until > either *put in > place within the NETCONF server. > > o The information contained in a notification should be sufficient > so that it can be analyzed independent of the transport mechanism. > In other words the data content fully describes a notification; > protocol information is not needed to understand a notification. > > o The server should have the capability to replay locally logged > notifications. > > 1.3. Event Notifications in NETCONF > > This memo defines a mechanism whereby the NETCONF client indicates > interest in receiving event notifications from a NETCONF server by > creating a subscription to receive event notifications. The NETCONF > server replies to indicate whether the subscription request was > successful and, if it was successful, begins sending the event > notifications to the NETCONF client as the events occur within the > system. These event notifications will continue to be sent until > either* the NETCONF session is terminated or the subscription > terminates for some other reason. The event notification > subscription allows a number of options to enable the NETCONF client > 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 > session associated with the subscription until the *client SHOULD NOT send requests while a* notification subscription > is done. A capability may be advertised to announce > that a *active, because the* server is able to *MAY NOT* process RPCs while a notification stream is > active on a session. The behaviour *them. An example* of such > *when the notifications would be process is if* a *separate* capability is outside > the scope > *was advertised indicating support* of this document. > > 1.4. Requirements *functionality. > > 2. Notification-Related Operations > > 2.1. Subscribing to Receive Event Notifications* > > The following requirements have been addressed *event notification subscription is initiated* by the solution: > > o Initial release should ensure it supports notification in support > of configuration operations > > o Data content must not preclude *NETCONF > client and responded to by* the use *NETCONF server. A subscription is > bound to a single stream for the lifetime* of the same data model as > used in configuration > > o Solution should support a reasonable message size limit (ie, not > too short) > > o Solution should provide reliable delivery of notifications > > 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) > > o Solution should provide a filtering mechanism within the NETCONF > server > > o Solution should send sufficient information in a notification so > that it can be analyzed independent of the transport mechanism > (data content fully describes a notification; protocol information > is not needed to understand a notification) > > o Solution should support replay of locally logged notifications > > 2. Notification-Related Operations > > 2.1. Subscribing to Receive Event Notifications > > The event notification subscription is initiated by the NETCONF > client and responded to by the NETCONF server. *subscription.* When > the event notification subscription is created, the events of > interest are specified. > > Content for an event notification subscription can be selected by > applying user-specified filters. > > 2.1.1. > > Description: > > This operation initiates an event notification subscription which > will send asynchronous event notifications to the initiator of the > command until the subscription terminates. > > Parameters: > > Stream: > > An optional parameter *parameter, ,* that indicates which stream of > events is of interest. If not present, then events in the default > NETCONF stream will be sent. > > Filter: > > An optional parameter *parameter, ,* that indicates which subset of > all possible events are *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 information on filters. > > Start Time: > > A parameter *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 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. > > Stop Time: > > An optional parameter *parameter, ,* used with the optional > replay feature to indicate the newest notifications of > interest. If stop time 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 later than the current time. This > parameter is of type dateTime. > > Positive Response: > > If the NETCONF server can satisfy the request, the server sends an > element. > > Negative Response: > > An element is included within the if the > request cannot be completed for any 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: > > Tag: missing-element > > Error-type: protocol > > Severity: error > > Error-info: : *:* startTime > > Description: An expected element is missing. > > If the optional replay feature is requested but it is not > supported by the NETCONF server, the following error is returned: > > Tag: operation-failed > > Error-type: protocol > > Severity: error > > Error-info: none > Description: Request could not be completed because the > requested operation failed for some reason not covered by any > other error condition > > 2.1.1.1. Usage Example > > *The following demonstrates creating a simple subscription. More > complex examples can be found in section 5.* > > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > *xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"\>* > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > > > > Figure 2 > > 2.2. Sending Event Notifications > > Once the subscription has been set up, the NETCONF server sends the > event notifications asynchronously over the connection. > > 2.2.1. > > 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 XML > document. Note that is not an RPC method but > rather the top level element identifying the one way *one-way* message as a > notification. > > Parameters: > > Contains notification-specific tagged content. *content, if any.* The > content of the data tag is beyond the scope of this document. > > Response: > > No response. Not applicable. > > 2.3. Terminating the Subscription > > 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 > reached. In this case, the NETCONF session will still be an active > session. > > 3. Supporting Concepts > > 3.1. Capabilities Exchange > > The ability to process and send event notifications is advertised > during the capability exchange between the NETCONF client and server. > > 3.1.1. Capability Identifier > > "urn:ietf:params:netconf:capability:notification:1.0" > > 3.1.2. Capability Example > > > > > urn:ietf:params:xml:ns:netconf:base:1.0 > > > urn:ietf:params:netconf:capability:startup:1.0 > > > urn:ietf:params:netconf:capability:notification:1.0 > > > 4 > > > Figure 3 > > 3.2. Event Streams > > 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 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 classification and distribution. > The central component inspects each event notification and matches > the event notification against the set of stream definitions. When a > match occurs, the event notification is considered to be a member of > that event stream (stream 1..stream n). An event notification may be > part of multiple event streams. > > *At some point after the 'NETCONF server' receives the internal event > from a stream, it is converted to an appropriate 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.* > > When a NETCONF client subscribes to a given event stream, user- > defined filters, *filter elements,* 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. A notification logging service may also be available, in which case, > the *filter is > transferred from the client to the agent during the subscription> operation and applied against each > element generated by the stream. For more information on filtering, > see section 3.6. > > A notification logging service may also be available, in which case, > the* central component logs notifications. The NETCONF server may > later retrieve logged notifications via the optional replay feature. > For more information on replay, see section 3.3. > > +----+ > | c1 |----+ available streams > +----+ | +---------+ > +----+ | |central |-> stream 1 > | c2 | +--->|event |-> stream 2 filter +-------+ > +----+ | |processor|-> NETCONF stream ----->|netconf| *----->|NETCONF|* > ... | | |-> stream n |server | > System | +---------+ +-------+ > Components| | /\ > ... | | || > +----+ | | (------------) || > | cn |----+ | (notification) || > +----+ +-----> ( logging ) || > ( service ) || > (------------) || > || > || > \/ > +-------+ > |netconf| > *|NETCONF|* > |client | > +-------+ > > Figure 4 *2* > > 3.2.1. Event Stream Definition > > Event streams are predefined on the managed device. The > configuration of event streams is outside the scope of this document. > However, it is envisioned that event streams are either pre- > established by the vendor (pre-configured) or *(pre-configured),* user configurable (e.g., > part of the device's configuration) or both. Device vendors may > allow event stream configuration via *the* NETCONF protocol (i.e., > edit-config operation). > > 3.2.2. Event Stream Content Format > > 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. > > 3.2.3. Default Event Stream > > A NETCONF server implementation supporting the notification > capability must support the "NETCONF" notification event stream. > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. The definition *exact string "NETCONF" is used to during > advertisement of stream support during operation on > and during the operation. Definition* of the > event notifications and their contents for this event stream is > outside the scope of this document. > > 3.2.4. Event Stream Sources > > With the exception of the default event stream (NETCONF > notifications) > *notifications),* specification of additional event stream sources > (e.g., SNMP, syslog, etc.) *syslog)* is outside the scope of this document. NETCONF > server implementations may leverage any desired event stream source > in the creation of supported event streams. > > 3.2.5. Event Stream Discovery > > A NETCONF client retrieves the list of supported event streams from a > NETCONF server using the RPC request. *operation.* > > 3.2.5.1. Name Retrieval using operation > > The list of available event streams is retrieved by requesting the > > ** 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 > *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 > control mechanisms which are beyond the scope of this document. An empty reply is returned if there are no available event > streams. The > > *Additional* information *available about a stream include whether > notification replay* is retrieved by requesting *available and if so,* the subtree via > a operation. *timestamp if the > earliest possible notification to replay.* > > Example: Retrieving *the list of* available event stream list using > operation: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > * > > * > > > > > Figure 5 > The NETCONF server returns a list of event streams available for > subscription: NETCONF, SNMP, and syslog-critical in this example. > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > * > ** > > NETCONF > Default 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 > > > * > * > > > Figure 6 > > 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 subscription> request with the desired event stream name. Omitting > the event stream name from the request results > in subscription to the default NETCONF event stream. > > 3.2.5.2.1. Filtering Event Stream Contents > > The set of event notifications delivered in an event stream may be > further refined by applying a user-specified filter *supplied* at > subscription creation time ( ). This is a > transient filter associated with the event notification subscription > and does not modify the event stream configuration. *Either subtree > or XPATH filtering can be used.* > > 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 > XPATH is not supported for notification filtering. > > 3.3. Notification Replay > > 3.3.1. Overview > > Replay is the ability to create an event subscription that will > resend recently generated notifications, or in some cases send them > for the first time to a particular NETCONF client. These > 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 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. > > A notification stream that supports replay is not expected to have an > unlimited supply of saved notifications available to accommodate any > replay request. > > The actual number of stored notifications available for retrieval at > any given time is a NETCONF server implementation specific matter. > Control parameters for this aspect of the feature are outside the > scope of the current *this* document. > > 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 *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 indicate the earliest available logged notification. > > 3.3.2. Creating a Subscription with Replay > > This feature uses optional parameters to the > command called 'startTime' ** and 'stopTime'. '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 > for event notifications being replayed. If it is not present, then > notifications will continue to be sent until the subscription is > terminated. > > Note that startTime ** and stopTime ** are associated with the time an > event was generated by the system. *event source.* > > 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. *The > NETCONF server will then accept operations.* 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 *sent,* > followed by notifications as they arise naturally within the system. > > 3.3.3. Replay Complete Notification > > The replayComplete notification is the last notification sent over a > replay subscription. It indicates that replay is complete. After > this ** notification is received the subscription is terminated and the > session becomes normal command-response NETCONF session. > > The replayComplete can not *cannot* be filtered out. It will > always be sent on a relay *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, * > notification,* which is sent to indicate that an event replay has sent > all applicable > notifications." *notifications.* > > > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:ncEvent="urn:ietf:params:netconf:capability:notification:1.0" > xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification" > targetNamespace="urn:ietf:params:xml:ns:netmod:notification" > elementFormDefault="qualified" > attributeFormDefault="unqualified"> > *attributeFormDefault="unqualified" > xml:lang="en" version="1.0">* > > > A schema that can be used to learn about current > event streams. It also > contains the replayComplete notification. > > > > schemaLocation="http://www.w3.org/2001/xml.xsd"/> > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > "urn:ietf:params:netconf:capability:notification:1.0" > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> > ** > > > > > > > > > The list of event streams supported by the > system. When a query is issued, the returned > set of streams is determined based on user > privileges. > > > > > > > > Stream name and description. > > > > > > type="xs:string"/> > type="xs:boolean"/> > type="xs:dateTime" minOccurs="0"> > *type="ncEvent:streamNameType">* > > > The start time *name* of the log used to > support *event stream. If this is* > the replay function. This > object MUST be present *default NETCONF stream, this must have > the value "NETCONF". > > > > type="xs:string"> > > > A description of the event stream, including > such information as the type of events that > are sent over this stream. > > > > type="xs:boolean"> > > > An indication of whether or not event replay > is available on this stream. > > > > type="xs:dateTime" minOccurs="0"> > > > The timestamp of the earliest available > notification in the log used to > support the replay function. This > object MUST be present* if replay is > supported. > > > > > > > > > > > > > > > > > > > type="manageEvent:ReplayCompleteNotificationType" > substitutionGroup="ncEvent:notificationContent"> > > > This notification is sent to signal the end of a replay > portion of a subscription. > > > > > > > > Figure 7 > > 3.5. Subscriptions Data > > While it may be possible to retrieve information about subscriptions > via a get operation, subscriptions are not stored configuration. > They > > *Subscriptions* are non-persistent state information and their lifetime > is defined by their session. > > 3.6. Filter Mechanics > > When multiple filter elements are specified, they are applied > collectively, so event notifications need to pass all specified > filters > *filter elements* in order to be sent to the subscriber. 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. For example, if one were to check for 'severity=critical' in a > configuration event notification where this field was not supported, > then the notification would be filtered out. > > The order > > *For subtree filtering, a non-empty node set means* that filter elements are applied does not matter since the > resulting set of notifications is *filter > matches. For XPath fitlering,* the intersection of *mechanisms defined in [XPATH] > should be used to convert* the set of > notifications that pass each filtering criteria. *returned value to boolean.* > > 3.6.1. Filtering > > Filtering is explicitly stated when the event notification > subscription is created. This is specified via the 'filter' > parameter. Filters *A Filter* only exist as parameters *parameter* to the subscription. > > 3.7. Message Flow > The following figure depicts message flow between a NETCONF client > (C) and NETCONF server (S) in order *to* create a subscription and > begin the flow of notifications. *This subscription specified a > , so it starts by replaying logged notifications.* It is > possible that many rpc/rpc-reply sequences occur before the > subscription is created or after a > stopTime in a replay subscription, *created,* but this is not depicted in the figure. > > C S > | | > | capability exchange | > |-------------------------->| > |<------------------------->| > | | > | | > |-------------------------->| > |<--------------------------| > | | > | | > | | > |<--------------------------| > | | > | | > |<--------------------------| > | * | (replayComplete) > |<--------------------------| > | | > | | > |* | > | * | > |<--------------------------| > |* | > | | > | | > |<--------------------------| > | | > | | > > Figure 8 > > 4. XML Schema for Event Notifications *3* > The following [XML Schema] defines *figure depicts message flow between a* NETCONF Event Notifications. > > > xmlns="urn:ietf:params:netconf:capability:notification:1.0" > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" > targetNamespace= > "urn:ietf:params:netconf:capability:notification:1.0" > elementFormDefault="qualified" > attributeFormDefault="unqualified" > xml:lang="en"> > > > > schemaLocation="http://www.w3.org/2001/xml.xsd"> > > > This import accesses the xml: attribute groups for the > xml:lang as declared on *client > (C) and NETCONF server (S) in order to create a subscription and > begin* the error-message element. > > > > > | > |<------------------------->| > | | > | | > |-------------------------->| > |<--------------------------| > | | > | | > | | > |<--------------------------| > | | > | | > |<--------------------------| > | | (replayComplete) > |<--------------------------| > | | > | | > | | > | | > |-------------------------->| > |<--------------------------| > | | > | | > > Figure 4 > > 4. XML Schema for Event Notifications > > The following [XML Schema] defines NETCONF Event Notifications. > > > xmlns="urn:ietf:params:netconf:capability:notification:1.0" > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" > targetNamespace= > "urn:ietf:params:netconf:capability:notification:1.0" > elementFormDefault="qualified" > attributeFormDefault="unqualified" > xml:lang="en"> > > > > schemaLocation="http://www.w3.org/2001/xml.xsd"> > > > This import accesses the xml: attribute groups for the > xml:lang as declared on the error-message element. > > > > > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > > > > > > > > > > type="streamNameType" minOccurs="0"> > > > An optional parameter that indicates > which stream of events is of interest. If > not present, then events in the default > NETCONF stream will be sent. > > > > type="netconf:filterInlineType" > minOccurs="0"> > > > An optional parameter that indicates > which subset of all possible events > are > *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. > > > > minOccurs="0" > > > > 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 > replay subscription. > > > > minOccurs="0" > > > > An optional parameter used with the > optional replay feature to indicate the > newest notifications of interest. If > stop time is not present, the > notifications will continue until the > subscription is terminated. Must be used > with 'startTime'. *startTime.* > > > > > > > > > > > > The name of an event stream. > > > > > > type="createSubscriptionType" > substitutionGroup="netconf:rpcOperation"> > > > The command to create a notification subscription. It > takes as argument the name of the notification stream > and filter or profile information. *filter.* 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 > of interest. > > > > > > > > > > type="NotificationContentType" abstract="true"/> > > > > > > > > > > > Figure 9 > > 5. Filtering Examples > > The following section provides examples to illustrate the various > methods of filtering content on an event notification subscription. > > 5.1. Subtree Filtering > > 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 *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 > elements consisting of the event class (e.g., > fault, state, config, etc.) *config)* reporting entity and either severity or > operational state. > > Sample event list > > > fault > > Ethernet0 > > major > > > > fault > > Ethernet2 > > critical > > > > > *Examples in this section are generated from the following fictional > Schema. > > > xmlns="http://example.com/event/1.0" > elementFormDefault="qualified" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:ncEvent="urn:ietf:params:netconf:capability:notification:1.0"> > > "urn:ietf:params:netconf:capability:notification:1.0" > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> > > > > > > > > > > processContents="lax"/> > > > > > > > > > > > > > type="eventType" > substitutionGroup="ncEvent:notificationContent"/> > > > The above fictional notification definition could results following > is a sample notification list used in the examples in this section. > > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > > fault > > Ethernet0 > > major > > > > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > > fault > > Ethernet2 > > critical > > > > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > * > fault > > ATM1 > > minor > > * > > xmlns="urn:ietf:params:netconf:capability:notification:1.0">* > > state > > Ethernet0 > > enabled > > > Figure 10 > * > > 5.1. Subtree Filtering > > XML subtree filtering is not well-suited for creating elaborate > filter definitions given that it only supports equality comparisons > and application of the logical OR operators (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.* > > The following example illustrates selecting *how to select* events which have > severities of critical, major, or minor (presumably fault events). > The filtering criteria evaluation is as follows: > > ((severity=critical) | (severity=major) | (severity=minor)) > > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > > > fault > critical > > > fault > major > > > fault > minor > > > > > > Figure 11 > > The following example illustrates selecting *how to select* state or config > EventClasses or fault events that are related to card Ethernet0. The > filtering criteria evaluation is as follows: > > ( state | config | *(* fault & card=Ethernet0) *( severity=critical | severity=major | > severity = minor | card=Ethernet0)))* > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns="urn:ietf:params:netconf:capability:notification:1.0"> > > > fault > > > state > > > config > > > fault > > Ethernet0 > > > *netconf:type="xpath" > xmlns:ex="http://example.com/event/1.0" > select="/ex:event[ > (ex:eventClass='state' or > ex:eventClass='config' or > ex:eventClass='fault') and > (ex:severity='minor' or > ex:severity='major' or > ex:severity='critical' or > ex:reportingEntity/ex:card='Ethernet0')]/>* > > > > 5.2. XPATH filters > > The following [XPATH] example illustrates selecting *how to select* fault > EventClass notifications that have severities of critical, major, or > minor. The filtering criteria evaluation is as follows: > > ((fault) & ((severity=critical) | (severity=major) | (severity = > minor))) > > 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='fault' and > (ex:severity='minor' or ex:severity='major' > or ex:severity='critical')]"/> > > > Figure 13 > > The following example illustrates selecting *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: > > (( state | config) & ((fault & severity=critical) | (fault & > severity=major) | (fault & severity = minor) | (fault & > card=Ethernet0))) > > 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='fault' > *(ex:eventClass='state' or ex:eventClass='config')* and ex:severity='minor') > *((ex:eventClass='fault' and ex:severity='critical')* or > (ex:eventClass='fault' and ex:severity='major') or > ex:eventClass='fault' > *(ex:eventClass='fault'* and ex:severity='critical') *ex:severity='minor')* or > (ex:eventClass='fault' and > ex:reportingElement/ex:card='Ethernet0') or > ex:eventClass='state' or > ex:eventClass='config']"/> *ex:card='Ethernet0'))]"/>* > > > > Figure 14 > > 6. Security Considerations > > The security considerations from the base [NETCONF] document apply 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 *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 > of the following commands: *execution:* > > o invocation > > o * on* read-only data models > > o read-write data models > > o notification ** content > > One issue related to the notifications draft is the transport of data from non-netconf *non-NETCONF* streams, such as > syslog and SNMP. This data may be more vulnerable (or is not more > vulnerable) when being transported over netconf *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 *applying* access control to stream > content. > > *The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users.* If a user does not have > permission to view content via other NETCONF > operations *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. > > 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. > > 7. IANA Considerations > > This document registers two *three* URIs for the NETCONF XML namespace in > the IETF XML registry [RFC3688]. > > Following the format in RFC 3688, IANA has made the following > registration. > > URI: urn:ietf:params:netconf:capability:notification:1.0 > > URI: urn:ietf:params:xml:ns:netmod:notification > > *URI: urn:ietf:params:xml:ns:netconf:notification* > > Registrant Contact: The IESG. > > XML: N/A, the requested URI is an XML namespace. > > 8. Acknowledgements > > Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing > their input into the early work on this document. In addition, the > 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 *David* 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, > Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William > Chow. *We would also like to thank Li Yan for his numerous reviews.* > > 9. Normative References > > [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, > December 2006. > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", RFC 2026, BCP 9, October 1996. > > [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements > Levels", RFC 2119, March 1997. > > [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", > RFC 2223, October 1997. > > [RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January > 2004. > > [XML] World Wide Web Consortium, "Extensible Markup Language > (XML) 1.0", W3C XML, February 1998, > . > > [XML Schema] > Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer > Second Edition", W3C XML Schema, October 2004. > > [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) > Version 1.0", > W3C http://www.w3.org/TR/1999/REC-xpath-19991116, > November 1999. > > Appendix A. Change Log > > A.1. Version -08 > > 1. Removed named profiles > > 2. Removed eventClass that was accidentally included in the > definition of the replayComplete notification > > 3. Deleted data wrapper from notification > > 4. Changed replayLogStartTime to have a minOccurs of 0. It will > only be there when replay is supported. Verify examples in > section 3.2.5.1 are correct with respect to this element. > > 5. Error codes in section 2.1.1, fixed formatting issue > > 6. Moved replayComplete to not be under > > 7. Section 2.1, fixed capitalization > > 8. In figure 4, the line was pushed out by 'system components', > fixed this. > > 9. On page 8, replaced "If the startTime specified is earlier then > the" with 'If the startTime specified is earlier than the" > > 10. Updated some name spaces and schemaLocations as per Andy's June > 3rd email. > > 11. Added discussion of replayLogStartTime to draft in section 3.3.1 > as follows "Whether or not a stream supports replay can be > discovered by doing a operation on the eventStreams ** elements > of the Notification Management Schema. This schema also > provides the replayLogStartTime element to indicate the earliest > available logged notification." > > 12. Removed most of the uses of the phrase 'Note that'. I kept two > uses that prevent sentences from starting with either a lower > case letter or an angle bracket. > > 13. In section 3.6 replaced "it will be filtered out" with "the > notification will be filtered out" > > 14. In section 3.4, replaced "and the query" with "and to query" > > 15. Replaced 3 instances of "replay complete notification" with > "replayComplete notification" > 16. In section 3.3.2, replaced "normal NETCONF session" with "normal > command-response NETCONF session" > > 17. In section 3.3.1, replaced "create an event subscription that > will resend recently generated notification" with "create an > event subscription that will resend recently generated > notification, or is some cases send them for the first time to a > particular NETCONF client." > > 18. In section 3.2.5.2, s/available event streams to/event streams > available to/ > > 19. In one spot, changed snmp to SNMP (the other gets deleted) > > 20. In section 3.2.5.1 s/where element is/where the > element is/ > > 21. In section 3.2.5.1, clarified that "value is unique" - within > the scope of a NETCONF server. > > 22. In section 2.1.1, clarified that stopTime cannot preceded start > time. > > 23. In section 2.1.1, in Start Time s/indicates/indicate/ > > 24. In section 2.1.1, in Filter: s/This is mutually exclusive/The > filter parameter is mutually exclusive/ ("this" could refer to > the behavior described in the previous sentence.) > > 25. In section 1.4, third bullet, replaced "syslog and SNMP are > rather constrained in terms of message sizes)" with (ie, not too > short) > > 26. In section 1.4, made all bullets start with capital leters. > > 27. Added definition of Filter to section 1.1 > > 28. In section 1.1, improved the definition of subscription with "An > agreement and method to receive event notifications over a > NETCONF session." > > 29. In section 1.1, in the definition of operation, added a > reference to [NETCONF]. > > 30. Created a change log section > > 31. Fixed reference to IETF XML Registry in IANA Considerations > section. > > 32. In section 3.3.3, deleted "This notification will only be sent > if a 'stopTime' was specified when the replay subscription was > created." > > 33. Added text to the security considerations section that says "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". > > 34. Update examples in section 5 to get rid of extra wrapper tag. > > 35. In section 2.1, replace "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." with "A NETCONF server is will > not read RPC requests, by default, on the session associated > with the subscription until the notification subscription is > done. > > 36. Updated the notification definition and the replyComplete > notification definition to use a substitution group. > > *A.2. Version -09 > > 1. In section 5.1 "logical OR operation" -> "application of the > logical OR operator" > > 2. In section 6 "ensure the secure operation of the following > commands" -> "secure execution" > > 3. Removed a couple remaining references to named profiles. > > 4. Updated name datatype in eventStreams element. > > 5. Modified the cardinality of eventStreams to reflect that there > will always be at least one event stream. > > 6. Fixed description of examples to remove reference to eventEntry, > which is no longer part of the actual example. > > 7. In examples, for consistency changed some references to > reportingElement to be reportingEntity > > 8. Fixed section 3.2, third pararaph to talk about filter elements > instead of filters. > > 9. Merge section 3.3.2 and section 3.3.3. Delete the first > paragraph in (old) section 3.3.3 since it both duplicates and > contradicts text in section 3.3.2 > > 10. In section 3.2.5.2.1, added clarification to first paragraph > that "Either subtree or XPATH filtering can be used. " > > 11. Removed discussion of not allowing the return of stream names > for which the user does not have permissions from the body of > the document to the security considerations section. > > 12. Fixed typos and did wordsmithing in various parts of the > document. > > 13. In section 2.1, explicitly stated that a subscription is bound > to a single stream for the lifetime of the subscription. > > 14. removed single quotes around some instances of stopTime and > startTime for consistency. When appropriate, put between angle > brackets. > > 15. In section 2.1.1, changed "Error-info: : startTime" > to use bad-element. > > 16. In section 2.2.1, under the parameter tag, replaced "Contains > notification-specific tagged content." with "Contains > notification-specific tagged content, if any. " > > 17. Clarified some text in section 3.2, paragraph 3 around sending > of filters from client and the fitlers later being applied to > the notifications. > > 18. Fixed target namespace in section 4. > > 19. Added missing lang and version information to schema in section > 3.4 > > 20. Clarified that the examples in section 5 all used the same > example event list. > > 21. Cleaned up security considerations section. > > 22. In section 3.4, clarified the definition of replayLogStart time > to be the timestamp of the earliest available notification in > the log used to support the replay function in the description > tag for the object definition. > > 23. In section 3.3.2, clarified that the time an event was generated > by the system means time an event was generated by the event > source. > > 24. In section 3.5, deleted discussion about possibly defining > subscriptions in XML Schema. > > 25. In section 3.6, deleted discussion about filter element > execution order not mattering. > > 26. Fixed examples in section 5 to add tag and to make > other corrections > > 27. Added XML Schema definition for examples in section 5 and showed > the event list with wrappers.* > > Authors' Addresses > > Sharon Chisholm > Nortel > 3500 Carling Ave > Nepean, Ontario K2H 8E9 > Canada > > Email: schishol@nortel.com > > Hector Trevino > Cisco > Suite 400 > 9155 E. Nichols Ave > Englewood, CO 80112 > USA > > Email: htrevino@cisco.com > > Full Copyright Statement > > Copyright (C) The IETF Trust (2007). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > Acknowledgment > > Funding for the RFC Editor function is provided by the IETF > Administrative Support Activity (IASA). > -- to unsubscribe send a message to netconf-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 Aug 09 12:04: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 1IJAVO-0008SC-5u for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 12:04:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJAVM-0005CN-U6 for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 12:04:58 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJAKP-000Fbi-BS for netconf-data@psg.com; Thu, 09 Aug 2007 15:53: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=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 1IJAKE-000FYG-0K for netconf@ops.ietf.org; Thu, 09 Aug 2007 15:53:31 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CA1B20142; Thu, 9 Aug 2007 17:53:23 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-e9-46bb3873e26c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5CD9F200FB; Thu, 9 Aug 2007 17:53:23 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 17:53:22 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 17:53:22 +0200 Message-ID: <46BB3872.5090400@ericsson.com> Date: Thu, 09 Aug 2007 17:53:22 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Pre-release 2 of Notification Update References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 15:53:22.0778 (UTC) FILETIME=[6A143BA0:01C7DA9D] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hello, I think we should add to the security considerations chapter: When notifications carry non-NETCONF streams, such as syslog or SNMP, the receiver of the data is a not the syslog server or the SNMP manager but a Netconf manager application. Transferring the same data to a different application might be a security risk depending on the level of trust in the applications and access control for the applications. 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 Aug 09 13:22: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 1IJBi5-000274-W8 for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 13:22:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJBi4-0007GU-Oq for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 13:22:09 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJBWe-0002Fm-Ly for netconf-data@psg.com; Thu, 09 Aug 2007 17:10: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=BAYES_00 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 1II6td-000FZZ-Ll for netconf@ops.ietf.org; Mon, 06 Aug 2007 18:01:43 +0000 Received: from localhost ([127.0.0.1] helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1II6t6-0004NN-Tm; Mon, 06 Aug 2007 20:01:04 +0200 Message-ID: <46B761E0.2030704@levkowetz.com> Date: Mon, 06 Aug 2007 20:01:04 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Andy Bierman CC: David Partain , "Netconf (E-mail)" Subject: Re: tracker version field References: <46B0CFD1.6020609@andybierman.com> In-Reply-To: <46B0CFD1.6020609@andybierman.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ietf@andybierman.com, david.partain@ericsson.com, netconf@ops.ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com 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: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Andy, On 2007-08-01 20:24 Andy Bierman said the following: > Hi, > > How do we change the fixed labels on the version field? Under the Admin tab, you'll be able to change those to anything you want. > Does it have to be a fixed field? Currently, yes. > The 'new ticket' form gives an option of 1.0' and '2.0'. > The real choice is -08, since this is an Internet draft, > not a C source file. Can we get the numbering changed, > so the version field shows the current I-D version > if the component is an I-D? Or just a string? That sounds like a plugin, which is possible but will take more time to get in place than using the admin interface to change the 1.0 and 2.0 to -00, -01, -02, -03 etc.; something you can do yourself (having admin rights) right away. Regards, Henrik -- to unsubscribe send a message to netconf-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 Aug 09 13:22: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 1IJBiL-00029m-HJ for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 13:22:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJBiK-0007Go-95 for netconf-archive@lists.ietf.org; Thu, 09 Aug 2007 13:22:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IJBZS-0002Xt-0n for netconf-data@psg.com; Thu, 09 Aug 2007 17:13: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.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 1IIOZh-000PBN-CA for netconf@ops.ietf.org; Tue, 07 Aug 2007 12:54:21 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 43C891B80C5; Tue, 7 Aug 2007 14:54:12 +0200 (CEST) Date: Tue, 07 Aug 2007 14:54:51 +0200 (CEST) Message-Id: <20070807.145451.137676189.mbj@tail-f.com> To: johan.rydberg@edgeware.tv Cc: balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: Questions on Confirmed commit From: Martin Bjorklund In-Reply-To: <46A76B84.6030102@edgeware.tv> References: <469C9CE9.5090209@ericsson.com> <46A76B84.6030102@edgeware.tv> 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: d185fa790257f526fedfd5d01ed9c976 Johan Rydberg wrote: > 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. But it also says: The confirming commit can itself include a parameter. I.e. a confirming commit can at the same time be a confirmed commit. Note that the way it's defined is that running is reverted _unless_ a confirming commit is sent, not that the changes are made persistent when a confirming commit is sent. So I think that the text in the rfc is consistent with the junos interpretation. Thus, a confirming confirmed commit with a zero timeout will explicitly revert running. But unfortunately, zero is not allowed, so you have to use a 1 second delay: 1 In any case this is not IMO crystal clear from the text. So the question is if the behaviour described above was the intention? Otherwise I'm sure we can find an interpretation of the current text which is consistent with the intention ;) /martin > 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: > -- to unsubscribe send a message to netconf-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 Aug 13 10:57: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 1IKbMB-00063O-L0 for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 10:57:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbMA-0007Sj-EU for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 10:57:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKbD8-00035t-42 for netconf-data@psg.com; Mon, 13 Aug 2007 14:48:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS, RDNS_NONE autolearn=no version=3.2.1 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 1IKbCx-000332-8n for netconf@ops.ietf.org; Mon, 13 Aug 2007 14:47:56 +0000 Received: from localhost ([127.0.0.1]:46785 helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IKbCu-0004gk-Kk; Mon, 13 Aug 2007 16:47:48 +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, 13 Aug 2007 14:47:48 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: Re: [Netconf] #14: notification termination mechanism considered dangerous X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netconf/trac/ticket/14#comment:1 Message-ID: <079.9d29ea151eb87f7d842e8caf6d416e66@tools.ietf.org> References: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: schishol@nortel.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 IzE0OiBub3RpZmljYXRpb24gdGVybWluYXRpb24gbWVjaGFuaXNtIGNvbnNpZGVyZWQgZGFuZ2Vy b3VzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIFJlcG9ydGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5j b20gICAgICAgICAgICAgfCAgICAgICBPd25lcjogICAgICAgICAgICAgICAgIA0KICAgICAgVHlw ZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcg ICAgICAgICAgICANCiAgUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgTWlsZXN0b25lOiAgICAgICAgICAgICAgICAgDQogQ29tcG9uZW50OiAgZHJhZnQtaWV0 Zi1uZXRjb25mLW5vdGlmaWNhdGlvbiAgfCAgICAgVmVyc2lvbjogICAgICAgICAgICAgICAgIA0K UmVzb2x1dGlvbjogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgS2V5d29y ZHM6ICBub3RpZmljYXRpb24tMDgNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNvbW1lbnQgKGJ5IHNj aGlzaG9sQG5vcnRlbC5jb20pOg0KDQogVGhpcyBoYXMgYmVlbiBkZXNpZ24gaW50ZW50IGV2ZXIg c2luY2UgaW50ZXJhY3RpdmUgbm90aWZpY2F0aW9uIHNlc3Npb25zDQogd2VyZSByZW1vdmVkIGFm dGVyIHRoZSBNb250cmVhbCBtZWV0aW5nLiBXaHkgaXMgdGhpcyBzdWRkZW5seSBhbiBpc3N1ZT8N Cg0KIERvIHdlIGV4cGVjdCB0byByZXNvbHZlIHRoaXMgImlzc3VlIiBpbiB0aGlzIHJlbGVhc2Ug b3IgdmlhIGFuIGFkZGl0aW9uYWwNCiBjYXBhYmlsaXR5IGxhdGVyIHRoYXQgZnVsbHkgc3VwcG9y dHMgaW50ZXJhY3RpdmUgbm90aWZpY2F0aW9uIHNlc3Npb25zPw0KDQotLSANClRpY2tldCBVUkw6 IDxodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMvdGlja2V0LzE0I2Nv bW1lbnQ6MT4NCk5ldGNvbmYgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3RyYWMv Pg0KSXNzdWUgdHJhY2tlciBmb3IgdGhlIE5FVENPTkYgV29ya2luZyBHcm91cA== -- to unsubscribe send a message to netconf-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 Aug 13 11:40: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 1IKc1V-0004MA-42 for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 11:40:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKc1T-0000Ms-Pv for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 11:40:05 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKbuo-0009B3-IW for netconf-data@psg.com; Mon, 13 Aug 2007 15:33:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [66.196.96.92] (helo=smtp119.sbc.mail.re3.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKbud-00099J-Lr for netconf@ops.ietf.org; Mon, 13 Aug 2007 15:33:05 +0000 Received: (qmail 68652 invoked from network); 13 Aug 2007 15:32:55 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp119.sbc.mail.re3.yahoo.com with SMTP; 13 Aug 2007 15:32:55 -0000 X-YMail-OSG: 1kO4lz8VM1n.GuK_gjHyDBngokXa95ndHyaohCKFgrkMDowwdV9Fsq5dzro09si0ZyRMbWtAoGIDyQEAmDtCaC5v_ptXy_Bsy3WIbrbV4Iq9XIFzeH4VKg-- Message-ID: <46C0794C.2080406@andybierman.com> Date: Mon, 13 Aug 2007 08:31:24 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: [Netconf] #14: notification termination mechanism considered dangerous References: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> <079.9d29ea151eb87f7d842e8caf6d416e66@tools.ietf.org> In-Reply-To: <079.9d29ea151eb87f7d842e8caf6d416e66@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: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Netconf wrote: > #14: notification termination mechanism considered dangerous > ----------------------------------------------+----------------------------- > Reporter: ietf@andybierman.com | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-ietf-netconf-notification | Version: > Resolution: | Keywords: notification-08 > ----------------------------------------------+----------------------------- > Comment (by schishol@nortel.com): > > This has been design intent ever since interactive notification sessions > were removed after the Montreal meeting. Why is this suddenly an issue? > > Do we expect to resolve this "issue" in this release or via an additional > capability later that fully supports interactive notification sessions? > I do not want to enter thread replies into the tracker. There is too much overhead in the messages. This is an issue because it cam up during a WGLC review. I am raising an objection to the design of the termination mechanism as defined. It is especially bad form for a WG that is supposed to know network management to design a protocol mechanism that generates alarms (drop TCP conn) or makes it easy to break the network (kill wrong session), on purpose -- with intent -- by design, even. IMO, a better design would be that agents MUST support RPC inter-leaving, at least for the operation. This greatly impacts the complexity of script-driven NETCONF client implementations, which connect to an agent, execute a bunch of NETCONF commands, and then use to finish up cleanly. This Notification design choice breaks all applications that assume they can establish a session, do work, then close the session. This is a rather common design assumption, and it keeps applications simple. 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 Aug 13 15:46: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 1IKfrZ-0005Wg-1N for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 15:46:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKfrX-00036n-Ec for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 15:46:05 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKfkm-000FnO-BF for netconf-data@psg.com; Mon, 13 Aug 2007 19:39:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IKfkb-000FkL-2R for netconf@ops.ietf.org; Mon, 13 Aug 2007 19:38:58 +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 l7DJcXV23903; Mon, 13 Aug 2007 19:38: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: [Netconf] #9: notification replay in the future Date: Mon, 13 Aug 2007 15:38:26 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4105613A8@zcarhxm2.corp.nortel.com> In-Reply-To: <46B0A795.7030802@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] #9: notification replay in the future Thread-Index: AcfUUmSWDjcYgy2ST86FPvP2O//H1wJjsMgg References: <070.ceadd83576df6ec0f0cbcbac7e722cfd@tools.ietf.org> <00ca01c7d2f3$03e3dfe0$0600a8c0@china.huawei.com> <46AE5FBC.3060704@andybierman.com> <46AEE888.5000405@ericsson.com> <46B09F61.6060005@andybierman.com> <46B0A0D9.6000307@ericsson.com> <46B0A795.7030802@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , "Balazs Lengyel" Cc: "David B Harrington" , , Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Hi Actually, the document as currently written supports replay in the future and requires no changes to continue to do so. (With the possible exception of the fact the name is inappropriate). A change is required to forbid start and stop times in the future. My big concern is that there seem to be a number of issues the working group is changing its mind on and I'm running out of editing chocolate. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, August 01, 2007 11:33 AM To: Balazs Lengyel Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org Subject: Re: [Netconf] #9: notification replay in the future Balazs Lengyel wrote: > Hello Andy, > My mail was about replay in the future not interleaving. There I vote=20 > for "the client MUST NOT" support replay in the future. > And yes interleaving is complicated. IMO, there is WG consensus that startTime in the future MUST be an error. The alternative is to rewrite major portions of the document to support a 'cron' like feature, added at the last minute. The current replay feature needs to be as simple as possible so it will be more inter-operable. There needs to be complete and precise definitions of as much behavior as we can anticipate. > Balazs Andy >=20 > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello, >>> I vote for MUST NOT. Why complicate things. Will it bring us anything? >>> >> >> Things are complicated either way. >> First, what are the choices? >> >> 1) require interleaving MUST be supported by the agent >> 2) allow interleaving to be supported by the agent, >> but just warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 3) allow interleaving to be supported by the agent, >> based on the '#interleave' capability, >> and also warn that the manager SHOULD NOT interleave >> and the agent MAY NOT accept interleaved requests. >> 4) require interleaving MUST NOT be supported by the agent >> - what happens when the manager sends an anyway? >> a) close session >> b) ignore request >> c) send operation-failed response >> >> What are the benefits? >> >> There obvious benefit from allowing interleaving, if you believe=20 >> sessions are expensive -- it saves an extra session on both the=20 >> manager and the agent. >> >> The real benefit is that is a the cleanest way to=20 >> terminate sessions, and it should be used in all modes. >> The and drop connection methods are both bad ideas. >> >> It would also be a HUGE CLR to forbid interleaving completely. >> In the future, some new feature will come up that will make it clear=20 >> the agent should never be in a mode it MUST stop listening to all=20 >> input from the client. It will be clear then (if not now) that this=20 >> is a really bad idea. >> >> So what are the benefits of forbidding interleaving completely, and=20 >> what happens if the manager sends an anyway? >> >> >>> I submitted the same comment as Dave in trac, but it seems that=20 >>> there is no email about updates to trac issues. >>> >>> Balazs >>> >> >> Andy >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 13 16:09: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 1IKgDp-0001ah-0W for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 16:09:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKgDn-0003u3-9b for netconf-archive@lists.ietf.org; Mon, 13 Aug 2007 16:09:04 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKg8Z-000Iuk-J9 for netconf-data@psg.com; Mon, 13 Aug 2007 20:03:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IKg8N-000Itb-Bg for netconf@ops.ietf.org; Mon, 13 Aug 2007 20:03:33 +0000 Received: (qmail 1969 invoked from network); 13 Aug 2007 20:02:15 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2007 20:02:15 -0000 X-YMail-OSG: VYhNX6oVM1kDjRIjtWdDLsnlgvGVcKQj4FSHNx2t5DbzlztzgLEW6luP34w1UvsxG53DYvigsqSoz6t7w7XLjoAB Message-ID: <46C0B86B.2060902@andybierman.com> Date: Mon, 13 Aug 2007 13:00:43 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Sharon Chisholm CC: Balazs Lengyel , 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> <46AEE888.5000405@ericsson.com> <46B09F61.6060005@andybierman.com> <46B0A0D9.6000307@ericsson.com> <46B0A795.7030802@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4105613A8@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4105613A8@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: b132cb3ed2d4be2017585bf6859e1ede Sharon Chisholm wrote: > Hi > > Actually, the document as currently written supports replay in the > future and requires no changes to continue to do so. (With the possible > exception of the fact the name is inappropriate). A change is required > to forbid start and stop times in the future. > I will have to look at -09 when it comes out, but -08 has details unspecified which raised interoperability concerns. > My big concern is that there seem to be a number of issues the working > group is changing its mind on and I'm running out of editing chocolate. We have not even started the AD review, IESG review, and IETF Last Call yet. Standards consensus is a fluid process. As more details are understood, and and more clarifications needed, sometimes facts come to light which made previously agreed-upon compromises unworkable, or previously discarded compromises relevant again. > > Sharon Andy > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Wednesday, August 01, 2007 11:33 AM > To: Balazs Lengyel > Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org > Subject: Re: [Netconf] #9: notification replay in the future > > Balazs Lengyel wrote: >> Hello Andy, >> My mail was about replay in the future not interleaving. There I vote >> for "the client MUST NOT" support replay in the future. >> And yes interleaving is complicated. > > IMO, there is WG consensus that startTime in the future MUST be an > error. The alternative is to rewrite major portions of the document to > support a 'cron' like feature, added at the last minute. > > The current replay feature needs to be as simple as possible so it will > be more inter-operable. There needs to be complete and precise > definitions of as much behavior as we can anticipate. > >> Balazs > > Andy > >> Andy Bierman wrote: >>> Balazs Lengyel wrote: >>>> Hello, >>>> I vote for MUST NOT. Why complicate things. Will it bring us > anything? >>> Things are complicated either way. >>> First, what are the choices? >>> >>> 1) require interleaving MUST be supported by the agent >>> 2) allow interleaving to be supported by the agent, >>> but just warn that the manager SHOULD NOT interleave >>> and the agent MAY NOT accept interleaved requests. >>> 3) allow interleaving to be supported by the agent, >>> based on the '#interleave' capability, >>> and also warn that the manager SHOULD NOT interleave >>> and the agent MAY NOT accept interleaved requests. >>> 4) require interleaving MUST NOT be supported by the agent >>> - what happens when the manager sends an anyway? >>> a) close session >>> b) ignore request >>> c) send operation-failed response >>> >>> What are the benefits? >>> >>> There obvious benefit from allowing interleaving, if you believe >>> sessions are expensive -- it saves an extra session on both the >>> manager and the agent. >>> >>> The real benefit is that is a the cleanest way to >>> terminate sessions, and it should be used in all modes. >>> The and drop connection methods are both bad ideas. >>> >>> It would also be a HUGE CLR to forbid interleaving completely. >>> In the future, some new feature will come up that will make it clear >>> the agent should never be in a mode it MUST stop listening to all >>> input from the client. It will be clear then (if not now) that this >>> is a really bad idea. >>> >>> So what are the benefits of forbidding interleaving completely, and >>> what happens if the manager sends an anyway? >>> >>> >>>> I submitted the same comment as Dave in trac, but it seems that >>>> there is no email about updates to trac issues. >>>> >>>> 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: > > -- > to 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 Aug 14 07:37: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 1IKuiK-0005oa-Q3 for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 07:37:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKuiJ-00066F-Ea for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 07:37:32 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKuXx-0003Hw-Ca for netconf-data@psg.com; Tue, 14 Aug 2007 11:26:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IKuXu-0003HU-P3 for netconf@ops.ietf.org; Tue, 14 Aug 2007 11:26:48 +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 l7EBQgJ25115 for ; Tue, 14 Aug 2007 11:26:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: [Netconf] #16: notification replay stopTime synch problem Date: Tue, 14 Aug 2007 07:26:26 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B410561700@zcarhxm2.corp.nortel.com> In-Reply-To: <070.c729ac2300cd71183ad674d0d5cfeda1@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] #16: notification replay stopTime synch problem Thread-Index: AcfUaIasFsiJS98lTqCUEUsGPV5pqAJ/Ng0Q References: <070.c729ac2300cd71183ad674d0d5cfeda1@tools.ietf.org> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 SGkNCg0KSSBkb24ndCB0aGluayB0aGlzIGlzIG5lY2Vzc2FyeS4gWWVzLCB0aGUgdGltZXMgYXJl IG5vdCBzeW5jaGVkLCBidXQgSSBkb24ndCB0aGluayB0aGUgZGlmZmVyZW5jZSB3YXJyYW50cyBj cmVhdGluZyB0aGlzIG5ldyB0eXBlLiBJZiB0aGUgb3BlcmF0b3IvbWFuYWdlciBpcyB3b3JyaWVk LCB0aGV5IGNhbiBhbHdheXMganVzdCBhZGQgYSBjb3VwbGUgc2Vjb25kcyB0byB0aGVpciB0aW1l IHRvIGNyZWF0ZSB0aGUgc3RvcCB0aW1lLiBNYW5hZ2VycyBrbm93IGhvdyB0byBkZS1kdXBsaWNh dGUuDQoNClNoYXJvbiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG93bmVy LW5ldGNvbmZAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItbmV0Y29uZkBvcHMuaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBOZXRjb25mDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwMSwgMjAwNyAy OjEzIFBNDQpDYzogbmV0Y29uZkBvcHMuaWV0Zi5vcmcNClN1YmplY3Q6IFtOZXRjb25mXSAjMTY6 IG5vdGlmaWNhdGlvbiByZXBsYXkgc3RvcFRpbWUgc3luY2ggcHJvYmxlbQ0KDQojMTY6IG5vdGlm aWNhdGlvbiByZXBsYXkgc3RvcFRpbWUgc3luY2ggcHJvYmxlbQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KIFJlcG9y dGVyOiAgaWV0ZkBhbmR5Ymllcm1hbi5jb20gICAgICAgICAgICAgfCAgICAgICBPd25lcjogICAg IA0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgIE1pbGVzdG9uZTogICAgIA0KQ29tcG9uZW50OiAgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlm aWNhdGlvbiAgfCAgICAgVmVyc2lvbjogICAgIA0KIEtleXdvcmRzOiAgbm90aWZpY2F0aW9uLTA4 ICAgICAgICAgICAgICAgICAgfCAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tDQogSGksDQogVGhpcyB3YXMgcmFpc2Vk IG9mZmxpbmUgYnkgUmFuZHkgUHJlc3Vobi4NCiBUaGUgbWFuYWdlciBtdXN0IHByb3ZpZGUgYSBz dG9wVGltZSBpZg0KIGl0IHdhbnRzIHRvIGdldCB0aGUgbG9nZ2VkIG5vdGlmaWNhdGlvbnMgIGFu ZCB0aGVuIHJldmVydCB0aGUgc2Vzc2lvbiB0byBub3JtYWwgbW9kZS4NCg0KIEhvd2V2ZXIsIGl0 IGlzIGRpZmZpY3VsdCBmb3IgdGhlIG1hbmFnZXIgYW5kICB0aGUgYWdlbnQgdG8gYmUgaW4gcGVy ZmVjdCB0aW1lIHN5bmNoLCBhbmQgIHRoZSB2YWx1ZSBmb3IgJ25vdycgaXMgbGlrZWx5IHRvIGJl IGRpZmZlcmVudCAgb24gYm90aCBzeXN0ZW1zLg0KDQogQSBzcGVjaWFsIHZhbHVlIGZvciB0aGUg c3RvcFRpbWUgcGFyYW1ldGVyIGlzIG5lZWRlZCwgICh0aGUgc3RyaW5nICdub3cnKSB0byBpbmRp Y2F0ZSB0byB0aGUgYWdlbnQgdGhhdCAgdGhlIGFnZW50IHNob3VsZCBkZXJpdmUgdGhlIGFjdHVh bCBzdG9wVGltZSB2YWx1ZSAgZnJvbSB0aGUgaXRzIGN1cnJlbnQgc3lzdGVtIHRpbWUuDQoNCiBU aGlzIGltcGFjdHMgdGhlIFhTRC4NCiBJbnN0ZWFkIG9mIHRoZSAneHM6ZGF0ZVRpbWUnIGRhdGEg dHlwZSwgdGhlICBzdG9wVGltZSBlbGVtZW50IHdpbGwgbmVlZCBhIG5ldyBkYXRhIHR5cGUgIHdo aWNoIGlzIGEgdW5pb24gb2YgdGhlIGZpeGVkIHN0cmluZyAnbm93JyBhbmQgYSBkYXRlVGltZSBz dHJpbmcuDQoNCi0tDQpUaWNrZXQgVVJMOiA8aHR0cDovL3d3dzMudG9vbHMuaWV0Zi5vcmcvd2cv bmV0Y29uZi90cmFjL3RpY2tldC8xNj4NCk5ldGNvbmYgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93 Zy9uZXRjb25mL3RyYWMvPg0KSXNzdWUgdHJhY2tlciBmb3IgdGhlIE5FVENPTkYgV29ya2luZyBH cm91cHJ6x6d1xqB6J3oo3qrnrLZsXzBtKNuncnop2rIpYuasthd6Gl53JnIYehttyJ4rYj9cdw0K -- to unsubscribe send a message to netconf-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 Aug 14 07:38: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 1IKuj6-0005ze-Bx for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 07:38:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKuj5-00067y-4W for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 07:38:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKudT-0003qr-9u for netconf-data@psg.com; Tue, 14 Aug 2007 11:32:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKudN-0003qH-8H for netconf@ops.ietf.org; Tue, 14 Aug 2007 11:32:26 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7EBUNr12125 for ; Tue, 14 Aug 2007 11:30:23 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: [Netconf] #14: notification termination mechanism considered dangerous Date: Tue, 14 Aug 2007 07:32:21 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B410561706@zcarhxm2.corp.nortel.com> In-Reply-To: <46B0CEA4.7090007@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] #14: notification termination mechanism considered dangerous Thread-Index: AcfUabtIXVrgArMxRJGs/UW4GH0dTAJ/JNBA References: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> <023601c7d45c$a393ca40$0601a8c0@pc6> <46B0CEA4.7090007@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 =20 One really valid option, raised by Phil, is to just close the session normally (as if the was followed by a ) after replay w/stopTime is complete. Problem solved. The agent never 'sees' any new because the is implicitly ahead of it in the queue. That's an unexpected side-effect and not terribly pretty. I think the current behaviour of just not reading the requests until stopTime makes the most sense. Sharon=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 Aug 14 09:44: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 1IKwgi-0004v3-EW for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 09:44:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKwgh-0001lR-7Y for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 09:44:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKwY8-000GKH-Id for netconf-data@psg.com; Tue, 14 Aug 2007 13:35:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IKwY5-000GJk-RP for netconf@ops.ietf.org; Tue, 14 Aug 2007 13:35:07 +0000 Received: (qmail 36377 invoked from network); 14 Aug 2007 13:35:05 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2007 13:35:05 -0000 X-YMail-OSG: AeHz2msVM1nrTnSOwoYOkK3qPwQQ2kGk59d5loZMrQXNoWdPhsrmfffDlmE91XfThFTipkaI7g-- Message-ID: <46C1AF2F.3000403@andybierman.com> Date: Tue, 14 Aug 2007 06:33:35 -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: [Netconf] #14: notification termination mechanism considered dangerous References: <070.2c5e6ef4a1cf7d55c2d58b7280722168@tools.ietf.org> <023601c7d45c$a393ca40$0601a8c0@pc6> <46B0CEA4.7090007@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B410561706@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B410561706@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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Sharon Chisholm wrote: > > > > > One really valid option, raised by Phil, is to just close the session > normally (as if the was followed by a > ) after replay w/stopTime is complete. Problem solved. > The agent never 'sees' any new because the is > implicitly ahead of it in the queue. > > > > That's an unexpected side-effect and not terribly pretty. I think the > current behaviour of just not reading the requests until stopTime makes > the most sense. > The real issue is the interpretation of the filter which is specified by startTime and stopTime. I think there is WG consensus that this filter only applies to logged entries, not notifications in the future that have not happened yet. Are you challenging this WG consensus? Whether the notifications are stored with sequence IDs or timestanps makes no difference. If there are notifications numbered 4, 5, and 6 in the replay log, and I ask "Give me all the stored notifications from 1 to 10", this still just returned 4, 5, and 6, sends replayComplete, and is done. It doesn't mean "Send 4, 5, 6, and wait (maybe forever) until notifications 7 - 10 are generated." So stopTime in the future is not an error -- it is just the upper bound on the set of stored notifications. > Sharon Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Aug 14 11:37: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 1IKyS4-0004QQ-CU for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 11:37:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKyS3-0004yN-4g for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 11:37:00 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKyJE-0002Uz-Dz for netconf-data@psg.com; Tue, 14 Aug 2007 15:27:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKyJ8-0002UG-Ct for netconf@ops.ietf.org; Tue, 14 Aug 2007 15:27:51 +0000 Received: from pc6 (1Cust211.tnt1.lnd4.gbr.da.uu.net [62.188.130.211]) by ranger.systems.pipex.net (Postfix) with SMTP id 28122E0003C4; Tue, 14 Aug 2007 16:27:43 +0100 (BST) Message-ID: <021601c7de7e$7d54bf20$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Sharon Chisholm" , "Netconf (E-mail)" References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> Subject: Re: Pre-release 2 of Notification Update Date: Tue, 14 Aug 2007 16:13:03 +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: -100.0 (---------------------------------------------------) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Sharon I raised the question of whether a filter would be applied to the event as it would appear on the wire, or as it might appear in the datastore (thinking of XPath roots and namespaces). Andy reported back, after a hallway BoF with Martin '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..' I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 "Conceptually, the filter is applied to the event notification as it would appear on the wire and not to it as it might appear in the conceptual NETCONF database." Tom Petch ----- Original Message ----- From: "Sharon Chisholm" To: "Netconf (E-mail)" Sent: Wednesday, August 08, 2007 9:24 PM Subject: Pre-release 2 of Notification Update Hi I'm almost done the update (hopefully). Attached is a pre-release. Please let me know if anything was incorrectly executed. <> Disclaimers: 1. I have not validated much of the schema or examples 2. I got a bit confused in the updates to section 5.2. These may still have issues. 3. I have not done anything about replays in the future. The text remains unchanged in this area. 4. I need to double check that I have not missed updates. 5. There were a few changes (mainly editorial) that I did not make for specific reasons which I need to send an email to discuss. 6. Not sure if using correct namespace in section 2.1.1.1. Andy said what was there was wrong, but it validates for me and there was no suggestions. I tried something else, but it didn't validate. 7. There was a request to add description of how to define notification instances, which has not been added, but there are now two examples (one in replayComplete and one in the examples in section 5). Is this sufficient? 8. I have not validate that I am always using the correct The URI string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) Sharon Chisholm Nortel 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 Aug 14 12:03: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 1IKyrj-0006nn-GL for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 12:03:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKyri-0006X0-6Y for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 12:03:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IKykk-0005mw-Ox for netconf-data@psg.com; Tue, 14 Aug 2007 15:56:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IKykh-0005mc-M5 for netconf@ops.ietf.org; Tue, 14 Aug 2007 15:56:17 +0000 Received: (qmail 75358 invoked from network); 14 Aug 2007 15:56:11 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 14 Aug 2007 15:56:11 -0000 X-YMail-OSG: MGCdxKgVM1kaDyNfOty2kmuXXAKubTsBgr36uylJ0M6DeJVpAdqPDBlw8H1Fd_k8as3cx9Gi76olZ18uKgTjDKWk Message-ID: <46C1D041.5090706@andybierman.com> Date: Tue, 14 Aug 2007 08:54:41 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" CC: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Pre-release 2 of Notification Update References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> In-Reply-To: <021601c7de7e$7d54bf20$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: a8a20a483a84f747e56475e290ee868e tom.petch wrote: > Sharon > > I raised the question of whether a filter would be applied to the event as it > would appear on the wire, or as it might appear in the datastore (thinking of > XPath roots and namespaces). Andy reported back, after a hallway BoF with > Martin > > '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..' > > I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 > "Conceptually, the filter is applied to the event notification as it would > appear on the wire and not to it as it might appear in the conceptual NETCONF > database." Good catch. This needs more detail I think. Given a conceptual notification message: fault major ws1/hd0 Do you want to force the string "/notification" to appear over and over in every filter, or start the filter at instead, and save 13 chars in almost every term in the expression? Is the element constrained to contain exactly one child element? (I think so.) Then this section should specify that the element in the is applied to the one and only child element of the top-level element. Andy > > Tom Petch > > ----- Original Message ----- > From: "Sharon Chisholm" > To: "Netconf (E-mail)" > Sent: Wednesday, August 08, 2007 9:24 PM > Subject: Pre-release 2 of Notification Update > > > Hi > > I'm almost done the update (hopefully). Attached is a pre-release. > Please let me know if anything was incorrectly executed. > <> > > Disclaimers: > > 1. I have not validated much of the schema or examples > 2. I got a bit confused in the updates to section 5.2. These may still > have issues. > 3. I have not done anything about replays in the future. The text > remains unchanged in this area. > 4. I need to double check that I have not missed updates. > 5. There were a few changes (mainly editorial) that I did not make for > specific reasons which I need to send an email to discuss. > 6. Not sure if using correct namespace in section 2.1.1.1. Andy said > what was there was wrong, but it validates for me and there was no > suggestions. I tried something else, but it didn't validate. > 7. There was a request to add description of how to define notification > instances, which has not been added, but there are now two examples (one > in replayComplete and one in the examples in section 5). Is this > sufficient? > 8. I have not validate that I am always using the correct The URI > string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) > > Sharon Chisholm > Nortel > 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: > > -- to unsubscribe send a message to netconf-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 Aug 14 15:41:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL2Gy-0007wZ-OF for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 15:41:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL2Gx-0004WA-8i for netconf-archive@lists.ietf.org; Tue, 14 Aug 2007 15:41:48 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IL292-00037k-I8 for netconf-data@psg.com; Tue, 14 Aug 2007 19:33:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IL28z-000362-KQ for netconf@ops.ietf.org; Tue, 14 Aug 2007 19:33:35 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 61C371B80C3; Tue, 14 Aug 2007 21:33:31 +0200 (CEST) Date: Tue, 14 Aug 2007 21:33:36 +0200 (CEST) Message-Id: <20070814.213336.188051818.mbj@tail-f.com> To: ietf@andybierman.com Cc: cfinss@dial.pipex.com, schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Pre-release 2 of Notification Update From: Martin Bjorklund In-Reply-To: <46C1D041.5090706@andybierman.com> References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@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: 69a74e02bbee44ab4f8eafdbcedd94a1 Andy Bierman wrote: > tom.petch wrote: > > Sharon > > > > I raised the question of whether a filter would be applied to the event as it > > would appear on the wire, or as it might appear in the datastore (thinking of > > XPath roots and namespaces). Andy reported back, after a hallway BoF with > > Martin > > > > '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..' > > > > I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 > > "Conceptually, the filter is applied to the event notification as it would > > appear on the wire and not to it as it might appear in the conceptual NETCONF > > database." I suggested earlier that we should say that that the filter is applied with the 'notificationContent' element as root (which is the abstract element). I don't think it's a good idea to add text about the conceptual NETCONF database here - it has nothing to do with the notifications. > Is the element constrained to contain > exactly one child element? (I think so.) Yes, it is in the XSD in draft -09. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 15 04:53: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 1ILEdA-0004jC-0h for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 04:53:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILEd8-0006VF-Ff for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 04:53:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILEVn-0001qJ-32 for netconf-data@psg.com; Wed, 15 Aug 2007 08:45:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILEVj-0001jP-WE for netconf@ops.ietf.org; Wed, 15 Aug 2007 08:45:53 +0000 Received: from pc6 (1Cust58.tnt102.lnd4.gbr.da.uu.net [213.116.52.58]) by ranger.systems.pipex.net (Postfix) with SMTP id 2DF33E0005E6; Wed, 15 Aug 2007 09:22:06 +0100 (BST) Message-ID: <000201c7df0c$370dc780$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" Cc: "Sharon Chisholm" , "Netconf (E-mail)" References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> Subject: Re: Pre-release 2 of Notification Update Date: Tue, 14 Aug 2007 21:27:59 +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: -98.2 (---------------------------------------------------) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 ----- Original Message ----- From: "Andy Bierman" To: "tom.petch" Cc: "Sharon Chisholm" ; "Netconf (E-mail)" Sent: Tuesday, August 14, 2007 5:54 PM Subject: Re: Pre-release 2 of Notification Update > tom.petch wrote: > > Sharon > > > > I raised the question of whether a filter would be applied to the event as it > > would appear on the wire, or as it might appear in the datastore (thinking of > > XPath roots and namespaces). Andy reported back, after a hallway BoF with > > Martin > > > > '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..' > > > > I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 > > "Conceptually, the filter is applied to the event notification as it would > > appear on the wire and not to it as it might appear in the conceptual NETCONF > > database." > > > Good catch. > This needs more detail I think. > Given a conceptual notification message: > > > > fault > major > ws1/hd0 > > > > Do you want to force the string "/notification" to appear > over and over in every filter, or start the filter at > instead, and save 13 chars in almost every term in the expression? > > Is the element constrained to contain > exactly one child element? (I think so.) > > Then this section should specify that the element > in the is applied to the one and only > child element of the top-level element. > My logic is slightly different, that XPath filtering is defined for well-formed XML documents and well-formed documents can only be relied on on the wire, eg in having a single root. If that means that an extra 13 characters appear in each filter, well ... if we were concerned about 13 characters, would we be using XML? (XPath does allow for short cuts so the additional element names would not be in every filter). Tom Petch > > Andy > > > > > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Sharon Chisholm" > > To: "Netconf (E-mail)" > > Sent: Wednesday, August 08, 2007 9:24 PM > > Subject: Pre-release 2 of Notification Update > > > > > > Hi > > > > I'm almost done the update (hopefully). Attached is a pre-release. > > Please let me know if anything was incorrectly executed. > > <> > > > > Disclaimers: > > > > 1. I have not validated much of the schema or examples > > 2. I got a bit confused in the updates to section 5.2. These may still > > have issues. > > 3. I have not done anything about replays in the future. The text > > remains unchanged in this area. > > 4. I need to double check that I have not missed updates. > > 5. There were a few changes (mainly editorial) that I did not make for > > specific reasons which I need to send an email to discuss. > > 6. Not sure if using correct namespace in section 2.1.1.1. Andy said > > what was there was wrong, but it validates for me and there was no > > suggestions. I tried something else, but it didn't validate. > > 7. There was a request to add description of how to define notification > > instances, which has not been added, but there are now two examples (one > > in replayComplete and one in the examples in section 5). Is this > > sufficient? > > 8. I have not validate that I am always using the correct The URI > > string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) > > > > Sharon Chisholm > > Nortel > > 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: > > > > > > > -- > to 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 Aug 15 06:27:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILG67-0000Pp-05 for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 06:27:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILG65-0000pf-IC for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 06:27:30 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILG0V-000CbX-Ge for netconf-data@psg.com; Wed, 15 Aug 2007 10:21:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILG0S-000CbC-4M for netconf@ops.ietf.org; Wed, 15 Aug 2007 10:21:41 +0000 Received: (qmail 55792 invoked from network); 15 Aug 2007 10:21:39 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 15 Aug 2007 10:21:38 -0000 X-YMail-OSG: bNEMOMwVM1lL1b3A8oH0SV9eDsq_g7osyAvXLOoVRcTsp8Ug6C.xvw2x9dTLXU69m7vsi6W7tzrFH7173KrdEsFBeQ-- Message-ID: <46C2D354.8070803@andybierman.com> Date: Wed, 15 Aug 2007 03:20:04 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" CC: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Pre-release 2 of Notification Update References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> <000201c7df0c$370dc780$0601a8c0@pc6> In-Reply-To: <000201c7df0c$370dc780$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: 2ed806e2f53ff1a061ad4f97e00345ac tom.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "tom.petch" > Cc: "Sharon Chisholm" ; "Netconf (E-mail)" > > Sent: Tuesday, August 14, 2007 5:54 PM > Subject: Re: Pre-release 2 of Notification Update > > >> tom.petch wrote: >>> Sharon >>> >>> I raised the question of whether a filter would be applied to the event as > it >>> would appear on the wire, or as it might appear in the datastore (thinking > of >>> XPath roots and namespaces). Andy reported back, after a hallway BoF with >>> Martin >>> >>> '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..' >>> >>> I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 >>> "Conceptually, the filter is applied to the event notification as it would >>> appear on the wire and not to it as it might appear in the conceptual > NETCONF >>> database." >> >> Good catch. >> This needs more detail I think. >> Given a conceptual notification message: >> >> >> >> fault >> major >> ws1/hd0 >> >> >> >> Do you want to force the string "/notification" to appear >> over and over in every filter, or start the filter at >> instead, and save 13 chars in almost every term in the expression? >> >> Is the element constrained to contain >> exactly one child element? (I think so.) >> >> Then this section should specify that the element >> in the is applied to the one and only >> child element of the top-level element. >> > My logic is slightly different, that XPath filtering is defined for well-formed > XML documents and well-formed documents can only be relied on on the wire, eg in > having a single root. If that means that an extra 13 characters appear in each > filter, well ... if we were concerned about 13 characters, would we be using > XML? (XPath does allow for short cuts so the additional element names would not > be in every filter). > Then why don't you have this concern about filters for ? These filters do not start with /rpc/get-config/filter/foo, they just start with /foo. I think Martin's suggestion of pointing at the abstract notificationContent element is fine. > Tom Petch Andy > > >> Andy >> >> >> >> >> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Sharon Chisholm" >>> To: "Netconf (E-mail)" >>> Sent: Wednesday, August 08, 2007 9:24 PM >>> Subject: Pre-release 2 of Notification Update >>> >>> >>> Hi >>> >>> I'm almost done the update (hopefully). Attached is a pre-release. >>> Please let me know if anything was incorrectly executed. >>> <> >>> >>> Disclaimers: >>> >>> 1. I have not validated much of the schema or examples >>> 2. I got a bit confused in the updates to section 5.2. These may still >>> have issues. >>> 3. I have not done anything about replays in the future. The text >>> remains unchanged in this area. >>> 4. I need to double check that I have not missed updates. >>> 5. There were a few changes (mainly editorial) that I did not make for >>> specific reasons which I need to send an email to discuss. >>> 6. Not sure if using correct namespace in section 2.1.1.1. Andy said >>> what was there was wrong, but it validates for me and there was no >>> suggestions. I tried something else, but it didn't validate. >>> 7. There was a request to add description of how to define notification >>> instances, which has not been added, but there are now two examples (one >>> in replayComplete and one in the examples in section 5). Is this >>> sufficient? >>> 8. I have not validate that I am always using the correct The URI >>> string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) >>> >>> Sharon Chisholm >>> Nortel >>> 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: >>> >>> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 15 10:30: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 1ILJsp-0002tR-4v for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 10:30:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILJsn-0006hh-Nb for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 10:30:03 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILJkb-000Euh-JR for netconf-data@psg.com; Wed, 15 Aug 2007 14:21:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILJkY-000Eu7-4t for netconf@ops.ietf.org; Wed, 15 Aug 2007 14:21:31 +0000 Received: from pc6 (1Cust175.tnt1.lnd4.gbr.da.uu.net [62.188.130.175]) by ranger.systems.pipex.net (Postfix) with SMTP id 11405E00038F; Wed, 15 Aug 2007 15:21:19 +0100 (BST) Message-ID: <02db01c7df3e$649e2280$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" Cc: "Sharon Chisholm" , "Netconf (E-mail)" References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> <000201c7df0c$370dc780$0601a8c0@pc6> <46C2D354.8070803@andybierman.com> Subject: Re: Pre-release 2 of Notification Update Date: Wed, 15 Aug 2007 15:14:29 +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: -100.0 (---------------------------------------------------) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 ----- Original Message ----- From: "Andy Bierman" To: "tom.petch" Cc: "Sharon Chisholm" ; "Netconf (E-mail)" Sent: Wednesday, August 15, 2007 12:20 PM Subject: Re: Pre-release 2 of Notification Update > tom.petch wrote: > > ----- Original Message ----- > > From: "Andy Bierman" > > To: "tom.petch" > > Cc: "Sharon Chisholm" ; "Netconf (E-mail)" > > > > Sent: Tuesday, August 14, 2007 5:54 PM > > Subject: Re: Pre-release 2 of Notification Update > > > >> tom.petch wrote: > >>> Sharon > >>> > >>> I raised the question of whether a filter would be applied to the event as > > it > >>> would appear on the wire, or as it might appear in the datastore (thinking > > of > >>> XPath roots and namespaces). Andy reported back, after a hallway BoF with > >>> Martin > >>> > >>> '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..' > >>> > >>> I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 > >>> "Conceptually, the filter is applied to the event notification as it would > >>> appear on the wire and not to it as it might appear in the conceptual > > NETCONF > >>> database." > >> > >> Good catch. > >> This needs more detail I think. > >> Given a conceptual notification message: > >> > >> > >> > >> fault > >> major > >> ws1/hd0 > >> > >> > >> > >> Do you want to force the string "/notification" to appear > >> over and over in every filter, or start the filter at > >> instead, and save 13 chars in almost every term in the expression? > >> > >> Is the element constrained to contain > >> exactly one child element? (I think so.) > >> > >> Then this section should specify that the element > >> in the is applied to the one and only > >> child element of the top-level element. > >> > > My logic is slightly different, that XPath filtering is defined for well-formed > > XML documents and well-formed documents can only be relied on on the wire, eg in > > having a single root. If that means that an extra 13 characters appear in each > > filter, well ... if we were concerned about 13 characters, would we be using > > XML? (XPath does allow for short cuts so the additional element names would not > > be in every filter). > > > Then why don't you have this concern about filters for ? > Because the format of the datastore is undefined and may or may not look like an XML document, may or may not have a single root, so there are no existing rules for us to follow. The notification on the wire is defined, to be an XML document (ie with a single root element), and XPath has some rules (start at the root) so I think we need a good reason not to follow them. (If I reuse someone else's technology, then I prefer not to introduce my own proprietary tweak lest I be accused of behaving like ... - I have just been reading articles describing how some large players in the IT world do this to IETF RFC:-). > These filters do not start with /rpc/get-config/filter/foo, they > just start with /foo. I think Martin's suggestion of pointing > at the abstract notificationContent element is fine. > It's ok; I would prefer the root of the document on the wire but can be persuaded otherwise. I also take Martin's comment about omitting reference to the conceptual data store. Tom Petch > > Andy > > > > > > >> Andy > >> > >> > >> > >> > >> > >>> Tom Petch > >>> > >>> ----- Original Message ----- > >>> From: "Sharon Chisholm" > >>> To: "Netconf (E-mail)" > >>> Sent: Wednesday, August 08, 2007 9:24 PM > >>> Subject: Pre-release 2 of Notification Update > >>> > >>> > >>> Hi > >>> > >>> I'm almost done the update (hopefully). Attached is a pre-release. > >>> Please let me know if anything was incorrectly executed. > >>> <> > >>> > >>> Disclaimers: > >>> > >>> 1. I have not validated much of the schema or examples > >>> 2. I got a bit confused in the updates to section 5.2. These may still > >>> have issues. > >>> 3. I have not done anything about replays in the future. The text > >>> remains unchanged in this area. > >>> 4. I need to double check that I have not missed updates. > >>> 5. There were a few changes (mainly editorial) that I did not make for > >>> specific reasons which I need to send an email to discuss. > >>> 6. Not sure if using correct namespace in section 2.1.1.1. Andy said > >>> what was there was wrong, but it validates for me and there was no > >>> suggestions. I tried something else, but it didn't validate. > >>> 7. There was a request to add description of how to define notification > >>> instances, which has not been added, but there are now two examples (one > >>> in replayComplete and one in the examples in section 5). Is this > >>> sufficient? > >>> 8. I have not validate that I am always using the correct The URI > >>> string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) > >>> > >>> Sharon Chisholm > >>> Nortel > >>> 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: > >>> > >>> > >> > >> -- > >> to unsubscribe send a message to netconf-request@ops.ietf.org with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 15 12:51: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 1ILM63-0007Ht-HY for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 12:51:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILM62-0002jZ-6v for netconf-archive@lists.ietf.org; Wed, 15 Aug 2007 12:51:51 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILLyW-0006nc-40 for netconf-data@psg.com; Wed, 15 Aug 2007 16:44:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILLyS-0006nF-Hj for netconf@ops.ietf.org; Wed, 15 Aug 2007 16:44:02 +0000 Received: from pc6 (1Cust49.tnt108.lnd4.gbr.da.uu.net [62.188.170.49]) by ranger.systems.pipex.net (Postfix) with SMTP id 0B925E0006C2; Wed, 15 Aug 2007 17:43:44 +0100 (BST) Message-ID: <03d301c7df52$4d39e2a0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" Cc: "Sharon Chisholm" , "Netconf (E-mail)" , "Martin Bjorklund" References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> <000201c7df0c$370dc780$0601a8c0@pc6> <46C2D354.8070803@andybierman.com> Subject: Re: Pre-release 2 of Notification Update Date: Wed, 15 Aug 2007 15:50:41 +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: -100.0 (---------------------------------------------------) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff ----- Original Message ----- From: "Andy Bierman" To: "tom.petch" Cc: "Sharon Chisholm" ; "Netconf (E-mail)" Sent: Wednesday, August 15, 2007 12:20 PM Subject: Re: Pre-release 2 of Notification Update > tom.petch wrote: > > ----- Original Message ----- > > From: "Andy Bierman" > > To: "tom.petch" > > Cc: "Sharon Chisholm" ; "Netconf (E-mail)" > > > > Sent: Tuesday, August 14, 2007 5:54 PM > > Subject: Re: Pre-release 2 of Notification Update > > > >> tom.petch wrote: > >>> Sharon > >>> > >>> I raised the question of whether a filter would be applied to the event as > > it > >>> would appear on the wire, or as it might appear in the datastore (thinking > > of > >>> XPath roots and namespaces). Andy reported back, after a hallway BoF with > >>> Martin > >>> > >>> '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..' > >>> > >>> I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 > >>> "Conceptually, the filter is applied to the event notification as it would > >>> appear on the wire and not to it as it might appear in the conceptual > > NETCONF > >>> database." > >> > >> Good catch. > >> This needs more detail I think. > >> Given a conceptual notification message: > >> > >> > >> > >> fault > >> major > >> ws1/hd0 > >> > >> > >> > >> Do you want to force the string "/notification" to appear > >> over and over in every filter, or start the filter at > >> instead, and save 13 chars in almost every term in the expression? > >> > >> Is the element constrained to contain > >> exactly one child element? (I think so.) > >> > >> Then this section should specify that the element > >> in the is applied to the one and only > >> child element of the top-level element. > >> > > My logic is slightly different, that XPath filtering is defined for well-formed > > XML documents and well-formed documents can only be relied on on the wire, eg in > > having a single root. If that means that an extra 13 characters appear in each > > filter, well ... if we were concerned about 13 characters, would we be using > > XML? (XPath does allow for short cuts so the additional element names would not > > be in every filter). > > > Then why don't you have this concern about filters for ? > Because the format of the datastore is undefined and may or may not look like an XML document, may or may not have a single root, so there are no existing rules for us to follow. The notification on the wire is defined, to be an XML document (ie with a single root element), and XPath has some rules (start at the root) so I think we need a good reason not to follow them. (If I reuse someone else's technology, then I prefer not to introduce my own proprietary tweak lest I be accused of behaving like ... - I have just been reading articles describing how some large players in the IT world do this to IETF RFC:-). > These filters do not start with /rpc/get-config/filter/foo, they > just start with /foo. I think Martin's suggestion of pointing > at the abstract notificationContent element is fine. > It's ok; I would prefer the root of the document on the wire but can be persuaded otherwise. I also take Martin's comment about omitting reference to the conceptual data store. Tom Petch > > Andy > > > > > > >> Andy > >> > >> > >> > >> > >> > >>> Tom Petch > >>> > >>> ----- Original Message ----- > >>> From: "Sharon Chisholm" > >>> To: "Netconf (E-mail)" > >>> Sent: Wednesday, August 08, 2007 9:24 PM > >>> Subject: Pre-release 2 of Notification Update > >>> > >>> > >>> Hi > >>> > >>> I'm almost done the update (hopefully). Attached is a pre-release. > >>> Please let me know if anything was incorrectly executed. > >>> <> > >>> > >>> Disclaimers: > >>> > >>> 1. I have not validated much of the schema or examples > >>> 2. I got a bit confused in the updates to section 5.2. These may still > >>> have issues. > >>> 3. I have not done anything about replays in the future. The text > >>> remains unchanged in this area. > >>> 4. I need to double check that I have not missed updates. > >>> 5. There were a few changes (mainly editorial) that I did not make for > >>> specific reasons which I need to send an email to discuss. > >>> 6. Not sure if using correct namespace in section 2.1.1.1. Andy said > >>> what was there was wrong, but it validates for me and there was no > >>> suggestions. I tried something else, but it didn't validate. > >>> 7. There was a request to add description of how to define notification > >>> instances, which has not been added, but there are now two examples (one > >>> in replayComplete and one in the examples in section 5). Is this > >>> sufficient? > >>> 8. I have not validate that I am always using the correct The URI > >>> string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) > >>> > >>> Sharon Chisholm > >>> Nortel > >>> 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: > >>> > >>> > >> > >> -- > >> to unsubscribe send a message to netconf-request@ops.ietf.org with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 16 07:37: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 1ILdfL-0005NJ-U8 for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 07:37:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILdfK-0003v1-Iy for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 07:37:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILdXj-000DqS-7t for netconf-data@psg.com; Thu, 16 Aug 2007 11:29:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1ILdXg-000Dq4-8F for netconf@ops.ietf.org; Thu, 16 Aug 2007 11:29:33 +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 l7GBTRZ28765 for ; Thu, 16 Aug 2007 11:29:28 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 #9: replay in the future consensus point Date: Thu, 16 Aug 2007 07:27:56 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41060CAE9@zcarhxm2.corp.nortel.com> In-Reply-To: <46BA309D.2090807@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification #9: replay in the future consensus point Thread-Index: AcfaAaMyfcuWtj42TOSHhKcd7NUrfAF9oZmw References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > The 'eventClass', 'eventSeverity', and 'eventTime' fields are meta-data which could be encoded as XML attributes in the element. This should be required, even if the proprietary has some or all of these fields already. This is why I keep asking the WG: Are you SURE you want to forbid all XML attributes, forever, from being included in the element? Are you SURE this is not going to ever come up again as an issue, because this is the only place we can really put inter-operable meta-data into the notification message? I don't consider these meta-data and it is only meta-data that you are suppose to be using attributes for according to best practice I keep hearing. These should be elements so I don't think there is an issue. 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 Aug 16 07:41: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 1ILdjg-0000SV-2F for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 07:41:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILdje-000475-Rj for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 07:41:56 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILdeA-000EYG-KJ for netconf-data@psg.com; Thu, 16 Aug 2007 11:36:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1ILde8-000EY0-BJ for netconf@ops.ietf.org; Thu, 16 Aug 2007 11:36:13 +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 l7GBa9X13977 for ; Thu, 16 Aug 2007 11:36:09 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 #9: replay in the future consensus point Date: Thu, 16 Aug 2007 07:35:48 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41060CAF0@zcarhxm2.corp.nortel.com> In-Reply-To: <46BA6FFD.30004@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification #9: replay in the future consensus point Thread-Index: AcfaJ9OGckMCXDHQQQy/D+ejqDDJngF0S92A References: <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@andybierman.com> <20070808.232718.66373367.mbj@tail-f.com> <46BA6FFD.30004@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi I'm not sure if this is helpful, but the original design we did of replay, which I'm not sure was ever captured in any of the internet drafts, was that a subscription was only either a replay subscription or a real-time subscription. You got a replay by specifying startTime. There was no stopTime as this was implicitly "now" for a replay subscription (ie, the time the subscription was created). Not specifying startTime gave you notifications as they happened. This is simpler, but was also in a universe that supported interleaving and multiple subscriptions per session. 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 Aug 16 11:06:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgvs-0002Kw-IY for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 11:06:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILgvr-0000im-7A for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 11:06:44 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILgqo-000G5X-3v for netconf-data@psg.com; Thu, 16 Aug 2007 15:01:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1ILgqd-000G4P-Ev for netconf@ops.ietf.org; Thu, 16 Aug 2007 15:01:21 +0000 Received: (qmail 73808 invoked from network); 16 Aug 2007 15:01:18 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 16 Aug 2007 15:01:18 -0000 X-YMail-OSG: 5lRgoZkVM1nsnXAxt08l5Ox9pDLQYVhrq51B0Bq8lKX.z6gZ Message-ID: <46C4665E.6060102@andybierman.com> Date: Thu, 16 Aug 2007 07:59:42 -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: Notification #9: replay in the future consensus point References: <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@andybierman.com> <20070808.232718.66373367.mbj@tail-f.com> <46BA6FFD.30004@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41060CAF0@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41060CAF0@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: 2409bba43e9c8d580670fda8b695204a Sharon Chisholm wrote: > Hi > > I'm not sure if this is helpful, but the original design we did of > replay, which I'm not sure was ever captured in any of the internet > drafts, was that a subscription was only either a replay subscription or > a real-time subscription. You got a replay by specifying startTime. > There was no stopTime as this was implicitly "now" for a replay > subscription (ie, the time the subscription was created). Not specifying > startTime gave you notifications as they happened. This is simpler, but > was also in a universe that supported interleaving and multiple > subscriptions per session. If you leave out the stopTime, then the agent sends all the replayed notifications, followed by live notifications. If stopTime is present, the agent reverts to normal mode after the replayed notifications are sent. > > Sharon Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 16 11:06:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgvy-0002LA-KM for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 11:06:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILgvx-0000iu-D9 for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 11:06:50 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILgnA-000FkL-8g for netconf-data@psg.com; Thu, 16 Aug 2007 14:57:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1ILgn7-000Fk3-H7 for netconf@ops.ietf.org; Thu, 16 Aug 2007 14:57:43 +0000 Received: (qmail 2377 invoked from network); 16 Aug 2007 14:57:41 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 16 Aug 2007 14:57:40 -0000 X-YMail-OSG: 7yHj2JcVM1kXv.vqQFhFAgDJW8TcLr98zllvEoqTnawR7mDu Message-ID: <46C46585.2000000@andybierman.com> Date: Thu, 16 Aug 2007 07:56:05 -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: Notification #9: replay in the future consensus point References: <46B9E175.8020200@andybierman.com> <20070808.210806.33045977.mbj@tail-f.com> <46BA24E3.9000900@andybierman.com> <20070808.224106.192363477.mbj@tail-f.com> <46BA309D.2090807@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41060CAE9@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41060CAE9@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: 8b30eb7682a596edff707698f4a80f7d Sharon Chisholm wrote: > > > The 'eventClass', 'eventSeverity', and 'eventTime' fields are meta-data > which could be encoded as XML attributes in the element. > This should be required, even if the proprietary has some or > all of these fields already. > > This is why I keep asking the WG: > Are you SURE you want to forbid all XML attributes, forever, from being > included in the element? > > Are you SURE this is not going to ever come up again as an issue, > because this is the only place we can really put inter-operable > meta-data into the notification message? > > > I don't consider these meta-data and it is only meta-data that you are > suppose to be using attributes for according to best practice I keep > hearing. These should be elements so I don't think there is an issue. > That's fine. Leave the element such that nobody may ever place an XML attribute there. It can't be part of the filter anyway, which starts at the next layer. Note that there is no standard for 'eventClass', 'eventSeverity', or 'eventTime', and a vendor may choose to use XML attributes or elements for these fields (if they exist at all). > > Sharon Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 16 14:28: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 1ILk5K-0006U0-Ak for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 14:28:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILk5I-0008F1-Vo for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 14:28:42 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILjy3-000GKj-Ip for netconf-data@psg.com; Thu, 16 Aug 2007 18:21:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILjxx-000GJz-3M for netconf@ops.ietf.org; Thu, 16 Aug 2007 18:21:10 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 152291B80C3; Thu, 16 Aug 2007 20:21:01 +0200 (CEST) Date: Thu, 16 Aug 2007 20:21:10 +0200 (CEST) Message-Id: <20070816.202110.99185670.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point From: Martin Bjorklund In-Reply-To: <46C46585.2000000@andybierman.com> References: <46BA309D.2090807@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41060CAE9@zcarhxm2.corp.nortel.com> <46C46585.2000000@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: 7d33c50f3756db14428398e2bdedd581 Andy Bierman wrote: > Note that there is no standard for 'eventClass', 'eventSeverity', > or 'eventTime', and a vendor may choose to use XML attributes > or elements for these fields (if they exist at all). The entire replay feature relies on the presence of an eventTime (or similar). If the manager can't figure out when the notifications were generated, he cannot set startTime and stopTime to get missing notifications. IMO, it's a big mistake that this event time isn't standardized - it means that a manager, in order to use replay efficiently, has to know all datamodels of all notifications, and know where to find the non-standard event time in each one. /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 Aug 16 14:51: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 1ILkRQ-0007DQ-4U for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 14:51:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILkRO-0000DC-TG for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 14:51:32 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILkLc-000JIA-DX for netconf-data@psg.com; Thu, 16 Aug 2007 18:45:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1ILkLZ-000JHq-Iv for netconf@ops.ietf.org; Thu, 16 Aug 2007 18:45:31 +0000 Received: (qmail 98889 invoked from network); 16 Aug 2007 18:45:29 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 16 Aug 2007 18:45:28 -0000 X-YMail-OSG: Aezoe4QVM1koJD0d_uTfDekEMeib2FQ85fSbNvw2H6iksUO7 Message-ID: <46C49AE9.5000000@andybierman.com> Date: Thu, 16 Aug 2007 11:43:53 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point References: <46BA309D.2090807@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41060CAE9@zcarhxm2.corp.nortel.com> <46C46585.2000000@andybierman.com> <20070816.202110.99185670.mbj@tail-f.com> In-Reply-To: <20070816.202110.99185670.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: ea4ac80f790299f943f0a53be7e1a21a Martin Bjorklund wrote: > Andy Bierman wrote: >> Note that there is no standard for 'eventClass', 'eventSeverity', >> or 'eventTime', and a vendor may choose to use XML attributes >> or elements for these fields (if they exist at all). > > The entire replay feature relies on the presence of an eventTime (or > similar). If the manager can't figure out when the notifications were > generated, he cannot set startTime and stopTime to get missing > notifications. IMO, it's a big mistake that this event time isn't > standardized - it means that a manager, in order to use replay > efficiently, has to know all datamodels of all notifications, and know > where to find the non-standard event time in each one. I agree. It is a mistake to design the notification message assuming these critical standard fields will be retro-fitted in an inter-operable manner. > > > > /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 Aug 16 15:04: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 1ILke8-0006jP-B8 for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 15:04:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILke7-0000Wj-4J for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 15:04:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILkZ0-000Kz8-2J for netconf-data@psg.com; Thu, 16 Aug 2007 18:59:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILkYx-000Kye-FU for netconf@ops.ietf.org; Thu, 16 Aug 2007 18:59:20 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7GIvFh25795 for ; Thu, 16 Aug 2007 18:57:15 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: Pre-release 2 of Notification Update Date: Thu, 16 Aug 2007 14:58:51 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41060D3E3@zcarhxm2.corp.nortel.com> In-Reply-To: <46C1D041.5090706@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pre-release 2 of Notification Update Thread-Index: Acfei6bKrbCmoIQiQVqGhBfyjR88LQBqx4pw References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Given a conceptual notification message: fault major ws1/hd0 Do you want to force the string "/notification" to appear over and over in every filter, or start the filter at instead, and save 13 chars in almost every term in the expression? Historically, optimizations that make thing less intuitive to save a few bits on the wire are not worth it (not being able to varbind in table indices into SNMP notifications, for example.) I guess I had always thought the filter started at fooEvent because it was against the definition of the notification, not what was on the wire. What was the reasoning again to go with what is on the wire? 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 Aug 16 16:01: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 1ILlXO-0002gW-UO for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 16:01:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILlXN-00026S-Mv for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 16:01:46 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILlSz-0002np-0V for netconf-data@psg.com; Thu, 16 Aug 2007 19:57:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILlSw-0002nU-Gv for netconf@ops.ietf.org; Thu, 16 Aug 2007 19:57:11 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id A6AA51B80C3; Thu, 16 Aug 2007 21:57:09 +0200 (CEST) Date: Thu, 16 Aug 2007 21:57:19 +0200 (CEST) Message-Id: <20070816.215719.209154953.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: Pre-release 2 of Notification Update From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41060D3E3@zcarhxm2.corp.nortel.com> References: <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41060D3E3@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: bb8f917bb6b8da28fc948aeffb74aa17 "Sharon Chisholm" wrote: > > Given a conceptual notification message: > > > > fault > major > ws1/hd0 > > > > Do you want to force the string "/notification" to appear over and over > in every filter, or start the filter at instead, and save 13 > chars in almost every term in the expression? > > > Historically, optimizations that make thing less intuitive to save a few > bits on the wire are not worth it (not being able to varbind in table > indices into SNMP notifications, for example.) > > I guess I had always thought the filter started at fooEvent because it > was against the definition of the notification, not what was on the > wire. What was the reasoning again to go with what is on the wire? I think everyone agrees (or can live with) that the filtering starts at the notificationContent element, i.e. in this case fooEvent. /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 Aug 16 16:02:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILlY7-00031Y-Fp for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 16:02:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILlY6-00027X-8H for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 16:02:31 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILlQ6-0002On-3s for netconf-data@psg.com; Thu, 16 Aug 2007 19:54:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILlQ3-0002OT-7o for netconf@ops.ietf.org; Thu, 16 Aug 2007 19:54:12 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id F31E01B80C3; Thu, 16 Aug 2007 21:54:09 +0200 (CEST) Date: Thu, 16 Aug 2007 21:54:19 +0200 (CEST) Message-Id: <20070816.215419.88144443.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point From: Martin Bjorklund In-Reply-To: <46C49AE9.5000000@andybierman.com> References: <46C46585.2000000@andybierman.com> <20070816.202110.99185670.mbj@tail-f.com> <46C49AE9.5000000@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: 082a9cbf4d599f360ac7f815372a6a15 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Note that there is no standard for 'eventClass', 'eventSeverity', > >> or 'eventTime', and a vendor may choose to use XML attributes > >> or elements for these fields (if they exist at all). > > > > The entire replay feature relies on the presence of an eventTime (or > > similar). If the manager can't figure out when the notifications were > > generated, he cannot set startTime and stopTime to get missing > > notifications. IMO, it's a big mistake that this event time isn't > > standardized - it means that a manager, in order to use replay > > efficiently, has to know all datamodels of all notifications, and know > > where to find the non-standard event time in each one. > > I agree. > It is a mistake to design the notification message assuming > these critical standard fields will be retro-fitted in > an inter-operable manner. I'm implementing this draft right now, and there are a couple of things that are awkward, but the main thing that makes it virtually impossible to do a good implementation of the replay is the lack of the eventTime (the time the notification was generated). In my manager, I want to be able to tell if I lost any notifications. So I get all notifs from the log and maybe listen to the live feed. If for any reason I can't listen to the live feed for a while, I try to resync. In order to do that, I use the replay feature with a startTime equal to the generation time of the latest notification I received. But there is no standard way to get the generation time from a notification. I think that in order to make replay interopable, we need to add the eventTime to the notifications. Here are two small modifications to the XSD that will allow this: As an attribute: or as an element: Standard eventClass and eventSeverity would be nice, but they are not crucial to the operations defined in the spec. /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 Aug 16 23: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 1ILsL0-0003tH-Pl for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 23:17:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILsKz-0005dB-Dt for netconf-archive@lists.ietf.org; Thu, 16 Aug 2007 23:17:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILsCv-0005GO-8M for netconf-data@psg.com; Fri, 17 Aug 2007 03:09:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1ILsCs-0005G3-Ab for netconf@ops.ietf.org; Fri, 17 Aug 2007 03:09:03 +0000 Received: (qmail 39912 invoked from network); 17 Aug 2007 03:09:02 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 17 Aug 2007 03:09:01 -0000 X-YMail-OSG: iPlK_BgVM1nC5jt5BPNa6oYBYMHhRRMc8_eDwS9aN3LrZMWpnqxCcO4.VPyG3EsZPtSBdFdbWP4- Message-ID: <46C510ED.4060505@andybierman.com> Date: Thu, 16 Aug 2007 20:07:25 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point References: <46C46585.2000000@andybierman.com> <20070816.202110.99185670.mbj@tail-f.com> <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> In-Reply-To: <20070816.215419.88144443.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: 73734d43604d52d23b3eba644a169745 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Note that there is no standard for 'eventClass', 'eventSeverity', >>>> or 'eventTime', and a vendor may choose to use XML attributes >>>> or elements for these fields (if they exist at all). >>> The entire replay feature relies on the presence of an eventTime (or >>> similar). If the manager can't figure out when the notifications were >>> generated, he cannot set startTime and stopTime to get missing >>> notifications. IMO, it's a big mistake that this event time isn't >>> standardized - it means that a manager, in order to use replay >>> efficiently, has to know all datamodels of all notifications, and know >>> where to find the non-standard event time in each one. >> I agree. >> It is a mistake to design the notification message assuming >> these critical standard fields will be retro-fitted in >> an inter-operable manner. > > I'm implementing this draft right now, and there are a couple of > things that are awkward, but the main thing that makes it virtually > impossible to do a good implementation of the replay is the lack of > the eventTime (the time the notification was generated). > > In my manager, I want to be able to tell if I lost any notifications. > So I get all notifs from the log and maybe listen to the live feed. > If for any reason I can't listen to the live feed for a while, I try > to resync. In order to do that, I use the replay feature with a > startTime equal to the generation time of the latest notification I > received. But there is no standard way to get the generation time > from a notification. I think this is a very important comment. I don't see how anyone in the WG (or IETF for that matter) can say that running code is not important to the standards process. I would call the notification replay feature 'broken', based on your comments. > > I think that in order to make replay interopable, we need to add the > eventTime to the notifications. Here are two small modifications to > the XSD that will allow this: > > As an attribute: > > > > > > or as an element: > > > > > > > Which namespace would the 'eventTime' element be defined in? Wouldn't it be different for every element definition? If it was an attribute in the element, it would be in the same namespace as that element. > > Standard eventClass and eventSeverity would be nice, but they are not > crucial to the operations defined in the spec. Furthermore, there is no agreement on what the enumerated strings should be, or what semantics are associated with each string. There is no disagreement at all that an event timestamp would be encoded in xs:dateTime format. This would the time the agent generated the message, not any of the other esoteric timestamps that have been discussed. > > > /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 Aug 17 03:06:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILvuf-0002P5-3A for netconf-archive@lists.ietf.org; Fri, 17 Aug 2007 03:06:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILvue-0003WI-Hp for netconf-archive@lists.ietf.org; Fri, 17 Aug 2007 03:06:29 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILvmg-0005uf-Ed for netconf-data@psg.com; Fri, 17 Aug 2007 06:58:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILvmd-0005uI-Oe for netconf@ops.ietf.org; Fri, 17 Aug 2007 06:58:13 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id E37FE1B80C3; Fri, 17 Aug 2007 08:58:09 +0200 (CEST) Date: Fri, 17 Aug 2007 08:58:20 +0200 (CEST) Message-Id: <20070817.085820.267376660.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point From: Martin Bjorklund In-Reply-To: <46C510ED.4060505@andybierman.com> References: <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> <46C510ED.4060505@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: 769a46790fb42fbb0b0cc700c82f7081 Andy Bierman wrote: > Martin Bjorklund wrote: > > I think that in order to make replay interopable, we need to add the > > eventTime to the notifications. Here are two small modifications to > > the XSD that will allow this: > > > > As an attribute: > > > > > > > > > > > > or as an element: > > > > > > > > > > > > > > > > Which namespace would the 'eventTime' element be defined in? > Wouldn't it be different for every element definition? No. > If it was an attribute in the element, > it would be in the same namespace as that element. If it's defined the way I wrote above, the eventTime element is in the same namespace as 'notification', i.e. "urn:ietf:params:xml:ns:netmod:notification". An example of an notification on the wire: 2007-08-17T08:56:05 3 /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Aug 17 14:23: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 1IM6Tb-0007ox-Rk for netconf-archive@lists.ietf.org; Fri, 17 Aug 2007 14:23:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM6Ta-0005ss-L7 for netconf-archive@lists.ietf.org; Fri, 17 Aug 2007 14:23:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IM6LP-000IQa-Tc for netconf-data@psg.com; Fri, 17 Aug 2007 18:14:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IM6LM-000IQF-Vz for netconf@ops.ietf.org; Fri, 17 Aug 2007 18:14:46 +0000 Received: (qmail 97690 invoked from network); 17 Aug 2007 18:14:43 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 17 Aug 2007 18:14:43 -0000 X-YMail-OSG: .ijdwC0VM1k49h8.aPsUYMZYyrK7WKMnMHVyMfSH9LtAwg8TondSQ9G0mglZbk8ZNEo_a_i2U7IQqOdp6xtTArCA Message-ID: <46C5E533.7070501@andybierman.com> Date: Fri, 17 Aug 2007 11:13:07 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point References: <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> <46C510ED.4060505@andybierman.com> <20070817.085820.267376660.mbj@tail-f.com> In-Reply-To: <20070817.085820.267376660.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: 082a9cbf4d599f360ac7f815372a6a15 Attn WG: Are there any objections to adding 'eventTime' to the notification message, as described by Martin? Andy > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> I think that in order to make replay interopable, we need to add the >>> eventTime to the notifications. Here are two small modifications to >>> the XSD that will allow this: >>> >>> As an attribute: >>> >>> >>> >>> >>> >>> or as an element: >>> >>> >>> >>> >>> >>> >>> >> Which namespace would the 'eventTime' element be defined in? >> Wouldn't it be different for every element definition? > > No. > >> If it was an attribute in the element, >> it would be in the same namespace as that element. > > If it's defined the way I wrote above, the eventTime element is in > the same namespace as 'notification', > i.e. "urn:ietf:params:xml:ns:netmod:notification". An example of an > notification on the wire: > > > > 2007-08-17T08:56:05 > 3 > > > > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Aug 17 17:25: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 1IM9Ja-0006Lk-I2 for netconf-archive@lists.ietf.org; Fri, 17 Aug 2007 17:25:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM9JX-0002mX-RB for netconf-archive@lists.ietf.org; Fri, 17 Aug 2007 17:25:06 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IM9CZ-000H3P-AA for netconf-data@psg.com; Fri, 17 Aug 2007 21:17:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [69.147.64.88] (helo=smtp115.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IM9CW-000H34-AJ for netconf@ops.ietf.org; Fri, 17 Aug 2007 21:17:49 +0000 Received: (qmail 87378 invoked from network); 17 Aug 2007 21:17:48 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 17 Aug 2007 21:17:47 -0000 X-YMail-OSG: PiK9Z14VM1lJS.47ToHorLvo90Y_PNzGx5NFa4nt.kluFU94 Message-ID: <46C6101B.3080306@andybierman.com> Date: Fri, 17 Aug 2007 14:16:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Pre-release 2 of Notification Update References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41060D3E3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41060D3E3@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: 4adaf050708fb13be3316a9eee889caa Sharon Chisholm wrote: > > Given a conceptual notification message: > > > > fault > major > ws1/hd0 > > > > Do you want to force the string "/notification" to appear over and over > in every filter, or start the filter at instead, and save 13 > chars in almost every term in the expression? > > > Historically, optimizations that make thing less intuitive to save a few > bits on the wire are not worth it (not being able to varbind in table > indices into SNMP notifications, for example.) > > I guess I had always thought the filter started at fooEvent because it > was against the definition of the notification, not what was on the > wire. What was the reasoning again to go with what is on the wire? This needs to be clarified in the draft. The filtering applies to the conceptual event messages, not anything in the configuration database. NETCONF filtering applies to the content layer. Since we want to be as consistent with and filtering as possible, this is really the abstract 'notificationContent' element. The top-level element is a protocol-specific wrapper. If this wrapper ever changes (e.g., SOAP) then the filters should still work. > > Sharon Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 20 10:09: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 1IN7wH-00086K-9L for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 10:09:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN7wG-000663-1D for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 10:09:05 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IN7iR-000N7k-A1 for netconf-data@psg.com; Mon, 20 Aug 2007 13:54:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IN7iK-000N73-82 for netconf@ops.ietf.org; Mon, 20 Aug 2007 13:54:41 +0000 Received: from pc6 (1Cust239.tnt1.lnd4.gbr.da.uu.net [62.188.130.239]) by ranger.systems.pipex.net (Postfix) with SMTP id D2BD1E000755; Mon, 20 Aug 2007 14:54:28 +0100 (BST) Message-ID: <032201c7e328$75b14fa0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" , "Martin Bjorklund" Cc: , References: <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> <46C510ED.4060505@andybierman.com> <20070817.085820.267376660.mbj@tail-f.com> <46C5E533.7070501@andybierman.com> Subject: Re: Notification #9: replay in the future consensus point Date: Mon, 20 Aug 2007 12:20:08 +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: -98.6 (---------------------------------------------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: ; Sent: Friday, August 17, 2007 8:13 PM Subject: Re: Notification #9: replay in the future consensus point > Attn WG: > > Are there any objections to adding 'eventTime' to the notification > message, as described by Martin? > I prefer the option since I think it gives simpler XPath expressions for filtering. Tom Petch > Andy > > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> I think that in order to make replay interopable, we need to add the > >>> eventTime to the notifications. Here are two small modifications to > >>> the XSD that will allow this: > >>> > >>> As an attribute: > >>> > >>> > >>> > >>> > >>> > >>> or as an element: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> Which namespace would the 'eventTime' element be defined in? > >> Wouldn't it be different for every element definition? > > > > No. > > > >> If it was an attribute in the element, > >> it would be in the same namespace as that element. > > > > If it's defined the way I wrote above, the eventTime element is in > > the same namespace as 'notification', > > i.e. "urn:ietf:params:xml:ns:netmod:notification". An example of an > > notification on the wire: > > > > > > > > 2007-08-17T08:56:05 > > 3 > > > > > > > > > > /martin > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 20 10:24: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 1IN8At-0002CN-M3 for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 10:24:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN8As-0006S7-3d for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 10:24:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IN7xO-000Oxp-3h for netconf-data@psg.com; Mon, 20 Aug 2007 14:10:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IN7xL-000OxC-Jy for netconf@ops.ietf.org; Mon, 20 Aug 2007 14:10:12 +0000 Received: from 12.140.8.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-outbound.avaya.com with ESMTP; 20 Aug 2007 10:10:04 -0400 X-IronPort-AV: i="4.19,285,1183348800"; d="scan'208"; a="52276264:sNHT10384332" 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: FW: [NGO] Netconf-Proxy Date: Mon, 20 Aug 2007 16:10:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] Netconf-Proxy Thread-Index: AcfjLLDRliYshLQSQW24GW7anLbB6gABvMKA From: "Romascanu, Dan (Dan)" To: "Netconf (E-mail)" Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This question is probably more within the scope of netconf rather than ngo.=20 Dan =20 -----Original Message----- From: Philipp Batroff [mailto:P.Batroff@gmx.net]=20 Sent: Monday, August 20, 2007 4:16 PM To: ngo@ietf.org Subject: [NGO] Netconf-Proxy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello, i have the Problem, that iam developing a box (similar to a proxy) with a Netconf-agent, which redirects request to several different agents. The problem is, that this box has just one IP-address. How can I divide between the different agents? Is there a wrapper, where i can specify the "target" behind that proxy, or is there anything else possible? I want to stay conform with the Netconf standard. Thank you and greets Phil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGyZQO9Os+BmHRimYRAoHrAJ4sKkIPPXRy6OlX12FsIwQz/kaVnQCcDlLV P1//yS1JJKXNfKh6mFtiyis=3D =3Dwcc5 -----END PGP SIGNATURE----- _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo -- to unsubscribe send a message to netconf-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 Aug 20 10:43: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 1IN8TS-0007Wc-Uo for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 10:43:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN8TR-0006vd-Ic for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 10:43:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IN8Mo-00025U-1H for netconf-data@psg.com; Mon, 20 Aug 2007 14:36:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IN8Ml-000259-5l for netconf@ops.ietf.org; Mon, 20 Aug 2007 14:36:28 +0000 Received: (qmail 60319 invoked from network); 20 Aug 2007 14:36:19 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 20 Aug 2007 14:36:19 -0000 X-YMail-OSG: PebkSuwVM1mVtS4OZSLCAtZOGG627ztonrvyB6OBlUjsrsEuN6EBLlWD4rKbxwq0vGn3bowEPY44Chub7_Y_qsuy6coKuEaAyLs- Message-ID: <46C9A680.1080300@andybierman.com> Date: Mon, 20 Aug 2007 07:34:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: "Netconf (E-mail)" , P.Batroff@gmx.net Subject: Re: FW: [NGO] Netconf-Proxy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Romascanu, Dan (Dan) wrote: > This question is probably more within the scope of netconf rather than > ngo. > > Dan > > > > > > -----Original Message----- > From: Philipp Batroff [mailto:P.Batroff@gmx.net] > Sent: Monday, August 20, 2007 4:16 PM > To: ngo@ietf.org > Subject: [NGO] Netconf-Proxy > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hello, > > i have the Problem, that iam developing a box (similar to a proxy) with > a Netconf-agent, which redirects request to several different agents. > The problem is, that this box has just one IP-address. > How can I divide between the different agents? Is there a wrapper, where > i can specify the "target" behind that proxy, or is there anything else > possible? > I want to stay conform with the Netconf standard. You can put whatever XML attributes you want in the element. NETCONF has no concept of proxy. Operators told us they hate SNMP Proxy and want nothing like it in NETCONF. Andy > > Thank you and greets Phil > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGyZQO9Os+BmHRimYRAoHrAJ4sKkIPPXRy6OlX12FsIwQz/kaVnQCcDlLV > P1//yS1JJKXNfKh6mFtiyis= > =wcc5 > -----END PGP SIGNATURE----- > > > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo > > -- > to 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 Aug 20 20:01: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 1INHBH-0003Tj-Q6 for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 20:01:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INHBG-0006Mh-Dr for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 20:01:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INGyb-000FNZ-Mf for netconf-data@psg.com; Mon, 20 Aug 2007 23:48:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INGyY-000FNE-Gu for netconf@ops.ietf.org; Mon, 20 Aug 2007 23:48:04 +0000 Received: (qmail 29211 invoked from network); 20 Aug 2007 23:48:01 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2007 23:48:01 -0000 X-YMail-OSG: ZjcXRiQVM1lO97qAdC2HgdLYgGLm2po.z0ydrNQc5ZyPNteqAc6UMBHWPBxGAPrff5zgxoSAETooJ6zlGUaU665C8g-- Message-ID: <46CA27CD.4040406@andybierman.com> Date: Mon, 20 Aug 2007 16:46:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David B Harrington CC: 'Martin Bjorklund' , schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point References: <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> <46C510ED.4060505@andybierman.com> <20070817.085820.267376660.mbj@tail-f.com> <46C5E533.7070501@andybierman.com> <046b01c7e37f$db601f50$6702a8c0@china.huawei.com> In-Reply-To: <046b01c7e37f$db601f50$6702a8c0@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: a8a20a483a84f747e56475e290ee868e David B Harrington wrote: > Hi, > > I would recommend adding fields akin to severity and facility as well. The WG tried but did not come close to agreeing on all the enumerations. The WG agreed this was a "content" issue. The WG does not agree that the notification mechanism is directly mapped to syslog. What is the severity and facility for a "linkUp" or "linkDown" event, for example? > > dbh Andy > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >> Sent: Friday, August 17, 2007 2:13 PM >> To: Martin Bjorklund >> Cc: schishol@nortel.com; netconf@ops.ietf.org >> Subject: Re: Notification #9: replay in the future consensus point >> >> Attn WG: >> >> Are there any objections to adding 'eventTime' to the notification >> message, as described by Martin? >> >> Andy >> >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> I think that in order to make replay interopable, we need >> to add the >>>>> eventTime to the notifications. Here are two small >> modifications to >>>>> the XSD that will allow this: >>>>> >>>>> As an attribute: >>>>> >>>>> >>>>> > use="required"/> >>>>> >>>>> >>>>> or as an element: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Which namespace would the 'eventTime' element be defined in? >>>> Wouldn't it be different for every element definition? >>> No. >>> >>>> If it was an attribute in the element, >>>> it would be in the same namespace as that element. >>> If it's defined the way I wrote above, the eventTime element is in >>> the same namespace as 'notification', >>> i.e. "urn:ietf:params:xml:ns:netmod:notification". An example of > an >>> notification on the wire: >>> >>> > xmlns:ncn="urn:ietf:params:xml:ns:netconf:notification:1.0"> >>> >>> 2007-08-17T08:56:05 >>> 3 >>> >>> >>> >>> >>> /martin >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >>> >> >> -- >> to 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 Aug 20 20:02: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 1INHCQ-00045M-78 for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 20:02:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INHCO-0006P0-TG for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 20:02:22 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INH1e-000Fov-II for netconf-data@psg.com; Mon, 20 Aug 2007 23:51:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1INH1b-000FoX-JO for netconf@ops.ietf.org; Mon, 20 Aug 2007 23:51:13 +0000 Received: (qmail 87081 invoked from network); 20 Aug 2007 23:51:10 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 20 Aug 2007 23:51:10 -0000 X-YMail-OSG: 7Xwg508VM1menqYctvlPk.OfQgBUfDW8JN.IrNVNWPYN1vrwrcarvFLRAVffRARSunGbfKJfexCgtBH0cDIiDj1qGtPa1gP_MdIX Message-ID: <46CA288A.5030202@andybierman.com> Date: Mon, 20 Aug 2007 16:49:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David B Harrington CC: "'Romascanu, Dan \(Dan\)'" , "'Netconf (E-mail)'" , P.Batroff@gmx.net Subject: Re: FW: [NGO] Netconf-Proxy References: <46C9A680.1080300@andybierman.com> <046c01c7e381$3280b2d0$6702a8c0@china.huawei.com> In-Reply-To: <046c01c7e381$3280b2d0$6702a8c0@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: a87a9cdae4ac5d3fbeee75cd0026d632 David B Harrington wrote: > Hi, > > Is that operator opinion documented somewhere? I checked RFC3535, the > IAB Workshop on Network Management, but found no mention of proxy. Was > that input captured in some netconf meeting minutes? no - the discussion at the IAB NM workshop did not make it into RFC 3535. Nobody has ever seriously suggested adding a proxy mechanism to NETCONF, similar to SNMP Proxy. > > dbh > Andy >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >> Sent: Monday, August 20, 2007 10:35 AM >> To: Romascanu, Dan (Dan) >> Cc: Netconf (E-mail); P.Batroff@gmx.net >> Subject: Re: FW: [NGO] Netconf-Proxy >> >> Romascanu, Dan (Dan) wrote: >>> This question is probably more within the scope of netconf >> rather than >>> ngo. >>> >>> Dan >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Philipp Batroff [mailto:P.Batroff@gmx.net] >>> Sent: Monday, August 20, 2007 4:16 PM >>> To: ngo@ietf.org >>> Subject: [NGO] Netconf-Proxy >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> hello, >>> >>> i have the Problem, that iam developing a box (similar to a >> proxy) with >>> a Netconf-agent, which redirects request to several >> different agents. >>> The problem is, that this box has just one IP-address. >>> How can I divide between the different agents? Is there a >> wrapper, where >>> i can specify the "target" behind that proxy, or is there >> anything else >>> possible? >>> I want to stay conform with the Netconf standard. >> You can put whatever XML attributes you want in the element. >> NETCONF has no concept of proxy. Operators told us they hate >> SNMP Proxy and want nothing like it in NETCONF. >> >> Andy >> >>> Thank you and greets Phil >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.7 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iD8DBQFGyZQO9Os+BmHRimYRAoHrAJ4sKkIPPXRy6OlX12FsIwQz/kaVnQCcDlLV >>> P1//yS1JJKXNfKh6mFtiyis= >>> =wcc5 >>> -----END PGP SIGNATURE----- >>> >>> >>> >>> _______________________________________________ >>> NGO mailing list >>> NGO@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ngo >>> >>> -- >>> to 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 Aug 20 22:17: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 1INJJH-0003dT-Eo for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 22:17:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INJJG-0001Dx-48 for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 22:17:35 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INJ9c-000747-IC for netconf-data@psg.com; Tue, 21 Aug 2007 02:07:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [206.18.177.55] (helo=alnrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INJ9Z-00072q-Jj for netconf@ops.ietf.org; Tue, 21 Aug 2007 02:07:35 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070820232415b1500a4pf7e>; Mon, 20 Aug 2007 23:24:15 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Romascanu, Dan \(Dan\)'" Cc: "'Netconf \(E-mail\)'" , References: <46C9A680.1080300@andybierman.com> Subject: RE: FW: [NGO] Netconf-Proxy Date: Mon, 20 Aug 2007 19:24:00 -0400 Message-ID: <046c01c7e381$3280b2d0$6702a8c0@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: <46C9A680.1080300@andybierman.com> Thread-Index: AcfjOHVcFPES+5sERy29BcO8lReOJgAR9rtA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hi, Is that operator opinion documented somewhere? I checked RFC3535, the IAB Workshop on Network Management, but found no mention of proxy. Was that input captured in some netconf meeting minutes? dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Monday, August 20, 2007 10:35 AM > To: Romascanu, Dan (Dan) > Cc: Netconf (E-mail); P.Batroff@gmx.net > Subject: Re: FW: [NGO] Netconf-Proxy > > Romascanu, Dan (Dan) wrote: > > This question is probably more within the scope of netconf > rather than > > ngo. > > > > Dan > > > > > > > > > > > > -----Original Message----- > > From: Philipp Batroff [mailto:P.Batroff@gmx.net] > > Sent: Monday, August 20, 2007 4:16 PM > > To: ngo@ietf.org > > Subject: [NGO] Netconf-Proxy > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > hello, > > > > i have the Problem, that iam developing a box (similar to a > proxy) with > > a Netconf-agent, which redirects request to several > different agents. > > The problem is, that this box has just one IP-address. > > How can I divide between the different agents? Is there a > wrapper, where > > i can specify the "target" behind that proxy, or is there > anything else > > possible? > > I want to stay conform with the Netconf standard. > > You can put whatever XML attributes you want in the element. > NETCONF has no concept of proxy. Operators told us they hate > SNMP Proxy and want nothing like it in NETCONF. > > Andy > > > > > Thank you and greets Phil > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.7 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFGyZQO9Os+BmHRimYRAoHrAJ4sKkIPPXRy6OlX12FsIwQz/kaVnQCcDlLV > > P1//yS1JJKXNfKh6mFtiyis= > > =wcc5 > > -----END PGP SIGNATURE----- > > > > > > > > _______________________________________________ > > NGO mailing list > > NGO@ietf.org > > https://www1.ietf.org/mailman/listinfo/ngo > > > > -- > > to 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 Aug 20 23:42:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INKdm-0003mr-Bz for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 23:42:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INKdl-0002cO-0b for netconf-archive@lists.ietf.org; Mon, 20 Aug 2007 23:42:50 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INKWJ-000IJC-RF for netconf-data@psg.com; Tue, 21 Aug 2007 03:35:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [204.127.200.84] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INKWH-000IF2-6X for netconf@ops.ietf.org; Tue, 21 Aug 2007 03:35:06 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <200708210335040140009754e>; Tue, 21 Aug 2007 03:35:04 +0000 From: "David B Harrington" To: "'Andy Bierman'" Cc: "'Romascanu, Dan \(Dan\)'" , "'Netconf \(E-mail\)'" , References: <46C9A680.1080300@andybierman.com> <046c01c7e381$3280b2d0$6702a8c0@china.huawei.com> <46CA288A.5030202@andybierman.com> Subject: RE: FW: [NGO] Netconf-Proxy Date: Mon, 20 Aug 2007 23:34:51 -0400 Message-ID: <002001c7e3a4$3c087f40$6702a8c0@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: AcfjhPw36WtDkhj1TaSenpqlrI+BKAAHutBQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46CA288A.5030202@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Hi, I didn't say anybody had tried to add proxy to Netconf, or that it was desirable. You made a statement that operators said they HATED SNMP proxy. I wanted to see documentation of that statement from operators. Or is that just your opinion? I'd like ti to be clear whether it is aomething the operators said or something you said. dbh > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Monday, August 20, 2007 7:50 PM > To: David B Harrington > Cc: 'Romascanu, Dan (Dan)'; 'Netconf (E-mail)'; P.Batroff@gmx.net > Subject: Re: FW: [NGO] Netconf-Proxy > > David B Harrington wrote: > > Hi, > > > > Is that operator opinion documented somewhere? I checked > RFC3535, the > > IAB Workshop on Network Management, but found no mention of > proxy. Was > > that input captured in some netconf meeting minutes? > > no - the discussion at the IAB NM workshop did not make it > into RFC 3535. > Nobody has ever seriously suggested adding a proxy mechanism > to NETCONF, > similar to SNMP Proxy. > > > > > > dbh > > > > Andy > > >> -----Original Message----- > >> From: owner-netconf@ops.ietf.org > >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > >> Sent: Monday, August 20, 2007 10:35 AM > >> To: Romascanu, Dan (Dan) > >> Cc: Netconf (E-mail); P.Batroff@gmx.net > >> Subject: Re: FW: [NGO] Netconf-Proxy > >> > >> Romascanu, Dan (Dan) wrote: > >>> This question is probably more within the scope of netconf > >> rather than > >>> ngo. > >>> > >>> Dan > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Philipp Batroff [mailto:P.Batroff@gmx.net] > >>> Sent: Monday, August 20, 2007 4:16 PM > >>> To: ngo@ietf.org > >>> Subject: [NGO] Netconf-Proxy > >>> > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> hello, > >>> > >>> i have the Problem, that iam developing a box (similar to a > >> proxy) with > >>> a Netconf-agent, which redirects request to several > >> different agents. > >>> The problem is, that this box has just one IP-address. > >>> How can I divide between the different agents? Is there a > >> wrapper, where > >>> i can specify the "target" behind that proxy, or is there > >> anything else > >>> possible? > >>> I want to stay conform with the Netconf standard. > >> You can put whatever XML attributes you want in the element. > >> NETCONF has no concept of proxy. Operators told us they hate > >> SNMP Proxy and want nothing like it in NETCONF. > >> > >> Andy > >> > >>> Thank you and greets Phil > >>> -----BEGIN PGP SIGNATURE----- > >>> Version: GnuPG v1.4.7 (GNU/Linux) > >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>> > >>> iD8DBQFGyZQO9Os+BmHRimYRAoHrAJ4sKkIPPXRy6OlX12FsIwQz/kaVnQCcDlLV > >>> P1//yS1JJKXNfKh6mFtiyis= > >>> =wcc5 > >>> -----END PGP SIGNATURE----- > >>> > >>> > >>> > >>> _______________________________________________ > >>> NGO mailing list > >>> NGO@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ngo > >>> > >>> -- > >>> to 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 Aug 21 01:32: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 1INMLs-0003tn-Ht for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 01:32:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INMLr-0004Mk-97 for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 01:32:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INMAX-0006uH-9i for netconf-data@psg.com; Tue, 21 Aug 2007 05:20:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [206.18.177.53] (helo=alnrmhc13.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INMAU-0006tz-HT for netconf@ops.ietf.org; Tue, 21 Aug 2007 05:20:43 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070820231441b1300efil2e>; Mon, 20 Aug 2007 23:14:41 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Martin Bjorklund'" Cc: , References: <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> <46C510ED.4060505@andybierman.com> <20070817.085820.267376660.mbj@tail-f.com> <46C5E533.7070501@andybierman.com> Subject: RE: Notification #9: replay in the future consensus point Date: Mon, 20 Aug 2007 19:14:27 -0400 Message-ID: <046b01c7e37f$db601f50$6702a8c0@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: <46C5E533.7070501@andybierman.com> Thread-Index: Acfg+63DTqzOWDDfSuGXZ9vpJ1bAbgChA3zg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi, I would recommend adding fields akin to severity and facility as well. dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Friday, August 17, 2007 2:13 PM > To: Martin Bjorklund > Cc: schishol@nortel.com; netconf@ops.ietf.org > Subject: Re: Notification #9: replay in the future consensus point > > Attn WG: > > Are there any objections to adding 'eventTime' to the notification > message, as described by Martin? > > Andy > > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> I think that in order to make replay interopable, we need > to add the > >>> eventTime to the notifications. Here are two small > modifications to > >>> the XSD that will allow this: > >>> > >>> As an attribute: > >>> > >>> > >>> use="required"/> > >>> > >>> > >>> or as an element: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> Which namespace would the 'eventTime' element be defined in? > >> Wouldn't it be different for every element definition? > > > > No. > > > >> If it was an attribute in the element, > >> it would be in the same namespace as that element. > > > > If it's defined the way I wrote above, the eventTime element is in > > the same namespace as 'notification', > > i.e. "urn:ietf:params:xml:ns:netmod:notification". An example of an > > notification on the wire: > > > > xmlns:ncn="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > 2007-08-17T08:56:05 > > 3 > > > > > > > > > > /martin > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > -- > to 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 Aug 21 01:52: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 1INMey-0002gJ-D8 for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 01:52:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INMex-0004cW-1x for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 01:52:12 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INMTB-0009PE-8S for netconf-data@psg.com; Tue, 21 Aug 2007 05:40:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1INMT8-0009Oq-F6 for netconf@ops.ietf.org; Tue, 21 Aug 2007 05:39:59 +0000 Received: (qmail 39828 invoked from network); 21 Aug 2007 05:39:58 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2007 05:39:57 -0000 X-YMail-OSG: cy4XIa8VM1nfoWPrdao6fq.1mEwnoPUkDp3.yjYzC6uEOw21U.ZpQyPUj9qiZgZD.RvnUHsMsTK1PukFfCKTpNY6REnZiehPWIQ- Message-ID: <46CA7A4A.1080301@andybierman.com> Date: Mon, 20 Aug 2007 22:38:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David B Harrington CC: "'Romascanu, Dan \(Dan\)'" , "'Netconf (E-mail)'" , P.Batroff@gmx.net Subject: Re: FW: [NGO] Netconf-Proxy References: <46C9A680.1080300@andybierman.com> <046c01c7e381$3280b2d0$6702a8c0@china.huawei.com> <46CA288A.5030202@andybierman.com> <002001c7e3a4$3c087f40$6702a8c0@china.huawei.com> In-Reply-To: <002001c7e3a4$3c087f40$6702a8c0@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: 789c141a303c09204b537a4078e2a63f David B Harrington wrote: > Hi, > > I didn't say anybody had tried to add proxy to Netconf, or that it was > desirable. > > You made a statement that operators said they HATED SNMP proxy. I > wanted to see documentation of that statement from operators. Or is > that just your opinion? I'd like ti to be clear whether it is > aomething the operators said or something you said. I heard 2 operators at the IAB NM workshop say that, including Randy Bush. The concerns were over increased system complexity without sufficient gain. I'm not sure why we need to discuss SNMP proxy on this list, since nobody is actually suggesting that a proxy mechanism needs to be added to the NETCONF protocol. > > dbh Andy > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Monday, August 20, 2007 7:50 PM >> To: David B Harrington >> Cc: 'Romascanu, Dan (Dan)'; 'Netconf (E-mail)'; P.Batroff@gmx.net >> Subject: Re: FW: [NGO] Netconf-Proxy >> >> David B Harrington wrote: >>> Hi, >>> >>> Is that operator opinion documented somewhere? I checked >> RFC3535, the >>> IAB Workshop on Network Management, but found no mention of >> proxy. Was >>> that input captured in some netconf meeting minutes? >> no - the discussion at the IAB NM workshop did not make it >> into RFC 3535. >> Nobody has ever seriously suggested adding a proxy mechanism >> to NETCONF, >> similar to SNMP Proxy. >> >> >>> dbh >>> >> Andy >> >>>> -----Original Message----- >>>> From: owner-netconf@ops.ietf.org >>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>>> Sent: Monday, August 20, 2007 10:35 AM >>>> To: Romascanu, Dan (Dan) >>>> Cc: Netconf (E-mail); P.Batroff@gmx.net >>>> Subject: Re: FW: [NGO] Netconf-Proxy >>>> >>>> Romascanu, Dan (Dan) wrote: >>>>> This question is probably more within the scope of netconf >>>> rather than >>>>> ngo. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Philipp Batroff [mailto:P.Batroff@gmx.net] >>>>> Sent: Monday, August 20, 2007 4:16 PM >>>>> To: ngo@ietf.org >>>>> Subject: [NGO] Netconf-Proxy >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> hello, >>>>> >>>>> i have the Problem, that iam developing a box (similar to a >>>> proxy) with >>>>> a Netconf-agent, which redirects request to several >>>> different agents. >>>>> The problem is, that this box has just one IP-address. >>>>> How can I divide between the different agents? Is there a >>>> wrapper, where >>>>> i can specify the "target" behind that proxy, or is there >>>> anything else >>>>> possible? >>>>> I want to stay conform with the Netconf standard. >>>> You can put whatever XML attributes you want in the > element. >>>> NETCONF has no concept of proxy. Operators told us they hate >>>> SNMP Proxy and want nothing like it in NETCONF. >>>> >>>> Andy >>>> >>>>> Thank you and greets Phil >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.7 (GNU/Linux) >>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>>>> >>>>> iD8DBQFGyZQO9Os+BmHRimYRAoHrAJ4sKkIPPXRy6OlX12FsIwQz/kaVnQCcDlLV >>>>> P1//yS1JJKXNfKh6mFtiyis= >>>>> =wcc5 >>>>> -----END PGP SIGNATURE----- >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> NGO mailing list >>>>> NGO@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ngo >>>>> >>>>> -- >>>>> to 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 Aug 21 06:29: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 1INQys-0002EP-Fy for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 06:29:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INQyr-0004My-1J for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 06:29:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INQnY-000Nq8-54 for netconf-data@psg.com; Tue, 21 Aug 2007 10:17:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [204.127.200.85] (helo=sccrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INQnS-000Npe-4u for netconf@ops.ietf.org; Tue, 21 Aug 2007 10:17:15 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007082110171201500pejoce>; Tue, 21 Aug 2007 10:17:12 +0000 From: "David B Harrington" To: "'Andy Bierman'" Cc: "'Romascanu, Dan \(Dan\)'" , "'Netconf \(E-mail\)'" , References: <46C9A680.1080300@andybierman.com> <046c01c7e381$3280b2d0$6702a8c0@china.huawei.com> <46CA288A.5030202@andybierman.com> <002001c7e3a4$3c087f40$6702a8c0@china.huawei.com> <46CA7A4A.1080301@andybierman.com> Subject: RE: FW: [NGO] Netconf-Proxy Date: Tue, 21 Aug 2007 06:16:59 -0400 Message-ID: <004e01c7e3dc$694183c0$6702a8c0@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: AcfjtbWtYStXq2cDSpeBlhVlXTuy2wAJo01w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46CA7A4A.1080301@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 You are the person that first mentioned snmp proxy. I just wanted to know if your statement had documentation behind it. dbh > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Tuesday, August 21, 2007 1:38 AM > To: David B Harrington > Cc: 'Romascanu, Dan (Dan)'; 'Netconf (E-mail)'; P.Batroff@gmx.net > Subject: Re: FW: [NGO] Netconf-Proxy > > David B Harrington wrote: > > Hi, > > > > I didn't say anybody had tried to add proxy to Netconf, or > that it was > > desirable. > > > > You made a statement that operators said they HATED SNMP proxy. I > > wanted to see documentation of that statement from operators. Or is > > that just your opinion? I'd like ti to be clear whether it is > > aomething the operators said or something you said. > > I heard 2 operators at the IAB NM workshop say that, > including Randy Bush. > The concerns were over increased system complexity without > sufficient gain. > I'm not sure why we need to discuss SNMP proxy on this list, > since nobody is actually suggesting that a proxy mechanism > needs to be added to the NETCONF protocol. > > > > > > dbh > > Andy > > > > >> -----Original Message----- > >> From: Andy Bierman [mailto:ietf@andybierman.com] > >> Sent: Monday, August 20, 2007 7:50 PM > >> To: David B Harrington > >> Cc: 'Romascanu, Dan (Dan)'; 'Netconf (E-mail)'; P.Batroff@gmx.net > >> Subject: Re: FW: [NGO] Netconf-Proxy > >> > >> David B Harrington wrote: > >>> Hi, > >>> > >>> Is that operator opinion documented somewhere? I checked > >> RFC3535, the > >>> IAB Workshop on Network Management, but found no mention of > >> proxy. Was > >>> that input captured in some netconf meeting minutes? > >> no - the discussion at the IAB NM workshop did not make it > >> into RFC 3535. > >> Nobody has ever seriously suggested adding a proxy mechanism > >> to NETCONF, > >> similar to SNMP Proxy. > >> > >> > >>> dbh > >>> > >> Andy > >> > >>>> -----Original Message----- > >>>> From: owner-netconf@ops.ietf.org > >>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > >>>> Sent: Monday, August 20, 2007 10:35 AM > >>>> To: Romascanu, Dan (Dan) > >>>> Cc: Netconf (E-mail); P.Batroff@gmx.net > >>>> Subject: Re: FW: [NGO] Netconf-Proxy > >>>> > >>>> Romascanu, Dan (Dan) wrote: > >>>>> This question is probably more within the scope of netconf > >>>> rather than > >>>>> ngo. > >>>>> > >>>>> Dan > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Philipp Batroff [mailto:P.Batroff@gmx.net] > >>>>> Sent: Monday, August 20, 2007 4:16 PM > >>>>> To: ngo@ietf.org > >>>>> Subject: [NGO] Netconf-Proxy > >>>>> > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA1 > >>>>> > >>>>> hello, > >>>>> > >>>>> i have the Problem, that iam developing a box (similar to a > >>>> proxy) with > >>>>> a Netconf-agent, which redirects request to several > >>>> different agents. > >>>>> The problem is, that this box has just one IP-address. > >>>>> How can I divide between the different agents? Is there a > >>>> wrapper, where > >>>>> i can specify the "target" behind that proxy, or is there > >>>> anything else > >>>>> possible? > >>>>> I want to stay conform with the Netconf standard. > >>>> You can put whatever XML attributes you want in the > > element. > >>>> NETCONF has no concept of proxy. Operators told us they hate > >>>> SNMP Proxy and want nothing like it in NETCONF. > >>>> > >>>> Andy > >>>> > >>>>> Thank you and greets Phil > >>>>> -----BEGIN PGP SIGNATURE----- > >>>>> Version: GnuPG v1.4.7 (GNU/Linux) > >>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>>>> > >>>>> iD8DBQFGyZQO9Os+BmHRimYRAoHrAJ4sKkIPPXRy6OlX12FsIwQz/kaVnQCcDlLV > >>>>> P1//yS1JJKXNfKh6mFtiyis= > >>>>> =wcc5 > >>>>> -----END PGP SIGNATURE----- > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> NGO mailing list > >>>>> NGO@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ngo > >>>>> > >>>>> -- > >>>>> to 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 Aug 21 09:08: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 1INTTF-0000yD-DG for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 09:08:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INTTE-00008A-62 for netconf-archive@lists.ietf.org; Tue, 21 Aug 2007 09:08:33 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INTEE-000Nbu-NO for netconf-data@psg.com; Tue, 21 Aug 2007 12:53:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [63.240.77.84] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INTEC-000NbQ-77 for netconf@ops.ietf.org; Tue, 21 Aug 2007 12:53:01 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007082112525901400073tbe>; Tue, 21 Aug 2007 12:52:59 +0000 From: "David B Harrington" To: Cc: "'Netconf \(E-mail\)'" References: <46C9A680.1080300@andybierman.com> <046c01c7e381$3280b2d0$6702a8c0@china.huawei.com> <46CA288A.5030202@andybierman.com> <002001c7e3a4$3c087f40$6702a8c0@china.huawei.com> <46CA7A4A.1080301@andybierman.com> Subject: RE: FW: [NGO] Netconf-Proxy Date: Tue, 21 Aug 2007 08:52:46 -0400 Message-ID: <005b01c7e3f2$2c4022e0$6702a8c0@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: Acfjt2vFihxZH03sTRy9AQVxjSV/lQAMhGng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46CA7A4A.1080301@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Phil, Unfortunately, the word "proxy" can be sensitive. ;-) The Netconf protocol does not have a proxy mechanism. I am interested in your use case. Can you describe your use case in more detail? Is your use case a request from operators/customers? Is this related to NAT, where you have only one public IP address but multiple devices you want to configure in the private address space behind the NAT device? When I worked at Enterasys, customers requested the ability to perform CLI-based configuration in a distributed hierarchical manner, going through intermediate routers and switches to reach devices. To a degree this can be done using a policy-based distributed management approach, where you "configure" an intermediate node to hold the configuration information for other nodes. There have been a number of IETF efforts focused on standardizing this type of policy-based management, none of which has seemed to achieve success in the field. Is you use case related to policy-based management? Hope this helps, David Harrington dbharrington@comcast.net ietfdbh@comcast.net -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 22 09:01: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 1INppr-0003JC-5w for netconf-archive@lists.ietf.org; Wed, 22 Aug 2007 09:01:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INppp-0002Y2-Np for netconf-archive@lists.ietf.org; Wed, 22 Aug 2007 09:01:23 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INpZl-000L7a-Ml for netconf-data@psg.com; Wed, 22 Aug 2007 12:44:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INpZi-000L7C-VD for netconf@ops.ietf.org; Wed, 22 Aug 2007 12:44:44 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7MCgZt07005 for ; Wed, 22 Aug 2007 12:42:35 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 #9: replay in the future consensus point Date: Wed, 22 Aug 2007 08:44:36 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41075254F@zcarhxm2.corp.nortel.com> In-Reply-To: <46C510ED.4060505@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification #9: replay in the future consensus point thread-index: Acfge/fDL1MHNkQGR621Ckmzi5LD/AEPfZyw References: <46C46585.2000000@andybierman.com> <20070816.202110.99185670.mbj@tail-f.com> <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> <46C510ED.4060505@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Hi Two comments on this. Our implementation has eventTime for many of the reasons discussed. I support inclusion of eventTime as an element in the notification. Sharon=20 -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Thursday, August 16, 2007 11:07 PM To: Martin Bjorklund Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Note that there is no standard for 'eventClass', 'eventSeverity',=20 >>>> or 'eventTime', and a vendor may choose to use XML attributes or=20 >>>> elements for these fields (if they exist at all). >>> The entire replay feature relies on the presence of an eventTime (or >>> similar). If the manager can't figure out when the notifications=20 >>> were generated, he cannot set startTime and stopTime to get missing=20 >>> notifications. IMO, it's a big mistake that this event time isn't=20 >>> standardized - it means that a manager, in order to use replay=20 >>> efficiently, has to know all datamodels of all notifications, and=20 >>> know where to find the non-standard event time in each one. >> I agree. >> It is a mistake to design the notification message assuming these=20 >> critical standard fields will be retro-fitted in an inter-operable=20 >> manner. >=20 > I'm implementing this draft right now, and there are a couple of=20 > things that are awkward, but the main thing that makes it virtually=20 > impossible to do a good implementation of the replay is the lack of=20 > the eventTime (the time the notification was generated). >=20 > In my manager, I want to be able to tell if I lost any notifications. > So I get all notifs from the log and maybe listen to the live feed. > If for any reason I can't listen to the live feed for a while, I try=20 > to resync. In order to do that, I use the replay feature with a=20 > startTime equal to the generation time of the latest notification I=20 > received. But there is no standard way to get the generation time=20 > from a notification. I think this is a very important comment. I don't see how anyone in the WG (or IETF for that matter) can say that running code is not important to the standards process. I would call the notification replay feature 'broken', based on your comments. >=20 > I think that in order to make replay interopable, we need to add the=20 > eventTime to the notifications. Here are two small modifications to=20 > the XSD that will allow this: >=20 > As an attribute: >=20 > > > >=20 > or as an element: >=20 > > > > > >=20 Which namespace would the 'eventTime' element be defined in? Wouldn't it be different for every element definition? If it was an attribute in the element, it would be in the same namespace as that element. >=20 > Standard eventClass and eventSeverity would be nice, but they are not=20 > crucial to the operations defined in the spec. Furthermore, there is no agreement on what the enumerated strings should be, or what semantics are associated with each string. There is no disagreement at all that an event timestamp would be encoded in xs:dateTime format. This would the time the agent generated the message, not any of the other esoteric timestamps that have been discussed. >=20 >=20 > /martin >=20 >=20 Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 22 14: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 1INvOx-0001M4-91 for netconf-archive@lists.ietf.org; Wed, 22 Aug 2007 14:57:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INvOw-0001o3-PM for netconf-archive@lists.ietf.org; Wed, 22 Aug 2007 14:57:59 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INvAx-0003On-Lm for netconf-data@psg.com; Wed, 22 Aug 2007 18:43:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INvAu-0003OL-Qx for netconf@ops.ietf.org; Wed, 22 Aug 2007 18:43:30 +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 l7MIhP607180 for ; Wed, 22 Aug 2007 18:43:25 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: Pre-release 2 of Notification Update Date: Wed, 22 Aug 2007 14:43:09 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4107A7FD1@zcarhxm2.corp.nortel.com> In-Reply-To: <021601c7de7e$7d54bf20$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pre-release 2 of Notification Update thread-index: Acfeh60nZmiooInJTxyIAP8OT4gVdAGYyGwA References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> From: "Sharon Chisholm" To: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Hi I find the reference to 'on the wire' a bit confusing, so instead I propose saying in section 3.2.5.2.1 the following:=20 The filter element is specified against the contents of the wrapper and not the wrapper itself. See section 5 for examples. =20 Sharon -----Original Message----- From: tom.petch [mailto:cfinss@dial.pipex.com]=20 Sent: Tuesday, August 14, 2007 10:13 AM To: Chisholm, Sharon (CAR:ZZ00); Netconf (E-mail) Subject: Re: Pre-release 2 of Notification Update Sharon I raised the question of whether a filter would be applied to the event as it would appear on the wire, or as it might appear in the datastore (thinking of XPath roots and namespaces). Andy reported back, after a hallway BoF with Martin '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..' I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 "Conceptually, the filter is applied to the event notification as it would appear on the wire and not to it as it might appear in the conceptual NETCONF database." Tom Petch ----- Original Message ----- From: "Sharon Chisholm" To: "Netconf (E-mail)" Sent: Wednesday, August 08, 2007 9:24 PM Subject: Pre-release 2 of Notification Update Hi I'm almost done the update (hopefully). Attached is a pre-release. Please let me know if anything was incorrectly executed. <> Disclaimers: 1. I have not validated much of the schema or examples 2. I got a bit confused in the updates to section 5.2. These may still have issues. 3. I have not done anything about replays in the future. The text remains unchanged in this area. 4. I need to double check that I have not missed updates. 5. There were a few changes (mainly editorial) that I did not make for specific reasons which I need to send an email to discuss. 6. Not sure if using correct namespace in section 2.1.1.1. Andy said what was there was wrong, but it validates for me and there was no suggestions. I tried something else, but it didn't validate. 7. There was a request to add description of how to define notification instances, which has not been added, but there are now two examples (one in replayComplete and one in the examples in section 5). Is this sufficient? 8. I have not validate that I am always using the correct The URI string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) Sharon Chisholm Nortel Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 22 15:21: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 1INvlt-0000L1-Hb for netconf-archive@lists.ietf.org; Wed, 22 Aug 2007 15:21:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INvls-0002B9-Sc for netconf-archive@lists.ietf.org; Wed, 22 Aug 2007 15:21:41 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INvf4-00064F-Iz for netconf-data@psg.com; Wed, 22 Aug 2007 19:14:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1INvf1-00063z-U2 for netconf@ops.ietf.org; Wed, 22 Aug 2007 19:14:37 +0000 Received: (qmail 2811 invoked from network); 22 Aug 2007 19:14:35 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 22 Aug 2007 19:14:35 -0000 X-YMail-OSG: skSfKY0VM1lZBeWKBGpsAiOaIc2mz.ldSLwAi34IiAhyPakDAv0bxCoox1vCwWM238e.kV3YbA3kLu3Pdt_lKIoQ Message-ID: <46CC8AB6.3060208@andybierman.com> Date: Wed, 22 Aug 2007 12:12:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Pre-release 2 of Notification Update References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <713043CE8B8E1348AF3C546DBE02C1B4107A7FD1@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4107A7FD1@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: 5011df3e2a27abcc044eaa15befcaa87 Sharon Chisholm wrote: > Hi > > I find the reference to 'on the wire' a bit confusing, so instead I > propose saying in section 3.2.5.2.1 the following: It made more sense before 802.11 > > The filter element is specified against the contents of the > wrapper and not the wrapper itself. See section 5 for > examples. How about: s/specified/applied/ > > Sharon Andy > > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, August 14, 2007 10:13 AM > To: Chisholm, Sharon (CAR:ZZ00); Netconf (E-mail) > Subject: Re: Pre-release 2 of Notification Update > > Sharon > > I raised the question of whether a filter would be applied to the event > as it would appear on the wire, or as it might appear in the datastore > (thinking of XPath roots and namespaces). Andy reported back, after a > hallway BoF with Martin > > '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..' > > I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 > "Conceptually, the filter is applied to the event notification as it > would appear on the wire and not to it as it might appear in the > conceptual NETCONF database." > > Tom Petch > > ----- Original Message ----- > From: "Sharon Chisholm" > To: "Netconf (E-mail)" > Sent: Wednesday, August 08, 2007 9:24 PM > Subject: Pre-release 2 of Notification Update > > > Hi > > I'm almost done the update (hopefully). Attached is a pre-release. > Please let me know if anything was incorrectly executed. > <> > > Disclaimers: > > 1. I have not validated much of the schema or examples 2. I got a bit > confused in the updates to section 5.2. These may still have issues. > 3. I have not done anything about replays in the future. The text > remains unchanged in this area. > 4. I need to double check that I have not missed updates. > 5. There were a few changes (mainly editorial) that I did not make for > specific reasons which I need to send an email to discuss. > 6. Not sure if using correct namespace in section 2.1.1.1. Andy said > what was there was wrong, but it validates for me and there was no > suggestions. I tried something else, but it didn't validate. > 7. There was a request to add description of how to define notification > instances, which has not been added, but there are now two examples (one > in replayComplete and one in the examples in section 5). Is this > sufficient? > 8. I have not validate that I am always using the correct The URI > string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) > > Sharon Chisholm > Nortel > 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: > > -- to unsubscribe send a message to netconf-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 Aug 23 03:44: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 1IO7Mp-0003qD-W7 for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 03:44:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO7Mo-00079W-Jo for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 03:44:35 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IO74p-000HEJ-1J for netconf-data@psg.com; Thu, 23 Aug 2007 07:25:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [69.147.64.88] (helo=smtp115.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IO74l-000HDp-NO for netconf@ops.ietf.org; Thu, 23 Aug 2007 07:25:57 +0000 Received: (qmail 84719 invoked from network); 23 Aug 2007 07:25:50 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 23 Aug 2007 07:25:50 -0000 X-YMail-OSG: v399ZSIVM1lG5bLBT91Mu1NU2XA7766BRGhAEUBMhcLgrda8 Message-ID: <46CD3619.90103@andybierman.com> Date: Thu, 23 Aug 2007 00:24:09 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: notification issues update (draft) 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: c0bedb65cce30976f0bf60a0a39edea4 Hi, There has been some off-line discussions with the people raising big concerns with the notification design. The following changes and decisions seem to reflect the widest consensus and the next revision (notification-09), due around Sept. 7, will (hopefully) reflect these changes/decisions: - the mandatory eventTime element will be added to the notification element, as per Martin's XSD fragment. - the agent must always accept close-session, even if delivering notifications. - the agent may accept more RPC operations during notification delivery, and will advertise a new capability (e.g., interleave) to indicate it supports this optional feature. - multiple calls to create-subscription should not be done. An agent should reject this request with a 'resource-denied' error if notifications are already being delivered. - if the agent does not support the interleave capability, and receives an RPC operation other than 'close-session', it should return a 'resource-denied' error. - notification filter parameters startTime and stopTime refer to the eventTime values of the notifications. - notification filters are applied to the notification element contents. - startTime in the future is an error. - stopTime in the future indicates the eventTime value for stopping notification delivery. (The agent exits notification delivery after this time passes and all notifications with timestamps before this time are delivered). - the replayComplete event type is renamed to notificationComplete. It is sent if stopTime is present, just before the agent returns to accepting all RPC operations (normal mode). - The agent will seamlessly transition from replayed notifications to notifications received after the create-subscription started, if stopTime is not present, or present but in the future. - if stopTime is not present, the notification delivery will continue until the session is terminated somehow: (close, kill, drop)-session. - there is no need for a 'now' parameter, since the eventTime element has been added to the notification. Clear as mud? If anyone has any strong objections to these decisions, they should send an email to this mailing list by August 26. thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 23 07:31: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 1IOAu9-00087k-Uj for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 07:31:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOAu8-0003Sq-JW for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 07:31:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOAeM-000DGB-8c for netconf-data@psg.com; Thu, 23 Aug 2007 11:14:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOAeJ-000DES-OL for netconf@ops.ietf.org; Thu, 23 Aug 2007 11:14:53 +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 l7NBElh08592 for ; Thu, 23 Aug 2007 11:14:48 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 issues update (draft) Date: Thu, 23 Aug 2007 07:14:32 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4107A84BC@zcarhxm2.corp.nortel.com> In-Reply-To: <46CD3619.90103@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notification issues update (draft) thread-index: AcflWhvvFZssmewLQ5iHpHLzFa8aPAAHHYQg References: <46CD3619.90103@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: 856eb5f76e7a34990d1d457d8e8e5b7f - the replayComplete event type is renamed to notificationComplete. It is sent if stopTime is present, just before the agent returns to accepting all RPC operations (normal mode). I'm not sure I agree with this one. This is the notification that gets sent after replayed notifications are sent and before real-time ones are sent (if applicable). Calling it notificationComplete would seem to imply something else. 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 Aug 23 07:58: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 1IOBKS-0003DF-E5 for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 07:58:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOBKS-0003sP-1X for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 07:58:24 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOBCG-000GkJ-4V for netconf-data@psg.com; Thu, 23 Aug 2007 11:49:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOBCD-000Gjs-JM for netconf@ops.ietf.org; Thu, 23 Aug 2007 11:49:54 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 343BF1B80C3; Thu, 23 Aug 2007 13:49:42 +0200 (CEST) Date: Thu, 23 Aug 2007 13:50:06 +0200 (CEST) Message-Id: <20070823.135006.152278665.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: notification issues update (draft) From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4107A84BC@zcarhxm2.corp.nortel.com> References: <46CD3619.90103@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4107A84BC@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: bb8f917bb6b8da28fc948aeffb74aa17 "Sharon Chisholm" wrote: > > > - the replayComplete event type is renamed to notificationComplete. > It is sent if stopTime is present, just before the agent returns > to accepting all RPC operations (normal mode). > > > I'm not sure I agree with this one. This is the notification that gets > sent after replayed notifications are sent and before real-time ones are > sent (if applicable). Calling it notificationComplete would seem to > imply something else. We discussed this in Chicago. There are two things that can happen: 1. when the last replayed notif has been sent, and the live feed starts. (replayComplete) 2. when a stopTime is given, and the last notif has been sent; after this the session switches back to normal command-response mode. (notificationsComplete) A manager needs to know when the session switches back to normal mode, so item 2 must be signalled. However, it has been argued that a manager doesn't care about item 1. /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 Aug 23 11:46: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 1IOEtM-00030G-Ci for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 11:46:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOEtL-0000kP-1D for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 11:46:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOEhl-000Cit-Bv for netconf-data@psg.com; Thu, 23 Aug 2007 15:34:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IOEhi-000CiU-BA for netconf@ops.ietf.org; Thu, 23 Aug 2007 15:34:39 +0000 Received: (qmail 65325 invoked from network); 23 Aug 2007 15:34:38 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 23 Aug 2007 15:34:37 -0000 X-YMail-OSG: AWbzffsVM1lrFwOHwCBxA9g1HjWhkWyT723c1tORlcqyVcpE Message-ID: <46CDA8A8.4060808@andybierman.com> Date: Thu, 23 Aug 2007 08:32:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: notification issues update (draft) References: <46CD3619.90103@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4107A84BC@zcarhxm2.corp.nortel.com> <20070823.135006.152278665.mbj@tail-f.com> In-Reply-To: <20070823.135006.152278665.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: 0fa76816851382eb71b0a882ccdc29ac Martin Bjorklund wrote: > "Sharon Chisholm" wrote: >> >> - the replayComplete event type is renamed to notificationComplete. >> It is sent if stopTime is present, just before the agent returns >> to accepting all RPC operations (normal mode). >> >> >> I'm not sure I agree with this one. This is the notification that gets >> sent after replayed notifications are sent and before real-time ones are >> sent (if applicable). Calling it notificationComplete would seem to >> imply something else. This event (see below) is not very interesting to the manager. > > We discussed this in Chicago. There are two things that can happen: > > 1. when the last replayed notif has been sent, and the live feed > starts. (replayComplete) > > 2. when a stopTime is given, and the last notif has been sent; > after this the session switches back to normal command-response > mode. (notificationsComplete) > > A manager needs to know when the session switches back to normal mode, > so item 2 must be signalled. However, it has been argued that a > manager doesn't care about item 1. Maybe it isn't clear to everyone that both conceptual events (replayComplete and notificationComplete) happen whenever replay is supported by the agent and requested by the manager. If startTime is present: 1) send zero or more notifications from the replay buffer (as requested) 2) replayComplete event occurs (not needed!!) 3a) If stopTime is in the past when create-subscription runs: - notificationComplete event occurs 3b) Else if stopTime is in the future: - agent waits until some time after stopTime, and generates all notifications that happened after and until eventTime >= stopTime. - notificationComplete event occurs 3c) Else if stopTime not present: - agent waits until session termination, and generates all notifications that happened after - there is no notificationComplete event in this case because the session is terminating If startTime is not present: 1) generate zero or more live notifications (eventTime >= now) until the session is terminated One more detail I left out (probably in the draft already) - If replay is not supported on a stream, then an error is returned if startTime or stopTime is present in > > > > /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 Aug 23 12:25: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 1IOFVB-0002av-2I for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 12:25:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOFVA-0001b3-LT for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 12:25:45 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOFLP-000GxG-Jo for netconf-data@psg.com; Thu, 23 Aug 2007 16:15:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOFLN-000Gws-3P for netconf@ops.ietf.org; Thu, 23 Aug 2007 16:15:38 +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 l7NGFWY08532; Thu, 23 Aug 2007 16:15:32 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 issues update (draft) Date: Thu, 23 Aug 2007 12:15:06 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4107A8A8D@zcarhxm2.corp.nortel.com> In-Reply-To: <20070823.135006.152278665.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notification issues update (draft) thread-index: Acfle8owP7stnJbtS82FXQUDSGpHkAADP1Xg References: <46CD3619.90103@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4107A84BC@zcarhxm2.corp.nortel.com> <20070823.135006.152278665.mbj@tail-f.com> From: "Sharon Chisholm" To: "Martin Bjorklund" , Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi Actually we do. I've just heard from a colleague on this and he says they need this notification to trigger that it is time to perform mark&delete resynch clean-ups.=20 Sharon -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Thursday, August 23, 2007 7:50 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ops.ietf.org Subject: Re: notification issues update (draft) "Sharon Chisholm" wrote: >=20 > > - the replayComplete event type is renamed to notificationComplete. > It is sent if stopTime is present, just before the agent returns > to accepting all RPC operations (normal mode). > >=20 > I'm not sure I agree with this one. This is the notification that gets > sent after replayed notifications are sent and before real-time ones=20 > are sent (if applicable). Calling it notificationComplete would seem=20 > to imply something else. We discussed this in Chicago. There are two things that can happen: 1. when the last replayed notif has been sent, and the live feed starts. (replayComplete) 2. when a stopTime is given, and the last notif has been sent; after this the session switches back to normal command-response mode. (notificationsComplete) A manager needs to know when the session switches back to normal mode, so item 2 must be signalled. However, it has been argued that a manager doesn't care about item 1. /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 Aug 23 12:52: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 1IOFv7-0004pq-KE for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 12:52:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOFv7-0002F5-3q for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 12:52:33 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOFlk-000JTc-Vf for netconf-data@psg.com; Thu, 23 Aug 2007 16:42:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IOFje-000JBR-L8 for netconf@ops.ietf.org; Thu, 23 Aug 2007 16:42:32 +0000 Received: (qmail 59512 invoked from network); 23 Aug 2007 16:40:41 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 23 Aug 2007 16:40:41 -0000 X-YMail-OSG: ZtcjOj0VM1nDh2MOG6tjeXcpRix2fzyVr7.zIkD917Q.V95aL0_MzQ77vaLvMesjuHiGW1AZej2EGLDv9c8IFjL2 Message-ID: <46CDB824.6050308@andybierman.com> Date: Thu, 23 Aug 2007 09:39:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sharon Chisholm CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: notification issues update (draft) References: <46CD3619.90103@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4107A84BC@zcarhxm2.corp.nortel.com> <20070823.135006.152278665.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B4107A8A8D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4107A8A8D@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: 41c17b4b16d1eedaa8395c26e9a251c4 Sharon Chisholm wrote: > Hi > > Actually we do. I've just heard from a colleague on this and he says > they need this notification to trigger that it is time to perform > mark&delete resynch clean-ups. Hmmm... the manager could do that based on eventTime, but whatever. So is it okay with everyone if we have both event types? > > Sharon Andy > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, August 23, 2007 7:50 AM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ops.ietf.org > Subject: Re: notification issues update (draft) > > "Sharon Chisholm" wrote: >> >> - the replayComplete event type is renamed to notificationComplete. >> It is sent if stopTime is present, just before the agent returns >> to accepting all RPC operations (normal mode). >> >> >> I'm not sure I agree with this one. This is the notification that gets > >> sent after replayed notifications are sent and before real-time ones >> are sent (if applicable). Calling it notificationComplete would seem >> to imply something else. > > We discussed this in Chicago. There are two things that can happen: > > 1. when the last replayed notif has been sent, and the live feed > starts. (replayComplete) > > 2. when a stopTime is given, and the last notif has been sent; > after this the session switches back to normal command-response > mode. (notificationsComplete) > > A manager needs to know when the session switches back to normal mode, > so item 2 must be signalled. However, it has been argued that a manager > doesn't care about item 1. > > > > /martin > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 23 12:54: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 1IOFx6-0006Zc-3q for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 12:54:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOFx5-0002XW-Lt for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 12:54:36 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOFqw-000K8Y-B8 for netconf-data@psg.com; Thu, 23 Aug 2007 16:48:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOFqs-000K89-Vh for netconf@ops.ietf.org; Thu, 23 Aug 2007 16:48:12 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 8722D1B80C3; Thu, 23 Aug 2007 18:48:08 +0200 (CEST) Date: Thu, 23 Aug 2007 18:48:33 +0200 (CEST) Message-Id: <20070823.184833.183040692.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: notification issues update (draft) From: Martin Bjorklund In-Reply-To: <46CDB824.6050308@andybierman.com> References: <20070823.135006.152278665.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B4107A8A8D@zcarhxm2.corp.nortel.com> <46CDB824.6050308@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: 0bc60ec82efc80c84b8d02f4b0e4de22 Andy Bierman wrote: > Sharon Chisholm wrote: > > Hi > > > > Actually we do. I've just heard from a colleague on this and he says > > they need this notification to trigger that it is time to perform > > mark&delete resynch clean-ups. > > Hmmm... the manager could do that based on eventTime, but whatever. Yes I don't quite understand what "mark&delete resynch clean-ups" means... why can't it be done with notificationComplete? > So is it okay with everyone if we have both event types? So notificationsComplete marks the switch back to normal mode, and replayComplete marks the end-of-buffered events. What if stopTime < now? Will you get both events? Or will you get replayComplete *only* when EOF on the log is reached? /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 Aug 23 13:12: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 1IOGEO-00064E-U0 for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 13:12:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOGEO-0003dY-GV for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 13:12:28 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOG4w-000Liq-NK for netconf-data@psg.com; Thu, 23 Aug 2007 17:02:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [69.147.64.95] (helo=smtp122.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOG4u-000LiV-9l for netconf@ops.ietf.org; Thu, 23 Aug 2007 17:02:41 +0000 Received: (qmail 36891 invoked from network); 23 Aug 2007 17:02:40 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 23 Aug 2007 17:02:39 -0000 X-YMail-OSG: kXpwIp8VM1nZoj4J3ruUokqq4q2HZRS82oZEIMYm5o44EuCc Message-ID: <46CDBD4B.1010105@andybierman.com> Date: Thu, 23 Aug 2007 10:00:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: notification issues update (draft) References: <20070823.135006.152278665.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B4107A8A8D@zcarhxm2.corp.nortel.com> <46CDB824.6050308@andybierman.com> <20070823.184833.183040692.mbj@tail-f.com> In-Reply-To: <20070823.184833.183040692.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: 9ed51c9d1356100bce94f1ae4ec616a9 Martin Bjorklund wrote: > Andy Bierman wrote: >> Sharon Chisholm wrote: >>> Hi >>> >>> Actually we do. I've just heard from a colleague on this and he says >>> they need this notification to trigger that it is time to perform >>> mark&delete resynch clean-ups. >> Hmmm... the manager could do that based on eventTime, but whatever. > > Yes I don't quite understand what "mark&delete resynch clean-ups" > means... why can't it be done with notificationComplete? I'm not that sure either, but I figure it's not important enough to argue over. Perhaps it refers to overlap in the replayed notifications stored on the manager? > >> So is it okay with everyone if we have both event types? > > So notificationsComplete marks the switch back to normal mode, and > replayComplete marks the end-of-buffered events. > > What if stopTime < now? Will you get both events? Or will you get > replayComplete *only* when EOF on the log is reached? Yes, you would get both events, so the meaning of replayComplete is not overloaded, and event-specific handlers do not have to be aware of the stopTime value at all. > > > /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 Aug 23 17:28: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 1IOKE1-0008HW-FP for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 17:28:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOKE0-0004Jq-3V for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 17:28:21 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOK5b-000MJl-7w for netconf-data@psg.com; Thu, 23 Aug 2007 21:19:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOK5Z-000MJR-0e for netconf@ops.ietf.org; Thu, 23 Aug 2007 21:19:38 +0000 Received: from unknown (HELO emailsmtp55.jnpr.net) ([172.24.18.132]) by smtpb.juniper.net with ESMTP; 23 Aug 2007 14:19:36 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 14:19:36 -0700 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: is a warning really an error? Date: Thu, 23 Aug 2007 14:19:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is a warning really an error? Thread-Index: Acfly04KbH+ifBQeRlm+05ikygkNjg== From: "Kent Watsen" To: X-OriginalArrivalTime: 23 Aug 2007 21:19:36.0457 (UTC) FILETIME=[4EAF1F90:01C7E5CB] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 All, The spec specifies that an can be returned to report a warning, but warnings generally do not terminate processing while errors do and are returned whenever a "request cannot be completed for any reason" To highlight the conflict, consider: 1. Is it possible for to return a warning using without signaling that the transaction failed? 2. Is it possible for to return a warning using without signaling that the error-options (stop-on-error, continue-on-error, rollback-on-error) were ignored? Given this ambiguity, should "warning" should be removed from the spec? Thanks, Kent -- Kent Watsen Software Architect Juniper Networks -- to unsubscribe send a message to netconf-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 Aug 23 18:10: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 1IOKse-0002ZQ-NS for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 18:10:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOKsd-0005Y8-GO for netconf-archive@lists.ietf.org; Thu, 23 Aug 2007 18:10:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOKkK-0000E8-PD for netconf-data@psg.com; Thu, 23 Aug 2007 22:01:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IOKkI-0000Dl-Ba for netconf@ops.ietf.org; Thu, 23 Aug 2007 22:01:43 +0000 Received: (qmail 71226 invoked from network); 23 Aug 2007 22:01:38 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 23 Aug 2007 22:01:37 -0000 X-YMail-OSG: Tj33ZCoVM1kNSnQ975qaZ5zP535rIMTJl8mTpxWfqJ5bujYj Message-ID: <46CE035C.1020600@andybierman.com> Date: Thu, 23 Aug 2007 14:59:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kent Watsen CC: netconf@ops.ietf.org Subject: Re: is a warning really an error? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Kent Watsen wrote: > All, > > The spec specifies that an can be returned to report a > warning, but warnings generally do not terminate processing while errors > do and are returned whenever a "request cannot be completed > for any reason" warnings cannot be returned with , but they can be returned with . The spec is sort of silent on the use of warnings, mostly because none are defined in the RFC. But the XSD for is correct, and there is no restriction on the setting of the error-severity field. I think it is okay to use 'warning' instead of 'error' for a pre-defined error condition, especially if the agent is ignoring or correcting for the error. It is not really okay to define new error-tag values, because the error-app-tag should be used instead, added to existing errors. > > To highlight the conflict, consider: > > 1. Is it possible for to return a warning using > without signaling that the transaction failed? If the reply contains only warnings and no errors, then it succeeded, but maybe not as intended. > > 2. Is it possible for to return a warning using > without signaling that the error-options (stop-on-error, > continue-on-error, rollback-on-error) were ignored? > > > Given this ambiguity, should "warning" should be removed from the spec? no -- it is not compliant to RFC 4741 to ignore the error-option parameter. A spec always has room for more clarifications, so I guess it could be more clear that if all the error-severity values are 'warning', then the operation did not fail. > > Thanks, > Kent > 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 Aug 24 13:18: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 1IOcnL-0004Yd-B6 for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 13:18:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOcnK-0007ij-0L for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 13:18:03 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOcfB-000P7g-W1 for netconf-data@psg.com; Fri, 24 Aug 2007 17:09:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IOcf9-000P7M-H6 for netconf@ops.ietf.org; Fri, 24 Aug 2007 17:09:36 +0000 Received: (qmail 18735 invoked from network); 24 Aug 2007 17:09:35 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2007 17:09:34 -0000 X-YMail-OSG: lk6xIEIVM1lJp03BvYxMGv3YK6WwU_.2D0Qz.k2BxUf4mQC8uvdHWq4d52RXYJ2Al0CAI84Z_1SPoZ53jO9jOmJM Message-ID: <46CF1068.9030505@andybierman.com> Date: Fri, 24 Aug 2007 10:07:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: IETF69 NETCONF WG minutes posted 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: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hi, The minutes for the IETF69 meeting are now available online: http://www3.ietf.org/proceedings/07jul/minutes/netconf.txt 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 Aug 24 14:41: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 1IOe6N-0007Mc-33 for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 14:41:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOe6L-0002SX-Ew for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 14:41:47 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOdyX-0007k5-Ke for netconf-data@psg.com; Fri, 24 Aug 2007 18:33:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOdyU-0007jW-4d for netconf@ops.ietf.org; Fri, 24 Aug 2007 18:33:40 +0000 Received: from pc6 (1Cust148.tnt9.lnd4.gbr.da.uu.net [62.188.138.148]) by ranger.systems.pipex.net (Postfix) with SMTP id 41FBEE000564; Fri, 24 Aug 2007 19:33:32 +0100 (BST) Message-ID: <023301c7e674$146e0d60$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" , "Sharon Chisholm" Cc: "Netconf (E-mail)" References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <713043CE8B8E1348AF3C546DBE02C1B4107A7FD1@zcarhxm2.corp.nortel.com> <46CC8AB6.3060208@andybierman.com> Subject: Re: Pre-release 2 of Notification Update Date: Fri, 24 Aug 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: -104.0 (---------------------------------------------------) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Neither of these seem quite to nail down my concern, which is that we are not specifying how the notifications are stored in whatever database or log they may or not be stored in, which may or may not be specified in some future time in a standards or proprietary format. Rather, it is the format that is used in the Notification protocol that matters for filtering, and I was using 'on the wire' to refer to that protocol format. Something like "The filter is applied to the notification as it would be transmitted as part of an event stream" If the use of "would be transmitted" is too cryptic, then I would insert - but might not be as a result of a filter being applied - after transmitted Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Sharon Chisholm" Cc: "Netconf (E-mail)" Sent: Wednesday, August 22, 2007 9:12 PM Subject: Re: Pre-release 2 of Notification Update > Sharon Chisholm wrote: > > Hi > > > > I find the reference to 'on the wire' a bit confusing, so instead I > > propose saying in section 3.2.5.2.1 the following: > > It made more sense before 802.11 > > > > > The filter element is specified against the contents of the > > wrapper and not the wrapper itself. See section 5 for > > examples. > > How about: > > s/specified/applied/ > > > > > > Sharon > > Andy > > > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Tuesday, August 14, 2007 10:13 AM > > To: Chisholm, Sharon (CAR:ZZ00); Netconf (E-mail) > > Subject: Re: Pre-release 2 of Notification Update > > > > Sharon > > > > I raised the question of whether a filter would be applied to the event > > as it would appear on the wire, or as it might appear in the datastore > > (thinking of XPath roots and namespaces). Andy reported back, after a > > hallway BoF with Martin > > > > '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..' > > > > I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 > > "Conceptually, the filter is applied to the event notification as it > > would appear on the wire and not to it as it might appear in the > > conceptual NETCONF database." > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Sharon Chisholm" > > To: "Netconf (E-mail)" > > Sent: Wednesday, August 08, 2007 9:24 PM > > Subject: Pre-release 2 of Notification Update > > > > > > Hi > > > > I'm almost done the update (hopefully). Attached is a pre-release. > > Please let me know if anything was incorrectly executed. > > <> > > > > Disclaimers: > > > > 1. I have not validated much of the schema or examples 2. I got a bit > > confused in the updates to section 5.2. These may still have issues. > > 3. I have not done anything about replays in the future. The text > > remains unchanged in this area. > > 4. I need to double check that I have not missed updates. > > 5. There were a few changes (mainly editorial) that I did not make for > > specific reasons which I need to send an email to discuss. > > 6. Not sure if using correct namespace in section 2.1.1.1. Andy said > > what was there was wrong, but it validates for me and there was no > > suggestions. I tried something else, but it didn't validate. > > 7. There was a request to add description of how to define notification > > instances, which has not been added, but there are now two examples (one > > in replayComplete and one in the examples in section 5). Is this > > sufficient? > > 8. I have not validate that I am always using the correct The URI > > string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) > > > > Sharon Chisholm > > Nortel > > 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: > > > > > > > -- > to 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 Aug 24 15:03: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 1IOeRL-0000XY-6J for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 15:03:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOeRJ-00031c-Sg for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 15:03:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOeHQ-0009wG-VL for netconf-data@psg.com; Fri, 24 Aug 2007 18:53:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IOeHO-0009vw-Ab for netconf@ops.ietf.org; Fri, 24 Aug 2007 18:53:11 +0000 Received: (qmail 95008 invoked from network); 24 Aug 2007 18:53:05 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2007 18:53:05 -0000 X-YMail-OSG: t7DZ2uUVM1mxCero4GzShQ6v.aeurj_rCzMCWHfh9IIerpRovXAonQ1hN7Qxb_xCr5sqa9wxMI8LI2RJn0Mp3lRC Message-ID: <46CF28AB.2010007@andybierman.com> Date: Fri, 24 Aug 2007 11:51:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "tom.petch" CC: Sharon Chisholm , "Netconf (E-mail)" Subject: Re: Pre-release 2 of Notification Update References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <713043CE8B8E1348AF3C546DBE02C1B4107A7FD1@zcarhxm2.corp.nortel.com> <46CC8AB6.3060208@andybierman.com> <023301c7e674$146e0d60$0601a8c0@pc6> In-Reply-To: <023301c7e674$146e0d60$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: -4.0 (----) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a tom.petch wrote: > Neither of these seem quite to nail down my concern, which is that we are not > specifying how the notifications are stored in whatever database or log they may > or not be stored in, which may or may not be specified in some future time in a > standards or proprietary format. > But the WG decided it wanted a "tail" and "tail -f" type of interface, done with a new RPC method (create-subscription). The idea of justing having a log that could be retrieved with was discussed several times, and rejected. I don't see why you could not define a data model that had stored elements in it. > Rather, it is the format that is used in the Notification protocol that matters > for filtering, and I was using 'on the wire' to refer to that protocol format. > > Something like "The filter is applied to the notification as it would be > transmitted as part of an event stream" > > If the use of "would be transmitted" is too cryptic, then I would insert - but > might not be as a result of a filter being applied - after transmitted > The filter seems fine to me being defined against conceptual XML instances. A filter is defined with XML or Xpath, so there is no ambiguity about internal or on-the-wire formats. > Tom Petch Andy > > ----- Original Message ----- > From: "Andy Bierman" > To: "Sharon Chisholm" > Cc: "Netconf (E-mail)" > Sent: Wednesday, August 22, 2007 9:12 PM > Subject: Re: Pre-release 2 of Notification Update > > >> Sharon Chisholm wrote: >>> Hi >>> >>> I find the reference to 'on the wire' a bit confusing, so instead I >>> propose saying in section 3.2.5.2.1 the following: >> It made more sense before 802.11 >> >>> The filter element is specified against the contents of the >>> wrapper and not the wrapper itself. See section 5 for >>> examples. >> How about: >> >> s/specified/applied/ >> >> >>> Sharon >> Andy >> >>> -----Original Message----- >>> From: tom.petch [mailto:cfinss@dial.pipex.com] >>> Sent: Tuesday, August 14, 2007 10:13 AM >>> To: Chisholm, Sharon (CAR:ZZ00); Netconf (E-mail) >>> Subject: Re: Pre-release 2 of Notification Update >>> >>> Sharon >>> >>> I raised the question of whether a filter would be applied to the event >>> as it would appear on the wire, or as it might appear in the datastore >>> (thinking of XPath roots and namespaces). Andy reported back, after a >>> hallway BoF with Martin >>> >>> '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..' >>> >>> I would like to see that explicit. I suggest adding to 3.2.5.2.1 para 1 >>> "Conceptually, the filter is applied to the event notification as it >>> would appear on the wire and not to it as it might appear in the >>> conceptual NETCONF database." >>> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Sharon Chisholm" >>> To: "Netconf (E-mail)" >>> Sent: Wednesday, August 08, 2007 9:24 PM >>> Subject: Pre-release 2 of Notification Update >>> >>> >>> Hi >>> >>> I'm almost done the update (hopefully). Attached is a pre-release. >>> Please let me know if anything was incorrectly executed. >>> <> >>> >>> Disclaimers: >>> >>> 1. I have not validated much of the schema or examples 2. I got a bit >>> confused in the updates to section 5.2. These may still have issues. >>> 3. I have not done anything about replays in the future. The text >>> remains unchanged in this area. >>> 4. I need to double check that I have not missed updates. >>> 5. There were a few changes (mainly editorial) that I did not make for >>> specific reasons which I need to send an email to discuss. >>> 6. Not sure if using correct namespace in section 2.1.1.1. Andy said >>> what was there was wrong, but it validates for me and there was no >>> suggestions. I tried something else, but it didn't validate. >>> 7. There was a request to add description of how to define notification >>> instances, which has not been added, but there are now two examples (one >>> in replayComplete and one in the examples in section 5). Is this >>> sufficient? >>> 8. I have not validate that I am always using the correct The URI >>> string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER) >>> >>> Sharon Chisholm >>> Nortel >>> 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: >>> >>> >> >> -- >> to 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 Aug 24 18:34: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 1IOhjK-0006Ny-Al for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 18:34:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOhjI-0001iL-WD for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 18:34:14 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOhcb-0002l3-3l for netconf-data@psg.com; Fri, 24 Aug 2007 22:27:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [207.17.137.120] (helo=smtpa.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOhcY-0002kp-Fn for netconf@ops.ietf.org; Fri, 24 Aug 2007 22:27:15 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by smtpa.juniper.net with ESMTP; 24 Aug 2007 15:27:15 -0700 X-IronPort-AV: i="4.19,305,1183359600"; d="scan'208"; a="66023931:sNHT37987596" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 15:27:13 -0700 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: is a warning really an error? Date: Fri, 24 Aug 2007 15:27:12 -0700 Message-ID: In-Reply-To: <46CE035C.1020600@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is a warning really an error? Thread-Index: Acfl0UJumWHckw5FSya/HhjIJu83+AAyONeA References: <46CE035C.1020600@andybierman.com> From: "Kent Watsen" To: "Andy Bierman" Cc: X-OriginalArrivalTime: 24 Aug 2007 22:27:13.0714 (UTC) FILETIME=[EB692920:01C7E69D] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 > warnings cannot be returned with , > but they can be returned with true, but my issue is with the =20 > > To highlight the conflict, consider: > > > > 1. Is it possible for to return a warning using > > without signaling that the transaction failed? >=20 > If the reply contains only warnings and no errors, > then it succeeded, but maybe not as intended. Section 8.3.4.1 says:=20 In the Description section:=20 If the device is unable to commit *all of the changes* in the candidate configuration datastore, then the running configuration MUST remain unchanged.=20 In the Negative Response section: An element is included in the if the request *cannot be completed* for any reason.=20 Thus, I conclude that receiving *any* means that the request was not completed and hence the datastore remains unchanged... Perhaps this is where the spec can be clarified by adding to the Negative Response section the following: "However, if all the element(s) are warnings, then the client should assume that the target datastore was modified" > > 2. Is it possible for to return a warning using > > without signaling that the error-options (stop-on-error, > > continue-on-error, rollback-on-error) were ignored? You didn't respond to this one, but I'll go ahead and point out that section 7.2 says in the Negative Response section: An response is sent if the request cannot be completed for any reason. Thus, I conclude that if it didn't "complete" then it must have "stopped" and therefore the specified error-option ("stop-on-error" being the default) was applied... Perhaps this is where the spec can be clarified by adding to the Negative Response section the following: "However, if all the element(s) are warnings, then the client should assume that the processing did not stop and that the error-option was not applied" > A spec always has room for more clarifications, so I guess it > could be more clear that if all the error-severity values > are 'warning', then the operation did not fail. Yes, it would also be good to add to section 4.3 Thanks, Kent -- Kent Watsen Software Architect Juniper Networks -- to unsubscribe send a message to netconf-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 Aug 24 19: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 1IOiJ0-0005Wr-MU for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 19:11:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOiIz-0002lK-D3 for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 19:11:06 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOiBj-0005gT-0r for netconf-data@psg.com; Fri, 24 Aug 2007 23:03:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IOiBg-0005fu-8o for netconf@ops.ietf.org; Fri, 24 Aug 2007 23:03:33 +0000 Received: (qmail 17630 invoked from network); 24 Aug 2007 23:03:28 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 24 Aug 2007 23:03:27 -0000 X-YMail-OSG: EQ_LJAcVM1ldhTYQS4VefN8A7TL.BQtSzAp_Bb2Uaem5mRrA Message-ID: <46CF6359.6020101@andybierman.com> Date: Fri, 24 Aug 2007 16:01:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kent Watsen CC: netconf@ops.ietf.org Subject: Re: is a warning really an error? References: <46CE035C.1020600@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Kent Watsen wrote: > >> warnings cannot be returned with , >> but they can be returned with > > true, but my issue is with the The rpc-error element contains the error-severity element. A 'warning' is just an rpc-error with an error-severity of 'warning'. There is one report template for errors and warnings. > > > > >>> To highlight the conflict, consider: >>> >>> 1. Is it possible for to return a warning using >>> without signaling that the transaction failed? >> If the reply contains only warnings and no errors, >> then it succeeded, but maybe not as intended. > > Section 8.3.4.1 says: > > In the Description section: > If the device is unable to commit *all of the changes* in the > candidate configuration datastore, then the running > configuration > MUST remain unchanged. > > In the Negative Response section: > An element is included in the if > the request *cannot be completed* for any reason. > > Thus, I conclude that receiving *any* means that the request > was not completed and hence the datastore remains unchanged... Perhaps > this is where the spec can be clarified by adding to the Negative > Response section the following: I think you are reading the document too literally. > > "However, if all the element(s) are warnings, then > the client should assume that the target datastore was > modified" You can add this to the issue tracker for RFC 4741 if you want. > > > > >>> 2. Is it possible for to return a warning using >>> without signaling that the error-options (stop-on-error, >>> continue-on-error, rollback-on-error) were ignored? > > You didn't respond to this one, but I'll go ahead and point out that > section 7.2 says in the Negative Response section: > > An response is sent if the request cannot be > completed > for any reason. > > Thus, I conclude that if it didn't "complete" then it must have > "stopped" and therefore the specified error-option ("stop-on-error" > being the default) was applied... Perhaps this is where the spec can be > clarified by adding to the Negative Response section the following: This parameter is for requesting certain error handling behavior. If an agent receives an unsupported option, then the operation-not-supported error-tag is returned right away. The error-option semantics are kind of implementation dependent. Rather than ramble on about esoteric features of data modeling frameworks and agent callback architectures, let's just say that the behavior of continue-on-error is hard to explain, let alone implement the same way twice. I interpret this parameter to apply to the 'apply' phase of the conceptual edit-config operation. That means the entire PDU has to validate (as much as the instrumentation checks for) before any of the PDU is applied for real. The apply phase can fail due to resource-denied errors for example. IMO, the continue-on-error does not require the agent to accept bad parameter values (i.e., validation phase fails). You can't get an embedded software engineer to write code that can knowingly crash the device by allowing certain wrong parameter values. > > "However, if all the element(s) are warnings, then > the client should assume that the processing did not stop and > that the error-option was not applied" What about continue-on-error? This is intended to go with the partial operation error report. IMO, there error-option is always 'applied' if the agent accepts the operation. This is probably too simplistic for distributed or modular agent implementations that only partially support a given option (like rollback-on-error). Clearly you have figured out that data-model dependent error handling for the NETCONF protocol is largely undefined in RFC 4741. This is partly by design, and partly because NETCONF data modeling is largely undefined. (Insert plug here for draft-bierman-ncx-smi-00.txt ;-) > > > > >> A spec always has room for more clarifications, so I guess it >> could be more clear that if all the error-severity values >> are 'warning', then the operation did not fail. > > Yes, it would also be good to add to section 4.3 It was a mistake for us to put the 'Severity' field into the ad-hoc template in RFC 4741, Appendix A. This should have been a dynamic field, which could be defined for specific RPC methods, like create-subscription. This 'feature' should not be used without guidelines of course. For example, if the parameter was for some resource request, and the agent granted a lowered resource value instead of rejecting the entire request, this would be a good use case for a warning. > > > Thanks, > Kent 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 Aug 24 19:59: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 1IOj3m-0001qm-61 for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 19:59:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOj3k-0003gF-Vx for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 19:59:26 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOiuq-0009B0-2Y for netconf-data@psg.com; Fri, 24 Aug 2007 23:50:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [207.17.137.119] (helo=smtpb.juniper.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOiun-0009Ae-K9 for netconf@ops.ietf.org; Fri, 24 Aug 2007 23:50:10 +0000 Received: from unknown (HELO emailsmtp55.jnpr.net) ([172.24.18.132]) by smtpb.juniper.net with ESMTP; 24 Aug 2007 16:50:09 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 16:50:09 -0700 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: is a warning really an error? Date: Fri, 24 Aug 2007 16:50:08 -0700 Message-ID: In-Reply-To: <46CF6359.6020101@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is a warning really an error? Thread-Index: Acfmov8HZcMw10/WRtuEjhFBbpUQYgABYYAg References: <46CE035C.1020600@andybierman.com> <46CF6359.6020101@andybierman.com> From: "Kent Watsen" To: "Andy Bierman" Cc: X-OriginalArrivalTime: 24 Aug 2007 23:50:09.0137 (UTC) FILETIME=[80FE7610:01C7E6A9] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > I think you are reading the document too literally. Yes, I tend to read specifications that way ;^) > You can add this to the issue tracker for RFC 4741 if you want. I will add all of these items to the issue tracker > Clearly you have figured out that data-model dependent error handling > for the NETCONF protocol is largely undefined in RFC 4741. > This is partly by design, and partly because NETCONF data modeling > is largely undefined. I don't see this as being dependent on the data-model as I'm only caring if the target datastore was modified on not > (Insert plug here for draft-bierman-ncx-smi-00.txt ;-) Ever so subtle! ;) Best, Kent -- Kent Watsen Software Architect Juniper Networks -- to unsubscribe send a message to netconf-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 Aug 24 20:07: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 1IOjBm-0000ks-GL for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 20:07:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOjBl-0003vO-9e for netconf-archive@lists.ietf.org; Fri, 24 Aug 2007 20:07:42 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IOj6s-000ABt-17 for netconf-data@psg.com; Sat, 25 Aug 2007 00:02:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IOj6p-000ABe-FZ for netconf@ops.ietf.org; Sat, 25 Aug 2007 00:02:36 +0000 Received: (qmail 52233 invoked from network); 25 Aug 2007 00:02:35 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 25 Aug 2007 00:02:34 -0000 X-YMail-OSG: k9VwYPsVM1kMkHdJcXCwku2AyKct1e_PZqEIma5jSCjD7Cdp Message-ID: <46CF7134.9090306@andybierman.com> Date: Fri, 24 Aug 2007 17:00:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kent Watsen CC: netconf@ops.ietf.org Subject: Re: is a warning really an error? References: <46CE035C.1020600@andybierman.com> <46CF6359.6020101@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Kent Watsen wrote: > > >> I think you are reading the document too literally. > > Yes, I tend to read specifications that way ;^) > > >> You can add this to the issue tracker for RFC 4741 if you want. > > I will add all of these items to the issue tracker > > >> Clearly you have figured out that data-model dependent error handling >> for the NETCONF protocol is largely undefined in RFC 4741. >> This is partly by design, and partly because NETCONF data modeling >> is largely undefined. > > I don't see this as being dependent on the data-model as I'm only caring > if the target datastore was modified on not The partial-operation error-tag is intended to provide this information. if any values are returned, then the target was modified. Partial-operation is intended to be included in addition to the primary error-tag report(s). > > >> (Insert plug here for draft-bierman-ncx-smi-00.txt ;-) > > Ever so subtle! ;) > > > Best, > Kent 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 Aug 27 07:14: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 1IPcXn-0004S6-Ct for netconf-archive@lists.ietf.org; Mon, 27 Aug 2007 07:14:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPcXl-0006GH-T5 for netconf-archive@lists.ietf.org; Mon, 27 Aug 2007 07:14:07 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPcLo-000Pbd-AV for netconf-data@psg.com; Mon, 27 Aug 2007 11:01:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPcLl-000PbA-Dq for netconf@ops.ietf.org; Mon, 27 Aug 2007 11:01:42 +0000 Received: from pc6 (1Cust210.tnt14.lnd4.gbr.da.uu.net [62.188.143.210]) by astro.systems.pipex.net (Postfix) with SMTP id 8AA15E00047E; Mon, 27 Aug 2007 12:01:26 +0100 (BST) Message-ID: <00df01c7e890$6df73280$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" Cc: "Sharon Chisholm" , "Netconf \(E-mail\)" References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <713043CE8B8E1348AF3C546DBE02C1B4107A7FD1@zcarhxm2.corp.nortel.com> <46CC8AB6.3060208@andybierman.com> <023301c7e674$146e0d60$0601a8c0@pc6> <46CF28AB.2010007@andybierman.com> Subject: Re: Pre-release 2 of Notification Update Date: Mon, 27 Aug 2007 11:53:44 +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: -104.0 (---------------------------------------------------) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 ----- Original Message ----- From: "Andy Bierman" To: "tom.petch" Cc: "Sharon Chisholm" ; "Netconf (E-mail)" Sent: Friday, August 24, 2007 8:51 PM Subject: Re: Pre-release 2 of Notification Update > > The filter seems fine to me being defined against > conceptual XML instances. A filter is defined > with XML or Xpath, so there is no ambiguity about > internal or on-the-wire formats. > Andy If you do not say whether the filter is applied to what is on the wire, eg to lift Martin's example, 2007-08-17T08:56:05 3 in which at least part of the XML node structure is defined in the -notification I-D: or whether the filter is applied to some internal format where exactly the same XML elements may appear in a completely different structure, then my word for that is ambiguity, which may lead to a lack of interoperability. Which I would like to eliminate The current proposed wording talks of without saying in which XML documents the element appears and where it appears is what I would like nailed down. Tom Petch > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 27 08:13: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 1IPdTQ-00056M-95 for netconf-archive@lists.ietf.org; Mon, 27 Aug 2007 08:13:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPdTO-0007C2-Uk for netconf-archive@lists.ietf.org; Mon, 27 Aug 2007 08:13:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPdHT-0004Gm-4z for netconf-data@psg.com; Mon, 27 Aug 2007 12:01:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IPdHQ-0004GI-2w for netconf@ops.ietf.org; Mon, 27 Aug 2007 12:01:17 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D87E120489 for ; Mon, 27 Aug 2007 14:01:13 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-7c-46d2bd09c2c6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C748E20712 for ; Mon, 27 Aug 2007 14:01:13 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 14:01:13 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 14:01:13 +0200 Message-ID: <46D2BD08.8050407@ericsson.com> Date: Mon, 27 Aug 2007 14:01:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: Notification #9: replay in the future consensus point References: <46C49AE9.5000000@andybierman.com> <20070816.215419.88144443.mbj@tail-f.com> <46C510ED.4060505@andybierman.com> <20070817.085820.267376660.mbj@tail-f.com> <46C5E533.7070501@andybierman.com> In-Reply-To: <46C5E533.7070501@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 12:01:13.0073 (UTC) FILETIME=[F6C36E10:01C7E8A1] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Hello, I support inclusion of eventTime as an element in the notification. Balazs Andy Bierman wrote: > Attn WG: > > Are there any objections to adding 'eventTime' to the notification > message, as described by Martin? > > Andy > >> Andy Bierman wrote: >>> Martin Bjorklund wrote: >>>> I think that in order to make replay interopable, we need to add the >>>> eventTime to the notifications. Here are two small modifications to >>>> the XSD that will allow this: >>>> >>>> As an attribute: >>>> >>>> >>>> >>>> >>>> >>>> or as an element: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> Which namespace would the 'eventTime' element be defined in? >>> Wouldn't it be different for every element definition? >> >> No. >> >>> If it was an attribute in the element, >>> it would be in the same namespace as that element. >> >> If it's defined the way I wrote above, the eventTime element is in >> the same namespace as 'notification', >> i.e. "urn:ietf:params:xml:ns:netmod:notification". An example of an >> notification on the wire: >> >> > xmlns:ncn="urn:ietf:params:xml:ns:netconf:notification:1.0"> >> >> 2007-08-17T08:56:05 >> 3 >> >> >> >> >> /martin >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> > > > -- > to 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 Aug 28 05:29: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 1IPxNe-0007Yc-43 for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 05:29:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPxNc-0005Bu-OE for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 05:29:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPxBT-000EqE-H2 for netconf-data@psg.com; Tue, 28 Aug 2007 09:16:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPxBR-000Epn-3m for netconf@ops.ietf.org; Tue, 28 Aug 2007 09:16:26 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 66A4C1B80C3 for ; Tue, 28 Aug 2007 11:16:21 +0200 (CEST) Date: Tue, 28 Aug 2007 11:16:57 +0200 (CEST) Message-Id: <20070828.111657.219708635.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: replayLogStartTime From: Martin Bjorklund 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: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi, We briefly talked about this in Chicago. The draft says, about replayLogStartTime: The timestamp of the earliest available notification in the log used to support the replay function. This object MUST be present if replay is supported. What should this timestamp be if there are no entries in the log? Since there's already a replaySupport element, which indicates if the stream supports replay, I suggest that the replayLogStartTime should not be present if there are no entries in the log. The text could maybe be changed to The timestamp of the earliest available notification in the log used to support the replay function. This object MUST be present if replay is supported and there are entires in the log. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Aug 28 10:55: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 1IQ2Tx-0002y8-39 for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 10:55:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ2Tv-0004p7-NO for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 10:55:53 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IQ2CE-000Ag5-CC for netconf-data@psg.com; Tue, 28 Aug 2007 14:37:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IQ2CB-000Afl-Kf for netconf@ops.ietf.org; Tue, 28 Aug 2007 14:37:33 +0000 Received: (qmail 78412 invoked from network); 28 Aug 2007 14:37:31 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 28 Aug 2007 14:37:31 -0000 X-YMail-OSG: 7vbc1sIVM1kqQqSyK0IaZTvUiyrmkWlj.tlfNtxG_OBwomI5AyqZkvw3x0VRvp68wREUk.lJLE8tfZ2PLN.N3JoJ Message-ID: <46D432C1.6050106@andybierman.com> Date: Tue, 28 Aug 2007 07:35:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: replayLogStartTime References: <20070828.111657.219708635.mbj@tail-f.com> In-Reply-To: <20070828.111657.219708635.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: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Martin Bjorklund wrote: > Hi, > > We briefly talked about this in Chicago. > > The draft says, about replayLogStartTime: > > The timestamp of the earliest available notification in the log > used to support the replay function. This object MUST be present > if replay is supported. > > What should this timestamp be if there are no entries in the log? > > Since there's already a replaySupport element, which indicates if the > stream supports replay, I suggest that the replayLogStartTime should > not be present if there are no entries in the log. The text could > maybe be changed to > > The timestamp of the earliest available notification in the log > used to support the replay function. This object MUST be present > if replay is supported and there are entires in the log. > What is the purpose of this timestamp within the overall system? Is the manager supposed to check this object before every call to create-subscription? The intended algorithm should be in the draft, since the author obviously has one in mind. I have some concern about an object instance that comes and goes, and keeps changing, because of the complexity on the agent and manager. Does this place implementation restrictions on the log? Do entries always have to be added with ever-increasing eventTime values? This may be difficult if multiple sub-agents feed the log, and the timestamp is not centrally generated. I.e., can replayLogStartTime ever go backwards? Can it disappear and come back with a lower value? On the other hand, a static timestamp representing the file creation time of the log is not very useful for picking optimal startTime values. (BTW, how come there are all these bells and whistles for replay, but no switch to actually turn it on or off? Oh yeah, that's configuration, so it's out of scope ;-) > > /martin Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Aug 28 14:42: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 1IQ61B-0002vm-L4 for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 14:42:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ61A-0003rV-9r for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 14:42:25 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IQ5kr-0000un-4c for netconf-data@psg.com; Tue, 28 Aug 2007 18:25:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IQ5kn-0000uM-SZ for netconf@ops.ietf.org; Tue, 28 Aug 2007 18:25:31 +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 l7SIPM505666; Tue, 28 Aug 2007 18:25:22 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: replayLogStartTime Date: Tue, 28 Aug 2007 14:25:21 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4108D7A35@zcarhxm2.corp.nortel.com> In-Reply-To: <46D432C1.6050106@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: replayLogStartTime Thread-Index: AcfphGvoO/qBCkYaRyaOrNgQ/dCBcwAG5FYQ References: <20070828.111657.219708635.mbj@tail-f.com> <46D432C1.6050106@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , "Martin Bjorklund" Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi This timestamp helps differentiate the cases that there are no logs in the log for a particular time period and there were no logs generated for that period. The replayed events start at 2pm, is that because the log start them or there were no events between 1 and 2, for example. We have seen two designs of this object - present only when replay is supported - always present, but with a particular value when replay isn't supported Back when we could replay the future, the latter was the better option since it was possible to just return 'now' as the value while replay is supported to only support future replays. Now, I could go either ways. I know that in the past not all SNMP tools faired well with holes. I expect XML tools to fair better. The important thing is to be clear in whichever we choose. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, August 28, 2007 10:36 AM To: Martin Bjorklund Cc: netconf@ops.ietf.org Subject: Re: replayLogStartTime Martin Bjorklund wrote: > Hi, >=20 > We briefly talked about this in Chicago. >=20 > The draft says, about replayLogStartTime: >=20 > The timestamp of the earliest available notification in the log > used to support the replay function. This object MUST be present > if replay is supported. >=20 > What should this timestamp be if there are no entries in the log? =20 >=20 > Since there's already a replaySupport element, which indicates if the=20 > stream supports replay, I suggest that the replayLogStartTime should=20 > not be present if there are no entries in the log. The text could=20 > maybe be changed to >=20 > The timestamp of the earliest available notification in the log > used to support the replay function. This object MUST be present > if replay is supported and there are entires in the log. >=20 What is the purpose of this timestamp within the overall system? Is the manager supposed to check this object before every call to create-subscription? The intended algorithm should be in the draft, since the author obviously has one in mind. I have some concern about an object instance that comes and goes, and keeps changing, because of the complexity on the agent and manager. Does this place implementation restrictions on the log? Do entries always have to be added with ever-increasing eventTime values? This may be difficult if multiple sub-agents feed the log, and the timestamp is not centrally generated. I.e., can replayLogStartTime ever go backwards? Can it disappear and come back with a lower value? On the other hand, a static timestamp representing the file creation time of the log is not very useful for picking optimal startTime values. (BTW, how come there are all these bells and whistles for replay, but no switch to actually turn it on or off? Oh yeah, that's configuration, so it's out of scope ;-) >=20 > /martin Andy >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=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 Tue Aug 28 15:01: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 1IQ6Jo-0002cH-Co for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 15:01:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ6Jn-0004wA-5d for netconf-archive@lists.ietf.org; Tue, 28 Aug 2007 15:01:40 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IQ68Q-0002qF-Sq for netconf-data@psg.com; Tue, 28 Aug 2007 18:49:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IQ68L-0002pc-3C for netconf@ops.ietf.org; Tue, 28 Aug 2007 18:49:50 +0000 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 776A11B80CA; Tue, 28 Aug 2007 20:49:46 +0200 (CEST) Date: Tue, 28 Aug 2007 20:50:22 +0200 (CEST) Message-Id: <20070828.205022.106474902.mbj@tail-f.com> To: schishol@nortel.com Cc: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: replayLogStartTime From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4108D7A35@zcarhxm2.corp.nortel.com> References: <20070828.111657.219708635.mbj@tail-f.com> <46D432C1.6050106@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4108D7A35@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: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 "Sharon Chisholm" wrote: > Hi > > This timestamp helps differentiate the cases that there are no logs in > the log for a particular time period and there were no logs generated > for that period. The replayed events start at 2pm, is that because the > log start them or there were no events between 1 and 2, for example. > > We have seen two designs of this object > - present only when replay is supported > - always present, but with a particular value when replay isn't > supported > > Back when we could replay the future, the latter was the better option > since it was possible to just return 'now' as the value while replay is > supported to only support future replays. > > Now, I could go either ways. I know that in the past not all SNMP tools > faired well with holes. I expect XML tools to fair better. The important > thing is to be clear in whichever we choose. And the current text isn't very clear, since it says The timestamp of the earliest available notification in the log so what happens if there is no such notification at all? /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 Aug 30 17:34: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 1IQrfF-0000pd-MZ for netconf-archive@lists.ietf.org; Thu, 30 Aug 2007 17:34:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQrfE-0007lc-Eu for netconf-archive@lists.ietf.org; Thu, 30 Aug 2007 17:34:57 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IQrVz-000JGf-Ov for netconf-data@psg.com; Thu, 30 Aug 2007 21:25:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [216.148.227.152] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IQmNX-000K0e-PY for netconf@ops.ietf.org; Thu, 30 Aug 2007 15:56:21 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc12) with SMTP id <20070830155618m1200dgtque>; Thu, 30 Aug 2007 15:56:19 +0000 From: "David Harrington" To: "'Netconf \(E-mail\)'" Subject: partial locking Date: Thu, 30 Aug 2007 11:56:20 -0400 Message-ID: <029401c7eb1e$4f4de640$6702a8c0@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: AcfrHk6iX+L2UFNeRteVvM7KzZQXiw== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi, For partial locking, since the lock applies not only to Netconf but to other NM interfaces as well, it is imperative that the managed entity understand just what **instrumentation** is being partially locked, not just what Netconf data model subset is being partially locked. In SNMP, we use strings to identify a "naming scope" - a community or a context, and it is imperative that the agent understand what data is in the community or the context. It is the implementation of the managed entity that determines just what distinct communities or contexts exist within the managed entity, and an agent knows about the data subsets, even if there are dynamic hardware changes that affect the subsets. The manager can learn what managed objects are in a community or context by querying the agent. I think the same agent-centric determination of named data partitions will be required if the partial locking will apply to multiple NM interfaces that use different data modeling interfaces. In SNMP and/or Netconf, the manager/operatorcan also dynamically specify subtrees of data or "view families" or XPath expressions. I think we need to identify whether and how this type of dynamic subset of data might be locked by partial locking, whether such dynamically-specified locks apply across multiple NM interfaces, and how the managed entity knows which non-Netconf data to partially lock. David Harrington dbharrington@comcast.net ietfdbh@comcast.net -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 30 19:48: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 1IQtkG-0003QM-OG for netconf-archive@lists.ietf.org; Thu, 30 Aug 2007 19:48:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQtkF-0001mr-DX for netconf-archive@lists.ietf.org; Thu, 30 Aug 2007 19:48:16 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IQtXX-0002Ko-Aa for netconf-data@psg.com; Thu, 30 Aug 2007 23:35:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IQtXS-0002JI-PG for netconf@ops.ietf.org; Thu, 30 Aug 2007 23:35:05 +0000 Received: (qmail 70830 invoked from network); 30 Aug 2007 23:35:02 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 30 Aug 2007 23:35:01 -0000 X-YMail-OSG: CZOXKpYVM1ltab0UWulYhKyF_XTMyoeCZGZ3Cmf4KDKb7Lbc Message-ID: <46D753B9.1030606@andybierman.com> Date: Thu, 30 Aug 2007 16:33:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Harrington CC: "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> In-Reply-To: <029401c7eb1e$4f4de640$6702a8c0@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: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca David Harrington wrote: > Hi, > > For partial locking, since the lock applies not only to Netconf but to > other NM interfaces as well, it is imperative that the managed entity > understand just what **instrumentation** is being partially locked, > not just what Netconf data model subset is being partially locked. > > In SNMP, we use strings to identify a "naming scope" - a community or > a context, and it is imperative that the agent understand what data is > in the community or the context. It is the implementation of the > managed entity that determines just what distinct communities or > contexts exist within the managed entity, and an agent knows about the > data subsets, even if there are dynamic hardware changes that affect > the subsets. The manager can learn what managed objects are in a > community or context by querying the agent. I think the same > agent-centric determination of named data partitions will be required > if the partial locking will apply to multiple NM interfaces that use > different data modeling interfaces. > > In SNMP and/or Netconf, the manager/operatorcan also dynamically > specify subtrees of data or "view families" or XPath expressions. I > think we need to identify whether and how this type of dynamic subset > of data might be locked by partial locking, whether such > dynamically-specified locks apply across multiple NM interfaces, and > how the managed entity knows which non-Netconf data to partially lock. > I'm not sure there is any use case to share write access to the configuration database between SNMP and NETCONF. Is anybody doing this already? Is anybody implementing SNMP context or community string based 'partitions' within the NETCONF protocol? There is no non-NETCONF data to lock. There are non-NETCONF locks on NETCONF data, and global locks of this type are probably good enough. > > 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 Fri Aug 31 05:52: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 1IR3BS-0001of-VK for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 05:52:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR3BR-00078b-Mv for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 05:52:58 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR32o-000AfX-MK for netconf-data@psg.com; Fri, 31 Aug 2007 09:44:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR32l-000AfC-SO for netconf@ops.ietf.org; Fri, 31 Aug 2007 09:44:01 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2007 11:42:58 +0200 X-IronPort-AV: i="4.19,330,1183327200"; d="scan'208"; a="151991058:sNHT44579748" 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 l7V9gwlm026800; Fri, 31 Aug 2007 11:42:58 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp144.cisco.com [10.61.64.144]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7V9gvf3001716; Fri, 31 Aug 2007 09:42:57 GMT Message-ID: <46D7E2A6.1010504@cisco.com> Date: Fri, 31 Aug 2007 11:43:02 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Andy Bierman CC: David Harrington , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> In-Reply-To: <46D753B9.1030606@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=589; t=1188553378; x=1189417378; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20partial=20locking |Sender:=20; bh=m4dK9CHvZDfbqYIW8iByI9B/YNPIandSwxXP+cYPjyI=; b=BEXypLENRNiVddx+PdbLXDlGHOa2feERjSh4OsfcjV7LPQpI31ylKYzxpWUXq/WAzdzFMwJh FRaSGJMMJkFjrs3nNLnBO8BsZ7qNBioxp4/zwYHPCxxtXg2VOiThtePr; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Should NETCONF impose a write-lock on the data then it shouldn't be writable to other applications, be that SNMP, or for that matter the CLI. An error should be returned. In other words, the lock interface needs to be below the external protocol interface. This can prove Challenging in some implementations, but it's still the right thing to do. I'm a little leery (perhaps evena little LEARy) about attempting to codify coherency of this form within the IETF, but I could be convinced. Customers, on the other hand, can codify anything they want in their RFPs... -- to unsubscribe send a message to netconf-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 Aug 31 07:01: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 1IR4FJ-0000YY-2Z for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:01:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR4FH-0000VM-Pt for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:01:01 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR463-000ECK-JT for netconf-data@psg.com; Fri, 31 Aug 2007 10:51:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR460-000EBu-SW for netconf@ops.ietf.org; Fri, 31 Aug 2007 10:51:26 +0000 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Aug 2007 06:51:21 -0400 X-IronPort-AV: i="4.19,330,1183348800"; d="scan'208"; a="53216060:sNHT66798198" 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: partial locking Date: Fri, 31 Aug 2007 12:50:40 +0200 Message-ID: In-Reply-To: <46D7E2A6.1010504@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: partial locking Thread-Index: Acfrs8ExRnuqZSzuTQGm8BZF84w2jQACFkkA References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> From: "Romascanu, Dan (Dan)" To: "Eliot Lear" , "Andy Bierman" Cc: "David Harrington" , "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Eliot, Just to make sure that I understand the requirement here. Do you assume that the data is writeable only by NETCONF? What if another protocol may change the same set of data or part of it?=20 Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear > Sent: Friday, August 31, 2007 12:43 PM > To: Andy Bierman > Cc: David Harrington; 'Netconf (E-mail)' > Subject: Re: partial locking >=20 >=20 > Should NETCONF impose a write-lock on the data then it=20 > shouldn't be writable to other applications, be that SNMP, or=20 > for that matter the CLI. An error should be returned. In=20 > other words, the lock interface needs to be below the=20 > external protocol interface. This can prove Challenging in=20 > some implementations, but it's still the right thing to do. =20 > I'm a little leery (perhaps evena little LEARy) about=20 > attempting to codify coherency of this form within the IETF,=20 > but I could be convinced. Customers, on the other hand, can=20 > codify anything they want in their RFPs... >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Aug 31 07:22: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 1IR4a3-0002pu-JP for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:22:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR4a2-00010G-7h for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:22:27 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR4OG-000FU8-DD for netconf-data@psg.com; Fri, 31 Aug 2007 11:10:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR4OD-000FTn-Oh for netconf@ops.ietf.org; Fri, 31 Aug 2007 11:10:15 +0000 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 31 Aug 2007 07:07:11 -0400 X-IronPort-AV: i="4.19,330,1183348800"; d="scan'208"; a="59869568:sNHT10439712" 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: partial locking Date: Fri, 31 Aug 2007 13:06:35 +0200 Message-ID: In-Reply-To: <46D753B9.1030606@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: partial locking Thread-Index: AcfrXuroF4yAoyJZRSGx72odAYcogwAXswRw References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "David Harrington" Cc: "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Friday, August 31, 2007 2:33 AM > To: David Harrington > Cc: 'Netconf (E-mail)' > Subject: Re: partial locking >=20 > David Harrington wrote: > > Hi, > >=20 > > For partial locking, since the lock applies not only to=20 > Netconf but to=20 > > other NM interfaces as well, it is imperative that the=20 > managed entity=20 > > understand just what **instrumentation** is being partially locked,=20 > > not just what Netconf data model subset is being partially locked. > >=20 > > In SNMP, we use strings to identify a "naming scope" - a=20 > community or=20 > > a context, and it is imperative that the agent understand=20 > what data is=20 > > in the community or the context. It is the implementation of the=20 > > managed entity that determines just what distinct communities or=20 > > contexts exist within the managed entity, and an agent=20 > knows about the=20 > > data subsets, even if there are dynamic hardware changes=20 > that affect=20 > > the subsets. The manager can learn what managed objects are in a=20 > > community or context by querying the agent. I think the same=20 > > agent-centric determination of named data partitions will=20 > be required=20 > > if the partial locking will apply to multiple NM interfaces=20 > that use=20 > > different data modeling interfaces. > >=20 > > In SNMP and/or Netconf, the manager/operatorcan also dynamically=20 > > specify subtrees of data or "view families" or XPath expressions. I=20 > > think we need to identify whether and how this type of=20 > dynamic subset=20 > > of data might be locked by partial locking, whether such=20 > > dynamically-specified locks apply across multiple NM=20 > interfaces, and=20 > > how the managed entity knows which non-Netconf data to=20 > partially lock. > >=20 >=20 > I'm not sure there is any use case to share write access to=20 > the configuration database between SNMP and NETCONF. > Is anybody doing this already? >=20 > Is anybody implementing SNMP context or community string=20 > based 'partitions' > within the NETCONF protocol? >=20 > There is no non-NETCONF data to lock. > There are non-NETCONF locks on NETCONF data, and global locks=20 > of this type are probably good enough. >=20 I am not sure that I understand the concepts of NETCONF data and non-NETCONF data. We deal with network devices that are being configured nowadays using different protocols - I know for example uses of CLI and SNMP and some forms of secure file transfer and telephony provisioning protocols in any combination - and now we want to add NETCONF as another configuration protocol. Unless we assume that what is being configured by NETCONF is something completely new or that we introduce a requirement that I was not aware about that what is configured by NETCONF is not configured by other protocols it seems to me that there the use case of NETCONF sharing write access with other protocols is obvious. Am I missing something?=20 Dan (speaking as contributor) -- to unsubscribe send a message to netconf-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 Aug 31 07:30: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 1IR4hZ-00030h-P5 for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:30:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR4hY-0001DK-Gv for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:30:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR4a7-000GDl-RS for netconf-data@psg.com; Fri, 31 Aug 2007 11:22:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR4a5-000GDO-BQ for netconf@ops.ietf.org; Fri, 31 Aug 2007 11:22:30 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2007 13:21:29 +0200 X-IronPort-AV: i="4.19,330,1183327200"; d="scan'208"; a="152019298:sNHT43448966" 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 l7VBLSL9024125; Fri, 31 Aug 2007 13:21:28 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp144.cisco.com [10.61.64.144]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7VBLRf3013506; Fri, 31 Aug 2007 11:21:27 GMT Message-ID: <46D7F9BC.30301@cisco.com> Date: Fri, 31 Aug 2007 13:21:32 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: Andy Bierman , David Harrington , "Netconf (E-mail)" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=396; t=1188559288; x=1189423288; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20partial=20locking |Sender:=20; bh=k3Arf8SYTuOd1x41K95MFJ8NO90CzlG1BM/9ZZMN/2A=; b=I4/ZIAUg77f36KA012aSCV3wk+P52FPp7M+0jYfL411NthjCXvJz2R2UFnCNv7HLFv/ADnbH ZEm9eA/1sEC1t4omnllAMoL3Y1TfWQe7JcAuYpepHzc8jAYkHjog4XmT; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Dan, > Eliot, > > Just to make sure that I understand the requirement here. Do you assume > that the data is writeable only by NETCONF? What if another protocol may > change the same set of data or part of it? > I think it should work in reverse as well, so long as the protocol semantics allow for it. That is to say, you have to have an explicit locking capability. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Aug 31 07:55: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 1IR55n-000075-CR for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:55:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR55m-0001ye-5O for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 07:55:15 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR4ye-000HsI-2H for netconf-data@psg.com; Fri, 31 Aug 2007 11:47:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IR4yb-000Hs1-Eg for netconf@ops.ietf.org; Fri, 31 Aug 2007 11:47:50 +0000 Received: (qmail 34036 invoked from network); 31 Aug 2007 11:41:09 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 31 Aug 2007 11:41:09 -0000 X-YMail-OSG: 4tqAI.AVM1nm.pY77QTP.JK1We_JyLv1w4RgK1ph9VQJFEMV Message-ID: <46D7FDE8.9090600@andybierman.com> Date: Fri, 31 Aug 2007 04:39:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear CC: David Harrington , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> In-Reply-To: <46D7E2A6.1010504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Eliot Lear wrote: > Should NETCONF impose a write-lock on the data then it shouldn't be > writable to other applications, be that SNMP, or for that matter the > CLI. An error should be returned. In other words, the lock interface > needs to be below the external protocol interface. This can prove > Challenging in some implementations, but it's still the right thing to > do. I'm a little leery (perhaps evena little LEARy) about attempting > to codify coherency of this form within the IETF, but I could be > convinced. Customers, on the other hand, can codify anything they want > in their RFPs... Partial locking in NETCONF is a performance optimization. I suppose if an agent implementation contained data that was written frequently by non-NETCONF sources then it might be worthwhile to implement partial locking for those sources. IMO, this is an academic exercise. I am not convinced that SNMP has any meaningful role to play in writing NETCONF configuration databases, let alone one that requires performance optimizations such as partial locking. 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 Aug 31 08:00: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 1IR5AW-00065A-VI for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 08:00:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR5AV-00027C-9R for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 08:00:08 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR4ys-000HtQ-LO for netconf-data@psg.com; Fri, 31 Aug 2007 11:48:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR4yq-000Hsz-6x for netconf@ops.ietf.org; Fri, 31 Aug 2007 11:48:05 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2007 13:48:03 +0200 X-IronPort-AV: i="4.19,330,1183327200"; d="scan'208"; a="152022830:sNHT44542176" 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 l7VBm3m8032744; Fri, 31 Aug 2007 13:48:03 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp144.cisco.com [10.61.64.144]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7VBlwf3027931; Fri, 31 Aug 2007 11:48:02 GMT Message-ID: <46D7FFF3.9010603@cisco.com> Date: Fri, 31 Aug 2007 13:48:03 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Andy Bierman CC: David Harrington , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <46D7FDE8.9090600@andybierman.com> In-Reply-To: <46D7FDE8.9090600@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=434; t=1188560883; x=1189424883; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20partial=20locking |Sender:=20; bh=akVZ6TzEAPXSyRMArLjvl2r/8jLuTrrmDMkahmvAgx0=; b=Ez08Yre9TGMD8/HFBNtUgdFPerwG3w3ZWTojF6VCT1R6rjZfD+JpDABjY7dW7TP/1Dg5ckQL j3um5tyQ4lnSDt96XmLlRBjDucnsp0Pq3UKmfa3EwZUqjVOALaHB14bk; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Andy Bierman wrote: > IMO, this is an academic exercise. I am not convinced that > SNMP has any meaningful role to play in writing NETCONF > configuration databases, let alone one that requires > performance optimizations such as partial locking. This is going to be highly implementation dependent. And it truly is academic as relates to SNMP if READ-WRITE is not enabled for configuration objects that NETCONF covers. -- to unsubscribe send a message to netconf-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 Aug 31 10:52: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 1IR7r1-0007Vw-Gw for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 10:52:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR7qy-0008Fb-4I for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 10:52:11 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR7ep-0004Yz-Em for netconf-data@psg.com; Fri, 31 Aug 2007 14:39:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IR7em-0004YZ-E2 for netconf@ops.ietf.org; Fri, 31 Aug 2007 14:39:34 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0910620461; Fri, 31 Aug 2007 16:39:28 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-83-46d8281f4003 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D1C492015E; Fri, 31 Aug 2007 16:39:27 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 16:39:27 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 16:39:26 +0200 Message-ID: <46D8281E.8090300@ericsson.com> Date: Fri, 31 Aug 2007 16:39:26 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Eliot Lear CC: Andy Bierman , David Harrington , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <46D7FDE8.9090600@andybierman.com> <46D7FFF3.9010603@cisco.com> In-Reply-To: <46D7FFF3.9010603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2007 14:39:27.0011 (UTC) FILETIME=[BB3E6730:01C7EBDC] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hello, As Dan has pointed out there are a big number of protocols/interfaces that can modify device data. As I understand this device data will have an internal addressing/naming scheme that is mapped to the addressing schemes of the different protocols. It is the responsibility of the device to do this mapping. This mapping has to be done for partial locking as well, to map the area to be locked. However this internal mapping (easy or difficult) is completely device dependent, and I fail to see why IETF should try to standardize it. The same mapping is needed for the base Netconf anyway. If parts of the device data is not visible via Netconf that might be a good or bad thing, but does not really effect Netconf locking. Netconf can only lock what it sees. Balazs Eliot Lear wrote: > Andy Bierman wrote: >> IMO, this is an academic exercise. I am not convinced that >> SNMP has any meaningful role to play in writing NETCONF >> configuration databases, let alone one that requires >> performance optimizations such as partial locking. > > This is going to be highly implementation dependent. And it truly is > academic as relates to SNMP if READ-WRITE is not enabled for > configuration objects that NETCONF covers. > > -- > to 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 Aug 31 11:40: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 1IR8bp-0005w1-EP for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 11:40:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8bo-0001ep-3j for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 11:40:33 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR8S0-0008rl-Kg for netconf-data@psg.com; Fri, 31 Aug 2007 15:30:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IR8Rx-0008qy-IE for netconf@ops.ietf.org; Fri, 31 Aug 2007 15:30:22 +0000 Received: (qmail 85502 invoked from network); 31 Aug 2007 15:30:17 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 31 Aug 2007 15:30:16 -0000 X-YMail-OSG: 8lex_UEVM1nivyrp.rzAt5AkZvh13IhtR6PE0mR43LKzWaHndSBUvYjHgW98y_.WxiI5PrIhWnDI.f.teDQRTLED Message-ID: <46D8339B.3020102@andybierman.com> Date: Fri, 31 Aug 2007 08:28:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David B Harrington CC: "'Romascanu, Dan \(Dan\)'" , 'Eliot Lear' , 'David Harrington' , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <005501c7ebd9$5b6ab960$6702a8c0@china.huawei.com> In-Reply-To: <005501c7ebd9$5b6ab960$6702a8c0@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: -4.0 (----) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 David B Harrington wrote: > Hi, > >>> Should NETCONF impose a write-lock on the data then it >>> shouldn't be writable to other applications, be that SNMP, or >>> for that matter the CLI. An error should be returned. > > I interpret the conceptual model to be that there is a writable > "configuration database" that is shared by all NM interfaces. It is a completely implementation-specific matter as to how a NETCONF configuration database is accessed by other protocols. One thing that is clear is that NETCONF uses XML encoded data, and the mechanisms to manipulate NETCONF data are XML mechanisms. So if SNMP or CLI or even COPS-PR data is encoded in XML and part of the database, then NETCONF managers cannot tell the difference. There is only one agent per device and the entire conceptual configuration database can be represented as one XML instance document. So as long as other protocols integrate their data into the XML database, then an Xpath expression can be used to identify the XML sub-trees to lock. Adding SNMP concepts such as context ID is not appropriate. There are only namespaces and elements (QNames) to lock. (XML attributes should not be locked individually.) Andy > > When an instance of Netconf applies a global lock. it prevents the > shared config datastore from being modified by any other NM interface > (CLI, SNMP, COPS-PR, Web server, ...) or by any other instance/session > of Netconf. The implementation can simply block all CLI writes, all > SNMP write, all COPS-PR writes, and all web-server writes that wqould > modify the shared config datastore. > > Now we want to talk about partial locking, so that two parts of the > shared config datastore can be worked on simultaneously using more > than one interface or Netconf instance. I interpret the conceptual > model to be a lock is taken out on **part** of the shared config > datastore, but not the complete datastore. The partial lock prevents > the locked part of the shared config datastore from being modified by > any other NM interface (CLI, SNMP, COPS-PR, Web server, ...) or any > other instance of Netconf. The implementation needs to block all > writes to that part of the config datastore by any NM interface other > than the one holding the lock. > > My concern is how to specify the part of the shared config datastore > that is locked, in a way that the implementation cam determine what > configuration data is locked, in a way that it can efficiently > determine whether a write by another NM interface would modify the > locked part. > > My shared config datastore implementation may in fact include complex > data structures such as hash tables or tree structures implmented in C > that happens to be very different from the type of structure used to > model the information in a Netconf XML-based data model, an SNMP > SMI-based data mode, a web-page-based data model, a COPS-PR PIB data > model, or a CLI data model. > > If the part being locked is a statically-defined > implementation-defined subset of the shared config datastore, such as > "the config data in physical blade7", this is probably not an issue > for an implementation to determine what data is in the part. The > partition is statically defined by the implementation, and probably > means much the same set of data regardless of which NM interface is > used to modify it, or which vendor implemented it. > > If the part being locked, however, is a dynamically-defined > client-defined logical part of the config datastore specified in an > NM-interface-dependent manner, such as with a Netconf XPath > expression, that might be problematic, because the NM-interface > modeling might not match my actual implementation. In SNMP, we have > oft heard complaints that the two-dimensional tables do not map well > to the actual underlying instrumentation of complex data structures. > Operators also may want to be able to specify "that part of the config > datastore that relates to the service I have configued for my > customer, the ACME company." > > If there is a mismatch between the NM-interface data modeling concepts > and actual implementations, then allowing the lock specifications to > be dynamically defined using NM-interface-specific expressions could > be difficult for an implementation to apply. If partial locking is > constrained to some implementation-defined partitions, that might be > easier for the server to apply, although this could impact > interoperability across vendors. > > I am not advocating one approach or the other. I think it is important > that proposals for partial locking clearly identify whether the data > partitions that can be locked are expected to be determined by the > implementation or by the client. > > 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 Romascanu, Dan > (Dan) >> Sent: Friday, August 31, 2007 6:51 AM >> To: Eliot Lear; Andy Bierman >> Cc: David Harrington; Netconf (E-mail) >> Subject: RE: partial locking >> >> Eliot, >> >> Just to make sure that I understand the requirement here. Do >> you assume >> that the data is writeable only by NETCONF? What if another >> protocol may >> change the same set of data or part of it? >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org >>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear >>> Sent: Friday, August 31, 2007 12:43 PM >>> To: Andy Bierman >>> Cc: David Harrington; 'Netconf (E-mail)' >>> Subject: Re: partial locking >>> >>> >>> Should NETCONF impose a write-lock on the data then it >>> shouldn't be writable to other applications, be that SNMP, or >>> for that matter the CLI. An error should be returned. In >>> other words, the lock interface needs to be below the >>> external protocol interface. This can prove Challenging in >>> some implementations, but it's still the right thing to do. >>> I'm a little leery (perhaps evena little LEARy) about >>> attempting to codify coherency of this form within the IETF, >>> but I could be convinced. Customers, on the other hand, can >>> codify anything they want in their RFPs... >>> >>> -- >>> to 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 Aug 31 12: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 1IR9BJ-0002AU-PW for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 12:17:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR9BI-0002kH-F5 for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 12:17:13 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR8z2-000C1t-8A for netconf-data@psg.com; Fri, 31 Aug 2007 16:04:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IR8yz-000C1O-Mk for netconf@ops.ietf.org; Fri, 31 Aug 2007 16:04:31 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5789620106; Fri, 31 Aug 2007 18:04:27 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-7e-46d83c0b8171 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 22B6420265; Fri, 31 Aug 2007 18:04:27 +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, 31 Aug 2007 18:04:26 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 18:04:26 +0200 Message-ID: <46D83C0A.8030302@ericsson.com> Date: Fri, 31 Aug 2007 18:04:26 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: David B Harrington , "'Romascanu, Dan \(Dan\)'" , 'Eliot Lear' , 'David Harrington' , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <005501c7ebd9$5b6ab960$6702a8c0@china.huawei.com> <46D8339B.3020102@andybierman.com> In-Reply-To: <46D8339B.3020102@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2007 16:04:26.0453 (UTC) FILETIME=[9ABF8050:01C7EBE8] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hello Andy, I have a problem with the terminology used in this mail-thread. People are speaking about SNMP database, Netconf database etc. IMHO we should speak about the device's management database as the only database. Different protocols, interfaces might provide a complete or partial view to this database, but the data is not owned by this or that protocol as I understand. 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 Aug 31 12:28:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9MN-0005Sl-HV for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 12:28:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR9MM-000322-0x for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 12:28:39 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR9Fx-000DMa-UP for netconf-data@psg.com; Fri, 31 Aug 2007 16:22:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IR9Fq-000DLy-RC for netconf@ops.ietf.org; Fri, 31 Aug 2007 16:22:00 +0000 Received: (qmail 16251 invoked from network); 31 Aug 2007 16:21:54 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 31 Aug 2007 16:21:54 -0000 X-YMail-OSG: tIBy_j8VM1lbrGvLqc5sV0JYczJUOp6J9yIkBc5TVD1Mljol Message-ID: <46D83FB4.7010306@andybierman.com> Date: Fri, 31 Aug 2007 09:20:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Balazs Lengyel CC: David B Harrington , "'Romascanu, Dan \(Dan\)'" , 'Eliot Lear' , 'David Harrington' , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <005501c7ebd9$5b6ab960$6702a8c0@china.huawei.com> <46D8339B.3020102@andybierman.com> <46D83C0A.8030302@ericsson.com> In-Reply-To: <46D83C0A.8030302@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: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Balazs Lengyel wrote: > Hello Andy, > I have a problem with the terminology used in this mail-thread. > > People are speaking about SNMP database, Netconf database etc. IMHO we > should speak about the device's management database as the only > database. Different protocols, interfaces might provide a complete or > partial view to this database, but the data is not owned by this or that > protocol as I understand. This may be true in the abstract sense, but for standards purposes, I am interested in how the NETCONF protocol operations work with the XML encoded data in the element. This data is entirely up the agent implementor. It may or may not represent the entire device. What if the agent is for a virtual router, not the entire physical router? I completely agree with you that there is one seamless XML-encoded configuration database on the agent, which can be manipulated in a consistent manner with standard protocol operations. In other words, if an implementor puts data within the , then it must support the standard operations such as and (if writable) on that data. This is a much different requirement than saying all configuration data on the device must be accessible via NETCONF. > > 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 Aug 31 12:45:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9co-0005za-4W for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 12:45:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR9cm-0003Tg-Q5 for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 12:45:38 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR9Wr-000Ejv-Ir for netconf-data@psg.com; Fri, 31 Aug 2007 16:39:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 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 1IR9Wo-000Eje-UU for netconf@ops.ietf.org; Fri, 31 Aug 2007 16:39:28 +0000 Received: (qmail 53007 invoked from network); 31 Aug 2007 16:39:26 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 31 Aug 2007 16:39:26 -0000 X-YMail-OSG: 3Z70deQVM1md.M5_J7VLG1qz_YBikfr35aPRtk39l4ot98hy Message-ID: <46D843D0.7030702@andybierman.com> Date: Fri, 31 Aug 2007 09:37:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David B Harrington CC: 'Balazs Lengyel' , "'Romascanu, Dan \(Dan\)'" , 'Eliot Lear' , 'David Harrington' , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <005501c7ebd9$5b6ab960$6702a8c0@china.huawei.com> <46D8339B.3020102@andybierman.com> <46D83C0A.8030302@ericsson.com> <00ba01c7ebeb$9cbf1980$6702a8c0@china.huawei.com> In-Reply-To: <00ba01c7ebeb$9cbf1980$6702a8c0@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: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c David B Harrington wrote: > Hi, > > I agree. > I think there is one virtual shared configuration database that > contains all configuration regardless of the protocol(s) used to > access it. > yes -- this is what we have now with internal agent instrumentation allowing various protocols to access various internal data structures. SNMP has an tree populated with OIDs and NETCONF has a conceptual XML instance document. How they overlap within internal agent instrumentation is not relevant to the NETCONF WG. > And then there are protocol-specific representations (views) of this > shared configuration database. yes -- this is what we have now. Different protocols with different data model architectures accessing various subsets of internal data structures on the agent. This does not mean the NETCONF protocol needs to access the database with special RPCs like and . Each protocol has its own consistent view of the data, and the agent handles any translation for multi-protocol access as an implementation detail. > > dbh Andy > >> -----Original Message----- >> From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] >> Sent: Friday, August 31, 2007 12:04 PM >> To: Andy Bierman >> Cc: David B Harrington; 'Romascanu, Dan (Dan)'; 'Eliot Lear'; >> 'David Harrington'; 'Netconf (E-mail)' >> Subject: Re: partial locking >> >> Hello Andy, >> I have a problem with the terminology used in this mail-thread. >> >> People are speaking about SNMP database, Netconf database >> etc. IMHO we should speak about the >> device's management database as the only database. Different >> protocols, interfaces might >> provide a complete or partial view to this database, but the >> data is not owned by this or that >> protocol as I understand. >> >> 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 Aug 31 13:05: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 1IR9va-0002It-Ap for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 13:05:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR9vZ-0003uX-3e for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 13:05:02 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR9o8-000GIs-Kn for netconf-data@psg.com; Fri, 31 Aug 2007 16:57:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR9o6-000GIb-3f for netconf@ops.ietf.org; Fri, 31 Aug 2007 16:57:19 +0000 Received: from 14.140.8.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-outbound.avaya.com with ESMTP; 31 Aug 2007 12:57:16 -0400 X-IronPort-AV: i="4.20,193,1186372800"; d="scan'208"; a="56537680:sNHT10276020" 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: partial locking Date: Fri, 31 Aug 2007 18:57:15 +0200 Message-ID: In-Reply-To: <46D83C0A.8030302@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: partial locking Thread-Index: Acfr6K/d5XYCkuCpTH6ydk6W45dJ4AABzJMA References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <005501c7ebd9$5b6ab960$6702a8c0@china.huawei.com> <46D8339B.3020102@andybierman.com> <46D83C0A.8030302@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Andy Bierman" Cc: "David B Harrington" , "Eliot Lear" , "David Harrington" , "Netconf (E-mail)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 That was also my point when I said that I do not understand the concept of 'NETCONF data'.=20 Dan =20 =20 > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 > Sent: Friday, August 31, 2007 7:04 PM > To: Andy Bierman > Cc: David B Harrington; Romascanu, Dan (Dan); 'Eliot Lear';=20 > 'David Harrington'; 'Netconf (E-mail)' > Subject: Re: partial locking >=20 > Hello Andy, > I have a problem with the terminology used in this mail-thread. >=20 > People are speaking about SNMP database, Netconf database=20 > etc. IMHO we should speak about the device's management=20 > database as the only database. Different protocols,=20 > interfaces might provide a complete or partial view to this=20 > database, but the data is not owned by this or that protocol=20 > as I understand. >=20 > Balazs >=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 Aug 31 13:59: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 1IRAmV-0007Jn-9i for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 13:59:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRAmT-0005jQ-Rv for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 13:59:43 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRAeF-000KAQ-2V for netconf-data@psg.com; Fri, 31 Aug 2007 17:51:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [68.142.198.213] (helo=smtp114.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRAeC-000KA3-6G for netconf@ops.ietf.org; Fri, 31 Aug 2007 17:51:09 +0000 Received: (qmail 57103 invoked from network); 31 Aug 2007 17:24:27 -0000 Received: from unknown (HELO ?192.168.1.11?) (andybierman@att.net@75.50.187.99 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 31 Aug 2007 17:24:27 -0000 X-YMail-OSG: RigEYz0VM1m9UBXktiEEyWOb24g92ceAMikYX.qSt.i5sThQ Message-ID: <46D84E5D.7090302@andybierman.com> Date: Fri, 31 Aug 2007 10:22:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Harrington CC: 'Balazs Lengyel' , 'David B Harrington' , "'Romascanu, Dan \(Dan\)'" , 'Eliot Lear' , "'Netconf (E-mail)'" Subject: Re: partial locking References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <005501c7ebd9$5b6ab960$6702a8c0@china.huawei.com> <46D8339B.3020102@andybierman.com> <46D83C0A.8030302@ericsson.com> <46D83FB4.7010306@andybierman.com> <00c101c7ebf0$8c4355d0$6702a8c0@china.huawei.com> In-Reply-To: <00c101c7ebf0$8c4355d0$6702a8c0@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: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 David Harrington wrote: > > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] > [...] >> This may be true in the abstract sense, but for standards purposes, >> I am interested in how the NETCONF protocol operations work with >> the XML encoded data in the element. > > But I'm interested in how the 'lock' works, which seems to be > potentially larger than the view encoded in XML. > >>From RFC4741: > > o Running: The complete configuration currently active on the > network device. I do not interpret these words to mean that there a content-level conformance requirement that all data comprising the conceptual device configuration be supported by an agent. I interpret it to mean all of the configuration data managed within a single NETCONF agent, as provided by the agent implementor. I interpret the global lock to apply to the writable data that a NETCONF manager can actually access within a single NETCONF agent. It is an agent implementation detail as to how the configurations from multiple virtual agents are combined into one instance document within an agent for the entire physical device. "NETCONF Data" is the conceptual data that a NETCONF manager can access with the NETCONF protocol, as represented in various protocol operations (e.g., or elements). Andy > Only one configuration datastore of this type > exists on the device, and it is always present. NETCONF > protocol > operations refer to this datastore using the element. > > and > > The lock operation allows the client to lock the configuration > system of a device. Such locks are intended to be short-lived > and > allow a client to make a change without fear of interaction with > other NETCONF clients, non-NETCONF clients (e.g., SNMP and > command > line interface (CLI) scripts), and human users. > ... > The lock operation takes a mandatory parameter, target. The > target parameter names the configuration that will be locked. > When a lock is active, using the operation on the > locked configuration and using the locked configuration as a > target of the operation will be disallowed by any > other NETCONF session. Additionally, the system will ensure > that > these locked configuration resources will not be modified by > other > non-NETCONF management operations such as SNMP and CLI. > > When you talk about a Netconf global lock, on an implementation that > has a "running config" that is "the complete configuration currently > active on the network device", does the global lock apply only to the > Netconf XML-encoded subset of the implementation's running config? > > If I have multiple virtual routers within a physical router, then does > a Netconf lock on "running" only apply to the configuration of one > virutal router or to "the complete configuration currently active on > the network device"? > > If I parse your paragraph correctly, you are saying "the XML encoded > data in the element" + "may or may not represent the entire > device." Doesn't that contradict the definition of in > RFC4741? > > 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 Fri Aug 31 15:19: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 1IRC1U-0003nF-Sw for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 15:19:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRC1T-0000Fw-LV for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 15:19:16 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRBuk-0000FX-6P for netconf-data@psg.com; Fri, 31 Aug 2007 19:12:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [204.127.225.95] (helo=alnrmhc15.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRBMz-000Niw-LW for netconf@ops.ietf.org; Fri, 31 Aug 2007 18:37:26 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070831170120b1500a40ike>; Fri, 31 Aug 2007 17:01:20 +0000 From: "David Harrington" To: "'Andy Bierman'" , "'Balazs Lengyel'" Cc: "'David B Harrington'" , "'Romascanu, Dan \(Dan\)'" , "'Eliot Lear'" , "'Netconf \(E-mail\)'" References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> <005501c7ebd9$5b6ab960$6702a8c0@china.huawei.com> <46D8339B.3020102@andybierman.com> <46D83C0A.8030302@ericsson.com> <46D83FB4.7010306@andybierman.com> Subject: RE: partial locking Date: Fri, 31 Aug 2007 13:01:16 -0400 Message-ID: <00c101c7ebf0$8c4355d0$6702a8c0@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: Acfr6wu71VQ7l/MzSFW+wOFdPNAlpwAAKCoQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-reply-to: <46D83FB4.7010306@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] [...] > > This may be true in the abstract sense, but for standards purposes, > I am interested in how the NETCONF protocol operations work with > the XML encoded data in the element. But I'm interested in how the 'lock' works, which seems to be potentially larger than the view encoded in XML. >From RFC4741: o Running: The complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present. NETCONF protocol operations refer to this datastore using the element. and The lock operation allows the client to lock the configuration system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users. ... The lock operation takes a mandatory parameter, target. The target parameter names the configuration that will be locked. When a lock is active, using the operation on the locked configuration and using the locked configuration as a target of the operation will be disallowed by any other NETCONF session. Additionally, the system will ensure that these locked configuration resources will not be modified by other non-NETCONF management operations such as SNMP and CLI. When you talk about a Netconf global lock, on an implementation that has a "running config" that is "the complete configuration currently active on the network device", does the global lock apply only to the Netconf XML-encoded subset of the implementation's running config? If I have multiple virtual routers within a physical router, then does a Netconf lock on "running" only apply to the configuration of one virutal router or to "the complete configuration currently active on the network device"? If I parse your paragraph correctly, you are saying "the XML encoded data in the element" + "may or may not represent the entire device." Doesn't that contradict the definition of in RFC4741? 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 Fri Aug 31 20:31: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 1IRGtU-0000Xu-QD for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 20:31:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRGtT-0006dQ-C5 for netconf-archive@lists.ietf.org; Fri, 31 Aug 2007 20:31:20 -0400 Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRGjQ-000Mmc-8v for netconf-data@psg.com; Sat, 01 Sep 2007 00:20:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.1 Received: from [206.18.177.52] (helo=alnrmhc12.comcast.net) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IRGjN-000MlQ-EM for netconf@ops.ietf.org; Sat, 01 Sep 2007 00:20:54 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070831141519b1200dopoue>; Fri, 31 Aug 2007 14:15:20 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Eliot Lear'" , "'Andy Bierman'" Cc: "'David Harrington'" , "'Netconf \(E-mail\)'" References: <029401c7eb1e$4f4de640$6702a8c0@china.huawei.com> <46D753B9.1030606@andybierman.com> <46D7E2A6.1010504@cisco.com> Subject: RE: partial locking Date: Fri, 31 Aug 2007 10:15:16 -0400 Message-ID: <005501c7ebd9$5b6ab960$6702a8c0@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: Acfrs8ExRnuqZSzuTQGm8BZF84w2jQACFkkAAAQwhEA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-reply-to: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Hi, > > Should NETCONF impose a write-lock on the data then it > > shouldn't be writable to other applications, be that SNMP, or > > for that matter the CLI. An error should be returned. I interpret the conceptual model to be that there is a writable "configuration database" that is shared by all NM interfaces. When an instance of Netconf applies a global lock. it prevents the shared config datastore from being modified by any other NM interface (CLI, SNMP, COPS-PR, Web server, ...) or by any other instance/session of Netconf. The implementation can simply block all CLI writes, all SNMP write, all COPS-PR writes, and all web-server writes that wqould modify the shared config datastore. Now we want to talk about partial locking, so that two parts of the shared config datastore can be worked on simultaneously using more than one interface or Netconf instance. I interpret the conceptual model to be a lock is taken out on **part** of the shared config datastore, but not the complete datastore. The partial lock prevents the locked part of the shared config datastore from being modified by any other NM interface (CLI, SNMP, COPS-PR, Web server, ...) or any other instance of Netconf. The implementation needs to block all writes to that part of the config datastore by any NM interface other than the one holding the lock. My concern is how to specify the part of the shared config datastore that is locked, in a way that the implementation cam determine what configuration data is locked, in a way that it can efficiently determine whether a write by another NM interface would modify the locked part. My shared config datastore implementation may in fact include complex data structures such as hash tables or tree structures implmented in C that happens to be very different from the type of structure used to model the information in a Netconf XML-based data model, an SNMP SMI-based data mode, a web-page-based data model, a COPS-PR PIB data model, or a CLI data model. If the part being locked is a statically-defined implementation-defined subset of the shared config datastore, such as "the config data in physical blade7", this is probably not an issue for an implementation to determine what data is in the part. The partition is statically defined by the implementation, and probably means much the same set of data regardless of which NM interface is used to modify it, or which vendor implemented it. If the part being locked, however, is a dynamically-defined client-defined logical part of the config datastore specified in an NM-interface-dependent manner, such as with a Netconf XPath expression, that might be problematic, because the NM-interface modeling might not match my actual implementation. In SNMP, we have oft heard complaints that the two-dimensional tables do not map well to the actual underlying instrumentation of complex data structures. Operators also may want to be able to specify "that part of the config datastore that relates to the service I have configued for my customer, the ACME company." If there is a mismatch between the NM-interface data modeling concepts and actual implementations, then allowing the lock specifications to be dynamically defined using NM-interface-specific expressions could be difficult for an implementation to apply. If partial locking is constrained to some implementation-defined partitions, that might be easier for the server to apply, although this could impact interoperability across vendors. I am not advocating one approach or the other. I think it is important that proposals for partial locking clearly identify whether the data partitions that can be locked are expected to be determined by the implementation or by the client. 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 Romascanu, Dan (Dan) > Sent: Friday, August 31, 2007 6:51 AM > To: Eliot Lear; Andy Bierman > Cc: David Harrington; Netconf (E-mail) > Subject: RE: partial locking > > Eliot, > > Just to make sure that I understand the requirement here. Do > you assume > that the data is writeable only by NETCONF? What if another > protocol may > change the same set of data or part of it? > > Dan > > > > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear > > Sent: Friday, August 31, 2007 12:43 PM > > To: Andy Bierman > > Cc: David Harrington; 'Netconf (E-mail)' > > Subject: Re: partial locking > > > > > > Should NETCONF impose a write-lock on the data then it > > shouldn't be writable to other applications, be that SNMP, or > > for that matter the CLI. An error should be returned. In > > other words, the lock interface needs to be below the > > external protocol interface. This can prove Challenging in > > some implementations, but it's still the right thing to do. > > I'm a little leery (perhaps evena little LEARy) about > > attempting to codify coherency of this form within the IETF, > > but I could be convinced. Customers, on the other hand, can > > codify anything they want in their RFPs... > > > > -- > > to 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: