From owner-netconf@ops.ietf.org Fri Aug 04 06:20:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8wn2-0008Jp-24 for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 06:20:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8uLl-0000fY-P6 for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 03:44:05 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8u34-00086c-5E for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 03:24:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G8tvM-000DIl-Iv for netconf-data@psg.com; Fri, 04 Aug 2006 07:16:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G8tvL-000DIY-QL for netconf@ops.ietf.org; Fri, 04 Aug 2006 07:16:47 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k747Baqs004019 for ; Fri, 4 Aug 2006 03:11:37 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: Relax NG use in RAI X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Fri, 4 Aug 2006 10:16:43 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Relax NG use in RAI Thread-Index: Aca3KSRA7z2fWBPZTdWbL50xV67dpwAbGE9w From: "Romascanu, Dan \(Dan\)" To: "Netconf Data Model Discussion" , "Netconf Mailing List \(E-mail\)" Cc: "Cullen Jennings" , "Lisa Dusseault" X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb =20 I believe that this may be of interest for the Netconf and Netmod folks. Dan =20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Thursday, August 03, 2006 9:18 PM To: Lisa Dusseault; XML Directorate; Jon Peterson Cc: IESG IESG; Henning Schulzrinne Subject: Relax NG use in RAI Hi all - I'm looking for some advice here. The RAI area uses XML all over the place and every time we get to have a discussion about DTD/Scheme/Relax NG. More than one person has suggested we could make life easier and stop the same discussion from happening over and over again. I am considering sending an email that says something like the following and I would like to get some input on how to word this or if I should send it at all. Thanks, Cullen In the RAI area, when working with XML, many folks have come to the =20 conclusion that Relax NG is currently the preferred schema language. =20 Authors are encouraged to use Relax NG unless there is a good reason to use something else. Ease of reuse of previous work could certainly be a good reason to choose something else. In the future, other things may come along and this is not meant to block usage of better tools when and where they are more appropriate. -- to unsubscribe send a message to netconf-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 04 11:21:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91UA-0001Lt-Jo for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 11:21:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91U9-0005Sx-9j for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 11:21:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G91Oi-0002ln-RN for netconf-data@psg.com; Fri, 04 Aug 2006 15:15:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G91Oh-0002lS-AS for netconf@ops.ietf.org; Fri, 04 Aug 2006 15:15:35 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k74FFWZq030994 for ; Fri, 4 Aug 2006 11:15:33 -0400 Received: (qmail 17275 invoked by uid 78); 4 Aug 2006 15:15:32 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 4 Aug 2006 15:15:32 -0000 Message-ID: <44D3648D.9040907@andybierman.com> Date: Fri, 04 Aug 2006 08:15:25 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Callhome 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.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi, I was wondering if anyone is willing to be the Editor/author of 2 drafts to fully specify the Callhome feature for both BEEP and SSH. I don't know if this would be Informational, Experimental, or standards track. If done correctly, not one sentence in the protocol or notification drafts will be impacted by the Callhome feature. IMO, the "southbound interface" for Callhome is application-independent, and should work the same for any protocol mapping to SSH or BEEP (BEEP already has this part). The "northbound interface" of the Callhome mechanism is protocol-specific, and a mapping to NETCONF is needed. (NETCONF over BEEP already has this part.) I think there was interest at the Callhome BOF in a generic solution, but I hope this doesn't mean the problem will be abstracted so far away nobody ever works on it. thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Aug 04 13:17:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93J6-000733-Ai for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 13:17:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93J3-00055c-Ss for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 13:17:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G93CL-000BiV-EZ for netconf-data@psg.com; Fri, 04 Aug 2006 17:10:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [216.65.151.51] (helo=mail2.sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G93CK-000BiC-7o for netconf@ops.ietf.org; Fri, 04 Aug 2006 17:10:56 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 6FB971E14F3; Fri, 4 Aug 2006 10:10:50 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Aug 2006 10:10:50 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEA9@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'Romascanu, Dan (Dan)'" , Netconf Data Model Discussion , "Netconf Mailing List (E-mail)" Cc: Cullen Jennings , Lisa Dusseault Subject: RE: Relax NG use in RAI Date: Fri, 4 Aug 2006 10:10:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi folks, In support of the proposal below to recommend Relax NG as preferred RAI schema language at present, note the following quote from the latest W3C XHTML 2.0 working draft in the 'Status of This Document' section: "This version includes an early implementation of XHTML 2.0 in RELAX NG [RELAXNG [p.247] ], but does not include the implementations in DTD or XML Schema form. Those will be included in subsequent versions, once the content of this language stabilizes." This working draft is posted at: http://www.w3.org/TR/2006/WD-xhtml2-20060726 Notice in particular that the W3C HTML WG is using Relax NG until their specification content stabilizes. This approach coheres well with rapidly evolving IETF specifications. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Romascanu, Dan (Dan) > Sent: Friday, August 04, 2006 3:17 AM > To: Netconf Data Model Discussion; Netconf Mailing List (E-mail) > Cc: Cullen Jennings; Lisa Dusseault > Subject: FW: Relax NG use in RAI > > > > I believe that this may be of interest for the Netconf and > Netmod folks. > > > Dan > > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, August 03, 2006 9:18 PM > To: Lisa Dusseault; XML Directorate; Jon Peterson > Cc: IESG IESG; Henning Schulzrinne > Subject: Relax NG use in RAI > > > Hi all - I'm looking for some advice here. > > The RAI area uses XML all over the place and every time we > get to have a > discussion about DTD/Scheme/Relax NG. More than one person > has suggested > we could make life easier and stop the same discussion from happening > over and over again. I am considering sending an email that says > something like the following and I would like to get some input on how > to word this or if I should send it at all. Thanks, Cullen > > In the RAI area, when working with XML, many folks have come to the > conclusion that Relax NG is currently the preferred schema > language. > Authors are encouraged to use Relax NG unless there is a good > reason to > use something else. Ease of reuse of previous work could > certainly be a > good reason to choose something else. In the future, other things may > come along and this is not meant to block usage of better > tools when and > where they are more appropriate. > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006 -- to unsubscribe send a message to netconf-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 04 13:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93N9-0008Jt-V7 for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 13:22:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93N8-0005Ne-Fd for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 13:22:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G93Jp-000CEL-S6 for netconf-data@psg.com; Fri, 04 Aug 2006 17:18:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G93Jo-000CDt-7l for netconf@ops.ietf.org; Fri, 04 Aug 2006 17:18:40 +0000 Received: from [71.240.232.162] (helo=JMHLap3.stevecrocker.com) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G93Jj-0003YO-8A; Fri, 04 Aug 2006 13:18:35 -0400 Message-Id: <7.0.1.0.0.20060804131707.03f42938@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 04 Aug 2006 13:18:33 -0400 To: "McDonald, Ira" , "'Romascanu, Dan (Dan)'" , Netconf Data Model Discussion , "Netconf Mailing List (E-mail)" From: "Joel M. Halpern" Subject: RE: Relax NG use in RAI Cc: Cullen Jennings , Lisa Dusseault In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EEA9@mailsrvnt05.enet.shar plabs.com> References: <789E617C880666438EDEE30C2A3E8D10EEA9@mailsrvnt05.enet.sharplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112024907aab0a2d16047726900999613f1a09fb96a4f735602f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.240.232.162 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 I don't object to letting working groups try using relaxNG. It appears to have a number of useful properties. However, given the weak tool support available, as compared with XML Schema, I would be reluctant to see us require working groups to work that way. I realize that this means that for now each working group has to have the debate, but I do not see a practical alternative. Yours, Joel M. Halpern At 01:10 PM 8/4/2006, McDonald, Ira wrote: >Hi folks, > >In support of the proposal below to recommend Relax NG as >preferred RAI schema language at present, note the following >quote from the latest W3C XHTML 2.0 working draft in the >'Status of This Document' section: > > "This version includes an early implementation of XHTML 2.0 > in RELAX NG [RELAXNG [p.247] ], but does not include the > implementations in DTD or XML Schema form. Those will be > included in subsequent versions, once the content of this > language stabilizes." > >This working draft is posted at: > > http://www.w3.org/TR/2006/WD-xhtml2-20060726 > >Notice in particular that the W3C HTML WG is using Relax NG >until their specification content stabilizes. This approach >coheres well with rapidly evolving IETF specifications. > >Cheers, >- Ira > >Ira McDonald (Musician / Software Architect) >Blue Roof Music / High North Inc >PO Box 221 Grand Marais, MI 49839 >phone: +1-906-494-2434 >email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > > Behalf Of Romascanu, Dan (Dan) > > Sent: Friday, August 04, 2006 3:17 AM > > To: Netconf Data Model Discussion; Netconf Mailing List (E-mail) > > Cc: Cullen Jennings; Lisa Dusseault > > Subject: FW: Relax NG use in RAI > > > > > > > > I believe that this may be of interest for the Netconf and > > Netmod folks. > > > > > > Dan > > > > > > > > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Thursday, August 03, 2006 9:18 PM > > To: Lisa Dusseault; XML Directorate; Jon Peterson > > Cc: IESG IESG; Henning Schulzrinne > > Subject: Relax NG use in RAI > > > > > > Hi all - I'm looking for some advice here. > > > > The RAI area uses XML all over the place and every time we > > get to have a > > discussion about DTD/Scheme/Relax NG. More than one person > > has suggested > > we could make life easier and stop the same discussion from happening > > over and over again. I am considering sending an email that says > > something like the following and I would like to get some input on how > > to word this or if I should send it at all. Thanks, Cullen > > > > In the RAI area, when working with XML, many folks have come to the > > conclusion that Relax NG is currently the preferred schema > > language. > > Authors are encouraged to use Relax NG unless there is a good > > reason to > > use something else. Ease of reuse of previous work could > > certainly be a > > good reason to choose something else. In the future, other things may > > come along and this is not meant to block usage of better > > tools when and > > where they are more appropriate. > > > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > >-- >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006 > > >-- >to 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 04 18:29:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98Ah-00019F-NC for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 18:29:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G98Ag-0000X5-7Q for netconf-archive@lists.ietf.org; Fri, 04 Aug 2006 18:29:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G984i-0005ab-SB for netconf-data@psg.com; Fri, 04 Aug 2006 22:23:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G984h-0005aO-5o for netconf@ops.ietf.org; Fri, 04 Aug 2006 22:23:23 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k74MNM5J029961 for ; Fri, 4 Aug 2006 18:23:22 -0400 Received: (qmail 27936 invoked by uid 78); 4 Aug 2006 22:23:21 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 4 Aug 2006 22:23:21 -0000 Message-ID: <44D3C8D2.6080900@andybierman.com> Date: Fri, 04 Aug 2006 15:23:14 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Joel M. Halpern" CC: "McDonald, Ira" , "'Romascanu, Dan (Dan)'" , Netconf Data Model Discussion , "Netconf Mailing List (E-mail)" , Cullen Jennings , Lisa Dusseault Subject: Re: Relax NG use in RAI References: <789E617C880666438EDEE30C2A3E8D10EEA9@mailsrvnt05.enet.sharplabs.com> <7.0.1.0.0.20060804131707.03f42938@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20060804131707.03f42938@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Joel M. Halpern wrote: > I don't object to letting working groups try using relaxNG. It appears > to have a number of useful properties. > However, given the weak tool support available, as compared with XML > Schema, I would be reluctant to see us require working groups to work > that way. > I realize that this means that for now each working group has to have > the debate, but I do not see a practical alternative. This has been the rationale all along, and I'm not trying to go against it, but RelaxNG can be converted to XSD with free tools. IMO, none of the "XML languages" -- even RelaxNG Compact -- has the right mix of data modeling constructs and user-friendliness. SML is even harder to read than XSD -- a step backward in that dept., but a step forward in others. A workable solution is probably going to mean a powerful new DM language that has nested indexed tables and other powerful DM mechanisms, but is super easy to read and write by humans. This high level language can then be automatically translated to XSD using free tools. RelaxNG-NG. (But I call it NCX.) > > Yours, > Joel M. Halpern Andy > > At 01:10 PM 8/4/2006, McDonald, Ira wrote: >> Hi folks, >> >> In support of the proposal below to recommend Relax NG as >> preferred RAI schema language at present, note the following >> quote from the latest W3C XHTML 2.0 working draft in the >> 'Status of This Document' section: >> >> "This version includes an early implementation of XHTML 2.0 >> in RELAX NG [RELAXNG [p.247] ], but does not include the >> implementations in DTD or XML Schema form. Those will be >> included in subsequent versions, once the content of this >> language stabilizes." >> >> This working draft is posted at: >> >> http://www.w3.org/TR/2006/WD-xhtml2-20060726 >> >> Notice in particular that the W3C HTML WG is using Relax NG >> until their specification content stabilizes. This approach >> coheres well with rapidly evolving IETF specifications. >> >> Cheers, >> - Ira >> >> Ira McDonald (Musician / Software Architect) >> Blue Roof Music / High North Inc >> PO Box 221 Grand Marais, MI 49839 >> phone: +1-906-494-2434 >> email: imcdonald@sharplabs.com >> >> > -----Original Message----- >> > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >> > Behalf Of Romascanu, Dan (Dan) >> > Sent: Friday, August 04, 2006 3:17 AM >> > To: Netconf Data Model Discussion; Netconf Mailing List (E-mail) >> > Cc: Cullen Jennings; Lisa Dusseault >> > Subject: FW: Relax NG use in RAI >> > >> > >> > >> > I believe that this may be of interest for the Netconf and >> > Netmod folks. >> > >> > >> > Dan >> > >> > >> > >> > >> > -----Original Message----- >> > From: Cullen Jennings [mailto:fluffy@cisco.com] >> > Sent: Thursday, August 03, 2006 9:18 PM >> > To: Lisa Dusseault; XML Directorate; Jon Peterson >> > Cc: IESG IESG; Henning Schulzrinne >> > Subject: Relax NG use in RAI >> > >> > >> > Hi all - I'm looking for some advice here. >> > >> > The RAI area uses XML all over the place and every time we >> > get to have a >> > discussion about DTD/Scheme/Relax NG. More than one person >> > has suggested >> > we could make life easier and stop the same discussion from happening >> > over and over again. I am considering sending an email that says >> > something like the following and I would like to get some input on how >> > to word this or if I should send it at all. Thanks, Cullen >> > >> > In the RAI area, when working with XML, many folks have come to the >> > conclusion that Relax NG is currently the preferred schema >> > language. >> > Authors are encouraged to use Relax NG unless there is a good >> > reason to >> > use something else. Ease of reuse of previous work could >> > certainly be a >> > good reason to choose something else. In the future, other things may >> > come along and this is not meant to block usage of better >> > tools when and >> > where they are more appropriate. >> > >> > >> > >> > >> > -- >> > to unsubscribe send a message to netconf-request@ops.ietf.org with >> > the word 'unsubscribe' in a single line as the message text body. >> > archive: >> > >> >> -- >> No virus found in this outgoing message. >> Checked by AVG Free Edition. >> Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006 >> >> >> -- >> to 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 07 03:27:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9zWL-000435-Di for netconf-archive@lists.ietf.org; Mon, 07 Aug 2006 03:27:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9zWH-0001Wl-Np for netconf-archive@lists.ietf.org; Mon, 07 Aug 2006 03:27:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G9zRL-000C6f-Bl for netconf-data@psg.com; Mon, 07 Aug 2006 07:22:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G9zRJ-000C6O-JV for netconf@ops.ietf.org; Mon, 07 Aug 2006 07:22:17 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 64DCE4F0029; Mon, 7 Aug 2006 09:22:16 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 09:22:15 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 09:22:15 +0200 Message-ID: <44D6EA29.7040901@ericsson.com> Date: Mon, 07 Aug 2006 09:22:17 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: Callhome draft? References: <44D3648D.9040907@andybierman.com> In-Reply-To: <44D3648D.9040907@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2006 07:22:15.0692 (UTC) FILETIME=[357804C0:01C6B9F2] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hello, On the IETF Jurgen in the ISMS group presented a solution. Do you propose we base our solution on that one? I feel it would be good. He had some problems with security but I believe those can be solved. Balazs Andy Bierman wrote: > Hi, > > I was wondering if anyone is willing to be the Editor/author > of 2 drafts to fully specify the Callhome feature for both > BEEP and SSH. I don't know if this would be Informational, > Experimental, or standards track. > > If done correctly, not one sentence in the protocol or notification > drafts will be impacted by the Callhome feature. > > IMO, the "southbound interface" for Callhome is application-independent, > and should work the same for any protocol mapping to SSH or BEEP > (BEEP already has this part). The "northbound interface" of the > Callhome mechanism is protocol-specific, and a mapping to NETCONF > is needed. (NETCONF over BEEP already has this part.) > > I think there was interest at the Callhome BOF in a generic > solution, but I hope this doesn't mean the problem will > be abstracted so far away nobody ever works on it. > > > 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: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 07 19:47:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAEp8-0002Vv-RH for netconf-archive@lists.ietf.org; Mon, 07 Aug 2006 19:47:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAEp7-0002Q0-Gg for netconf-archive@lists.ietf.org; Mon, 07 Aug 2006 19:47:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAEkO-00069C-88 for netconf-data@psg.com; Mon, 07 Aug 2006 23:43:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAEkK-000683-Pr for netconf@ops.ietf.org; Mon, 07 Aug 2006 23:42:57 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k77NgtPb002671 for ; Mon, 7 Aug 2006 19:42:56 -0400 Received: (qmail 11057 invoked by uid 78); 7 Aug 2006 23:42:55 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 7 Aug 2006 23:42:55 -0000 Message-ID: <44D7D037.3080309@andybierman.com> Date: Mon, 07 Aug 2006 16:43:51 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: Callhome draft? References: <44D3648D.9040907@andybierman.com> <44D6EA29.7040901@ericsson.com> In-Reply-To: <44D6EA29.7040901@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Balazs Lengyel wrote: > Hello, > On the IETF Jurgen in the ISMS group presented a solution. Do you > propose we base our solution on that one? I feel it would be good. He > had some problems with security but I believe those can be solved. I guess that would take care of most of it, except for the direct mapping to NETCONF. > Balazs Andy > > Andy Bierman wrote: >> Hi, >> >> I was wondering if anyone is willing to be the Editor/author >> of 2 drafts to fully specify the Callhome feature for both >> BEEP and SSH. I don't know if this would be Informational, >> Experimental, or standards track. >> >> If done correctly, not one sentence in the protocol or notification >> drafts will be impacted by the Callhome feature. >> >> IMO, the "southbound interface" for Callhome is application-independent, >> and should work the same for any protocol mapping to SSH or BEEP >> (BEEP already has this part). The "northbound interface" of the >> Callhome mechanism is protocol-specific, and a mapping to NETCONF >> is needed. (NETCONF over BEEP already has this part.) >> >> I think there was interest at the Callhome BOF in a generic >> solution, but I hope this doesn't mean the problem will >> be abstracted so far away nobody ever works on it. >> >> >> thanks, >> Andy >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Aug 08 14:09:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAW1M-0005Lo-FO for netconf-archive@lists.ietf.org; Tue, 08 Aug 2006 14:09:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAW1L-0002O9-1K for netconf-archive@lists.ietf.org; Tue, 08 Aug 2006 14:09:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAVry-000Iga-50 for netconf-data@psg.com; Tue, 08 Aug 2006 17:59:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [206.18.177.51] (helo=alnrmhc11.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAVrt-000IgD-Q6 for netconf@ops.ietf.org; Tue, 08 Aug 2006 17:59:53 +0000 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060808175952b1100nr3e4e>; Tue, 8 Aug 2006 17:59:53 +0000 From: "David B Harrington" To: "'Balazs Lengyel'" , "'Andy Bierman'" Cc: "'Netconf \(E-mail\)'" Subject: RE: Callhome draft? Date: Tue, 8 Aug 2006 13:58:18 -0400 Message-ID: <066d01c6bb14$3b18f830$0400a8c0@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.2180 In-Reply-To: <44D6EA29.7040901@ericsson.com> Thread-Index: Aca58vWU7D1CuZieSMeyYknadTOkzQBH2cyQ Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi, It is unclear from your message just which proposal you refer to when saying Juergen presented a solution. I have seen a number of porposals considered in ISMS that relate to callhome, but none so far that solve all the problems. I don't believe that Juergen's proposal has been accepted by the ISMS WG yet. There is ongoing discussion about multiple approaches to session reuse and callhome functionality and data access controls that are related. As editor of the TMSM and SSHSM WG drafts, I believe the current consensus in ISMS is to permit session reuse regardless of whether the session was created as a R/R session or a notification session, in order to support a callhome functionality, if we can resolve the security issues presented by a client-server transport session versus the SNMPv3/VACM security requirements. Stay tuned, but the ISMS "solution" is not yet ready to be the basis of the Netconf WG solution. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Monday, August 07, 2006 3:22 AM > To: Andy Bierman > Cc: Netconf (E-mail) > Subject: Re: Callhome draft? > > Hello, > On the IETF Jurgen in the ISMS group presented a solution. Do > you propose we base our > solution on that one? I feel it would be good. He had some > problems with security but I > believe those can be solved. > Balazs > > Andy Bierman wrote: > > Hi, > > > > I was wondering if anyone is willing to be the Editor/author > > of 2 drafts to fully specify the Callhome feature for both > > BEEP and SSH. I don't know if this would be Informational, > > Experimental, or standards track. > > > > If done correctly, not one sentence in the protocol or notification > > drafts will be impacted by the Callhome feature. > > > > IMO, the "southbound interface" for Callhome is > application-independent, > > and should work the same for any protocol mapping to SSH or BEEP > > (BEEP already has this part). The "northbound interface" of the > > Callhome mechanism is protocol-specific, and a mapping to NETCONF > > is needed. (NETCONF over BEEP already has this part.) > > > > I think there was interest at the Callhome BOF in a generic > > solution, but I hope this doesn't mean the problem will > > be abstracted so far away nobody ever works on it. > > > > > > 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: > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Aug 08 14:24:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWFo-0004Af-4f for netconf-archive@lists.ietf.org; Tue, 08 Aug 2006 14:24:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWFm-0003uI-Mf for netconf-archive@lists.ietf.org; Tue, 08 Aug 2006 14:24:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAW9X-000KPP-8b for netconf-data@psg.com; Tue, 08 Aug 2006 18:18:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAW9U-000KPC-B5 for netconf@ops.ietf.org; Tue, 08 Aug 2006 18:18:04 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k78IHvok005949 for ; Tue, 8 Aug 2006 14:18:02 -0400 Received: (qmail 869 invoked by uid 78); 8 Aug 2006 18:16:14 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 8 Aug 2006 18:16:14 -0000 Message-ID: <44D8D4E6.804@andybierman.com> Date: Tue, 08 Aug 2006 11:16:06 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: David B Harrington CC: "'Balazs Lengyel'" , "'Netconf (E-mail)'" Subject: Re: Callhome draft? References: <066d01c6bb14$3b18f830$0400a8c0@china.huawei.com> In-Reply-To: <066d01c6bb14$3b18f830$0400a8c0@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.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Hi Dave, Thanks for this clarification. As I said in a previous email, this feature is generic enough that the protocol-independent bits should be done one way, in one document. There are protocol-specific bits, like the impact on the capabilities list in the NETCONF . IMO we also need a standard "reason-for-calling-home" mechanism. (Perhaps just a message, not rigid standard content). The other features are just bells and whistles. Andy > Hi, > > It is unclear from your message just which proposal you refer to when > saying Juergen presented a solution. I have seen a number of porposals > considered in ISMS that relate to callhome, but none so far that solve > all the problems. > > I don't believe that Juergen's proposal has been accepted by the ISMS > WG yet. There is ongoing discussion about multiple approaches to > session reuse and callhome functionality and data access controls that > are related. > > As editor of the TMSM and SSHSM WG drafts, I believe the current > consensus in ISMS is to permit session reuse regardless of whether the > session was created as a R/R session or a notification session, in > order to support a callhome functionality, if we can resolve the > security issues presented by a client-server transport session versus > the SNMPv3/VACM security requirements. > > Stay tuned, but the ISMS "solution" is not yet ready to be the basis > of the Netconf WG solution. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel >> Sent: Monday, August 07, 2006 3:22 AM >> To: Andy Bierman >> Cc: Netconf (E-mail) >> Subject: Re: Callhome draft? >> >> Hello, >> On the IETF Jurgen in the ISMS group presented a solution. Do >> you propose we base our >> solution on that one? I feel it would be good. He had some >> problems with security but I >> believe those can be solved. >> Balazs >> >> Andy Bierman wrote: >>> Hi, >>> >>> I was wondering if anyone is willing to be the Editor/author >>> of 2 drafts to fully specify the Callhome feature for both >>> BEEP and SSH. I don't know if this would be Informational, >>> Experimental, or standards track. >>> >>> If done correctly, not one sentence in the protocol or > notification >>> drafts will be impacted by the Callhome feature. >>> >>> IMO, the "southbound interface" for Callhome is >> application-independent, >>> and should work the same for any protocol mapping to SSH or BEEP >>> (BEEP already has this part). The "northbound interface" of the >>> Callhome mechanism is protocol-specific, and a mapping to NETCONF >>> is needed. (NETCONF over BEEP already has this part.) >>> >>> I think there was interest at the Callhome BOF in a generic >>> solution, but I hope this doesn't mean the problem will >>> be abstracted so far away nobody ever works on it. >>> >>> >>> 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: >> -- >> 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 Wed Aug 09 18:24:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwTO-0003VI-A8 for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 18:24:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwTN-0004EI-S9 for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 18:24:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAwN2-0001ES-Ot for netconf-data@psg.com; Wed, 09 Aug 2006 22:17:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAwN1-0001EG-RB for netconf@ops.ietf.org; Wed, 09 Aug 2006 22:17:47 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 09 Aug 2006 15:17:53 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="575932374:sNHT53786196" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 15:18:05 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Character encoding for Netconf messages? Date: Wed, 9 Aug 2006 15:18:05 -0700 Message-ID: In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EE92@mailsrvnt05.enet.sharplabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Character encoding for Netconf messages? Thread-Index: AcazOXdLrXziOVxfRDG4h0z27/68FwIx6Vlw From: "Kent Watsen" To: "McDonald, Ira" , "Andy Bierman" , "Randy Presuhn" Cc: X-OriginalArrivalTime: 09 Aug 2006 22:18:05.0686 (UTC) FILETIME=[AFC9B960:01C6BC01] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Should the WG decide which approach NetConf uses? Seem like its going to be one of: 1. Only UTF-8 (no XML declaration not needed per message) 2. At least UTF-8 (XML declaration needed per message) Either way, the spec needs to be updated to document the decision Thanks! Kent =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of McDonald, Ira Sent: Saturday, July 29, 2006 11:02 AM To: 'Andy Bierman'; Randy Presuhn Cc: netconf@ops.ietf.org Subject: RE: Character encoding for Netconf messages? Hi, The IESG policy on charsets has been stable for years, since publication of BCP 18/RFC 2277 (January 1998). Verbatim from section 3.1 'What charset to use': "All protocols MUST identify, for all character data, which charset is in use. Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text. Protocols MAY specify, in addition, how to use other charsets or other character encoding schemes for ISO 10646, such as UTF-16, but lack of an ability to use UTF-8 is a violation of this policy; such a violation would need a variance procedure ([BCP9] section 9) with clear and solid justification in the protocol specification document before being entered into or advanced upon the standards track." So, either an IETF standards-track protocol MUST only support UTF-8 (so that tagging is irrelevant over the wire) or it MUST always tag the charset in use in every over-the-wire message. If Netconf permits the use of UTF-16 over the wire without an 'encoding' attribute in the XML declaration, then Netconf needs a variance - not easy to get. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Wednesday, July 26, 2006 6:56 PM > To: Randy Presuhn > Cc: netconf@ops.ietf.org > Subject: Re: Character encoding for Netconf messages? >=20 >=20 > Randy Presuhn wrote: > > Hi - > >=20 > > If we specify a mandatory-to-implement encoding, I'd=20 > strongly suggest > > that it be UTF-8. > >=20 >=20 > Excellent topic for a VERY TBD WG work item!!! :-) >=20 > (I agree with you, but I'm coding for internationalization.) >=20 > That's not an easy decision, or one that should be made > as part of some ad-hoc design process. >=20 >=20 > > Randy >=20 > Andy >=20 >=20 > >=20 > > ----- Original Message -----=20 > > From: "Kent Watsen" > > To: > > Sent: Tuesday, July 25, 2006 7:46 PM > > Subject: Character encoding for Netconf messages? > >=20 > >=20 > >=20 > >=20 > > The Netconf spec does not require XML declarations (i.e. > version=3D"1.0" encoding=3D"UTF-8" ?>). However, both the SSH and = SOAP > > mapping specs show the use of XML declarations; though the=20 > BEEP mapping > > spec does not... =20 > >=20 > > =20 > >=20 > > Should NetConf specify a mandatory encoding (e.g. USASCII)=20 > or leave it > > up to implementations to decide? If it is up to the=20 > implementations to > > decide, then would that require the client to defer sending=20 > its > > until after receiving the server's in order to determine the > > encoding to use? > >=20 > > =20 > >=20 > > Would it make sense for the to be USASCII and to list all > > supported encodings as capabilities? - this seems flexible=20 > but then the > > NetConf spec would need to require an XML declaration on=20 > every message > >=20 > > =20 > >=20 > > Thanks! > >=20 > > Kent > >=20 > > =20 > >=20 > > -- > >=20 > > Kent Watsen > >=20 > > Software Architect > >=20 > > Juniper Networks > >=20 > > =20 > >=20 > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 > >=20 >=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 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.5/403 - Release Date: 7/28/2006 =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 Wed Aug 09 18:44:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwmy-0008Du-20 for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 18:44:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwmw-0006bp-MG for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 18:44:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAwjT-000335-Cc for netconf-data@psg.com; Wed, 09 Aug 2006 22:40:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [209.86.89.61] (helo=elasmtp-galgo.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAwjR-00032s-0I for netconf@ops.ietf.org; Wed, 09 Aug 2006 22:40:57 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WM78OMeo2WPXeSqsO2PjUn4j0QBlewHKXXm8voEohMbGySApKOvOllL9pNo1eKDS; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.245] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GAwjQ-0001Zr-EZ for netconf@ops.ietf.org; Wed, 09 Aug 2006 18:40:56 -0400 Message-ID: <000601c6bc05$2c571240$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: Character encoding for Netconf messages? Date: Wed, 9 Aug 2006 15:43:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af1ec30c5073d99fd02b84d483c72dfa78350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.245 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi - > From: "Kent Watsen" > To: "McDonald, Ira" ; "Andy Bierman" ; "Randy Presuhn" > Cc: > Sent: Wednesday, August 09, 2006 3:18 PM > Subject: RE: Character encoding for Netconf messages? ... > Seem like its going to be one of: > > 1. Only UTF-8 (no XML declaration not needed per message) > 2. At least UTF-8 (XML declaration needed per message) ... I think (1) makes sense. I haven't heard any convincing arguments that (2) would be worth the hassle. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 09 19:00:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAx2H-0004oj-Nm for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 19:00:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAx2G-000070-8M for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 19:00:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAwz3-0004Sc-Hi for netconf-data@psg.com; Wed, 09 Aug 2006 22:57:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAwz1-0004SO-T6 for netconf@ops.ietf.org; Wed, 09 Aug 2006 22:57:04 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k79Mv2dk013453 for ; Wed, 9 Aug 2006 18:57:02 -0400 Received: (qmail 16449 invoked by uid 78); 9 Aug 2006 22:57:02 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 9 Aug 2006 22:57:02 -0000 Message-ID: <44DA6838.5010205@andybierman.com> Date: Wed, 09 Aug 2006 15:56:56 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Kent Watsen CC: "McDonald, Ira" , Randy Presuhn , netconf@ops.ietf.org Subject: Re: Character encoding for Netconf messages? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Kent Watsen wrote: > > Should the WG decide which approach NetConf uses? > > Seem like its going to be one of: > > 1. Only UTF-8 (no XML declaration not needed per message) > 2. At least UTF-8 (XML declaration needed per message) > > Either way, the spec needs to be updated to document the decision > I disagree. Why does the NETCONF protocol have to specify the XML encoding scheme? That is part of the "XML header" or the "data model framework", but not really something that should be mandated right now in the protocol WG. Doesn't this depend on the data models and features of the agent? > Thanks! > Kent Andy > > > > > > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of McDonald, Ira > Sent: Saturday, July 29, 2006 11:02 AM > To: 'Andy Bierman'; Randy Presuhn > Cc: netconf@ops.ietf.org > Subject: RE: Character encoding for Netconf messages? > > Hi, > > The IESG policy on charsets has been stable for years, > since publication of BCP 18/RFC 2277 (January 1998). > Verbatim from section 3.1 'What charset to use': > > "All protocols MUST identify, for all character data, which charset is > in use. > > Protocols MUST be able to use the UTF-8 charset, which consists of > the ISO 10646 coded character set combined with the UTF-8 character > encoding scheme, as defined in [10646] Annex R (published in > Amendment 2), for all text. > > Protocols MAY specify, in addition, how to use other charsets or > other character encoding schemes for ISO 10646, such as UTF-16, but > lack of an ability to use UTF-8 is a violation of this policy; such a > violation would need a variance procedure ([BCP9] section 9) with > clear and solid justification in the protocol specification document > before being entered into or advanced upon the standards track." > > So, either an IETF standards-track protocol MUST only support > UTF-8 (so that tagging is irrelevant over the wire) or it MUST > always tag the charset in use in every over-the-wire message. > > If Netconf permits the use of UTF-16 over the wire without an > 'encoding' attribute in the XML declaration, then Netconf needs > a variance - not easy to get. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >> Behalf Of Andy Bierman >> Sent: Wednesday, July 26, 2006 6:56 PM >> To: Randy Presuhn >> Cc: netconf@ops.ietf.org >> Subject: Re: Character encoding for Netconf messages? >> >> >> Randy Presuhn wrote: >>> Hi - >>> >>> If we specify a mandatory-to-implement encoding, I'd >> strongly suggest >>> that it be UTF-8. >>> >> Excellent topic for a VERY TBD WG work item!!! :-) >> >> (I agree with you, but I'm coding for internationalization.) >> >> That's not an easy decision, or one that should be made >> as part of some ad-hoc design process. >> >> >>> Randy >> Andy >> >> >>> ----- Original Message ----- >>> From: "Kent Watsen" >>> To: >>> Sent: Tuesday, July 25, 2006 7:46 PM >>> Subject: Character encoding for Netconf messages? >>> >>> >>> >>> >>> The Netconf spec does not require XML declarations (i.e. >> version="1.0" encoding="UTF-8" ?>). However, both the SSH and SOAP >>> mapping specs show the use of XML declarations; though the >> BEEP mapping >>> spec does not... >>> >>> >>> >>> Should NetConf specify a mandatory encoding (e.g. USASCII) >> or leave it >>> up to implementations to decide? If it is up to the >> implementations to >>> decide, then would that require the client to defer sending >> its >>> until after receiving the server's in order to determine the >>> encoding to use? >>> >>> >>> >>> Would it make sense for the to be USASCII and to list all >>> supported encodings as capabilities? - this seems flexible >> but then the >>> NetConf spec would need to require an XML declaration on >> every message >>> >>> >>> 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: >>> >>> >> >> -- >> to 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 09 20:29:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAyQq-0000jv-7i for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 20:29:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAyQo-0001PD-RR for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 20:29:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAyMk-000Bfs-4r for netconf-data@psg.com; Thu, 10 Aug 2006 00:25:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [209.86.89.66] (helo=elasmtp-spurfowl.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAyMi-000Bfa-72 for netconf@ops.ietf.org; Thu, 10 Aug 2006 00:25:36 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cfc9JxTtjvlxaX9jfkRlTY/rkbn9uJP52qlVKiKtp0pLOHZL/WgYnG6vzJfgpM+5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.245] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GAyMh-0003EP-Ct for netconf@ops.ietf.org; Wed, 09 Aug 2006 20:25:35 -0400 Message-ID: <000c01c6bc13$cbe94220$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <44DA6838.5010205@andybierman.com> Subject: Re: Character encoding for Netconf messages? Date: Wed, 9 Aug 2006 17:27:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af3ea1a837b52d34a4d66cc40cc1b474b0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.245 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi - > From: "Andy Bierman" > To: "Kent Watsen" > Cc: "McDonald, Ira" ; "Randy Presuhn" ; > Sent: Wednesday, August 09, 2006 3:56 PM > Subject: Re: Character encoding for Netconf messages? ... > Why does the NETCONF protocol have to specify the XML encoding scheme? ... BCP 18 (RFC 2277) clause 3.1: | 3.1. What charset to use | | All protocols MUST identify, for all character data, which charset is | in use. Seems rather clear. Are you proposing that we ask the IESG for an exception? BCP 18 continues: | Protocols MUST be able to use the UTF-8 charset, which consists of | the ISO 10646 coded character set combined with the UTF-8 character | encoding scheme, as defined in [10646] Annex R (published in | Amendment 2), for all text. This also seems rather clear. What's the rationale for not addressing these requirements? Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 09 20:45:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAyfs-0004m4-1c for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 20:45:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAyfq-0002vI-Nf for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 20:45:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAycL-000D4p-IM for netconf-data@psg.com; Thu, 10 Aug 2006 00:41:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GAycK-000D4c-Og for netconf@ops.ietf.org; Thu, 10 Aug 2006 00:41:44 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7A0finl018418 for ; Wed, 9 Aug 2006 20:41:44 -0400 Received: (qmail 24202 invoked by uid 78); 10 Aug 2006 00:41:43 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 10 Aug 2006 00:41:43 -0000 Message-ID: <44DA80C2.1060204@andybierman.com> Date: Wed, 09 Aug 2006 17:41:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Randy Presuhn CC: netconf@ops.ietf.org Subject: Re: Character encoding for Netconf messages? References: <44DA6838.5010205@andybierman.com> <000c01c6bc13$cbe94220$6501a8c0@oemcomputer> In-Reply-To: <000c01c6bc13$cbe94220$6501a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Kent Watsen" >> Cc: "McDonald, Ira" ; "Randy Presuhn" ; >> Sent: Wednesday, August 09, 2006 3:56 PM >> Subject: Re: Character encoding for Netconf messages? > ... >> Why does the NETCONF protocol have to specify the XML encoding scheme? > ... > > BCP 18 (RFC 2277) clause 3.1: > > | 3.1. What charset to use > | > | All protocols MUST identify, for all character data, which charset is > | in use. > > Seems rather clear. Are you proposing that we ask the IESG for > an exception? > > BCP 18 continues: > > | Protocols MUST be able to use the UTF-8 charset, which consists of > | the ISO 10646 coded character set combined with the UTF-8 character > | encoding scheme, as defined in [10646] Annex R (published in > | Amendment 2), for all text. > > This also seems rather clear. > > What's the rationale for not addressing these requirements? > none I guess. Since the requirements are so clear, there isn't anything to discuss, and the documentation requirement is just another CLR -- NETCONF uses the UTF-8 charset. > Randy Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 09 22:25:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0EW-0001Pb-Mq for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 22:25:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB0EV-000066-DQ for netconf-archive@lists.ietf.org; Wed, 09 Aug 2006 22:25:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GB08p-000LQq-GW for netconf-data@psg.com; Thu, 10 Aug 2006 02:19:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GB08o-000LQW-JR for netconf@ops.ietf.org; Thu, 10 Aug 2006 02:19:22 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7A2JLPs017877 for ; Wed, 9 Aug 2006 22:19:22 -0400 Received: (qmail 25922 invoked by uid 78); 10 Aug 2006 02:19:21 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 10 Aug 2006 02:19:21 -0000 Message-ID: <44DA979E.5070403@andybierman.com> Date: Wed, 09 Aug 2006 19:19:10 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: FYI: 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: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, The WG meeting minutes from IETF #66 can be found on the meeting materials page: http://www3.ietf.org/proceedings/06jul/minutes/netconf.txt The minutes from the Montreal interim are still in progress and should hopefully be done before Friday. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Aug 12 17:43:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC1Gd-0004MV-3L for netconf-archive@lists.ietf.org; Sat, 12 Aug 2006 17:43:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC1Ga-0004SG-M5 for netconf-archive@lists.ietf.org; Sat, 12 Aug 2006 17:43:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GC19y-000GzX-1f for netconf-data@psg.com; Sat, 12 Aug 2006 21:36:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GC19c-000Gxo-VW for netconf@ops.ietf.org; Sat, 12 Aug 2006 21:36:25 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9811B4D33C; Sat, 12 Aug 2006 23:36:21 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28230-10; Sat, 12 Aug 2006 23:36:19 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 0A61F4D298; Sat, 12 Aug 2006 23:36:19 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 634067BAB96; Sat, 12 Aug 2006 23:36:17 +0200 (CEST) Date: Sat, 12 Aug 2006 23:36:16 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: Andy Bierman , "Netconf (E-mail)" Subject: Re: Callhome draft? Message-ID: <20060812213616.GA2203@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Balazs Lengyel , Andy Bierman , "Netconf (E-mail)" References: <44D3648D.9040907@andybierman.com> <44D6EA29.7040901@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D6EA29.7040901@ericsson.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Mon, Aug 07, 2006 at 09:22:17AM +0200, Balazs Lengyel wrote: > On the IETF Jurgen in the ISMS group presented a solution. Do you > propose we base our solution on that one? I feel it would be > good. He had some problems with security but I believe those can be > solved. I am less optimistic there is a reasonable generic solution for SSH anytime soon. So far, I have only collected a list of reasons why various approaches do _not_ work. It is too early to document a call home solution for SSH since we have not found one yet. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Aug 13 16:07:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCMF0-0002qw-L1 for netconf-archive@lists.ietf.org; Sun, 13 Aug 2006 16:07:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCMEx-0006Uq-BZ for netconf-archive@lists.ietf.org; Sun, 13 Aug 2006 16:07:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCM77-000LVh-6K for netconf-data@psg.com; Sun, 13 Aug 2006 19:59:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCM73-000LVT-MO for netconf@ops.ietf.org; Sun, 13 Aug 2006 19:59:10 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7DJx70J016461 for ; Sun, 13 Aug 2006 15:59:08 -0400 Received: (qmail 29416 invoked by uid 78); 13 Aug 2006 19:59:05 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 13 Aug 2006 19:59:05 -0000 Message-ID: <44DF8482.2080706@andybierman.com> Date: Sun, 13 Aug 2006 12:58:58 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Draft: Montreal NETCONF Interim Meeting Minutes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e09ca23b1e78625a9f2987ce57451043 Hi, I would like the people who were at the meeting to check these minutes for correctness. thanks, Andy ========================================================================= [DRAFT] Network Configuration WG (netconf) Montreal Interim Meeting Minutes July 14 and 15, 2006 ===================== Chairs: Simon Leinen Andy Bierman Notes: Andy Bierman, Juergen Shoenwaelder Minutes: Andy Bierman ----------------------------------------------- Agenda: - Interim Meeting Location IETF Headquarter Hotel: Delta Centre-Ville 777 University Street Montreal, Quebec, Canada, H3C 3Z7 Hotel WEB site: http://www.deltahotels.com/hotels/hotels.php?hotelId=35 - Interim Meeting Times Friday, July 14, 2006 (1:30 PM - 6:00 PM) Saturday, July 15, 2006 (9:00 AM - 6:00 PM) - Internet Drafts: - NETCONF Event Notifications draft-ietf-netconf-notification-02.txt - A SYSLOG Capability for NETCONF draft-shafer-netconf-syslog-00.txt - Functional Requirements - determine WG consensus on need and priority of Juergen's list http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications - Architecture - role of notifications within netconf - relationship to syslog and snmp notifications - scaling issues - security issues (session vs. signed msg, etc.) - standard RPC methods vs. new RPC methods - agent resource vs. NMS resource issues - Use within Sessions - endless RPC - mixed-mode (rpc operations and notifications) - single vs. multiple subscriptions within a single session - Transport Specific Support - use of channels (ssh, beep, what about soap?) - callhome support for agent initiated sessions - Agent Notification Configuration and Control Mechanism - config-data vs. subscription-data - RPCs used to configure and control agent notification generation - Notification Event Classes - WG consensus on specific list - Guidelines for selecting classifications - Notification Filtering - Configuration mechanism(s) - Agent processing model - Notification Header Content - Syntax and semantics of data included in all notifications - Standard Notification Content - WG consensus on 0 or more fully-specified standard notifications - Full syntax and semantics of each standard notification - Read-only (monitoring) data for agent notification activity - Access Control Issues - Data Model and XSD Issues - Data model design - XSD correctness - Need for 'min-access' and 'max-access' - Documentation Issues - Terminology - Inclusion of non-normative text - Document section order - Document clarity - Choice of examples - Example correctness (need to validate against the XSD) --------------------------------------------------------------- Minutes: 1) Functional Requirements The interim meeting began with a continuation of the requirements discussion began in the WG meeting. The group tried to understand and prioritize each requirement, as captured by Juergen on th wiki page set up for this purpose. The following is a list of requirements (Rn), optional comments (Cn) on the issues discussed, and the resolutions (Sn) reached by the group. R1) Scope of work The solution should focus on notification support for configuration. C1) A basic disagreement within the WG is caused by the assumption of different implied application infrastructures, which would use a notification system in very different ways. The group interpreted this requirement to mean that configuration specific notification content should be defined for some configuration related tasks. S1) Accepted The solution is required to identify configuration changes on a device (i.e., NETCONF agent). R2) Hierarchical Data The solution should support structured hierarchical data. C2) This requirement is superseded by the content-independent requirement. S2) Rejected This requirement is not meaningful, since we have XML encoded data already, and we do not focus on the content of a notification. R3) Configuration Fragments The solution should be able to carry configuration fragments. S3) Rejected This requirement is not meaningful since we do not focus on the content of a notification. R4) Message Size Limit The solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes) S4) Rejected (N/A) The NETCONF protocol does not impose message size constraints. R5) Reliable Notification Delivery The solution should provide reliable delivery of notifications. C5) The WG discussed this issue at length on the mailing list. The result of that discussion was that the underlying transport protocol that NETCONF uses provides this feature. Application level ACKs for notifications have been rejected by the WG already. S5) Rejected The WG consensus on this issue has not changed. Application-level ACKs will not be supported. R6) Pre-configured Notification Destinations The solution should support pre-configured notification destinations. S6) Deferred The group determined this is a nice to have feature if there is a solution (done somewhere else)- ISMS is investigating whether there is a solution for SSH (seems to be easy over BEEP). This is just a notification specific instantiation of the call home feature (see below) R7) Agent Initiated Connections The solution should support agent initiated connections. C7) This is the Callhome feature. After much discussion, it was determined this feature should not be part of this notification work because it is not notification-specific. S7) Rejected This is a transport issue and as such must be handled outside the notification work. R8) Subscription Mechanism The solution should provide a subscription mechanism. C8) The actual meaning of this requirement was discussed at length. There was agreement (at the start) that a special RPC call to initiate notification delivery was reasonable, but also significant differences on the structure of that RPC method. S8) Accepted The term 'subscription' refers to the delivery of notifications (if any to send), and is bound to the lifetime of a session, not a more permanent subscription? An agent does not send notifications before asked to do so by the manager, i.e., the manager initiates the flow of notifications. R9) Multiple Subscriptions The solution should support multiple subscriptions. C9) The term was clarified to mean multiple subscriptions per session, since multiple sessions is already supported. S9) Rejected Multiple subscriptions over the same session are not required. R10) Filtering Mechanism The solution should provide a filtering mechanism. C10) There are many different interpretations of this feature, and the group determined that notification filtering means the manager somehow selects one of possibly several notification content output formats, and also somehow selects a subset of all possible notifications, based on some portion of the notification data content. S10) Accepted There continues to be WG consensus that this feature is needed. R11) Notification Names The solution should support notification names. S11) Rejected Notification names belong into the data content. S12) Notification Timestamps The solution should support notification timestamps. C12) The group discussed the need for timestamps in the notification header. The following diagram shows the 3 different timestamps that were considered: +----------+ +-----------+ +--------------+ | | | | | | | Mgr App | <---- | Agent Tx | <---- | Agent Detect | | | | | | | +----------+ +-----------+ +--------------+ TS-3 TS-2 TS-1 R12) Rejected Notification timestamps (TS-1) belong into the data content. A (possibly additional) timestamp (TS-2) to indicate when the agent transmitted the notification is not needed. R13) Notification Classes The solution should support notification classes. C13) This has been a contentious topic all along due to the overlapping classifications and the low probability of interoperability of complex NE devices, based solely on the text in the draft. S13) Rejected Notification classes belong into the data content. R14) Notification Info The solution should support notification info. C14) It was never really clear to everybody what this feature really meant. It was clear that this is just part of the data model specification. S14) Rejected Notification info belong into the data content. R15) Notification Content Specification The solution should provide the ability to specify the content of notifications to ensure predictability. S15) Rejected Notifications should be formally defined, to be addressed by data modeling language efforts. R16) Transport and Session Independent Notification Content The solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism, or the session-specific context. C16) This item deals with the identifiers used in the notification header to identify its classification in various ways. This feature was obsoleted by other related decisions. S16) Accepted Data content fully describes a notification; protocol information should not be not needed to understand a notification R17) Reference to Prior Configuration Change RPC Invocations The solution should allow notifications to refer to prior configuration change RPCs S17) Rejected This feature belongs into the data model content. R18) Do not bind Subscriptions to Connections The solution should not bind subscriptions to a connection. C18) It was unclear how this would ever work in NETCONF, since NETCONF is session-based. S18) Rejected Sounds a bit too complex - unclear what the real use case is. R19)Fate Sharing Notification Channels The channels for configuration change notifications should share fate with a session that includes a configuration channel. S19) Rejected Sessions are independent R20) Notification Replay The solution should support replay of locally logged notifications. C20) A manager needs to be able to distinguish between retrieval of logged notifications and replay of 'fresh' notifications This feature was explored in more detail later in the meeting, but the basic decision did not change. S20) Accepted (as capability) Could be an optional feature. R21) Message Chunking The solution should support message chunking capability in cases channels carry mixed RPCs. S21) Rejected Netconf does not interleave messages, no chunking/fragmentation needed. R22) Notification Transmitter Scaling The solution should scale to 30.000-100.000 nodes which may emit notifications. C22) R23 was removed because it is considered a duplicate of R22. S22) Rejected The netconf transport has already been decided. It is a transport and implementation specific matter how many concurrent sessions a single node can handle. 1.2) Requirements Evaluation Summary R1) Scope of work is configuration : Accepted R2) Hierarchical Data : Rejected R3) Configuration Fragments : Rejected R4) Message Size Limit : Rejected R5) Reliable Notification Delivery : Rejected R6) Preconfigured Notif. Destinations : Deferred R7) Agent Initiated Connections : Rejected R8) Subscription Mechanism : Accepted R9) Multiple Subscriptions : Rejected R10) Filtering Mechanism : Accepted R11) Notification Names : Rejected S12) Notification Timestamps : Rejected R13) Notification Classes : Rejected R14) Notification Info : Rejected R15) Notification Content Specification : Rejected R16) Independent Notification Content : Accepted R17) Reference to Prior Config RPCs : Rejected R18) Do not bind Subscriptions to Conn. : Rejected R19) Fate Sharing Notification Channels : Rejected R20) Notification Replay : Accepted (as capability) R21) Message Chunking : Rejected R22) Notification Transmitter Scaling : Rejected 2) Notification Delivery Control The group agreed that the real 'standards' goal is to provide for the delivery of standard NETCONF notifications without the need for any proprietary configuration to be used at all. There are different ways of approaching this problem, which required a lot of discussion to resolve. 2.1) Streams vs. Subscriptions The group discussed the details of the 'streams' design. The essential difference between the architectures in two drafts under consideration is that in the 'Streams' approach, the device has a set of potentially many distinct notification paths and data model encodings, and in the 'Subscription' approach, there is one conceptual notification path with a monolithic data model encompassing all possible data encodings and notification content data models. There are 2 distinct uses for multiple notification streams: 1) Different data encodings The same notification information may be encoded in multiple formats to accommodate legacy and new applications, such as syslog/RAW, syslog/COOKED, syslog/SD-Params, snmp/XML, etc. 2) Different event sources and/or event processing SW Not all events may be reported in all streams for various reasons. For example, console syslog messages and SNMP notifications rarely coincide, event for event. The application of session-specific parameters to connect to a stream or subscription are basically the same. There were no real objections to the mechanisms proposed in the 'Streams' approach. After some clarifications, the following model was agreed upon as the correct approach for the WG: ============================ (Within 1 NETCONF Agent) Part 1: Stream X: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor A | ---> | Model A | ---> X +--------+ +--------------+ +---------+ Stream Y: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor B | ---> | Model B | ---> Y +--------+ +--------------+ +---------+ Stream Z: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor C | ---> | Model C | ---> Z +--------+ +--------------+ +---------+ Part 2: +------------------------------------------------------+ | Session N | | +---------+ +--------+ +----------+ | | | Stream | | Filter | | Notif. | To | | | Select | ---> | Set | --> | Delivery | --> Mgr | | | (X,Y,Z) | | Config | | Capabil. | | | +---------+ +--------+ +----------+ | | | +------------------------------------------------------+ =============== 2.2) Group Consensus Points a) The solution will support multiple event streams. The exact capabilities and characteristics of a stream are determined by the agent, and advertised to the manager. The manager can select 1 of N streams, and optionally apply notification suppression filters to that stream. b) There will be a special named stream to carry "netconf" notifications, which is mandatory to implement. c) There might be other special named streams to carry "snmp" or "syslog" notifications. d) Filters are applied before a notification is shipped over a session. Filters are established as part of the stream selection (and they share fate with the underlying session). e) An empty filter matches all notifications. f) The configuration of streams is out of scope for the current work in this working group (part 1 above). g) The configuration of stream selection and notification suppression filters in in scope (part 2 above). h) Notification suppression filtering is data-model and stream dependent. i) It was noted that just because the WG can define a read-only data model which provides a 'snapshot' of the standard Stream or Filter parameters, the actual parameters used to configure these mechanisms may be different, and may not even map 1:1 to a given standard parameter. Therefore, the configuration of device-specific streams are not in scope. 3) Notification Use Within a Session 3.1) Long-Lived RPC vs. Mixed-Mode RPC It is assumed that a new RPC method will be created for the manager to use to cause the agent to start the delivery of notifications. All parameters needed to configure the session-specific delivery of notifications should be passed as parameters (by reference or by value). Additional features such as filtering and notification replay are also supported via this new RPC method. Once this new RPC method is invoked, there are three potential ways to ship notifications: A) One big (potentially never ending) to the initial request that sends multiple notifications and then eventually sends the closing end-tag to complete the RPC invocation. B) This new RPC method is followed by an reply, followed by a sequence of notifications, each one carrying a single notification message (but no other RPCs interleaved). It is unclear whether requests received by the agent would be queued until the notification delivery is terminated, simply ignored, or caused an to be returned. C) Same as b) but interleaved requests are allowed, and supported by the agent. This has been called 'mixed-mode'. The agent will buffer and properly interleave and elements as needed, on each session using this operational mode. This mode could be optional, and identified with an additional capability. [Ed. - XML declarations omitted from examples.] Example A: S: S: S: ... S: S: ... S: S: S: S: ]]>]]> Example B: S: S: S: S: ]]>]]> S: S: ... S: S: ]]>]]> Example C - Mixed Mode: S: S: S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> 3.2) Consensus Points a) The group decided to use "Approach B". b) An agent is not required to process RPC requests until the notification stream is done. c) A capability may be defined to announce that a server is capable to process RPCs while a notification stream is active on a session. d) Every implementation should be correct :-) e) The use cases for modifying the subscription filtering parameters frequently were not widely accepted, although a great deal of time was spent trying to convince the group that the feature is important. f) The WG needs to investigate the use of SSH channels for separation of operations and notifications. [ed. - does this imply multiple NETCONF sessions over a single SSH connection? What exactly does this mean?] 4) Notification Replay The group discussed a replay feature, which is not the same as a notification logging MIB. Instead of using the operation to retrieve stored notifications, the agent sends them as PDUs instead. There are several agent implementation requirements related to support for this feature: 4.1) Notification Storage The actual number of stored notifications available for retrieval at any given time is an agent implementation specific matter. Control parameters for this aspect of the feature are outside the scope of the current work. 4.2) Retrieval Mechanisms There was strong agreement that the CLI operation "tail -f logfile" is an important use case for the behavior of this feature. Translation: Retrieval of all matching notifications since an absolute or relative point in time, optionally followed by any new notifications since the request was started. In addition, a manager may request that all future notifications that match the selection criteria are delivered, so the request for stored and 'live' notifications can be mixed. 4.3) Live Notification Buffering If an agent supports notification replay, then it must also support the ability to defer delivery of new notifications while replayed notifications are currently being delivered on a particular session, thereby maintaining temporal order of the notification stream. 4.4) Issues a) How does a manager tell the difference between these 2 'empty response' conditions? 1) no notifications buffered for the requested time period 2) no notifications occurred during the requested time period b) Should there be a mode where stored and live notifications are mixed together, and temporal order is not preserved? c) How can this feature be realized with the fewest number of options and permutations, while still maintaining enough implementation flexibility? 5) Notification Data Models 5.1) State and Statistics A standard data model will be developed to provide some important information to managers: a) Available Streams The streams supported by the agent are stored by the agent for retrieval. b) State Data It is possible some notification management state data will be standardized to help applications debug and interact properly with the agent and other applications. 5.2) vs. The group discussed the use of the standard operation vs. collections of specific (standard and proprietary) operations. The biggest concern is that an ad-hoc collection of RPC calls is not as interoperable as one RPC method used with a common data framework. The issue is whether an agent must support the or operations for each data set returned in a 'special get' operation. One point raised was that a specialized operation might have the feature that it can pull things together from different subtrees and namespaces, e.g. with parameter 42 might retrieve all information related to vlan 42. Another use for a 'special get' RPC is to simplify access (e.g., iteration over data-model-specific 'chunks' such as rows in a table) to data which would otherwise be difficult to access efficiently using the standard RPC. The group agreed that the data expected for notifications did not warrant the use of special get RPCs, do a standard data model (for use with ) will be defined instead. 5.3) XML Data Hierarchy There was some discussion of the need for a standard data framework to give standard data a 'root', or more precisely, a unique absolute Xpath expression that describes the path from a conceptual XML root to any given element in any namespace. There are many different ways to organize XML data, but the target namespace and the nested element names are the two 'independent variables' that can be used to place XML data somewhere in a conceptual tree. The or element (used in many NETCONF operations) is a placeholder for the conceptual root of the XML data. All Xpath expressions and other filters that operate on NETCONF data use this point in the PDU as the root of the filter expression. It was noted that the NETCONF WG does not have to define a data organization framework for the entire data modeling universe, but rather just a small 'bootstrap' model that focused on the NETCONF protocol itself. The manner in which this small set of NETCONF standard data should be organized is still an open issue. There were some on-the-fly proposals made, but they provided more questions than answers: Q1: What is the granularity of a namespace? Q2: How does the granularity affect filter expressions? Q3: How should the element hierarchy be defined? a) /ietf/netconf/notifications (in 1 netconf-data namespace) b) /ietf:netconf/nc-data:notifications (in 2 namespaces) c) ??? The WG considers the data organization problem to be a high priority work item. An initial solution is required. It is possible that this initial data model will later be discarded in favor of a more comprehensive and widely deployed data model framework (if and when that happens). This is similar to how MIB-1 was later replaced by MIB-2 in the SNMP protocol. It is critical to define even a small set of standard data in order to begin interoperability testing and deployment of the NETCONF protocol. 5.4) Filtering The use of POSIX regular expressions is planned for this feature. There are still a lot of details that need to be written down before an interoperable filtering mechanism (i.e., same NETCONF behavior across agents) is fully defined. It was noted that the function library of XPATH 2.0 supports regular expressions in the function library. XPATH 1.0 does not have something like that. The authors will propose some text in the next revision of the Notifications I-D. 6) Document Integration The authors of both documents under consideration will rewrite the WG notification document, which will continue to be the deliverable for this work item. a) All the non-normative appendices will be removed. Data model specific issues need to be addressed with a separate WG effort. b) The 'Streams' approach and other recent design decisions will be implemented in the next revision of the WG draft, and the appropriate text will be moved or adapted from the 'Syslog Capability for Netconf' draft. New text will be written as needed. c) A new version will be ready soon, hopefully in September. 7) Summary The two drafts under consideration will be merged, and possibly design approaches (as decided by the WG) will be attempted by all the authors, in the next version of the 'Netconf Event Notifications' draft. Some specific feature mechanisms are data-dependent, and a minimal set of data modeling issues must be resolved by the WG in order for this notification work to be satisfactorily completed. --------------------------------------------------------------- Appendix A) Attendee List (Email addresses removed to reduce spam) Andy Bierman Simon Leinen Juergen Schoenwaelder David Harrington Dan Romascanu Opiuier Festor Sharon Chisholm Rodu State Hector Travino David Perkins Bert Wijnen William Chow Yoshifumi Atarashi Hideki Okita Vincent Cridlig Martin Bjorklund Balazs Lengyel James Balestriere Phil Shafer Rob Enns Brian Trammell -- to unsubscribe send a message to netconf-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 14 11:49:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCegu-0000Uo-GD for netconf-archive@lists.ietf.org; Mon, 14 Aug 2006 11:49:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCegr-0005tn-61 for netconf-archive@lists.ietf.org; Mon, 14 Aug 2006 11:49:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCeZA-000G8C-8J for netconf-data@psg.com; Mon, 14 Aug 2006 15:41:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCeZ3-000G7q-4e for netconf@ops.ietf.org; Mon, 14 Aug 2006 15:41:21 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7EFfCpC007109 for ; Mon, 14 Aug 2006 11:41:13 -0400 Received: (qmail 14757 invoked by uid 78); 14 Aug 2006 15:41:11 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 14 Aug 2006 15:41:11 -0000 Message-ID: <44E0998F.2040201@andybierman.com> Date: Mon, 14 Aug 2006 08:41:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Draft B: NETCONF Montreal Interim Meeting Minutes Content-Type: multipart/mixed; boundary="------------010101020800090601010201" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 313575717ab99ab523072fd0986ea42f This is a multi-part message in MIME format. --------------010101020800090601010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Trying again with less bugs, as an attachment. [Thunderbird drops a CR/LF if the previous line is whitespace/CR/LF instead of just CR/LF.] Andy --------------010101020800090601010201 Content-Type: text/plain; name="interim_minutes_B.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="interim_minutes_B.txt" [DRAFT B] Network Configuration WG (netconf) Montreal Interim Meeting Minutes July 14 and 15, 2006 ===================== Chairs: Simon Leinen Andy Bierman Notes: Andy Bierman, Juergen Shoenwaelder Minutes: Andy Bierman ----------------------------------------------- Agenda: - Interim Meeting Location IETF Headquarter Hotel: Delta Centre-Ville 777 University Street Montreal, Quebec, Canada, H3C 3Z7 Hotel WEB site: http://www.deltahotels.com/hotels/hotels.php?hotelId=35 - Interim Meeting Times Friday, July 14, 2006 (1:30 PM - 6:00 PM) Saturday, July 15, 2006 (9:00 AM - 6:00 PM) - Internet Drafts: - NETCONF Event Notifications draft-ietf-netconf-notification-02.txt - A SYSLOG Capability for NETCONF draft-shafer-netconf-syslog-00.txt - Functional Requirements - determine WG consensus on need and priority of Juergen's list http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications - Architecture - role of notifications within netconf - relationship to syslog and snmp notifications - scaling issues - security issues (session vs. signed msg, etc.) - standard RPC methods vs. new RPC methods - agent resource vs. NMS resource issues - Use within Sessions - endless RPC - mixed-mode (rpc operations and notifications) - single vs. multiple subscriptions within a single session - Transport Specific Support - use of channels (ssh, beep, what about soap?) - callhome support for agent initiated sessions - Agent Notification Configuration and Control Mechanism - config-data vs. subscription-data - RPCs used to configure and control agent notification generation - Notification Event Classes - WG consensus on specific list - Guidelines for selecting classifications - Notification Filtering - Configuration mechanism(s) - Agent processing model - Notification Header Content - Syntax and semantics of data included in all notifications - Standard Notification Content - WG consensus on 0 or more fully-specified standard notifications - Full syntax and semantics of each standard notification - Read-only (monitoring) data for agent notification activity - Access Control Issues - Data Model and XSD Issues - Data model design - XSD correctness - Need for 'min-access' and 'max-access' - Documentation Issues - Terminology - Inclusion of non-normative text - Document section order - Document clarity - Choice of examples - Example correctness (need to validate against the XSD) --------------------------------------------------------------- Minutes: 1) Functional Requirements The interim meeting began with a continuation of the requirements discussion began in the WG meeting. The group tried to understand and prioritize each requirement, as captured by Juergen on the wiki page set up for this purpose. The following is a list of requirements (Rn), optional comments (Cn) on the issues discussed, and the resolutions (Sn) reached by the group. R1) Scope of work The solution should focus on notification support for configuration. C1) A basic disagreement within the WG is caused by the assumption of different implied application infrastructures, which would use a notification system in very different ways. The group interpreted this requirement to mean that configuration specific notification content should be defined for some configuration related tasks. S1) Accepted The solution is required to identify configuration changes on a device (i.e., NETCONF agent). R2) Hierarchical Data The solution should support structured hierarchical data. C2) This requirement is superseded by the content-independent requirement. S2) Rejected This requirement is not meaningful, since we have XML encoded data already, and we do not focus on the content of a notification. R3) Configuration Fragments The solution should be able to carry configuration fragments. S3) Rejected This requirement is not meaningful since we do not focus on the content of a notification. R4) Message Size Limit The solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes). S4) Rejected (N/A) The NETCONF protocol does not impose message size constraints. R5) Reliable Notification Delivery The solution should provide reliable delivery of notifications. C5) The WG discussed this issue at length on the mailing list. The result of that discussion was that the underlying transport protocol that NETCONF uses provides this feature. Application level ACKs for notifications have been rejected by the WG already. S5) Rejected The WG consensus on this issue has not changed. Application-level ACKs will not be supported. R6) Pre-configured Notification Destinations The solution should support pre-configured notification destinations. S6) Deferred The group determined this is a nice to have feature if there is a solution (done somewhere else)- ISMS is investigating whether there is a solution for SSH (seems to be easy over BEEP). This is just a notification specific instantiation of the call home feature (see below). R7) Agent Initiated Connections The solution should support agent initiated connections. C7) This is the Callhome feature. After much discussion, it was determined this feature should not be part of this notification work because it is not notification-specific. S7) Rejected This is a transport issue and as such must be handled outside the notification work. R8) Subscription Mechanism The solution should provide a subscription mechanism. C8) The actual meaning of this requirement was discussed at length. There was agreement (at the start) that a special RPC call to initiate notification delivery was reasonable, but also significant differences on the structure of that RPC method. S8) Accepted The term 'subscription' refers to the delivery of notifications (if any to send), and is bound to the lifetime of a session, not a more permanent subscription. An agent does not send notifications before asked to do so by the manager, i.e., the manager initiates the flow of notifications. R9) Multiple Subscriptions The solution should support multiple subscriptions. C9) The term was clarified to mean multiple subscriptions per session, since multiple sessions is already supported. S9) Rejected Multiple subscriptions over the same session are not required. R10) Filtering Mechanism The solution should provide a filtering mechanism. C10) There are many different interpretations of this feature, and the group determined that notification filtering means the manager somehow selects one of possibly several notification content output formats, and also somehow selects a subset of all possible notifications, based on some portion of the notification data content. S10) Accepted There continues to be WG consensus that this feature is needed. R11) Notification Names The solution should support notification names. S11) Rejected Notification names belong into the data content. S12) Notification Timestamps The solution should support notification timestamps. C12) The group discussed the need for timestamps in the notification header. The following diagram shows the 3 different timestamps that were considered: +----------+ +-----------+ +--------------+ | | | | | | | Mgr App | <---- | Agent Tx | <---- | Agent Detect | | | | | | | +----------+ +-----------+ +--------------+ TS-3 TS-2 TS-1 R12) Rejected Notification timestamps (TS-1) belong into the data content. A (possibly additional) timestamp (TS-2) to indicate when the agent transmitted the notification is not needed. R13) Notification Classes The solution should support notification classes. C13) This has been a contentious topic all along due to the overlapping classifications and the low probability of interoperability of complex NE devices, based solely on the text in the draft. S13) Rejected Notification classes belong into the data content. R14) Notification Info The solution should support notification info. C14) It was never really clear to everybody what this feature really meant. It was clear that this is just part of the data model specification. S14) Rejected Notification info belongs in the data content. R15) Notification Content Specification The solution should provide the ability to specify the content of notifications to ensure predictability. S15) Rejected Notifications should be formally defined, to be addressed by data modeling language efforts. R16) Transport and Session Independent Notification Content The solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism, or the session-specific context. C16) This item deals with the identifiers used in the notification header to identify its classification in various ways. This feature was obsoleted by other related decisions. S16) Accepted Data content fully describes a notification; protocol information should not be not needed to understand a notification. R17) Reference to Prior Configuration Change RPC Invocations The solution should allow notifications to refer to prior configuration change RPCs. S17) Rejected This feature belongs into the data model content. R18) Do not bind Subscriptions to Connections The solution should not bind subscriptions to a connection. C18) It was unclear how this would ever work in NETCONF, since NETCONF is session-based. S18) Rejected Sounds a bit too complex - unclear what the real use case is. R19) Fate Sharing Notification Channels The channels for configuration change notifications should share fate with a session that includes a configuration channel. S19) Rejected NETCONF Sessions are independent of each other. R20) Notification Replay The solution should support replay of locally logged notifications. C20) A manager needs to be able to distinguish between retrieval of logged notifications and replay of 'fresh' notifications. This feature was explored in more detail later in the meeting, but the basic decision did not change. S20) Accepted (as capability) Could be an optional feature. R21) Message Chunking The solution should support message chunking capability in cases channels carry mixed RPCs. S21) Rejected Netconf does not interleave messages, no chunking/fragmentation needed. R22) Notification Transmitter Scaling The solution should scale to 30.000-100.000 nodes which may emit notifications. C22) R23 was removed because it is considered a duplicate of R22. S22) Rejected The netconf transport has already been decided. It is a transport and implementation specific matter how many concurrent sessions a single node can handle. 1.2) Requirements Evaluation Summary R1) Scope of work is configuration : Accepted R2) Hierarchical Data : Rejected R3) Configuration Fragments : Rejected R4) Message Size Limit : Rejected R5) Reliable Notification Delivery : Rejected R6) Preconfigured Notif. Destinations : Deferred R7) Agent Initiated Connections : Rejected R8) Subscription Mechanism : Accepted R9) Multiple Subscriptions : Rejected R10) Filtering Mechanism : Accepted R11) Notification Names : Rejected S12) Notification Timestamps : Rejected R13) Notification Classes : Rejected R14) Notification Info : Rejected R15) Notification Content Specification : Rejected R16) Independent Notification Content : Accepted R17) Reference to Prior Config RPCs : Rejected R18) Do not bind Subscriptions to Conn. : Rejected R19) Fate Sharing Notification Channels : Rejected R20) Notification Replay : Accepted (as capability) R21) Message Chunking : Rejected R22) Notification Transmitter Scaling : Rejected 2) Notification Delivery Control The group agreed that the real 'standards' goal is to provide for the delivery of standard NETCONF notifications without the need for any proprietary configuration to be used at all. There are different ways of approaching this problem, which required a lot of discussion to resolve. 2.1) Streams vs. Subscriptions The group discussed the details of the 'streams' design. The essential difference between the architectures in two drafts under consideration is that in the 'Streams' approach, the device has a set of potentially many distinct notification paths and data model encodings. In the 'Subscription' approach, there is one conceptual notification path with a monolithic data model encompassing all possible data encodings and notification content data models. There are 2 distinct uses for multiple notification streams: 1) Different data encodings The same notification information may be encoded in multiple formats to accommodate legacy and new applications, such as syslog/RAW, syslog/COOKED, syslog/SD-Params, snmp/XML, etc. 2) Different event sources and/or event processing SW Not all events may be reported in all streams for various reasons. For example, console syslog messages and SNMP notifications rarely coincide, event for event. The application of session-specific parameters to connect to a stream or subscription are basically the same in both drafts. There were no real objections to the mechanisms proposed in the 'Streams' approach. After some clarifications, the following model was agreed upon as the correct approach for the WG: ============================ (Within 1 NETCONF Agent) Part 1: Stream X: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor A | ---> | Model A | ---> X +--------+ +--------------+ +---------+ Stream Y: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor B | ---> | Model B | ---> Y +--------+ +--------------+ +---------+ Stream Z: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor C | ---> | Model C | ---> Z +--------+ +--------------+ +---------+ Part 2: +------------------------------------------------------+ | Session N | | +---------+ +--------+ +----------+ | | | Stream | | Filter | | Notif. | To | | | Select | ---> | Set | --> | Delivery | --> Mgr | | | (X,Y,Z) | | Config | | Capabil. | | | +---------+ +--------+ +----------+ | | | +------------------------------------------------------+ =============== 2.2) Group Consensus Points a) The solution will support multiple event streams. The exact capabilities and characteristics of a stream are determined by the agent, and advertised to the manager. The manager can select 1 of N streams, and optionally apply notification suppression filters to that stream. b) There will be a special named stream to carry "netconf" notifications, which is mandatory to implement. c) There might be other special named streams to carry "snmp" or "syslog" notifications. d) Filters are applied before a notification is shipped over a session. Filters are established as part of the stream selection (and they share fate with the underlying session). e) An empty filter matches all notifications. f) The configuration of streams is out of scope for the current work in this working group (part 1 above). g) The configuration of stream selection and notification suppression filters in in scope (part 2 above). h) Notification suppression filtering is data-model and stream dependent. i) It was noted that just because the WG can define a read-only data model which provides a 'snapshot' of the standard Stream or Filter parameters, the actual parameters used to configure these mechanisms may be different, and may not even map 1:1 to a given standard parameter. Therefore, the configuration of device-specific streams are not in scope. 3) Notification Use Within a Session 3.1) Long-Lived RPC vs. Mixed-Mode RPC It is assumed that a new RPC method will be created for the manager to use to cause the agent to start the delivery of notifications. All parameters needed to configure the session-specific delivery of notifications should be passed as parameters (by reference or by value). Additional features such as filtering and notification replay are also supported via this new RPC method. Once this new RPC method is invoked, there are three potential ways to ship notifications: A) One big (potentially never ending) to the initial request that sends multiple notifications and then eventually sends the closing end-tag to complete the RPC invocation. B) This new RPC method is followed by an reply, followed by a sequence of notifications, each one carrying a single notification message (but no other RPCs interleaved). It is unclear whether requests received by the agent would be queued until the notification delivery is terminated, simply ignored, or caused an to be returned. C) Same as b) but interleaved requests are allowed, and supported by the agent. This has been called 'mixed-mode'. The agent will buffer and properly interleave and elements as needed, on each session using this operational mode. This mode could be optional, and identified with an additional capability. [Ed. - XML declarations omitted from examples.] Example A: S: S: S: ... S: S: ... S: S: S: S: ]]>]]> Example B: S: S: S: S: ]]>]]> S: S: ... S: S: ]]>]]> Example C - Mixed Mode: S: S: S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> 3.2) Consensus Points a) The group decided to use "Approach B". b) An agent is not required to process RPC requests until the notification stream is done. c) A capability may be defined to announce that a server is capable to process RPCs while a notification stream is active on a session. d) Every implementation should be correct :-) e) The use cases for modifying the subscription filtering parameters frequently were not widely accepted, although a great deal of time was spent trying to convince the group that the feature is important. f) The WG needs to investigate the use of SSH channels for separation of operations and notifications. [ed. - does this imply multiple NETCONF sessions over a single SSH connection? What exactly does this mean?] 4) Notification Replay The group discussed a replay feature, which is not the same as a notification logging MIB. Instead of using the operation to retrieve stored notifications, the agent sends them as PDUs. There are several agent implementation requirements needed to support this feature: 4.1) Notification Storage The actual number of stored notifications available for retrieval at any given time is an agent implementation specific matter. Control parameters for this aspect of the feature are outside the scope of the current work. 4.2) Retrieval Mechanisms There was strong agreement that the CLI operation "tail -f logfile" is an important use case for the behavior of this feature. Translation: Retrieval of all matching notifications since an absolute or relative point in time, optionally followed by any new notifications since the request was started. In addition, a manager may request that all future notifications that match the selection criteria are delivered, so the request for stored and 'live' notifications can be mixed. There were no objections to any of the retrieval mechanisms defined in the draft. 4.3) Live Notification Buffering If an agent supports notification replay, then it must (should?) also support the ability to defer delivery of new notifications while replayed notifications are currently being delivered on a particular session, thereby maintaining temporal order of the notification stream. 4.4) Issues a) How does a manager tell the difference between these 2 'empty response' conditions? 1) no notifications buffered for the requested time period 2) no notifications occurred during the requested time period b) Should there be a mode where stored and live notifications are mixed together, and temporal order is not preserved? Should this be the only mode? Or should preserved order be the only mode? c) How can this feature be realized with the fewest number of options and permutations, while still maintaining enough implementation flexibility? 5) Notification Data Models 5.1) State and Statistics A standard data model will be developed to provide some important information to managers: a) Available Streams The streams supported by the agent are stored by the agent for retrieval. b) State Data It is possible some notification management state data will be standardized to help applications debug and interact properly with the agent and other applications. 5.2) vs. The group discussed the use of the standard operation vs. collections of specific (standard and proprietary) operations. The biggest concern is that an ad-hoc collection of RPC calls is not as interoperable as one RPC method used with a common data framework. The issue is whether an agent must support the or operations for each data set returned in a 'special get' operation. One point raised was that a specialized operation might have the feature that it can pull things together from different subtrees and namespaces, e.g. with parameter 42 might retrieve all information related to vlan 42. Another use for a 'special get' RPC is to simplify access (e.g., iteration over data-model-specific 'chunks' such as rows in a table) to data which would otherwise be difficult to access efficiently using the standard RPC. The group agreed that the data expected for notifications did not warrant the use of special get RPCs, and a standard data model (for use with ) will be defined instead. 5.3) XML Data Hierarchy There was some discussion of the need for a standard data framework to give standard data a 'root', or more precisely, a unique absolute Xpath expression that describes the path from a conceptual XML root to any given element in any namespace. There are many different ways to organize XML data, but the target namespace and the nested element names are the two 'independent variables' that can be used to place XML data somewhere in a conceptual tree. The or element (used in many NETCONF operations) is a placeholder for the conceptual root of the XML data. All Xpath expressions and other filters that operate on NETCONF data use this point in the PDU as the root of the filter expression. It was noted that the NETCONF WG does not have to define a data organization framework for the entire data modeling universe, but rather just a small 'bootstrap' model that focused on the NETCONF protocol itself. The manner in which this small set of NETCONF standard data should be organized is still an open issue. There were some on-the-fly proposals made, but they provided more questions than answers: Q1: What is the granularity of a namespace? Q2: How does the granularity affect filter expressions? Q3: How should the element hierarchy be defined? a) /ietf/netconf/notifications (in 1 netconf-data namespace) b) /ietf:netconf/nc-data:notifications (in 2 namespaces) c) ??? Q4: Object Naming - How should the canonical Object Instance Identifier for each data node be defined? - Is there a way to avoid the use of namespace prefixes when mixing vendor and IETF nodes? - How should multiple unnamed, position-dependent instances of a particular node be identified? e.g.: interface 'eth0' /ietf/interfaces/interface[name="eth0"] e.g.: 4th (unnamed) MAC address for interface 'eth0' (unnamed position-dependent instances start at position 0) /ietf/interfaces/interface[name="eth0"]/addresses/address[pos="3"] The WG considers the data organization problem to be a high priority work item. An initial solution is required. It is possible that this initial data model will later be discarded in favor of a more comprehensive and widely deployed data model framework (if and when that happens). This is similar to how MIB-1 was later replaced by MIB-2 in the SNMP protocol. It is critical to define even a small set of standard data in order to begin interoperability testing and deployment of the NETCONF protocol. 5.4) Filtering The use of POSIX regular expressions is planned for this feature. There are still a lot of details that need to be written down before an interoperable filtering mechanism (i.e., same NETCONF behavior across agents) is fully defined. It was noted that the function library of XPATH 2.0 supports regular expressions in the function library. XPATH 1.0 does not have something like that. The authors will propose some text in the next revision of the Notifications I-D. 6) Document Integration The authors of both documents under consideration will rewrite the WG notification document, which will continue to be the deliverable for this work item. a) All the non-normative appendices will be removed. Data model specific issues need to be addressed with a separate WG effort. b) The 'Streams' approach and other recent design decisions will be implemented in the next revision of the WG draft, and the appropriate text will be moved or adapted from the 'Syslog Capability for Netconf' draft. New text will be written as needed. c) A new version will be ready soon, hopefully in September. 7) Summary The two drafts under consideration will be merged, and possibly design approaches (as decided by the WG) will be attempted by all the authors, in the next version of the 'Netconf Event Notifications' draft. Some specific feature mechanisms are data-dependent, and a minimal set of data modeling issues must be resolved by the WG in order for this notification work to be satisfactorily completed. --------------------------------------------------------------- Appendix A) Attendee List (Email addresses removed to reduce spam) Andy Bierman Simon Leinen Juergen Schoenwaelder David Harrington Dan Romascanu Opiuier Festor Sharon Chisholm Rodu State Hector Travino David Perkins Bert Wijnen William Chow Yoshifumi Atarashi Hideki Okita Vincent Cridlig Martin Bjorklund Balazs Lengyel James Balestriere Phil Shafer Rob Enns Brian Trammell --------------010101020800090601010201-- -- to unsubscribe send a message to netconf-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 15 20:00:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD8pd-0006XS-G2 for netconf-archive@lists.ietf.org; Tue, 15 Aug 2006 20:00:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD8pW-0001Ay-Q4 for netconf-archive@lists.ietf.org; Tue, 15 Aug 2006 20:00:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GD8ie-000N0B-UP for netconf-data@psg.com; Tue, 15 Aug 2006 23:53:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GD8ic-000Mzw-Cc for netconf@ops.ietf.org; Tue, 15 Aug 2006 23:53:10 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id EBDF9560A1; Wed, 16 Aug 2006 01:53:08 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11993-03; Wed, 16 Aug 2006 01:53:05 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 0878056081; Wed, 16 Aug 2006 01:53:05 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id A2B567BC961; Wed, 16 Aug 2006 01:53:02 +0200 (CEST) Date: Wed, 16 Aug 2006 01:53:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Netconf (E-mail)" Subject: Re: Draft B: NETCONF Montreal Interim Meeting Minutes Message-ID: <20060815235302.GA10852@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , "Netconf (E-mail)" References: <44E0998F.2040201@andybierman.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <44E0998F.2040201@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 14, 2006 at 08:41:03AM -0700, Andy Bierman wrote: > Trying again with less bugs, as an attachment. Attached are some cosmetic fixes. There is one hidden question I like to comment on: > f) The WG needs to investigate the use of SSH channels > for separation of operations and notifications. > > [ed. - does this imply multiple NETCONF sessions over > a single SSH connection? What exactly does this mean?] SSH has the nice feature that it provides independent channels running over the same underlying TCP session and sharing the same SSH session keys etc. which makes them pretty lightweight mechanisms to separate different NETCONF notification channels or to seperate NETCONF notification channels from the "normal" NETCONF RPC channel. There was some discussion during the meeting whether the SSH mapping document actually allows us to make use of SSH channels or not. Item f) quoted above was recorded as an action item to carefully re-read draft-ietf-netconf-ssh- and to figure out what the document actually says and to compare that to what the intention was the document should be saying. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=typos --- interim_minutes_B.txt 2006-08-16 01:40:37.000000000 +0200 +++ interim_minutes_C.txt 2006-08-16 01:32:36.000000000 +0200 @@ -11,7 +11,7 @@ Simon Leinen Andy Bierman -Notes: Andy Bierman, Juergen Shoenwaelder +Notes: Andy Bierman, Juergen Schoenwaelder Minutes: Andy Bierman ----------------------------------------------- @@ -555,7 +555,7 @@ in this working group (part 1 above). g) The configuration of stream selection and notification - suppression filters in in scope (part 2 above). + suppression filters are in scope (part 2 above). h) Notification suppression filtering is data-model and stream dependent. @@ -573,7 +573,7 @@ 3.1) Long-Lived RPC vs. Mixed-Mode RPC It is assumed that a new RPC method will be created for -the manager to use to cause the agent to start the delivery +the manager to cause the agent to start the delivery of notifications. All parameters needed to configure the session-specific delivery of notifications should be passed as parameters (by reference or by value). --a8Wt8u1KmwUX3Y2C-- -- to unsubscribe send a message to netconf-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 16 12:48:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOZd-0004Gb-Jm for netconf-archive@lists.ietf.org; Wed, 16 Aug 2006 12:48:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDOZc-00037b-6I for netconf-archive@lists.ietf.org; Wed, 16 Aug 2006 12:48:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDOUC-000PTq-IB for netconf-data@psg.com; Wed, 16 Aug 2006 16:43:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level:=20 X-Spam-Status: No, score=3D-0.7 required=3D5.0 tests=3DBAYES=5F00,DNS=5F= Message-Id: From: owner-netconf@ops.ietf.org Date: Wed, 16 Aug 2006 16:43:20 +0000 X-Spam-Score: 1.7 (+) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c FROM=5FRFC=5FABUSE, =09DNS=5FFROM=5FRFC=5FPOST,MSGID=5FFROM=5FMTA=5FHEADER,SPF=5FPASS autol= earn=3Dno=20 =09version=3D3.1.1 Received: from [65.54.246.76] (helo=3Dbay0-omc1-s4.bay0.hotmail.com) =09by psg.com with esmtp (Exim 4.60 (FreeBSD)) =09(envelope-from ) =09id 1GDCtw-000HEi-SE =09for netconf@ops.ietf.org; Wed, 16 Aug 2006 04:21:08 +0000 Received: from hotmail.com ([64.4.51.41]) by bay0-omc1-s4.bay0.hotmail.= com with Microsoft SMTPSVC(6.0.3790.1830); =09 Tue, 15 Aug 2006 21:21:08 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSV= C; =09 Tue, 15 Aug 2006 21:21:08 -0700 Message-ID: Received: from 64.4.51.220 by by107fd.bay107.hotmail.msn.com with HTTP;= Sender: owner-netconf@ops.ietf.org Precedence: bulk =09Wed, 16 Aug 2006 04:21:05 GMT X-Originating-IP: [216.93.211.196] X-Originating-Email: [henrypootel@hotmail.com] X-Sender: henrypootel@hotmail.com From: "Henry Pootel" To: netconf@ops.ietf.org Bcc:=20 Subject: configuration use case question Date: Tue, 15 Aug 2006 21:21:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=3Dflowed X-OriginalArrivalTime: 16 Aug 2006 04:21:08.0278 (UTC) FILETIME=3D[65B3= FD60:01C6C0EB] I have been reading the NETCONF standard and think you people have done= a=20 great job! As I was reading, I thought of a question for which I haven= 't=20 found an answer. (I did find some posts that mentioned 'operational'=20= commands when talking about what the WG should work on next---notificat= ions,=20 or whatever---I hope my question doesn't just re-kindle an unrelated=20= discussion topic and my question is left un-answered!) Please help me=20= understand how this use case should work: There are commands in network devices, like "sdm prefer routing" on a C= isco=20 3750, that require a reload. However, I didn't see any built-in operat= ion=20 for rebooting a device. How should this interaction with a device, whe= n the=20 configuration option requires a reboot, work using NETCONF=3F I thought of a few options: 0. NETCONF does only configuration--operational commands like "reload" = are=20 outside the scope. 1. Ooops, we forgot about reload (not likely!) or just haven't got to i= t=20 yet. 2. It's left to the data model--devices can expose a configuration elem= ent=20 that results in a reload. Something like: reload The device would respond with a reply of , close the NETCONF=20 connection, and then reload. (After typing this in, it seems really ho= key.) 3. A device manufacturer can add a capability that adds a new operation= . =20 Something like this: urn:ietf:params:netconf:base:1.0 http:/example.com/schema/1.0/reload 4 And then you could send the device a NETCONF rpc with this new "reload"= =20 operation when required. The rpc would look like this: The device would respond with a reply of , close the NETCONF=20 connection, and then reload. (If NETCONF doesn't include a native "rel= oad"=20 operation, then this makes the most sense---to me anyway!) 4. How should it work=3F Thanks! Henry -- to unsubscribe send a message to netconf-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 16 12:49:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOac-0005B2-Qp for netconf-archive@lists.ietf.org; Wed, 16 Aug 2006 12:49:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDOaY-000396-Kc for netconf-archive@lists.ietf.org; Wed, 16 Aug 2006 12:49:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDOVx-000Pg5-C0 for netconf-data@psg.com; Wed, 16 Aug 2006 16:45:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDOVo-000Pco-QR for netconf@ops.ietf.org; Wed, 16 Aug 2006 16:45:06 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7GGiZWg011865 for ; Wed, 16 Aug 2006 12:44:51 -0400 Received: (qmail 12679 invoked by uid 78); 16 Aug 2006 16:44:34 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 16 Aug 2006 16:44:34 -0000 Message-ID: <44E34BDF.5080506@andybierman.com> Date: Wed, 16 Aug 2006 09:46:23 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: proceedings@ietf.org CC: "Netconf WG" Subject: minutes for NETCONF WG Interim Meeting, Montreal 2006 Content-Type: multipart/mixed; boundary="------------090505090702010104000108" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e19fe12a2b60f5c397f73b74149e8776 This is a multi-part message in MIME format. --------------090505090702010104000108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The NETCONF WG held an interim meeting after the Montreal IETF. These minutes are separate Interim Meeting minutes, and do not replace the IETF66 WG Meeting minutes in any way. thanks, Andy --------------090505090702010104000108 Content-Type: text/plain; name="interim_minutes_C.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="interim_minutes_C.txt" Network Configuration WG (netconf) Montreal Interim Meeting Minutes July 14 and 15, 2006 ===================== Chairs: Simon Leinen Andy Bierman Notes: Andy Bierman, Juergen Schoenwaelder Minutes: Andy Bierman ----------------------------------------------- Agenda: - Interim Meeting Location IETF Headquarter Hotel: Delta Centre-Ville 777 University Street Montreal, Quebec, Canada, H3C 3Z7 Hotel WEB site: http://www.deltahotels.com/hotels/hotels.php?hotelId=35 - Interim Meeting Times Friday, July 14, 2006 (1:30 PM - 6:00 PM) Saturday, July 15, 2006 (9:00 AM - 6:00 PM) - Internet Drafts: - NETCONF Event Notifications draft-ietf-netconf-notification-02.txt - A SYSLOG Capability for NETCONF draft-shafer-netconf-syslog-00.txt - Functional Requirements - determine WG consensus on need and priority of Juergen's list http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications - Architecture - role of notifications within netconf - relationship to syslog and snmp notifications - scaling issues - security issues (session vs. signed msg, etc.) - standard RPC methods vs. new RPC methods - agent resource vs. NMS resource issues - Use within Sessions - endless RPC - mixed-mode (rpc operations and notifications) - single vs. multiple subscriptions within a single session - Transport Specific Support - use of channels (ssh, beep, what about soap?) - callhome support for agent initiated sessions - Agent Notification Configuration and Control Mechanism - config-data vs. subscription-data - RPCs used to configure and control agent notification generation - Notification Event Classes - WG consensus on specific list - Guidelines for selecting classifications - Notification Filtering - Configuration mechanism(s) - Agent processing model - Notification Header Content - Syntax and semantics of data included in all notifications - Standard Notification Content - WG consensus on 0 or more fully-specified standard notifications - Full syntax and semantics of each standard notification - Read-only (monitoring) data for agent notification activity - Access Control Issues - Data Model and XSD Issues - Data model design - XSD correctness - Need for 'min-access' and 'max-access' - Documentation Issues - Terminology - Inclusion of non-normative text - Document section order - Document clarity - Choice of examples - Example correctness (need to validate against the XSD) --------------------------------------------------------------- Minutes: 1) Functional Requirements The interim meeting began with a continuation of the requirements discussion began in the WG meeting. The group tried to understand and prioritize each requirement, as captured by Juergen on the wiki page set up for this purpose. The following is a list of requirements (Rn), optional comments (Cn) on the issues discussed, and the resolutions (Sn) reached by the group. R1) Scope of work The solution should focus on notification support for configuration. C1) A basic disagreement within the WG is caused by the assumption of different implied application infrastructures, which would use a notification system in very different ways. The group interpreted this requirement to mean that configuration specific notification content should be defined for some configuration related tasks. S1) Accepted The solution is required to identify configuration changes on a device (i.e., NETCONF agent). R2) Hierarchical Data The solution should support structured hierarchical data. C2) This requirement is superseded by the content-independent requirement. S2) Rejected This requirement is not meaningful, since we have XML encoded data already, and we do not focus on the content of a notification. R3) Configuration Fragments The solution should be able to carry configuration fragments. S3) Rejected This requirement is not meaningful since we do not focus on the content of a notification. R4) Message Size Limit The solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes). S4) Rejected (N/A) The NETCONF protocol does not impose message size constraints. R5) Reliable Notification Delivery The solution should provide reliable delivery of notifications. C5) The WG discussed this issue at length on the mailing list. The result of that discussion was that the underlying transport protocol that NETCONF uses provides this feature. Application level ACKs for notifications have been rejected by the WG already. S5) Rejected The WG consensus on this issue has not changed. Application-level ACKs will not be supported. R6) Pre-configured Notification Destinations The solution should support pre-configured notification destinations. S6) Deferred The group determined this is a nice to have feature if there is a solution (done somewhere else)- ISMS is investigating whether there is a solution for SSH (seems to be easy over BEEP). This is just a notification specific instantiation of the call home feature (see below). R7) Agent Initiated Connections The solution should support agent initiated connections. C7) This is the Callhome feature. After much discussion, it was determined this feature should not be part of this notification work because it is not notification-specific. S7) Rejected This is a transport issue and as such must be handled outside the notification work. R8) Subscription Mechanism The solution should provide a subscription mechanism. C8) The actual meaning of this requirement was discussed at length. There was agreement (at the start) that a special RPC call to initiate notification delivery was reasonable, but also significant differences on the structure of that RPC method. S8) Accepted The term 'subscription' refers to the delivery of notifications (if any to send), and is bound to the lifetime of a session, not a more permanent subscription. An agent does not send notifications before asked to do so by the manager, i.e., the manager initiates the flow of notifications. R9) Multiple Subscriptions The solution should support multiple subscriptions. C9) The term was clarified to mean multiple subscriptions per session, since multiple sessions is already supported. S9) Rejected Multiple subscriptions over the same session are not required. R10) Filtering Mechanism The solution should provide a filtering mechanism. C10) There are many different interpretations of this feature, and the group determined that notification filtering means the manager somehow selects one of possibly several notification content output formats, and also somehow selects a subset of all possible notifications, based on some portion of the notification data content. S10) Accepted There continues to be WG consensus that this feature is needed. R11) Notification Names The solution should support notification names. S11) Rejected Notification names belong into the data content. S12) Notification Timestamps The solution should support notification timestamps. C12) The group discussed the need for timestamps in the notification header. The following diagram shows the 3 different timestamps that were considered: +----------+ +-----------+ +--------------+ | | | | | | | Mgr App | <---- | Agent Tx | <---- | Agent Detect | | | | | | | +----------+ +-----------+ +--------------+ TS-3 TS-2 TS-1 R12) Rejected Notification timestamps (TS-1) belong into the data content. A (possibly additional) timestamp (TS-2) to indicate when the agent transmitted the notification is not needed. R13) Notification Classes The solution should support notification classes. C13) This has been a contentious topic all along due to the overlapping classifications and the low probability of interoperability of complex NE devices, based solely on the text in the draft. S13) Rejected Notification classes belong into the data content. R14) Notification Info The solution should support notification info. C14) It was never really clear to everybody what this feature really meant. It was clear that this is just part of the data model specification. S14) Rejected Notification info belongs in the data content. R15) Notification Content Specification The solution should provide the ability to specify the content of notifications to ensure predictability. S15) Rejected Notifications should be formally defined, to be addressed by data modeling language efforts. R16) Transport and Session Independent Notification Content The solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism, or the session-specific context. C16) This item deals with the identifiers used in the notification header to identify its classification in various ways. This feature was obsoleted by other related decisions. S16) Accepted Data content fully describes a notification; protocol information should not be not needed to understand a notification. R17) Reference to Prior Configuration Change RPC Invocations The solution should allow notifications to refer to prior configuration change RPCs. S17) Rejected This feature belongs into the data model content. R18) Do not bind Subscriptions to Connections The solution should not bind subscriptions to a connection. C18) It was unclear how this would ever work in NETCONF, since NETCONF is session-based. S18) Rejected Sounds a bit too complex - unclear what the real use case is. R19) Fate Sharing Notification Channels The channels for configuration change notifications should share fate with a session that includes a configuration channel. S19) Rejected NETCONF Sessions are independent of each other. R20) Notification Replay The solution should support replay of locally logged notifications. C20) A manager needs to be able to distinguish between retrieval of logged notifications and replay of 'fresh' notifications. This feature was explored in more detail later in the meeting, but the basic decision did not change. S20) Accepted (as capability) Could be an optional feature. R21) Message Chunking The solution should support message chunking capability in cases channels carry mixed RPCs. S21) Rejected Netconf does not interleave messages, no chunking/fragmentation needed. R22) Notification Transmitter Scaling The solution should scale to 30.000-100.000 nodes which may emit notifications. C22) R23 was removed because it is considered a duplicate of R22. S22) Rejected The netconf transport has already been decided. It is a transport and implementation specific matter how many concurrent sessions a single node can handle. 1.2) Requirements Evaluation Summary R1) Scope of work is configuration : Accepted R2) Hierarchical Data : Rejected R3) Configuration Fragments : Rejected R4) Message Size Limit : Rejected R5) Reliable Notification Delivery : Rejected R6) Preconfigured Notif. Destinations : Deferred R7) Agent Initiated Connections : Rejected R8) Subscription Mechanism : Accepted R9) Multiple Subscriptions : Rejected R10) Filtering Mechanism : Accepted R11) Notification Names : Rejected S12) Notification Timestamps : Rejected R13) Notification Classes : Rejected R14) Notification Info : Rejected R15) Notification Content Specification : Rejected R16) Independent Notification Content : Accepted R17) Reference to Prior Config RPCs : Rejected R18) Do not bind Subscriptions to Conn. : Rejected R19) Fate Sharing Notification Channels : Rejected R20) Notification Replay : Accepted (as capability) R21) Message Chunking : Rejected R22) Notification Transmitter Scaling : Rejected 2) Notification Delivery Control The group agreed that the real 'standards' goal is to provide for the delivery of standard NETCONF notifications without the need for any proprietary configuration to be used at all. There are different ways of approaching this problem, which required a lot of discussion to resolve. 2.1) Streams vs. Subscriptions The group discussed the details of the 'streams' design. The essential difference between the architectures in two drafts under consideration is that in the 'Streams' approach, the device has a set of potentially many distinct notification paths and data model encodings. In the 'Subscription' approach, there is one conceptual notification path with a monolithic data model encompassing all possible data encodings and notification content data models. There are 2 distinct uses for multiple notification streams: 1) Different data encodings The same notification information may be encoded in multiple formats to accommodate legacy and new applications, such as syslog/RAW, syslog/COOKED, syslog/SD-Params, snmp/XML, etc. 2) Different event sources and/or event processing SW Not all events may be reported in all streams for various reasons. For example, console syslog messages and SNMP notifications rarely coincide, event for event. The application of session-specific parameters to connect to a stream or subscription are basically the same in both drafts. There were no real objections to the mechanisms proposed in the 'Streams' approach. After some clarifications, the following model was agreed upon as the correct approach for the WG: ============================ (Within 1 NETCONF Agent) Part 1: Stream X: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor A | ---> | Model A | ---> X +--------+ +--------------+ +---------+ Stream Y: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor B | ---> | Model B | ---> Y +--------+ +--------------+ +---------+ Stream Z: +--------+ +--------------+ +---------+ | Event | | Event | | Data | | Source | ... | Processor C | ---> | Model C | ---> Z +--------+ +--------------+ +---------+ Part 2: +------------------------------------------------------+ | Session N | | +---------+ +--------+ +----------+ | | | Stream | | Filter | | Notif. | To | | | Select | ---> | Set | --> | Delivery | --> Mgr | | | (X,Y,Z) | | Config | | Capabil. | | | +---------+ +--------+ +----------+ | | | +------------------------------------------------------+ =============== 2.2) Group Consensus Points a) The solution will support multiple event streams. The exact capabilities and characteristics of a stream are determined by the agent, and advertised to the manager. The manager can select 1 of N streams, and optionally apply notification suppression filters to that stream. b) There will be a special named stream to carry "netconf" notifications, which is mandatory to implement. c) There might be other special named streams to carry "snmp" or "syslog" notifications. d) Filters are applied before a notification is shipped over a session. Filters are established as part of the stream selection (and they share fate with the underlying session). e) An empty filter matches all notifications. f) The configuration of streams is out of scope for the current work in this working group (part 1 above). g) The configuration of stream selection and notification suppression filters are in scope (part 2 above). h) Notification suppression filtering is data-model and stream dependent. i) It was noted that just because the WG can define a read-only data model which provides a 'snapshot' of the standard Stream or Filter parameters, the actual parameters used to configure these mechanisms may be different, and may not even map 1:1 to a given standard parameter. Therefore, the configuration of device-specific streams are not in scope. 3) Notification Use Within a Session 3.1) Long-Lived RPC vs. Mixed-Mode RPC It is assumed that a new RPC method will be created for the manager to cause the agent to start the delivery of notifications. All parameters needed to configure the session-specific delivery of notifications should be passed as parameters (by reference or by value). Additional features such as filtering and notification replay are also supported via this new RPC method. Once this new RPC method is invoked, there are three potential ways to ship notifications: A) One big (potentially never ending) to the initial request that sends multiple notifications and then eventually sends the closing end-tag to complete the RPC invocation. B) This new RPC method is followed by an reply, followed by a sequence of notifications, each one carrying a single notification message (but no other RPCs interleaved). It is unclear whether requests received by the agent would be queued until the notification delivery is terminated, simply ignored, or caused an to be returned. C) Same as b) but interleaved requests are allowed, and supported by the agent. This has been called 'mixed-mode'. The agent will buffer and properly interleave and elements as needed, on each session using this operational mode. This mode could be optional, and identified with an additional capability. [Ed. - XML declarations omitted from examples.] Example A: S: S: S: ... S: S: ... S: S: S: S: ]]>]]> Example B: S: S: S: S: ]]>]]> S: S: ... S: S: ]]>]]> Example C - Mixed Mode: S: S: S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> S: S: ... S: S: ]]>]]> 3.2) Consensus Points a) The group decided to use "Approach B". b) An agent is not required to process RPC requests until the notification stream is done. c) A capability may be defined to announce that a server is capable to process RPCs while a notification stream is active on a session. d) Every implementation should be correct :-) e) The use cases for modifying the subscription filtering parameters frequently were not widely accepted, although a great deal of time was spent trying to convince the group that the feature is important. f) The WG needs to investigate the use of SSH channels for separation of operations and notifications. SSH has the nice feature that it provides independent channels running over the same underlying TCP session and sharing the same SSH session keys etc., which makes them pretty lightweight mechanisms to separate different NETCONF notification channels, or to seperate NETCONF notification channels from the "normal" NETCONF RPC channel. There was some discussion during the meeting whether the SSH mapping document actually allows us to make use of SSH channels or not. Item f) above was recorded as an action item to carefully re-read draft-ietf-netconf-ssh- and to figure out what the document actually says and to compare that to what the intention was the document should be saying. 4) Notification Replay The group discussed a replay feature, which is not the same as a notification logging MIB. Instead of using the operation to retrieve stored notifications, the agent sends them as PDUs. There are several agent implementation requirements needed to support this feature: 4.1) Notification Storage The actual number of stored notifications available for retrieval at any given time is an agent implementation specific matter. Control parameters for this aspect of the feature are outside the scope of the current work. 4.2) Retrieval Mechanisms There was strong agreement that the CLI operation "tail -f logfile" is an important use case for the behavior of this feature. Translation: Retrieval of all matching notifications since an absolute or relative point in time, optionally followed by any new notifications since the request was started. In addition, a manager may request that all future notifications that match the selection criteria are delivered, so the request for stored and 'live' notifications can be mixed. There were no objections to any of the retrieval mechanisms defined in the draft. 4.3) Live Notification Buffering If an agent supports notification replay, then it must (should?) also support the ability to defer delivery of new notifications while replayed notifications are currently being delivered on a particular session, thereby maintaining temporal order of the notification stream. 4.4) Issues a) How does a manager tell the difference between these 2 'empty response' conditions? 1) no notifications buffered for the requested time period 2) no notifications occurred during the requested time period b) Should there be a mode where stored and live notifications are mixed together, and temporal order is not preserved? Should this be the only mode? Or should preserved order be the only mode? c) How can this feature be realized with the fewest number of options and permutations, while still maintaining enough implementation flexibility? 5) Notification Data Models 5.1) State and Statistics A standard data model will be developed to provide some important information to managers: a) Available Streams The streams supported by the agent are stored by the agent for retrieval. b) State Data It is possible some notification management state data will be standardized to help applications debug and interact properly with the agent and other applications. 5.2) vs. The group discussed the use of the standard operation vs. collections of specific (standard and proprietary) operations. The biggest concern is that an ad-hoc collection of RPC calls is not as interoperable as one RPC method used with a common data framework. The issue is whether an agent must support the or operations for each data set returned in a 'special get' operation. One point raised was that a specialized operation might have the feature that it can pull things together from different subtrees and namespaces, e.g. with parameter 42 might retrieve all information related to vlan 42. Another use for a 'special get' RPC is to simplify access (e.g., iteration over data-model-specific 'chunks' such as rows in a table) to data which would otherwise be difficult to access efficiently using the standard RPC. The group agreed that the data expected for notifications did not warrant the use of special get RPCs, and a standard data model (for use with ) will be defined instead. 5.3) XML Data Hierarchy There was some discussion of the need for a standard data framework to give standard data a 'root', or more precisely, a unique absolute Xpath expression that describes the path from a conceptual XML root to any given element in any namespace. There are many different ways to organize XML data, but the target namespace and the nested element names are the two 'independent variables' that can be used to place XML data somewhere in a conceptual tree. The or element (used in many NETCONF operations) is a placeholder for the conceptual root of the XML data. All Xpath expressions and other filters that operate on NETCONF data use this point in the PDU as the root of the filter expression. It was noted that the NETCONF WG does not have to define a data organization framework for the entire data modeling universe, but rather just a small 'bootstrap' model that focused on the NETCONF protocol itself. The manner in which this small set of NETCONF standard data should be organized is still an open issue. There were some on-the-fly proposals made, but they provided more questions than answers: Q1: What is the granularity of a namespace? Q2: How does the granularity affect filter expressions? Q3: How should the element hierarchy be defined? a) /ietf/netconf/notifications (in 1 netconf-data namespace) b) /ietf:netconf/nc-data:notifications (in 2 namespaces) c) ??? Q4: Object Naming - How should the canonical Object Instance Identifier for each data node be defined? - Is there a way to avoid the use of namespace prefixes when mixing vendor and IETF nodes? - How should multiple unnamed, position-dependent instances of a particular node be identified? e.g.: interface 'eth0' /ietf/interfaces/interface[name="eth0"] e.g.: 4th (unnamed) MAC address for interface 'eth0' (unnamed position-dependent instances start at position 0) /ietf/interfaces/interface[name="eth0"]/addresses/address[pos="3"] The WG considers the data organization problem to be a high priority work item. An initial solution is required. It is possible that this initial data model will later be discarded in favor of a more comprehensive and widely deployed data model framework (if and when that happens). This is similar to how MIB-1 was later replaced by MIB-2 in the SNMP protocol. It is critical to define even a small set of standard data in order to begin interoperability testing and deployment of the NETCONF protocol. 5.4) Filtering The use of POSIX regular expressions is planned for this feature. There are still a lot of details that need to be written down before an interoperable filtering mechanism (i.e., same NETCONF behavior across agents) is fully defined. It was noted that the function library of XPATH 2.0 supports regular expressions in the function library. XPATH 1.0 does not have something like that. The authors will propose some text in the next revision of the Notifications I-D. 6) Document Integration The authors of both documents under consideration will rewrite the WG notification document, which will continue to be the deliverable for this work item. a) All the non-normative appendices will be removed. Data model specific issues need to be addressed with a separate WG effort. b) The 'Streams' approach and other recent design decisions will be implemented in the next revision of the WG draft, and the appropriate text will be moved or adapted from the 'Syslog Capability for Netconf' draft. New text will be written as needed. c) A new version will be ready soon, hopefully in September. 7) Summary The two drafts under consideration will be merged, and possibly new design approaches (as decided by the WG) will be attempted by all the authors, in the next version of the 'Netconf Event Notifications' draft. Some specific feature mechanisms are data-dependent, and a minimal set of data modeling issues must be resolved by the WG in order for this notification work to be satisfactorily completed. --------------------------------------------------------------- Appendix A) Attendee List (Email addresses removed to reduce spam) Andy Bierman Simon Leinen Juergen Schoenwaelder David Harrington Dan Romascanu Opiuier Festor Sharon Chisholm Rodu State Hector Travino David Perkins Bert Wijnen William Chow Yoshifumi Atarashi Hideki Okita Vincent Cridlig Martin Bjorklund Balazs Lengyel James Balestriere Phil Shafer Rob Enns Brian Trammell --------------090505090702010104000108-- -- to unsubscribe send a message to netconf-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 16 14:25:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDQ5L-0004W6-8Y for netconf-archive@lists.ietf.org; Wed, 16 Aug 2006 14:25:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDQ5J-0008Il-Qb for netconf-archive@lists.ietf.org; Wed, 16 Aug 2006 14:25:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDQ20-0008dQ-T4 for netconf-data@psg.com; Wed, 16 Aug 2006 18:22:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDQ1z-0008dC-Ry for netconf@ops.ietf.org; Wed, 16 Aug 2006 18:22:20 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7GIMDsh025354 for ; Wed, 16 Aug 2006 14:22:17 -0400 Received: (qmail 14043 invoked by uid 78); 16 Aug 2006 18:22:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 16 Aug 2006 18:22:13 -0000 Message-ID: <44E362C8.6080600@andybierman.com> Date: Wed, 16 Aug 2006 11:24:08 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: Reload References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Hi, The method itself can be a reload operation: There is no value in a standard operation using proprietary CLI commands. It justs adds a layer of XML with no real purpose. The reload operation is actually much harder to standardize than it appears. In any case, this is a data model issue, and out of current WG scope. Andy >... > > I have been reading the NETCONF standard and think you people have done= > a=20 > great job! As I was reading, I thought of a question for which I haven= > 't=20 > found an answer. (I did find some posts that mentioned 'operational'=20= > > commands when talking about what the WG should work on next---notificat= > ions,=20 > or whatever---I hope my question doesn't just re-kindle an unrelated=20= > > discussion topic and my question is left un-answered!) Please help me=20= > > understand how this use case should work: > > There are commands in network devices, like "sdm prefer routing" on a C= > isco=20 > 3750, that require a reload. However, I didn't see any built-in operat= > ion=20 > for rebooting a device. How should this interaction with a device, whe= > n the=20 > configuration option requires a reboot, work using NETCONF=3F > > I thought of a few options: > > 0. NETCONF does only configuration--operational commands like "reload" = > are=20 > outside the scope. > > 1. Ooops, we forgot about reload (not likely!) or just haven't got to i= > t=20 > yet. > > 2. It's left to the data model--devices can expose a configuration elem= > ent=20 > that results in a reload. Something like: > > 0"> > > > > > > > reload > > > > > > The device would respond with a reply of , close the NETCONF=20 > connection, and then reload. (After typing this in, it seems really ho= > key.) > > 3. A device manufacturer can add a capability that adds a new operation= > . =20 > Something like this: > > > > > urn:ietf:params:netconf:base:1.0 > > > http:/example.com/schema/1.0/reload > > > 4 > > > And then you could send the device a NETCONF rpc with this new "reload"= > =20 > operation when required. The rpc would look like this: > > 0"> > > > > The device would respond with a reply of , close the NETCONF=20 > connection, and then reload. (If NETCONF doesn't include a native "rel= > oad"=20 > operation, then this makes the most sense---to me anyway!) > > 4. > > How should it work=3F > > Thanks! > > Henry > > > > > > -- > to 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 17 10:40:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDj2w-0000Ga-7E for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 10:40:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDj2p-0007ET-In for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 10:40:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDiwl-000JQ5-Fn for netconf-data@psg.com; Thu, 17 Aug 2006 14:34:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDiwj-000JPo-0l for netconf@ops.ietf.org; Thu, 17 Aug 2006 14:34:09 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0E7496E0001 for ; Thu, 17 Aug 2006 16:34:08 +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, 17 Aug 2006 16:34:07 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 16:34:07 +0200 Message-ID: <44E47E5F.1050009@ericsson.com> Date: Thu, 17 Aug 2006 16:34:07 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: Reload References: <44E362C8.6080600@andybierman.com> In-Reply-To: <44E362C8.6080600@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2006 14:34:07.0187 (UTC) FILETIME=[320DE230:01C6C20A] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Hello, I don't want to restart a debate that happened before I joined the mail group, so just as an observation: Ericsson widely uses standard operations; both on netconf and also on other similar hierarchical configuration interfaces. All custom commands share some common specifics that could be part of a standard, and their standard format would greatly help management tools. This is much more then just an extra XML layer as we (only) standardize the common features. Common features include: - all generic calls are executed on a specific managed object e.g. on interface=eth0, - have parameters that can be defined in the data model and type checked during execution - have return types and sometimes generic exception methods By defining a generic method you don't need to update capabilities and protocol mechanisms (new RPCs) just the data model for a new proprietary command. Most management tools will anyway be able to handle model based execution which can be easily formalized, but few will be able to handle extra capabilities. What Ericsson has done is to misuse the operation which can take input parameters and can supply back data. Later we will hopefully make our own generic RPC as it is missing in the standard. Some other protocols like LDAP also have a generic method (Extended operations). Balazs Andy Bierman wrote: > > Hi, > > The method itself can be a reload operation: > > > > > > There is no value in a standard operation > using proprietary CLI commands. > > It justs adds a layer of XML with no real purpose. > > The reload operation is actually much harder to standardize > than it appears. In any case, this is a data model issue, > and out of current WG scope. > > > Andy > > > >... >> >> I have been reading the NETCONF standard and think you people have done= >> a=20 >> great job! As I was reading, I thought of a question for which I haven= >> 't=20 >> found an answer. (I did find some posts that mentioned 'operational'=20= >> >> commands when talking about what the WG should work on next---notificat= >> ions,=20 >> or whatever---I hope my question doesn't just re-kindle an unrelated=20= >> >> discussion topic and my question is left un-answered!) Please help >> me=20= >> >> understand how this use case should work: >> >> There are commands in network devices, like "sdm prefer routing" on a C= >> isco=20 >> 3750, that require a reload. However, I didn't see any built-in operat= >> ion=20 >> for rebooting a device. How should this interaction with a device, whe= >> n the=20 >> configuration option requires a reboot, work using NETCONF=3F >> >> I thought of a few options: >> >> 0. NETCONF does only configuration--operational commands like "reload" = >> are=20 >> outside the scope. >> >> 1. Ooops, we forgot about reload (not likely!) or just haven't got to i= >> t=20 >> yet. >> >> 2. It's left to the data model--devices can expose a configuration elem= >> ent=20 >> that results in a reload. Something like: >> >> > 0"> >> >> >> >> >> >> >> reload >> >> >> >> >> >> The device would respond with a reply of , close the NETCONF=20 >> connection, and then reload. (After typing this in, it seems really ho= >> key.) >> >> 3. A device manufacturer can add a capability that adds a new operation= >> . =20 >> Something like this: >> >> >> >> >> urn:ietf:params:netconf:base:1.0 >> >> >> http:/example.com/schema/1.0/reload >> >> >> 4 >> >> >> And then you could send the device a NETCONF rpc with this new "reload"= >> =20 >> operation when required. The rpc would look like this: >> >> > 0"> >> >> >> >> The device would respond with a reply of , close the NETCONF=20 >> connection, and then reload. (If NETCONF doesn't include a native "rel= >> oad"=20 >> operation, then this makes the most sense---to me anyway!) >> >> 4. >> >> How should it work=3F >> >> Thanks! >> >> Henry >> >> >> >> >> >> -- >> to 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 17 11:06:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjSA-000449-CT for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 11:06:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDjS8-0003BH-S5 for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 11:06:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDjLq-000Mue-28 for netconf-data@psg.com; Thu, 17 Aug 2006 15:00:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDjLj-000MqQ-R4 for netconf@ops.ietf.org; Thu, 17 Aug 2006 15:00:00 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7HExwE2016352 for ; Thu, 17 Aug 2006 10:59:58 -0400 Received: (qmail 19137 invoked by uid 78); 17 Aug 2006 14:56:53 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 17 Aug 2006 14:56:53 -0000 Message-ID: <44E483AE.7030500@andybierman.com> Date: Thu, 17 Aug 2006 07:56:46 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: Reload References: <44E362C8.6080600@andybierman.com> <44E47E5F.1050009@ericsson.com> In-Reply-To: <44E47E5F.1050009@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Hi, A couple points: 1) The term 'standard' is being used rather loosely here. IMO, standards are produced by independent SDOs and independently implemented in an interoperable manner by many vendors. 2) The prot document clearly states how to add your own RPC operations in your own namespace. Hijacking the operation is just about as "wrong" as you can get (from a standards POV). Andy > Hello, > I don't want to restart a debate that happened before I joined the mail > group, so just as > an observation: > > Ericsson widely uses standard operations; both on netconf and > also on other similar > hierarchical configuration interfaces. > All custom commands share some common specifics that could be part of a > standard, and > their standard format would greatly help management tools. This is much > more then just an > extra XML layer as we (only) standardize the common features. Common > features include: > - all generic calls are executed on a specific managed object > e.g. on interface=eth0, > - have parameters that can be defined in the data model and type checked > during execution > - have return types and sometimes generic exception methods > > By defining a generic method you don't need to update > capabilities and protocol > mechanisms (new RPCs) just the data model for a new proprietary command. > Most management tools will anyway be able to handle model based > execution which can be > easily formalized, but few will be able to handle extra capabilities. > > What Ericsson has done is to misuse the operation which can take > input parameters > and can supply back data. Later we will hopefully make our own generic > RPC as it is > missing in the standard. > > Some other protocols like LDAP also have a generic method > (Extended operations). > > Balazs > > Andy Bierman wrote: >> >> Hi, >> >> The method itself can be a reload operation: >> >> >> >> >> >> There is no value in a standard operation >> using proprietary CLI commands. >> >> It justs adds a layer of XML with no real purpose. >> >> The reload operation is actually much harder to standardize >> than it appears. In any case, this is a data model issue, >> and out of current WG scope. >> >> >> Andy >> >> >> >... >>> >>> I have been reading the NETCONF standard and think you people have done= >>> a=20 >>> great job! As I was reading, I thought of a question for which I haven= >>> 't=20 >>> found an answer. (I did find some posts that mentioned >>> 'operational'=20= >>> >>> commands when talking about what the WG should work on next---notificat= >>> ions,=20 >>> or whatever---I hope my question doesn't just re-kindle an unrelated=20= >>> >>> discussion topic and my question is left un-answered!) Please help >>> me=20= >>> >>> understand how this use case should work: >>> >>> There are commands in network devices, like "sdm prefer routing" on a C= >>> isco=20 >>> 3750, that require a reload. However, I didn't see any built-in operat= >>> ion=20 >>> for rebooting a device. How should this interaction with a device, whe= >>> n the=20 >>> configuration option requires a reboot, work using NETCONF=3F >>> >>> I thought of a few options: >>> >>> 0. NETCONF does only configuration--operational commands like "reload" = >>> are=20 >>> outside the scope. >>> >>> 1. Ooops, we forgot about reload (not likely!) or just haven't got to i= >>> t=20 >>> yet. >>> >>> 2. It's left to the data model--devices can expose a configuration elem= >>> ent=20 >>> that results in a reload. Something like: >>> >>> >> 0"> >>> >>> >>> >>> >>> >>> >>> reload >>> >>> >>> >>> >>> >>> The device would respond with a reply of , close the NETCONF=20 >>> connection, and then reload. (After typing this in, it seems really ho= >>> key.) >>> >>> 3. A device manufacturer can add a capability that adds a new operation= >>> . =20 >>> Something like this: >>> >>> >>> >>> >>> urn:ietf:params:netconf:base:1.0 >>> >>> >>> http:/example.com/schema/1.0/reload >>> >>> >>> 4 >>> >>> >>> And then you could send the device a NETCONF rpc with this new "reload"= >>> =20 >>> operation when required. The rpc would look like this: >>> >>> >> 0"> >>> >>> >>> >>> The device would respond with a reply of , close the NETCONF=20 >>> connection, and then reload. (If NETCONF doesn't include a native "rel= >>> oad"=20 >>> operation, then this makes the most sense---to me anyway!) >>> >>> 4. >>> >>> How should it work=3F >>> >>> Thanks! >>> >>> Henry >>> >>> >>> >>> >>> >>> -- >>> to 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 17 11:31:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjqT-0007nF-MT for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 11:31:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDjqR-0004vv-Af for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 11:31:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDjmL-000Q00-3I for netconf-data@psg.com; Thu, 17 Aug 2006 15:27:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDjmK-000Pzl-JW for netconf@ops.ietf.org; Thu, 17 Aug 2006 15:27:28 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7HFRQ1Z070585; Thu, 17 Aug 2006 08:27:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7HFRQg16505; Thu, 17 Aug 2006 08:27:26 -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 k7HFRPwn056915; Thu, 17 Aug 2006 11:27:25 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200608171527.k7HFRPwn056915@idle.juniper.net> To: Balazs Lengyel cc: netconf@ops.ietf.org Subject: Re: Reload In-Reply-To: Your message of "Thu, 17 Aug 2006 16:34:07 +0200." <44E47E5F.1050009@ericsson.com> Date: Thu, 17 Aug 2006 11:27:25 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Balazs Lengyel writes: >By defining a generic method you don't need to update capabilities and protocol >mechanisms (new RPCs) just the data model for a new proprietary command. This puts your mgmt app in the spot of guessing which version of your data model a particular device supports. Using capabilities allows the mgmt app to know this, based on the capability. You could also define two distinct capabilities, one for the generic data model and one for that is version specific. 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 17 13:14:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDlRg-0006g0-CO for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:14:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDlRf-0004Tp-2Y for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:14:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlLD-000Bux-Oh for netconf-data@psg.com; Thu, 17 Aug 2006 17:07:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlLC-000Buk-KH for netconf@ops.ietf.org; Thu, 17 Aug 2006 17:07:34 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AE6568E0001; Thu, 17 Aug 2006 19:07:33 +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, 17 Aug 2006 19:07:33 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 19:07:32 +0200 Message-ID: <44E4A254.3040602@ericsson.com> Date: Thu, 17 Aug 2006 19:07:32 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Phil Shafer CC: netconf@ops.ietf.org Subject: Re: Reload References: <200608171527.k7HFRPwn056915@idle.juniper.net> In-Reply-To: <200608171527.k7HFRPwn056915@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2006 17:07:32.0971 (UTC) FILETIME=[A1210BB0:01C6C21F] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 I thought I could include the data model version in a capability indicating support for the data model itself. That is important even if I don't use . Balazs Phil Shafer wrote: > Balazs Lengyel writes: >> By defining a generic method you don't need to update capabilities and protocol >> mechanisms (new RPCs) just the data model for a new proprietary command. > > This puts your mgmt app in the spot of guessing which version of > your data model a particular device supports. Using capabilities > allows the mgmt app to know this, based on the capability. You > could also define two distinct capabilities, one for the generic > data model and one for that is version specific. > > Thanks, > Phil -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 17 13:17:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDlUz-0000YU-Bs for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:17:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDlUx-0004zJ-QZ for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:17:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlOy-000CFX-I8 for netconf-data@psg.com; Thu, 17 Aug 2006 17:11:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlOw-000CFK-Uh for netconf@ops.ietf.org; Thu, 17 Aug 2006 17:11:27 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 14E5D8E0001; Thu, 17 Aug 2006 19:11:26 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 19:11:25 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 19:11:25 +0200 Message-ID: <44E4A33D.1030205@ericsson.com> Date: Thu, 17 Aug 2006 19:11:25 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Andy Bierman CC: netconf@ops.ietf.org Subject: Re: Reload References: <44E362C8.6080600@andybierman.com> <44E47E5F.1050009@ericsson.com> <44E483AE.7030500@andybierman.com> In-Reply-To: <44E483AE.7030500@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2006 17:11:25.0361 (UTC) FILETIME=[2BA4F210:01C6C220] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 My point is only: I would see clear advantages for an operation in the netconf-protocol draft/rfc. Balazs Andy Bierman wrote: > Hi, > > A couple points: > > 1) The term 'standard' is being used rather loosely here. > IMO, standards are produced by independent SDOs and > independently implemented in an interoperable manner > by many vendors. BALAZS: Sorry, I meant the netconf-protocol draft or some similar IETF draft/RFC. > > 2) The prot document clearly states how to add your own RPC operations > in your own namespace. Hijacking the operation is just > about as "wrong" as you can get (from a standards POV). BALAZS: I agree that this is a misuse of get, I see it as a strictly temporary hack. > > Andy > > >> Hello, >> I don't want to restart a debate that happened before I joined the >> mail group, so just as >> an observation: >> >> Ericsson widely uses standard operations; both on netconf and >> also on other similar >> hierarchical configuration interfaces. >> All custom commands share some common specifics that could be part of >> a standard, and >> their standard format would greatly help management tools. This is >> much more then just an >> extra XML layer as we (only) standardize the common features. Common >> features include: >> - all generic calls are executed on a specific managed object >> e.g. on interface=eth0, >> - have parameters that can be defined in the data model and type >> checked during execution >> - have return types and sometimes generic exception methods >> >> By defining a generic method you don't need to update >> capabilities and protocol >> mechanisms (new RPCs) just the data model for a new proprietary command. >> Most management tools will anyway be able to handle model based >> execution which can be >> easily formalized, but few will be able to handle extra capabilities. >> >> What Ericsson has done is to misuse the operation which can take >> input parameters >> and can supply back data. Later we will hopefully make our own generic >> RPC as it is >> missing in the standard. >> >> Some other protocols like LDAP also have a generic method >> (Extended operations). >> >> Balazs >> >> Andy Bierman wrote: >>> >>> Hi, >>> >>> The method itself can be a reload operation: >>> >>> >>> >>> >>> >>> There is no value in a standard operation >>> using proprietary CLI commands. >>> >>> It justs adds a layer of XML with no real purpose. >>> >>> The reload operation is actually much harder to standardize >>> than it appears. In any case, this is a data model issue, >>> and out of current WG scope. >>> >>> >>> Andy >>> >>> >>> >... >>>> >>>> I have been reading the NETCONF standard and think you people have >>>> done= >>>> a=20 >>>> great job! As I was reading, I thought of a question for which I >>>> haven= >>>> 't=20 >>>> found an answer. (I did find some posts that mentioned >>>> 'operational'=20= >>>> >>>> commands when talking about what the WG should work on >>>> next---notificat= >>>> ions,=20 >>>> or whatever---I hope my question doesn't just re-kindle an >>>> unrelated=20= >>>> >>>> discussion topic and my question is left un-answered!) Please help >>>> me=20= >>>> >>>> understand how this use case should work: >>>> >>>> There are commands in network devices, like "sdm prefer routing" on >>>> a C= >>>> isco=20 >>>> 3750, that require a reload. However, I didn't see any built-in >>>> operat= >>>> ion=20 >>>> for rebooting a device. How should this interaction with a device, >>>> whe= >>>> n the=20 >>>> configuration option requires a reboot, work using NETCONF=3F >>>> >>>> I thought of a few options: >>>> >>>> 0. NETCONF does only configuration--operational commands like >>>> "reload" = >>>> are=20 >>>> outside the scope. >>>> >>>> 1. Ooops, we forgot about reload (not likely!) or just haven't got >>>> to i= >>>> t=20 >>>> yet. >>>> >>>> 2. It's left to the data model--devices can expose a configuration >>>> elem= >>>> ent=20 >>>> that results in a reload. Something like: >>>> >>>> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= >>>> 0"> >>>> >>>> >>>> >>>> >>>> >>>> >>>> reload >>>> >>>> >>>> >>>> >>>> >>>> The device would respond with a reply of , close the NETCONF=20 >>>> connection, and then reload. (After typing this in, it seems really >>>> ho= >>>> key.) >>>> >>>> 3. A device manufacturer can add a capability that adds a new >>>> operation= >>>> . =20 >>>> Something like this: >>>> >>>> >>>> >>>> >>>> urn:ietf:params:netconf:base:1.0 >>>> >>>> >>>> http:/example.com/schema/1.0/reload >>>> >>>> >>>> 4 >>>> >>>> >>>> And then you could send the device a NETCONF rpc with this new >>>> "reload"= >>>> =20 >>>> operation when required. The rpc would look like this: >>>> >>>> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= >>>> 0"> >>>> >>>> >>>> >>>> The device would respond with a reply of , close the NETCONF=20 >>>> connection, and then reload. (If NETCONF doesn't include a native >>>> "rel= >>>> oad"=20 >>>> operation, then this makes the most sense---to me anyway!) >>>> >>>> 4. >>>> >>>> How should it work=3F >>>> >>>> Thanks! >>>> >>>> Henry >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> to 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 17 13:30:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDlhT-0005T2-7Z for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:30:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDlhQ-00067K-MB for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:30:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlaI-000DPR-6L for netconf-data@psg.com; Thu, 17 Aug 2006 17:23:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlaG-000DPB-JW for netconf@ops.ietf.org; Thu, 17 Aug 2006 17:23:08 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7HHN2QR012910 for ; Thu, 17 Aug 2006 13:23:04 -0400 Received: (qmail 14654 invoked by uid 78); 17 Aug 2006 17:23:00 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 17 Aug 2006 17:23:00 -0000 Message-ID: <44E4A5ED.5010601@andybierman.com> Date: Thu, 17 Aug 2006 10:22:53 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: Reload References: <44E362C8.6080600@andybierman.com> <44E47E5F.1050009@ericsson.com> <44E483AE.7030500@andybierman.com> <44E4A33D.1030205@ericsson.com> In-Reply-To: <44E4A33D.1030205@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Hi, I am going to buy in for a nickel and consider what a standard operation would entail. Most of the details fall out for free because we have the NETCONF session to "wrapper" the security aspects. I strongly support the use of "special" RPCs when appropriate. IMO, the data-driven 'buttons' in SMI/SNMP need to be nuked, and a direct RPC method used instead (granularity up to the designer). So there is no existing RPC operation that could or should be hacked/extended to provide this feature. A new RPC operation is clearly the best option. However, this is what the WG describes as Takes 0 - N parameters of an opaque nature, and returns zero or more unspecified elements, and has zero or more unspecified side effects. IMO there is no point in this 'feature'. Unless there was more to it than this, the node has no real value. Andy > My point is only: I would see clear advantages for an operation > in the netconf-protocol draft/rfc. > Balazs > > Andy Bierman wrote: >> Hi, >> >> A couple points: >> >> 1) The term 'standard' is being used rather loosely here. >> IMO, standards are produced by independent SDOs and >> independently implemented in an interoperable manner >> by many vendors. > BALAZS: Sorry, I meant the netconf-protocol draft or some similar IETF > draft/RFC. >> >> 2) The prot document clearly states how to add your own RPC operations >> in your own namespace. Hijacking the operation is just >> about as "wrong" as you can get (from a standards POV). > BALAZS: I agree that this is a misuse of get, I see it as a strictly > temporary hack. >> >> Andy >> >> >>> Hello, >>> I don't want to restart a debate that happened before I joined the >>> mail group, so just as >>> an observation: >>> >>> Ericsson widely uses standard operations; both on netconf and >>> also on other similar >>> hierarchical configuration interfaces. >>> All custom commands share some common specifics that could be part of >>> a standard, and >>> their standard format would greatly help management tools. This is >>> much more then just an >>> extra XML layer as we (only) standardize the common features. Common >>> features include: >>> - all generic calls are executed on a specific managed object >>> e.g. on interface=eth0, >>> - have parameters that can be defined in the data model and type >>> checked during execution >>> - have return types and sometimes generic exception methods >>> >>> By defining a generic method you don't need to update >>> capabilities and protocol >>> mechanisms (new RPCs) just the data model for a new proprietary command. >>> Most management tools will anyway be able to handle model based >>> execution which can be >>> easily formalized, but few will be able to handle extra capabilities. >>> >>> What Ericsson has done is to misuse the operation which can >>> take input parameters >>> and can supply back data. Later we will hopefully make our own >>> generic RPC as it is >>> missing in the standard. >>> >>> Some other protocols like LDAP also have a generic method >>> (Extended operations). >>> >>> Balazs >>> >>> Andy Bierman wrote: >>>> >>>> Hi, >>>> >>>> The method itself can be a reload operation: >>>> >>>> >>>> >>>> >>>> >>>> There is no value in a standard operation >>>> using proprietary CLI commands. >>>> >>>> It justs adds a layer of XML with no real purpose. >>>> >>>> The reload operation is actually much harder to standardize >>>> than it appears. In any case, this is a data model issue, >>>> and out of current WG scope. >>>> >>>> >>>> Andy >>>> >>>> >>>> >... >>>>> >>>>> I have been reading the NETCONF standard and think you people have >>>>> done= >>>>> a=20 >>>>> great job! As I was reading, I thought of a question for which I >>>>> haven= >>>>> 't=20 >>>>> found an answer. (I did find some posts that mentioned >>>>> 'operational'=20= >>>>> >>>>> commands when talking about what the WG should work on >>>>> next---notificat= >>>>> ions,=20 >>>>> or whatever---I hope my question doesn't just re-kindle an >>>>> unrelated=20= >>>>> >>>>> discussion topic and my question is left un-answered!) Please help >>>>> me=20= >>>>> >>>>> understand how this use case should work: >>>>> >>>>> There are commands in network devices, like "sdm prefer routing" on >>>>> a C= >>>>> isco=20 >>>>> 3750, that require a reload. However, I didn't see any built-in >>>>> operat= >>>>> ion=20 >>>>> for rebooting a device. How should this interaction with a device, >>>>> whe= >>>>> n the=20 >>>>> configuration option requires a reboot, work using NETCONF=3F >>>>> >>>>> I thought of a few options: >>>>> >>>>> 0. NETCONF does only configuration--operational commands like >>>>> "reload" = >>>>> are=20 >>>>> outside the scope. >>>>> >>>>> 1. Ooops, we forgot about reload (not likely!) or just haven't got >>>>> to i= >>>>> t=20 >>>>> yet. >>>>> >>>>> 2. It's left to the data model--devices can expose a configuration >>>>> elem= >>>>> ent=20 >>>>> that results in a reload. Something like: >>>>> >>>>> >>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= >>>>> 0"> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> reload >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The device would respond with a reply of , close the NETCONF=20 >>>>> connection, and then reload. (After typing this in, it seems >>>>> really ho= >>>>> key.) >>>>> >>>>> 3. A device manufacturer can add a capability that adds a new >>>>> operation= >>>>> . =20 >>>>> Something like this: >>>>> >>>>> >>>>> >>>>> >>>>> urn:ietf:params:netconf:base:1.0 >>>>> >>>>> >>>>> http:/example.com/schema/1.0/reload >>>>> >>>>> >>>>> 4 >>>>> >>>>> >>>>> And then you could send the device a NETCONF rpc with this new >>>>> "reload"= >>>>> =20 >>>>> operation when required. The rpc would look like this: >>>>> >>>>> >>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= >>>>> 0"> >>>>> >>>>> >>>>> >>>>> The device would respond with a reply of , close the NETCONF=20 >>>>> connection, and then reload. (If NETCONF doesn't include a native >>>>> "rel= >>>>> oad"=20 >>>>> operation, then this makes the most sense---to me anyway!) >>>>> >>>>> 4. >>>>> >>>>> How should it work=3F >>>>> >>>>> Thanks! >>>>> >>>>> Henry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> to 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 17 13:45:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDlvv-0005Ns-JM for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:45:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDlvq-0007gB-QL for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:45:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlqN-000EvD-2d for netconf-data@psg.com; Thu, 17 Aug 2006 17:39:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [216.65.151.51] (helo=mail2.sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlqJ-000Eut-T3 for netconf@ops.ietf.org; Thu, 17 Aug 2006 17:39:44 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 603E31E15C5; Thu, 17 Aug 2006 10:39:43 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 17 Aug 2006 10:39:43 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEC6@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Andy Bierman' , Balazs Lengyel Cc: netconf@ops.ietf.org Subject: RE: Reload Date: Thu, 17 Aug 2006 10:39:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Hi Andy, Agreed that as you describe it below is a non-feature. But suppose had better features: (1) MUST have an input parameter of dataModelIdentifier (2) MUST return an output parameter of status like (3) etc. Why not try to make a better-than-strictly-opaque operation? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Thursday, August 17, 2006 1:23 PM > To: Balazs Lengyel > Cc: netconf@ops.ietf.org > Subject: Re: Reload > > > Hi, > > I am going to buy in for a nickel and consider > what a standard operation would entail. > > Most of the details fall out for free because we have > the NETCONF session to "wrapper" the security aspects. > > I strongly support the use of "special" RPCs when appropriate. > IMO, the data-driven 'buttons' in SMI/SNMP need to be nuked, > and a direct RPC method used instead (granularity up to the designer). > So there is no existing RPC operation that could or should be > hacked/extended to provide this feature. A new RPC operation > is clearly the best option. > > > However, this is what the WG describes as > > > Takes 0 - N parameters of an opaque nature, and returns > zero or more unspecified elements, and has zero or more > unspecified side effects. > > IMO there is no point in this 'feature'. > > Unless there was more to it than this, the node > has no real value. > > > Andy > > > > > > > My point is only: I would see clear advantages for an > operation > > in the netconf-protocol draft/rfc. > > Balazs > > > > Andy Bierman wrote: > >> Hi, > >> > >> A couple points: > >> > >> 1) The term 'standard' is being used rather loosely here. > >> IMO, standards are produced by independent SDOs and > >> independently implemented in an interoperable manner > >> by many vendors. > > BALAZS: Sorry, I meant the netconf-protocol draft or some > similar IETF > > draft/RFC. > >> > >> 2) The prot document clearly states how to add your own > RPC operations > >> in your own namespace. Hijacking the operation is just > >> about as "wrong" as you can get (from a standards POV). > > BALAZS: I agree that this is a misuse of get, I see it as a > strictly > > temporary hack. > >> > >> Andy > >> > >> > >>> Hello, > >>> I don't want to restart a debate that happened before I > joined the > >>> mail group, so just as > >>> an observation: > >>> > >>> Ericsson widely uses standard operations; both on > netconf and > >>> also on other similar > >>> hierarchical configuration interfaces. > >>> All custom commands share some common specifics that > could be part of > >>> a standard, and > >>> their standard format would greatly help management > tools. This is > >>> much more then just an > >>> extra XML layer as we (only) standardize the common > features. Common > >>> features include: > >>> - all generic calls are executed on a specific > managed object > >>> e.g. on interface=eth0, > >>> - have parameters that can be defined in the data model and type > >>> checked during execution > >>> - have return types and sometimes generic exception methods > >>> > >>> By defining a generic method you don't need to update > >>> capabilities and protocol > >>> mechanisms (new RPCs) just the data model for a new > proprietary command. > >>> Most management tools will anyway be able to handle model based > >>> execution which can be > >>> easily formalized, but few will be able to handle extra > capabilities. > >>> > >>> What Ericsson has done is to misuse the operation which can > >>> take input parameters > >>> and can supply back data. Later we will hopefully make our own > >>> generic RPC as it is > >>> missing in the standard. > >>> > >>> Some other protocols like LDAP also have a generic method > >>> (Extended operations). > >>> > >>> Balazs > >>> > >>> Andy Bierman wrote: > >>>> > >>>> Hi, > >>>> > >>>> The method itself can be a reload operation: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> There is no value in a standard operation > >>>> using proprietary CLI commands. > >>>> > >>>> It justs adds a layer of XML with no real purpose. > >>>> > >>>> The reload operation is actually much harder to standardize > >>>> than it appears. In any case, this is a data model issue, > >>>> and out of current WG scope. > >>>> > >>>> > >>>> Andy > >>>> > >>>> > >>>> >... > >>>>> > >>>>> I have been reading the NETCONF standard and think you > people have > >>>>> done= > >>>>> a=20 > >>>>> great job! As I was reading, I thought of a question > for which I > >>>>> haven= > >>>>> 't=20 > >>>>> found an answer. (I did find some posts that mentioned > >>>>> 'operational'=20= > >>>>> > >>>>> commands when talking about what the WG should work on > >>>>> next---notificat= > >>>>> ions,=20 > >>>>> or whatever---I hope my question doesn't just re-kindle an > >>>>> unrelated=20= > >>>>> > >>>>> discussion topic and my question is left un-answered!) > Please help > >>>>> me=20= > >>>>> > >>>>> understand how this use case should work: > >>>>> > >>>>> There are commands in network devices, like "sdm prefer > routing" on > >>>>> a C= > >>>>> isco=20 > >>>>> 3750, that require a reload. However, I didn't see any > built-in > >>>>> operat= > >>>>> ion=20 > >>>>> for rebooting a device. How should this interaction > with a device, > >>>>> whe= > >>>>> n the=20 > >>>>> configuration option requires a reboot, work using NETCONF=3F > >>>>> > >>>>> I thought of a few options: > >>>>> > >>>>> 0. NETCONF does only configuration--operational commands like > >>>>> "reload" = > >>>>> are=20 > >>>>> outside the scope. > >>>>> > >>>>> 1. Ooops, we forgot about reload (not likely!) or just > haven't got > >>>>> to i= > >>>>> t=20 > >>>>> yet. > >>>>> > >>>>> 2. It's left to the data model--devices can expose a > configuration > >>>>> elem= > >>>>> ent=20 > >>>>> that results in a reload. Something like: > >>>>> > >>>>> >>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= > >>>>> 0"> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> xmlns=3D=94http://example.com/schema/1.0/config/=94> > >>>>> reload > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The device would respond with a reply of , close > the NETCONF=20 > >>>>> connection, and then reload. (After typing this in, it seems > >>>>> really ho= > >>>>> key.) > >>>>> > >>>>> 3. A device manufacturer can add a capability that adds a new > >>>>> operation= > >>>>> . =20 > >>>>> Something like this: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> urn:ietf:params:netconf:base:1.0 > >>>>> > >>>>> > >>>>> http:/example.com/schema/1.0/reload > >>>>> > >>>>> > >>>>> 4 > >>>>> > >>>>> > >>>>> And then you could send the device a NETCONF rpc with this new > >>>>> "reload"= > >>>>> =20 > >>>>> operation when required. The rpc would look like this: > >>>>> > >>>>> >>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= > >>>>> 0"> > >>>>> > >>>>> > >>>>> > >>>>> The device would respond with a reply of , close > the NETCONF=20 > >>>>> connection, and then reload. (If NETCONF doesn't > include a native > >>>>> "rel= > >>>>> oad"=20 > >>>>> operation, then this makes the most sense---to me anyway!) > >>>>> > >>>>> 4. > >>>>> > >>>>> How should it work=3F > >>>>> > >>>>> Thanks! > >>>>> > >>>>> Henry > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> to 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: > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.1/421 - Release Date: 8/16/2006 -- to unsubscribe send a message to netconf-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 17 13:52:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDm2s-0007Jo-4l for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:52:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDm2q-0008D8-Qh for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:52:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlyT-000FVe-Si for netconf-data@psg.com; Thu, 17 Aug 2006 17:48:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDlyR-000FVG-TD for netconf@ops.ietf.org; Thu, 17 Aug 2006 17:48:08 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E2E0456207; Thu, 17 Aug 2006 19:48:06 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19824-01; Thu, 17 Aug 2006 19:48:04 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 3EC6E561F4; Thu, 17 Aug 2006 19:48:04 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id E75647BEC0A; Thu, 17 Aug 2006 19:48:01 +0200 (CEST) Date: Thu, 17 Aug 2006 19:48:01 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: Reload Message-ID: <20060817174801.GA3782@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Balazs Lengyel , netconf@ops.ietf.org References: <44E362C8.6080600@andybierman.com> <44E47E5F.1050009@ericsson.com> <44E483AE.7030500@andybierman.com> <44E4A33D.1030205@ericsson.com> <44E4A5ED.5010601@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E4A5ED.5010601@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Thu, Aug 17, 2006 at 10:22:53AM -0700, Andy Bierman wrote: > However, this is what the WG describes as > > > Takes 0 - N parameters of an opaque nature, and returns > zero or more unspecified elements, and has zero or more > unspecified side effects. > > IMO there is no point in this 'feature'. > > Unless there was more to it than this, the node > has no real value. I am not sure I agree. Such an "exec" feature allows a data model to formally describe what the in/out argument for an exec are. For example, a data model could define that there is an operation called "ping", that it takes an IP address as input and returns some statistics. This moves the definition of operations out of the protocol into the data model (and thus requires that there is a data model framework to support this). The other approach is to introduce all new verbs as protocol extensions which does not require any data modeling agreement. (This is for those people who believe the IETF is good at protocols but less so on data models.) I am not arguing in either direction. I am just questioning the statement that there is "no point in this 'feature'" and "has no real value". /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 17 13:57:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDm73-0008T7-VX for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:57:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDm72-0008W5-MB for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:57:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDm3b-000FsI-QK for netconf-data@psg.com; Thu, 17 Aug 2006 17:53:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDm30-000FpW-95 for netconf@ops.ietf.org; Thu, 17 Aug 2006 17:53:26 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7HHpxs5003287 for ; Thu, 17 Aug 2006 13:52:35 -0400 Received: (qmail 6328 invoked by uid 78); 17 Aug 2006 17:51:14 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 17 Aug 2006 17:51:14 -0000 Message-ID: <44E4AC8B.4020106@andybierman.com> Date: Thu, 17 Aug 2006 10:51:07 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "McDonald, Ira" CC: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: Reload References: <789E617C880666438EDEE30C2A3E8D10EEC6@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EEC6@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb McDonald, Ira wrote: > Hi Andy, > > Agreed that as you describe it below is a non-feature. > > But suppose had better features: > (1) MUST have an input parameter of dataModelIdentifier interesting idea -- what does this dataModelIdentifier look like? > (2) MUST return an output parameter of status like All NETCONF methods already have this feature. All of the standard RPC operations conform to a specific output: | { *, ? } Andy > (3) etc. > > Why not try to make a better-than-strictly-opaque > operation? That is the question I am implicitly asking the WG. Let's consider what etc. means -- the value and the details. > > Cheers, > - Ira Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Aug 18 04:07:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDzNl-0001Dg-3V for netconf-archive@lists.ietf.org; Fri, 18 Aug 2006 04:07:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDzNb-0000JX-Dz for netconf-archive@lists.ietf.org; Fri, 18 Aug 2006 04:07:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDzG2-0002b3-Cg for netconf-data@psg.com; Fri, 18 Aug 2006 07:59:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDzG0-0002Zs-7O for netconf@ops.ietf.org; Fri, 18 Aug 2006 07:59:08 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AFC6D4F005F; Fri, 18 Aug 2006 09:59:02 +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, 18 Aug 2006 09:59:02 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 09:59:01 +0200 Message-ID: <44E57345.8080305@ericsson.com> Date: Fri, 18 Aug 2006 09:59:01 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Andy Bierman , Balazs Lengyel , netconf@ops.ietf.org Subject: Re: Reload References: <44E362C8.6080600@andybierman.com> <44E47E5F.1050009@ericsson.com> <44E483AE.7030500@andybierman.com> <44E4A33D.1030205@ericsson.com> <44E4A5ED.5010601@andybierman.com> <20060817174801.GA3782@boskop.local> In-Reply-To: <20060817174801.GA3782@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2006 07:59:01.0882 (UTC) FILETIME=[2B0125A0:01C6C29C] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 For us the main point is to allow the definition of new s with minimum modification to the management SW. Yes the full value of relies on data modeling. You really gain a lot only if you have something like this in place (an excerpt from our DTD that defines our modeling language like SMI) You have to define the number of parameters and for each parameter you have to define the exact type. This allows our management system to handle new actions (s) based on the data model without modification. I know that netconf does not have (yet) a data model in place, but I could think about a two stage introduction of this feature. 1) define a standard with opaque parameters to allow users who already have a proprietary data model (actually everyone) to easily implement the function 2) define the necessary data model to gain the full value regards Balazs Juergen Schoenwaelder wrote: > On Thu, Aug 17, 2006 at 10:22:53AM -0700, Andy Bierman wrote: > >> However, this is what the WG describes as > >> >> >> Takes 0 - N parameters of an opaque nature, and returns >> zero or more unspecified elements, and has zero or more >> unspecified side effects. >> >> IMO there is no point in this 'feature'. >> >> Unless there was more to it than this, the node >> has no real value. > > I am not sure I agree. Such an "exec" feature allows a data model to > formally describe what the in/out argument for an exec are. For > example, a data model could define that there is an operation called > "ping", that it takes an IP address as input and returns some > statistics. This moves the definition of operations out of the > protocol into the data model (and thus requires that there is a data > model framework to support this). > > The other approach is to introduce all new verbs as protocol > extensions which does not require any data modeling agreement. (This > is for those people who believe the IETF is good at protocols but less > so on data models.) > > I am not arguing in either direction. I am just questioning the > statement that there is "no point in this 'feature'" and "has no real > value". > > /js > -- 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 18 09:19:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4G6-0007E4-LD for netconf-archive@lists.ietf.org; Fri, 18 Aug 2006 09:19:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE4G5-0001cL-7y for netconf-archive@lists.ietf.org; Fri, 18 Aug 2006 09:19:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GE499-000Pz0-KI for netconf-data@psg.com; Fri, 18 Aug 2006 13:12:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GE498-000Pyn-C9 for netconf@ops.ietf.org; Fri, 18 Aug 2006 13:12:22 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7IDCJP2028593 for ; Fri, 18 Aug 2006 09:12:20 -0400 Received: (qmail 26066 invoked by uid 78); 18 Aug 2006 13:11:38 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 18 Aug 2006 13:11:38 -0000 Message-ID: <44E5BC84.8080101@andybierman.com> Date: Fri, 18 Aug 2006 06:11:32 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: Reload References: <44E362C8.6080600@andybierman.com> <44E47E5F.1050009@ericsson.com> <44E483AE.7030500@andybierman.com> <44E4A33D.1030205@ericsson.com> <44E4A5ED.5010601@andybierman.com> <20060817174801.GA3782@boskop.local> <44E57345.8080305@ericsson.com> In-Reply-To: <44E57345.8080305@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Balazs Lengyel wrote: > For us the main point is to allow the definition of new s with > minimum modification to the management SW. > > Yes the full value of relies on data modeling. You really gain a > lot only if you have something like this in place (an excerpt from our > DTD that defines our modeling language like SMI) > > > > > > > You have to define the number of parameters and for each parameter you > have to define the exact type. This allows our management system to > handle new actions (s) based on the data model without modification. > > I know that netconf does not have (yet) a data model in place, but I > could think about a two stage introduction of this feature. > 1) define a standard with opaque parameters to allow users who > already have a proprietary data model (actually everyone) to easily > implement the function What are the implementation requirements? It seems like the one commonality is that the node used to "wrapper" the proprietary command is called 'exec'. IMO, this is not worth standardizing. In any event, this is not a chartered work item, and a written proposal would have to fly a lot further than "wrapper named exec" to get chartered. > 2) define the necessary data model to gain the full value > > regards Balazs > Andy > > > Juergen Schoenwaelder wrote: >> On Thu, Aug 17, 2006 at 10:22:53AM -0700, Andy Bierman wrote: >> >>> However, this is what the WG describes as >> >>> >>> >>> Takes 0 - N parameters of an opaque nature, and returns >>> zero or more unspecified elements, and has zero or more >>> unspecified side effects. >>> >>> IMO there is no point in this 'feature'. >>> >>> Unless there was more to it than this, the node >>> has no real value. >> >> I am not sure I agree. Such an "exec" feature allows a data model to >> formally describe what the in/out argument for an exec are. For >> example, a data model could define that there is an operation called >> "ping", that it takes an IP address as input and returns some >> statistics. This moves the definition of operations out of the >> protocol into the data model (and thus requires that there is a data >> model framework to support this). >> >> The other approach is to introduce all new verbs as protocol >> extensions which does not require any data modeling agreement. (This >> is for those people who believe the IETF is good at protocols but less >> so on data models.) >> >> I am not arguing in either direction. I am just questioning the >> statement that there is "no point in this 'feature'" and "has no real >> value". >> >> /js >> > -- to unsubscribe send a message to netconf-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 18 09:54:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4ny-0004pA-41 for netconf-archive@lists.ietf.org; Fri, 18 Aug 2006 09:54:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE4nv-0005B7-Oj for netconf-archive@lists.ietf.org; Fri, 18 Aug 2006 09:54:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GE4ia-0002t9-U3 for netconf-data@psg.com; Fri, 18 Aug 2006 13:49:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GE4iZ-0002sy-Uo for netconf@ops.ietf.org; Fri, 18 Aug 2006 13:49:00 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k7IDmwJ4025054 for ; Fri, 18 Aug 2006 09:48:58 -0400 Received: (qmail 591 invoked by uid 78); 18 Aug 2006 13:48:57 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 18 Aug 2006 13:48:57 -0000 Message-ID: <44E5C543.7060500@andybierman.com> Date: Fri, 18 Aug 2006 06:48:51 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: Reload References: <44E362C8.6080600@andybierman.com> <44E47E5F.1050009@ericsson.com> <44E483AE.7030500@andybierman.com> <44E4A33D.1030205@ericsson.com> <44E4A5ED.5010601@andybierman.com> <20060817174801.GA3782@boskop.local> <44E57345.8080305@ericsson.com> In-Reply-To: <44E57345.8080305@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Balazs Lengyel wrote: > For us the main point is to allow the definition of new s with > minimum modification to the management SW. > > Yes the full value of relies on data modeling. You really gain a > lot only if you have something like this in place (an excerpt from our > DTD that defines our modeling language like SMI) > > > > > > > You have to define the number of parameters and for each parameter you > have to define the exact type. This allows our management system to > handle new actions (s) based on the data model without modification. > IMO, this belongs in the schema, not the agent. There is already a mechanism to advertise data model capabilities. There is a plan in the WG to specify what a "module capability" looks like. The only place the schema should show up (wrt/ mandatory support) is in the capabilities exchange, in the PDU. some-uri-to-identify-the-data-model-namespace There is an assumption (by many people) that the DM language is XSD, and therefore a module is a element, which refers to a single target namespace. I don't like this assumption, but as long as a identifies a data model namespace, and not a module, then it doesn't matter. But the WG's plan to use capabilities for this purpose is still somewhat broken because we're not really supposed to parse URIs to get the capability name and version fields. http://example.com/schemas/foo/1.0 I don't think the NETCONF schema allows this extension, so we need to leave the ad-hoc parsing out-of-scope. I am not in favor of standardizing additional data model discovery mechanisms, especially before all the current chartered work is completed. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Aug 19 11:30:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GESlu-0004UO-Ee for netconf-archive@lists.ietf.org; Sat, 19 Aug 2006 11:30:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GESlr-0008Ih-3j for netconf-archive@lists.ietf.org; Sat, 19 Aug 2006 11:30:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GESgA-0002yl-OD for netconf-data@psg.com; Sat, 19 Aug 2006 15:24:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GESgA-0002yT-0W for netconf@ops.ietf.org; Sat, 19 Aug 2006 15:24:06 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7JFGAB5024703 for ; Sat, 19 Aug 2006 11:16:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C3A3.803781AA" Subject: Out of Office AutoReply: DELIVERY REPORTS ABOUT YOUR E-MAIL Date: Sat, 19 Aug 2006 18:24:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DELIVERY REPORTS ABOUT YOUR E-MAIL Thread-Index: AcbDo4AwRGSVADECShGQycr8Gg7b7AAAAAFi From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C3A3.803781AA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am out of office on vacation. I will be back on August 21, 2006. I = will not read and respond to e-mails during this period. If you need to = contact me urgently, please leave a voice mail message at my office = number. Regards, Dan ------_=_NextPart_001_01C6C3A3.803781AA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: DELIVERY REPORTS ABOUT YOUR = E-MAIL

I am out of office on vacation. I will be back on = August 21, 2006.  I will not read and respond to e-mails during = this period.  If you need to contact me urgently, please leave a = voice mail message at my office number.

Regards,

Dan

------_=_NextPart_001_01C6C3A3.803781AA-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From sugarbeatsquall@yahoo.fr Sun Aug 27 05:56:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHHNW-0003zr-4p for NETCONF-ARCHIVE@MEGATRON.IETF.ORG; Sun, 27 Aug 2006 05:56:30 -0400 Received: from [60.14.176.81] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHHMJ-0005jK-Us for NETCONF-ARCHIVE@MEGATRON.IETF.ORG; Sun, 27 Aug 2006 05:55:38 -0400 Subject: =?iso-2022-jp?B?GyRCIVpEeSRhQFokajRWJDgkKyEqISohWxsoQg==?= From: =?gb2312?B?Q0FNUEFJR05fUFJFU0VOVCE=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0008_01C6C938.F6DF78F0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C6C938.F6DF78F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6C938.F6DF78F0" ------=_NextPart_001_0009_01C6C938.F6DF78F0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoISElVSVqITwlYSE8JWskSDhA JCgkUCEhISEhIU14TVE8VDdjQX1DZiROJTklXiVDJTclZSVhITwlayEqISEhISIoIigiKCIoIigi KCIoIigiKCIoIigiKCIoIigiKCIoIigbKEI4LzMxGyRCJF4kRyRONHw0VjhCRGokTiFaJTUlXiE8 NkMkLSUtJWMlcyVaITwlcyVXJWwlPCVzJUghKiFbPEI7XENmJEckOSEqQCdIcyQzJE41ITJxJEsj RyNFI1QkNyRGMjwkNSQkISohISUtJWMlcyVaITwlczR8NFY9Kk47JF4kRxsoQiAbJEIkIiRIO0Qk ajZPJCskRyQ5ISobKEINChskQiRJJEokPyRLJGIkXiRAJF4kQCVBJWMlcyU5JE8kIiRqJF4kOSEq GyhCDQoNCg0KGyRCISEbKEJodHRwOi8vc21hc2gtbWFpbC5uZXQvamltdQ0KGyRCIVokQSRKJF8k SyVVJWohPCVhITwlayRIJE8hKSFbRVBPPyQqJGgkU0F3PHU/LiEiTXhNUSROJDkkWSRGJHJMNU5B JEc5VCQoJGslNSE8JVMlOSROO3YkRyQ5ISMhWiU5JV4lQyU3JWUlYSE8JWskSCRPISkhWyU5JV4l QyU3JWUhJiVhITwlayRPPCtNMyRLQy8kYiQsRVBPPyRHJC0lVSVqITwbKEIgGyRCJWEhPCVrJCwz WiQ3JGEkaxsoQiAbJEIlYSE8JWslPSVVJUgkRyQ5ISMkYiRBJG0kc0VQTz8kTzRKQzEkRyEiJG8k OiQrGyhCNRskQklDJEdFUE8/JEckLUE0JEZMNU5BJEc7SCQoJF4kOSEjRXklYSE8JWskTzktOXA8 fUZ+JEcxPzFEJDckRiQqJGokXiQ5JE4kRyEiQTQkRiROJTUhPCVTJTkkckw1TkEkR0RzNiEkNSQ7 JEZEOiQkJEYkKiRqJF4kOSEjRVBPPyROOl0hIjhEP00+cEpzJHI1LTpcJDkka0ksTVckTzhmOkIk JCReJDskcyEjGyhCIBskQiQqPz0kNzl+JF84ZSEiJDkkMCQ0TXhNUUQ6JDEkXiQ5ISNLXCUiJUkl bCU5IUolVyVtJVAlJCVAITw3QExzIUskRyRPO0hNUSQ3P0kkJD5sOWckTiVXJWklJCVZITwlSCEi TTckUyEiO0U7dhsoQiAbJEJNUSRIJDckRjtIJCRKLCQxJHIkOSRrJWEhPCVrJSIlSSVsJTkkNyRG OkdFLCRHJDkhIyVRJT0lMyVzJE8kYiRBJG0kcyROO3YhIjdIQlMkKyRpJE5NeE1RJGIyREc9JEck OSEjIVolOSVeJUMlNyVlJWEhPCVrJSIlSSVsJTkkcjpuQC4kOSRrJEskTyEpIVsbKEJodHRwOi8v c21hc2gtbWFpbC5uZXQvamltdSAbJEIkXiRHISMbKEI= ------=_NextPart_001_0009_01C6C938.F6DF78F0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjgwMiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9 Mj4NCjxESVY+PEZPTlQgZmFjZT0iGyRCI00jUxsoQiAbJEIlNCU3JUMlLxsoQiIgc2l6ZT0zPg0K PERJVj48UFJFPjxUVD48Rk9OVCBjbGFzcz1sdGJwcmU+PC9GT05UPjwvVFQ+PC9QUkU+PC9ESVY+ DQo8RElWPjxQUkU+PFRUPhskQiEhIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKBso QjxCUj48L1RUPjxUVD4bJEIhISVVJWohPCVhITwlayRIOEAkKCRQISEbKEI8QlI+PC9UVD48VFQ+ GyRCISEhIU14TVE8VDdjQX1DZiROGyhCPC9UVD48VFQ+PEZPTlQgY29sb3I9IzAwODA4MD4bJEIl OSVeJUMlNyVlJWEhPCVrISohIRsoQjxCUj48L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMD4bJEIh ISIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigbKEI8L0ZPTlQ+PC9UVD48L1BSRT48 UFJFPjxUVD48SU1HIGFsdD0bJEIlOSVeJUMlNyVlJWEhPCVrISobKEIgaHNwYWNlPTAgc3JjPSJj aWQ6MDAwMzAxYzZjOGY1JGUxMWRkODEwJDNiNjRhOGMwQGE1OSIgYWxpZ249YmFzZWxpbmUgYm9y ZGVyPTA+PC9UVD48L1BSRT48UFJFPjxUVD48Rk9OVCBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjog I2ZmZmY2NiI+OC8zMRskQiReJEckTjR8NFY4QkRqJE4hWiU1JV4hPDZDJC0lLSVjJXMlWiE8JXMl VyVsJTwlcyVIISohWxsoQjwvRk9OVD48L1RUPjwvUFJFPjxQUkU+PFRUPjxGT05UIHN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiAjZmZmZjY2Ij4bJEI8QjtcQ2YkRyQ5ISpAJ0hzJDMkTjUhMnEkSyNH I0UjVCQ3JEYyPCQ1JCQhKhsoQjwvRk9OVD48L1RUPjxUVD48L1BSRT48L0RJVj4NCjxESVY+GyRC ISElLSVjJXMlWiE8JXM0fDRWPSpOOyReJEcbKEIgGyRCJCIkSDtEJGo2TyQrJEckOSEqGyhCPEJS PhskQiRJJEokPyRLJGIkXiRAJF4kQCVBJWMlcyU5JE8kIiRqJF4kOSEqGyhCPEJSPjwvRElWPg0K PERJVj48QlI+GyRCISEbKEI8QSANCmhyZWY9Imh0dHA6Ly9zbWFzaC1tYWlsLm5ldC9qaW11Ij5o dHRwOi8vc21hc2gtbWFpbC5uZXQvamltdTwvQT48L1RUPjwvRElWPg0KPERJVj48UFJFPjxUVD4b JEIhWiRBJEokXyRLGyhCPEZPTlQgY29sb3I9I2ZmMDAwMD4bJEIlVSVqITwlYSE8JWsbKEI8L0ZP TlQ+GyRCJEgkTyEpIVsbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJVj48UFJFPjxUVD4bJEJFUE8/ JCokaCRTQXc8dT8uISJNeE1RJE4kOSRZJEYkckw1TkEkRxsoQjxCUj4bJEI5VCQoJGslNSE8JVMl OSROO3YkRyQ5ISMbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJVj48UFJFPjxUVD4bJEIhWhsoQjxG T05UIGNvbG9yPSNmZjAwMDA+GyRCJTklXiVDJTclZSVhITwlaxsoQjwvRk9OVD4bJEIkSCRPISkh WxsoQjwvVFQ+PC9QUkU+PC9ESVY+DQo8RElWPjxQUkU+PFRUPhskQiU5JV4lQyU3JWUhJiVhITwl ayRPPCtNMyRLQy8kYiQsRVBPPyRHJC0bKEI8QlI+GyRCJVUlaiE8GyhCIBskQiVhITwlayQsM1ok NyRhJGsbKEIgGyRCJWEhPCVrJT0lVSVIJEckOSEjGyhCPEJSPhskQiRiJEEkbSRzRVBPPyRPNEpD MSRHISIkbyQ6JCsbKEI1GyRCSUMkR0VQTz8kRyQtQTQkRhsoQjwvVFQ+PFRUPhskQkw1TkEkRztI JCgkXiQ5ISMbKEI8QlI+GyRCRXklYSE8JWskTzktOXA8fUZ+JEcxPzFEJDckRiQqJGokXiQ5JE4k RyEiQTQkRiROJTUhPCVTJTkkchsoQjxCUj4bJEJMNU5BJEdEczYhJDUkOyRGRDokJCRGJCokaiRe JDkhIxsoQjwvVFQ+PC9QUkU+PC9ESVY+DQo8RElWPjxQUkU+PFRUPjwvVFQ+PFRUPhskQkVQTz8k TjpdISI4RD9NPnBKcyRyNS06XCQ5JGtJLE1XJE84ZjpCJCQkXiQ7JHMhIxsoQiA8QlI+GyRCJCo/ PSQ3OX4kXzhlISIkOSQwJDRNeE1RRDokMSReJDkhIxsoQjxCUj4bJEJLXCUiJUklbCU5IUolVyVt JVAlJCVAITw3QExzIUskRyRPO0hNUSQ3P0kkJD5sOWckThsoQjxCUj4bJEIlVyVpJSQlWSE8JUgh Ik03JFMhIjtFO3YbKEIgGyRCTVEkSCQ3JEY7SCQkSiwkMSRyJDkkayVhITwlaxsoQjxCUj4bJEIl IiVJJWwlOSQ3JEY6R0UsJEckOSEjGyhCPEJSPhskQiVRJT0lMyVzJE8kYiRBJG0kcyROO3YhIjdI QlMkKyRpJE5NeE1RJGIyREc9JEckOSEjGyhCPC9UVD48L1BSRT48L0RJVj4NCjxESVY+PFBSRT48 VFQ+GyRCIVobKEI8Rk9OVCBjb2xvcj0jZmYwMDAwPhskQiU5JV4lQyU3JWUlYSE8JWslIiVJJWwl ORsoQjwvRk9OVD4bJEIkcjpuQC4kOSRrJEskTyEpIVsbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJ Vj48UFJFPjxUVD48QSBocmVmPSJodHRwOi8vc21hc2gtbWFpbC5uZXQvamltdSI+aHR0cDovL3Nt YXNoLW1haWwubmV0L2ppbXU8L0E+IBskQiReJEchIxsoQjxCUj48L1RUPjwvUFJFPjwvRElWPjwv Rk9OVD48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_001_0009_01C6C938.F6DF78F0-- ------=_NextPart_000_0008_01C6C938.F6DF78F0 Content-Type: image/gif; name="logo2.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6c8f5$e11dd810$3b64a8c0@a59> R0lGODlh+gA6APcAAPP57vDRzNfn0/Tr65ANEpTGxXF0c4uOi9rY24t6T/dvC/FzcO3r7UpMSsna 2uPt2+fIu3KQkfb79Zy8wOv392yYY/O4svGnEqbIyFW1sbFQM4nEve8XD/v39zEzMrHMtmy6siHp mdje4UJzj+bs7ZKSZ8fIxZm1uCOgnvb7+4K+vky8fKJerbq4ue3v8bjV1fOTj4akpHHFxt3l5OXj 5bbGyXq6tXm6unqKWcd5enSPpiBYYFuIjt2ysvw1M+f19TPVi8naxfXv8TrNhunc39K7x2ihlMY8 KE5sac1MT6inpWOgaU6pm+bu5ImltO7KFfDk48+OkHG2reXn6vs9BJiilae7vd3s7Xmlo0TCfmG6 vHrEtmWyp8zh4vf3+9Xk4h3unahBR/r/90HIg/z3+3urtIWYrO/761OYpsnQ1Bj0oefz5F2ma9Yp G1G0dVqscPSBfXm2suzn6oCyqFMHCN7s4rnYwdbKzJ2XHCjhk9fR1ubz7flJRbfO0EuJeanMaN7m 7KjW16WwnJukpEREQzc9O2WrEtTc0IO6uO3t5Ky0rBCBfWuipK0vNKiJuXq1umVmZI7DlZHCG6nO z/KmoNTs7KnSx3G6s4+ssGinsyzbj5qZmFTEvu7795C8vu/7+31/fiUnZ7lsblpfXMUBAY+1uoSy soS1up9jQKemucmnhrK5r+/3+JS2pW+6uqjPpHC0tEdOd7jb3TDckbFYXBq0ttTm6nS+jmoQdw6K L9Ts4+Hv8JKyspC7tDm7rxcuKtegpFRWVHq0XjLBx2pbcrrh4cNeYW+0vLixtL4hnd9hYq2trBob Gt7QeuLz81SAKcThyzzHgC8FBnlQQI7Q0yQlJPphXOb78+Pz+N7z7xMTE06na0msUxsAQlO4ae/3 6+/35////+v35+/37/v7+/f39+v34//7+/Pz8//7//jz9/Lz9/jz8vP3+O/34/v7//r//+v36+vz 5/P38/v/++vz7O7z8uvz4f//+/f38ur38fDz6OryHBT6pgkJCf8AACH5BAAAAAAALAAAAAD6ADoA AAj/ANuRmyKnXDhy6MiVYzdADxR2QgZ0EAJFCI1NkCAho+Hi4EEE6OwdFBiupL11Xmig+wgyXbtw M0yQIFHyIDkvNfGRgyDEYDiR5ciRO+gioYsOA4SQYTAgqRAG5DqsExquXEQoA9R1gDrFnr0p72wV mPSFHAl0LvTomVKuC6A0M9qdTSOCRg0MGKzgRaRC1q4uLxwgcKSDSYFSPBhlmuDgxYRHfpZUWIKo MhcuTJigYNInTRoXNTDFOIGJdIwIMVJjwsSr9ekYq2PLhp06BpYIt7GcQMKjN48IwHOr5jU7gpHj Rvwox+nChQiU4Ri4mMlAnTohK6MrgcTMnz9t1SC1/6CBzx46PUI6lEOXsJw6dB3Ud6hZcmjJGlFJ dCBTdF04F9exEwA7cpxzDg3n6KEVER3IEV92XtCUEH/1DQUPPAid0xQNUyAgAlteAOLFDDXQFU4a RMgxBQnliNDODDQUwUA5Md0xRR8OWGGFCVVMkIEtf1nxgmMRGDABBiSMMEEfO2Aw5JCyNDbkJBgU gIgpEZxQ4hQTMOGkAyo4gMEkkximRQZlYOLEBKU4cYITcJ4gZykjPMKIDidYYYYTeJqhA59mqMkn JjqYwcMIiI6gnHJIYIEFbKilJtR84eBkDzsdqOOFC17IAQU6M2ynjXekeueBAUVYJAemZFQaTjsT df/ADjkvkTPDUCIdhE4RcgBDgxAiwMeAHOHEx845872Dk3/rHXROdWTI0Zw60ZKB7FYRsWOTC9Ki ow4DH6JTRxdX9DETOV9gkMZ67BUlggvnTDHDDAgwMAMy9CLAQigTnPnICEjoGAEvJ2CBxhelYDDB BBsUUMAGNtigwgYqqFCAKxlo4UsGKExSwAuykOmkkyF38eUNj5RyyimPPOLJwmyWUsojVWJwSmM6 8KBDLDqPoMPPOWMxwqCyzWF0KS+YDNzSEdj3zkvhwEeDOi5EJUdTywTTXamlVgPKMkr1VFU5HVzL wFb2cCqCef/Zg1UATRFBAwLhILApTkKwo22E5Nj/04FQuKIFn1I1GWQPGfupc5A975oUFULkuDDD OHW4kLYXUzggQjkMdM4ADdLKm8wUNGyuBwNYBdPOCJkgEkMfBkTAAxIGYMJIDTs4YMopnmzg++++ P4yBChnAMoEnntigxQZbbICx7xZfXED0BeAlMgZ99PHCI5VhrMIkfQDSRSYYZPIIGotkkgka7KNh MwZoIALL/KYYPYcpPEzygm6stRbUpqyo1B1owAB0BOUc6mgIKKrBNa5VwwDLgBc5GBAOB6FjADQg w0rKcY6SrOMoCBEBEa4iBCIoxAUI4Bw6IkKRV01hKzOaQlRooJD4GCgcN6SPff4jAqGUYx32YFeD /9BBAxOggwQuaIe8pqAHOcxNBHXxQjvekgYEICAteiACEeDyhV8UwAoiMMABDpCGBtTgCw5wwBf6 MIETVAYRwKuYDG7QhxmggxdGuIHzrPS7iangBq5QgStcQTFXADKQcnQFXsYSsuuNyQFkysAiHDY9 LTBhEip4QfVOUYqFlcEUMktYH1ajG17o4CkanJE69NAe9cDDHgwYRDAayDVmjGITv2LH2YQwlAd1 8BwKKRZC5NUC1I1wAESYAumKMAUDluMOQuClPV4ihHOwgwQfhBx8jnWOhPxkIe85WzimRgOOeMtB KrkJBWeyDv2UjnR3yCIZUsiAz0yRBO14gbpa4P8jLXRhC0ZIQxUU0YdTGQAJSPBHDayACSv0ohe9 iyPxPNEFe8wgAxuYoyf4UrGO3uCjHQ1pSG8wATROoAAouIQNLsGFDGDGFZR02JjIpL8XeIxKeIGZ KcpwqEwoxhSeQEMfbNI3oVhRhT9phwlA4QFalkobhACFHvaTqQ6go5tQUUk55ICOZtLwDuRIgxzk Vp1oHogMIWTFF2p1EFnFpxy2kOGtpqCUFF2nAx3xwqQOkoDrnKMcVkGAWcmRjv+YhQEIkIMcRCAH h2QRK1CIbGPBBQg0uiANVvAEFxwgyRzVoA+FiAUoImCFLpyGtA/1hMMa1tENfIEV7YBHMR52A0// iLRiH73BbUW6hSoEsQZaqBhLJyYxV5wpAxlQARMyAAIQMNdLKljk9TyGvJgWABYOiE4HEECDcrzw KU9xwQ+RAYqtOdU71RgFMurSrCm042zomNE5hICAZl61g8XqACCwsQ74VCVzgBBTF1KwC3VuBXL2 AN0UMCeCTUUtV0r0QjlE4gV4XPVvKfBWdbhaDi9oCkGeIgIyiIDMAJjYB09oRiJwQYJUaI8T1EjB FaawChaUYxObcEKgdhaKu2ABCanZTWoptoUtyGBivrjCDyhAAXgkd2KIHClId1uxLXDiAzToQA2o MYyIRUylhTTuIC/hXC7YgAsbuEEBtCADTgzD/xdkYt4fdXuDDOjWFdE5hxygwgAhVAon6sDUICBx 3lIVwgBqqY4X1vFCe6RhCgy4w4WLhQ52kIEI3xLC6ZiCaXsFhRws+Ix/ajKUZkYHPhN84X/OJhQD /qRqRYG1WV5VtaHQ6h01UUdky0kDuZkAAT3QIhREQAIHuEAWXejCLgDhAivkIgXPIIYO+kAnHVTD AWkARTAMMIhBHAARNqAYb/25C1b84ApYYJMndEvlOeeW3RWjBgWukAJ4BAIFHv2ol23QXBC88d+D NOTyPGGCNAjiA72QgRa4oFJ+X8KAHeC1RDqQAmUZUB2bGEWhSRWMA0whDTTQ66Y6MA0HSJWIev/9 kCOu2EzBIsA60vEJYBFAhCwKgWrMIYEc0tM5q3LrPR2QIaVakIb6zMfWUvQCA7yQK2WlgxwpSMEH XZC5GoggjScITMHTiG1IQmwSMxBEEMphh1bwAAMnAEUsiIHtYNAuBsSJmLhF2rsvXMEWvigAypK3 74hJ+d0dlUEXflAMeGCjGNTI9w323e9/vzHgwdWCK16QrtpuAAThfhgIuJAeq1oxbwN4Vueas4lZ btwfwdiEFxzwFBEgtpki0AMBUcmppB8kDC6fUVtVKB2VYNBFXpD6OTSouIMQooEt8EexWrBDocCj HazwRzVkUgc0Js07kPAAJgZByxYUwh9KkIP/Pz5QgxqYoQXob4EH4FKCVvwi/cmvAigOioRfLGwO ci9EMLRhhC1UjBEOUA/1YA+W8AIjYAD+EAf91ly/4B0t8AvvNmUVo2yDdwW78GTuxnjN5XjdM0jL 8yO7UG/DUAC9cAkmqFKY51UMoAdWdHRT4AKaJgcZd3r+MAoHgBbwIgROFBM71xTxcRB6VRIpEA53 cEzoIAG6lBAz8CoTxBToUAMCYRZDIV7ngBP+EB9YuAkdAH4dYABpQwJXMANXRwiYcIWgACXtEHVX mHxXUA0IgIXxQQgImFhb+AF2YAlIAIcmoDmpUAZXiIXVIIcGMIibQCqj0h0O4g+9EAFbYAMO/4BE 89AADXCF1QBu+3aFV/gLXhaBHwUCV/AFP2AyGSBwudV3fUdmCwgCKmADBbALzpACziADBTABiBAH tniLViR76kE3UxgOJOAF6DCDp9dxFIQTOOERlcIgUHA2kOYtUXM2wccKffMf61EOnBIUoDMvOtAc xuZdBmQP85B8pLKFW1gIW1gF3TYISvAFV6gNW4h+ihCPDsAKwRAfNahxmNgBB9AC2jAqhLCFaXAA ChUBxICJXcAdVgANy2AGBtABhQAJg2gASrCFB6AEV2gACEBofmgA74d+hVAPm4B+BlAIvtEbNnCF kNABSFAIEcOJJEUCdTCAHiNmpWiKXoaKC/94CZkhC87gDLswDDJQBrc4lDSnDramBzXxEuwhBwcw icO4CSvxEpxiK++xDmdDYmTwQehQIFlUNfBADykAWOwRFC+0Es0xHdNhDyQghiKQBmk0AZ9VUAZA aB0wiVtICHiJl9gXh3mJl9XQB1q4hR5QCNHXAZAgfljoHR1QDTNwhR5QA4WgWAewCdqAAP7QEVcY DJPAA+OomMe3hW/oHUzpDy1gAl1oD3/oHX15fFc4kd7RkpwYByTQBInQAR6jBVrwbjZ5k6kIAhvA BFwwCeWWAsPACX4wlLd4c8U3LRyBOAXhAgeAj06lDczgAaBQTPbAdPUFXsd4EOXwEkr3V3f/8DkW 0S5nw1UF1DmPRg4YgG1o5AAz0AVf8AXVNwN1MAPB0AKLeYWbUA3iF5GD+H0puYUAioAesJj6uIVf 0AIP5A+gsIUpeYXM4I6QUIimuYXakIh68IcIMAoNEJjasAF4iQQMigR+oJgmUAh6hAAH8AeNaY8P BKCF0IJa6A+M4G65hZskcAhNMA8hg1wZuJsr1Vw4qQIowAUvsAs/8Am1UAsjEAdSgJxy8IbqsHNE cA5EgBXdFBWDdnrMYADIgABk4AWNA4RLiBNRQS1aoWcmlDZHFJ8OUAOWQ3RksyIHMAPKVF/zMi9f sKdp4A+K5Q9puAkH6g9R9wOd0AkUkJri//cDP5ACP6AL/mACyWePheCOhQAO4uCOHrAKimmPBzCg V4gAy1AI36eflNkBHvANDRAfo7AGhwB+cjAKH+APDakN34eXHXB8DekPhHYMsHALwtoLhRofHpAJ mvVGLfMIcWAur1AH5GAFE3AZUhCliICTvdlwNnCLUcoFBUANxbALslgKRsAF1XqunCNY0eQgTZEe PiEqG2edJmBf3eUR1TgF6xAfcjBN7WCNJCCfXWAFNTADxgYqM0AHBDsDgFBsZOp6MCkveDovUwCo WzgDF3KgJnAAS5YCn0ABrNAC4seOuqALdaAP4vANmIiJJlCP2gAOLmuG4BAE1dABFgkOB//QAcnn qSYgCOYAAI4pfQfgAS57oKOAsvZotKp6AHXwh/HhjtqwBMzABMalWxvACHLgAczQIB5QAI+gAsra MnHwAiQQBEEQrVaAGdUaB9fam/2mrdwaB94aCIHwA9RwGOV6rtX6X/H1KwEQTQgwE+zRAgtUaMxA CJtwByoULN5ZDjORNoAACDjyRVX0BS2WRiSgB+/CAlL0Eo0zE1D0iPZAAVFHFQexodXQkxTQCd4R DEvmDHtAeHXgAQdwsi7rst/wDeBgAv4ADsl3u97hsuIADrYaBC77fYfgsuYwqS7bBMEADu7wAE0g qOUAAMHwALgrCIPgspOYqeAwCgx0u+D/IACKsArkm3wnuwZ1UAcPIAACAA124A+RUKuFoAsYwA29 8Agrs6xxUAckUAHP0ARBYAiZwQRROqRsCwJua4tScGYFMAyBYAucoAJOcLd4q0QRxxRQQGIZPCw3 hwCbwJrnVQgHYAJOJAe/+IX0Uj1pIGkgQQIr0kwMMAUfMMMmIB1dMQWAQA620AUfZA9DGA4XQh9A TAFL9qhL6qhdkLoUkA26sAbxcAa4Cw63C761O8VTDLziELy32wSggMVafMW1a7sC8A0ScBBN8A37 QMXgaw7gwMa5G8aa+sVSfAZhDMZrsAYPUJtTcAivYAevcAtb4AuckAEk8AXPUAgu8AWZ/1AGmXAK ZVAGMVMKvWA/KmMK9WM0lWEDiJAZBSAL1GAL+IYGx+EopDwJVpcjDPAsWlESZfMfyGB6NOgdzNAA SjAjiDMDZ4FYoNEC3EUDwKAHpVkDn9MVHSHE9JECrJDMoksBsQWpu7ALlZANiaoP+hAP8XCyZ0C7 tZvFUmzFUVzHYBy84Iy74mAObmy7tjsO8zCE5PANAEDFVWzF6BzP2xzPYOyyALAP67sPAOCyePwA 6wsNQfAKkiAJAtAEf1DQhnALrHgJ3LNuHwULl4AFrnAMFl2tXIAImKFJZLIDaMADo0zKWNAF75I2 1pgpvFTDR8EAJmAAoxLLhnadDGAuUP8kC7bQHOVAwvbSDvZADvDACkyGzEBtbo96BV3gDNngsT3p DI9KAXuwB+Nwuycrz1K9BlnszXBsu/dsz/A8znA8xQAgAUMoAbibxt581vIMvFqN1V8txdArAVHd ze9cx1M9xWsAAQtgDT7wD//AAXz91359C8gFblDKBIvQBQbQAH1QJCBtBCI90h8CWDPxHnJADq4X FPZgAtwB01wjrx1AbClgC4HQBc3BFvbx053wA5VQDBTwCZ/gDErNChzrDJ8AD1E3zdUcD7i7211t z1mN1ty81lQc3OALxWF8su8MAFE9DvXQBOPwzmgd3VcM1gAA3bxtxVAsDkEgD+OwBx7/qw9o3Mb3 cM4BAAEWsNc+4LJ//Q9HgAr/8AZZkAf90A8r8A/uawcf8AqREAkbkAtfcADSUAPEYAZmoD6LjAWM YARD8i5HZDnNAQhQ9HHLAArfx9lcE1Uht0NRF3XJ/APmxmSVoGSVEAiLIAuB8Bd1sAf0uQd17dtZ zM1srandjNXiPONbLcVrrdXVXd1RDcbu/AD5PNdWXN1Ujd3WPd3unNZSvAb1gC7FEOI/8A0WsN5/ 3QZHoAEagAoV8A8Q0AYJsAQrIN//oAEVMAtqMN//AA7/vL7sK9Bkawd2EATu+wp0fgtuIAVINB0z MQNfkGwvkD1ddQCwbOGkwgzBsAo//1wStg19rMDUIU4BX/AyX7ADW+AA0NAEMTkOPW7jU3zVZ/3V n67W0T3O7gzFt1vdEpDqqi4GYqDq8zAPPN4E7JHcAGDq9/wNZ7Dj0q3rW20NVP4PcFAJ4/APbZDl CVABbpAF873s/fAG/4AKS/AGK6AJ/dDXXg7f1T7PcfzF4nDHTcDm0BDuQXAIQVADXFcHthCfXyAC CAAKTknoDaQNkFADySzbyOyo2PCo7fADnACGKQ7G5lDXL/4N2szp4GvkUg3joS7jOV7FYZ3q89Dj 32zr85DqYJ0P6JAPEsDqEqDc0o3d7kzr3wABv77eF8APKJ/y/7AHxL4EWUDtzB7z1f9+BGNw5mjO AUeAA24wBNV+8Jpqzm1cxeAgDy/+4uZwdWmERn0wn22pCJsN705luAgADx0r1J0g2xJgD/Ug8aN+ D1lt4zZu67br9TNO5KA+xWdAx+ns6tDt8FOs6kduxWRd9qpe92R9u+VtATBg1lb8D1SgACef8igf +ILPDxfAB/8ABjK/+NXOAWT+BkAw86jgBjD/D9/s2z9/D+Md8EYvAl8ACKxAA2YQnVgL9TR4SyQA W/qg9ddMu9ct1dt+u6reDppeD7p9u2kv9lW8BuPQAW3P1bk/5A9/9/A85HBP8KdOzm28Bk0gD2Iw D7he6xAAA3CwAHxNCe5c5Vbu3q3/7ur/QPiFH/4q/w84MAuKz/jLTuyTz/MzjwNDEAJoTs/DzcbB vc3mDEV9Kkulb/o0CBDVRilq8s3gwW/gxJkTJ04hwoPgHjSRJy9evXHz5qXgOM5jPYMAvp05A0AA jX37EJKE+E3CSwkAZIIzCI7mmXEy571ECODMSJvgzIFLBIESjH9JlSZtgyoBjgpH/tn8pwFHFiBg +v0TifAfP7BhxY4Nm7TfWbRp1R5pk0UN2n9H3sx6uxViUHND7wYNKsvWDAdKGlTzV9jwYcSJFS/2 V+iAiZYNHUa2efABTcnm1mwW921eO47kUrTTF+9bPQGJ8vmM2NmgBDExuwp1p/db/04AL8cdJCkz IjgOS5Vy4NDmiIan/9gAQZvg30gfCejCrVz5HxWy2cX+a1phiZssatceQbXkDfO4c0Ocfd4wb0Oa v/lCFOFgiotNhRjv588YUpU1JIsPofkgAuCBfTSD7yD48nogiFWWMWGGclwgp4NzANhtHJhi+mam ygzyKDcx5hHJAjj48EG4pcA5o6oh8hBPvH/Ucq6kGtV6DqJ/ONDuR+4qWGGM9WZEC5UjxqhrK+mW nErAEGtaaLK7nLHlh08g6W9LLv1pAJRDgkqIrwLHrOwBdxQaUJw1HlAEFA8K02ZOZhxTpINEEiHH ixTIEW2e3RIyxx2fZJIAigAC2P9NghWXOuIp78Db6h9r/sEhRiPT+qc8SW88wwe5smJPpq6++eeC H7WLC4glK1iqOKuWSCBJrdg7ogI3hljvHwETInDB3xYyhxUKKGBFvy6TXUwgRciMUr7KSnpAHoUk EycIUAhRTBtmmKlGoEFM2OeehioKwIKjWEyquDb+SYS76TJlr6oV8qhV3qquktE5gyi59Q2s7III DgXGemKsgreTC9OtbvpnhSVnHePef5qkbsAxh3rWJvdsouAHjghTdmTEqgFzr2fv+mbaAVuAkz9p 6CAgOHWN0wAVqNgYw14aOahgjFnknbeCe4V+OF7nRIouXoF9PYMS7FJNuKwj8nD/MqQcm6MVLovZ MzOvlPHS+CBnfqAgBW1IVtuwYBS5TMyW5DOoicoEGKSBtBEjQN2kqFDggoMrfsONaISGawXD0ZIq ca6VPCtpAJYuUuCSZPoqVX6mBou7BCpgQ9d/YBsgLhw+ByOBNnCYRcataLQpL9uChQ/jb+rQZQ9x tFxbbWYMUMSgn1oq9UPWEJRok1EUuw5zqolkfCsOjsBhLqGlqoD1s6Li++HJnXtpaSd7Y+0fzTNH eCzuhqB4KRulH0PUrOG6R6/gzSQzbo7F2UTb3UkO5oAHfGMffHFNSGpik33I4zarGIXIDiON5TGP H3FZwSyKhi9U1EstQ3hDBdSn/zjukKdzK1CKD/gABwtYYDdxScAKhtAPfn0DVG8IQV24IhIN2eFU Y0GVWKJWljbgagzsKc4RyAMVN2iCLVmYRdBapyPg/UZjtDvgPe5RGXFUgX/9UxYzgrGMAMZtTN8Q BwDEQI96BKEeh3iZyQ5DPglu7ojf0YThLOUGIBQpKSbkACpwxRwj0qgeGDmXBWAAmk1VIAsvdI5S aNQTAcBRLD0MS/l6hIo3OE9eRmyhE+PnNWilbEzucc9m1qCIYDCDiyPr3TIg0pncDGAAIqnHACyQ KEpEYQCFyQEBdlmYHWLuAgpQQFWW8EEYvuGFZ8GZC9nTzGX+IyVwSICO3Ie9pf8Yhzz/QEoF8pi4 f5CkcuOIYCXH8kM5zuWCM2JL55K4latQzH5wuwvsbGMtBjpwlV0axSYSIUBZvkQIAwgADGQ5ABhQ IgALUEYYftnLX/qjnJvbnqVmMTnxoEKTW9HAElY3r6QcgQ2LZE8bEjBEobXrH95c54y4UhKDrGGi /ECn+bYTPafgapPSodilKPY6UX5tigySTBAMgKx9GmaL/tgE25BhAG0gIwmyXMBBF3BVrCJUocqI AjAe6svC0OFylSQAKUghHGuIo2IrEFU/boYDN1QQFcyBSyYxmqmkdA1f/2Ca0X4j05pSEiw1rdjz uIOKXO3KKoltWFA5BjtfIQT/dtfKVlIJMYBNDKAHAzhAFUAhil1uIgBhiEJmw0AJSlzVoFjNakIH 0AhZLoOXBEBGYc5KFuFQQbf/oMSmNDkE8ixhZ4jTUV/3ikldCS04qHBK6eqIV45hRpJh8VFYnnCw 7WgAe0brZK3ighxchWBHLXnde8JWrYYcoBCqVNtBe5ADXfpyAL5UgiyT4NVGEEC/PTDAAJKgDNUO oKoEtUBVr5qD/ILVH72srT/EWj4gJRKP/SBuc2hUwZbS6JPyck4FGTcVmxTqH9gFyzAnids24DHD mpqrk3CgQVDWE2yiDAqbzHEPSORNbb3Ur37nK0v5KmMAQu4BARwaBV/CVsAB/6AEEVh7VQHnssdf BUVh9hbHCVZsDMvsZJE611YmueGuRkqKdhPnnOcJrCsAmC4/LiBYE2/noh/O4OQqhitdDWG8CXFP 7PBnk/k5RHdrO+gAaBHfARDBlxBQhjKA0QICQHS+ASAALZKQVXShNgBQ8G8PilzkBvdyi8FkHnfc ojg8Fim4bd0wvpDix5Euc0bOwRkbciWcFj6XhLeBCZvPJxYIb1g4GpgwkwAWzfMUadc0qRY9CdTs V2Jrqe31ZQ/CgAxR0GIZihCwfX/87UYcAcAGjfJVKfHaSPeYf708jFjjyDm27ioBpnsiWkholcFl IQGzMmKusGmQpTTqkm5g3f+szuNdODTkk86JDRm/YYGxDvacgp0gDrb7D3mwmQMwhl5HV7CrDf4D DliFQ8lLrsAD3s8gsJtfFZK3Oyj0EhQ5yAEoCACBYKDbob4kQAt+7MsoCHkA+8j0Au47XyP32DBh CANitofb6MEVPS/2pL4e948awmUpFYjXLP5xkdaksEdNwcESsmDEb7LHAgC3Clv7gQoQx6cJE6WC YP2GPhwU7R9iwAd3LqXHn7GOhEKi66S2x+cyzdMmJjhAnEh2WR/7gxCbULR9hRyA1zZi55gnABHE DQd5dBsOByUCgJOA5B4YRpaGqehMN8yBtVzlm9Zjq4xEDvAEHLwfOOCbEa3/4rkVFK5HCVhC8JtG up31o10Di/gEBTvRC2yKVXB5gBi0bOfAa8U5Xwans57dkiYwUG2KJkARCEOIIhh5vkcYgBw47WMf 96AR4QawLRk6VVkC46pJKHIj9EOIRggA1oMwIMkgCzoLDYg1ZsIzW7EauFg7U7ERFiI4O9Ko59oK eeCQqugcZUqKgxAJOGg+EUSnYkoAxhoCH2gCdLAUMFu4Dfw4O0q8lFOIADkILSKZ14ooQjAyl4GA ARgEXyGC9wMyWug8AYMBZUAw/QqDS4MBo5s/sJqvHGC9mkqVDesOt3uUY+Oo5Iqxh0m+fggONzAu MqORediMT/oHH4gIGRLB/4nzoU+qAGtQoIfREY8CoTa4GUipMNc5r2rJDQm4DY9QhFFgr/4xAAfq p/kBh3sQgE1YhrQ5qP+QJV0aAAjoqkQRMAiALQLQj2DIgV+ig7uTICq4M0x5CozKIIpJgKwDJXD4 h/fRo4opPlkzEqmgIU1pkx74lyFADzggo3gojR45p18DIsTqRbeihDUwlSMwu+dKQ0thIsPZNfyR DEFECHFQglRKKsMoBAOAjG9ogkNQr7zZIsIABW4JhkFogRaQA1lCgAGoL8OoMtuiuB95gqQQElVb gqIxwXhhIbgaorhbKZ1Bj38Agu3CK8EZg2c0CDhAhVbcCgvYgz3QB324hv+ZqilL4gCfOosj6AE0 1IAuhCcmsr2Veh/DiaFny58GeQ9zYKNpWyVm8IBRqIIWMIH90bHF4JZq8IAvqYIgwEmkSozWEw6I 45siYgsRSgC408JosD2asIAj8DAisoosSEi14D3uQI43iIYVWMNvgIC2wCZ0IAd6kACPIDWwKB9L QoUssDMHWIM68Ls3cCa+cpLDEpJaFA+peKVqQQgruqIQSYP94cbDqIYGUIJlMABDTIyZ/I9VAAW8 6RI6qEyZ6bGyIoXi4IMPWSg+UBEf8AFroBm+WQAWoQTiKcq4MCIjcooECA4iEJwVmM0E+MVvoCZl 8i4xqIc66M25rEKEeT7/6dCU3oykkEu7ScnDCgAYeWmXGnMIaCOqD4GJcYBJw9wSbfDJx5iBjPuQ kGiCTcgxkpnJAziElfhAUvEN+Rgb4sGh2fA+A0oh+TS5ADiIFAlN0RwjFoGBQdoDAeiCOkAK1SxK QCGnEEIOqZjN2RQvZpyeLIiGC9QRDnAWKprOrmATAcCWybxO/miAA5gB2IiNUmmCNFCCAxiF9eqS OnmMgiiQ9ExPxavQUKKiejAjcggUMcpR2JiHemgCAfhRIBWAOqgHe7CHJvDRDA0CSfgAO3iFEsAD VYDSKIAGVdAA0OStOgCEehC4igIHLm09C4BOGcyYGRPHFjiAYNAnDlUM/w/4RoTICZjwExJYhQMY DJ1UjGqABBMQAPsxIPJylsrxDZE4AwqNGw4Rg1KpDPWsJ5rIDXJAy5ZIiZbYDdeoiINYxm9YAx+t gx9tE4OwB0BIAxdIAQmoB3kwJc+IU1KdB3vYCQnYCQ551QIdJJCAzjEyiM7YBwDYGEBjPMdb08PQ BsT0HfP8DYjwiFiNjVclUTo9gAMQhFVIAwFYg6BCGXoanhilooygBzGIG2ytCXe4h9MYhzMCFIhQ iYRICXRtiQfI0D8IgmkNEJRbg3XdVBIgAXsIh3CwBzEaJDJSuW8wjXioiIo40jWohz0YJI0wEZGQ h3zwk+gKigc4BAipLGNg9RZCGAUD2IRonZbvy9Hb2IlH9ZCPFaP4eJbgGZ7yutYPFIPYAAkZRRmX cFm03A1wGB51/cAcZRNTola5TNJpIQcHuAIXYAUvCId2aNWdtZYCAtm4kYcjrYd56IAOIIdyCAgA Ow== ------=_NextPart_000_0008_01C6C938.F6DF78F0-- From sugarbeatsquall@yahoo.fr Wed Aug 30 01:09:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIKn-00035q-BI for NETCONF-ARCHIVE@MEGATRON.IETF.ORG; Wed, 30 Aug 2006 01:09:53 -0400 Received: from [60.14.176.178] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIJQ-0005gP-PD for NETCONF-ARCHIVE@MEGATRON.IETF.ORG; Wed, 30 Aug 2006 01:08:33 -0400 Subject: =?iso-2022-jp?B?GyRCIVpEeSRhQFokajRWJDgkKyEqISohWxsoQg==?= From: =?gb2312?B?Q0FNUEFJR05fUFJFU0VOVCE=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0008_01C6C938.F6DF78F0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C6C938.F6DF78F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6C938.F6DF78F0" ------=_NextPart_001_0009_01C6C938.F6DF78F0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoISElVSVqITwlYSE8JWskSDhA JCgkUCEhISEhIU14TVE8VDdjQX1DZiROJTklXiVDJTclZSVhITwlayEqISEhISIoIigiKCIoIigi KCIoIigiKCIoIigiKCIoIigiKCIoIigbKEI4LzMxGyRCJF4kRyRONHw0VjhCRGokTiFaJTUlXiE8 NkMkLSUtJWMlcyVaITwlcyVXJWwlPCVzJUghKiFbPEI7XENmJEckOSEqQCdIcyQzJE41ITJxJEsj RyNFI1QkNyRGMjwkNSQkISohISUtJWMlcyVaITwlczR8NFY9Kk47JF4kRxsoQiAbJEIkIiRIO0Qk ajZPJCskRyQ5ISobKEINChskQiRJJEokPyRLJGIkXiRAJF4kQCVBJWMlcyU5JE8kIiRqJF4kOSEq GyhCDQoNCg0KGyRCISEbKEJodHRwOi8vc21hc2gtbWFpbC5uZXQvamltdQ0KGyRCIVokQSRKJF8k SyVVJWohPCVhITwlayRIJE8hKSFbRVBPPyQqJGgkU0F3PHU/LiEiTXhNUSROJDkkWSRGJHJMNU5B JEc5VCQoJGslNSE8JVMlOSROO3YkRyQ5ISMhWiU5JV4lQyU3JWUlYSE8JWskSCRPISkhWyU5JV4l QyU3JWUhJiVhITwlayRPPCtNMyRLQy8kYiQsRVBPPyRHJC0lVSVqITwbKEIgGyRCJWEhPCVrJCwz WiQ3JGEkaxsoQiAbJEIlYSE8JWslPSVVJUgkRyQ5ISMkYiRBJG0kc0VQTz8kTzRKQzEkRyEiJG8k OiQrGyhCNRskQklDJEdFUE8/JEckLUE0JEZMNU5BJEc7SCQoJF4kOSEjRXklYSE8JWskTzktOXA8 fUZ+JEcxPzFEJDckRiQqJGokXiQ5JE4kRyEiQTQkRiROJTUhPCVTJTkkckw1TkEkR0RzNiEkNSQ7 JEZEOiQkJEYkKiRqJF4kOSEjRVBPPyROOl0hIjhEP00+cEpzJHI1LTpcJDkka0ksTVckTzhmOkIk JCReJDskcyEjGyhCIBskQiQqPz0kNzl+JF84ZSEiJDkkMCQ0TXhNUUQ6JDEkXiQ5ISNLXCUiJUkl bCU5IUolVyVtJVAlJCVAITw3QExzIUskRyRPO0hNUSQ3P0kkJD5sOWckTiVXJWklJCVZITwlSCEi TTckUyEiO0U7dhsoQiAbJEJNUSRIJDckRjtIJCRKLCQxJHIkOSRrJWEhPCVrJSIlSSVsJTkkNyRG OkdFLCRHJDkhIyVRJT0lMyVzJE8kYiRBJG0kcyROO3YhIjdIQlMkKyRpJE5NeE1RJGIyREc9JEck OSEjIVolOSVeJUMlNyVlJWEhPCVrJSIlSSVsJTkkcjpuQC4kOSRrJEskTyEpIVsbKEJodHRwOi8v c21hc2gtbWFpbC5uZXQvamltdSAbJEIkXiRHISMbKEI= ------=_NextPart_001_0009_01C6C938.F6DF78F0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjgwMiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9 Mj4NCjxESVY+PEZPTlQgZmFjZT0iGyRCI00jUxsoQiAbJEIlNCU3JUMlLxsoQiIgc2l6ZT0zPg0K PERJVj48UFJFPjxUVD48Rk9OVCBjbGFzcz1sdGJwcmU+PC9GT05UPjwvVFQ+PC9QUkU+PC9ESVY+ DQo8RElWPjxQUkU+PFRUPhskQiEhIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKBso QjxCUj48L1RUPjxUVD4bJEIhISVVJWohPCVhITwlayRIOEAkKCRQISEbKEI8QlI+PC9UVD48VFQ+ GyRCISEhIU14TVE8VDdjQX1DZiROGyhCPC9UVD48VFQ+PEZPTlQgY29sb3I9IzAwODA4MD4bJEIl OSVeJUMlNyVlJWEhPCVrISohIRsoQjxCUj48L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMD4bJEIh ISIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigbKEI8L0ZPTlQ+PC9UVD48L1BSRT48 UFJFPjxUVD48SU1HIGFsdD0bJEIlOSVeJUMlNyVlJWEhPCVrISobKEIgaHNwYWNlPTAgc3JjPSJj aWQ6MDAwMzAxYzZjOGY1JGUxMWRkODEwJDNiNjRhOGMwQGE1OSIgYWxpZ249YmFzZWxpbmUgYm9y ZGVyPTA+PC9UVD48L1BSRT48UFJFPjxUVD48Rk9OVCBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjog I2ZmZmY2NiI+OC8zMRskQiReJEckTjR8NFY4QkRqJE4hWiU1JV4hPDZDJC0lLSVjJXMlWiE8JXMl VyVsJTwlcyVIISohWxsoQjwvRk9OVD48L1RUPjwvUFJFPjxQUkU+PFRUPjxGT05UIHN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiAjZmZmZjY2Ij4bJEI8QjtcQ2YkRyQ5ISpAJ0hzJDMkTjUhMnEkSyNH I0UjVCQ3JEYyPCQ1JCQhKhsoQjwvRk9OVD48L1RUPjxUVD48L1BSRT48L0RJVj4NCjxESVY+GyRC ISElLSVjJXMlWiE8JXM0fDRWPSpOOyReJEcbKEIgGyRCJCIkSDtEJGo2TyQrJEckOSEqGyhCPEJS PhskQiRJJEokPyRLJGIkXiRAJF4kQCVBJWMlcyU5JE8kIiRqJF4kOSEqGyhCPEJSPjwvRElWPg0K PERJVj48QlI+GyRCISEbKEI8QSANCmhyZWY9Imh0dHA6Ly9zbWFzaC1tYWlsLm5ldC9qaW11Ij5o dHRwOi8vc21hc2gtbWFpbC5uZXQvamltdTwvQT48L1RUPjwvRElWPg0KPERJVj48UFJFPjxUVD4b JEIhWiRBJEokXyRLGyhCPEZPTlQgY29sb3I9I2ZmMDAwMD4bJEIlVSVqITwlYSE8JWsbKEI8L0ZP TlQ+GyRCJEgkTyEpIVsbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJVj48UFJFPjxUVD4bJEJFUE8/ JCokaCRTQXc8dT8uISJNeE1RJE4kOSRZJEYkckw1TkEkRxsoQjxCUj4bJEI5VCQoJGslNSE8JVMl OSROO3YkRyQ5ISMbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJVj48UFJFPjxUVD4bJEIhWhsoQjxG T05UIGNvbG9yPSNmZjAwMDA+GyRCJTklXiVDJTclZSVhITwlaxsoQjwvRk9OVD4bJEIkSCRPISkh WxsoQjwvVFQ+PC9QUkU+PC9ESVY+DQo8RElWPjxQUkU+PFRUPhskQiU5JV4lQyU3JWUhJiVhITwl ayRPPCtNMyRLQy8kYiQsRVBPPyRHJC0bKEI8QlI+GyRCJVUlaiE8GyhCIBskQiVhITwlayQsM1ok NyRhJGsbKEIgGyRCJWEhPCVrJT0lVSVIJEckOSEjGyhCPEJSPhskQiRiJEEkbSRzRVBPPyRPNEpD MSRHISIkbyQ6JCsbKEI1GyRCSUMkR0VQTz8kRyQtQTQkRhsoQjwvVFQ+PFRUPhskQkw1TkEkRztI JCgkXiQ5ISMbKEI8QlI+GyRCRXklYSE8JWskTzktOXA8fUZ+JEcxPzFEJDckRiQqJGokXiQ5JE4k RyEiQTQkRiROJTUhPCVTJTkkchsoQjxCUj4bJEJMNU5BJEdEczYhJDUkOyRGRDokJCRGJCokaiRe JDkhIxsoQjwvVFQ+PC9QUkU+PC9ESVY+DQo8RElWPjxQUkU+PFRUPjwvVFQ+PFRUPhskQkVQTz8k TjpdISI4RD9NPnBKcyRyNS06XCQ5JGtJLE1XJE84ZjpCJCQkXiQ7JHMhIxsoQiA8QlI+GyRCJCo/ PSQ3OX4kXzhlISIkOSQwJDRNeE1RRDokMSReJDkhIxsoQjxCUj4bJEJLXCUiJUklbCU5IUolVyVt JVAlJCVAITw3QExzIUskRyRPO0hNUSQ3P0kkJD5sOWckThsoQjxCUj4bJEIlVyVpJSQlWSE8JUgh Ik03JFMhIjtFO3YbKEIgGyRCTVEkSCQ3JEY7SCQkSiwkMSRyJDkkayVhITwlaxsoQjxCUj4bJEIl IiVJJWwlOSQ3JEY6R0UsJEckOSEjGyhCPEJSPhskQiVRJT0lMyVzJE8kYiRBJG0kcyROO3YhIjdI QlMkKyRpJE5NeE1RJGIyREc9JEckOSEjGyhCPC9UVD48L1BSRT48L0RJVj4NCjxESVY+PFBSRT48 VFQ+GyRCIVobKEI8Rk9OVCBjb2xvcj0jZmYwMDAwPhskQiU5JV4lQyU3JWUlYSE8JWslIiVJJWwl ORsoQjwvRk9OVD4bJEIkcjpuQC4kOSRrJEskTyEpIVsbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJ Vj48UFJFPjxUVD48QSBocmVmPSJodHRwOi8vc21hc2gtbWFpbC5uZXQvamltdSI+aHR0cDovL3Nt YXNoLW1haWwubmV0L2ppbXU8L0E+IBskQiReJEchIxsoQjxCUj48L1RUPjwvUFJFPjwvRElWPjwv Rk9OVD48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_001_0009_01C6C938.F6DF78F0-- ------=_NextPart_000_0008_01C6C938.F6DF78F0 Content-Type: image/gif; name="logo2.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6c8f5$e11dd810$3b64a8c0@a59> R0lGODlh+gA6APcAAPP57vDRzNfn0/Tr65ANEpTGxXF0c4uOi9rY24t6T/dvC/FzcO3r7UpMSsna 2uPt2+fIu3KQkfb79Zy8wOv392yYY/O4svGnEqbIyFW1sbFQM4nEve8XD/v39zEzMrHMtmy6siHp mdje4UJzj+bs7ZKSZ8fIxZm1uCOgnvb7+4K+vky8fKJerbq4ue3v8bjV1fOTj4akpHHFxt3l5OXj 5bbGyXq6tXm6unqKWcd5enSPpiBYYFuIjt2ysvw1M+f19TPVi8naxfXv8TrNhunc39K7x2ihlMY8 KE5sac1MT6inpWOgaU6pm+bu5ImltO7KFfDk48+OkHG2reXn6vs9BJiilae7vd3s7Xmlo0TCfmG6 vHrEtmWyp8zh4vf3+9Xk4h3unahBR/r/90HIg/z3+3urtIWYrO/761OYpsnQ1Bj0oefz5F2ma9Yp G1G0dVqscPSBfXm2suzn6oCyqFMHCN7s4rnYwdbKzJ2XHCjhk9fR1ubz7flJRbfO0EuJeanMaN7m 7KjW16WwnJukpEREQzc9O2WrEtTc0IO6uO3t5Ky0rBCBfWuipK0vNKiJuXq1umVmZI7DlZHCG6nO z/KmoNTs7KnSx3G6s4+ssGinsyzbj5qZmFTEvu7795C8vu/7+31/fiUnZ7lsblpfXMUBAY+1uoSy soS1up9jQKemucmnhrK5r+/3+JS2pW+6uqjPpHC0tEdOd7jb3TDckbFYXBq0ttTm6nS+jmoQdw6K L9Ts4+Hv8JKyspC7tDm7rxcuKtegpFRWVHq0XjLBx2pbcrrh4cNeYW+0vLixtL4hnd9hYq2trBob Gt7QeuLz81SAKcThyzzHgC8FBnlQQI7Q0yQlJPphXOb78+Pz+N7z7xMTE06na0msUxsAQlO4ae/3 6+/35////+v35+/37/v7+/f39+v34//7+/Pz8//7//jz9/Lz9/jz8vP3+O/34/v7//r//+v36+vz 5/P38/v/++vz7O7z8uvz4f//+/f38ur38fDz6OryHBT6pgkJCf8AACH5BAAAAAAALAAAAAD6ADoA AAj/ANuRmyKnXDhy6MiVYzdADxR2QgZ0EAJFCI1NkCAho+Hi4EEE6OwdFBiupL11Xmig+wgyXbtw M0yQIFHyIDkvNfGRgyDEYDiR5ciRO+gioYsOA4SQYTAgqRAG5DqsExquXEQoA9R1gDrFnr0p72wV mPSFHAl0LvTomVKuC6A0M9qdTSOCRg0MGKzgRaRC1q4uLxwgcKSDSYFSPBhlmuDgxYRHfpZUWIKo MhcuTJigYNInTRoXNTDFOIGJdIwIMVJjwsSr9ekYq2PLhp06BpYIt7GcQMKjN48IwHOr5jU7gpHj Rvwox+nChQiU4Ri4mMlAnTohK6MrgcTMnz9t1SC1/6CBzx46PUI6lEOXsJw6dB3Ud6hZcmjJGlFJ dCBTdF04F9exEwA7cpxzDg3n6KEVER3IEV92XtCUEH/1DQUPPAid0xQNUyAgAlteAOLFDDXQFU4a RMgxBQnliNDODDQUwUA5Md0xRR8OWGGFCVVMkIEtf1nxgmMRGDABBiSMMEEfO2Aw5JCyNDbkJBgU gIgpEZxQ4hQTMOGkAyo4gMEkkximRQZlYOLEBKU4cYITcJ4gZykjPMKIDidYYYYTeJqhA59mqMkn JjqYwcMIiI6gnHJIYIEFbKilJtR84eBkDzsdqOOFC17IAQU6M2ynjXekeueBAUVYJAemZFQaTjsT df/ADjkvkTPDUCIdhE4RcgBDgxAiwMeAHOHEx845872Dk3/rHXROdWTI0Zw60ZKB7FYRsWOTC9Ki ow4DH6JTRxdX9DETOV9gkMZ67BUlggvnTDHDDAgwMAMy9CLAQigTnPnICEjoGAEvJ2CBxhelYDDB BBsUUMAGNtigwgYqqFCAKxlo4UsGKExSwAuykOmkkyF38eUNj5RyyimPPOLJwmyWUsojVWJwSmM6 8KBDLDqPoMPPOWMxwqCyzWF0KS+YDNzSEdj3zkvhwEeDOi5EJUdTywTTXamlVgPKMkr1VFU5HVzL wFb2cCqCef/Zg1UATRFBAwLhILApTkKwo22E5Nj/04FQuKIFn1I1GWQPGfupc5A975oUFULkuDDD OHW4kLYXUzggQjkMdM4ADdLKm8wUNGyuBwNYBdPOCJkgEkMfBkTAAxIGYMJIDTs4YMopnmzg++++ P4yBChnAMoEnntigxQZbbICx7xZfXED0BeAlMgZ99PHCI5VhrMIkfQDSRSYYZPIIGotkkgka7KNh MwZoIALL/KYYPYcpPEzygm6stRbUpqyo1B1owAB0BOUc6mgIKKrBNa5VwwDLgBc5GBAOB6FjADQg w0rKcY6SrOMoCBEBEa4iBCIoxAUI4Bw6IkKRV01hKzOaQlRooJD4GCgcN6SPff4jAqGUYx32YFeD /9BBAxOggwQuaIe8pqAHOcxNBHXxQjvekgYEICAteiACEeDyhV8UwAoiMMABDpCGBtTgCw5wwBf6 MIETVAYRwKuYDG7QhxmggxdGuIHzrPS7iangBq5QgStcQTFXADKQcnQFXsYSsuuNyQFkysAiHDY9 LTBhEip4QfVOUYqFlcEUMktYH1ajG17o4CkanJE69NAe9cDDHgwYRDAayDVmjGITv2LH2YQwlAd1 8BwKKRZC5NUC1I1wAESYAumKMAUDluMOQuClPV4ihHOwgwQfhBx8jnWOhPxkIe85WzimRgOOeMtB KrkJBWeyDv2UjnR3yCIZUsiAz0yRBO14gbpa4P8jLXRhC0ZIQxUU0YdTGQAJSPBHDayACSv0ohe9 iyPxPNEFe8wgAxuYoyf4UrGO3uCjHQ1pSG8wATROoAAouIQNLsGFDGDGFZR02JjIpL8XeIxKeIGZ KcpwqEwoxhSeQEMfbNI3oVhRhT9phwlA4QFalkobhACFHvaTqQ6go5tQUUk55ICOZtLwDuRIgxzk Vp1oHogMIWTFF2p1EFnFpxy2kOGtpqCUFF2nAx3xwqQOkoDrnKMcVkGAWcmRjv+YhQEIkIMcRCAH h2QRK1CIbGPBBQg0uiANVvAEFxwgyRzVoA+FiAUoImCFLpyGtA/1hMMa1tENfIEV7YBHMR52A0// iLRiH73BbUW6hSoEsQZaqBhLJyYxV5wpAxlQARMyAAIQMNdLKljk9TyGvJgWABYOiE4HEECDcrzw KU9xwQ+RAYqtOdU71RgFMurSrCm042zomNE5hICAZl61g8XqACCwsQ74VCVzgBBTF1KwC3VuBXL2 AN0UMCeCTUUtV0r0QjlE4gV4XPVvKfBWdbhaDi9oCkGeIgIyiIDMAJjYB09oRiJwQYJUaI8T1EjB FaawChaUYxObcEKgdhaKu2ABCanZTWoptoUtyGBivrjCDyhAAXgkd2KIHClId1uxLXDiAzToQA2o MYyIRUylhTTuIC/hXC7YgAsbuEEBtCADTgzD/xdkYt4fdXuDDOjWFdE5hxygwgAhVAon6sDUICBx 3lIVwgBqqY4X1vFCe6RhCgy4w4WLhQ52kIEI3xLC6ZiCaXsFhRws+Ix/ajKUZkYHPhN84X/OJhQD /qRqRYG1WV5VtaHQ6h01UUdky0kDuZkAAT3QIhREQAIHuEAWXejCLgDhAivkIgXPIIYO+kAnHVTD AWkARTAMMIhBHAARNqAYb/25C1b84ApYYJMndEvlOeeW3RWjBgWukAJ4BAIFHv2ol23QXBC88d+D NOTyPGGCNAjiA72QgRa4oFJ+X8KAHeC1RDqQAmUZUB2bGEWhSRWMA0whDTTQ66Y6MA0HSJWIev/9 kCOu2EzBIsA60vEJYBFAhCwKgWrMIYEc0tM5q3LrPR2QIaVakIb6zMfWUvQCA7yQK2WlgxwpSMEH XZC5GoggjScITMHTiG1IQmwSMxBEEMphh1bwAAMnAEUsiIHtYNAuBsSJmLhF2rsvXMEWvigAypK3 74hJ+d0dlUEXflAMeGCjGNTI9w323e9/vzHgwdWCK16QrtpuAAThfhgIuJAeq1oxbwN4Vueas4lZ btwfwdiEFxzwFBEgtpki0AMBUcmppB8kDC6fUVtVKB2VYNBFXpD6OTSouIMQooEt8EexWrBDocCj HazwRzVkUgc0Js07kPAAJgZByxYUwh9KkIP/Pz5QgxqYoQXob4EH4FKCVvwi/cmvAigOioRfLGwO ci9EMLRhhC1UjBEOUA/1YA+W8AIjYAD+EAf91ly/4B0t8AvvNmUVo2yDdwW78GTuxnjN5XjdM0jL 8yO7UG/DUAC9cAkmqFKY51UMoAdWdHRT4AKaJgcZd3r+MAoHgBbwIgROFBM71xTxcRB6VRIpEA53 cEzoIAG6lBAz8CoTxBToUAMCYRZDIV7ngBP+EB9YuAkdAH4dYABpQwJXMANXRwiYcIWgACXtEHVX mHxXUA0IgIXxQQgImFhb+AF2YAlIAIcmoDmpUAZXiIXVIIcGMIibQCqj0h0O4g+9EAFbYAMO/4BE 89AADXCF1QBu+3aFV/gLXhaBHwUCV/AFP2AyGSBwudV3fUdmCwgCKmADBbALzpACziADBTABiBAH tniLViR76kE3UxgOJOAF6DCDp9dxFIQTOOERlcIgUHA2kOYtUXM2wccKffMf61EOnBIUoDMvOtAc xuZdBmQP85B8pLKFW1gIW1gF3TYISvAFV6gNW4h+ihCPDsAKwRAfNahxmNgBB9AC2jAqhLCFaXAA ChUBxICJXcAdVgANy2AGBtABhQAJg2gASrCFB6AEV2gACEBofmgA74d+hVAPm4B+BlAIvtEbNnCF kNABSFAIEcOJJEUCdTCAHiNmpWiKXoaKC/94CZkhC87gDLswDDJQBrc4lDSnDramBzXxEuwhBwcw icO4CSvxEpxiK++xDmdDYmTwQehQIFlUNfBADykAWOwRFC+0Es0xHdNhDyQghiKQBmk0AZ9VUAZA aB0wiVtICHiJl9gXh3mJl9XQB1q4hR5QCNHXAZAgfljoHR1QDTNwhR5QA4WgWAewCdqAAP7QEVcY DJPAA+OomMe3hW/oHUzpDy1gAl1oD3/oHX15fFc4kd7RkpwYByTQBInQAR6jBVrwbjZ5k6kIAhvA BFwwCeWWAsPACX4wlLd4c8U3LRyBOAXhAgeAj06lDczgAaBQTPbAdPUFXsd4EOXwEkr3V3f/8DkW 0S5nw1UF1DmPRg4YgG1o5AAz0AVf8AXVNwN1MAPB0AKLeYWbUA3iF5GD+H0puYUAioAesJj6uIVf 0AIP5A+gsIUpeYXM4I6QUIimuYXakIh68IcIMAoNEJjasAF4iQQMigR+oJgmUAh6hAAH8AeNaY8P BKCF0IJa6A+M4G65hZskcAhNMA8hg1wZuJsr1Vw4qQIowAUvsAs/8Am1UAsjEAdSgJxy8IbqsHNE cA5EgBXdFBWDdnrMYADIgABk4AWNA4RLiBNRQS1aoWcmlDZHFJ8OUAOWQ3RksyIHMAPKVF/zMi9f sKdp4A+K5Q9puAkH6g9R9wOd0AkUkJri//cDP5ACP6AL/mACyWePheCOhQAO4uCOHrAKimmPBzCg V4gAy1AI36eflNkBHvANDRAfo7AGhwB+cjAKH+APDakN34eXHXB8DekPhHYMsHALwtoLhRofHpAJ mvVGLfMIcWAur1AH5GAFE3AZUhCliICTvdlwNnCLUcoFBUANxbALslgKRsAF1XqunCNY0eQgTZEe PiEqG2edJmBf3eUR1TgF6xAfcjBN7WCNJCCfXWAFNTADxgYqM0AHBDsDgFBsZOp6MCkveDovUwCo WzgDF3KgJnAAS5YCn0ABrNAC4seOuqALdaAP4vANmIiJJlCP2gAOLmuG4BAE1dABFgkOB//QAcnn qSYgCOYAAI4pfQfgAS57oKOAsvZotKp6AHXwh/HhjtqwBMzABMalWxvACHLgAczQIB5QAI+gAsra MnHwAiQQBEEQrVaAGdUaB9fam/2mrdwaB94aCIHwA9RwGOV6rtX6X/H1KwEQTQgwE+zRAgtUaMxA CJtwByoULN5ZDjORNoAACDjyRVX0BS2WRiSgB+/CAlL0Eo0zE1D0iPZAAVFHFQexodXQkxTQCd4R DEvmDHtAeHXgAQdwsi7rst/wDeBgAv4ADsl3u97hsuIADrYaBC77fYfgsuYwqS7bBMEADu7wAE0g qOUAAMHwALgrCIPgspOYqeAwCgx0u+D/IACKsArkm3wnuwZ1UAcPIAACAA124A+RUKuFoAsYwA29 8Agrs6xxUAckUAHP0ARBYAiZwQRROqRsCwJua4tScGYFMAyBYAucoAJOcLd4q0QRxxRQQGIZPCw3 hwCbwJrnVQgHYAJOJAe/+IX0Uj1pIGkgQQIr0kwMMAUfMMMmIB1dMQWAQA620AUfZA9DGA4XQh9A TAFL9qhL6qhdkLoUkA26sAbxcAa4Cw63C761O8VTDLziELy32wSggMVafMW1a7sC8A0ScBBN8A37 QMXgaw7gwMa5G8aa+sVSfAZhDMZrsAYPUJtTcAivYAevcAtb4AuckAEk8AXPUAgu8AWZ/1AGmXAK ZVAGMVMKvWA/KmMK9WM0lWEDiJAZBSAL1GAL+IYGx+EopDwJVpcjDPAsWlESZfMfyGB6NOgdzNAA SjAjiDMDZ4FYoNEC3EUDwKAHpVkDn9MVHSHE9JECrJDMoksBsQWpu7ALlZANiaoP+hAP8XCyZ0C7 tZvFUmzFUVzHYBy84Iy74mAObmy7tjsO8zCE5PANAEDFVWzF6BzP2xzPYOyyALAP67sPAOCyePwA 6wsNQfAKkiAJAtAEf1DQhnALrHgJ3LNuHwULl4AFrnAMFl2tXIAImKFJZLIDaMADo0zKWNAF75I2 1pgpvFTDR8EAJmAAoxLLhnadDGAuUP8kC7bQHOVAwvbSDvZADvDACkyGzEBtbo96BV3gDNngsT3p DI9KAXuwB+Nwuycrz1K9BlnszXBsu/dsz/A8znA8xQAgAUMoAbibxt581vIMvFqN1V8txdArAVHd ze9cx1M9xWsAAQtgDT7wD//AAXz91359C8gFblDKBIvQBQbQAH1QJCBtBCI90h8CWDPxHnJADq4X FPZgAtwB01wjrx1AbClgC4HQBc3BFvbx053wA5VQDBTwCZ/gDErNChzrDJ8AD1E3zdUcD7i7211t z1mN1ty81lQc3OALxWF8su8MAFE9DvXQBOPwzmgd3VcM1gAA3bxtxVAsDkEgD+OwBx7/qw9o3Mb3 cM4BAAEWsNc+4LJ//Q9HgAr/8AZZkAf90A8r8A/uawcf8AqREAkbkAtfcADSUAPEYAZmoD6LjAWM YARD8i5HZDnNAQhQ9HHLAArfx9lcE1Uht0NRF3XJ/APmxmSVoGSVEAiLIAuB8Bd1sAf0uQd17dtZ zM1srandjNXiPONbLcVrrdXVXd1RDcbu/AD5PNdWXN1Ujd3WPd3unNZSvAb1gC7FEOI/8A0WsN5/ 3QZHoAEagAoV8A8Q0AYJsAQrIN//oAEVMAtqMN//AA7/vL7sK9Bkawd2EATu+wp0fgtuIAVINB0z MQNfkGwvkD1ddQCwbOGkwgzBsAo//1wStg19rMDUIU4BX/AyX7ADW+AA0NAEMTkOPW7jU3zVZ/3V n67W0T3O7gzFt1vdEpDqqi4GYqDq8zAPPN4E7JHcAGDq9/wNZ7Dj0q3rW20NVP4PcFAJ4/APbZDl CVABbpAF873s/fAG/4AKS/AGK6AJ/dDXXg7f1T7PcfzF4nDHTcDm0BDuQXAIQVADXFcHthCfXyAC CAAKTknoDaQNkFADySzbyOyo2PCo7fADnACGKQ7G5lDXL/4N2szp4GvkUg3joS7jOV7FYZ3q89Dj 32zr85DqYJ0P6JAPEsDqEqDc0o3d7kzr3wABv77eF8APKJ/y/7AHxL4EWUDtzB7z1f9+BGNw5mjO AUeAA24wBNV+8Jpqzm1cxeAgDy/+4uZwdWmERn0wn22pCJsN705luAgADx0r1J0g2xJgD/Ug8aN+ D1lt4zZu67br9TNO5KA+xWdAx+ns6tDt8FOs6kduxWRd9qpe92R9u+VtATBg1lb8D1SgACef8igf +ILPDxfAB/8ABjK/+NXOAWT+BkAw86jgBjD/D9/s2z9/D+Md8EYvAl8ACKxAA2YQnVgL9TR4SyQA W/qg9ddMu9ct1dt+u6reDppeD7p9u2kv9lW8BuPQAW3P1bk/5A9/9/A85HBP8KdOzm28Bk0gD2Iw D7he6xAAA3CwAHxNCe5c5Vbu3q3/7ur/QPiFH/4q/w84MAuKz/jLTuyTz/MzjwNDEAJoTs/DzcbB vc3mDEV9Kkulb/o0CBDVRilq8s3gwW/gxJkTJ04hwoPgHjSRJy9evXHz5qXgOM5jPYMAvp05A0AA jX37EJKE+E3CSwkAZIIzCI7mmXEy571ECODMSJvgzIFLBIESjH9JlSZtgyoBjgpH/tn8pwFHFiBg +v0TifAfP7BhxY4Nm7TfWbRp1R5pk0UN2n9H3sx6uxViUHND7wYNKsvWDAdKGlTzV9jwYcSJFS/2 V+iAiZYNHUa2efABTcnm1mwW921eO47kUrTTF+9bPQGJ8vmM2NmgBDExuwp1p/db/04AL8cdJCkz IjgOS5Vy4NDmiIan/9gAQZvg30gfCejCrVz5HxWy2cX+a1phiZssatceQbXkDfO4c0Ocfd4wb0Oa v/lCFOFgiotNhRjv588YUpU1JIsPofkgAuCBfTSD7yD48nogiFWWMWGGclwgp4NzANhtHJhi+mam ygzyKDcx5hHJAjj48EG4pcA5o6oh8hBPvH/Ucq6kGtV6DqJ/ONDuR+4qWGGM9WZEC5UjxqhrK+mW nErAEGtaaLK7nLHlh08g6W9LLv1pAJRDgkqIrwLHrOwBdxQaUJw1HlAEFA8K02ZOZhxTpINEEiHH ixTIEW2e3RIyxx2fZJIAigAC2P9NghWXOuIp78Db6h9r/sEhRiPT+qc8SW88wwe5smJPpq6++eeC H7WLC4glK1iqOKuWSCBJrdg7ogI3hljvHwETInDB3xYyhxUKKGBFvy6TXUwgRciMUr7KSnpAHoUk EycIUAhRTBtmmKlGoEFM2OeehioKwIKjWEyquDb+SYS76TJlr6oV8qhV3qquktE5gyi59Q2s7III DgXGemKsgreTC9OtbvpnhSVnHePef5qkbsAxh3rWJvdsouAHjghTdmTEqgFzr2fv+mbaAVuAkz9p 6CAgOHWN0wAVqNgYw14aOahgjFnknbeCe4V+OF7nRIouXoF9PYMS7FJNuKwj8nD/MqQcm6MVLovZ MzOvlPHS+CBnfqAgBW1IVtuwYBS5TMyW5DOoicoEGKSBtBEjQN2kqFDggoMrfsONaISGawXD0ZIq ca6VPCtpAJYuUuCSZPoqVX6mBou7BCpgQ9d/YBsgLhw+ByOBNnCYRcataLQpL9uChQ/jb+rQZQ9x tFxbbWYMUMSgn1oq9UPWEJRok1EUuw5zqolkfCsOjsBhLqGlqoD1s6Li++HJnXtpaSd7Y+0fzTNH eCzuhqB4KRulH0PUrOG6R6/gzSQzbo7F2UTb3UkO5oAHfGMffHFNSGpik33I4zarGIXIDiON5TGP H3FZwSyKhi9U1EstQ3hDBdSn/zjukKdzK1CKD/gABwtYYDdxScAKhtAPfn0DVG8IQV24IhIN2eFU Y0GVWKJWljbgagzsKc4RyAMVN2iCLVmYRdBapyPg/UZjtDvgPe5RGXFUgX/9UxYzgrGMAMZtTN8Q BwDEQI96BKEeh3iZyQ5DPglu7ojf0YThLOUGIBQpKSbkACpwxRwj0qgeGDmXBWAAmk1VIAsvdI5S aNQTAcBRLD0MS/l6hIo3OE9eRmyhE+PnNWilbEzucc9m1qCIYDCDiyPr3TIg0pncDGAAIqnHACyQ KEpEYQCFyQEBdlmYHWLuAgpQQFWW8EEYvuGFZ8GZC9nTzGX+IyVwSICO3Ie9pf8Yhzz/QEoF8pi4 f5CkcuOIYCXH8kM5zuWCM2JL55K4latQzH5wuwvsbGMtBjpwlV0axSYSIUBZvkQIAwgADGQ5ABhQ IgALUEYYftnLX/qjnJvbnqVmMTnxoEKTW9HAElY3r6QcgQ2LZE8bEjBEobXrH95c54y4UhKDrGGi /ECn+bYTPafgapPSodilKPY6UX5tigySTBAMgKx9GmaL/tgE25BhAG0gIwmyXMBBF3BVrCJUocqI AjAe6svC0OFylSQAKUghHGuIo2IrEFU/boYDN1QQFcyBSyYxmqmkdA1f/2Ca0X4j05pSEiw1rdjz uIOKXO3KKoltWFA5BjtfIQT/dtfKVlIJMYBNDKAHAzhAFUAhil1uIgBhiEJmw0AJSlzVoFjNakIH 0AhZLoOXBEBGYc5KFuFQQbf/oMSmNDkE8ixhZ4jTUV/3ikldCS04qHBK6eqIV45hRpJh8VFYnnCw 7WgAe0brZK3ighxchWBHLXnde8JWrYYcoBCqVNtBe5ADXfpyAL5UgiyT4NVGEEC/PTDAAJKgDNUO oKoEtUBVr5qD/ILVH72srT/EWj4gJRKP/SBuc2hUwZbS6JPyck4FGTcVmxTqH9gFyzAnids24DHD mpqrk3CgQVDWE2yiDAqbzHEPSORNbb3Ur37nK0v5KmMAQu4BARwaBV/CVsAB/6AEEVh7VQHnssdf BUVh9hbHCVZsDMvsZJE611YmueGuRkqKdhPnnOcJrCsAmC4/LiBYE2/noh/O4OQqhitdDWG8CXFP 7PBnk/k5RHdrO+gAaBHfARDBlxBQhjKA0QICQHS+ASAALZKQVXShNgBQ8G8PilzkBvdyi8FkHnfc ojg8Fim4bd0wvpDix5Euc0bOwRkbciWcFj6XhLeBCZvPJxYIb1g4GpgwkwAWzfMUadc0qRY9CdTs V2Jrqe31ZQ/CgAxR0GIZihCwfX/87UYcAcAGjfJVKfHaSPeYf708jFjjyDm27ioBpnsiWkholcFl IQGzMmKusGmQpTTqkm5g3f+szuNdODTkk86JDRm/YYGxDvacgp0gDrb7D3mwmQMwhl5HV7CrDf4D DliFQ8lLrsAD3s8gsJtfFZK3Oyj0EhQ5yAEoCACBYKDbob4kQAt+7MsoCHkA+8j0Au47XyP32DBh CANitofb6MEVPS/2pL4e948awmUpFYjXLP5xkdaksEdNwcESsmDEb7LHAgC3Clv7gQoQx6cJE6WC YP2GPhwU7R9iwAd3LqXHn7GOhEKi66S2x+cyzdMmJjhAnEh2WR/7gxCbULR9hRyA1zZi55gnABHE DQd5dBsOByUCgJOA5B4YRpaGqehMN8yBtVzlm9Zjq4xEDvAEHLwfOOCbEa3/4rkVFK5HCVhC8JtG up31o10Di/gEBTvRC2yKVXB5gBi0bOfAa8U5Xwans57dkiYwUG2KJkARCEOIIhh5vkcYgBw47WMf 96AR4QawLRk6VVkC46pJKHIj9EOIRggA1oMwIMkgCzoLDYg1ZsIzW7EauFg7U7ERFiI4O9Ko59oK eeCQqugcZUqKgxAJOGg+EUSnYkoAxhoCH2gCdLAUMFu4Dfw4O0q8lFOIADkILSKZ14ooQjAyl4GA ARgEXyGC9wMyWug8AYMBZUAw/QqDS4MBo5s/sJqvHGC9mkqVDesOt3uUY+Oo5Iqxh0m+fggONzAu MqORediMT/oHH4gIGRLB/4nzoU+qAGtQoIfREY8CoTa4GUipMNc5r2rJDQm4DY9QhFFgr/4xAAfq p/kBh3sQgE1YhrQ5qP+QJV0aAAjoqkQRMAiALQLQj2DIgV+ig7uTICq4M0x5CozKIIpJgKwDJXD4 h/fRo4opPlkzEqmgIU1pkx74lyFADzggo3gojR45p18DIsTqRbeihDUwlSMwu+dKQ0thIsPZNfyR DEFECHFQglRKKsMoBAOAjG9ogkNQr7zZIsIABW4JhkFogRaQA1lCgAGoL8OoMtuiuB95gqQQElVb gqIxwXhhIbgaorhbKZ1Bj38Agu3CK8EZg2c0CDhAhVbcCgvYgz3QB324hv+ZqilL4gCfOosj6AE0 1IAuhCcmsr2Veh/DiaFny58GeQ9zYKNpWyVm8IBRqIIWMIH90bHF4JZq8IAvqYIgwEmkSozWEw6I 45siYgsRSgC408JosD2asIAj8DAisoosSEi14D3uQI43iIYVWMNvgIC2wCZ0IAd6kACPIDWwKB9L QoUssDMHWIM68Ls3cCa+cpLDEpJaFA+peKVqQQgruqIQSYP94cbDqIYGUIJlMABDTIyZ/I9VAAW8 6RI6qEyZ6bGyIoXi4IMPWSg+UBEf8AFroBm+WQAWoQTiKcq4MCIjcooECA4iEJwVmM0E+MVvoCZl 8i4xqIc66M25rEKEeT7/6dCU3oykkEu7ScnDCgAYeWmXGnMIaCOqD4GJcYBJw9wSbfDJx5iBjPuQ kGiCTcgxkpnJAziElfhAUvEN+Rgb4sGh2fA+A0oh+TS5ADiIFAlN0RwjFoGBQdoDAeiCOkAK1SxK QCGnEEIOqZjN2RQvZpyeLIiGC9QRDnAWKprOrmATAcCWybxO/miAA5gB2IiNUmmCNFCCAxiF9eqS OnmMgiiQ9ExPxavQUKKiejAjcggUMcpR2JiHemgCAfhRIBWAOqgHe7CHJvDRDA0CSfgAO3iFEsAD VYDSKIAGVdAA0OStOgCEehC4igIHLm09C4BOGcyYGRPHFjiAYNAnDlUM/w/4RoTICZjwExJYhQMY DJ1UjGqABBMQAPsxIPJylsrxDZE4AwqNGw4Rg1KpDPWsJ5rIDXJAy5ZIiZbYDdeoiINYxm9YAx+t gx9tE4OwB0BIAxdIAQmoB3kwJc+IU1KdB3vYCQnYCQ551QIdJJCAzjEyiM7YBwDYGEBjPMdb08PQ BsT0HfP8DYjwiFiNjVclUTo9gAMQhFVIAwFYg6BCGXoanhilooygBzGIG2ytCXe4h9MYhzMCFIhQ iYRICXRtiQfI0D8IgmkNEJRbg3XdVBIgAXsIh3CwBzEaJDJSuW8wjXioiIo40jWohz0YJI0wEZGQ h3zwk+gKigc4BAipLGNg9RZCGAUD2IRonZbvy9Hb2IlH9ZCPFaP4eJbgGZ7yutYPFIPYAAkZRRmX cFm03A1wGB51/cAcZRNTola5TNJpIQcHuAIXYAUvCId2aNWdtZYCAtm4kYcjrYd56IAOIIdyCAgA Ow== ------=_NextPart_000_0008_01C6C938.F6DF78F0--