From owner-netconf@ops.ietf.org Thu Jun 01 06:00:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fljyz-0001FZ-LP for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 06:00:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fljyy-0005cy-93 for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 06:00:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fljnt-000CQH-0C for netconf-data@psg.com; Thu, 01 Jun 2006 09:49:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [61.144.161.55] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fljnp-000CQ0-5m for netconf@ops.ietf.org; Thu, 01 Jun 2006 09:49:17 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0600CM7E4C8F@szxga03-in.huawei.com> for netconf@ops.ietf.org; Thu, 01 Jun 2006 17:53:01 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J060014EE4CGO@szxga03-in.huawei.com> for netconf@ops.ietf.org; Thu, 01 Jun 2006 17:53:00 +0800 (CST) Received: from l48181 ([10.110.114.162]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J060040ME6JO9@szxml04-in.huawei.com> for netconf@ops.ietf.org; Thu, 01 Jun 2006 17:54:27 +0800 (CST) Date: Thu, 01 Jun 2006 17:44:01 +0800 From: Li Yan Subject: and filter conditions To: "'Netconf (E-mail)'" Message-id: <000001c6855f$ecae48b0$a2726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_38np1nhERIWOZbOIDtJtBA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb This is a multi-part message in MIME format. --Boundary_(ID_38np1nhERIWOZbOIDtJtBA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Will the request get a positive response, when the result of and is nothing? If the subscription is successful in the circumstances, the session of notification will keep silent, and each event generated by server will be mathed with the filter conditions. Therefore, I believe the subscription should be failed. What do you think about it? Yan --Boundary_(ID_38np1nhERIWOZbOIDtJtBA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi

Will the <create-subscription> request get a positive response, when the result of <filter> and <named-profile> is nothing?

If the subscription is successful in the circumstances, the session of notification will keep silent, and each event generated by server will be mathed with the filter conditions.

Therefore, I believe the subscription should be failed.

What do you think about it?

 

Yan

--Boundary_(ID_38np1nhERIWOZbOIDtJtBA)-- -- to unsubscribe send a message to netconf-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 Jun 01 12:51:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlqOZ-0007B6-PP for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 12:51:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlqOX-0008Mw-EP for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 12:51:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlqFo-000172-A3 for netconf-data@psg.com; Thu, 01 Jun 2006 16:42: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [63.240.1.43] (helo=relay2.nyc2.attens.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlmVY-0003SL-QX for netconf@ops.ietf.org; Thu, 01 Jun 2006 12:42:36 +0000 Received: from mailhub.masconit.com (email.masconit.com [12.107.104.100]) by relay2.nyc2.attens.net (8.13.6/8.13.6) with ESMTP id k51CgZLZ029915 for ; Thu, 1 Jun 2006 12:42:35 GMT Received: by MAILHUB with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jun 2006 07:42:35 -0500 Received: from POOJA ([172.16.15.43]) by mailhub.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K5PD63KQ; Thu, 1 Jun 2006 07:42:30 -0500 From: Pooja Malhotra To: netconf@ops.ietf.org Subject: SOAP/HTTP over SSH Date: Thu, 1 Jun 2006 18:07:48 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi... We are planning to implement NetConf.And I am very new to this standard. In this effort I went thro' the initial draft "NETCONF Configuration Protocol draft-ietf-netconf-prot-12" proposed by IETF. After going through it , I understood the architecture as shown below in the figure: Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | NETCONF operation | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | SOAP over HTTP | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | SSH | | Protocol | | | +-------------+ +-----------------------------+ As you can see, our proposed solution indicated that the SSH would be used as Transport Protocol.This choice was made because it is mentioned in section 2.4.(Mandatory Transport Protocol ) that SSH is mandatory for NetConf. Now we are stuck with the RPC layer protocol. Intially we thought of SOAP over HTTP (as RPC layer implementation), But if this the case, we fail to understand how the SSH layer will communicate with the RPC layer. How the SSH layer will interact with the RPC layer over HTTP as it is not secure. Also,once the SSH session is opened between the remote machine, how can we ensure that the data transfer is secured through SOAP/HTTP? What is the nature of the SSH connection?Is it socket connection like SSL? We tried implementing SSH using opensource Library from JSch (for client)and OpenSSH (for SSH Server). Other tool we tried was Corkscrew(tool for tunneling SSH through HTTP proxies.) Also Is it mandatory to implement SSH.Instead can we use SOAP over HTTPS. I would be highly obliged if you could please throw some light on the queries I have and tell us some tools which can help us in implementation. Thanks, Pooja Malhotra Senior Software Engineer, MASCON Global ltd. Bangalore Karnatka (India) -- to unsubscribe send a message to netconf-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 Jun 01 13:11:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqhj-0007Zx-AS for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 13:11:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flqhh-0002MT-Mc for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 13:11:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlqcI-0003Q0-1T for netconf-data@psg.com; Thu, 01 Jun 2006 17:05:50 +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 1FlqcF-0003Pj-NU for netconf@ops.ietf.org; Thu, 01 Jun 2006 17:05:48 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A2C6355F81; Thu, 1 Jun 2006 19:05:46 +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 28959-01; Thu, 1 Jun 2006 19:05:44 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8D36E55E1B; Thu, 1 Jun 2006 19:05:44 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 4991D73AB49; Thu, 1 Jun 2006 19:05:42 +0200 (CEST) Date: Thu, 1 Jun 2006 19:05:42 +0200 From: Juergen Schoenwaelder To: Pooja Malhotra Cc: netconf@ops.ietf.org Subject: Re: SOAP/HTTP over SSH Message-ID: <20060601170542.GB7051@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Pooja Malhotra , netconf@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc On Thu, Jun 01, 2006 at 06:07:48PM +0530, Pooja Malhotra wrote: > We are planning to implement NetConf.And I am very new to this standard. > In this effort I went thro' the initial draft > "NETCONF Configuration Protocol draft-ietf-netconf-prot-12" proposed by > IETF. > After going through it , I understood the architecture > as shown below in the figure: > > > Layer Example > +-------------+ +-----------------------------+ > (4) | Content | | Configuration data | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (3) | Operations | | NETCONF operation | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (2) | RPC | | SOAP over HTTP | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (1) | Transport | | SSH | > | Protocol | | | > +-------------+ +-----------------------------+ It might help if you actually look at the figure contained in the draft you are citing since the one above is not correct. It figure in the draft looks like this: Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ The RPC layer is netconf's RPC mechanism and not SOAP/HTTP. If you run NETCONF over SSH, there is no SOAP or HTTP involved at all. > What is the nature of the SSH connection?Is it socket connection > like SSL? SSH provides your application with so called channels where each channel realizes a data stream interface (much like a TCP socket if you like). > Also Is it mandatory to implement SSH. Instead can we use SOAP > over HTTPS. I think the wording in the document is rather clear: : 2.4. Mandatory Transport Protocol : : A NETCONF implementation MUST support the SSH transport protocol : mapping [4]. Sure, you can choose to not support the SSH transport. But then you can't claim to be compliant. /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 Jun 01 13:21:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqr0-0002sH-EN for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 13:21:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flqqz-0002da-1O for netconf-archive@lists.ietf.org; Thu, 01 Jun 2006 13:21:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlqkP-00048e-DI for netconf-data@psg.com; Thu, 01 Jun 2006 17:14: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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlqkN-00048O-TK for netconf@ops.ietf.org; Thu, 01 Jun 2006 17:14:12 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k51HEAsx031000 for ; Thu, 1 Jun 2006 13:14:11 -0400 Received: (qmail 8663 invoked by uid 78); 1 Jun 2006 17:13:12 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 1 Jun 2006 17:13:12 -0000 Message-ID: <447F2061.5080105@andybierman.com> Date: Thu, 01 Jun 2006 10:14:09 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pooja Malhotra CC: netconf@ops.ietf.org Subject: Re: SOAP/HTTP over SSH 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: 32b73d73e8047ed17386f9799119ce43 Pooja Malhotra wrote: > Hi... > > We are planning to implement NetConf.And I am very new to this standard. > In this effort I went thro' the initial draft > "NETCONF Configuration Protocol draft-ietf-netconf-prot-12" proposed by > IETF. > After going through it , I understood the architecture > as shown below in the figure: You have misunderstood the document. The RPC layer is 'SOAP over HTTP'. The transport protocol SOAP over HTTPS (HTTP over TLS) is supported. You would use this instead of SSH. Andy > > > Layer Example > +-------------+ +-----------------------------+ > (4) | Content | | Configuration data | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (3) | Operations | | NETCONF operation | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (2) | RPC | | SOAP over HTTP | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (1) | Transport | | SSH | > | Protocol | | | > +-------------+ +-----------------------------+ > > As you can see, our proposed solution indicated that the SSH would > be used as Transport Protocol.This choice was made because it > is mentioned in section 2.4.(Mandatory Transport Protocol ) > that SSH is mandatory for NetConf. Now we > are stuck with the RPC layer protocol. Intially we thought of > SOAP over HTTP (as RPC layer implementation), But if this the case, > we fail to understand how the SSH layer will communicate with > the RPC layer. > How the SSH layer will interact with the RPC layer over HTTP as it is not > secure. > > Also,once the SSH session is opened between the remote machine, > how can we ensure that the data transfer is secured through SOAP/HTTP? > > What is the nature of the SSH connection?Is it socket connection like SSL? > > We tried implementing SSH using opensource Library from JSch > (for client)and OpenSSH (for SSH Server). > Other tool we tried was Corkscrew(tool for tunneling SSH > through HTTP proxies.) > > Also Is it mandatory to implement SSH.Instead can we use SOAP > over HTTPS. > > I would be highly obliged if you could please throw some light on > the queries I have and tell us some tools which can help us in > implementation. > > > Thanks, > > Pooja Malhotra > Senior Software Engineer, > MASCON Global ltd. > Bangalore > Karnatka (India) > > > > > > -- > to 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 Jun 02 08:40:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8wc-0007lq-Pp for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 08:40:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8wb-000096-Dz for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 08:40:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fm8pb-000PGb-UI for netconf-data@psg.com; Fri, 02 Jun 2006 12:32: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.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 1Fm8pa-000PGN-Cq for netconf@ops.ietf.org; Fri, 02 Jun 2006 12:32:46 +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 k52CWjPh024271 for ; Fri, 2 Jun 2006 08:32:45 -0400 Received: (qmail 22178 invoked by uid 78); 2 Jun 2006 12:32:05 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 2 Jun 2006 12:32:05 -0000 Message-ID: <44802FA9.2080601@andybierman.com> Date: Fri, 02 Jun 2006 05:31:37 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pooja Malhotra CC: netconf@ops.ietf.org Subject: Re: SOAP/HTTP over SSH 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: b132cb3ed2d4be2017585bf6859e1ede Pooja Malhotra wrote: > Thanks Andy.. > I really appreciate ur help. > But again..as the draft says > that SSH is an mandatory transport > protocol , Can we implement > SOAP over HTTPS (as transport Protocol) > and still be netconf compliant. Not unless you also implement NETCONF over SSH. > > Regards, > Pooja > Andy > > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, June 01, 2006 10:44 PM > To: Pooja Malhotra > Cc: netconf@ops.ietf.org > Subject: Re: SOAP/HTTP over SSH > > > Pooja Malhotra wrote: >> Hi... >> >> We are planning to implement NetConf.And I am very new to this standard. >> In this effort I went thro' the initial draft >> "NETCONF Configuration Protocol draft-ietf-netconf-prot-12" proposed by >> IETF. >> After going through it , I understood the architecture >> as shown below in the figure: > > You have misunderstood the document. > The RPC layer is 'SOAP over HTTP'. > The transport protocol SOAP over HTTPS (HTTP over TLS) > is supported. You would use this instead of SSH. > > > Andy > >> >> Layer Example >> +-------------+ +-----------------------------+ >> (4) | Content | | Configuration data | >> +-------------+ +-----------------------------+ >> | | >> +-------------+ +-----------------------------+ >> (3) | Operations | | NETCONF operation | >> +-------------+ +-----------------------------+ >> | | >> +-------------+ +-----------------------------+ >> (2) | RPC | | SOAP over HTTP | >> +-------------+ +-----------------------------+ >> | | >> +-------------+ +-----------------------------+ >> (1) | Transport | | SSH | >> | Protocol | | | >> +-------------+ +-----------------------------+ >> >> As you can see, our proposed solution indicated that the SSH would >> be used as Transport Protocol.This choice was made because it >> is mentioned in section 2.4.(Mandatory Transport Protocol ) >> that SSH is mandatory for NetConf. Now we >> are stuck with the RPC layer protocol. Intially we thought of >> SOAP over HTTP (as RPC layer implementation), But if this the case, >> we fail to understand how the SSH layer will communicate with >> the RPC layer. >> How the SSH layer will interact with the RPC layer over HTTP as it is not >> secure. >> >> Also,once the SSH session is opened between the remote machine, >> how can we ensure that the data transfer is secured through SOAP/HTTP? >> >> What is the nature of the SSH connection?Is it socket connection like SSL? >> >> We tried implementing SSH using opensource Library from JSch >> (for client)and OpenSSH (for SSH Server). >> Other tool we tried was Corkscrew(tool for tunneling SSH >> through HTTP proxies.) >> >> Also Is it mandatory to implement SSH.Instead can we use SOAP >> over HTTPS. >> >> I would be highly obliged if you could please throw some light on >> the queries I have and tell us some tools which can help us in >> implementation. >> >> >> Thanks, >> >> Pooja Malhotra >> Senior Software Engineer, >> MASCON Global ltd. >> Bangalore >> Karnatka (India) >> >> >> >> >> >> -- >> to 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 Jun 02 10:46:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAvA-0006sg-Or for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 10:46:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmAv9-0005fB-34 for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 10:46:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmAqX-000B8P-I9 for netconf-data@psg.com; Fri, 02 Jun 2006 14:41:53 +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, HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmAqS-000B88-3D for netconf@ops.ietf.org; Fri, 02 Jun 2006 14:41:48 +0000 Received: from rchemx01.fnc.net.local ([167.254.101.101]) by fncnmp04.fnc.fujitsu.com with ESMTP; 02 Jun 2006 09:41:47 -0500 X-IronPort-AV: i="4.05,204,1146459600"; d="scan'208,217"; a="26002593:sNHT28102952" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68652.AC92D897" Subject: Validating with the Operations Schema Date: Fri, 2 Jun 2006 09:41:46 -0500 Message-ID: <50B73C8966FCF840BABA099651DBE060011AB335@rchemx01.fnc.net.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Validating with the Operations Schema Thread-Index: AcaGUqy6ogQLhoHEQQ636nQCMMSDBQ== From: "Hare, Michael" To: "Netconf Mailing List \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d This is a multi-part message in MIME format. ------_=_NextPart_001_01C68652.AC92D897 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Working through draft-ietf-netconf-prot-12 I find that the example XML = provided does not validate using the XSD provided in the same document. The main problem I have run into is the schema does not allow any = content within the , or nodes; the schema = defines these to be an empty set. I have made a few changes to the XSD to allow validation: For the original XSD definition is: By definition http://www.w3.org/TR/xmlschema-1/#key-efm, this resolves = to an empty set. By changing this to: I am able to add elements from my namespace as a payload for = which I believe is the desired results. The other changes are along the same lines. For the type definition: Also resolved to an empty set. I changed this to: and finally, the definition: Is also resolved to an empty set. I changed this to: with the added attribute: mixed=3D"true" to allow including XPath = expression when the 'type' attribute is set to 'xpath' Are these valid changes to the Base XSD, or am I missing something? Thanks, --------------------------------- Michael Hare NMI Engineering Fujitsu Network Communications GnuPG Key fingerprint =3D 1AD4 726D E359 A31D 05BF ACE5 CA93 7AD5 D8E3 = A876 ------_=_NextPart_001_01C68652.AC92D897 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Validating with the Operations Schema

Working through draft-ietf-netconf-prot-12 I find that the example XML provided does not validate = using the XSD provided in the same document.

The main problem I have run into is the = schema does not allow any content within the <config>, = <filter> or <data> nodes; the schema defines these to be an = empty set.

I have made a few changes to the XSD to = allow validation:

For <config> the original XSD = definition is:

        <xs:complexType = name=3D"configInlineType">
        =         <xs:complexContent>
        =         =         <xs:restriction = base=3D"xs:anyType"/>
        =         </xs:complexContent>
        </xs:complexType>

By definition http://www.w3.org/TR/x= mlschema-1/#key-efm, this resolves to an empty set.

By changing this to:

        <xs:complexType = name=3D"configInlineType">
        =         <xs:sequence>
        =         =         <xs:any namespace=3D"##other" = processContents=3D"lax"/>
        =         </xs:sequence>
        </xs:complexType>

I am able to add elements from my = namespace as a payload for <config> which I believe is the desired = results.

The other changes are along the same = lines.

For the <data> type = definition:

        <xs:complexType = name=3D"dataInlineType">
        =         <xs:complexContent>
        =         =         <xs:restriction = base=3D"xs:anyType"/>
        =         </xs:complexContent>
        </xs:complexType>

Also resolved to an empty set.
I changed this to:

        <xs:complexType = name=3D"dataInlineType">
        =         <xs:sequence>
        =         =         <xs:any namespace=3D"##other" = processContents=3D"lax"/>
        =         </xs:sequence>
        </xs:complexType>

and finally, the <filter> = definition:

        <xs:complexType = name=3D"filterInlineType">
        =         <xs:complexContent>
        =         =         <xs:restriction = base=3D"xs:anyType">
        =         =         =         <xs:attribute name=3D"type" = type=3D"FilterType" default=3D"subtree"/>
        =         =         </xs:restriction>
        =         </xs:complexContent>
        </xs:complexType>

Is also resolved to an empty = set.
I changed this to:

        <xs:complexType name=3D"filterInlineType" = mixed=3D"true">
        =         <xs:sequence>
        =         =         <xs:any namespace=3D"##other" = processContents=3D"lax" minOccurs=3D"0"/>
        =         </xs:sequence>
        =         <xs:attribute name=3D"type" = type=3D"FilterType" default=3D"subtree"/>
        </xs:complexType>

with the added attribute: mixed=3D"true" to allow including XPath expression when the 'type' = attribute is set to 'xpath'

Are these valid changes to the Base = XSD, or am I missing something?

Thanks,
---------------------------------
Michael Hare
NMI Engineering
Fujitsu Network Communications

GnuPG Key fingerprint =3D 1AD4 726D = E359 A31D 05BF  ACE5 CA93 7AD5 D8E3 A876


------_=_NextPart_001_01C68652.AC92D897-- -- to unsubscribe send a message to netconf-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 Jun 02 11:36:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBhD-0006hW-0k for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:36:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmBhB-0000na-NQ for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:36:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmBdo-000Fr4-Tr for netconf-data@psg.com; Fri, 02 Jun 2006 15:32: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.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 1FmBdo-000Fqr-3Y for netconf@ops.ietf.org; Fri, 02 Jun 2006 15:32:48 +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 k52FWkLS030793 for ; Fri, 2 Jun 2006 11:32:47 -0400 Received: (qmail 15687 invoked by uid 78); 2 Jun 2006 15:31:15 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 2 Jun 2006 15:31:15 -0000 Message-ID: <4480598D.6080605@andybierman.com> Date: Fri, 02 Jun 2006 08:30:21 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Canonical configuration database order 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: 97adf591118a232206bdb5a27b217034 Hi, This may be data-model specific, but maybe not. The SMI uses OIDs to name data, which implies a canonical order of all possible data (lexi-next in this case). A canonical order is useful for implementing a diff-config RPC. CLIs maintain an internal canonical order, even if the user enters instanced data in a different order (e.g., interface command). In XML you need to distinguish between multiple named instances (e.g., a key is defined) vs. multiple unnamed instances (e.g., maxOccurs > 1). The canonical order for named sibling instances is the natural sort order, based on the key associated with the nodes. For multiple unnamed instances, the ordinal position (0 to N-1) uniquely identifies each node within a set of sibling nodes. The canonical order of unnamed instances should not be changed from the PDU order. However, agent merge order of unnamed instances is data-model specific. Is this something of interest to the WG, or something that every vendor should (potentially) do differently? 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 Jun 02 11:42:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBnA-0008VR-Hw for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:42:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmBn9-0001bU-3M for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:42:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmBjU-000GTU-7e for netconf-data@psg.com; Fri, 02 Jun 2006 15:38:40 +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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmBjT-000GTJ-Aj for netconf@ops.ietf.org; Fri, 02 Jun 2006 15:38:39 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k52FcbbC003272 for ; Fri, 2 Jun 2006 11:38:37 -0400 Received: (qmail 17107 invoked by uid 78); 2 Jun 2006 15:03:06 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 2 Jun 2006 15:03:06 -0000 Message-ID: <448052F7.3060604@andybierman.com> Date: Fri, 02 Jun 2006 08:02:15 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Hare, Michael" CC: "Netconf Mailing List (E-mail)" Subject: Re: Validating with the Operations Schema References: <50B73C8966FCF840BABA099651DBE060011AB335@rchemx01.fnc.net.local> In-Reply-To: <50B73C8966FCF840BABA099651DBE060011AB335@rchemx01.fnc.net.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Hare, Michael wrote: > Working through draft-ietf-netconf-prot-12 I find that the example XML > provided does not validate using the XSD provided in the same document. > This was discussed in detail on the mailing list a few months ago. There is already an RFC-Editor note dealing with the filter XSD issue. This won't show up until the RFC is published. The Xpath filter was changed to avoid needing to allow mixed content in subtree filters. The xpath expression is now an attribute instead of element content: Andy > The main problem I have run into is the schema does not allow any > content within the , or nodes; the schema > defines these to be an empty set. > > I have made a few changes to the XSD to allow validation: > > For the original XSD definition is: > > > > > > > > By definition http://www.w3.org/TR/xmlschema-1/#key-efm, this resolves > to an empty set. > > By changing this to: > > > > > > > > I am able to add elements from my namespace as a payload for > which I believe is the desired results. > > The other changes are along the same lines. > > For the type definition: > > > > > > > > Also resolved to an empty set. > I changed this to: > > > > > > > > and finally, the definition: > > > > > type="FilterType" default="subtree"/> > > > > > Is also resolved to an empty set. > I changed this to: > > > > processContents="lax" minOccurs="0"/> > > default="subtree"/> > > > with the added attribute: mixed="true" to allow including XPath > expression when the 'type' attribute is set to 'xpath' > > Are these valid changes to the Base XSD, or am I missing something? > > Thanks, > --------------------------------- > Michael Hare > NMI Engineering > Fujitsu Network Communications > > GnuPG Key fingerprint = 1AD4 726D E359 A31D 05BF ACE5 CA93 7AD5 D8E3 A876 > > -- to unsubscribe send a message to netconf-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 Jun 02 11:45:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBqA-0003U4-4c for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:45:34 -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 1FmBUW-0007RR-Sr for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:23:12 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmBLC-0005yb-4q for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:13:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmBGm-000Dee-7P for netconf-data@psg.com; Fri, 02 Jun 2006 15:09: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.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 1FmBGk-000DeR-Rd for netconf@ops.ietf.org; Fri, 02 Jun 2006 15:08:59 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 945D74F002C for ; Fri, 2 Jun 2006 17:08:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 17:08:56 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 17:08:56 +0200 Message-ID: <44805488.5070300@ericsson.com> Date: Fri, 02 Jun 2006 17:08:56 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Underspecified CallHome Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 15:08:56.0964 (UTC) FILETIME=[78438C40:01C68656] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Hello, It was stated a number of times that call-home is underspecified. I would like to work on that a bit. Please could you make a short list of things you believe should be specified for call home! Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 11:49:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBte-0007mC-3x for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:49:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmBtc-00042R-Pw for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:49:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmBpw-000H9x-FL for netconf-data@psg.com; Fri, 02 Jun 2006 15:45: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.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [207.69.195.65] (helo=pop-scotia.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmBpu-000H9Z-MK for netconf@ops.ietf.org; Fri, 02 Jun 2006 15:45:19 +0000 Received: from h-68-166-189-153.snvacaid.dynamic.covad.net ([68.166.189.153] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FmBpt-0006ht-00 for netconf@ops.ietf.org; Fri, 02 Jun 2006 11:45:17 -0400 Message-ID: <002101c6865c$52975340$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf \(E-mail\)" References: <4480598D.6080605@andybierman.com> Subject: Re: Canonical configuration database order Date: Fri, 2 Jun 2006 08:50:47 -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 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - > From: "Andy Bierman" > To: "Netconf (E-mail)" > Sent: Friday, June 02, 2006 8:30 AM > Subject: Canonical configuration database order ... > The canonical order for named sibling instances is the natural sort order, > based on the key associated with the nodes. For multiple unnamed ... What is meant by "the natural sort order"? Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 11:51:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBvQ-00010W-Fm for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:51:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmBvP-00052B-6h for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 11:51:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmBsL-000HSC-Br for netconf-data@psg.com; Fri, 02 Jun 2006 15:47:49 +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 1FmBsK-000HRx-OA for netconf@ops.ietf.org; Fri, 02 Jun 2006 15:47:48 +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 k52FlcYE014531 for ; Fri, 2 Jun 2006 11:47:38 -0400 Received: (qmail 5794 invoked by uid 78); 2 Jun 2006 15:43:08 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 2 Jun 2006 15:43:08 -0000 Message-ID: <44805C53.6080903@andybierman.com> Date: Fri, 02 Jun 2006 08:42:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: Underspecified CallHome References: <44805488.5070300@ericsson.com> In-Reply-To: <44805488.5070300@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Balazs Lengyel wrote: > Hello, > It was stated a number of times that call-home is underspecified. I > would like to work on that a bit. > Please could you make a short list of things you believe should be > specified for call home! - data model to NV-configure an agent to call home - capability for callhome (fully specified capability template defined in prot-12, Appendix C) - agent needs to convey reason for connect when calling home (operations or notifications or ?) - NV-configure multiple (ordered) managers to call - callhome agent protocol procedures - callhome manager protocol procedures - manager fail-over procedure (agent reconnects to new manager) > Balazs Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 12:37:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCek-00043F-OE for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:37:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCej-0002OF-Es for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:37:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmCbO-000M9Q-Gy for netconf-data@psg.com; Fri, 02 Jun 2006 16:34:22 +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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmCbM-000M9E-NN for netconf@ops.ietf.org; Fri, 02 Jun 2006 16:34:20 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k52GYJQA031383 for ; Fri, 2 Jun 2006 12:34:19 -0400 Received: (qmail 3310 invoked by uid 78); 2 Jun 2006 16:34:04 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 2 Jun 2006 16:34:04 -0000 Message-ID: <4480683C.50606@andybierman.com> Date: Fri, 02 Jun 2006 09:33:00 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Randy Presuhn CC: "Netconf (E-mail)" Subject: Re: Canonical configuration database order References: <4480598D.6080605@andybierman.com> <002101c6865c$52975340$6501a8c0@oemcomputer> In-Reply-To: <002101c6865c$52975340$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: ea4ac80f790299f943f0a53be7e1a21a Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Netconf (E-mail)" >> Sent: Friday, June 02, 2006 8:30 AM >> Subject: Canonical configuration database order > ... >> The canonical order for named sibling instances is the natural sort order, >> based on the key associated with the nodes. For multiple unnamed > ... > > What is meant by "the natural sort order"? Ascending order for each component of the key. Keys are evaluated 'top to bottom', where the topmost component represents the major index, and each successive key component represents successive minor index components. > > 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 Fri Jun 02 12:38:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCeA-0003oT-Jf for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:37:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCTo-0007h1-Tx for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:26:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmCOA-000Ko4-Ih for netconf-data@psg.com; Fri, 02 Jun 2006 16:20:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.1 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmCO9-000Knq-TA for netconf@ops.ietf.org; Fri, 02 Jun 2006 16:20:41 +0000 Received: from rchemx01.fnc.net.local ([167.254.101.101]) by fncnmp04.fnc.fujitsu.com with ESMTP; 02 Jun 2006 11:20:41 -0500 X-IronPort-AV: i="4.05,204,1146459600"; d="scan'208"; a="26007748:sNHT27699064" 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Validating with the Operations Schema Date: Fri, 2 Jun 2006 11:20:40 -0500 Message-ID: <50B73C8966FCF840BABA099651DBE060011AB336@rchemx01.fnc.net.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Validating with the Operations Schema Thread-Index: AcaGWsU5MHHvGNsKQeyYSf0eWHHQEwAA3qMg From: "Hare, Michael" To: "Netconf Mailing List \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Ah, so..=20 That addresses the xpath filter issue, but not [really] the empty set = content issue for the config, data and filter nodes. I went back in the maillist archive and found the email discussion. The proposed solution in the archive was to simply skip the content = checking. Especially with the introduction of the proposed 'select' attribute for = the filter node, the=20 payload for these 3 elements are aligned and in a private namespace. Simply skipping the check is one method, but specifying elements to be = in a namespace other than the netconf namespace provides a bit more sanity checking to what = is actually being included for the payload. Anyway.. I look forward to the revised base XSD and to results from the upcoming = Notifications meeting as the current notification xsd has even worse = problems than the base schema. Thanx, - mike -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Friday, June 02, 2006 10:02 AM To: Hare, Michael Cc: Netconf Mailing List (E-mail) Subject: Re: Validating with the Operations Schema Hare, Michael wrote: > Working through draft-ietf-netconf-prot-12 I find that the example XML = > provided does not validate using the XSD provided in the same = document. >=20 This was discussed in detail on the mailing list a few months ago. There is already an RFC-Editor note dealing with the filter XSD issue. This won't show up until the RFC is published. The Xpath filter was changed to avoid needing to allow mixed content in subtree filters. The xpath expression is now an attribute instead of element content: Andy > The main problem I have run into is the schema does not allow any=20 > content within the , or nodes; the schema=20 > defines these to be an empty set. >=20 > I have made a few changes to the XSD to allow validation: >=20 > For the original XSD definition is: >=20 > > > > > >=20 > By definition http://www.w3.org/TR/xmlschema-1/#key-efm, this resolves = > to an empty set. >=20 > By changing this to: >=20 > > > > > >=20 > I am able to add elements from my namespace as a payload for =20 > which I believe is the desired results. >=20 > The other changes are along the same lines. >=20 > For the type definition: >=20 > > > > > >=20 > Also resolved to an empty set. > I changed this to: >=20 > > > > > >=20 > and finally, the definition: >=20 > > > > type=3D"FilterType" default=3D"subtree"/> > > > >=20 > Is also resolved to an empty set. > I changed this to: >=20 > > > processContents=3D"lax" minOccurs=3D"0"/> > > default=3D"subtree"/> > >=20 > with the added attribute: mixed=3D"true" to allow including XPath=20 > expression when the 'type' attribute is set to 'xpath' >=20 > Are these valid changes to the Base XSD, or am I missing something? >=20 > Thanks, > --------------------------------- > Michael Hare > NMI Engineering > Fujitsu Network Communications >=20 > GnuPG Key fingerprint =3D 1AD4 726D E359 A31D 05BF ACE5 CA93 7AD5 = D8E3 A876 >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 12:52:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCt1-00026a-4G for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:52:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCsz-0003gq-Q1 for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:52:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmCnP-000NPC-05 for netconf-data@psg.com; Fri, 02 Jun 2006 16:46: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.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [207.69.195.69] (helo=pop-savannah.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmCnM-000NOl-5N for netconf@ops.ietf.org; Fri, 02 Jun 2006 16:46:45 +0000 Received: from h-68-166-189-153.snvacaid.dynamic.covad.net ([68.166.189.153] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FmCnG-00005M-00 for netconf@ops.ietf.org; Fri, 02 Jun 2006 12:46:38 -0400 Message-ID: <000a01c68664$ea97b420$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf \(E-mail\)" References: <4480598D.6080605@andybierman.com> <002101c6865c$52975340$6501a8c0@oemcomputer> <4480683C.50606@andybierman.com> Subject: Re: Canonical configuration database order Date: Fri, 2 Jun 2006 09:52:19 -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 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: "Netconf (E-mail)" > Sent: Friday, June 02, 2006 9:33 AM > Subject: Re: Canonical configuration database order > > Randy Presuhn wrote: > > Hi - > > > >> From: "Andy Bierman" > >> To: "Netconf (E-mail)" > >> Sent: Friday, June 02, 2006 8:30 AM > >> Subject: Canonical configuration database order > > ... > >> The canonical order for named sibling instances is the natural sort order, > >> based on the key associated with the nodes. For multiple unnamed > > ... > > > > What is meant by "the natural sort order"? > > Ascending order for each component of the key. > Keys are evaluated 'top to bottom', where the > topmost component represents the major index, > and each successive key component represents > successive minor index components. ... Yes, but what is meant by "ascending order"? I'm wondering whether, for example, strings are canonicalized before comparison (e.g. is "A" plus "Umlaut" the same thing as "A-Umlaut"), whether locales matter (e.g. does "tra" come before or after "tuy"), and what happens with numbers (e.g. does 9.9 come before or after 999)? Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 13:12:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDC7-0003yW-3y for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 13:12:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmDC5-0005kX-QN for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 13:12:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmD8m-000Pa3-Q5 for netconf-data@psg.com; Fri, 02 Jun 2006 17:08:52 +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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmD8m-000PZq-57 for netconf@ops.ietf.org; Fri, 02 Jun 2006 17:08:52 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k52H8p7K005107 for ; Fri, 2 Jun 2006 13:08:51 -0400 Received: (qmail 5808 invoked by uid 78); 2 Jun 2006 17:08:51 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 2 Jun 2006 17:08:51 -0000 Message-ID: <4480705D.7070209@andybierman.com> Date: Fri, 02 Jun 2006 10:07:41 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Randy Presuhn CC: "Netconf (E-mail)" Subject: Re: Canonical configuration database order References: <4480598D.6080605@andybierman.com> <002101c6865c$52975340$6501a8c0@oemcomputer> <4480683C.50606@andybierman.com> <000a01c68664$ea97b420$6501a8c0@oemcomputer> In-Reply-To: <000a01c68664$ea97b420$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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: "Netconf (E-mail)" >> Sent: Friday, June 02, 2006 9:33 AM >> Subject: Re: Canonical configuration database order >> >> Randy Presuhn wrote: >>> Hi - >>> >>>> From: "Andy Bierman" >>>> To: "Netconf (E-mail)" >>>> Sent: Friday, June 02, 2006 8:30 AM >>>> Subject: Canonical configuration database order >>> ... >>>> The canonical order for named sibling instances is the natural sort order, >>>> based on the key associated with the nodes. For multiple unnamed >>> ... >>> >>> What is meant by "the natural sort order"? >> Ascending order for each component of the key. >> Keys are evaluated 'top to bottom', where the >> topmost component represents the major index, >> and each successive key component represents >> successive minor index components. > ... > > Yes, but what is meant by "ascending order"? > I'm wondering whether, for example, strings are > canonicalized before comparison (e.g. is "A" plus > "Umlaut" the same thing as "A-Umlaut"), whether > locales matter (e.g. does "tra" come before or > after "tuy"), and what happens with numbers > (e.g. does 9.9 come before or after 999)? I should have seen this coming, based on who asked the question ;-) Hopefully, there are rules in place for canonical representation and sort order of UTF-8 strings, including internationalization and localization details. I guess it is data type (and data modeling language) specific as to the exact meaning of ascending order. I compare numbers as numbers, not strings, so 9.9 is less than 999 and -4 is less than 2.1. Enumerations ascend in the order they are defined (aligns with SMIv2 and C), not alphabetic order of the enum values. > > 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 Fri Jun 02 13:27:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDQP-0004uv-9l for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 13:27:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmDQN-00066i-Tm for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 13:27:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmDLA-0000rb-TZ for netconf-data@psg.com; Fri, 02 Jun 2006 17:21:40 +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=BAYES_00 autolearn=ham version=3.1.1 Received: from [209.128.82.1] (helo=shell4.bayarea.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmDLA-0000rH-4O for netconf@ops.ietf.org; Fri, 02 Jun 2006 17:21:40 +0000 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k52HLU53002353; Fri, 2 Jun 2006 10:21:30 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k52HLISS002298; Fri, 2 Jun 2006 10:21:25 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 2 Jun 2006 10:21:18 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Andy Bierman cc: Randy Presuhn , "Netconf (E-mail)" Subject: Re: Canonical configuration database order In-Reply-To: <4480683C.50606@andybierman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 HI, Yes, and remember that the sort order for values is not just the order if the values were text strings, but the order is based on the type of the value. For example, sorting as text, string "10" preceeds string "2". But sorting as numbers, value "2" preceeds value "10". On Fri, 2 Jun 2006, Andy Bierman wrote: > Randy Presuhn wrote: > > Hi - > > > >> From: "Andy Bierman" > >> To: "Netconf (E-mail)" > >> Sent: Friday, June 02, 2006 8:30 AM > >> Subject: Canonical configuration database order > > ... > >> The canonical order for named sibling instances is the natural sort order, > >> based on the key associated with the nodes. For multiple unnamed > > ... > > > > What is meant by "the natural sort order"? > > Ascending order for each component of the key. > Keys are evaluated 'top to bottom', where the > topmost component represents the major index, > and each successive key component represents > successive minor index components. > > > > > Randy > > Andy > Regards, /david t. perkins -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 14:34:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmETR-000732-Ji for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 14:34:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmETQ-00051E-9j for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 14:34:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmEPY-00078x-GI for netconf-data@psg.com; Fri, 02 Jun 2006 18:30:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [207.69.195.69] (helo=pop-savannah.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmEPX-00078j-Ru for netconf@ops.ietf.org; Fri, 02 Jun 2006 18:30:15 +0000 Received: from h-68-166-189-153.snvacaid.dynamic.covad.net ([68.166.189.153] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FmEPX-0001iw-00 for netconf@ops.ietf.org; Fri, 02 Jun 2006 14:30:15 -0400 Message-ID: <000401c68673$63e5bf80$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf \(E-mail\)" References: <4480598D.6080605@andybierman.com> <002101c6865c$52975340$6501a8c0@oemcomputer> <4480683C.50606@andybierman.com> <000a01c68664$ea97b420$6501a8c0@oemcomputer> <4480705D.7070209@andybierman.com> Subject: Re: Canonical configuration database order Date: Fri, 2 Jun 2006 11:35:56 -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 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: "Netconf (E-mail)" > Sent: Friday, June 02, 2006 10:07 AM > Subject: Re: Canonical configuration database order ... > Hopefully, there are rules in place for canonical representation > and sort order of UTF-8 strings, including internationalization > and localization details. There are lots of rules available. We need to chose a set that can reasonably be implemented in a way that will ensure interoperability. I think that permitting localization to affect representation or ordering would be a recipe for disaster, since it would require any entity potentially needing to compare configuration data to be privy to the localization parameters used by whatever thing(s) generated the data. > I guess it is data type (and data modeling language) specific > as to the exact meaning of ascending order. I compare numbers > as numbers, not strings, so 9.9 is less than 999 and -4 is less > than 2.1. Enumerations ascend in the order they are defined > (aligns with SMIv2 and C), not alphabetic order of the enum values. ... A consequence of doing things this way is that data could be compared only by things with full knowledge of the schema. That's not necessary in the case of SNMP, and is quite useful. This may be a bug or a feature, but we should be aware of the implications for, for example, configuration management systems that, in trying to identify changes in configuration, will need to know which differences in representation are significant and which are not. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 15:25:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFH8-0002js-T1 for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 15:25:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFH7-00019B-BQ for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 15:25:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmFDg-000BoO-NK for netconf-data@psg.com; Fri, 02 Jun 2006 19:22:04 +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=BAYES_00 autolearn=ham version=3.1.1 Received: from [63.240.1.44] (helo=relay3.nyc2.attens.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fm6Cp-000A1u-4O for netconf@ops.ietf.org; Fri, 02 Jun 2006 09:44:35 +0000 Received: from mailhub.masconit.com (email.masconit.com [12.107.104.100]) by relay3.nyc2.attens.net (8.13.6/8.13.6) with ESMTP id k529iXR0013641; Fri, 2 Jun 2006 09:44:33 GMT Received: by MAILHUB with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Jun 2006 04:44:33 -0500 Received: from POOJA ([172.16.15.43]) by mailhub.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K5PD9HBG; Fri, 2 Jun 2006 04:44:28 -0500 From: Pooja Malhotra To: Andy Bierman Cc: netconf@ops.ietf.org Subject: RE: SOAP/HTTP over SSH Date: Fri, 2 Jun 2006 15:09:44 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <447F2061.5080105@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Thanks Andy.. I really appreciate ur help. But again..as the draft says that SSH is an mandatory transport protocol , Can we implement SOAP over HTTPS (as transport Protocol) and still be netconf compliant. Regards, Pooja -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Thursday, June 01, 2006 10:44 PM To: Pooja Malhotra Cc: netconf@ops.ietf.org Subject: Re: SOAP/HTTP over SSH Pooja Malhotra wrote: > Hi... > > We are planning to implement NetConf.And I am very new to this standard. > In this effort I went thro' the initial draft > "NETCONF Configuration Protocol draft-ietf-netconf-prot-12" proposed by > IETF. > After going through it , I understood the architecture > as shown below in the figure: You have misunderstood the document. The RPC layer is 'SOAP over HTTP'. The transport protocol SOAP over HTTPS (HTTP over TLS) is supported. You would use this instead of SSH. Andy > > > Layer Example > +-------------+ +-----------------------------+ > (4) | Content | | Configuration data | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (3) | Operations | | NETCONF operation | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (2) | RPC | | SOAP over HTTP | > +-------------+ +-----------------------------+ > | | > +-------------+ +-----------------------------+ > (1) | Transport | | SSH | > | Protocol | | | > +-------------+ +-----------------------------+ > > As you can see, our proposed solution indicated that the SSH would > be used as Transport Protocol.This choice was made because it > is mentioned in section 2.4.(Mandatory Transport Protocol ) > that SSH is mandatory for NetConf. Now we > are stuck with the RPC layer protocol. Intially we thought of > SOAP over HTTP (as RPC layer implementation), But if this the case, > we fail to understand how the SSH layer will communicate with > the RPC layer. > How the SSH layer will interact with the RPC layer over HTTP as it is not > secure. > > Also,once the SSH session is opened between the remote machine, > how can we ensure that the data transfer is secured through SOAP/HTTP? > > What is the nature of the SSH connection?Is it socket connection like SSL? > > We tried implementing SSH using opensource Library from JSch > (for client)and OpenSSH (for SSH Server). > Other tool we tried was Corkscrew(tool for tunneling SSH > through HTTP proxies.) > > Also Is it mandatory to implement SSH.Instead can we use SOAP > over HTTPS. > > I would be highly obliged if you could please throw some light on > the queries I have and tell us some tools which can help us in > implementation. > > > Thanks, > > Pooja Malhotra > Senior Software Engineer, > MASCON Global ltd. > Bangalore > Karnatka (India) > > > > > > -- > to 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 Jun 02 16:08:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFwj-0004Nn-MA for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:08:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFwi-0006vr-Cb for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:08:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmFto-000GB2-7T for netconf-data@psg.com; Fri, 02 Jun 2006 20:05: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.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [207.69.195.65] (helo=pop-scotia.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmFtn-000GAm-Jp for netconf@ops.ietf.org; Fri, 02 Jun 2006 20:05:35 +0000 Received: from h-68-166-189-153.snvacaid.dynamic.covad.net ([68.166.189.153] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FmFtm-0004cv-00 for netconf@ops.ietf.org; Fri, 02 Jun 2006 16:05:34 -0400 Message-ID: <006801c68680$b5b4d1e0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf \(E-mail\)" References: <4475D753.4050206@ericsson.com> <44772D30.8010302@andybierman.com> <447AB1F9.8060205@ericsson.com> Subject: Re: Event classes Date: Fri, 2 Jun 2006 13:11:18 -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 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - > From: "Balazs Lengyel" > To: "Andy Bierman" > Cc: "Netconf (E-mail)" > Sent: Monday, May 29, 2006 1:34 AM > Subject: Re: Event classes ... > State is a good choice but there is a more general issue hidden here. > > State events can also represent a fault. E.g. For threshold-crossing: memory-usage more > then 20% is just a state event. Memory usage more then 99.9% is a critical fault/alarm as > at this point we can easily have a crash. Where do we put such events? Shall we > - allow such events to jump from state to fault depending on the seriousness of the situation > - allow some notifications to belong to more then one event class > - leave it to the application developer ... I think that syntactic needs, rather than semantic distinctions, will be most useful in characterizing event classes at the level of a data model. Decisions about "seriousness" are in the eye of the beholder, and may depend on the context in which they occur. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 16:45:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGWY-000591-NC for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:45:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGWW-0004ME-Vd for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:45:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmGT9-000JvC-Op for netconf-data@psg.com; Fri, 02 Jun 2006 20:42: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.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 1FmGT7-000Jux-UJ for netconf@ops.ietf.org; Fri, 02 Jun 2006 20:42:06 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 015FF55EF9; Fri, 2 Jun 2006 22:42:05 +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 05911-05; Fri, 2 Jun 2006 22:42:03 +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 0DEC455EF8; Fri, 2 Jun 2006 22:42:03 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id C9A2373F471; Fri, 2 Jun 2006 22:42:01 +0200 (CEST) Date: Fri, 2 Jun 2006 22:42:01 +0200 From: Juergen Schoenwaelder To: Phil Shafer Cc: Andy Bierman , Balazs Lengyel , "Netconf (E-mail)" Subject: Re: Underspecified CallHome Message-ID: <20060602204201.GA17337@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Phil Shafer , Andy Bierman , Balazs Lengyel , "Netconf (E-mail)" References: <44805C53.6080903@andybierman.com> <200606022029.k52KTmPd009390@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606022029.k52KTmPd009390@idle.juniper.net> 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: ea4ac80f790299f943f0a53be7e1a21a On Fri, Jun 02, 2006 at 04:29:48PM -0400, Phil Shafer wrote: > BEEP handles the device-initiated connection easily, and one can > use 'sshd -i' on the device side to pass a device-initiated connection > into the ssh daemon code, allowing us to preserve the existing > client/server relationship in netconf. I'm clueless about how soap > would handle this. While I love the simplicity of this approach (agent establishes the TCP connection and once established it takes over the SSH server role), I had the feeling that security folks seriously disliked it during the ISMS discussions. Instead, they seemed to prefer something where you have to use host-key authentication and you end up with different notions of access control rules since you have different authenticated identities to deal with. I like to see a common approach to deal with "agent" initiated connections between netconf and ISMS and as I said I love the simplicity of what you propose for netconf... /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 Fri Jun 02 18:09:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHpN-0003Zd-AF for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 18:09:09 -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 1FmGQm-0002ck-IP for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:39:40 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmFzx-0002jh-8D for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:11:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmFxK-000GYD-DX for netconf-data@psg.com; Fri, 02 Jun 2006 20:09:14 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmFxJ-000GY2-Lk for netconf@ops.ietf.org; Fri, 02 Jun 2006 20:09:13 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k52K96X47806; Fri, 2 Jun 2006 13:09:06 -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 k52K91533072; Fri, 2 Jun 2006 13:09:01 -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 k52KTmPd009390; Fri, 2 Jun 2006 16:29:48 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606022029.k52KTmPd009390@idle.juniper.net> To: Andy Bierman cc: Balazs Lengyel , "Netconf (E-mail)" Subject: Re: Underspecified CallHome In-Reply-To: Your message of "Fri, 02 Jun 2006 08:42:11 PDT." <44805C53.6080903@andybierman.com> Date: Fri, 02 Jun 2006 16:29:48 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Andy Bierman writes: > - data model to NV-configure an agent to call home The config needed to get a device to call home is might well be device specific. > - callhome agent protocol procedures > - callhome manager protocol procedures The big job here is getting the protocol mappings for reverse direction connections, and having a mechanism to uniquely identify the device to the app. BEEP handles the device-initiated connection easily, and one can use 'sshd -i' on the device side to pass a device-initiated connection into the ssh daemon code, allowing us to preserve the existing client/server relationship in netconf. I'm clueless about how soap would handle this. As far as device identification, the device's ssh host-key (or its fingerprint?) should suffice. > - agent needs to convey reason for connect when calling home > (operations or notifications or ?) For this, I was imagining a specific log, where the newly connected manager could do a simple RPC saying "Who dares to disturb the great and powerful Oz?" The reply would be a list of recent reasons the device has called home, which the manager can inspect to find both the current reason (the last one on the list) and the past reasons (to see if any were lost). Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 18:19:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHzW-0001OH-35 for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 18:19:38 -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 1FmGQi-0002dX-6e for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:39:36 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmG90-0002qT-0I for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:21:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmG5f-000HZ4-I6 for netconf-data@psg.com; Fri, 02 Jun 2006 20:17:51 +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 1FmG5f-000HYo-34 for netconf@ops.ietf.org; Fri, 02 Jun 2006 20:17:51 +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 k52KHn1Z029702; Fri, 2 Jun 2006 13:17:49 -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 k52KHm535983; Fri, 2 Jun 2006 13:17:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k52KccPd009446; Fri, 2 Jun 2006 16:38:38 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606022038.k52KccPd009446@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: Canonical configuration database order In-Reply-To: Your message of "Fri, 02 Jun 2006 08:30:21 PDT." <4480598D.6080605@andybierman.com> Date: Fri, 02 Jun 2006 16:38:38 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Andy Bierman writes: >The canonical order for named sibling instances is the natural sort order, >based on the key associated with the nodes. FWIW, JUNOS has both auto-sorted and user-sorted lists. For example, the terms of an import policy are named by the user and ordered by the user, since the order matters. But for interface definitions, the order doesn't matter, so we sort them automatically. Both have keys (term name and interface name), to allow users to refer to them. The term name for policies is not important to the routing code, which simply applies the terms in the order they appear in the configuration, but is necessary to allow users to do stuff like: edit policy foo term goo copy term goo to term zoo delete term goo insert term goo before term moo Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 02 18:31:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmIBE-00048o-Mp for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 18:31:44 -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 1FmGQl-0002dn-Au for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:39:39 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmG42-0002nm-Jp for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 16:16:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmG1U-000H62-Je for netconf-data@psg.com; Fri, 02 Jun 2006 20:13:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO,RCVD_NUMERIC_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmG1T-000H5n-NH for netconf@ops.ietf.org; Fri, 02 Jun 2006 20:13:31 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2006 13:13:31 -0700 X-IronPort-AV: i="4.05,204,1146466800"; d="scan'208"; a="288037992:sNHT34371782" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k52KDVYn009735; Fri, 2 Jun 2006 13:13:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k52KDVCU013786; Fri, 2 Jun 2006 13:13:31 -0700 (PDT) Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 13:13:31 -0700 Received: from 171.69.71.225 ([171.69.71.225]) by xmb-sjc-217.amer.cisco.com ([171.70.151.175]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Jun 2006 20:13:30 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 02 Jun 2006 13:13:30 -0700 Subject: Re: Underspecified CallHome From: Steve Berl To: Phil Shafer , Andy Bierman CC: Balazs Lengyel , "Netconf (E-mail)" Message-ID: Thread-Topic: Underspecified CallHome Thread-Index: AcaGgQPXQj9lHvJ0EdqmmgARJNUQLA== In-Reply-To: <200606022029.k52KTmPd009390@idle.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 20:13:31.0118 (UTC) FILETIME=[048228E0:01C68681] DKIM-Signature: a=rsa-sha1; q=dns; l=1847; t=1149279211; x=1150143211; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=sberl@cisco.com; z=From:Steve=20Berl=20 |Subject:Re=3A=20Underspecified=20CallHome=20; X=v=3Dcisco.com=3B=20h=3DJEVhuEOr7r5pXHH6tAztQePv8ig=3D; b=ZDFNPrHDeG8t3/jIsOKN/j8ovhG/rI4SfszNeawSrsKAYgkYmbc8h8PlzrP4zcK0M/mTiti0 lrZCCBOHqSDiOY+Qc0H+23eVo+odHEc2MAzwnrNG3zNsS+K+FfEaWLZ9; Authentication-Results: sj-dkim-1.cisco.com; header.From=sberl@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -1.4 (-) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On 6/2/06 1:29 PM, "Phil Shafer" wrote: > Andy Bierman writes: >> - data model to NV-configure an agent to call home > > The config needed to get a device to call home is might > well be device specific. > >> - callhome agent protocol procedures >> - callhome manager protocol procedures > > The big job here is getting the protocol mappings for reverse > direction connections, and having a mechanism to uniquely identify > the device to the app. > > BEEP handles the device-initiated connection easily, and one can > use 'sshd -i' on the device side to pass a device-initiated connection > into the ssh daemon code, allowing us to preserve the existing > client/server relationship in netconf. I'm clueless about how soap > would handle this. DSL Forum TR-069 has this already. It be valuable to steal from there. > > As far as device identification, the device's ssh host-key (or its > fingerprint?) should suffice. > >> - agent needs to convey reason for connect when calling home >> (operations or notifications or ?) > > For this, I was imagining a specific log, where the newly connected > manager could do a simple RPC saying "Who dares to disturb the great > and powerful Oz?" The reply would be a list of recent reasons the > device has called home, which the manager can inspect to find both > the current reason (the last one on the list) and the past reasons > (to see if any were lost). Again, TR-069 specifies that the first message that the device sends is an Inform, which includes the reason for the call. -steve > > 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: -- to unsubscribe send a message to netconf-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 Jun 02 23:40:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmMzh-0007rM-7O for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 23:40:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmMzd-0003jZ-FZ for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 23:40:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmMty-0004Kn-So for netconf-data@psg.com; Sat, 03 Jun 2006 03:34:14 +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 1FmMtx-0004KZ-RQ for netconf@ops.ietf.org; Sat, 03 Jun 2006 03:34:14 +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 k533YDBu027619 for ; Fri, 2 Jun 2006 23:34:13 -0400 Received: (qmail 1651 invoked by uid 78); 3 Jun 2006 03:34:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 3 Jun 2006 03:34:13 -0000 Message-ID: <448102B3.1000603@andybierman.com> Date: Fri, 02 Jun 2006 20:32:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: "Netconf (E-mail)" Subject: Re: Canonical configuration database order References: <200606022038.k52KccPd009446@idle.juniper.net> In-Reply-To: <200606022038.k52KccPd009446@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Phil Shafer wrote: > Andy Bierman writes: >> The canonical order for named sibling instances is the natural sort order, >> based on the key associated with the nodes. > > FWIW, JUNOS has both auto-sorted and user-sorted lists. For example, > the terms of an import policy are named by the user and ordered by > the user, since the order matters. But for interface definitions, > the order doesn't matter, so we sort them automatically. Both have > keys (term name and interface name), to allow users to refer to > them. The term name for policies is not important to the routing > code, which simply applies the terms in the order they appear in > the configuration, but is necessary to allow users to do stuff like: > > edit policy foo term goo > copy term goo to term zoo > delete term goo > insert term goo before term moo > Your user-sorted list is a position-dependent (unnamed) list. For automation purposes, I always leave the order unchanged. Presumably, these CLI commands can be NV-stored, so they will appear in a specific place in the config. Now consider a 'merge' operation. There is no deterministic algorithm you can use to reliably automate the merge operation for unnamed instances. (That's one area where data-model callbacks are difficult to eliminate.) In some data models concatenation may be the algorithm, but it doesn't have to be. In your example, if I merged these commands with an identical existing set by concatenation, the result would be syntactically correct, but operational garbage. > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 03 01:38:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmOqR-0000l1-KU for netconf-archive@lists.ietf.org; Sat, 03 Jun 2006 01:38:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmOqP-0006Ch-8C for netconf-archive@lists.ietf.org; Sat, 03 Jun 2006 01:38:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmOml-000Euu-FC for netconf-data@psg.com; Sat, 03 Jun 2006 05:34:55 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmOmi-000Euh-IS for netconf@ops.ietf.org; Sat, 03 Jun 2006 05:34:52 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k535YpKf020796 for ; Sat, 3 Jun 2006 01:34:51 -0400 Received: (qmail 4460 invoked by uid 78); 3 Jun 2006 05:34:51 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 3 Jun 2006 05:34:51 -0000 Message-ID: <44811EFA.9040702@andybierman.com> Date: Fri, 02 Jun 2006 22:32:42 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer , Andy Bierman , Balazs Lengyel , "Netconf (E-mail)" Subject: Re: Underspecified CallHome References: <44805C53.6080903@andybierman.com> <200606022029.k52KTmPd009390@idle.juniper.net> <20060602204201.GA17337@boskop.local> In-Reply-To: <20060602204201.GA17337@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Juergen Schoenwaelder wrote: > On Fri, Jun 02, 2006 at 04:29:48PM -0400, Phil Shafer wrote: > >> BEEP handles the device-initiated connection easily, and one can >> use 'sshd -i' on the device side to pass a device-initiated connection >> into the ssh daemon code, allowing us to preserve the existing >> client/server relationship in netconf. I'm clueless about how soap >> would handle this. > > While I love the simplicity of this approach (agent establishes the > TCP connection and once established it takes over the SSH server > role), I had the feeling that security folks seriously disliked it > during the ISMS discussions. Instead, they seemed to prefer something > where you have to use host-key authentication and you end up with > different notions of access control rules since you have different > authenticated identities to deal with. > > I like to see a common approach to deal with "agent" initiated > connections between netconf and ISMS and as I said I love the > simplicity of what you propose for netconf... Yes. Ditto for endless-RPC. One more and I guess you win a prize :-) Since I'm an embedded C programmer, I have a permanent bias towards simplicity. The art of engineering is keeping the inherent complexity as low as possible (which is like entropy; once introduced, it can never be removed from the system ;-) (I will refrain from ranting on IETF security protocol usage and documentation requirements. Not simple.) > > /js > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 03 12:14:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYlb-0006f3-5P for netconf-archive@lists.ietf.org; Sat, 03 Jun 2006 12:14:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmYlY-0001YP-KH for netconf-archive@lists.ietf.org; Sat, 03 Jun 2006 12:14:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmYg6-000MHG-Mc for netconf-data@psg.com; Sat, 03 Jun 2006 16:08:42 +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 1FmYg4-000MGw-Cb for netconf@ops.ietf.org; Sat, 03 Jun 2006 16:08:40 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id C20A31E14F7; Sat, 3 Jun 2006 09:08:37 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 3 Jun 2006 09:08:37 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE30@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Andy Bierman' , Randy Presuhn Cc: "Netconf (E-mail)" Subject: RE: Canonical configuration database order Date: Sat, 3 Jun 2006 09:08:31 -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: 5ebbf074524e58e662bc8209a6235027 Hi, W3C XML Schema Part 2 (datatypes) explicitly chooses NOT to define an 'order-relation' for 'xsd:string'. But for real-world use of XML documents, sorting of strings should be locale-sensitive - or it produces nonsense results - even a straight codepoint value sort of UTF-8 may produce garbage in English, if you don't first normalize the UTF-8. The best IETF document on this topic is Stringprep (RFC 3454). The W3C I18N Core WG is working on "LTLI" (Language Tags and Locale Identifiers) to address the impact of language tags (e.g., xml:lang) on W3C technologies (including XML itself). 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: Friday, June 02, 2006 1:08 PM > To: Randy Presuhn > Cc: Netconf (E-mail) > Subject: Re: Canonical configuration database order > > > Randy Presuhn wrote: > > Hi - > > > >> From: "Andy Bierman" > >> To: "Randy Presuhn" > >> Cc: "Netconf (E-mail)" > >> Sent: Friday, June 02, 2006 9:33 AM > >> Subject: Re: Canonical configuration database order > >> > >> Randy Presuhn wrote: > >>> Hi - > >>> > >>>> From: "Andy Bierman" > >>>> To: "Netconf (E-mail)" > >>>> Sent: Friday, June 02, 2006 8:30 AM > >>>> Subject: Canonical configuration database order > >>> ... > >>>> The canonical order for named sibling instances is the > natural sort order, > >>>> based on the key associated with the nodes. For multiple unnamed > >>> ... > >>> > >>> What is meant by "the natural sort order"? > >> Ascending order for each component of the key. > >> Keys are evaluated 'top to bottom', where the > >> topmost component represents the major index, > >> and each successive key component represents > >> successive minor index components. > > ... > > > > Yes, but what is meant by "ascending order"? > > I'm wondering whether, for example, strings are > > canonicalized before comparison (e.g. is "A" plus > > "Umlaut" the same thing as "A-Umlaut"), whether > > locales matter (e.g. does "tra" come before or > > after "tuy"), and what happens with numbers > > (e.g. does 9.9 come before or after 999)? > > I should have seen this coming, based on who asked the question ;-) > Hopefully, there are rules in place for canonical representation > and sort order of UTF-8 strings, including internationalization > and localization details. > > I guess it is data type (and data modeling language) specific > as to the exact meaning of ascending order. I compare numbers > as numbers, not strings, so 9.9 is less than 999 and -4 is less > than 2.1. Enumerations ascend in the order they are defined > (aligns with SMIv2 and C), not alphabetic order of the enum values. > > > > > 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: > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.8.1/355 - Release > Date: 6/2/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 6/2/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 Sat Jun 03 12:32:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmZ2m-0008U5-VO for netconf-archive@lists.ietf.org; Sat, 03 Jun 2006 12:32:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmZ2l-00030E-A4 for netconf-archive@lists.ietf.org; Sat, 03 Jun 2006 12:32:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmYza-000No6-51 for netconf-data@psg.com; Sat, 03 Jun 2006 16:28:50 +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 1FmYzZ-000Nnu-AK for netconf@ops.ietf.org; Sat, 03 Jun 2006 16:28:49 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id D2C3F1E14AE; Sat, 3 Jun 2006 09:28:48 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 3 Jun 2006 09:28:48 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE31@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Randy Presuhn' , "Netconf (E-mail)" Subject: RE: Event classes Date: Sat, 3 Jun 2006 09:28:44 -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: 386e0819b1192672467565a524848168 Hi, It's important to separate atomic event names from their associated event metadata (e.g., severity of informational, warning, critical) - one event, multiple contexts. FWIW, the Printer MIB (RFC 1759/3805) defined 'prtAlertCode' (of type 'PrtAlertCodeTC') with the following event metadata: prtAlertSeverityLevel PrtAlertSeverityLevelTC, prtAlertTrainingLevel PrtAlertTrainingLevelTC, prtAlertGroup PrtAlertGroupTC, prtAlertGroupIndex Integer32, prtAlertLocation Integer32, prtAlertDescription PrtLocalizedDescriptionStringTC, prtAlertTime TimeTicks 'prtAlertTrainingLevel' describes the necessary training to handle the event (fieldService, trained, untrained, etc.). 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 Randy Presuhn > Sent: Friday, June 02, 2006 4:11 PM > To: Netconf (E-mail) > Subject: Re: Event classes > > > Hi - > > > From: "Balazs Lengyel" > > To: "Andy Bierman" > > Cc: "Netconf (E-mail)" > > Sent: Monday, May 29, 2006 1:34 AM > > Subject: Re: Event classes > ... > > State is a good choice but there is a more general issue > hidden here. > > > > State events can also represent a fault. E.g. For > threshold-crossing: memory-usage more > > then 20% is just a state event. Memory usage more then > 99.9% is a critical fault/alarm as > > at this point we can easily have a crash. Where do we put > such events? Shall we > > - allow such events to jump from state to fault depending > on the seriousness of the situation > > - allow some notifications to belong to more then one event class > > - leave it to the application developer > ... > > I think that syntactic needs, rather than semantic distinctions, > will be most useful in characterizing event classes at the level > of a data model. Decisions about "seriousness" are in the > eye of the beholder, and may depend on the context in which > they occur. > > 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: > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.8.1/355 - Release > Date: 6/2/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 6/2/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 Mon Jun 05 14:43:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnK3I-0001sj-Rh for netconf-archive@lists.ietf.org; Mon, 05 Jun 2006 14:43:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnK3H-0008Eh-D9 for netconf-archive@lists.ietf.org; Mon, 05 Jun 2006 14:43:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnJxW-000ByS-2o for netconf-data@psg.com; Mon, 05 Jun 2006 18:37:50 +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 1FnJxT-000ByC-Lu for netconf@ops.ietf.org; Mon, 05 Jun 2006 18:37:48 +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 k55IbgfI019993 for ; Mon, 5 Jun 2006 14:37:47 -0400 Received: (qmail 7817 invoked by uid 78); 5 Jun 2006 18:37:42 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 5 Jun 2006 18:37:42 -0000 Message-ID: <448479F5.8060905@andybierman.com> Date: Mon, 05 Jun 2006 11:37:41 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: edit-config test-option clarification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi, prot-12:pg 38, middle: test-option: The test-option element may be specified only if the device advertises the :validate capability (Section 8.6). The test-option element has one of the following values: test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the operation. This is the default test-option. set: Perform a set without a validation test first. IMO, the last sentence regarding 'set' mode is misleading. The terminology is intentionally vague because the WG could not agree on exactly what 'validation' meant. It should be understood that a conforming agent implementation MUST NOT use parameters passed in RPCs as-is without any checking, even if the :validate capability is implemented and the 'set' option is selected by the manager. (Or the hacker ;-) The 'set' value of the 'test-option' does not indicate that the agent should use schema-invalid values, or invalid values of any kind. Instead, it means: "An agent MUST NOT not complete all implementation-specific referential integrity, or other validation checks, in addition to schema-validation checks, before applying any changes to the target. An agent MUST apply a valid sub-operation within the edit-config operation without first completing a full validation test of the entire edit-config PDU." Is there anyone who thinks the 'set' option should mean otherwise? IMO (and I can say this because I was there when it was written ;-), this 'test-option' is the lamest thing I've ever put in a standard. It is an extremely implementation-specific detail at best, especially when rollback-on-error is also selected. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 06 14:51:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngeC-0003xU-EP for netconf-archive@lists.ietf.org; Tue, 06 Jun 2006 14:51:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngeA-0006Ub-3r for netconf-archive@lists.ietf.org; Tue, 06 Jun 2006 14:51:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FngYX-000Gkv-G0 for netconf-data@psg.com; Tue, 06 Jun 2006 18:45:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FngYW-000Gkj-RW for netconf@ops.ietf.org; Tue, 06 Jun 2006 18:45:32 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 06 Jun 2006 11:45:13 -0700 X-IronPort-AV: i="4.05,213,1146466800"; d="scan'208"; a="552280703:sNHT55389155354" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 11:44:52 -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: Underspecified CallHome Date: Tue, 6 Jun 2006 11:44:38 -0700 Message-ID: In-Reply-To: <200606022029.k52KTmPd009390@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Underspecified CallHome Thread-Index: AcaGgH22eeiRHlEpTwWkL7TD2Uy9SADFMr0w From: "Kent Watsen" To: "Phil Shafer" , "Andy Bierman" Cc: "Balazs Lengyel" , "Netconf \(E-mail\)" X-OriginalArrivalTime: 06 Jun 2006 18:44:52.0291 (UTC) FILETIME=[4BE49130:01C68999] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 >> - data model to NV-configure an agent to call home > >The config needed to get a device to call home is might >well be device specific. At first I was hopeful that a standard agent-configuration model could be imposed on all devices, but than realized that devices have wildly different approaches towards how they enable services on interfaces. However, it might make sense to standardize a "virtual agent-configuration" - that is, a top-level node using the netconf-namespace that if read-from or written-to would trigger the device to adapt to/from its internal model. My assumption is would not return this virtual-configuration without a filter, but it would return the device-specific configuration for the same.=20 > As far as device identification, the device's ssh host-key (or its > fingerprint?) should suffice. This only works if there is a chance to float the host-key beforehand, which isn't possible when the customer receives the equipment directly from manufacturing and uses an NMS-supplied script to bootstrap its call home. A resolution to this is to also configure the agent with NMS-supplied ID/OTP (one-time password). Thus, immediately after the agent-initiated TCP session is established and before passing the connection to `sshd -i`, the device can send a TCP message containing its ID, host-key, and the HMAC of its host-key using the OTP. The NMS can use the ID to do a database lookup for the device's record, which should contain the same OTP, which it can use to authenticate the host-key. Then the NMS can initiate an SSH-client on top of the already-established TCP session and authenticate itself to the device (i.e. login) at which time the device can clear the OTP from its configuration. Kent -- to unsubscribe send a message to netconf-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 Jun 07 10:59:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzV8-0005Wy-Ga for netconf-archive@lists.ietf.org; Wed, 07 Jun 2006 10:59:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzJN-0002zR-DQ for netconf-archive@lists.ietf.org; Wed, 07 Jun 2006 10:47:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnzDI-000DhG-Md for netconf-data@psg.com; Wed, 07 Jun 2006 14:40:52 +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 1FnzDF-000Dgq-8s for netconf@ops.ietf.org; Wed, 07 Jun 2006 14:40:49 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 075924F0069; Wed, 7 Jun 2006 16:40:43 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 16:40:42 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 16:40:42 +0200 Message-ID: <4486E569.2000500@ericsson.com> Date: Wed, 07 Jun 2006 16:40:41 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" , Andy Bierman Subject: Session reuse Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 14:40:42.0203 (UTC) FILETIME=[5A2C4AB0:01C68A40] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Hello Andy, As I remember you mentioned you hoped to reach consensus on session reuse before the IETF meeting. Could you summarize how you see the state of consensus? Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 07 11:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0BP-0004Yx-PH for netconf-archive@lists.ietf.org; Wed, 07 Jun 2006 11:42:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0BO-0000P4-E1 for netconf-archive@lists.ietf.org; Wed, 07 Jun 2006 11:42:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fo06p-000JhH-Ug for netconf-data@psg.com; Wed, 07 Jun 2006 15:38:15 +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 1Fo06o-000Jh3-Ur for netconf@ops.ietf.org; Wed, 07 Jun 2006 15:38:15 +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 k57FcERY016136 for ; Wed, 7 Jun 2006 11:38:14 -0400 Received: (qmail 10232 invoked by uid 78); 7 Jun 2006 15:38:14 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 7 Jun 2006 15:38:14 -0000 Message-ID: <4486F2DF.7090104@andybierman.com> Date: Wed, 07 Jun 2006 08:38:07 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: Session reuse References: <4486E569.2000500@ericsson.com> In-Reply-To: <4486E569.2000500@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: bb8f917bb6b8da28fc948aeffb74aa17 Balazs Lengyel wrote: > Hello Andy, > As I remember you mentioned you hoped to reach consensus on session > reuse before the IETF meeting. Could you summarize how you see the state > of consensus? I wrote: I was hoping we could finish up event classes before the meeting. The other issue that seems to be finishing up is the use of existing configuration RPCs instead of new subscription RPCs for conveying notification generation parameters. Not session reuse. RPC reuse. I think there is WG consensus that notification generation parameters need to be capable of being NV-stored, and that existing RPCs for manipulating configuration data must be used for this purpose. There have also been multiple objections to having overlapping subscription and configuration based mechanisms, so IMO there is also WG consensus to limit any new RPCs to new features which do not duplicate existing RPCs. > Balazs > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 08 11:05:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoM4u-0006M2-Ej for netconf-archive@lists.ietf.org; Thu, 08 Jun 2006 11:05:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoM4r-0005Gq-Vh for netconf-archive@lists.ietf.org; Thu, 08 Jun 2006 11:05:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FoLum-000KTo-Im for netconf-data@psg.com; Thu, 08 Jun 2006 14:55:16 +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 autolearn=ham version=3.1.1 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FoLuh-000KTT-0M for netconf@ops.ietf.org; Thu, 08 Jun 2006 14:55:15 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k58Et96Q026409 for ; Thu, 8 Jun 2006 09:55:09 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jun 2006 16:55:08 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A338495@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: [members] Public Review of WSN (Web Services Notification) Date: Thu, 8 Jun 2006 16:55:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e FYI, since it is about notifications, I thought I'd at least make sure you all know about this. Bert -----Original Message----- From: Mary McRae [mailto:mary.mcrae@oasis-open.org] Sent: Thursday, June 08, 2006 16:41 To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org Cc: wsn@lists.oasis-open.org Subject: [members] Public Review of WSN TO: OASIS Members, public announce lists The OASIS Web Services Notification TC recently has approved the following specifications as Committee Drafts and approved the package for public review. WS-BaseNotification, public review draft 3 dated 31 May 2006 WS-BrokeredNotification, public review draft 3 dated 31 May 2006 WS-Topics, public review draft 2 dated 31 May 2006 The public review starts today, 8 June 2006, and ends 23 June 2006. This is a third review of the WS-BaseNotification and WS-BrokeredNotification specifications and the second review of WS-Topics. Announcements of previous reviews can be found at [1], [2] and [3]. The 15-day review is limited in scope to changes made from the previous review. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn. Comments may be submitted to the TC by any person, by a web-form that can be reached either on that page, via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=wsn. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/wsn-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: Zip: http://www.oasis-open.org/apps/org/workgroup/wsn/download.php/18585/wsn-pr-03.zip This zip file contains: 1. The specifications with change marks (showing changes since the previous public review), in 3 formats: wsn-ws_base_notification-1.3-spec-pr-03.pdf wsn-ws_base_notification-1.3-spec-pr-03.htm wsn-ws_base_notification-1.3-spec-pr-03.doc wsn-ws_brokered_notification-1.3-spec-pr-03.pdf wsn-ws_brokered_notification-1.3-spec-pr-03.htm wsn-ws_brokered_notification-1.3-spec-pr-03.doc wsn-ws_topics-1.3-spec-pr-02.pdf wsn-ws_topics-1.3-spec-pr-02.htm wsn-ws_topics-1.3-spec-pr-02.doc 2. Schemas and WSDL files: b-2.xsd bw-2.wsdl br-2.xsd brw-2.wsdl t-1.xsd 3. A log of the changes made since the previous public review: wsn_report_pr-03.htm OASIS and the Web Services Notification Technical Committee welcome your comments. Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae@oasis-open.org [1] http://lists.oasis-open.org/archives/tc-announce/200507/msg00004.html WS-BaseNotification, public review draft dated 7 July 2005 WS-BrokeredNotification, public review draft dated 7 July 2005 [2] http://lists.oasis-open.org/archives/tc-announce/200512/msg00007.html WS-BaseNotification, public review draft dated 28 November 2005 WS-BrokeredNotification, public review draft dated 28 November 2005 [3] http://lists.oasis-open.org/archives/tc-announce/200512/msg00006.html WS-Topics, public review draft dated 16 December 2005 --------------------------------------------------------------------- This email list is used solely by OASIS for official consortium communications. Opt-out requests may be sent to member_services@oasis-open.org, however, all members are strongly encouraged to maintain a subscription to this list. -- to unsubscribe send a message to netconf-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 Jun 08 17:27:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoS2j-0000Qz-Ja for netconf-archive@lists.ietf.org; Thu, 08 Jun 2006 17:27:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoS2j-0005Xm-0w for netconf-archive@lists.ietf.org; Thu, 08 Jun 2006 17:27:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FoRyH-0008dq-Sl for netconf-data@psg.com; Thu, 08 Jun 2006 21:23:17 +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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FoRyE-0008cy-LE for netconf@ops.ietf.org; Thu, 08 Jun 2006 21:23:15 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k58LNCZS001224 for ; Thu, 8 Jun 2006 17:23:13 -0400 Received: (qmail 15607 invoked by uid 78); 8 Jun 2006 21:22:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 8 Jun 2006 21:22:13 -0000 Message-ID: <448894FF.1060006@andybierman.com> Date: Thu, 08 Jun 2006 14:22:07 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: RFC Editor edit list for approved netconf drafts Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Hi, Somebody asked for this edit list earlier. It is available from the ID-Tracker as well. Is this list complete? =========================== We are currently working on an edit for the subtree filter. (prot-12, bottom of page 22, sec. 6.2.5) Since everybody who commented agreed that the intent of the WG for an empty subtree filter is not reflected in the text, 1 or 2 sentences reflecting the WG intent will be submitted as another 'rfc edit' request. The text will indicate that a containment node at a particular level, that has any nested content-select or attribute-select nodes, will be removed from the results if all of these nested boolean expressions evaluate to 'false' results. This will also allow us to write text in the Notifications draft that says "a subtree filter set that results in an empty element indicates that the notification MUST NOT be generated by the agent." ============================ thanks, Andy ------ for the draft-ietf-netconf-ssh-06.txt document ---------- - In section 3, page 3 (last line) and 4: OLD: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, if a subsystem cannot be used, it should be possible for a client to skip over any system messages that are sent at shell start-up by searching for a NETCONF element. Note that this may not avoid problems if system messages are recieved later in the session. NEW: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, even when a subsystem is used, some extraneous messages may be printed by the user's start-up scripts. Implementations MUST skip over these messages by searching for an 'xml' start directive, which MUST be followed by a element in the 'NETCONF' namespace. - In section 5, page 6, line 4 in 1st para: OLD: ...and terminate the SSH session. NEW: ...and close the SSH session channel. ----- in the draft-ietf-netconf-prot-12.txt document ---------- Page 16: OLD: The following illustrates the case of returning multiple elements. NEW: The following illustrates the case of returning multiple elements. Note that the data models used in the examples in this section use the element to distinguish between multiple instances of the element. On page 34: OLD: If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the filter element contains an XPath expression. NEW: If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute on the filter element contains an XPath expression. Page 39, bottom: OLD: Example: Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration: NEW: Example: The examples in this section utilize a simple data model, in which multiple instances of the 'interface' element may be present, and an instance is distinguished by the 'name' element within each 'interface' element. Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration: On page 46: OLD: A lock MUST not be granted if any of the following conditions are true: * a lock is already held by another NETCONF session or another ^^^^^^^ entity NEW: A lock MUST not be granted if any of the following conditions are true: * a lock is already held by any NETCONF session or another entity On page 50: OLD: If the NETCONF peer supports the :xpath capability (Section 8.9), the value 'xpath' may be used to indicate that the filter element contains an XPath expression. NEW: If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute on the filter element contains an XPath expression. On page 67: OLD: The :xpath capability modifies the and operations to accept the value "xpath" in the type attribute of the filter element. When the type attribute is set to "xpath", the contents of the filter element will be treated as an xpath expression and used to filter the returned data. NEW: The :xpath capability modifies the and operations to accept the value "xpath" in the type attribute of the filter element. When the type attribute is set to "xpath", a select attribute MUST be present on the filter element. The select attribute will be treated as an XPath expression and used to filter the returned data. The filter element itself MUST be empty in this case. On page 67: OLD: top/users/user[name="fred"] NEW: On page 81: OLD: NEW: -- to unsubscribe send a message to netconf-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 Jun 09 18:57:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fopup-0004CM-HQ for netconf-archive@lists.ietf.org; Fri, 09 Jun 2006 18:57:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fopum-0003r4-4B for netconf-archive@lists.ietf.org; Fri, 09 Jun 2006 18:57:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fopof-000NbN-JR for netconf-data@psg.com; Fri, 09 Jun 2006 22:50: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.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fopoe-000Nao-C4 for netconf@ops.ietf.org; Fri, 09 Jun 2006 22:50:56 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k59MotPG027316 for ; Fri, 9 Jun 2006 18:50:55 -0400 Received: (qmail 18134 invoked by uid 78); 9 Jun 2006 22:50:55 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 9 Jun 2006 22:50:55 -0000 Message-ID: <4489FB4A.8080100@andybierman.com> Date: Fri, 09 Jun 2006 15:50:50 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: prot-12 non-change 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: 798b2e660f1819ae38035ac1d8d5e3ab Hi, We discussed changing the partial-operation error previously, but the changes were never made. Since it is such a minor nit, there is no point in changing it now. This error report uses to identify elements with errors. Every other error report uses for this purpose. Oh well. A bug in my original text that nobody never caught. 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 Jun 10 01:00:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fova3-0006CS-Gx for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 01:00:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FovZy-0003Lh-78 for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 01:00:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FovTy-000Oqa-VI for netconf-data@psg.com; Sat, 10 Jun 2006 04:53:58 +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 1FovTx-000OqN-So for netconf@ops.ietf.org; Sat, 10 Jun 2006 04:53:58 +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 k5A4rvCu004928 for ; Sat, 10 Jun 2006 00:53:57 -0400 Received: (qmail 4236 invoked by uid 78); 10 Jun 2006 04:53:57 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 10 Jun 2006 04:53:57 -0000 Message-ID: <448A505F.6080805@andybierman.com> Date: Fri, 09 Jun 2006 21:53:51 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: XML namespace advice Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi, 3 XML questions: Section 3.1 of prot-12 clearly states that the NETCONF elements reside in a specific namespace. Q1: Is it an error if a PDU (e.g., or ) is received by the peer, which does not use namespaces? Or is it okay to set the default namespace to the NETCONF NS in this case? My understanding of sec. 4.1 is that all of the attributes, including the xmlns declarations, in the , need to be replicated exactly in the element. However, an agent may add attributes to the end of the list. Q2: Are xmlns declarations special, and not supposed to be included in the list of replicated attributes? All the document examples show them replicated in the . I am choosing to reuse any xmlns prefix values from the in the , but I believe an implementation could ignore those prefixes, and add new xmlns declarations if it wanted. A conforming manager must figure out the corresponding namespace regardless of the prefix value. (It is a pain to minimize the number of xmlns decls generated in the , but they are so verbose!) Q3: Are there more xmlns processing and generation rules and/or guidelines to follow here? thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 10 01:50:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FowMX-0003P5-2V for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 01:50:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FowEY-0000sN-HI for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 01:42:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fow9D-0001rG-NF for netconf-data@psg.com; Sat, 10 Jun 2006 05:36: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 autolearn=ham version=3.1.1 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fow9C-0001qw-V0 for netconf@ops.ietf.org; Sat, 10 Jun 2006 05:36:35 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5A5aTX99700; Fri, 9 Jun 2006 22:36:29 -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 k5A5aO511876; Fri, 9 Jun 2006 22:36:24 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k5A5vCPd038095; Sat, 10 Jun 2006 01:57:12 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606100557.k5A5vCPd038095@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: XML namespace advice In-Reply-To: Your message of "Fri, 09 Jun 2006 21:53:51 PDT." <448A505F.6080805@andybierman.com> Date: Sat, 10 Jun 2006 01:57:12 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Andy Bierman writes: > Q1: Is it an error if a PDU (e.g., or ) is received by > the peer, which does not use namespaces? Or is it okay to set > the default namespace to the NETCONF NS in this case? Does this fit under the 'be liberal in what you accept' banner? JUNOS tries to follow that, accepting either an empty or an accurate namespace. > Q2: Are xmlns declarations special, and not supposed to be > included in the list of replicated attributes? All the > document examples show them replicated in the . They are special, but only slightly. JUNOS echoes them all, but I know that some XML parsers discard unused namespaces, so an xmlns:foo attribute may be trimmed from an element where nothing in it or its children reference that prefix. This trim happens in the parser, so the netconf implementation may never see the xmlns attribute. 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 Sat Jun 10 03:10:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoxcA-0004Xy-HU for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 03:10:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foxc8-0002ZZ-4m for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 03:10:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FoxYU-00085H-NJ for netconf-data@psg.com; Sat, 10 Jun 2006 07:06: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.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 1FoxYT-000855-MH for netconf@ops.ietf.org; Sat, 10 Jun 2006 07:06:46 +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 k5A76iPu011088 for ; Sat, 10 Jun 2006 03:06:45 -0400 Received: (qmail 26213 invoked by uid 78); 10 Jun 2006 07:06:44 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 10 Jun 2006 07:06:44 -0000 Message-ID: <448A6F7F.3080708@andybierman.com> Date: Sat, 10 Jun 2006 00:06:39 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: "Netconf (E-mail)" Subject: Re: XML namespace advice References: <200606100557.k5A5vCPd038095@idle.juniper.net> In-Reply-To: <200606100557.k5A5vCPd038095@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Phil Shafer wrote: > Andy Bierman writes: >> Q1: Is it an error if a PDU (e.g., or ) is received by >> the peer, which does not use namespaces? Or is it okay to set >> the default namespace to the NETCONF NS in this case? > > Does this fit under the 'be liberal in what you accept' > banner? JUNOS tries to follow that, accepting either > an empty or an accurate namespace. I believe the W3C documentation I read a long time ago said no namespace is different than all the elements and attributes in a default namespace. I don't remember why. If the targetNamespace attribute is missing from the element, and the elementFormDefault and attributeFormDefault are both 'unqualified', then there is no namespace at all. Even if you assign a namespace, if there are child elements of or they should generate errors, because they are not in the netconf namespace. Of course, you could really follow the Postel Principle with zeal, and ignore namespaces in the request entirely, figuring out which element the manager is specifying (i.e., org. naming conventions do not rely on namespaces to be unique). I do that and also allow the user to enter an owner="foo" attribute to help find the namespace. However, in the , I always use namespaces, even if they weren't used in the request. > >> Q2: Are xmlns declarations special, and not supposed to be >> included in the list of replicated attributes? All the >> document examples show them replicated in the . > > They are special, but only slightly. JUNOS echoes them all, > but I know that some XML parsers discard unused namespaces, > so an xmlns:foo attribute may be trimmed from an element where > nothing in it or its children reference that prefix. This > trim happens in the parser, so the netconf implementation > may never see the xmlns attribute. In netconf, only the element is special. There are no attribute requirements for any other element. I replicate every attribute from the , as the doc says, and then add more attributes as needed. > > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 10 11:59:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp5rg-0001pY-58 for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 11:59:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp5rc-0008KC-PL for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 11:59:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp5ln-0000ky-I0 for netconf-data@psg.com; Sat, 10 Jun 2006 15:53:03 +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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp5lm-0000kl-Dn for netconf@ops.ietf.org; Sat, 10 Jun 2006 15:53:02 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5AFr18K015722 for ; Sat, 10 Jun 2006 11:53:01 -0400 Received: (qmail 23986 invoked by uid 78); 10 Jun 2006 15:53:01 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 10 Jun 2006 15:53:01 -0000 Message-ID: <448AEAD7.1080003@andybierman.com> Date: Sat, 10 Jun 2006 08:52:55 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: "Netconf (E-mail)" Subject: Re: XML namespace advice References: <200606100557.k5A5vCPd038095@idle.juniper.net> <448A6F7F.3080708@andybierman.com> In-Reply-To: <448A6F7F.3080708@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >... > In netconf, only the element is special. > There are no attribute requirements for any other element. > I replicate every attribute from the , as the doc says, > and then add more attributes as needed. One more note: attributes are unordered in XML. The parser from libxml2 I am using does not preserve attribute order. (It puts the namespace decls first.) This text in prot-12, sec. 4.1 is the only normative mention of this, except a similar comment in the XSD: If additional attributes are present in an element, a NETCONF peer MUST return them unmodified in the element. This text means the individual attributes are returned unmodified, not that the order is also preserved, which is implied in all the examples. > > >> >> Thanks, >> Phil >> >> Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 10 14:55:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp8co-0005VG-3v for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 14:55:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp8cm-0002jV-Ly for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 14:55:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp8Yo-000EDw-Rl for netconf-data@psg.com; Sat, 10 Jun 2006 18:51:50 +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 [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp8Yn-000EDX-BW for netconf@ops.ietf.org; Sat, 10 Jun 2006 18:51:49 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id DF80443; Sat, 10 Jun 2006 20:51:47 +0200 (CEST) Date: Sat, 10 Jun 2006 20:51:35 +0200 (CEST) Message-Id: <20060610.205135.124298644.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: XML namespace advice From: Martin Bjorklund In-Reply-To: <448A505F.6080805@andybierman.com> References: <448A505F.6080805@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Andy Bierman wrote: > Hi, > > 3 XML questions: > > Section 3.1 of prot-12 clearly states that the NETCONF elements > reside in a specific namespace. > > Q1: Is it an error if a PDU (e.g., or ) is received by > the peer, which does not use namespaces? Or is it okay to set > the default namespace to the NETCONF NS in this case? Isn't the namespace in the message supposed to indicate which version of the NETCONF protocol the peer supports? If there is no namespace, which version should we guess the other side is using? (Ok, the answer is pretty obvious right now :) Also, if you take the schema from the draft, and an instance document which is a valid message but w/o the namespace, xmllint failes to validate. Although it's easy enough to implement both these cases, I think it's better if the namespace declaration is required. A follow-up question is if a peer is non-compliant if it requires a correct xmlns attribute on the and messages? > My understanding of sec. 4.1 is that all of the attributes, > including the xmlns declarations, in the , need to be > replicated exactly in the element. > However, an agent may add attributes to the end of the list. > > Q2: Are xmlns declarations special, and not supposed to be > included in the list of replicated attributes? All the > document examples show them replicated in the . We replicate the xmlns attributes, but I honestly can't see why this is important or even useful. > Q3: Are there more xmlns processing and generation rules and/or > guidelines to follow here? If you accept a rpc w/o namespaces, you have to decide what to do with e.g. an edit-config w/o namespaces. But I think you mentioned that you allow that. However, if you get a *with* a correct xmlns, and an edit-config *without* a xmlns, I think you should generate an error, since it's invalid per the XML Namespace Recommendation. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 10 15:41:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp9LG-00054d-Mo for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 15:41:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp9LF-0007he-8D for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 15:41:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp9Hk-000Hfv-7S for netconf-data@psg.com; Sat, 10 Jun 2006 19:38:16 +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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp9Hj-000Hfj-94 for netconf@ops.ietf.org; Sat, 10 Jun 2006 19:38:15 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5AJcELY001227 for ; Sat, 10 Jun 2006 15:38:14 -0400 Received: (qmail 28723 invoked by uid 78); 10 Jun 2006 19:38:14 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 10 Jun 2006 19:38:14 -0000 Message-ID: <448B1FA0.7060300@andybierman.com> Date: Sat, 10 Jun 2006 12:38:08 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: XML namespace advice References: <448A505F.6080805@andybierman.com> <20060610.205135.124298644.mbj@tail-f.com> In-Reply-To: <20060610.205135.124298644.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> 3 XML questions: >> >> Section 3.1 of prot-12 clearly states that the NETCONF elements >> reside in a specific namespace. >> >> Q1: Is it an error if a PDU (e.g., or ) is received by >> the peer, which does not use namespaces? Or is it okay to set >> the default namespace to the NETCONF NS in this case? > > Isn't the namespace in the message supposed to indicate which > version of the NETCONF protocol the peer supports? If there is no > namespace, which version should we guess the other side is using? > (Ok, the answer is pretty obvious right now :) Since it is implementation-dependent which namespace the peer picks as a default, the answer isn't obvious. I would pick the most current version the agent supports as the default (usual choice). > > Also, if you take the schema from the draft, and an instance document > which is a valid message but w/o the namespace, xmllint failes > to validate. > > Although it's easy enough to implement both these cases, I think it's > better if the namespace declaration is required. Not so fast! I don't want to force an agent to reject an otherwise valid RPC request because the netconf namespace is missing. And, as 8.1 clearly indicates, the PDU does not rely on the xmlns decl anywhere in the PDU to identify the version. In the example, the first capability for the protocol itself seems redundant, but this mechanism works even if the namespace decl is missing. > > A follow-up question is if a peer is non-compliant if it requires a > correct xmlns attribute on the and messages? > I knew you would ask that! I read through the draft. I can't find any text that says that PDUs must use namespaces. It's just shown that way in all the examples. This requires more thought, before we start creating any CLRs. >> My understanding of sec. 4.1 is that all of the attributes, >> including the xmlns declarations, in the , need to be >> replicated exactly in the element. >> However, an agent may add attributes to the end of the list. >> >> Q2: Are xmlns declarations special, and not supposed to be >> included in the list of replicated attributes? All the >> document examples show them replicated in the . > > We replicate the xmlns attributes, but I honestly can't see why this > is important or even useful. It's a lot of work for not much value. If anything, it might help the operator more easily analyze the reply by sight, instead of with tools. That's why I bother doing it. But just for , no other nested elements. > >> Q3: Are there more xmlns processing and generation rules and/or >> guidelines to follow here? > > If you accept a rpc w/o namespaces, you have to decide what to do with > e.g. an edit-config w/o namespaces. But I think you mentioned that > you allow that. > > However, if you get a *with* a correct xmlns, and an edit-config > *without* a xmlns, I think you should generate an error, since it's > invalid per the XML Namespace Recommendation. Yes -- I do. But not for the rpc method, unless it is in a different namespace than NETCONF. I think you mean the namespace of the edit-config data: ... (Note the prefix 'x' is not required; the xmlns decl in the 'top' element could have overridden the default namespace instead.) Actually, if namespaces are not used at all, there is a default 'owner' which happens to own the netconf RPCs and the core data models. However, an error will be generated if the "netconf-blah" namespace decl is present but the "example.com" decl is missing. The parser knows if namespaces are being used or not in the PDU. Even if namespaces are used, attributes without namespace prefixes will be classified by the libxml2 parser as "not in any namespace". I'm not picky wrt/ stuff like: operation="create" ns:operation="create" You have to check for both cases. (Love XML! ;-) > > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 10 16:00:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp9dZ-0001lp-Rt for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 16:00:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp9dU-0002lG-IC for netconf-archive@lists.ietf.org; Sat, 10 Jun 2006 16:00:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp9Z6-000J4B-R2 for netconf-data@psg.com; Sat, 10 Jun 2006 19:56: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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fp9Z6-000J3z-4G for netconf@ops.ietf.org; Sat, 10 Jun 2006 19:56:12 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5AJuBqD007353 for ; Sat, 10 Jun 2006 15:56:11 -0400 Received: (qmail 19408 invoked by uid 78); 10 Jun 2006 19:56:11 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 10 Jun 2006 19:56:11 -0000 Message-ID: <448B23D5.5010608@andybierman.com> Date: Sat, 10 Jun 2006 12:56:05 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: access-denied error Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi, I wanted to sneak in another comment on the non-existent access control model for netconf. There is no guidance whatsoever when to send the access-denied error. Therefore, it must be okay for implementors to make up their own rules. For example, on and operations, one may choose never to issue access-denied errors, and simply treat an explicit or implicit request for data that the session is not authorized to view as a 'false' filter. In other words, the and operations by definition are requesting only data that the session has access to read. Anything else is just skipped, similar to the way SNMP getNext works wrt/ VACM. This will make it harder for hackers to learn anything about the data model instances, especially since access to and will tend to be unrestricted, as opposed to access. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Jun 11 14:42:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpUtk-00085y-5w for netconf-archive@lists.ietf.org; Sun, 11 Jun 2006 14:42:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpUti-0002E4-Hy for netconf-archive@lists.ietf.org; Sun, 11 Jun 2006 14:42:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpUn3-000EYb-4o for netconf-data@psg.com; Sun, 11 Jun 2006 18:36:01 +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 [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpUn1-000EYJ-6o for netconf@ops.ietf.org; Sun, 11 Jun 2006 18:35:59 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id C677344; Sun, 11 Jun 2006 20:35:57 +0200 (CEST) Date: Sun, 11 Jun 2006 20:35:45 +0200 (CEST) Message-Id: <20060611.203545.64880698.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: RFC Editor edit list for approved netconf drafts From: Martin Bjorklund In-Reply-To: <448894FF.1060006@andybierman.com> References: <448894FF.1060006@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Andy Bierman wrote: > Hi, > > Somebody asked for this edit list earlier. > It is available from the ID-Tracker as well. > > Is this list complete? What about the schema issues that were discussed in http://ops.ietf.org/lists/netconf/netconf.2006/msg00512.html, and then in some more recent thread? /martin > > =========================== > We are currently working on an edit for the subtree filter. > (prot-12, bottom of page 22, sec. 6.2.5) > > Since everybody who commented agreed that the intent of the WG > for an empty subtree filter is not reflected in the text, > 1 or 2 sentences reflecting the WG intent will be submitted as > another 'rfc edit' request. > > The text will indicate that a containment node at a particular level, > that has any nested content-select or attribute-select nodes, > will be removed from the results if all of these nested boolean > expressions evaluate to 'false' results. > > This will also allow us to write text in the Notifications draft that > says "a subtree filter set that results in an empty element > indicates that the notification MUST NOT be generated by the agent." > ============================ > > thanks, > Andy > > > ------ for the draft-ietf-netconf-ssh-06.txt document ---------- > > - In section 3, page 3 (last line) and 4: > > OLD: > > SSHv1. Running NETCONF as an SSH subsystem avoids the need for the > script to recognize shell prompts or skip over extraneous > information, such as a system message that is sent at shell start-up. > However, if a subsystem cannot be used, it should be possible for a > client to skip over any system messages that are sent at shell > start-up by searching for a NETCONF element. Note that this > may not avoid problems if system messages are recieved later in the > session. > > NEW: > SSHv1. Running NETCONF as an SSH subsystem avoids the need for the > script to recognize shell prompts or skip over extraneous > information, such as a system message that is sent at shell start-up. > However, even when a subsystem is used, some extraneous messages may > be printed by the user's start-up scripts. Implementations MUST > skip over these messages by searching for an 'xml' start directive, > which MUST be followed by a element in the 'NETCONF' namespace. > > - In section 5, page 6, line 4 in 1st para: > > OLD: > > ...and terminate the SSH session. > > NEW: > > ...and close the SSH session channel. > > ----- in the draft-ietf-netconf-prot-12.txt document ---------- > > Page 16: > OLD: > The following illustrates the case of returning > multiple elements. > > NEW: > The following illustrates the case of returning > multiple elements. > > Note that the data models used in the examples in this section use > the element to distinguish between multiple instances of > the element. > > On page 34: > OLD: > If the NETCONF peer supports the :xpath capability > (Section 8.9), the value "xpath" may be used to indicate that > the filter element contains an XPath expression. > > NEW: > If the NETCONF peer supports the :xpath capability > (Section 8.9), the value "xpath" may be used to indicate that > the select attribute on the filter element contains an XPath > expression. > > Page 39, bottom: > > OLD: > > Example: > > Set the MTU to 1500 on an interface named "Ethernet0/0" in the > running configuration: > > NEW: > > Example: > > The examples in this section utilize a simple > data model, in which multiple instances of the 'interface' > element may be present, and an instance is distinguished > by the 'name' element within each 'interface' element. > > Set the MTU to 1500 on an interface named "Ethernet0/0" in the > running configuration: > > On page 46: > > OLD: > > A lock MUST not be granted if any of the following conditions are > true: > > * a lock is already held by another NETCONF session or another > ^^^^^^^ > entity > > NEW: > > A lock MUST not be granted if any of the following conditions are > true: > > * a lock is already held by any NETCONF session or another > entity > > > On page 50: > OLD: > If the NETCONF peer supports the :xpath capability > (Section 8.9), the value 'xpath' may be used to indicate that > the filter element contains an XPath expression. > > NEW: > If the NETCONF peer supports the :xpath capability > (Section 8.9), the value "xpath" may be used to indicate that > the select attribute on the filter element contains an XPath > expression. > > > On page 67: > OLD: > The :xpath capability modifies the and operations > to accept the value "xpath" in the type attribute of the filter > element. When the type attribute is set to "xpath", the contents of > the filter element will be treated as an xpath expression and used to > filter the returned data. > > NEW: > The :xpath capability modifies the and operations > to accept the value "xpath" in the type attribute of the filter > element. When the type attribute is set to "xpath", a select > attribute MUST be present on the filter element. The select > attribute will be treated as an XPath expression and used to filter > the returned data. The filter element itself MUST be empty in this > case. > > On page 67: > OLD: > > top/users/user[name="fred"] > > > NEW: > > > > > On page 81: > OLD: > type="FilterType" default="subtree"/> > > NEW: > type="FilterType" default="subtree"/> > > > > > > > > -- > to 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 Jun 12 09:11:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmCo-0003rI-Fa for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 09:11:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fplzt-0007Je-Iz for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 08:58:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fplqu-000MB9-ME for netconf-data@psg.com; Mon, 12 Jun 2006 12:49:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.54] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fplqe-000M7S-VC for netconf@ops.ietf.org; Mon, 12 Jun 2006 12:49:07 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R005WY03K6G@szxga02-in.huawei.com> for netconf@ops.ietf.org; Mon, 12 Jun 2006 20:59:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R003H403JZU@szxga02-in.huawei.com> for netconf@ops.ietf.org; Mon, 12 Jun 2006 20:59:44 +0800 (CST) Received: from l48181 ([10.110.115.37]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0Q00A9NZUR5W@szxml04-in.huawei.com> for netconf@ops.ietf.org; Mon, 12 Jun 2006 20:54:31 +0800 (CST) Date: Mon, 12 Jun 2006 20:43:54 +0800 From: Li Yan Subject: and filter conditions To: "'Netconf (E-mail)'" Message-id: <000301c68e1d$dda93ed0$25736e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_mzAj3aF72qvhRLF4mixKbQ)" Thread-index: AcaOHd1Odr8U8AWrTC2fOh5gGv3GFQ== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 2cf79100e158081ec662b95abd1ecd80 This is a multi-part message in MIME format. --Boundary_(ID_mzAj3aF72qvhRLF4mixKbQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Excuse me, I have asked this question again. I asked this question 10 days ago, but I've got no response. Question: Will the request get a positive response, when the result of and is nothing? If the subscription is successful in the circumstances, no event will be sent through this session. The client and server have to keep an empty session. When a new event is generated, the server must check whether the event matches to the filter conditions. It's waste of resources. So, I believe the subscription should be failed. Thanks Yan --Boundary_(ID_mzAj3aF72qvhRLF4mixKbQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Excuse me, I have asked this question again. I asked this question 10 days ago, but I've got no response.

Question:

Will the <create-subscription> request get a positive response, when the result of <filter> and <named-profile> is nothing?

If the subscription is successful in the circumstances, no event will be sent through this session. The client and server have to keep an empty session. When a new event is generated, the server must check whether the event matches to the filter conditions.

It's waste of resources. So, I believe the subscription should be failed.

Thanks

 

Yan

--Boundary_(ID_mzAj3aF72qvhRLF4mixKbQ)-- -- to unsubscribe send a message to netconf-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 Jun 12 10:11:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpn8G-0002Wh-LH for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 10:11:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpn8G-0002ai-05 for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 10:11:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fpn1s-0002tW-Hy for netconf-data@psg.com; Mon, 12 Jun 2006 14:04:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.1 Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fpn1r-0002tH-Du for netconf@ops.ietf.org; Mon, 12 Jun 2006 14:04:31 +0000 Received: from rchemx01.fnc.net.local ([167.254.101.101]) by fncnmp03.fnc.fujitsu.com with ESMTP; 12 Jun 2006 09:04:30 -0500 X-IronPort-AV: i="4.05,229,1146459600"; d="scan'208"; a="39587041:sNHT21953440" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: XML namespace advice Date: Mon, 12 Jun 2006 09:04:30 -0500 Message-ID: <50B73C8966FCF840BABA099651DBE060011AB35D@rchemx01.fnc.net.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XML namespace advice Thread-Index: AcaMxkAgqz7bdsbYSqaQnrOnzusKfABYUCkg From: "Hare, Michael" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 If it doesn't have the NETCONF NS, then how do you know you are parsing = a true NETCONF message and not some other construct? It seems to me NS should be mandatory, if even defaulted they still = exist in the internal DOM. The contents of a or should also be proprietary NS'd = by the vendor associated with the payload. I raised this a few weeks ago, the NETCONF base schema needs to allow = content inside a or node, with the added = attribute: namespace=3D"##other" to force the payload to be of a = different NS than NETCONF. as in: My payloads look something like: Ethernet0 DOWN I validate against my propietary schema, which in turn imports the = NETCONF schema. My entire passes schema validation. --------------------------------- Michael Hare NMI Engineering GnuPG Key fingerprint =3D 1AD4 726D E359 A31D 05BF ACE5 CA93 7AD5 D8E3 = A876 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On Behalf Of Andy Bierman Sent: Saturday, June 10, 2006 2:38 PM To: Martin Bjorklund Cc: netconf@ops.ietf.org Subject: Re: XML namespace advice Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> 3 XML questions: >> >> Section 3.1 of prot-12 clearly states that the NETCONF elements >> reside in a specific namespace. >> >> Q1: Is it an error if a PDU (e.g., or ) is received = by >> the peer, which does not use namespaces? Or is it okay to set >> the default namespace to the NETCONF NS in this case? >=20 > Isn't the namespace in the message supposed to indicate which > version of the NETCONF protocol the peer supports? If there is no > namespace, which version should we guess the other side is using? > (Ok, the answer is pretty obvious right now :) Since it is implementation-dependent which namespace the peer picks as a default, the answer isn't obvious. I would pick the most current version the agent supports as the default (usual choice). >=20 > Also, if you take the schema from the draft, and an instance document > which is a valid message but w/o the namespace, xmllint failes > to validate. >=20 > Although it's easy enough to implement both these cases, I think it's > better if the namespace declaration is required. Not so fast! I don't want to force an agent to reject an otherwise valid RPC request because the netconf namespace is missing. And, as 8.1 clearly indicates, the PDU does not rely on the xmlns decl anywhere in the PDU to identify the version. In the example, the first capability for the protocol itself seems redundant, but this mechanism works even if the namespace decl is missing. >=20 > A follow-up question is if a peer is non-compliant if it requires a > correct xmlns attribute on the and messages? >=20 I knew you would ask that! I read through the draft. I can't find any text that says that PDUs must use namespaces. It's just shown that way in all the examples. This requires more thought, before we start creating any CLRs. >> My understanding of sec. 4.1 is that all of the attributes, >> including the xmlns declarations, in the , need to be >> replicated exactly in the element.=20 >> However, an agent may add attributes to the end of the list. >> >> Q2: Are xmlns declarations special, and not supposed to be >> included in the list of replicated attributes? All the >> document examples show them replicated in the . >=20 > We replicate the xmlns attributes, but I honestly can't see why this > is important or even useful. It's a lot of work for not much value. If anything, it might help the operator more easily analyze the reply by sight, instead of with tools. That's why I bother doing it. But just for , no other nested elements. >=20 >> Q3: Are there more xmlns processing and generation rules and/or >> guidelines to follow here?=20 >=20 > If you accept a rpc w/o namespaces, you have to decide what to do with > e.g. an edit-config w/o namespaces. But I think you mentioned that > you allow that. >=20 > However, if you get a *with* a correct xmlns, and an edit-config > *without* a xmlns, I think you should generate an error, since it's > invalid per the XML Namespace Recommendation. Yes -- I do. But not for the rpc method, unless it is in a different namespace than NETCONF. I think you mean the namespace of the edit-config data: ... (Note the prefix 'x' is not required; the xmlns decl in the 'top' element could have overridden the default namespace instead.) Actually, if namespaces are not used at all, there is a default 'owner' which happens to own the netconf RPCs and the core data models. However, an error will be generated if the "netconf-blah" namespace decl is present but the "example.com" decl is missing. The parser knows if namespaces are being used or not in the PDU. Even if namespaces are used, attributes without namespace prefixes will be classified by the libxml2 parser as "not in any namespace". I'm not picky wrt/ stuff like: operation=3D"create" ns:operation=3D"create" You have to check for both cases. (Love XML! ;-) >=20 >=20 > /martin >=20 Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 12 12:14:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpp3S-0005oS-5K for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 12:14:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpp3R-0000fF-Kd for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 12:14:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpoyY-000Ein-9r for netconf-data@psg.com; Mon, 12 Jun 2006 16:09:14 +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 1FpoyO-000Ei9-Je for netconf@ops.ietf.org; Mon, 12 Jun 2006 16:09:13 +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 k5CG8YUi019533 for ; Mon, 12 Jun 2006 12:09:02 -0400 Received: (qmail 1176 invoked by uid 78); 12 Jun 2006 16:08:34 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 12 Jun 2006 16:08:34 -0000 Message-ID: <448D9179.2070304@andybierman.com> Date: Mon, 12 Jun 2006 09:08:25 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Hare, Michael" CC: netconf@ops.ietf.org Subject: Re: XML namespace advice References: <50B73C8966FCF840BABA099651DBE060011AB35D@rchemx01.fnc.net.local> In-Reply-To: <50B73C8966FCF840BABA099651DBE060011AB35D@rchemx01.fnc.net.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Hare, Michael wrote: > If it doesn't have the NETCONF NS, then how do you know you are parsing a true NETCONF message and not some other construct? > It seems to me NS should be mandatory, if even defaulted they still exist in the internal DOM. > > The contents of a or should also be proprietary NS'd by the vendor associated with the payload. > > I raised this a few weeks ago, the NETCONF base schema needs to allow content inside a or node, with the added attribute: namespace="##other" to force the payload to be of a different NS than NETCONF. > If it is another RPC mechanism that exactly matches and namespaces are not used at all, then the agent will be fooled into thinking it was a NETCONF RPC. Why is this other RPC mechanism using the NETCONF well-known assigned port numbers in the first place? That's the broken, non-conformant part. If the orther RPC does not match then the agent will respond with for the parts it did not understand. I want operators to be able to type a PDU by hand if required. Currently, the namespace URI is the only CLR junk in the PDU. Nobody remembers what the value is by memory (just as bad as OIDs!). I'm not going to force operators to remember NETCONF nonsense by heart so they can get the picky agent to accept a PDU. But you don't have to assume the netconf namespace. Your agent can reject a PDU without the netconf namespace if you think that helps. (This hack only works for simple PDUs without content, but that's all it's intended to do.) We did not put namespace="##other" in the schema because it may not always be true that the netconf namespace does not contain any data objects. Andy > as in: > > > > > > > My payloads look something like: > > > > > Ethernet0 > DOWN > > > > > > I validate against my propietary schema, which in turn imports the NETCONF schema. My entire passes schema validation. > > --------------------------------- > Michael Hare > NMI Engineering > > GnuPG Key fingerprint = 1AD4 726D E359 A31D 05BF ACE5 CA93 7AD5 D8E3 A876 > > > > > > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Saturday, June 10, 2006 2:38 PM > To: Martin Bjorklund > Cc: netconf@ops.ietf.org > Subject: Re: XML namespace advice > > > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, >>> >>> 3 XML questions: >>> >>> Section 3.1 of prot-12 clearly states that the NETCONF elements >>> reside in a specific namespace. >>> >>> Q1: Is it an error if a PDU (e.g., or ) is received by >>> the peer, which does not use namespaces? Or is it okay to set >>> the default namespace to the NETCONF NS in this case? >> Isn't the namespace in the message supposed to indicate which >> version of the NETCONF protocol the peer supports? If there is no >> namespace, which version should we guess the other side is using? >> (Ok, the answer is pretty obvious right now :) > > > Since it is implementation-dependent which namespace > the peer picks as a default, the answer isn't obvious. > I would pick the most current version the agent supports > as the default (usual choice). > > >> Also, if you take the schema from the draft, and an instance document >> which is a valid message but w/o the namespace, xmllint failes >> to validate. >> >> Although it's easy enough to implement both these cases, I think it's >> better if the namespace declaration is required. > > > Not so fast! > I don't want to force an agent to reject an otherwise valid > RPC request because the netconf namespace is missing. > > And, as 8.1 clearly indicates, the PDU > does not rely on the xmlns decl anywhere in the PDU > to identify the version. In the example, the first > capability for the protocol itself seems redundant, > but this mechanism works even if the namespace decl is missing. > > >> A follow-up question is if a peer is non-compliant if it requires a >> correct xmlns attribute on the and messages? >> > > I knew you would ask that! > I read through the draft. > I can't find any text that says that PDUs must use namespaces. > It's just shown that way in all the examples. > > This requires more thought, before we start creating any CLRs. > > >>> My understanding of sec. 4.1 is that all of the attributes, >>> including the xmlns declarations, in the , need to be >>> replicated exactly in the element. >>> However, an agent may add attributes to the end of the list. >>> >>> Q2: Are xmlns declarations special, and not supposed to be >>> included in the list of replicated attributes? All the >>> document examples show them replicated in the . >> We replicate the xmlns attributes, but I honestly can't see why this >> is important or even useful. > > > It's a lot of work for not much value. > If anything, it might help the operator more easily > analyze the reply by sight, instead of with tools. > That's why I bother doing it. But just for , > no other nested elements. > > >>> Q3: Are there more xmlns processing and generation rules and/or >>> guidelines to follow here? >> If you accept a rpc w/o namespaces, you have to decide what to do with >> e.g. an edit-config w/o namespaces. But I think you mentioned that >> you allow that. >> >> However, if you get a *with* a correct xmlns, and an edit-config >> *without* a xmlns, I think you should generate an error, since it's >> invalid per the XML Namespace Recommendation. > > > Yes -- I do. But not for the rpc method, unless it is in > a different namespace than NETCONF. > > I think you mean the namespace of the edit-config data: > > > > ... > > > > > > > > > (Note the prefix 'x' is not required; the xmlns decl in the 'top' > element could have overridden the default namespace instead.) > > Actually, if namespaces are not used at all, there is a > default 'owner' which happens to own the netconf RPCs > and the core data models. > > However, an error will be generated if the "netconf-blah" > namespace decl is present but the "example.com" decl is > missing. The parser knows if namespaces are being used or not > in the PDU. > > Even if namespaces are used, attributes without namespace prefixes > will be classified by the libxml2 parser as "not in any namespace". > I'm not picky wrt/ stuff like: > > operation="create" > ns:operation="create" > > You have to check for both cases. (Love XML! ;-) > > > > >> >> /martin >> > > Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 12 12:32:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FppLL-0001u2-Mq for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 12:32:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FppLJ-0001fI-DG for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 12:32:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FppHM-000GYx-H2 for netconf-data@psg.com; Mon, 12 Jun 2006 16:28:40 +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 1FppGz-000GW1-M1 for netconf@ops.ietf.org; Mon, 12 Jun 2006 16:28:40 +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 k5CGRwZZ012967 for ; Mon, 12 Jun 2006 12:28:07 -0400 Received: (qmail 22482 invoked by uid 78); 12 Jun 2006 16:27:41 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 12 Jun 2006 16:27:41 -0000 Message-ID: <448D95F4.3000801@andybierman.com> Date: Mon, 12 Jun 2006 09:27:32 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: RFC Editor edit list for approved netconf drafts References: <448894FF.1060006@andybierman.com> <20060611.203545.64880698.mbj@tail-f.com> In-Reply-To: <20060611.203545.64880698.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Somebody asked for this edit list earlier. >> It is available from the ID-Tracker as well. >> >> Is this list complete? > > What about the schema issues that were discussed in > http://ops.ietf.org/lists/netconf/netconf.2006/msg00512.html, and then > in some more recent thread? What is the proposed text for the RFC Edit? Are there any issues with now, or just ? > > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 12 17:27:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptwS-0007wy-Uh for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 17:27:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptwR-0000b4-HQ for netconf-archive@lists.ietf.org; Mon, 12 Jun 2006 17:27:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fptpn-000FGQ-6T for netconf-data@psg.com; Mon, 12 Jun 2006 21:20:31 +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 [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FptpV-000FEL-Rf for netconf@ops.ietf.org; Mon, 12 Jun 2006 21:20:14 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 6760644; Mon, 12 Jun 2006 23:20:12 +0200 (CEST) Date: Mon, 12 Jun 2006 23:20:12 +0200 (CEST) Message-Id: <20060612.232012.11236412.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: RFC Editor edit list for approved netconf drafts From: Martin Bjorklund In-Reply-To: <448D95F4.3000801@andybierman.com> References: <448894FF.1060006@andybierman.com> <20060611.203545.64880698.mbj@tail-f.com> <448D95F4.3000801@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> Somebody asked for this edit list earlier. > >> It is available from the ID-Tracker as well. > >> > >> Is this list complete? > > > > What about the schema issues that were discussed in > > http://ops.ietf.org/lists/netconf/netconf.2006/msg00512.html, and then > > in some more recent thread? > > What is the proposed text for the RFC Edit? I must say that I'm not sure that this is the right change, but I think that the easiest way to fix this is to change the dataInlineType, configInlineType and filterInlineType to be xs:extension of xs:anyType instead of xs:restriction, i.e. instead of which, as far as I understand it, restricts configInlineType to be 'empty', we should have (and same for dataInlineType and filterInlineType). > Are there any issues with now, or just ? Yes, see above. This change is verified with the validator in libxml2. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 13 12:22:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBem-0007IH-2F for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 12:22:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBek-0002v9-MM for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 12:22:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqBYd-0001CG-H6 for netconf-data@psg.com; Tue, 13 Jun 2006 16:15: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.6 required=5.0 tests=AWL,BAYES_00 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 1FqBYc-0001Bz-19 for netconf@ops.ietf.org; Tue, 13 Jun 2006 16:15:58 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5DGFvRZ029680 for ; Tue, 13 Jun 2006 12:15:57 -0400 Received: (qmail 22329 invoked by uid 78); 13 Jun 2006 16:15:38 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 13 Jun 2006 16:15:38 -0000 Message-ID: <448EE49B.6040706@andybierman.com> Date: Tue, 13 Jun 2006 09:15:23 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: RFC Editor edit list for approved netconf drafts References: <448894FF.1060006@andybierman.com> <20060611.203545.64880698.mbj@tail-f.com> <448D95F4.3000801@andybierman.com> <20060612.232012.11236412.mbj@tail-f.com> In-Reply-To: <20060612.232012.11236412.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> Somebody asked for this edit list earlier. >>>> It is available from the ID-Tracker as well. >>>> >>>> Is this list complete? >>> What about the schema issues that were discussed in >>> http://ops.ietf.org/lists/netconf/netconf.2006/msg00512.html, and then >>> in some more recent thread? >> What is the proposed text for the RFC Edit? > > I must say that I'm not sure that this is the right change, but I > think that the easiest way to fix this is to change the > dataInlineType, configInlineType and filterInlineType to be > xs:extension of xs:anyType instead of xs:restriction, i.e. instead of I don't know the correct XSD text either. Since this entire exercise is for the benefit of XSD tools, we need somebody who uses those tools to find the text that works. I really dislike the way some of the XML constructs in NETCONF were done. Using element names instead of strings for config names, using extra nesting layers (e.g. ) in some choices, The element, etc. The XSD needs to reflect these characteristics for (but cannot): - The element must be empty if the 'type' attribute is equal to "xpath". - The 'select' attribute must be present if the type attribute is equal to "xpath", and must not be present if it is equal to "subtree". - If the 'type' attribute is equal to "subtree", then the element content may be non-empty. - Mixed mode content is not allowed in the element, so if it is non-empty it must contain only XML child nodes and not text (from any namespace). - Since XML treats whitespace as content, the following filters are different: 1) legal, empty: 2) illegal, text: > > > > > > > > which, as far as I understand it, restricts configInlineType to be > 'empty', we should have > > > > > > > > (and same for dataInlineType and filterInlineType). > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 13 13:49:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD1O-0002gr-Io for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 13:49:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCwh-0003Ri-Bw for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 13:44:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqCsm-0007MJ-Gu for netconf-data@psg.com; Tue, 13 Jun 2006 17:40:52 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqCsl-0007M7-Oo for netconf@ops.ietf.org; Tue, 13 Jun 2006 17:40:52 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5DHeoiu007018 for ; Tue, 13 Jun 2006 13:40:51 -0400 Received: (qmail 2340 invoked by uid 78); 13 Jun 2006 17:40:50 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 13 Jun 2006 17:40:50 -0000 Message-ID: <448EF89D.7070100@andybierman.com> Date: Tue, 13 Jun 2006 10:40:45 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: XML namespace advice References: <448A505F.6080805@andybierman.com> <20060610.205135.124298644.mbj@tail-f.com> In-Reply-To: <20060610.205135.124298644.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, > However, if you get a *with* a correct xmlns, and an edit-config > *without* a xmlns, I think you should generate an error, since it's > invalid per the XML Namespace Recommendation. Agreed, but this is stated somewhat incorrectly. IMO, it is reasonable for the agent to assign the netconf NS as the default NS, in the event or PDUs without any NS declarations are received, if they are received on netconf connections (i.e., any port the agent is listening as a netconf port). If such a PDU contains elements or attributes that are not in the netconf NS that the agent is using, then you should generate the appropriate errors. So even if the agent can figure it out without namespaces, it SHOULD generate unknown-element or unknown-attribute errors in this case. (I think it's anti-user-friendly, but what can you do, it's XML ;-) > > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 13 15:18:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEOq-0005fi-2H for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 15:18:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEOo-0004Gg-KR for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 15:18:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqEGd-000DaD-TI for netconf-data@psg.com; Tue, 13 Jun 2006 19:09: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.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqEGb-000DZb-3T for netconf@ops.ietf.org; Tue, 13 Jun 2006 19:09:33 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id B86D148; Tue, 13 Jun 2006 21:09:31 +0200 (CEST) Date: Tue, 13 Jun 2006 21:09:31 +0200 (CEST) Message-Id: <20060613.210931.42855020.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: RFC Editor edit list for approved netconf drafts From: Martin Bjorklund In-Reply-To: <448EE49B.6040706@andybierman.com> References: <448D95F4.3000801@andybierman.com> <20060612.232012.11236412.mbj@tail-f.com> <448EE49B.6040706@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >>>> Hi, > >>>> > >>>> Somebody asked for this edit list earlier. > >>>> It is available from the ID-Tracker as well. > >>>> > >>>> Is this list complete? > >>> What about the schema issues that were discussed in > >>> http://ops.ietf.org/lists/netconf/netconf.2006/msg00512.html, and then > >>> in some more recent thread? > >> What is the proposed text for the RFC Edit? > > > > I must say that I'm not sure that this is the right change, but I > > think that the easiest way to fix this is to change the > > dataInlineType, configInlineType and filterInlineType to be > > xs:extension of xs:anyType instead of xs:restriction, i.e. instead of > > > I don't know the correct XSD text either. > Since this entire exercise is for the benefit > of XSD tools, we need somebody who uses those tools > to find the text that works. As I wrote, I did test it with libxml2. Furthermore, if this construct is used (i.e. xs:extension) the original filter definition validates just fine even for xpath, i.e. there would be no need to add the 'select' attribute. (Not that I have any problems with the 'select' attribute). > - Since XML treats whitespace as content, the following filters > are different: > > 1) legal, empty: > 2) illegal, text: I don't follow that logic. Are you suggesting that this is special only for the empty filter, but not when you have some subelements? Thus, would be identical to or not? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 13 15:24:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEVO-0001Ij-L8 for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 15:24:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEVN-0004Re-B7 for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 15:24:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqEPj-000EEM-FP for netconf-data@psg.com; Tue, 13 Jun 2006 19:18: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, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqEPi-000EEA-PN for netconf@ops.ietf.org; Tue, 13 Jun 2006 19:18:58 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id D59A670; Tue, 13 Jun 2006 21:18:57 +0200 (CEST) Date: Tue, 13 Jun 2006 21:18:57 +0200 (CEST) Message-Id: <20060613.211857.51012206.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: XML namespace advice From: Martin Bjorklund In-Reply-To: <448EF89D.7070100@andybierman.com> References: <448A505F.6080805@andybierman.com> <20060610.205135.124298644.mbj@tail-f.com> <448EF89D.7070100@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Andy Bierman wrote: > IMO, it is reasonable for the agent to assign the netconf NS > as the default NS, in the event or PDUs without any > NS declarations are received, if they are received on netconf > connections (i.e., any port the agent is listening as a netconf port). > > If such a PDU contains elements or attributes that are not > in the netconf NS that the agent is using, then you should generate the > appropriate errors. So even if the agent can figure it > out without namespaces, it SHOULD generate unknown-element > or unknown-attribute errors in this case. (I think it's > anti-user-friendly, but what can you do, it's XML ;-) I don't think you'd have to generate unknown-element in this case because of XML rules. If you get an instance document w/o xmlns declarations, the elements in the instance document don't belong to any namespace. If you treat an 'rpc' element without a namespace declaration to mean the 'rpc' element from the netconf namespace, you can treat the 'interfaces' element to mean the 'interfaces' element from the ifMIB namespace. I think it's logical to either be strict (which we are today) or else allow an instance document w/o namespaces whatsoever. (First I thought that the elementFormDefault="qualified" attribute in the netconf schema meant that the schema required instance documents to qualify the top-level elements with a namespace, but I'm not so sure anymore (although libxml2 seems to work like that). XML Schema is tricky...) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 13 17:40:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqGd3-0006sY-8c for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 17:40:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqGd1-0003Kc-Qj for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 17:40:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqGXD-000NH2-WE for netconf-data@psg.com; Tue, 13 Jun 2006 21:34:52 +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 1FqGWY-000NDd-B6 for netconf@ops.ietf.org; Tue, 13 Jun 2006 21:34:51 +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 k5DLWjFu030920 for ; Tue, 13 Jun 2006 17:33:41 -0400 Received: (qmail 30851 invoked by uid 78); 13 Jun 2006 21:32:45 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 13 Jun 2006 21:32:45 -0000 Message-ID: <448F2EF1.1060701@andybierman.com> Date: Tue, 13 Jun 2006 14:32:33 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: RFC Editor edit list for approved netconf drafts References: <448D95F4.3000801@andybierman.com> <20060612.232012.11236412.mbj@tail-f.com> <448EE49B.6040706@andybierman.com> <20060613.210931.42855020.mbj@tail-f.com> In-Reply-To: <20060613.210931.42855020.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy Bierman wrote: >>>>>> Hi, >>>>>> >>>>>> Somebody asked for this edit list earlier. >>>>>> It is available from the ID-Tracker as well. >>>>>> >>>>>> Is this list complete? >>>>> What about the schema issues that were discussed in >>>>> http://ops.ietf.org/lists/netconf/netconf.2006/msg00512.html, and then >>>>> in some more recent thread? >>>> What is the proposed text for the RFC Edit? >>> I must say that I'm not sure that this is the right change, but I >>> think that the easiest way to fix this is to change the >>> dataInlineType, configInlineType and filterInlineType to be >>> xs:extension of xs:anyType instead of xs:restriction, i.e. instead of >> >> I don't know the correct XSD text either. >> Since this entire exercise is for the benefit >> of XSD tools, we need somebody who uses those tools >> to find the text that works. > > As I wrote, I did test it with libxml2. > > Furthermore, if this construct is used (i.e. xs:extension) the > original filter definition validates just fine even for xpath, > i.e. there would be no need to add the 'select' attribute. (Not that I > have any problems with the 'select' attribute). > >> - Since XML treats whitespace as content, the following filters >> are different: >> >> 1) legal, empty: >> 2) illegal, text: > > I don't follow that logic. Are you suggesting that this is special > only for the empty filter, but not when you have some subelements? > Thus, would > > > > be identical to > > > > > > or not? > No it is not special. It is just whitespace between a start and end tag, not between two start tags. Your example is correct. Whitespace from start to start tag or end to start tag is ignored. Both of these elements contain whitespace; they are not empty. This test applies only to simpleTypes. I don't actually reject this. I check for it, and treat the construct as an empty tag. You can force the parser to take a whitespace string using double quotes: " ". > > > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 13 18:04:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqGzn-0001bq-4A for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 18:04:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqGzl-0005vQ-O6 for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 18:04:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqGw6-000PO7-LF for netconf-data@psg.com; Tue, 13 Jun 2006 22:00:34 +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 1FqGw5-000PNt-SL for netconf@ops.ietf.org; Tue, 13 Jun 2006 22:00:34 +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 k5DM0Wjw013172 for ; Tue, 13 Jun 2006 18:00:33 -0400 Received: (qmail 31683 invoked by uid 78); 13 Jun 2006 22:00:32 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 13 Jun 2006 22:00:32 -0000 Message-ID: <448F357A.9080802@andybierman.com> Date: Tue, 13 Jun 2006 15:00:26 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andy Bierman CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: RFC Editor edit list for approved netconf drafts References: <448D95F4.3000801@andybierman.com> <20060612.232012.11236412.mbj@tail-f.com> <448EE49B.6040706@andybierman.com> <20060613.210931.42855020.mbj@tail-f.com> <448F2EF1.1060701@andybierman.com> In-Reply-To: <448F2EF1.1060701@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 >.. Sorry for the confusion. The element does not allow mixed content, so it much contain a complexType or be empty. The filter examples below would be true if mixed content was allowed. Since it is not, the whitespace content will not be interpreted as a simpleType. Andy > > > No it is not special. > It is just whitespace between a start and end tag, > not between two start tags. Your example is correct. > Whitespace from start to start tag or end to start tag is ignored. > > > > > > > Both of these elements contain whitespace; they are not empty. > This test applies only to simpleTypes. I don't actually > reject this. I check for it, and treat the construct as > an empty tag. You can force the parser to take a whitespace > string using double quotes: " ". > > > > >> >> >> >> /martin >> >> > > Andy > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 13 21:27:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKA5-0005SK-Ny for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 21:27:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqKA1-0003kP-CN for netconf-archive@lists.ietf.org; Tue, 13 Jun 2006 21:27:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqK2L-000Ezu-MN for netconf-data@psg.com; Wed, 14 Jun 2006 01:19: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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqK2K-000Ezg-Nz for netconf@ops.ietf.org; Wed, 14 Jun 2006 01:19:12 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5E1JBKR013205 for ; Tue, 13 Jun 2006 21:19:12 -0400 Received: (qmail 9203 invoked by uid 78); 14 Jun 2006 01:19:11 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 14 Jun 2006 01:19:11 -0000 Message-ID: <448F6401.1080806@andybierman.com> Date: Tue, 13 Jun 2006 18:18:57 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: XML namespace advice References: <448A505F.6080805@andybierman.com> <20060610.205135.124298644.mbj@tail-f.com> <448EF89D.7070100@andybierman.com> <20060613.211857.51012206.mbj@tail-f.com> In-Reply-To: <20060613.211857.51012206.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO, it is reasonable for the agent to assign the netconf NS >> as the default NS, in the event or PDUs without any >> NS declarations are received, if they are received on netconf >> connections (i.e., any port the agent is listening as a netconf port). >> >> If such a PDU contains elements or attributes that are not >> in the netconf NS that the agent is using, then you should generate the >> appropriate errors. So even if the agent can figure it >> out without namespaces, it SHOULD generate unknown-element >> or unknown-attribute errors in this case. (I think it's >> anti-user-friendly, but what can you do, it's XML ;-) > > I don't think you'd have to generate unknown-element in this case > because of XML rules. If you get an instance document w/o xmlns > declarations, the elements in the instance document don't belong to > any namespace. If you treat an 'rpc' element without a namespace > declaration to mean the 'rpc' element from the netconf namespace, you > can treat the 'interfaces' element to mean the 'interfaces' element > from the ifMIB namespace. Actually this is what I do now. Instead of defaulting to the netconf NS, I default to no namespace. If namespaces are not used at all, then wrong-namespace won't be generated. If any of the elements are not owned by the default owner, then an unknown-element would be generated. Namespaces are fully supported if they are used, of course. Andy > > I think it's logical to either be strict (which we are today) or else > allow an instance document w/o namespaces whatsoever. > > (First I thought that the elementFormDefault="qualified" attribute in > the netconf schema meant that the schema required instance documents > to qualify the top-level elements with a namespace, but I'm not so > sure anymore (although libxml2 seems to work like that). XML Schema > is tricky...) > > > /martin > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 08:39:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqr8Y-0005QV-2p for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 08:39:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqr8W-0006YS-Op for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 08:39:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqr2i-0008YN-0W for netconf-data@psg.com; Thu, 15 Jun 2006 12:33: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.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 1Fqr2h-0008Y8-5z for netconf@ops.ietf.org; Thu, 15 Jun 2006 12:33:47 +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 k5FCUHGp007837 for ; Thu, 15 Jun 2006 08:30:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC Editor edit list for approved netconf drafts Date: Thu, 15 Jun 2006 15:33:44 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC Editor edit list for approved netconf drafts Thread-Index: AcaLQf2QZicWQIlpRaqMma3B8RxNbgFNPLmg From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Netconf \(E-mail\)" X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Friday, June 09, 2006 12:22 AM > To: Netconf (E-mail) > Subject: RFC Editor edit list for approved netconf drafts >=20 > Hi, >=20 > Somebody asked for this edit list earlier. > It is available from the ID-Tracker as well. >=20 Just a matter of clarification.=20 The list in the tracker is the ONLY list that the RFC Editor knows. The documents are in the RFC Editor queue, and may progress quicker than you believe based upon what is available in the tracker. It is not a common practice to insert anything but formatting or typos fixes in AUTH48, so if you believe that one or more of the documents will need further edits, we should ask for them to be frozen, and if the changes are consistent we may want to generate new versions to replace the one currently in the queue. This needs not generate a new IESG approval cycle, but the IESG should be informed about the changes so that somebody who has any doubts about the new variant being too far from the one that was approved has a chance to express his/her opinions.=20 Dan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 10:02:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsQ6-0003Y5-7c for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 10:02:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqsQ4-0000qX-To for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 10:02:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqsKp-000EYd-KF for netconf-data@psg.com; Thu, 15 Jun 2006 13:56: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 [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqsKm-000EY7-W6 for netconf@ops.ietf.org; Thu, 15 Jun 2006 13:56:33 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k5FDpBC08422 for ; Thu, 15 Jun 2006 09:51:11 -0400 (EDT) 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: Session reuse Date: Thu, 15 Jun 2006 09:56:27 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B409386FE8@zcarhxm2.corp.nortel.com> In-Reply-To: <4486F2DF.7090104@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Session reuse Thread-Index: AcaKSmnGibCSTZ/oThOSjWlZC/J8swGONdJQ From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 hi But there have also been a number of people who disagreed with this approach as making netconf unusable and supported intelligent introduction of new verbs. I think calling consensus on this issue is premature. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, June 07, 2006 11:38 AM To: Balazs Lengyel Cc: Netconf (E-mail) Subject: Re: Session reuse Balazs Lengyel wrote: > Hello Andy, > As I remember you mentioned you hoped to reach consensus on session > reuse before the IETF meeting. Could you summarize how you see the state=20 > of consensus? I wrote: I was hoping we could finish up event classes before the meeting. The other issue that seems to be finishing up is the use of existing configuration RPCs instead of new subscription RPCs for conveying notification generation parameters. Not session reuse. RPC reuse. I think there is WG consensus that notification generation parameters need to be capable of being NV-stored, and that existing RPCs for manipulating configuration data must be used for this purpose. There have also been multiple objections to having overlapping subscription and configuration based mechanisms, so IMO there is also WG consensus to limit any new RPCs to new features which do not duplicate existing RPCs. > Balazs >=20 Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 10:27:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqsp6-00006F-5b for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 10:27:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqsp4-0002xs-MS for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 10:27:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqsj3-000GdC-5c for netconf-data@psg.com; Thu, 15 Jun 2006 14:21:37 +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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqsj0-000Gcq-C5 for netconf@ops.ietf.org; Thu, 15 Jun 2006 14:21:34 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5FELXjI020362 for ; Thu, 15 Jun 2006 10:21:33 -0400 Received: (qmail 19276 invoked by uid 78); 15 Jun 2006 14:21:33 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 15 Jun 2006 14:21:33 -0000 Message-ID: <44916D0D.6010503@andybierman.com> Date: Thu, 15 Jun 2006 07:22:05 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Session reuse References: <713043CE8B8E1348AF3C546DBE02C1B409386FE8@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B409386FE8@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Sharon Chisholm wrote: > hi > > But there have also been a number of people who disagreed with this > approach as making netconf unusable and supported intelligent > introduction of new verbs. I think calling consensus on this issue is > premature. What is "this approach"? There isn't any consensus that the new verbs proposed in the draft are appropriate. Several people have mentioned that it is inefficient to require the notification generation and filtering parameters to be passed to the agent every time a new session starts. There have also been strong objections to multiple mechanisms (filter + profile) to convey the configuration parameters. Netconf already has a model and mechanisms for manipulating NV-stored configuration, which cannot be ignored or superseded. > Sharon Andy > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Wednesday, June 07, 2006 11:38 AM > To: Balazs Lengyel > Cc: Netconf (E-mail) > Subject: Re: Session reuse > > > Balazs Lengyel wrote: >> Hello Andy, >> As I remember you mentioned you hoped to reach consensus on session >> reuse before the IETF meeting. Could you summarize how you see the > state >> of consensus? > > I wrote: > > I was hoping we could finish up event classes before the meeting. > The other issue that seems to be finishing up is the use of existing > configuration RPCs instead of new subscription RPCs for conveying > notification generation parameters. > > > Not session reuse. RPC reuse. > > I think there is WG consensus that notification generation parameters > need to be capable of being NV-stored, and that existing RPCs for > manipulating configuration data must be used for this purpose. > > There have also been multiple objections to having overlapping > subscription and configuration based mechanisms, so IMO there is also WG > consensus to limit any new RPCs to new features which do not duplicate > existing RPCs. > >> Balazs >> > > Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 14:49:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqwua-0001lr-4d for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 14:49:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwuY-0005sQ-JM for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 14:49:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqwpF-000ACS-Ss for netconf-data@psg.com; Thu, 15 Jun 2006 18:44:17 +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 [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqwpE-000ACD-EN for netconf@ops.ietf.org; Thu, 15 Jun 2006 18:44:16 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5FIiCp10854 for ; Thu, 15 Jun 2006 14:44:12 -0400 (EDT) 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: Additional proposed update to Netconf Notification Draft Date: Thu, 15 Jun 2006 14:44:04 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4093F6035@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additional proposed update to Netconf Notification Draft Thread-Index: AcaQq6zSO0si5HIFQBqnqK7OfdUjoA== From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 hi Here are some additional proposed edits in addition to those that I sent a while back https://ops.ietf.org/lists/netconf/netconf.2006/msg00691.html 1. Replace the Event Class section with the following: " Events can be classified into one more event classes. Each event class identifies a set of event notifications which - share similar content - are generated from similar events =20 The initial set of event classes is configuration, fault, state, audit, data, maintenance, metrics, security, information, heartbeat and syslogTunnel. See the IANA Considerations section for information on defining new event classes. All events shall carry the following data: list of event class, timestamp and sequence number of the notification. They may also carry additional data. A configuration event, alternatively known as an inventory event, is used to indicate that hardware, software, or a service has been added/ changed/removed. In keeping aligned with NETCONF protocol operations, configuration events may included copy configuration event, delete configuration event, or the edit configuration event (create, delete, merge, replace). As configuration notifications could potentially carry huge amounts of data in order to properly support functions such as security audit logs, so it is expected that netconf clients will engineer their subscriptions to meet their needs and to not overwhelm their capacity to process and store event notifications. Examples include hardware board removed, software module loaded or DNS server reconfigured. Changes are reported to all subscribed clients, not just to those clients whose actions triggered the changes. A fault event notification is generated when a fault condition (error or warning) occurs. A fault event may result in an alarm. Examples of fault events could be a communications alarm, environmental alarm, equipment alarm, processing error alarm, quality of service alarm, or a threshold crossing event. See RFC3877 and RFC2819 for more information. The fault notification should carry the following data: severity, event source, probable cause, specific problem, additional information. A state event indicates a change from one state to another, where a state is a condition or stage in the existence of a managed entity. State change events are seen in many specifications. For Entity state changes, see [Entity-State-MIB] for more information. The notification shall identify the object who's state changed and the new state. Internal states of a node are important for supervision purposes and also effect how a node can be configured.=20 Audit events provide event of very specific actions within a managed device. In isolation an audit events provides very limited data. A collection of audit information forms an audit trail. A data dump event is an asynchronous event containing information about a system, its configuration, state, etc. A maintenance event signals the beginning, process or end of an action either generated by a manual or automated maintenance action. If the maintenance event is a direct result of a configuration management operation on this Netconf session then an rpc-reply notification should be used. This event class is intended instead for reporting on scheduled maintenance activities. Expected data includes a description of the maintenance process, the stage the process has reached, the manual action, automatic process that triggered the notification. Examples include .automatic backup completed A metrics event contains a metric or a collection of metrics. This includes performance metrics. A heart beat event is sent periodically to enable testing that the communications channel is still functional. It behaves much like the other event classes, with the exception that implementations may not want to include an event log, if supported. Although widely used throughout the industry, no current corresponding work within the IETF. However, other standards bodies such as the TeleManagement Forum have similar definitions. syslogTunnel event is when syslog content is sent, unmodified, within a Netconf event Notification. See appendix X.X for more information. " 2. Add text clarifying that session-based subscriptions are stored only in the running configuration. 3. To the callHome section, discuss target port and any implications on transport and other things missing [I've asked Balazs if he could help out with some text] 4. Clarify that the filters will be applied against the content of the notifications (including the event class which is part of the header). 5. Add clarification that if a subscription request will fail if either the filter is syntactically invalid or the named profile does not exist. Note that while you could also say it fails if the filter points at garbage, but someone consider it just pointing at something that does not yet exist yet and consider that a filter.=20 Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 15:28:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxVo-0003qU-O2 for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 15:28:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxVo-0001Iq-75 for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 15:28:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqxS9-000DMk-Qa for netconf-data@psg.com; Thu, 15 Jun 2006 19:24: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.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 1FqxS8-000DMW-MH for netconf@ops.ietf.org; Thu, 15 Jun 2006 19:24:28 +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 k5FJOR65013999 for ; Thu, 15 Jun 2006 15:24:27 -0400 Received: (qmail 23930 invoked by uid 78); 15 Jun 2006 19:24:27 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 15 Jun 2006 19:24:27 -0000 Message-ID: <4491B432.2000600@andybierman.com> Date: Thu, 15 Jun 2006 12:25:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Additional proposed update to Netconf Notification Draft References: <713043CE8B8E1348AF3C546DBE02C1B4093F6035@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4093F6035@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Sharon Chisholm wrote: IMO, the text that Balazs proposed on 5/25/06 better. Can you highlight the diffs; this doesn't look very changed. It still contains all the same overlapping, vague classifications. Andy > hi > > Here are some additional proposed edits in addition to those that I sent > a while back > https://ops.ietf.org/lists/netconf/netconf.2006/msg00691.html > > > 1. Replace the Event Class section with the following: > " > Events can be classified into one more event classes. Each event class > identifies a set of event notifications which > - share similar content > - are generated from similar events > > The initial set of event classes is configuration, fault, state, audit, > data, maintenance, metrics, security, information, heartbeat and > syslogTunnel. See the IANA Considerations section for information on > defining new event classes. > > All events shall carry the following data: list of event class, > timestamp and sequence number of the notification. They may also carry > additional data. > > A configuration event, alternatively known as an inventory event, is > used to indicate that hardware, software, or a service has been added/ > changed/removed. In keeping aligned with NETCONF protocol operations, > configuration events may included copy configuration event, delete > configuration event, or the edit configuration event (create, delete, > merge, replace). As configuration notifications could potentially carry > huge amounts of data in order to properly support functions such as > security audit logs, so it is expected that netconf clients will > engineer their subscriptions to meet their needs and to not overwhelm > their capacity to process and store event notifications. Examples > include hardware board removed, software module loaded or DNS server > reconfigured. Changes are reported to all subscribed clients, not just > to those clients whose actions triggered the changes. > > A fault event notification is generated when a fault condition (error or > warning) occurs. A fault event may result in an alarm. Examples of > fault events could be a communications alarm, environmental alarm, > equipment alarm, processing error alarm, quality of service alarm, or a > threshold crossing event. See RFC3877 and RFC2819 for more information. > The fault notification should carry the following data: severity, event > source, probable cause, specific problem, additional information. > > A state event indicates a change from one state to another, where a > state is a condition or stage in the existence of a managed entity. > State change events are seen in many specifications. For Entity state > changes, see [Entity-State-MIB] for more information. The notification > shall identify the object who's state changed and the new state. > Internal states of a node are important for supervision purposes and > also effect how a node can be configured. > > Audit events provide event of very specific actions within a managed > device. In isolation an audit events provides very limited data. A > collection of audit information forms an audit trail. > > A data dump event is an asynchronous event containing information about > a system, its configuration, state, etc. > > A maintenance event signals the beginning, process or end of an action > either generated by a manual or automated maintenance action. If the > maintenance event is a direct result of a configuration management > operation on this Netconf session then an rpc-reply notification should > be used. This event class is intended instead for reporting on scheduled > maintenance activities. > Expected data includes a description of the maintenance process, the > stage the process has reached, the manual action, automatic process that > triggered the notification. Examples include .automatic backup completed > > A metrics event contains a metric or a collection of metrics. This > includes performance metrics. > > A heart beat event is sent periodically to enable testing that the > communications channel is still functional. It behaves much like the > other event classes, with the exception that implementations may not > want to include an event log, if supported. Although widely used > throughout the industry, no current corresponding work within the IETF. > However, other standards bodies such as the TeleManagement Forum have > similar definitions. > > syslogTunnel event is when syslog content is sent, unmodified, within a > Netconf event Notification. See appendix X.X for more information. > " > > 2. Add text clarifying that session-based subscriptions are stored only > in the running configuration. > > 3. To the callHome section, discuss target port and any implications on > transport and other things missing [I've asked Balazs if he could help > out with some text] > > 4. Clarify that the filters will be applied against the content of the > notifications (including the event class which is part of the header). > > 5. Add clarification that if a subscription request will fail if either > the filter is syntactically invalid or the named profile does not exist. > Note that while you could also say it fails if the filter points at > garbage, but someone consider it just pointing at something that does > not yet exist yet and consider that a filter. > > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 15:52:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxtJ-0002Qo-15 for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 15:52:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxtH-0003T5-By for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 15:52:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqxpQ-000F6X-5I for netconf-data@psg.com; Thu, 15 Jun 2006 19:48:32 +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 [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqxpP-000F6F-0J for netconf@ops.ietf.org; Thu, 15 Jun 2006 19:48:31 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5FJmQK00022 for ; Thu, 15 Jun 2006 15:48:26 -0400 (EDT) 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: Additional proposed update to Netconf Notification Draft Date: Thu, 15 Jun 2006 15:48:25 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4093F6197@zcarhxm2.corp.nortel.com> In-Reply-To: <4491B432.2000600@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additional proposed update to Netconf Notification Draft Thread-Index: AcaQsYCQQd/m/5PjSpqKirXU63KAZAAAkuAg From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 hi This is a merge of the 5/25/06 text and the existing text. He had discussion about expectations on the client side which people had indicated was not something we could really talk about so that has not been included. I also reworked things to be sentences instead of "foo: stuff". Remember it is expected that message can belong to more then one event class. The event class is a predictor of content (and some behaviour). There will always be overlap. Just like the real-world. Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Thursday, June 15, 2006 3:26 PM To: Chisholm, Sharon [CAR:ZZ00:EXCH] Cc: Netconf (E-mail) Subject: Re: Additional proposed update to Netconf Notification Draft Sharon Chisholm wrote: IMO, the text that Balazs proposed on 5/25/06 better. Can you highlight the diffs; this doesn't look very changed. It still contains all the same overlapping, vague classifications. Andy > hi >=20 > Here are some additional proposed edits in addition to those that I=20 > sent a while back > https://ops.ietf.org/lists/netconf/netconf.2006/msg00691.html >=20 >=20 > 1. Replace the Event Class section with the following: > " > Events can be classified into one more event classes. Each event class > identifies a set of event notifications which > - share similar content > - are generated from similar events > =20 > The initial set of event classes is configuration, fault, state,=20 > audit, data, maintenance, metrics, security, information, heartbeat=20 > and syslogTunnel. See the IANA Considerations section for information=20 > on defining new event classes. >=20 > All events shall carry the following data: list of event class,=20 > timestamp and sequence number of the notification. They may also carry > additional data. >=20 > A configuration event, alternatively known as an inventory event, is=20 > used to indicate that hardware, software, or a service has been added/ > changed/removed. In keeping aligned with NETCONF protocol operations, > configuration events may included copy configuration event, delete=20 > configuration event, or the edit configuration event (create, delete,=20 > merge, replace). As configuration notifications could potentially=20 > carry huge amounts of data in order to properly support functions such > as security audit logs, so it is expected that netconf clients will=20 > engineer their subscriptions to meet their needs and to not overwhelm=20 > their capacity to process and store event notifications. Examples=20 > include hardware board removed, software module loaded or DNS server=20 > reconfigured. Changes are reported to all subscribed clients, not just > to those clients whose actions triggered the changes. >=20 > A fault event notification is generated when a fault condition (error=20 > or > warning) occurs. A fault event may result in an alarm. Examples of > fault events could be a communications alarm, environmental alarm, > equipment alarm, processing error alarm, quality of service alarm, or a > threshold crossing event. See RFC3877 and RFC2819 for more information. > The fault notification should carry the following data: severity, event > source, probable cause, specific problem, additional information. >=20 > A state event indicates a change from one state to another, where a=20 > state is a condition or stage in the existence of a managed entity.=20 > State change events are seen in many specifications. For Entity state > changes, see [Entity-State-MIB] for more information. The =20 > notification shall identify the object who's state changed and the new > state. Internal states of a node are important for supervision=20 > purposes and also effect how a node can be configured. >=20 > Audit events provide event of very specific actions within a managed=20 > device. In isolation an audit events provides very limited data. A=20 > collection of audit information forms an audit trail. >=20 > A data dump event is an asynchronous event containing information=20 > about a system, its configuration, state, etc. >=20 > A maintenance event signals the beginning, process or end of an action > either generated by a manual or automated maintenance action. If the=20 > maintenance event is a direct result of a configuration management=20 > operation on this Netconf session then an rpc-reply notification=20 > should be used. This event class is intended instead for reporting on=20 > scheduled maintenance activities. Expected data includes a description > of the maintenance process, the stage the process has reached, the=20 > manual action, automatic process that triggered the notification.=20 > Examples include .automatic backup completed >=20 > A metrics event contains a metric or a collection of metrics. This=20 > includes performance metrics. >=20 > A heart beat event is sent periodically to enable testing that the=20 > communications channel is still functional. It behaves much like the=20 > other event classes, with the exception that implementations may not=20 > want to include an event log, if supported. Although widely used=20 > throughout the industry, no current corresponding work within the=20 > IETF. However, other standards bodies such as the TeleManagement Forum > have similar definitions. >=20 > syslogTunnel event is when syslog content is sent, unmodified, within=20 > a Netconf event Notification. See appendix X.X for more information. " >=20 > 2. Add text clarifying that session-based subscriptions are stored=20 > only in the running configuration. >=20 > 3. To the callHome section, discuss target port and any implications=20 > on transport and other things missing [I've asked Balazs if he could=20 > help out with some text] >=20 > 4. Clarify that the filters will be applied against the content of the > notifications (including the event class which is part of the header). >=20 > 5. Add clarification that if a subscription request will fail if=20 > either the filter is syntactically invalid or the named profile does=20 > not exist. Note that while you could also say it fails if the filter=20 > points at garbage, but someone consider it just pointing at something=20 > that does not yet exist yet and consider that a filter. >=20 >=20 > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 16:23:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyMu-0005mG-0l for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 16:23:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyMt-0005zR-FV for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 16:23:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqyIe-000HRM-Bf for netconf-data@psg.com; Thu, 15 Jun 2006 20:18:44 +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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqyIc-000HR8-Lm for netconf@ops.ietf.org; Thu, 15 Jun 2006 20:18:43 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5FKIfFO001207 for ; Thu, 15 Jun 2006 16:18:41 -0400 Received: (qmail 10550 invoked by uid 78); 15 Jun 2006 20:18:41 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 15 Jun 2006 20:18:41 -0000 Message-ID: <4491C0F6.4070402@andybierman.com> Date: Thu, 15 Jun 2006 13:20:06 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Additional proposed update to Netconf Notification Draft References: <713043CE8B8E1348AF3C546DBE02C1B4093F6197@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4093F6197@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Sharon Chisholm wrote: > hi > > This is a merge of the 5/25/06 text and the existing text. He had > discussion about expectations on the client side which people had > indicated was not something we could really talk about so that has not > been included. I also reworked things to be sentences instead of "foo: > stuff". > > Remember it is expected that message can belong to more then one event > class. The event class is a predictor of content (and some behaviour). > There will always be overlap. Just like the real-world. > There are 2 standards issues here: 1) The standard field in a netconf notification that will always be present, for the purpose of classifying the event type. 2) The set of actual values that this stable event type field is allowed to contain. Unless it is very clear to implementors which standard classification to use, there isn't much value in standardizing (2), since an NMS will not be able to rely on consistent classification across agent vendors. If (2) should be standardized, it should be a small, non-overlapping list. IMO, the purpose of a really generalized, overlapping classification system is to provide agent vendors with a flexible mechanism which they can call a standard, but without any interoperability requirements. Why bother? Either standardize with interoperable enumerations, or leave it up to the vendors completely. > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, June 15, 2006 3:26 PM > To: Chisholm, Sharon [CAR:ZZ00:EXCH] > Cc: Netconf (E-mail) > Subject: Re: Additional proposed update to Netconf Notification Draft > > > Sharon Chisholm wrote: > > IMO, the text that Balazs proposed on 5/25/06 better. > Can you highlight the diffs; this doesn't look very changed. > It still contains all the same overlapping, vague classifications. > > > Andy > > >> hi >> >> Here are some additional proposed edits in addition to those that I >> sent a while back >> https://ops.ietf.org/lists/netconf/netconf.2006/msg00691.html >> >> >> 1. Replace the Event Class section with the following: >> " >> Events can be classified into one more event classes. Each event class > >> identifies a set of event notifications which >> - share similar content >> - are generated from similar events >> >> The initial set of event classes is configuration, fault, state, >> audit, data, maintenance, metrics, security, information, heartbeat >> and syslogTunnel. See the IANA Considerations section for information >> on defining new event classes. >> >> All events shall carry the following data: list of event class, >> timestamp and sequence number of the notification. They may also carry > >> additional data. >> >> A configuration event, alternatively known as an inventory event, is >> used to indicate that hardware, software, or a service has been added/ > >> changed/removed. In keeping aligned with NETCONF protocol operations, > >> configuration events may included copy configuration event, delete >> configuration event, or the edit configuration event (create, delete, >> merge, replace). As configuration notifications could potentially >> carry huge amounts of data in order to properly support functions such > >> as security audit logs, so it is expected that netconf clients will >> engineer their subscriptions to meet their needs and to not overwhelm >> their capacity to process and store event notifications. Examples >> include hardware board removed, software module loaded or DNS server >> reconfigured. Changes are reported to all subscribed clients, not just > >> to those clients whose actions triggered the changes. >> >> A fault event notification is generated when a fault condition (error >> or >> warning) occurs. A fault event may result in an alarm. Examples of >> fault events could be a communications alarm, environmental alarm, >> equipment alarm, processing error alarm, quality of service alarm, or > a >> threshold crossing event. See RFC3877 and RFC2819 for more > information. >> The fault notification should carry the following data: severity, > event >> source, probable cause, specific problem, additional information. >> >> A state event indicates a change from one state to another, where a >> state is a condition or stage in the existence of a managed entity. >> State change events are seen in many specifications. For Entity state > >> changes, see [Entity-State-MIB] for more information. The >> notification shall identify the object who's state changed and the new > >> state. Internal states of a node are important for supervision >> purposes and also effect how a node can be configured. >> >> Audit events provide event of very specific actions within a managed >> device. In isolation an audit events provides very limited data. A >> collection of audit information forms an audit trail. >> >> A data dump event is an asynchronous event containing information >> about a system, its configuration, state, etc. >> >> A maintenance event signals the beginning, process or end of an action > >> either generated by a manual or automated maintenance action. If the >> maintenance event is a direct result of a configuration management >> operation on this Netconf session then an rpc-reply notification >> should be used. This event class is intended instead for reporting on >> scheduled maintenance activities. Expected data includes a description > >> of the maintenance process, the stage the process has reached, the >> manual action, automatic process that triggered the notification. >> Examples include .automatic backup completed >> >> A metrics event contains a metric or a collection of metrics. This >> includes performance metrics. >> >> A heart beat event is sent periodically to enable testing that the >> communications channel is still functional. It behaves much like the >> other event classes, with the exception that implementations may not >> want to include an event log, if supported. Although widely used >> throughout the industry, no current corresponding work within the >> IETF. However, other standards bodies such as the TeleManagement Forum > >> have similar definitions. >> >> syslogTunnel event is when syslog content is sent, unmodified, within >> a Netconf event Notification. See appendix X.X for more information. " >> >> 2. Add text clarifying that session-based subscriptions are stored >> only in the running configuration. >> >> 3. To the callHome section, discuss target port and any implications >> on transport and other things missing [I've asked Balazs if he could >> help out with some text] >> >> 4. Clarify that the filters will be applied against the content of the > >> notifications (including the event class which is part of the header). >> >> 5. Add clarification that if a subscription request will fail if >> either the filter is syntactically invalid or the named profile does >> not exist. Note that while you could also say it fails if the filter >> points at garbage, but someone consider it just pointing at something >> that does not yet exist yet and consider that a filter. >> >> >> Sharon Chisholm >> Nortel >> Ottawa, Ontario >> Canada >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the > >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >> > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 15 16:50:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqynI-0001N8-T6 for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 16:50:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqynH-00019p-F2 for netconf-archive@lists.ietf.org; Thu, 15 Jun 2006 16:50:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqyk5-000Jg4-Rj for netconf-data@psg.com; Thu, 15 Jun 2006 20:47: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.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqurV-0001AE-7m for netconf@ops.ietf.org; Thu, 15 Jun 2006 16:38:29 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5FGcOK04057 for ; Thu, 15 Jun 2006 12:38:24 -0400 (EDT) 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: Session reuse Date: Thu, 15 Jun 2006 12:38:06 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4093F5D49@zcarhxm2.corp.nortel.com> In-Reply-To: <44916D0D.6010503@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Session reuse Thread-Index: AcaQiB8mdq0JotnSStuH4VsDFpoL3AAEMukQ From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 hi Another data point is that other popular XML-based network management solutions in the industry have also chosen to use subscribe and unsubscribe verbs - TMF MTOSI - WS-based Notifications Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, June 15, 2006 10:22 AM To: Chisholm, Sharon [CAR:ZZ00:EXCH] Cc: Netconf (E-mail) Subject: Re: Session reuse Sharon Chisholm wrote: > hi >=20 > But there have also been a number of people who disagreed with this=20 > approach as making netconf unusable and supported intelligent=20 > introduction of new verbs. I think calling consensus on this issue is=20 > premature. What is "this approach"? There isn't any consensus that the new verbs proposed in the draft are appropriate. Several people have mentioned that it is inefficient to require the notification generation and filtering parameters to be passed to the agent every time a new session starts. There have also been strong objections to multiple mechanisms (filter + profile) to convey the configuration parameters. Netconf already has a model and mechanisms for manipulating NV-stored configuration, which cannot be ignored or superseded. > Sharon Andy >=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]=20 > On Behalf Of Andy Bierman > Sent: Wednesday, June 07, 2006 11:38 AM > To: Balazs Lengyel > Cc: Netconf (E-mail) > Subject: Re: Session reuse >=20 >=20 > Balazs Lengyel wrote: >> Hello Andy, >> As I remember you mentioned you hoped to reach consensus on session=20 >> reuse before the IETF meeting. Could you summarize how you see the > state >> of consensus? >=20 > I wrote: >=20 > I was hoping we could finish up event classes before the meeting. > The other issue that seems to be finishing up is the use of existing > configuration RPCs instead of new subscription RPCs for conveying > notification generation parameters. >=20 >=20 > Not session reuse. RPC reuse. >=20 > I think there is WG consensus that notification generation parameters=20 > need to be capable of being NV-stored, and that existing RPCs for=20 > manipulating configuration data must be used for this purpose. >=20 > There have also been multiple objections to having overlapping=20 > subscription and configuration based mechanisms, so IMO there is also=20 > WG consensus to limit any new RPCs to new features which do not=20 > duplicate existing RPCs. >=20 >> Balazs >> >=20 > Andy >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 16 00:07:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr5cl-0007ss-3B for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 00:07:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr5cj-0006cc-Mw for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 00:07:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr5Xo-0001HZ-At for netconf-data@psg.com; Fri, 16 Jun 2006 04:02:52 +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 1Fr5Xn-0001HL-4t for netconf@ops.ietf.org; Fri, 16 Jun 2006 04:02:51 +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 k5G42ohi001162 for ; Fri, 16 Jun 2006 00:02:50 -0400 Received: (qmail 10647 invoked by uid 78); 16 Jun 2006 04:02:50 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 16 Jun 2006 04:02:50 -0000 Message-ID: <44922DDE.5020205@andybierman.com> Date: Thu, 15 Jun 2006 21:04:46 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: XML Namespace usage in NETCONF 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: 8fbbaa16f9fd29df280814cb95ae2290 Hi, I've been discussing this issue with Martin off-line. I've been re-reading the prot-12 draft. I've been writing code to implement this stuff. The draft is a bit sloppy wrt/ namespace usage. prot-12, pg. 11: 3. XML Considerations XML serves as the encoding format for NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML. This section discusses a small number of XML-related considerations pertaining to NETCONF. 3.1. Namespace All NETCONF protocol elements are defined in the following namespace: urn:ietf:params:xml:ns:netconf:base:1.0 Note the sentence regarding traditional tools. (I'll bring it up later ;-) Sec. 3.1 says that netconf XML is defined in a particular namespace, which is the targetNamespace in the netconf XSD. I cannot find any normative text in the document that says a manager MUST use namespaces in NETCONF PDUs. I know that they SHOULD use namespaces. There is text in the subtree filter section which indicates namespace usage is optional: from 6.1: XML namespaces may be specified (via 'xmlns' declarations) within the filter data model. If so, the declared namespace must first exactly match a namespace supported by the server. 6.2.1. Namespace Selection If namespaces are used then the filter output will only include elements from the specified namespace. A namespace is considered to match (for filter purposes) if the content of the 'xmlns' attributes are the same in the filter and the underlying data model. Note that namespace selection cannot be used by itself. At least one element must be specified in the filter any elements to be included in the filter output. Example: This example implies another example that would not require the top element to be in any particular namespace: There is a problem with this example. The RPC is missing: The problem is that the and parent elements are defined in a target namespace, so namespaces are being used. Any traditional XML parser that followed namespace rules will classify the node from the example above as being requested from the netconf namespace. Only the following PDU would actually work as intended: This assumes of course the agent doesn't have its own element in another namespace (bad idea but valid XML). Relying on the presence or absence of xmlns directives in child nodes of , but applying normal namespaces rules in the nodes above and below it is a hack, and a violation of the XML Namespace Guidelines. NETCONF needs to follow the rules for XML, otherwise traditional tools for XML are worthless for NETCONF. That would kind of defeat the purpose of using XML in the first place. So here is the rule: * Either use namespaces correctly, or don't use them at all. 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 Jun 16 01:36:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr70Q-0004DC-Rq for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 01:36:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr6va-0004gY-2P for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 01:31:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr6nw-0006Ow-Gf for netconf-data@psg.com; Fri, 16 Jun 2006 05:23: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr6nv-0006Ok-Hp for netconf@ops.ietf.org; Fri, 16 Jun 2006 05:23:35 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5G5NSX21529; Thu, 15 Jun 2006 22:23:29 -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 k5G5NJ526331; Thu, 15 Jun 2006 22:23:23 -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 k5G5NIwn014819; Fri, 16 Jun 2006 01:23:18 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606160523.k5G5NIwn014819@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: XML Namespace usage in NETCONF In-Reply-To: Your message of "Thu, 15 Jun 2006 21:04:46 PDT." <44922DDE.5020205@andybierman.com> Date: Fri, 16 Jun 2006 01:23:18 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Andy Bierman writes: >The problem is that the and parent elements >are defined in a target namespace, so namespaces are being used. Sure, since you haven't changed the namespace. You can encode this to but in the default namespace as follows: or: These are different encoding for the same infoset. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 16 10:05:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEwg-0004m5-AM for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 10:05:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEwd-0008ER-Az for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 10:05:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrEo4-000HQX-HE for netconf-data@psg.com; Fri, 16 Jun 2006 13:56:16 +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 1FrEo2-000HQC-Qx for netconf@ops.ietf.org; Fri, 16 Jun 2006 13:56:15 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 636F669E; Fri, 16 Jun 2006 15:56:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 15:56:08 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 15:56:08 +0200 Message-ID: <4492B877.9000903@ericsson.com> Date: Fri, 16 Jun 2006 15:56:07 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Verbs or data model [was: Session reuse] References: <713043CE8B8E1348AF3C546DBE02C1B4093F5D49@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4093F5D49@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 13:56:08.0464 (UTC) FILETIME=[9E37D900:01C6914C] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Hello, I am definitely no expert in the Web services field but as I understand: connections and notification sessions change in WS quite frequently which might suite the subscription model more. However in network management most of the time you are interested in the same set of notifications all the time or repeatedly. More static "subscription information" is better handled with a data based model. IMHO WS speaks about many or multiple subscribers to each notification source while in Netconf the number of interested parties for a given set of notifications is often just one. In case of TMF MTOSI the use of CORBA might have provided the designers of the system with a well established subscribe-notify mechanism. If you know about other reasons please share them? Sharon what would be the reason for selecting verbs instead of data model. As I see it: Pro Verbs: - some people feel verbs are more understandable - else ??? Pro Data Model: - some people feel if the whole of netconf is based on the idea of reading and writing configuration data we should use our own mechanisms - it lets short "mixed session type" notification sessions and call-home type sessions work together more easily. They can use a common data model and a single mechanism instead of in-line filter definition for subscriptions and stored filters for call-home. - it is inefficient to require the notification generation and filtering parameters to be passed to the agent every time - filters might be reused between sessions and different notification receivers Sharon please extend my list so we can collect pro and con arguments. Balazs Sharon Chisholm wrote: > hi > > Another data point is that other popular XML-based network management > solutions in the industry have also chosen to use subscribe and > unsubscribe verbs > - TMF MTOSI > - WS-based Notifications > > Sharon > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, June 15, 2006 10:22 AM > To: Chisholm, Sharon [CAR:ZZ00:EXCH] > Cc: Netconf (E-mail) > Subject: Re: Session reuse > > > Sharon Chisholm wrote: >> hi >> >> But there have also been a number of people who disagreed with this >> approach as making netconf unusable and supported intelligent >> introduction of new verbs. I think calling consensus on this issue is >> premature. > > What is "this approach"? > > There isn't any consensus that the new verbs proposed > in the draft are appropriate. > > Several people have mentioned that it is inefficient > to require the notification generation and filtering > parameters to be passed to the agent every time a new > session starts. There have also been strong objections > to multiple mechanisms (filter + profile) to convey > the configuration parameters. Netconf already has > a model and mechanisms for manipulating NV-stored configuration, which > cannot be ignored or superseded. > > > >> Sharon > > Andy > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >> On Behalf Of Andy Bierman >> Sent: Wednesday, June 07, 2006 11:38 AM >> To: Balazs Lengyel >> Cc: Netconf (E-mail) >> Subject: Re: Session reuse >> >> >> Balazs Lengyel wrote: >>> Hello Andy, >>> As I remember you mentioned you hoped to reach consensus on session >>> reuse before the IETF meeting. Could you summarize how you see the >> state >>> of consensus? >> I wrote: >> >> I was hoping we could finish up event classes before the meeting. >> The other issue that seems to be finishing up is the use of > existing >> configuration RPCs instead of new subscription RPCs for conveying >> notification generation parameters. >> >> >> Not session reuse. RPC reuse. >> >> I think there is WG consensus that notification generation parameters >> need to be capable of being NV-stored, and that existing RPCs for >> manipulating configuration data must be used for this purpose. >> >> There have also been multiple objections to having overlapping >> subscription and configuration based mechanisms, so IMO there is also >> WG consensus to limit any new RPCs to new features which do not >> duplicate existing RPCs. >> >>> Balazs >>> >> Andy >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the > >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the > >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >> > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > > > > -- > to 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 Jun 16 10:50:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFej-0001zv-Nm for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 10:50:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFei-0003N9-Cm for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 10:50:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrFZo-000LZ7-9Q for netconf-data@psg.com; Fri, 16 Jun 2006 14:45: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.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrFZl-000LYo-9b for netconf@ops.ietf.org; Fri, 16 Jun 2006 14:45:33 +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 k5GEjWij011494 for ; Fri, 16 Jun 2006 10:45:32 -0400 Received: (qmail 3572 invoked by uid 78); 16 Jun 2006 14:45:31 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 16 Jun 2006 14:45:31 -0000 Message-ID: <4492C479.60907@andybierman.com> Date: Fri, 16 Jun 2006 07:47:21 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: "Netconf (E-mail)" Subject: Re: XML Namespace usage in NETCONF References: <200606160523.k5G5NIwn014819@idle.juniper.net> In-Reply-To: <200606160523.k5G5NIwn014819@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Phil Shafer wrote: > Andy Bierman writes: >> The problem is that the and parent elements >> are defined in a target namespace, so namespaces are being used. > > Sure, since you haven't changed the namespace. You can encode > this to but in the default namespace as follows: > Ok - the text in the subtree filter section about presence or absence of xmlns directives is misleading (I guess I am reading it too literally). It should be interpreted in the general sense. Your example obviously shows it doesn't matter where the xmlns directives are in the PDU. All that matters is normal XML processing rules are followed to determine the requested namepsace. > > > > > > > > This does not work. Although extremely stupid, empty strings and whitespace-only strings are valid namespace names. (I wonder how many agents handle an empty NS string correctly?) > or: > > > > > > > > This works. I forgot about this variant in my original mail, but it is obviously the most correct one to be used here. > > These are different encoding for the same infoset. > > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 16 11:03:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFr3-0002Zc-AO for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 11:03:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFr2-00041k-0y for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 11:03:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrFn8-000Mmx-Im for netconf-data@psg.com; Fri, 16 Jun 2006 14:59:22 +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 1FrFn8-000Mmm-2K for netconf@ops.ietf.org; Fri, 16 Jun 2006 14:59:22 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k5GExA1Z047348; Fri, 16 Jun 2006 07:59:10 -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 k5GEx9524159; Fri, 16 Jun 2006 07:59:09 -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 k5GEx8wn016305; Fri, 16 Jun 2006 10:59:09 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606161459.k5GEx8wn016305@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: XML Namespace usage in NETCONF In-Reply-To: Your message of "Fri, 16 Jun 2006 07:47:21 PDT." <4492C479.60907@andybierman.com> Date: Fri, 16 Jun 2006 10:59:08 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Andy Bierman writes: >Your example obviously shows it doesn't matter where the xmlns >directives are in the PDU. All that matters is normal XML processing >rules are followed to determine the requested namepsace. Yup, the text is an encoding of the infoset, and there are multiple ways to encode it. >This does not work. >Although extremely stupid, empty strings and whitespace-only strings >are valid namespace names. (I wonder how many agents handle an empty >NS string correctly?) You sure? In section 5.2 of: http://www.w3.org/TR/1999/REC-xml-names-19990114/ it says: The default namespace can be set to the empty string. This has the same effect, within the scope of the declaration, of there being no default namespace. There's an example also. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 16 11:19:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrG6S-0003yw-Jx for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 11:19:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrG6R-0006NC-8w for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 11:19:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrG3O-000PMu-3a for netconf-data@psg.com; Fri, 16 Jun 2006 15:16: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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrG3N-000PMc-Ae for netconf@ops.ietf.org; Fri, 16 Jun 2006 15:16:09 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5GFG674008177 for ; Fri, 16 Jun 2006 11:16:08 -0400 Received: (qmail 14847 invoked by uid 78); 16 Jun 2006 15:16:06 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 16 Jun 2006 15:16:06 -0000 Message-ID: <4492CBA4.2020505@andybierman.com> Date: Fri, 16 Jun 2006 08:17:56 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: "Netconf (E-mail)" Subject: Re: XML Namespace usage in NETCONF References: <200606161459.k5GEx8wn016305@idle.juniper.net> In-Reply-To: <200606161459.k5GEx8wn016305@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Phil Shafer wrote: > Andy Bierman writes: >> Your example obviously shows it doesn't matter where the xmlns >> directives are in the PDU. All that matters is normal XML processing >> rules are followed to determine the requested namepsace. > > Yup, the text is an encoding of the infoset, and there are > multiple ways to encode it. > >> This does not work. >> Although extremely stupid, empty strings and whitespace-only strings >> are valid namespace names. (I wonder how many agents handle an empty >> NS string correctly?) > > You sure? In section 5.2 of: > > http://www.w3.org/TR/1999/REC-xml-names-19990114/ > > it says: > > The default namespace can be set to the empty string. This has > the same effect, within the scope of the declaration, of there > being no default namespace. > > There's an example also. Okay, you are right. The libxml2 parser behaves this way: no namespace namespace = "" no namespace One more weird XML corner case to deal with :-( Is this supposed to be a feature? > > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 16 11:21:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrG8V-0004Vm-Gm for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 11:21:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrG8U-0006ki-7l for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 11:21:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrG4q-000PUg-R5 for netconf-data@psg.com; Fri, 16 Jun 2006 15:17:40 +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 1FrG4q-000PUT-7r for netconf@ops.ietf.org; Fri, 16 Jun 2006 15:17:40 +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 k5GFHd1Z047669; Fri, 16 Jun 2006 08:17:39 -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 k5GFHc527817; Fri, 16 Jun 2006 08:17:38 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k5GFHcwn016426; Fri, 16 Jun 2006 11:17:38 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606161517.k5GFHcwn016426@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: XML Namespace usage in NETCONF In-Reply-To: Your message of "Fri, 16 Jun 2006 08:17:56 PDT." <4492CBA4.2020505@andybierman.com> Date: Fri, 16 Jun 2006 11:17:38 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Andy Bierman writes: >Is this supposed to be a feature? Everything's a feature, as soon as enough people depend on it ;^) Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 16 12:03:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGnC-0006Ot-Hg for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 12:03:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGnB-0000o0-7Y for netconf-archive@lists.ietf.org; Fri, 16 Jun 2006 12:03:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrGiY-00036P-2Y for netconf-data@psg.com; Fri, 16 Jun 2006 15:58:42 +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 1FrGiX-00036D-1i for netconf@ops.ietf.org; Fri, 16 Jun 2006 15:58:41 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5GFw6Wn032731 for ; Fri, 16 Jun 2006 11:58:16 -0400 Received: (qmail 13882 invoked by uid 78); 16 Jun 2006 15:58:06 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 16 Jun 2006 15:58:06 -0000 Message-ID: <4492D582.9060603@andybierman.com> Date: Fri, 16 Jun 2006 09:00:02 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: "Netconf (E-mail)" Subject: Re: RFC Editor edit list for approved netconf drafts 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: 538aad3a3c4f01d8b6a6477ca4248793 Romascanu, Dan (Dan) wrote: > > > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >> Sent: Friday, June 09, 2006 12:22 AM >> To: Netconf (E-mail) >> Subject: RFC Editor edit list for approved netconf drafts >> >> Hi, >> >> Somebody asked for this edit list earlier. >> It is available from the ID-Tracker as well. >> > > Just a matter of clarification. > > The list in the tracker is the ONLY list that the RFC Editor knows. The > documents are in the RFC Editor queue, and may progress quicker than you > believe based upon what is available in the tracker. It is not a common > practice to insert anything but formatting or typos fixes in AUTH48, so > if you believe that one or more of the documents will need further > edits, we should ask for them to be frozen, and if the changes are > consistent we may want to generate new versions to replace the one > currently in the queue. This needs not generate a new IESG approval > cycle, but the IESG should be informed about the changes so that > somebody who has any doubts about the new variant being too far from the > one that was approved has a chance to express his/her opinions. I will put together an RFC Editor note for you and the WG to approve this weekend. There is a fix in the XSD related to empty and elements (current XSD does not allow this but it is definitely legal in NETCONF). The text for the subtree filter clarification is more difficult to write, but it should be done soon. > > Dan Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Jun 17 00:13:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrSBt-0002Na-Rq for netconf-archive@lists.ietf.org; Sat, 17 Jun 2006 00:13:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrSBr-0004hj-U8 for netconf-archive@lists.ietf.org; Sat, 17 Jun 2006 00:13:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrS5t-0006Ed-9F for netconf-data@psg.com; Sat, 17 Jun 2006 04:07:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.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 1FrS5s-0006EQ-Ia for netconf@ops.ietf.org; Sat, 17 Jun 2006 04:07:32 +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 k5H47W1Z054216 for ; Fri, 16 Jun 2006 21:07:32 -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 k5H47V584284 for ; Fri, 16 Jun 2006 21:07:31 -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 k5H47Uwn018390 for ; Sat, 17 Jun 2006 00:07:31 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606170407.k5H47Uwn018390@idle.juniper.net> To: netconf Subject: draft-shafer-netconf-syslog-00.txt Date: Sat, 17 Jun 2006 00:07:30 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 I've finally got an initial version of the draft for a netconf capability that makes syslog data available over long-lived RPCs. I just sent it off to the RFC Editor, so it should show up on ietf.org sometime this weekend, but an advance copy is available. http://professional.juniper.net/phil/ietf/draft-shafer-netconf-syslog-00.txt 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 Sat Jun 17 00:15:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrSDW-0003Ax-Vt for netconf-archive@lists.ietf.org; Sat, 17 Jun 2006 00:15:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrSDV-0004l1-H3 for netconf-archive@lists.ietf.org; Sat, 17 Jun 2006 00:15:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrSAE-0006UQ-58 for netconf-data@psg.com; Sat, 17 Jun 2006 04:12:02 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrSAD-0006UE-50 for netconf@ops.ietf.org; Sat, 17 Jun 2006 04:12:01 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5H4C09m019054 for ; Sat, 17 Jun 2006 00:12:00 -0400 Received: (qmail 12040 invoked by uid 78); 17 Jun 2006 04:12:00 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 17 Jun 2006 04:12:00 -0000 Message-ID: <44938183.70206@andybierman.com> Date: Fri, 16 Jun 2006 21:13:55 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: "Netconf (E-mail)" Subject: Re: RFC Editor edit list for approved netconf drafts References: <4492D582.9060603@andybierman.com> In-Reply-To: <4492D582.9060603@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Hi, IMO, there is no need for any edit wrt/ subtree processing. I finally found the sentence that covers this (I wrote about 4 years ago!). From prot-12: 6.3. Subtree Filter Processing The filter output (the set of selected nodes) is initially empty. Each subtree filter can contain one or more data model fragments, which represent portions of the data model that should be selected (with all child nodes) in the filter output. Each subtree data fragment is compared by the server to the internal data models supported by the server. If the entire subtree data- fragment filter (starting from the root to the innermost element specified in the filter) exactly matches a corresponding portion of the supported data model, then that node and all its children are included in the result data. The server processes all nodes with the same parent node (sibling set) together, starting from the root to the leaf nodes. The root elements in the filter are considered to be in the same sibling set (assuming they are in the same namespace), even though they do not have a common parent. Note the 2nd sentence in para 3, and sentence 1 of para 4. This is normative text. The agent is clearly supposed to process the filter from root to the leaves. The phrase "entire subtree" applies recursively, starting from the child nodes of . IMO, this issue is closed, without any need for an RFC Edit. Andy >> >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>> On Behalf Of Andy Bierman >>> Sent: Friday, June 09, 2006 12:22 AM >>> To: Netconf (E-mail) >>> Subject: RFC Editor edit list for approved netconf drafts >>> >>> Hi, >>> >>> Somebody asked for this edit list earlier. >>> It is available from the ID-Tracker as well. >>> >> >> Just a matter of clarification. >> The list in the tracker is the ONLY list that the RFC Editor knows. The >> documents are in the RFC Editor queue, and may progress quicker than you >> believe based upon what is available in the tracker. It is not a common >> practice to insert anything but formatting or typos fixes in AUTH48, so >> if you believe that one or more of the documents will need further >> edits, we should ask for them to be frozen, and if the changes are >> consistent we may want to generate new versions to replace the one >> currently in the queue. This needs not generate a new IESG approval >> cycle, but the IESG should be informed about the changes so that >> somebody who has any doubts about the new variant being too far from the >> one that was approved has a chance to express his/her opinions. > > > I will put together an RFC Editor note for you and the WG to > approve this weekend. > > There is a fix in the XSD related to empty > and elements (current XSD does not allow this > but it is definitely legal in NETCONF). > > The text for the subtree filter clarification is more difficult > to write, but it should be done soon. > > >> >> Dan > > Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Jun 18 12:06:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrznN-0000N4-6x for netconf-archive@lists.ietf.org; Sun, 18 Jun 2006 12:06:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrznL-0001BA-Lv for netconf-archive@lists.ietf.org; Sun, 18 Jun 2006 12:06:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrzgO-000Pa6-9Z for netconf-data@psg.com; Sun, 18 Jun 2006 15:59: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.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 1FrzgN-000PZd-MP for netconf@ops.ietf.org; Sun, 18 Jun 2006 15:59:27 +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 k5IFxIYR018233 for ; Sun, 18 Jun 2006 11:59:26 -0400 Received: (qmail 860 invoked by uid 78); 18 Jun 2006 15:59:18 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 18 Jun 2006 15:59:18 -0000 Message-ID: <44957858.4060101@andybierman.com> Date: Sun, 18 Jun 2006 08:59:20 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" , Dan Romascanu Subject: Additional RFC Editor Note for draft-ietf-netconf-prot-12 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: 1a1bf7677bfe77d8af1ebe0e91045c5b Hi, This is an important bug fix for the netconf XSD. The current definition does not allow for an empty node in 3 places, which contradicts normative text in the rest of the document. There are 4 instances of the word 'restriction', which need to be changed to the word 'extension': ------------------------------------------------------ draft-ietf-netconf-prot-12.txt, bottom of page 80: OLD: ^^^^^^^^^^^ NEW: ------------------------------------------------------ draft-ietf-netconf-prot-12.txt, bottom of page 80: OLD: ^^^^^^^^^^^ NEW: ------------------------------------------------------ draft-ietf-netconf-prot-12.txt, top of page 81: OLD: ^^^^^^^^^^^ ^^^^^^^^^^^ NEW: -- to unsubscribe send a message to netconf-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 Jun 18 14:48:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs2JW-0002cW-Mz for netconf-archive@lists.ietf.org; Sun, 18 Jun 2006 14:48:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs2JV-0006fK-D5 for netconf-archive@lists.ietf.org; Sun, 18 Jun 2006 14:48:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs2GT-0008C0-Nh for netconf-data@psg.com; Sun, 18 Jun 2006 18:44:53 +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 1FrzdX-000PQj-Pp for netconf@ops.ietf.org; Sun, 18 Jun 2006 15:56:31 +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 k5IFuUn9017537 for ; Sun, 18 Jun 2006 11:56:30 -0400 Received: (qmail 32505 invoked by uid 78); 18 Jun 2006 15:56:30 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 18 Jun 2006 15:56:30 -0000 Message-ID: <449577AF.7060401@andybierman.com> Date: Sun, 18 Jun 2006 08:56:31 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" , Dan Romascanu Subject: Additional RFC Editor Note for draft-ietf-netconf-prot-12 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: a8a20a483a84f747e56475e290ee868e Hi, This is an important bug fix for the netconf XSD. The current definition does not allow for an empty node in 3 places, which contradicts normative text in the rest of the document. There are 4 instances of the word 'restriction', which need to be changed to the word 'extension': ------------------------------------------------------ draft-ietf-netconf-prot-12.txt, bottom of page 80: OLD: ^^^^^^^^^^^ NEW: ------------------------------------------------------ draft-ietf-netconf-prot-12.txt, bottom of page 80: OLD: ^^^^^^^^^^^ NEW: ------------------------------------------------------ draft-ietf-netconf-prot-12.txt, top of page 81: OLD: ^^^^^^^^^^^ ^^^^^^^^^^^ NEW: -- to unsubscribe send a message to netconf-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 Jun 18 16:30:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs3uK-0003Pn-Ly for netconf-archive@lists.ietf.org; Sun, 18 Jun 2006 16:30:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs3uJ-0002jN-5B for netconf-archive@lists.ietf.org; Sun, 18 Jun 2006 16:30:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs3pI-000EUh-Il for netconf-data@psg.com; Sun, 18 Jun 2006 20:24:56 +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 [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs3pH-000EUS-9Y for netconf@ops.ietf.org; Sun, 18 Jun 2006 20:24:55 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 43BE444; Sun, 18 Jun 2006 22:24:54 +0200 (CEST) Date: Sun, 18 Jun 2006 22:24:53 +0200 (CEST) Message-Id: <20060618.222453.45362794.mbj@tail-f.com> To: phil@juniper.net Cc: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt From: Martin Bjorklund In-Reply-To: <200606170407.k5H47Uwn018390@idle.juniper.net> References: <200606170407.k5H47Uwn018390@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Phil Shafer wrote: > I've finally got an initial version of the draft for a netconf > capability that makes syslog data available over long-lived RPCs. I have read this well-written draft, and I have a few comments. o The parameter is defined as a regexp which must match the name of the syslog event. What is the name of a syslog event? From the examples it looks like it might be the MSGID defined in draft-ietf-syslog-protocol-17.txt? o In 3.2.1, you write The , , and parameters are only supported if the requested stream is in the "structured-data" format. Why is priority supported only for structured-data? o Is it correct to assume that a stream is fully defined by the parameters in the element? If so, should there really be a new rpc operation ? You also write that the stream definitions may be part of the configuration. Thus, shouldn't the stream definitions be available by using or instead? o You use the terms "recorded events" and "historical data". I assume they mean the same thing? o For , does it match the MSG part of a "structured-data" event, or the entire formatted event? o The examples in 3.2.2.1 are supposed to show the same events in different formats, but they are not. (nit: the 'syslog-events' element is closed prematurely in these examples (same thing for get-syslog-event in 3.2.1.2 as well)). /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 03:14:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDxr-0002YY-Qc for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 03:14:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsDxq-00055D-Dp for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 03:14:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsDsu-000NvE-Rn for netconf-data@psg.com; Mon, 19 Jun 2006 07:09: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 [83.241.162.138] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsDst-000Nuy-Rw for netconf@ops.ietf.org; Mon, 19 Jun 2006 07:09:20 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tail-f.com (Postfix) with ESMTP id 4A3C169; Mon, 19 Jun 2006 09:09:18 +0200 (CEST) Date: Mon, 19 Jun 2006 09:09:16 +0200 (CEST) Message-Id: <20060619.090916.98345398.mbj@tail-f.com> To: phil@juniper.net Cc: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt From: Martin Bjorklund In-Reply-To: <20060618.222453.45362794.mbj@tail-f.com> References: <200606170407.k5H47Uwn018390@idle.juniper.net> <20060618.222453.45362794.mbj@tail-f.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, I discussed this briefly with Andy, and it seems the in section 3.2.2 is wrong. It has to be wrapped in a element in order to be valid NETCONF. I.e. Jun 11 21:34:52 dent chassisd[2971]: CHASSISD_IFDEV_DETACH_ALL_PSEUDO: ifdev_detach(pseudo devices: all) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 06:31:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsH2D-0005eZ-22 for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 06:31:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsH2B-0002Yg-LB for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 06:31:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsGxU-000CSN-Qs for netconf-data@psg.com; Mon, 19 Jun 2006 10:26:16 +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=BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsGxT-000CS4-Fh for netconf@ops.ietf.org; Mon, 19 Jun 2006 10:26:15 +0000 Received: from [192.168.2.191] (kerr.xs4all.nl [82.93.59.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 47160E6020; Mon, 19 Jun 2006 10:26:09 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <44967BBE.6040306@isc.org> Date: Mon, 19 Jun 2006 12:26:06 +0200 From: Shane Kerr Reply-To: shane_kerr@isc.org Organization: ISC User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Phil Shafer CC: netconf Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606170407.k5H47Uwn018390@idle.juniper.net> In-Reply-To: <200606170407.k5H47Uwn018390@idle.juniper.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phil Shafer wrote: > I've finally got an initial version of the draft for a netconf > capability that makes syslog data available over long-lived RPCs. > I just sent it off to the RFC Editor, so it should show up on > ietf.org sometime this weekend, but an advance copy is available. > > http://professional.juniper.net/phil/ietf/draft-shafer-netconf-syslog-00.txt Nicely done. One concern I have is difficulty for clients to actually get historical messages without duplication. On my system here, syslog records events with second-precision. A lot can happen in a second, on a busy system. So, I get a message from syslog: Jun 19 09:38:36 r00t3r kern.warn kernel: groove is in the heart Then my NETCONF session ends (for whatever reason... number of messages, network failure, or so on). So, when my NETCONF session restarts, I can either: - - Ask for 2006-06-19T09:38:36Z, and filter out any messages that I think I have seen (I guess a client could keep a buffer with all messages from the current second). This presumes the client knows that the server won't have sub-second accuracy. - - Ask for 2006-06-19T09:38:37Z, and hope I didn't miss any messages. Plus, using time means server clock skew would cause almost unlimited confusion. :) I think it would be much nicer to assign a unique identifier to each event. I recommend an increasing number. In this case, the server would only need to output the number at the beginning of the answer (and maybe periodically also). The client knows what the last event it received is, because it increments for each one. I think still makes sense, as I can see administrators wanting to always the last 5 minutes of logs in their client when they start it (for example). - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElnu+MsfZxBO4kbQRAluTAJ9dx/vn1T/dSsY+3/XFx7LWR8V7ZACfbegZ hPtDqHxRnopvHSvAZtXXsOM= =4mtE -----END PGP SIGNATURE----- -- to unsubscribe send a message to netconf-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 Jun 19 11:28:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLgB-0004CG-Kx for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 11:28:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsLgA-0001Lw-9W for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 11:28:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsLXs-0008Qd-CS for netconf-data@psg.com; Mon, 19 Jun 2006 15:20:08 +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 1FsLXl-0008PK-VZ for netconf@ops.ietf.org; Mon, 19 Jun 2006 15:20:07 +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 k5JFJjBp020488 for ; Mon, 19 Jun 2006 11:19:51 -0400 Received: (qmail 30773 invoked by uid 78); 19 Jun 2006 15:19:41 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 19 Jun 2006 15:19:41 -0000 Message-ID: <4496C07D.6070508@andybierman.com> Date: Mon, 19 Jun 2006 08:19:25 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606170407.k5H47Uwn018390@idle.juniper.net> <20060618.222453.45362794.mbj@tail-f.com> <20060619.090916.98345398.mbj@tail-f.com> In-Reply-To: <20060619.090916.98345398.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Martin Bjorklund wrote: > Hi, > > I discussed this briefly with Andy, and it seems the in > section 3.2.2 is wrong. It has to be wrapped in a element in > order to be valid NETCONF. I.e. > > > > > > Jun 11 21:34:52 dent chassisd[2971]: > CHASSISD_IFDEV_DETACH_ALL_PSEUDO: > ifdev_detach(pseudo devices: all) > > > > > Yes -- This is a feature, not a bug. All netconf RPC requests share the same basic format: element in the netconf NS and optional parameters in the netconf NS for standard operations, and any different NS for a vendor extension All netconf RPC replies follow 1 of 2 basic formats: element in the netconf NS element in the netconf NS OR element in the netconf NS * - Zero or more elements in the netconf NS ? - Zero or one element in the netconf NS, which can contain zero or more XML elements from any namespace, or no namespace at all. Just because lots of vendor CLI commands are unorganized, I mean, ad-hoc, does not mean that IETF standards should be the same way. In a standard, consistency and interoperability are far more important than saving the 13 bytes on the wire that the element represents. > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 14:14:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsOH1-0005Jx-7H for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 14:14:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsOGz-0006nV-TZ for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 14:14:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsOCx-000LJv-6K for netconf-data@psg.com; Mon, 19 Jun 2006 18:10:43 +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 [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsOCw-000LJM-1b for netconf@ops.ietf.org; Mon, 19 Jun 2006 18:10:42 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5JIAbI27874 for ; Mon, 19 Jun 2006 14:10:37 -0400 (EDT) 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: Verbs or data model [was: Session reuse] Date: Mon, 19 Jun 2006 14:10:31 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40945F0A4@zcarhxm2.corp.nortel.com> In-Reply-To: <4492B877.9000903@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs or data model [was: Session reuse] Thread-Index: AcaRTKMIeS6B9BMITIu0FCaf/N3x5wCfejoQ From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 hi We had another one of these lists goings at one point, but I'll add on to this one since I'm too lazy to dig it up ... Pro Verbs: - some people feel verbs are more understandable - else ??? First, we are talking verbs for this particular case since I don't support the general idea that we want 345309840 different verbs. We have historically made a decision to create new netconf verbs when it made sense to do so and that is what I am suggesting we do now - Acts as a hindrance for people wishing to over-engineer the subscription data model - Acts as a hindrance for people wishing to over-engineer the subscription process - Notification subscription a common verb in other solutions - Allows for the Netconf client to be the authoritative source of the subscription - Simplifies housekeeping Pro Data Model: - some people feel if the whole of netconf is based on the idea of reading and writing=20 configuration data we should use our own mechanisms - it lets short "mixed session type" notification sessions and call-home type sessions=20 work together more easily. They can use a common data model and a single mechanism instead=20 of in-line filter definition for subscriptions and stored filters for call-home. - it is inefficient to require the notification generation and filtering parameters to be=20 passed to the agent every time - filters might be reused between sessions and different notification receivers Actually both regular notifications and the call home ones can share the same named profile if they choose to use it. I'm not sure I would expect these in the same box, but perhaps the same network. Sharon -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 15:20:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPIX-0001bW-GX for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 15:20:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPIW-0005b5-3t for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 15:20:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsPE4-000PXt-Tm for netconf-data@psg.com; Mon, 19 Jun 2006 19:15:56 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsPE2-000PXY-6m for netconf@ops.ietf.org; Mon, 19 Jun 2006 19:15:54 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5JJFrPt019611 for ; Mon, 19 Jun 2006 15:15:53 -0400 Received: (qmail 5114 invoked by uid 78); 19 Jun 2006 19:15:52 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 19 Jun 2006 19:15:52 -0000 Message-ID: <4496F7E1.8030204@andybierman.com> Date: Mon, 19 Jun 2006 12:15:45 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Verbs or data model [was: Session reuse] References: <713043CE8B8E1348AF3C546DBE02C1B40945F0A4@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40945F0A4@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Sharon Chisholm wrote: > hi > > We had another one of these lists goings at one point, but I'll add on > to this one since I'm too lazy to dig it up ... > > > Pro Verbs: > - some people feel verbs are more understandable > - else ??? > > > First, we are talking verbs for this particular case since I don't > support the general idea that we want 345309840 different verbs. We have > historically made a decision to create new netconf verbs when it made > sense to do so and that is what I am suggesting we do now > > - Acts as a hindrance for people wishing to over-engineer the > subscription data model > - Acts as a hindrance for people wishing to over-engineer the > subscription process > - Notification subscription a common verb in other solutions > - Allows for the Netconf client to be the authoritative source of the > subscription > - Simplifies housekeeping Please explain in more detail. How are these goals achieved with these new RPCs in question? Some people (including myself) believe that passing all of the notification delivery parameters each time the session restarts is inefficient and bad SW design. - It also forces the manager to store all the parameters for every device, instead of giving them the option to use agent NV-stored data. - It forces all the NMS apps to share or duplicate this data, instead of having the option of storing it on the agent. - It forces the NMS and agent to replicate filter expressions instead of allowing them to be shared across applications, sessions, or even subscriptions. I think a solution which does not allow for agent NV-stored config for something this basic is deficient. The netconf solution for NV-stored config is + data model. (+ , , , , , etc.) IMO, new RPCs which in any way are intended to manipulate non-existent "pseudo data models", to avoid using all the existing operations which support NV-stored data models, is a poor design choice. Andy > > > Pro Data Model: > - some people feel if the whole of netconf is based on the idea of > reading and writing > configuration data we should use our own mechanisms > - it lets short "mixed session type" notification sessions and call-home > type sessions > work together more easily. They can use a common data model and a single > mechanism instead > of in-line filter definition for subscriptions and stored filters for > call-home. > - it is inefficient to require the notification generation and filtering > parameters to be > passed to the agent every time > - filters might be reused between sessions and different notification > receivers > > > > Actually both regular notifications and the call home ones can share the > same named profile if they choose to use it. I'm not sure I would expect > these in the same box, but perhaps the same network. > > Sharon > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 16:12:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQ6Y-0006qf-Av for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:12:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQ6W-0005kB-Ur for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:12:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQ3f-0004T5-H9 for netconf-data@psg.com; Mon, 19 Jun 2006 20:09:15 +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 [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQ3e-0004So-Gb for netconf@ops.ietf.org; Mon, 19 Jun 2006 20:09:14 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5JK9Bh14624 for ; Mon, 19 Jun 2006 16:09:11 -0400 (EDT) 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: Verbs or data model [was: Session reuse] Date: Mon, 19 Jun 2006 16:09:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4094F4C93@zcarhxm2.corp.nortel.com> In-Reply-To: <4496F7E1.8030204@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs or data model [was: Session reuse] Thread-Index: AcaT1NdY+JZntq20SS20PQx+FER3RwABotWw From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Some people (including myself) believe that passing all of the notification delivery parameters each time the session restarts is inefficient and bad SW design. - It also forces the manager to store all the parameters for every device, instead of giving them the option to use agent NV-stored data. - It forces all the NMS apps to share or duplicate this data, instead of having the option of storing it on the agent. Two points on that: 1) I need to store a copy of my desired notification subscription anyways because if configuration doesn't exist I need to create it. 2) I am likely to be asking for the same information from all of my devices. If they are stored on the device I then need to change them on all of the devices. Much more work have to update those and then worry about whether some other fool has the subscription configuration locked or will step on my changes later on. - It forces the NMS and agent to replicate filter expressions instead of allowing them to be shared across applications, sessions, or even subscriptions. You can use named profiles if you want to. Sharon -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 16:12:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQ6k-0006yK-Id for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:12:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQ6j-0005lX-9i for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:12:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQ36-0004Qz-Fi for netconf-data@psg.com; Mon, 19 Jun 2006 20:08:40 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQ35-0004Ql-Jh for netconf@ops.ietf.org; Mon, 19 Jun 2006 20:08:40 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5JK8ctF018869 for ; Mon, 19 Jun 2006 16:08:39 -0400 Received: (qmail 30511 invoked by uid 78); 19 Jun 2006 20:08:38 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 19 Jun 2006 20:08:38 -0000 Message-ID: <4497043F.9060106@andybierman.com> Date: Mon, 19 Jun 2006 13:08:31 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: NETCONF WG Interim Meeting Update Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi, The hotel has agreed to waive their usual (non-trivial) fee for wireless Internet service at the Montreal interim meeting, because we are with the IETF. So, contrary to previous announcements, there should be free wireless Internet access during the meeting. In addition, coffee/snack breaks will be provided on Friday and Saturday. A continental breakfast will also be provided Saturday morning. (Lunch on Saturday is not provided.) 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 Mon Jun 19 16:36:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQSf-0005lh-UD for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:35:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQQZ-0008KA-Ag for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:32:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQMc-0005st-TJ for netconf-data@psg.com; Mon, 19 Jun 2006 20:28:50 +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 1FsQMa-0005sQ-FL for netconf@ops.ietf.org; Mon, 19 Jun 2006 20:28:48 +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 k5JKSk1Z085789; Mon, 19 Jun 2006 13:28:46 -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 k5JKSk578156; Mon, 19 Jun 2006 13:28:46 -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 k5JKSjwn030954; Mon, 19 Jun 2006 16:28:45 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606192028.k5JKSjwn030954@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Mon, 19 Jun 2006 08:19:25 PDT." <4496C07D.6070508@andybierman.com> Date: Mon, 19 Jun 2006 16:28:45 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Andy Bierman writes: > element in the netconf NS > * - Zero or more elements in the netconf NS > ? - Zero or one element in the netconf NS, which > can contain zero or more XML elements from any namespace, > or no namespace at all. > The text in netconf-prot does not constrain the top level element of the reply, nor does it mandate that it be under a element. The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. Unfortunately, the xml schema does constain the reply to . So the question is: can we correct the schema? > >In a standard, consistency and interoperability are far more >important than saving the 13 bytes on the wire that the >element represents. I fail to see how the existence of the element does anything to improve consistency or interoperability. It's just a noise word that we'll be stuck putting in rpc replies, xpath expressions and sax filters for the rest of our lives, unless we can fix it now. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 16:54:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQlp-0002Ek-DW for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:54:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQlp-0007lA-4T for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 16:54:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQX9-0006eI-T0 for netconf-data@psg.com; Mon, 19 Jun 2006 20:39:43 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQX9-0006e6-Cy for netconf@ops.ietf.org; Mon, 19 Jun 2006 20:39:43 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5JKdeX77663; Mon, 19 Jun 2006 13:39:42 -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 k5JKdY580591; Mon, 19 Jun 2006 13:39:35 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k5JKdUwn031075; Mon, 19 Jun 2006 16:39:34 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606192039.k5JKdUwn031075@idle.juniper.net> To: shane_kerr@isc.org cc: netconf Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Mon, 19 Jun 2006 12:26:06 +0200." <44967BBE.6040306@isc.org> Date: Mon, 19 Jun 2006 16:39:30 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Shane Kerr writes: >Nicely done. One concern I have is difficulty for clients to actually >get historical messages without duplication. The doesn't really give a duplication-free guarantee, but one can increase the resolution of the log files (we optionally add milliseconds) to reduce the duplication. >Plus, using time means server clock skew would cause almost unlimited >confusion. :) The value for will most likely be the timestamp of the last message received from the server, assuming a connection failure. In this case, the timestamp will be assigned by the server and it will be interpreted by the server, so clock skew shouldn't matter. >I think it would be much nicer to assign a unique identifier to each >event. I recommend an increasing number. In this case, the server would >only need to output the number at the beginning of the answer (and maybe >periodically also). The client knows what the last event it received is, >because it increments for each one. A sequence number will interfere with filtering, since the client won't see monotonically increasing numbers, as messages will be dropped. It also introduces a number of complex issues that go against my KISS attitude, such as the lifespan of the sequence, sequences for multiple streams, and the interaction for messages that match multiple streams. Not unsolvable, but not a priority. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 17:02:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQt6-0005iP-L2 for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 17:02:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQt5-00008y-7g for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 17:02:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsQpg-00085E-3O for netconf-data@psg.com; Mon, 19 Jun 2006 20:58:52 +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 1FsQpf-000852-CY for netconf@ops.ietf.org; Mon, 19 Jun 2006 20:58:51 +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 k5JKwo1Z086163; Mon, 19 Jun 2006 13:58:51 -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 k5JKwo584942; Mon, 19 Jun 2006 13:58:50 -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 k5JKwown031172; Mon, 19 Jun 2006 16:58:50 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606192058.k5JKwown031172@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Sun, 18 Jun 2006 22:24:53 +0200." <20060618.222453.45362794.mbj@tail-f.com> Date: Mon, 19 Jun 2006 16:58:50 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Martin Bjorklund writes: > From the examples it looks like it might be the MSGID defined in > draft-ietf-syslog-protocol-17.txt? Yes, that's it. I would have used the same term, but "msgid" sounded particular to the message instance (like sequence id). I used event name instead, but this is probably just needlessly confusing. > Why is priority supported only for structured-data? Traditional syslog daemons don't record these fields, so they can't be supported on recorded data. It seemed too fine a line, so I widened it a bit. > o Is it correct to assume that a stream is fully defined by the > parameters in the element? If so, should there really > be a new rpc operation ? You also write that > the stream definitions may be part of the configuration. Thus, > shouldn't the stream definitions be available by using or > instead? The stream definition may not be configuration, since the device may be preconfigured with certain streams or have default streams. I shy away from the generic , well, it's too generic. If I want to add search criteria or fancy options to the RPC, it's less of a pain if I've got a specific method to enhance. Also, I'm a big fan of the way netconf allows for the definition of new RPCs, so we can use more specific queries that do exactly what we want, allowing us to expose APIs that looks like: $device->get_syslog_streams(); instead of: #device->get("data/logs/filtered/syslog/streams"); > o You use the terms "recorded events" and "historical data". I > assume they mean the same thing? Yup, I wasn't happy with either term, but I should have settled on one of the other. > o For , does it match the MSG part of a > "structured-data" event, or the entire formatted event? Yes, it matches the MSG part: contains a regular expression (as defined by IEEE Std 1003.2/POSIX.2 [5]) which the message of the SYSLOG must match. Any event whose message string matches this expression is carried in the stream. Both 3164 and syslog-protocol call their message payload "MSG", so I guess I could s/the message/the MSG part/, but it seems less clear. > o The examples in 3.2.2.1 are supposed to show the same events in > different formats, but they are not. (nit: the 'syslog-events' > element is closed prematurely in these examples (same thing for > get-syslog-event in 3.2.1.2 as well)). Yup, I'll fix that. I couldn't find the first set on SD format. The second error was a cut-n-paste thing. Thanks for spotting these. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 19 17:17:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsR7Y-0005tc-0C for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 17:17:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsR7W-0001AO-Lj for netconf-archive@lists.ietf.org; Mon, 19 Jun 2006 17:17:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsR4Z-00099m-O2 for netconf-data@psg.com; Mon, 19 Jun 2006 21:14:15 +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 1FsR4Y-00099Z-Vu for netconf@ops.ietf.org; Mon, 19 Jun 2006 21:14:15 +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 k5JLEDBM017911 for ; Mon, 19 Jun 2006 17:14:14 -0400 Received: (qmail 2582 invoked by uid 78); 19 Jun 2006 21:14:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 19 Jun 2006 21:14:13 -0000 Message-ID: <4497139E.5080005@andybierman.com> Date: Mon, 19 Jun 2006 14:14:06 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606192028.k5JKSjwn030954@idle.juniper.net> In-Reply-To: <200606192028.k5JKSjwn030954@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Phil Shafer wrote: > Andy Bierman writes: >> element in the netconf NS >> * - Zero or more elements in the netconf NS >> ? - Zero or one element in the netconf NS, which >> can contain zero or more XML elements from any namespace, >> or no namespace at all. >> > > The text in netconf-prot does not constrain the top level element > of the reply, nor does it mandate that it be under a element. > > The response name and response data are encoded as the contents of > the element. The name of the reply is an element > directly inside the element, and any data is encoded > inside this element. > > Unfortunately, the xml schema does constain the reply to . > So the question is: can we correct the schema? > >> >> In a standard, consistency and interoperability are far more >> important than saving the 13 bytes on the wire that the >> element represents. > > > I fail to see how the existence of the element does anything > to improve consistency or interoperability. It's just a noise word > that we'll be stuck putting in rpc replies, xpath expressions and > sax filters for the rest of our lives, unless we can fix it now. > I disagree. It allows generic tools a consistent format to work with, instead of a different ad-hoc format for every RPC. If the reply does not contain 0 - N , followed by 1 optional , then SW to pre-process the replies before the application gets it is much more complicated. It has to understand every schema instead of just the netconf schema, just to validate the "RPC layer" portion of the reply. Currently, we have a consistent way to say "your request yielded no data": This would be lost if the XSD were changed. I don't want to give vendors an opportunity to ignore the standard requirements. Allowing the to contain 'anything' will do that. > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 05:25:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FscTk-0007J2-6p for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 05:25:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FscTi-0006gO-P5 for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 05:25:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FscKV-0000Iq-7o for netconf-data@psg.com; Tue, 20 Jun 2006 09:15: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FscKU-0000Id-Ao for netconf@ops.ietf.org; Tue, 20 Jun 2006 09:15:26 +0000 Received: from [192.168.2.191] (kerr.xs4all.nl [82.93.59.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id B108DE601F; Tue, 20 Jun 2006 09:15:19 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <4497BCA5.1030001@isc.org> Date: Tue, 20 Jun 2006 11:15:17 +0200 From: Shane Kerr Reply-To: shane_kerr@isc.org Organization: ISC User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Phil Shafer CC: netconf Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606192039.k5JKdUwn031075@idle.juniper.net> In-Reply-To: <200606192039.k5JKdUwn031075@idle.juniper.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phil Shafer wrote: > Shane Kerr writes: >> Nicely done. One concern I have is difficulty for clients to actually >> get historical messages without duplication. > > The doesn't really give a duplication-free guarantee, > but one can increase the resolution of the log files (we optionally > add milliseconds) to reduce the duplication. I was hoping to allow a way for a client to: 1. Not lose log messages. 2. Not get duplicate log messages. The client has no way to know what the resolution on the server is. The only way I can think of for the client to remove duplicate messages is to store all of the messages down to the resolution of the time. So, if there is a 1-second resolution, the client would have to store all of the messages that arrived in the same second as the last message. That is: 2006-06-20T10:55:27 msg1 2006-06-20T10:55:27 msg2 2006-06-20T10:55:27 msg3 If the client disconnects and reconnects to the server, then selects a 2006-06-20T10:55:27, it would get all of these again, and discard them as already seen. But it would *need* to pick that time, in case a 4th message arrived that it did not want to miss. (Minor issue here that the server must re-send these messages, but I consider this will be a rare occurrence.) Whether the resolution is 1-second or 0.1-second, the process is the same. A client could attempt to minimize the buffer size by figuring out the resolution of the time on the server. (For instance, by remembering the smallest non-zero time difference between two events.) It seems like a lot of work, for what I think is a reasonable set of goals, which is why I suggested the addition/change. >> Plus, using time means server clock skew would cause almost unlimited >> confusion. :) > > The value for will most likely be the timestamp of the > last message received from the server, assuming a connection failure. > In this case, the timestamp will be assigned by the server and it > will be interpreted by the server, so clock skew shouldn't matter. My mistake. I should not have said "skew". I meant if the server jumps the time forward or backwards. >> I think it would be much nicer to assign a unique identifier to each >> event. I recommend an increasing number. In this case, the server would >> only need to output the number at the beginning of the answer (and maybe >> periodically also). The client knows what the last event it received is, >> because it increments for each one. > > A sequence number will interfere with filtering, since the client > won't see monotonically increasing numbers, as messages will be > dropped. It also introduces a number of complex issues that go > against my KISS attitude, such as the lifespan of the sequence, > sequences for multiple streams, and the interaction for messages > that match multiple streams. Not unsolvable, but not a priority. True, filtering complicates things a bit, as do multiple streams. You're probably right that it is a bit too complicated for the gain, and a small buffer on the client is the way to go if one cares. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEl7ykMsfZxBO4kbQRAqODAJwIeRzGXIKRYnU4EaoyRxCzNRfsaQCgnmWK NJ5iQtTkAAKLQUhU/tUXQNk= =cYrT -----END PGP SIGNATURE----- -- to unsubscribe send a message to netconf-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 Jun 20 07:37:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FseXn-0007WR-CN for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 07:37:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FseXm-0004vK-2f for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 07:37:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FseSH-0008y9-6Q for netconf-data@psg.com; Tue, 20 Jun 2006 11:31:37 +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, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FseSF-0008xv-TR for netconf@ops.ietf.org; Tue, 20 Jun 2006 11:31:36 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id C1FE727C065; Tue, 20 Jun 2006 13:28:10 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14894-02; Tue, 20 Jun 2006 13:28:10 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 8814727C061; Tue, 20 Jun 2006 13:28:10 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:31:29 +0200 Content-class: urn:content-classes:message Subject: RE: draft-shafer-netconf-syslog-00.txt Date: Tue, 20 Jun 2006 13:31:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174970@grfint2.intern.adiscon.com> In-Reply-To: <200606192039.k5JKdUwn031075@idle.juniper.net> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaT4Zy2YynJVO8+QJiPYiM+XGElKwAeqKUw From: "Rainer Gerhards" To: "Phil Shafer" , Cc: "netconf" X-OriginalArrivalTime: 20 Jun 2006 11:31:29.0952 (UTC) FILETIME=[13130200:01C6945D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Phil, congrats to this good draft. I've just reviewed it from the syslog guy's perspective. I will provide some thoughts to the currently ongoing discussions and then provide a summary from the syslog perspective. I am a lurker on this list, so I might misstate some netconf-related issues, but I have tried to focus on syslog as much as possible. > Shane Kerr writes: > >Nicely done. One concern I have is difficulty for clients to actually > >get historical messages without duplication. >=20 > The doesn't really give a duplication-free guarantee, > but one can increase the resolution of the log files (we optionally > add milliseconds) to reduce the duplication. The timestamp syslog-protocol allows for microsecond resolution. So refering to it should be sufficient. It might be a good idea to request implementations of netconf syslog receivers to support microsecond resolution, which is optional in syslog. Rainer -- to unsubscribe send a message to netconf-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 Jun 20 07:41:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsecD-0001p2-5C for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 07:41:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsecB-00053m-KH for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 07:41:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FseVu-0009Cn-Ha for netconf-data@psg.com; Tue, 20 Jun 2006 11:35:22 +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 [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FseVt-0009CQ-Fl for netconf@ops.ietf.org; Tue, 20 Jun 2006 11:35:21 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5KBZI716500 for ; Tue, 20 Jun 2006 07:35:18 -0400 (EDT) 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: Verbs or data model [was: Session reuse] Date: Tue, 20 Jun 2006 07:35:14 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4094F501B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4094F4C93@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs or data model [was: Session reuse] Thread-Index: AcaT1NdY+JZntq20SS20PQx+FER3RwABotWwACAuqxA= From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 hi I was driving home last night thinking about how of all the notification receiver applications I've worked on over the years only one attempted to perform automatic notification subscription. In thinking about why this was, aside from the complexity issue which I've already discussed, there is the support issue. Not all devices supported the MIB in SNMP. You could argue again that this was the complexity issue, but I think it also goes to the fact when we delegate everything to the data model, implementations have a difficult time figuring out which are the important bits to support or else start to support a proprietary chunk of data model which they think is better/simpler/cooler instead. I think this deviation is more obvious with verbs, assuming of course we have a finite number of them. So, verbs signal that this 'thing' is important so you should support it and support it exactly this way. It's good for interoperability. I am hoping there are other ways to solve this as well, since I am sure there will be key bits of data model we will want people to support. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon [CAR:ZZ00:EXCH] Sent: Monday, June 19, 2006 4:09 PM To: Netconf (E-mail) Subject: RE: Verbs or data model [was: Session reuse] Some people (including myself) believe that passing all of the notification delivery parameters each time the session restarts is inefficient and bad SW design. - It also forces the manager to store all the parameters for every device, instead of giving them the option to use agent NV-stored data. - It forces all the NMS apps to share or duplicate this data, instead of having the option of storing it on the agent. Two points on that: 1) I need to store a copy of my desired notification subscription anyways because if configuration doesn't exist I need to create it. 2) I am likely to be asking for the same information from all of my devices. If they are stored on the device I then need to change them on all of the devices. Much more work have to update those and then worry about whether some other fool has the subscription configuration locked or will step on my changes later on. - It forces the NMS and agent to replicate filter expressions instead of allowing them to be shared across applications, sessions, or even subscriptions. You can use named profiles if you want to. Sharon -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 07:50:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsekQ-0006T3-Bj for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 07:50:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsekO-0005sU-Un for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 07:50:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsedp-0009lv-8r for netconf-data@psg.com; Tue, 20 Jun 2006 11:43:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsedn-0009le-R4 for netconf@ops.ietf.org; Tue, 20 Jun 2006 11:43:32 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DFA4F27C066; Tue, 20 Jun 2006 13:40:10 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14894-05; Tue, 20 Jun 2006 13:40:10 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9937127C061; Tue, 20 Jun 2006 13:40:10 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:43:25 +0200 Content-class: urn:content-classes:message Subject: RE: draft-shafer-netconf-syslog-00.txt Date: Tue, 20 Jun 2006 13:43:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174971@grfint2.intern.adiscon.com> In-Reply-To: <200606192058.k5JKwown031172@idle.juniper.net> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaT4+xKgodHutyuT8CVojabSjgtPQAeV/aQ From: "Rainer Gerhards" To: "Phil Shafer" , "Martin Bjorklund" Cc: X-OriginalArrivalTime: 20 Jun 2006 11:43:25.0553 (UTC) FILETIME=[BD9B0E10:01C6945E] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Monday, June 19, 2006 10:59 PM > To: Martin Bjorklund > Cc: netconf@ops.ietf.org > Subject: Re: draft-shafer-netconf-syslog-00.txt=20 >=20 > Martin Bjorklund writes: > > From the examples it looks like it might be the MSGID defined in > > draft-ietf-syslog-protocol-17.txt? >=20 > Yes, that's it. I would have used the same term, but "msgid" sounded > particular to the message instance (like sequence id). I used event > name instead, but this is probably just needlessly confusing. I would prefer to stick with the same terminology as in syslog, because using different terms for the same things indeed confuse. >=20 > > Why is priority supported only for structured-data? =20 >=20 > Traditional syslog daemons don't record these fields, so they > can't be supported on recorded data. It seemed too fine a line, > so I widened it a bit. Actually, PRI is the only thing that is consistently recorded. It is defined in 4.1.1 in RFC 3164. In the (rare) case where it is absent, there are rules outlined in RFC 3164. Traditional syslogds filter exclusively on PRI. So I strongly suggest to support it for both formats. For a discussion on syslog format in the wild, please see: http://www.syslog.cc/ietf/existing-syslog.html [snip] > > o For , does it match the MSG part of a > > "structured-data" event, or the entire formatted event? >=20 > Yes, it matches the MSG part: >=20 > contains a regular expression (as defined=20 > by IEEE Std > 1003.2/POSIX.2 [5]) which the message of the SYSLOG must=20 > match. Any > event whose message string matches this expression is=20 > carried in the > stream. >=20 > Both 3164 and syslog-protocol call their message payload "MSG", so I > guess I could s/the message/the MSG part/, but it seems less clear. I strongly suggest to identify the field by calling it "MSG". The reason is that in RFC 3164 and syslog-protocol, the term "message" is defined as the complete syslog message, that is HEADER, [STRUCTURED-DATA], and MSG (e.g. in 6. of syslog-protocol-17). Rainer -- to unsubscribe send a message to netconf-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 Jun 20 08:44:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfbH-0003UP-Pp for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 08:44:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsfbH-0002OK-9q for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 08:44:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsfVj-000DMI-4P for netconf-data@psg.com; Tue, 20 Jun 2006 12:39:15 +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, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsfVh-000DLk-Si for netconf@ops.ietf.org; Tue, 20 Jun 2006 12:39:14 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id AC80327C065; Tue, 20 Jun 2006 14:35:52 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16984-01; Tue, 20 Jun 2006 14:35:52 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4985827C061; Tue, 20 Jun 2006 14:35:52 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:39:10 +0200 Content-class: urn:content-classes:message Subject: RE: draft-shafer-netconf-syslog-00.txt Date: Tue, 20 Jun 2006 14:39:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174973@grfint2.intern.adiscon.com> In-Reply-To: <200606170407.k5H47Uwn018390@idle.juniper.net> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaRxMJrD5azoL0hT82pDPoA1gdZ3QCmvrRw From: "Rainer Gerhards" To: "Phil Shafer" , "netconf" Cc: X-OriginalArrivalTime: 20 Jun 2006 12:39:10.0835 (UTC) FILETIME=[878C9430:01C69466] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Phil, as promised, I have gone through the netconf-syslog draft from the syslog guy's perspective. I think netconf-syslog is a very useful addition to the syslog community, too. I am cross-posting my message to the syslog WG. The most important thing that strikes me is terminology. Even though syslog terminology might not be familiar (or sound even strange) to the NETCONF WG, I think the draft should stick with it. The reason is that otherwise you will create confusion. One sample already under discussion: In you specify "the message". As a syslog-guy, I would apply the regex to the message as whole and not just the MSG part. Thus, I would find a match e.g. in STRUCTURED-DATA. This is a very natural approach for someone who implements syslog. Using the same terms also eases the work for the implementor. From my understanding, the server to support netconf-syslog must support both netconf as well as syslog. It is quite confusing in code if the thing the syslog code side e.g. calls "severity" becomes "level" as soon as another part of the same code is called. In syslog-protocol, we tried hard to use the most common terms for new header fields. Unfortunately, syslog has a lot a variance, but I think we actually managed to find quite good terms. So I suggest the following term changes: netconf-syslog syslog priority PRI level severity process PROCID event MSGID text MSG (because it works on the MSG field) I also suggest to add APP-NAME as a filter in netconf-syslog. Adding TAG (from RFC 3164 & 3195) will also be useful. Some things of more substance: In syslog-protocol, we have introduced the VERSION field. It denotes the version of syslog-rptocol message format of the message. It deliberately starts at 1 and increases monotonically (if considerable changed new versions of syslog should be specified). I suggest that in netconf-syslog is replaced by , where zero denotes RFC 3164/3195 format and non-zero denotes a version according to syslog-protocol. This also facilitates parsing the actual syslog message on the receiving netconf syslog parser. I suggest to rename it to STRUCTURED-DATA. I understand that the format is quite different from the actual syslog STRUCTURED-DATA format. But it filters on the STURUCTURED-DATA field. This is the same principle I applied above for text/MSG. I think it would be consistent to call the filter properties like the fields they operate on. Names for severity and facility RFC 3164 and syslog-protocol both list names (e.g. "authorization" and "emergency") as well as integer numbers for PRI contents. However, only the integers are normative (see ABNF in syslog-protocol, PRI description in RFC 3164). It has also been observed in practice that the names are not without ambiguity. So I strongly suggest to use the integer values only in netconf-syslog filters. If there is no consensus on this, I propose to support both the names as well as the numbers. Remotly Received Events=20 From my understanding of netconf-syslog, a netconf-syslog server supports forwarding via netconf both locally generated syslog messages as well remotely received ones. I think the ability to process remotely received messages is a vital asset. It enables a netconf-syslog server to act as a hub/gateway to a number of netconf-unaware syslog clients. To fully support remote syslog clients, a HOSTNAME filter is needed. That would be a (regex?) filter on the hostname. Similar filters are widely deployed on syslogds in practice today. When multiple host message may be present in a single netconf-syslog stream, it might also be that different VERSIONS of the syslog protocol be present in a single stream. The syslog WG expects this to be a frequent scenario once syslog-protocol is finished. syslog-protocol already contains an identification for this (via the VERSION fields) as well as some specifics on transforming RFC 3164 syslog in a syslog-protocol receiver (A.1 in syslog-protocol-17). I suggest that netconf-syslog supports the same. Finally one small correction. On page 4 of netconf-syslog (at the top) it states: "The SYSLOG protocol lacks security and reliability." This is not true. There is RFC 3195 (syslog over BEEP) which supports security and reliability. 3195 is currently only weakly accepted, but there as some implementations of it. I suggest a reference is made to 3195 to clarify on that issue (and so that a casual reader will become aware that there is more to look at then 3164 and syslog-protocol). I hope these comments are useful. Best regards, Rainer Gerhards > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Saturday, June 17, 2006 6:08 AM > To: netconf > Subject: draft-shafer-netconf-syslog-00.txt >=20 > I've finally got an initial version of the draft for a netconf > capability that makes syslog data available over long-lived RPCs. > I just sent it off to the RFC Editor, so it should show up on > ietf.org sometime this weekend, but an advance copy is available. >=20 > http://professional.juniper.net/phil/ietf/draft-shafer-netconf > -syslog-00.txt >=20 > Thanks, > Phil >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 11:39:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsiKU-0004kT-76 for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 11:39:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsiKR-0006Ou-LZ for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 11:39:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsiFB-000POu-4p for netconf-data@psg.com; Tue, 20 Jun 2006 15:34:21 +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=BAYES_00 autolearn=ham version=3.1.1 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsiF9-000POe-AI for netconf@ops.ietf.org; Tue, 20 Jun 2006 15:34:19 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A237B670A8; Tue, 20 Jun 2006 17:34:17 +0200 (CEST) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id 0B6A4670DD; Tue, 20 Jun 2006 17:33:58 +0200 (CEST) Message-ID: <44981592.5080906@loria.fr> Date: Tue, 20 Jun 2006 17:34:42 +0200 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Phil Shafer , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606170407.k5H47Uwn018390@idle.juniper.net> In-Reply-To: <200606170407.k5H47Uwn018390@idle.juniper.net> Content-Type: multipart/mixed; boundary="------------090007060608020504020800" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 This is a multi-part message in MIME format. --------------090007060608020504020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Phil Shafer a écrit : > I've finally got an initial version of the draft for a netconf > capability that makes syslog data available over long-lived RPCs. > I just sent it off to the RFC Editor, so it should show up on > ietf.org sometime this weekend, but an advance copy is available. > > http://professional.juniper.net/phil/ietf/draft-shafer-netconf-syslog-00.txt > A few comments and questions: I don't really understand the design choice of the get-syslog-streams operation because I think it breaks the idea of the get-config operation. IMHO, even if it is feasible and allowed by Netconf, nothing here justifies the need of a new operation. Wouldn't it be more conform to Netconf to define a short data model for syslog streams and use the regular get-config with a selection node ? The reply would be exactly the same as the one you described in the draft (except the element of course). For the second part 3.2, I am confused. What happens if I send a get-syslog-events with a stop-time one hour later ? Can I still use this Netconf session to send other RPC during this time ? I guess no. The Netconf session would be locked for a long period of time. If I understand well, this approach assumes that the agent is parsing the XML data stream on the fly (like with SAX, but not DOM). Because the rpc-reply does not seem to be closed until a stop condition happens and DOM can not read a partial document. If this is the case, must the agent assume that the rpc-reply message will be valid before it received the whole message ? And process it ? Regards, Vincent > 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: > --------------090007060608020504020800 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------090007060608020504020800-- -- to unsubscribe send a message to netconf-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 Jun 20 12:26:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsj3E-0007il-6J for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:26:04 -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 1Fsj3E-0003XC-50 for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:26:04 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fsj0K-0001Cl-U0 for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:23:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsiwP-0002Zo-Az for netconf-data@psg.com; Tue, 20 Jun 2006 16:19:01 +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 1FsiwO-0002Za-HA for netconf@ops.ietf.org; Tue, 20 Jun 2006 16:19:00 +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 k5KGIw1Z001452; Tue, 20 Jun 2006 09:18:58 -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 k5KGIv536946; Tue, 20 Jun 2006 09:18:57 -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 k5KGIvwn034000; Tue, 20 Jun 2006 12:18:57 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606201618.k5KGIvwn034000@idle.juniper.net> To: Vincent Cridlig cc: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Tue, 20 Jun 2006 17:34:42 +0200." <44981592.5080906@loria.fr> Date: Tue, 20 Jun 2006 12:18:57 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Vincent Cridlig writes: >I don't really understand the design choice of the get-syslog-streams >operation because I think it breaks the idea of the get-config operation. Syslog stream definitions are not limited to configuration, since the device may define default streams. >Wouldn't it be more conform to Netconf to define a short data model for >syslog streams and use the regular get-config with a selection node ? I'm not prepared to be the first lamb on that altar. ;^) >For the second part 3.2, I am confused. What happens if I send a >get-syslog-events with a stop-time one hour later ? Can I still use this >Netconf session to send other RPC during this time ? I guess no. The >Netconf session would be locked for a long period of time. Yup, exactly. >If I understand well, this approach assumes that the agent is parsing >the XML data stream on the fly (like with SAX, but not DOM). Because the >rpc-reply does not seem to be closed until a stop condition happens and >DOM can not read a partial document. If this is the case, must the agent >assume that the rpc-reply message will be valid before it received the >whole message ? And process it ? Yes, if you are looking for a real-time stream, you'll need to use a technology that allows you to parse it as it arrives. SAX is perfect for this, giving you callbacks to drive a simple state machine. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 12:33:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjAM-0005We-Ec for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:33:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsjAL-0003wh-1G for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:33:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsj79-0003M7-BZ for netconf-data@psg.com; Tue, 20 Jun 2006 16:30: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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsj78-0003Lr-8g for netconf@ops.ietf.org; Tue, 20 Jun 2006 16:30:06 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5KGU5JW023704 for ; Tue, 20 Jun 2006 12:30:05 -0400 Received: (qmail 3289 invoked by uid 78); 20 Jun 2006 16:30:05 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 20 Jun 2006 16:30:05 -0000 Message-ID: <44982284.6080007@andybierman.com> Date: Tue, 20 Jun 2006 09:29:56 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Vincent Cridlig CC: Phil Shafer , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606170407.k5H47Uwn018390@idle.juniper.net> <44981592.5080906@loria.fr> In-Reply-To: <44981592.5080906@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 >.. >> > A few comments and questions: > > I don't really understand the design choice of the get-syslog-streams > operation because I think it breaks the idea of the get-config operation. > IMHO, even if it is feasible and allowed by Netconf, nothing here > justifies the need of a new operation. > > ... I agree with you. I don't understand how specialized functions for standard data really helps here. It sure can't be because there are so many standard data models for netconf that specialized functions help us navigate the vast quantity and complexity of this data. I also don't understand the obsession with calling everything "subscription data" instead of "configuration data", and insisting that NV-storing this subscription data is not important, not useful, or not "simple enough" for the manager to use. IMO, this problem is pretty simple: * Use configuration data and standard existing RPCs to set and get the notification generation parameters, what has been called a "profile" and now called a "stream" * Use a special RPC to start generation of notifications, which has a parameter to indicate the stored profile to use. * Some parameters like "retrieve since time N" are session-specific, and belong only in the RPC, not the config (obviously). Some parameters like "get me the next 3804 notifications" seem pretty complicated and not very useful. I prefer only 1 mode: - get since time N (or sequence-id X) and keep going until the session is shut down > Regards, > Vincent > > >> Thanks, >> Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 12:33:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjAW-0005aS-8R for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:33:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsjAU-0003x3-Rz for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:33:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsj7V-0003Oo-KQ for netconf-data@psg.com; Tue, 20 Jun 2006 16:30: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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsj7U-0003O5-QX for netconf@ops.ietf.org; Tue, 20 Jun 2006 16:30:28 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5KGUPX97644; Tue, 20 Jun 2006 09:30:25 -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 k5KGUK539436; Tue, 20 Jun 2006 09:30:20 -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 k5KGUJwn034065; Tue, 20 Jun 2006 12:30:19 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606201630.k5KGUJwn034065@idle.juniper.net> To: "Rainer Gerhards" cc: "netconf" , syslog@ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Tue, 20 Jun 2006 14:39:15 +0200." <577465F99B41C842AAFBE9ED71E70ABA174973@grfint2.intern.adiscon.com> Date: Tue, 20 Jun 2006 12:30:19 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 "Rainer Gerhards" writes: >as promised, I have gone through the netconf-syslog draft from the >syslog guy's perspective. I think netconf-syslog is a very useful >addition to the syslog community, too. I am cross-posting my message to >the syslog WG. Truly appreciate your comments, especially the terminology ones. I'll update the draft with these next week. >RFC 3164 and syslog-protocol both list names (e.g. "authorization" and >"emergency") as well as integer numbers for PRI contents. However, only >the integers are normative (see ABNF in syslog-protocol, PRI description >in RFC 3164). It has also been observed in practice that the names are >not without ambiguity. So I strongly suggest to use the integer values >only in netconf-syslog filters. If there is no consensus on this, I >propose to support both the names as well as the numbers. I strongly dislike using numbers, but if there's consensus to use them, I'll survive. >Remotly Received Events >From my understanding of netconf-syslog, a netconf-syslog server >supports forwarding via netconf both locally generated syslog messages >as well remotely received ones. I think the ability to process remotely >received messages is a vital asset. It enables a netconf-syslog server >to act as a hub/gateway to a number of netconf-unaware syslog clients. The target audience for NETCONF (network service providers) don't configure their boxes to forward syslog messages. These devices are the source of events and operators dislike having open ports on their boxes that aren't strictly required. But I can see the utility of this for other environments and the cost is minimal, so I'd consider rolling it in, except.... >When multiple host message may be present in a single netconf-syslog >stream, it might also be that different VERSIONS of the syslog protocol >be present in a single stream. ... this sounds like it will be an issue. Can we avoid mixing VERSIONs in a single stream? >"The SYSLOG protocol lacks security and reliability." >This is not true. There is RFC 3195 (syslog over BEEP) which supports >security and reliability. 3195 is currently only weakly accepted, but >there as some implementations of it. I suggest a reference is made to >3195 to clarify on that issue (and so that a casual reader will become >aware that there is more to look at then 3164 and syslog-protocol). The target of this comment was 3164, since 3195 doesn't seem to have been picked up by the operator community, but I'll add a reference to 3195 and clarify my comment. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 12:47:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjNV-0004pB-JD for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:47:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsjNU-0006ND-9h for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 12:47:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsjJh-0004Rz-J6 for netconf-data@psg.com; Tue, 20 Jun 2006 16:43: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsjJf-0004Ra-5T for netconf@ops.ietf.org; Tue, 20 Jun 2006 16:43:03 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5KGgtX97832; Tue, 20 Jun 2006 09:42:55 -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 k5KGgj542074; Tue, 20 Jun 2006 09:42:46 -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 k5KGgjwn034160; Tue, 20 Jun 2006 12:42:45 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606201642.k5KGgjwn034160@idle.juniper.net> To: Andy Bierman cc: Vincent Cridlig , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Tue, 20 Jun 2006 09:29:56 PDT." <44982284.6080007@andybierman.com> Date: Tue, 20 Jun 2006 12:42:45 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Andy Bierman writes: >I also don't understand the obsession with calling everything >"subscription data" instead of "configuration data", and insisting >that NV-storing this subscription data is not important, not useful, >or not "simple enough" for the manager to use. I don't understand this comment wrt my draft. The draft's model is that the device defines a set of streams. This is not subscription data, nor necessarily configuration data. What I like is that it gives the device control over what applications can see, and prevents applications from asking for everything if the admin denies it. The stream approach also gives a recording mechanism (the device records each stream, not all events) so that an application user can hit the "what went wrong" button and see a list of recent messages, possibly from before the application was launched. > * Some parameters like "retrieve since time N" are session-specific, > and belong only in the RPC, not the config (obviously). Some > parameters like "get me the next 3804 notifications" seem pretty > complicated and not very useful. I prefer only 1 mode: > - get since time N (or sequence-id X) and keep going until the session > is shut down The two main scenarios I see are monitoring a stream and viewing the recorded data from a stream. Both are important facets of how syslog events are handled today. It's a "more" .vs. "tail -f" issue. ;^) Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 13:04:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjeT-0000Tf-7L for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 13:04:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsjeR-0008Il-T2 for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 13:04:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsjau-0005kY-QT for netconf-data@psg.com; Tue, 20 Jun 2006 17:00:52 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsjau-0005kK-3Y for netconf@ops.ietf.org; Tue, 20 Jun 2006 17:00:52 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5KH0oDB032688 for ; Tue, 20 Jun 2006 13:00:51 -0400 Received: (qmail 7145 invoked by uid 78); 20 Jun 2006 17:00:47 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 20 Jun 2006 17:00:47 -0000 Message-ID: <449829B7.2060402@andybierman.com> Date: Tue, 20 Jun 2006 10:00:39 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Vincent Cridlig , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606201642.k5KGgjwn034160@idle.juniper.net> In-Reply-To: <200606201642.k5KGgjwn034160@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Phil Shafer wrote: > Andy Bierman writes: >> I also don't understand the obsession with calling everything >> "subscription data" instead of "configuration data", and insisting >> that NV-storing this subscription data is not important, not useful, >> or not "simple enough" for the manager to use. > > I don't understand this comment wrt my draft. I prefer to use , , and standard data models to configure aspects of this feature such as filtering parameters. Sharon started in the right direction with a data model, but just for monitoring. IMO we should really get out of the SNMP and CLI mindset that standard data models for configuration are either too hard or too proprietary for the IETF to touch. The notion that CLI is all "special command driven" and not actually data is not really true. ACLs, Dialer plans, static routes, etc. are all NV-stored data. (Imagine how well ACLs would work if there were none until the root user logged in and "configured" them all with RPC calls. ;-) Andy > > The draft's model is that the device defines a set of streams. This > is not subscription data, nor necessarily configuration data. What > I like is that it gives the device control over what applications > can see, and prevents applications from asking for everything if > the admin denies it. > > The stream approach also gives a recording mechanism (the device > records each stream, not all events) so that an application user > can hit the "what went wrong" button and see a list of recent > messages, possibly from before the application was launched. > >> * Some parameters like "retrieve since time N" are session-specific, >> and belong only in the RPC, not the config (obviously). Some >> parameters like "get me the next 3804 notifications" seem pretty >> complicated and not very useful. I prefer only 1 mode: >> - get since time N (or sequence-id X) and keep going until the session >> is shut down > > The two main scenarios I see are monitoring a stream and viewing the > recorded data from a stream. Both are important facets of how syslog > events are handled today. > > It's a "more" .vs. "tail -f" issue. ;^) > > Thanks, > Phil > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 13:15:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsjoj-0006LG-N5 for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 13:15:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsjoh-0003Pd-Cx for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 13:15:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsjlO-0006Xh-0M for netconf-data@psg.com; Tue, 20 Jun 2006 17:11:42 +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 1FsjlM-0006XR-5Y for netconf@ops.ietf.org; Tue, 20 Jun 2006 17:11:40 +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 k5KHBd5A024837 for ; Tue, 20 Jun 2006 13:11:39 -0400 Received: (qmail 18782 invoked by uid 78); 20 Jun 2006 17:11:38 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 20 Jun 2006 17:11:38 -0000 Message-ID: <44982C42.3020906@andybierman.com> Date: Tue, 20 Jun 2006 10:11:30 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Vincent Cridlig , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606201642.k5KGgjwn034160@idle.juniper.net> In-Reply-To: <200606201642.k5KGgjwn034160@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Phil Shafer wrote: >.. > > It's a "more" .vs. "tail -f" issue. ;^) Ok. I was wondering about how live notifications and recorded notifications were mixed together. These models imply that they are not mixed, but rather that live notifications are buffered specially for the session, and delivery deferred until all the requested recorded notifications have been delivered. This is fine, as long as we stay away from complicated options to provide any other delivery order than this. > > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 15:15:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslhX-00069x-Op for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 15:15:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslhV-0007n9-Vs for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 15:15:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsldU-000EQa-M9 for netconf-data@psg.com; Tue, 20 Jun 2006 19:11:40 +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=BAYES_00 autolearn=ham version=3.1.1 Received: from [217.12.11.34] (helo=smtp003.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsldS-000EQL-Q8 for netconf@ops.ietf.org; Tue, 20 Jun 2006 19:11:39 +0000 Received: (qmail 60562 invoked from network); 20 Jun 2006 19:11:25 -0000 Received: from unknown (HELO ?192.168.0.2?) (cridligv@89.83.244.85 with plain) by smtp003.mail.ukl.yahoo.com with SMTP; 20 Jun 2006 19:11:24 -0000 Message-ID: <4498487B.5080802@loria.fr> Date: Tue, 20 Jun 2006 21:11:55 +0200 From: Cridlig Vincent User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Phil Shafer CC: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606201618.k5KGIvwn034000@idle.juniper.net> In-Reply-To: <200606201618.k5KGIvwn034000@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Phil Shafer a écrit : > Vincent Cridlig writes: > >> I don't really understand the design choice of the get-syslog-streams >> operation because I think it breaks the idea of the get-config operation. >> > > Syslog stream definitions are not limited to configuration, since > the device may define default streams. > > >> Wouldn't it be more conform to Netconf to define a short data model for >> syslog streams and use the regular get-config with a selection node ? >> > > I'm not prepared to be the first lamb on that altar. ;^) > > >> For the second part 3.2, I am confused. What happens if I send a >> get-syslog-events with a stop-time one hour later ? Can I still use this >> Netconf session to send other RPC during this time ? I guess no. The >> Netconf session would be locked for a long period of time. >> > > Yup, exactly. > > >> If I understand well, this approach assumes that the agent is parsing >> the XML data stream on the fly (like with SAX, but not DOM). Because the >> rpc-reply does not seem to be closed until a stop condition happens and >> DOM can not read a partial document. If this is the case, must the agent >> assume that the rpc-reply message will be valid before it received the >> whole message ? And process it ? >> > > Yes, if you are looking for a real-time stream, you'll need to > use a technology that allows you to parse it as it arrives. SAX > is perfect for this, giving you callbacks to drive a simple state > machine. > I personally prefer the solution embedding syslog messages in a element (specified in http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt) for the following reasons: - It does not block the Netconf session, so you can receive syslog notifications and still do other things, (Otherwise you need two Netconf sessions) - The processing of messages is easier because parsing partial messages is not necessary. Just considering the special caracter ]]>]]> for sequencing the messages. I prefer to process a buffer of full Netconf messages than start processing a stream which could contain errors lately, - You can check message well-formness and validity before processing it => more secure, - You can have the same functionnality (like receiving the next 100 syslog messages). Minor point which is more a taste problem: Whatever will be the solution, I think syslog messages should be parsed and rebuilt in an XML structure on the agent side, before being sent to the manager. This is easy to do (there are plenty of parser generator) and makes the management application more consistent, because everything is formatted in the same way. The agent would behave like a full syslog/Netconf gateway, similar to what was done with XML/SNMP gateways. Regards, Vincent ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 20 15:32:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fslxk-0008TI-Ou for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 15:32:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fslxk-0000r5-AU for netconf-archive@lists.ietf.org; Tue, 20 Jun 2006 15:32:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsltz-000Fak-0y for netconf-data@psg.com; Tue, 20 Jun 2006 19:28:43 +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 1Fsltu-000FaP-D1 for netconf@ops.ietf.org; Tue, 20 Jun 2006 19:28:41 +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 k5KJS8xn023882 for ; Tue, 20 Jun 2006 15:28:24 -0400 Received: (qmail 30031 invoked by uid 78); 20 Jun 2006 19:28:08 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 20 Jun 2006 19:28:08 -0000 Message-ID: <44984C39.6080404@andybierman.com> Date: Tue, 20 Jun 2006 12:27:53 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cridlig Vincent CC: Phil Shafer , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606201618.k5KGIvwn034000@idle.juniper.net> <4498487B.5080802@loria.fr> In-Reply-To: <4498487B.5080802@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cridlig Vincent wrote: > Phil Shafer a écrit : >> Vincent Cridlig writes: >> >>> I don't really understand the design choice of the get-syslog-streams >>> operation because I think it breaks the idea of the get-config >>> operation. >>> >> >> Syslog stream definitions are not limited to configuration, since >> the device may define default streams. >> >> >>> Wouldn't it be more conform to Netconf to define a short data model >>> for syslog streams and use the regular get-config with a selection >>> node ? >>> >> >> I'm not prepared to be the first lamb on that altar. ;^) Unfortunately, somebody has to go first. I suspect that the co-Chairs, ADs, and rest of the IESG are not going to be very impressed with this excuse as a justification for what appears to be a very questionable design decision. Andy >> >> >>> For the second part 3.2, I am confused. What happens if I send a >>> get-syslog-events with a stop-time one hour later ? Can I still use >>> this Netconf session to send other RPC during this time ? I guess no. >>> The Netconf session would be locked for a long period of time. >>> >> >> Yup, exactly. >> >> >>> If I understand well, this approach assumes that the agent is parsing >>> the XML data stream on the fly (like with SAX, but not DOM). Because >>> the rpc-reply does not seem to be closed until a stop condition >>> happens and DOM can not read a partial document. If this is the case, >>> must the agent assume that the rpc-reply message will be valid before >>> it received the whole message ? And process it ? >>> >> >> Yes, if you are looking for a real-time stream, you'll need to >> use a technology that allows you to parse it as it arrives. SAX >> is perfect for this, giving you callbacks to drive a simple state >> machine. >> > I personally prefer the solution embedding syslog messages in a > element > (specified in > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt) > for the following reasons: > > - It does not block the Netconf session, so you can receive syslog > notifications and still do other things, (Otherwise you need two Netconf > sessions) > - The processing of messages is easier because parsing partial messages > is not necessary. Just considering the special caracter ]]>]]> for > sequencing the messages. I prefer to process a buffer of full Netconf > messages than start processing a stream which could contain errors lately, > - You can check message well-formness and validity before processing it > => more secure, > - You can have the same functionnality (like receiving the next 100 > syslog messages). > > Minor point which is more a taste problem: > Whatever will be the solution, I think syslog messages should be parsed > and rebuilt in an XML structure on the agent side, before being sent to > the manager. This is easy to do (there are plenty of parser generator) > and makes the management application more consistent, because everything > is formatted in the same way. The agent would behave like a full > syslog/Netconf gateway, similar to what was done with XML/SNMP gateways. > > Regards, > Vincent > > > > > > > ___________________________________________________________________________ > Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son > interface révolutionnaire. > http://fr.mail.yahoo.com > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Jun 21 04:24:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsy0g-0001PP-Ra for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 04:24:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsy0f-0006gl-Et for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 04:24:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsxtx-000FFt-3H for netconf-data@psg.com; Wed, 21 Jun 2006 08:17: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.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsxtv-000FFf-TW for netconf@ops.ietf.org; Wed, 21 Jun 2006 08:17:28 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id A7C4C27C065; Wed, 21 Jun 2006 10:13:58 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21374-07; Wed, 21 Jun 2006 10:13:58 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 627BC27C061; Wed, 21 Jun 2006 10:13:58 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:17:20 +0200 Content-class: urn:content-classes:message Subject: RE: draft-shafer-netconf-syslog-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jun 2006 10:17:18 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174985@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <4498487B.5080802@loria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaUnnG71Sx7m5n/QISKmJsXHRIXoQAa3Yjg From: "Rainer Gerhards" To: "Cridlig Vincent" , "Phil Shafer" Cc: , "Chris Lonvick" , X-OriginalArrivalTime: 21 Jun 2006 08:17:20.0507 (UTC) FILETIME=[1DE084B0:01C6950B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 > Minor point which is more a taste problem: > Whatever will be the solution, I think syslog messages should=20 > be parsed=20 > and rebuilt in an XML structure on the agent side, before=20 > being sent to=20 > the manager. This is easy to do (there are plenty of parser=20 > generator)=20 > and makes the management application more consistent, because=20 > everything=20 > is formatted in the same way. The agent would behave like a full=20 > syslog/Netconf gateway, similar to what was done with=20 > XML/SNMP gateways. I essentially agree, BUT... The syslog WG is working on digitial signatures for syslog messages (syslog-sign I-D). The intention is to provide a long-lifed record of the authenticy of the log messages, no matter which transports and gateways have been used. Thus, this initial sender will sign the messages and the final destination will store an exact same copy of that message. Then, the original signature can be verified even years later (think about evidence in court). The bottom-line to make this happen is that the orginal message is available on the final destination. Parsing and XML-formatting it invalidates the message. One might argue if this is of concern for netconf. Probably not, if only syslog is used for long term archiving. But you never know. Besides that concern, I think a standard data model for syslog messages is definitely needed. Unfortunately, the syslog WG is not yet chartered to provide it. The current syslog-protocol draft has been written with the data model in mind. It is fairly trivial to define a standard data model based on it. It even contains hints for parsing RFC 3164 message in a way consistent with such a model. The data model might also optionally contain the original message, which solves the signature problem (at the cost of a large message size, but that should not be too much of a concern these days). I personally wouldn't care if that model is created by the netconf or syslog WG (though this sound like the more appropriate place). Given the current participation in both WGs, netconf would, practically thinking, be a better place to do it. Rainer -- to unsubscribe send a message to netconf-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 Jun 21 04:48:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyNn-0006EA-Ti for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 04:48:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsyNm-0000rf-At for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 04:48:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsyIX-000HGJ-KS for netconf-data@psg.com; Wed, 21 Jun 2006 08:42:53 +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 [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsyIV-000HG5-VH for netconf@ops.ietf.org; Wed, 21 Jun 2006 08:42:52 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D953D670D8; Wed, 21 Jun 2006 10:42:50 +0200 (CEST) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id 61561670D8; Wed, 21 Jun 2006 10:42:49 +0200 (CEST) Message-ID: <449906B2.4080704@loria.fr> Date: Wed, 21 Jun 2006 10:43:30 +0200 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Rainer Gerhards Cc: Phil Shafer , netconf@ops.ietf.org, Chris Lonvick , dbharrington@comcast.net Subject: Re: draft-shafer-netconf-syslog-00.txt References: <577465F99B41C842AAFBE9ED71E70ABA174985@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174985@grfint2.intern.adiscon.com> Content-Type: multipart/mixed; boundary="------------050201090209000500020602" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. --------------050201090209000500020602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Rainer Gerhards a écrit : > > I essentially agree, BUT... The syslog WG is working on digitial > signatures for syslog messages (syslog-sign I-D). The intention is to > provide a long-lifed record of the authenticy of the log messages, no > matter which transports and gateways have been used. Thus, this initial > sender will sign the messages and the final destination will store an > exact same copy of that message. Then, the original signature can be > verified even years later (think about evidence in court). > > The bottom-line to make this happen is that the orginal message is > available on the final destination. Parsing and XML-formatting it > invalidates the message. > > One might argue if this is of concern for netconf. Probably not, if only > syslog is used for long term archiving. But you never know. > Sure. That would be a problem. I was thinking of an alternative where the agent generates a new signature of the XML document (the translated syslog message) using XML-DigitalSignature from W3C. (Before doing so, the agent may check the original syslog signature.) As usual with security considerations, it would be more costly both for: - processing time on agent side (check old and generate new signature), - storage on the manager side (An XML-DS document might consume more storage than a signed syslog message). Vincent > Besides that concern, I think a standard data model for syslog messages > is definitely needed. Unfortunately, the syslog WG is not yet chartered > to provide it. The current syslog-protocol draft has been written with > the data model in mind. It is fairly trivial to define a standard data > model based on it. It even contains hints for parsing RFC 3164 message > in a way consistent with such a model. The data model might also > optionally contain the original message, which solves the signature > problem (at the cost of a large message size, but that should not be too > much of a concern these days). > I personally wouldn't care if that model is created by the netconf or > syslog WG (though this sound like the more appropriate place). Given the > current participation in both WGs, netconf would, practically thinking, > be a better place to do it. > > Rainer > --------------050201090209000500020602 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------050201090209000500020602-- -- to unsubscribe send a message to netconf-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 Jun 21 04:55:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyUn-0004Uz-72 for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 04:55:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsyUm-0001T8-Nn for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 04:55:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsyOn-000HpO-Lg for netconf-data@psg.com; Wed, 21 Jun 2006 08:49:21 +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, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsyOk-000Hoz-Tc for netconf@ops.ietf.org; Wed, 21 Jun 2006 08:49:19 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 46D9127C065; Wed, 21 Jun 2006 10:45:55 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22015-08; Wed, 21 Jun 2006 10:45:55 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D46CD27C061; Wed, 21 Jun 2006 10:45:54 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:49:16 +0200 Content-class: urn:content-classes:message Subject: RE: draft-shafer-netconf-syslog-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jun 2006 10:49:17 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174987@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <200606201630.k5KGUJwn034065@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaUhtsvgzEWDxbDQ12g0BSsYvJQTQAho3zQ From: "Rainer Gerhards" To: "Phil Shafer" Cc: "netconf" , X-OriginalArrivalTime: 21 Jun 2006 08:49:16.0891 (UTC) FILETIME=[942182B0:01C6950F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Phil, > >RFC 3164 and syslog-protocol both list names (e.g.=20 > "authorization" and > >"emergency") as well as integer numbers for PRI contents.=20 > However, only > >the integers are normative (see ABNF in syslog-protocol, PRI=20 > description > >in RFC 3164). It has also been observed in practice that the=20 > names are > >not without ambiguity. So I strongly suggest to use the=20 > integer values > >only in netconf-syslog filters. If there is no consensus on this, I > >propose to support both the names as well as the numbers. >=20 > I strongly dislike using numbers, but if there's consensus > to use them, I'll survive. I understand your position. At a minimum, I strongly suggest that you allow either numbers or names. I think most of the filter data is operator-entered, so it is left to the operators decisions what to use. This is especially important when different syslog message sources use different names (though this could be handled by the gateway exclusively). >=20 > >Remotly Received Events=20 > >From my understanding of netconf-syslog, a netconf-syslog server > >supports forwarding via netconf both locally generated=20 > syslog messages > >as well remotely received ones. I think the ability to=20 > process remotely > >received messages is a vital asset. It enables a=20 > netconf-syslog server > >to act as a hub/gateway to a number of netconf-unaware=20 > syslog clients. >=20 > The target audience for NETCONF (network service providers) don't > configure their boxes to forward syslog messages. These devices > are the source of events and operators dislike having open ports > on their boxes that aren't strictly required. >=20 > But I can see the utility of this for other environments and > the cost is minimal, so I'd consider rolling it in, except.... >=20 > >When multiple host message may be present in a single netconf-syslog > >stream, it might also be that different VERSIONS of the=20 > syslog protocol > >be present in a single stream. >=20 > ... this sounds like it will be an issue. Can we avoid mixing > VERSIONs in a single stream? Let me ask where you see an issue with multiple versions. For me it seems fairly easy to support them. I've also thought a little more about the local environment. I think there is no way you can guarantee that even a single machine will provide consistently one message format version or the other. Reasoning: The diagram in 2.1 of netconf-syslog precisely describes how the syslog subsystem works in many environments, namely Unix and Linux based systems. The syslog daemon is not the actual message generator. In fact, it is more like a relay. From the on-the-wire point of view, it is the initial sender. But if you think about local API, it is just a receiver forwarding (and potentially transforming) messages. The actual message generators are system components (called c1, c2, .... cn in your diagram). These components generate messages via API calls. The API covers only very limited syslog header fields. Most of the header is generated by the *system component*. So you are actually not dealing with a single syslogd and its format but with a potential myriad of different components on the box. This has been identified as a major issue moving legacy (rfc 3164) syslog to a standard (syslog-protocol). This is also one reason why there are so many different formats. In order to guarantee a consistent data model, you would need to change the (POSIX) logging API. As this change can not be done evolutionary (it would break existing apps), the old API would still needed to be supported. It is thought in the syslog WG that that API change should happen some time. But we are definitely some years away from that. Not to mention how long the old API will be utilized... So my firm believe is that it will be the absolutely common case for syslog implementations to have to deal with different message formats. Much of the evil in that can be avoided, if a syslog data model is defined. This, together with transformation rules, would make it very easy to handle different versions. As I have written in another mail this morning, syslog-protocol has such a data model "on its mind" but can not spell it out because the syslog WG is not chartered to do that. But it is fairly easy. I have also a working proof-of-concept implementation of the most important transformations in actual software (www.rsyslog.com). Its fairly easy to extend that to a full data model transformation. >=20 > >"The SYSLOG protocol lacks security and reliability." > >This is not true. There is RFC 3195 (syslog over BEEP) which supports > >security and reliability. 3195 is currently only weakly accepted, but > >there as some implementations of it. I suggest a reference is made to > >3195 to clarify on that issue (and so that a casual reader=20 > will become > >aware that there is more to look at then 3164 and syslog-protocol). >=20 > The target of this comment was 3164, since 3195 doesn't seem to > have been picked up by the operator community, but I'll add a > reference to 3195 and clarify my comment. I agree that 3195 is not overly successful ;) However, you never know what the future has in stock. As there is no additional effort to supporting 3195 in netconf-syslog, I think it would be useful to mention it and to also mention that it can be used together with netconf-syslog (it is VERSION 0 format, just like 3164). Rainer -- to unsubscribe send a message to netconf-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 Jun 21 05:01:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyaW-0007t5-Cg for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 05:01:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsyaV-00028P-2s for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 05:01:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsyXG-000Idx-4s for netconf-data@psg.com; Wed, 21 Jun 2006 08:58: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=BAYES_00,FORGED_RCVD_HELO, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsyXF-000Idi-Gw for netconf@ops.ietf.org; Wed, 21 Jun 2006 08:58:05 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id CBC0827C065; Wed, 21 Jun 2006 10:54:41 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22015-10; Wed, 21 Jun 2006 10:54:41 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 8A21127C061; Wed, 21 Jun 2006 10:54:41 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:57:58 +0200 Content-class: urn:content-classes:message Subject: RE: draft-shafer-netconf-syslog-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jun 2006 10:57:59 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174989@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <449906B2.4080704@loria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaVEB41K1+j8CgdQo6gKNXPniTqbgAAB7ZQ From: "Rainer Gerhards" To: "Vincent Cridlig" Cc: "Phil Shafer" , , "Chris Lonvick" , X-OriginalArrivalTime: 21 Jun 2006 08:57:58.0877 (UTC) FILETIME=[CB4240D0:01C69510] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Vincent,=20 > Sure. That would be a problem. > I was thinking of an alternative where the agent generates a new=20 > signature of the XML document (the translated syslog message) using=20 > XML-DigitalSignature from W3C. > (Before doing so, the agent may check the original syslog signature.) > As usual with security considerations, it would be more=20 > costly both for: > - processing time on agent side (check old and generate new=20 > signature), > - storage on the manager side (An XML-DS document might consume more=20 > storage than a signed syslog message). There is an importnat legal issue: AFAIK (I am not a lawyer), this would be a "derived signature" and not an "original signature". I have been told that (at least in the US) you need to have an original signature to use the log as evidence in court. Other voices said that if one can argue that the derived signature is as good as the original one AND can proove this point, then it *might* be used as evidence, too. The problem is that you must very carefully argue that no tampering is possible at the gateway. Rainer -- to unsubscribe send a message to netconf-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 Jun 21 06:46:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Dk-0005Eh-Iu for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 06:46:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0Dj-0003iL-0c for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 06:46:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft09N-00007D-1I for netconf-data@psg.com; Wed, 21 Jun 2006 10:41:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft09M-00006w-4e for netconf@ops.ietf.org; Wed, 21 Jun 2006 10:41:32 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) by mail.tail-f.com (Postfix) with ESMTP id 83A4D1B8094; Wed, 21 Jun 2006 12:41:29 +0200 (CEST) Date: Wed, 21 Jun 2006 12:41:27 +0200 (CEST) Message-Id: <20060621.124127.96932914.mbj@tail-f.com> To: phil@juniper.net Cc: vincent.cridlig@loria.fr, netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt From: Martin Bjorklund In-Reply-To: <200606201618.k5KGIvwn034000@idle.juniper.net> References: <44981592.5080906@loria.fr> <200606201618.k5KGIvwn034000@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Phil Shafer wrote: > Vincent Cridlig writes: > >I don't really understand the design choice of the get-syslog-streams > >operation because I think it breaks the idea of the get-config operation. > > Syslog stream definitions are not limited to configuration, since > the device may define default streams. So a manager can do to retreive this info. Suppose an agent actually did make this configurable. Without a standard data model, the vendor will have to invent his own model for this data. That means that different vendors will use different models. So even if there's a standard way to view the data (get-syslog-streams), there's no standard way to write it. Furthermore, this data will be available through two different rpcs, get-syslog-streams and with a vendor-specific namespace through get-config. If on the other hand a standard data model is used, there would be a standard way to read () and write (for the agents that support it). /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 21 06:46:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0EY-00063H-G9 for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 06:46:55 -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 1Fsz9h-0005SS-Ub for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 05:37:49 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fsyr5-0001dU-GG for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 05:18:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsylu-000JsH-68 for netconf-data@psg.com; Wed, 21 Jun 2006 09:13:14 +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=BAYES_00 autolearn=ham version=3.1.1 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fsylt-000Js4-8n for netconf@ops.ietf.org; Wed, 21 Jun 2006 09:13:13 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7EC25670AC; Wed, 21 Jun 2006 11:13:12 +0200 (CEST) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id D05DB670AC; Wed, 21 Jun 2006 11:13:10 +0200 (CEST) Message-ID: <44990DD0.90706@loria.fr> Date: Wed, 21 Jun 2006 11:13:52 +0200 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Rainer Gerhards Cc: Phil Shafer , netconf@ops.ietf.org, Chris Lonvick , dbharrington@comcast.net Subject: Re: draft-shafer-netconf-syslog-00.txt References: <577465F99B41C842AAFBE9ED71E70ABA174989@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174989@grfint2.intern.adiscon.com> Content-Type: multipart/mixed; boundary="------------080308030800030806000800" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. --------------080308030800030806000800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Rainer Gerhards a écrit : > Vincent, > > >> Sure. That would be a problem. >> I was thinking of an alternative where the agent generates a new >> signature of the XML document (the translated syslog message) using >> XML-DigitalSignature from W3C. >> (Before doing so, the agent may check the original syslog signature.) >> As usual with security considerations, it would be more >> costly both for: >> - processing time on agent side (check old and generate new >> signature), >> - storage on the manager side (An XML-DS document might consume more >> storage than a signed syslog message). >> > > There is an importnat legal issue: AFAIK (I am not a lawyer), this would > be a "derived signature" and not an "original signature". I have been > told that (at least in the US) you need to have an original signature to > use the log as evidence in court. Other voices said that if one can > argue that the derived signature is as good as the original one AND can > proove this point, then it *might* be used as evidence, too. The problem > is that you must very carefully argue that no tampering is possible at > the gateway. > You are probably right. I don't know about this legal issue that can be different among different countries. Vincent > Rainer > --------------080308030800030806000800 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------080308030800030806000800-- -- to unsubscribe send a message to netconf-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 Jun 21 10:46:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3y8-0000N3-M0 for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 10:46:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3y7-0002Oh-AR for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 10:46:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft3s9-000GxJ-AA for netconf-data@psg.com; Wed, 21 Jun 2006 14:40:01 +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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft3s7-000Gwx-Qc for netconf@ops.ietf.org; Wed, 21 Jun 2006 14:40:00 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5LEdwCs031387 for ; Wed, 21 Jun 2006 10:39:58 -0400 Received: (qmail 23786 invoked by uid 78); 21 Jun 2006 14:39:45 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 21 Jun 2006 14:39:45 -0000 Message-ID: <44995A2A.3020305@andybierman.com> Date: Wed, 21 Jun 2006 07:39:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, vincent.cridlig@loria.fr, netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <44981592.5080906@loria.fr> <200606201618.k5KGIvwn034000@idle.juniper.net> <20060621.124127.96932914.mbj@tail-f.com> In-Reply-To: <20060621.124127.96932914.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Martin Bjorklund wrote: > Phil Shafer wrote: >> Vincent Cridlig writes: >>> I don't really understand the design choice of the get-syslog-streams >>> operation because I think it breaks the idea of the get-config operation. >> Syslog stream definitions are not limited to configuration, since >> the device may define default streams. > > So a manager can do to retreive this info. > > Suppose an agent actually did make this configurable. Without a > standard data model, the vendor will have to invent his own model for > this data. That means that different vendors will use different > models. So even if there's a standard way to view the data > (get-syslog-streams), there's no standard way to write it. > Furthermore, this data will be available through two different rpcs, > get-syslog-streams and with a vendor-specific namespace through > get-config. > > If on the other hand a standard data model is used, there would be a > standard way to read () and write (for the agents that support > it). IMO this is a serious issue. I completely agree with Martin. What is the excuse for NETCONF to ignore configuration and do read-only data models instead? Should we tell the ADs and rest of the IESG "That network configuration problem is really hard -- you should get a WG to do something about it! Good think we only have to worry about monitoring in the NETWORK CONFIGURATION PROTOCOL WG." For years vendors would not do read-write because SNMP was insecure (but passing cleartext telnet passwords around didn't bother them too much at the time.) Then the excuse was "SNMP is too hard, XML is easier." Now what's the excuse? It's time to put up or shut up wrt/ standards based configuration. > > > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 21 12:50:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5uQ-00007a-3D for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 12:50:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5uO-00019v-QE for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 12:50:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft5qW-00006Q-Vq for netconf-data@psg.com; Wed, 21 Jun 2006 16:46: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 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 1Ft5qW-000065-2N for netconf@ops.ietf.org; Wed, 21 Jun 2006 16:46:28 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5LGkR1F030784 for ; Wed, 21 Jun 2006 12:46:27 -0400 Received: (qmail 8132 invoked by uid 78); 21 Jun 2006 16:46:20 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 21 Jun 2006 16:46:20 -0000 Message-ID: <449977D4.2020109@andybierman.com> Date: Wed, 21 Jun 2006 09:46:12 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Adding draft-shafer-netconf-syslog-00.txt to the meeting agenda Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi, There seems to be a lot of interest in further discussion of Phil's draft, so it will be added to the meeting agenda for Montreal. I would like the WG to start preparing for this meeting by commenting on both drafts in terms of the functional requirements discussion that we will have at the regular WG meeting on Friday morning (7/14). Q1: What are the important notification features? We will have to rank the priority of all the wish list features and start out with only the ones with WG consensus as "must-have" for this feature. Q2: Which solution proposal (if any) best addresses each specific requirement? thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 21 21:31:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtE2Z-0000rx-Rc for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 21:31:27 -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 1FtADu-0007Rf-OR for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 17:26:54 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtA6I-0006Lp-LH for netconf-archive@lists.ietf.org; Wed, 21 Jun 2006 17:19:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtA1G-000K03-Lx for netconf-data@psg.com; Wed, 21 Jun 2006 21:13:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [204.127.192.84] (helo=rwcrmhc14.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft2Um-000AiN-UZ for netconf@ops.ietf.org; Wed, 21 Jun 2006 13:11:48 +0000 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc14) with SMTP id <20060621131143m14000e3ule>; Wed, 21 Jun 2006 13:11:48 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Cridlig Vincent'" , "'Phil Shafer'" Cc: , "'Chris Lonvick'" Subject: RE: draft-shafer-netconf-syslog-00.txt Date: Wed, 21 Jun 2006 09:10:31 -0400 Message-ID: <144401c69534$15fd5600$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 In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174985@grfint2.intern.adiscon.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaUnnG71Sx7m5n/QISKmJsXHRIXoQAa3YjgAApQmsA= Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi Rainer, I suggest that it would be appropriate to charter a syslog-data WG in the OPS area to work on standardizing the syslog data modeling format. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, June 21, 2006 4:17 AM > To: Cridlig Vincent; Phil Shafer > Cc: netconf@ops.ietf.org; Chris Lonvick; dbharrington@comcast.net > Subject: RE: draft-shafer-netconf-syslog-00.txt > > > Minor point which is more a taste problem: > > Whatever will be the solution, I think syslog messages should > > be parsed > > and rebuilt in an XML structure on the agent side, before > > being sent to > > the manager. This is easy to do (there are plenty of parser > > generator) > > and makes the management application more consistent, because > > everything > > is formatted in the same way. The agent would behave like a full > > syslog/Netconf gateway, similar to what was done with > > XML/SNMP gateways. > > I essentially agree, BUT... The syslog WG is working on digitial > signatures for syslog messages (syslog-sign I-D). The intention is to > provide a long-lifed record of the authenticy of the log messages, no > matter which transports and gateways have been used. Thus, > this initial > sender will sign the messages and the final destination will store an > exact same copy of that message. Then, the original signature can be > verified even years later (think about evidence in court). > > The bottom-line to make this happen is that the orginal message is > available on the final destination. Parsing and XML-formatting it > invalidates the message. > > One might argue if this is of concern for netconf. Probably > not, if only > syslog is used for long term archiving. But you never know. > > Besides that concern, I think a standard data model for > syslog messages > is definitely needed. Unfortunately, the syslog WG is not yet > chartered > to provide it. The current syslog-protocol draft has been written with > the data model in mind. It is fairly trivial to define a standard data > model based on it. It even contains hints for parsing RFC 3164 message > in a way consistent with such a model. The data model might also > optionally contain the original message, which solves the signature > problem (at the cost of a large message size, but that should > not be too > much of a concern these days). > > I personally wouldn't care if that model is created by the netconf or > syslog WG (though this sound like the more appropriate > place). Given the > current participation in both WGs, netconf would, practically > thinking, > be a better place to do it. > > Rainer > -- to unsubscribe send a message to netconf-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 Jun 22 06:04:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtM2y-00045A-VM for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 06:04:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtM2v-0001BU-3l for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 06:04:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtLtM-000JvO-5D for netconf-data@psg.com; Thu, 22 Jun 2006 09:54: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 1FtLtK-000Jv7-Gf for netconf@ops.ietf.org; Thu, 22 Jun 2006 09:54:26 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 946F58E0003; Thu, 22 Jun 2006 11:54:25 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 11:54:25 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 11:54:24 +0200 Message-ID: <449A68F8.8010608@ericsson.com> Date: Thu, 22 Jun 2006 11:55:04 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Phil Shafer CC: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606201618.k5KGIvwn034000@idle.juniper.net> In-Reply-To: <200606201618.k5KGIvwn034000@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 09:54:24.0630 (UTC) FILETIME=[D7BCE960:01C695E1] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hello, 1) I want to fetch recorded data from yesterday 12:00Z till 13:00Z. The draft doesn't seem to allow this as the stop time is already in the past. I would allow this! I would write something like: The server closes the stream based on stop-time if stop-time has passed and all events up to stop-time, available at the server have been sent over the session. 2) Same comments as for Sharon's draft: Use a data model for streams and use the get and edit-config operations instead of a custom operation for a small set of special (?) data. Even if streams can be defined in multiple ways (configuration, system default, etc.) they still can nicely be modeled as read-only data. 3) > I'm not prepared to be the first lamb on that altar. ;^) Someone has to be :-) otherwise NETCONF is dead already. Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 09:26:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPCs-0005RA-GI for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 09:26:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtPCr-0003iR-6V for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 09:26:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtP7n-0008Av-Av for netconf-data@psg.com; Thu, 22 Jun 2006 13:21: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 [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtP7m-0008A2-6q for netconf@ops.ietf.org; Thu, 22 Jun 2006 13:21:34 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5MDLT925869 for ; Thu, 22 Jun 2006 09:21:29 -0400 (EDT) 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: Update to Netconf Notifications Draft Date: Thu, 22 Jun 2006 09:20:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4095C5B02@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update to Netconf Notifications Draft Thread-Index: AcaV/rKl5rkt8OrbQcOoOn5AS8jbMg== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 hi I have submitted the updated Netconf Event Notification Draft. There appears to be a problem with my website, so I can't post a version for people to read while waiting for real one. When the site is back up, I'll make a copy available. The update is as promised in the emails I sent with the proposed updates, with the following exceptions 1. I was hoping for some specific inputs to help flesh out the call home section but didn't receive it. These changes will have to wait for the next version. 2. I had said we would clarify that the filters would be applied against the content of the filters but when I went to make the change I realized the intention was that filters were applied against the notification itself, not the content. By this I mean that either through sub tree of XPath the element that defines the notification has a handle that we can use for filtering against the notification. I've added clarification around that instead, but in hindsight perhaps I could have explained it better. 3. It was suggested that instead of spreading the examples throughout the document that they get co-located in the document. In thinking about this more, I think it is useful to have examples in-line to help explain various ideas. This would not preclude having a more comprehensive example section though. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 10:30:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQCw-0006sF-DQ for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 10:30:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQCu-0002TD-Gc for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 10:30:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQ3v-000Cwf-GC for netconf-data@psg.com; Thu, 22 Jun 2006 14:21:39 +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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQ3u-000CwR-Mc for netconf@ops.ietf.org; Thu, 22 Jun 2006 14:21:38 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5MELcfB022197 for ; Thu, 22 Jun 2006 10:21:38 -0400 Received: (qmail 20205 invoked by uid 78); 22 Jun 2006 14:21:37 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 22 Jun 2006 14:21:37 -0000 Message-ID: <449AA791.4000408@andybierman.com> Date: Thu, 22 Jun 2006 07:22:09 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Balazs Lengyel CC: Phil Shafer , netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <200606201618.k5KGIvwn034000@idle.juniper.net> <449A68F8.8010608@ericsson.com> In-Reply-To: <449A68F8.8010608@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Balazs Lengyel wrote: >... > 3) > > I'm not prepared to be the first lamb on that altar. ;^) > Someone has to be :-) otherwise NETCONF is dead already. > Agreed. What is especially depressing: 1) Notification filtering and delivery is a well understood problem, traditionally handled with NV-stored configuration on the notification generator. 2) This is a relatively simple configurable feature on a complex networking device such as a router. 3) If the NETCONF WG cannot (or does not) use the NETCONF protocol to configure the NETCONF protocol, then nobody else will use it either. 4) If something as basic as a filtering table and notification generation parameters are not appropriate for implementation as a standard data model (accessed with and ), then what is an appropriate use of the NETCONF protocol standard operations and standard data models? 5) If you can define a representation of a 'feature' in a data model for monitoring, then you've already done most of the work for configuration. Read-only vs. read-write is an artificial attribute. > Balazs Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 10:49:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQUm-0005Mc-3Q for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 10:49:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQUj-0004pO-Ia for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 10:49:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQRW-000EhA-19 for netconf-data@psg.com; Thu, 22 Jun 2006 14:46:02 +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 [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQRS-000Egc-Ka for netconf@ops.ietf.org; Thu, 22 Jun 2006 14:45:58 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5MEjtx04687 for ; Thu, 22 Jun 2006 10:45:55 -0400 (EDT) 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: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Date: Thu, 22 Jun 2006 10:44:41 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4095C5D49@zcarhxm2.corp.nortel.com> In-Reply-To: <449AA791.4000408@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: AcaWCNmZ+EUuFCi8TIy2dc4lEG8FxAAAC3pw From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 hi If the working group gets too obsessed with architectural purity at the expense of usability to the operators and management applications trying to use an implementation of the protocol I think we are more in trouble. I've suggested previously the following criteria before deciding whether it was appropriate to create a new verb: 1. Is it possible to perform this with existing verbs without exploiting data model side efforts or being ridiculously complicated? 2. Is this operation a management operation and if so does it make sense for a management protocol to provide this function natively? I think the argument for this verb falls more out of the second question. Providing it native in the protocol operation keeps it simple, easy to use and highlights its importance over arbitrary bits of configuration.=20 And why do we have and again?=20 Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, June 22, 2006 10:22 AM To: Balazs Lengyel Cc: Phil Shafer; netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt Balazs Lengyel wrote: >... > 3) > > I'm not prepared to be the first lamb on that altar. ;^) Someone=20 >has to be :-) otherwise NETCONF is dead already. >=20 Agreed. What is especially depressing: 1) Notification filtering and delivery is a well understood problem, traditionally handled with NV-stored configuration on the notification generator. 2) This is a relatively simple configurable feature on a complex networking device such as a router. 3) If the NETCONF WG cannot (or does not) use the NETCONF protocol to configure the NETCONF protocol, then nobody else will use it either. 4) If something as basic as a filtering table and notification generation parameters are not appropriate for implementation as a standard data model (accessed with and ), then what is an appropriate use of the NETCONF protocol standard operations and standard data models? 5) If you can define a representation of a 'feature' in a data model for monitoring, then you've already done most of the work for configuration. Read-only vs. read-write is an artificial attribute. > Balazs Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 11:24:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtR2X-0006L6-QK for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 11:24:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtR2W-0001dG-C5 for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 11:24:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQyE-000HU5-BH for netconf-data@psg.com; Thu, 22 Jun 2006 15:19:50 +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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQy3-000HTO-Ok for netconf@ops.ietf.org; Thu, 22 Jun 2006 15:19:39 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5MFJcfG005438 for ; Thu, 22 Jun 2006 11:19:39 -0400 Received: (qmail 25942 invoked by uid 78); 22 Jun 2006 15:19:37 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 22 Jun 2006 15:19:37 -0000 Message-ID: <449AB532.6030105@andybierman.com> Date: Thu, 22 Jun 2006 08:20:18 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <713043CE8B8E1348AF3C546DBE02C1B4095C5D49@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4095C5D49@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Sharon Chisholm wrote: > hi > > If the working group gets too obsessed with architectural purity at the > expense of usability to the operators and management applications trying > to use an implementation of the protocol I think we are more in trouble. > I really disagree with this comment. We spent about 5 years developing a set of standard operations for the standard manipulation of NV-stored configuration data models encoded in XML. Instead of using it, some people want to pretend that filtering parameters do not fall in the category of NV-stored configuration data. > I've suggested previously the following criteria before deciding whether > it was appropriate to create a new verb: > > 1. Is it possible to perform this with existing verbs without exploiting > data model side efforts or being ridiculously complicated? > 2. Is this operation a management operation and if so does it make sense > for a management protocol to provide this function natively? > > I think the argument for this verb falls more out of the second > question. Providing it native in the protocol operation keeps it simple, > easy to use and highlights its importance over arbitrary bits of > configuration. > I think you are missing the point. Balazs and I are not saying that a verb to start the delivery of notifications is a problem. I totally agree with this approach, rather than the SNMP MIB approach of turning the knob to 'enabled' in the data model. Let's get past this point, okay? The problem is that many of the parameters (especially the most complicated part -- the filters) should be implemented as a read-create standard data model using the existing operation, and retrieval of these parameters and notification state information should be done with the operation. > And why do we have and again? To retrieve data > > Sharon > Andy > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, June 22, 2006 10:22 AM > To: Balazs Lengyel > Cc: Phil Shafer; netconf@ops.ietf.org > Subject: Re: draft-shafer-netconf-syslog-00.txt > > > Balazs Lengyel wrote: >> ... >> 3) >> > I'm not prepared to be the first lamb on that altar. ;^) Someone >> has to be :-) otherwise NETCONF is dead already. >> > > Agreed. > What is especially depressing: > > 1) Notification filtering and delivery is a well understood problem, > traditionally handled with NV-stored configuration on the > notification generator. > > 2) This is a relatively simple configurable feature on a > complex networking device such as a router. > > 3) If the NETCONF WG cannot (or does not) use the > NETCONF protocol to configure the NETCONF protocol, > then nobody else will use it either. > > 4) If something as basic as a filtering table and notification > generation parameters are not appropriate for implementation as a > standard data model (accessed with and ), > then what is an appropriate use of the NETCONF protocol > standard operations and standard data models? > > 5) If you can define a representation of a 'feature' in a data model > for monitoring, then you've already done most of the work for > configuration. Read-only vs. read-write is an artificial > attribute. > > >> Balazs > > > Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 12:03:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRem-0003xT-W5 for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 12:03:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRel-0006Sh-DL for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 12:03:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtRa7-000KZ4-Rr for netconf-data@psg.com; Thu, 22 Jun 2006 15:58: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.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtRa6-000KYn-Gm for netconf@ops.ietf.org; Thu, 22 Jun 2006 15:58:58 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k5MFrUI06114 for ; Thu, 22 Jun 2006 11:53:30 -0400 (EDT) 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: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Date: Thu, 22 Jun 2006 11:58:49 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4095C5F20@zcarhxm2.corp.nortel.com> In-Reply-To: <449AB532.6030105@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: AcaWD0rDLwQ7avjkSRuG+VW/nQkWPQABNuqA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Eureka.=20 So, we are closer then I thought. This is good to news. So, the current proposal has two approaches: 1) Provide the filters as parameters=20 2) Provide a pointer to the named profile which is a chunk of XML Schema and you think that 1)is rubbish and much prefer 2). My main problem with 2) is that it opens things up for over-engineering and it also makes the network element the authoritative source of the subscription parameters while I really want the netconf client to be. It also has some garbage collection issues. Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Thursday, June 22, 2006 11:20 AM To: Chisholm, Sharon [CAR:ZZ00:EXCH] Cc: netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Sharon Chisholm wrote: > hi >=20 > If the working group gets too obsessed with architectural purity at=20 > the expense of usability to the operators and management applications=20 > trying to use an implementation of the protocol I think we are more in > trouble. >=20 I really disagree with this comment. We spent about 5 years developing a set of standard operations for the standard manipulation of NV-stored configuration data models encoded in XML. Instead of using it, some people want to pretend that filtering parameters do not fall in the category of NV-stored configuration data. > I've suggested previously the following criteria before deciding=20 > whether it was appropriate to create a new verb: >=20 > 1. Is it possible to perform this with existing verbs without=20 > exploiting data model side efforts or being ridiculously complicated?=20 > 2. Is this operation a management operation and if so does it make=20 > sense for a management protocol to provide this function natively? >=20 > I think the argument for this verb falls more out of the second=20 > question. Providing it native in the protocol operation keeps it=20 > simple, easy to use and highlights its importance over arbitrary bits=20 > of configuration. >=20 I think you are missing the point. Balazs and I are not saying that a verb to start the delivery of notifications is a problem. I totally agree with this approach, rather than the SNMP MIB approach of turning the knob to 'enabled' in the data model. Let's get past this point, okay? The problem is that many of the parameters (especially the most complicated part -- the filters) should be implemented as a read-create standard data model using the existing operation, and retrieval of these parameters and notification state information should be done with the operation. > And why do we have and again? To retrieve data >=20 > Sharon >=20 Andy > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]=20 > On Behalf Of Andy Bierman > Sent: Thursday, June 22, 2006 10:22 AM > To: Balazs Lengyel > Cc: Phil Shafer; netconf@ops.ietf.org > Subject: Re: draft-shafer-netconf-syslog-00.txt >=20 >=20 > Balazs Lengyel wrote: >> ... >> 3) >> > I'm not prepared to be the first lamb on that altar. ;^) Someone >> has to be :-) otherwise NETCONF is dead already. >> >=20 > Agreed. > What is especially depressing: >=20 > 1) Notification filtering and delivery is a well understood problem, > traditionally handled with NV-stored configuration on the > notification generator. >=20 > 2) This is a relatively simple configurable feature on a > complex networking device such as a router. >=20 > 3) If the NETCONF WG cannot (or does not) use the > NETCONF protocol to configure the NETCONF protocol, > then nobody else will use it either. >=20 > 4) If something as basic as a filtering table and notification > generation parameters are not appropriate for implementation as a > standard data model (accessed with and ), > then what is an appropriate use of the NETCONF protocol > standard operations and standard data models? >=20 > 5) If you can define a representation of a 'feature' in a data model > for monitoring, then you've already done most of the work for > configuration. Read-only vs. read-write is an artificial > attribute. >=20 >=20 >> Balazs >=20 >=20 > Andy >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 12:42:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSGc-0002vk-Ap for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 12:42:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSGa-0008So-QA for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 12:42:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtS9p-000NGX-3O for netconf-data@psg.com; Thu, 22 Jun 2006 16:35:53 +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 1FtS9i-000NGE-V0 for netconf@ops.ietf.org; Thu, 22 Jun 2006 16:35:52 +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 k5MGZe5a007391 for ; Thu, 22 Jun 2006 12:35:46 -0400 Received: (qmail 6114 invoked by uid 78); 22 Jun 2006 16:35:36 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 22 Jun 2006 16:35:36 -0000 Message-ID: <449AC703.3020301@andybierman.com> Date: Thu, 22 Jun 2006 09:36:19 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <713043CE8B8E1348AF3C546DBE02C1B4095C5F20@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4095C5F20@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Sharon Chisholm wrote: > Eureka. > > So, we are closer then I thought. This is good to news. So, the current > proposal has two approaches: > > 1) Provide the filters as parameters > 2) Provide a pointer to the named profile which is a chunk of XML Schema > > and you think that 1)is rubbish and much prefer 2). > > My main problem with 2) is that it opens things up for over-engineering > and it also makes the network element the authoritative source of the > subscription parameters while I really want the netconf client to be. It > also has some garbage collection issues. Forcing every manager application to come up with the correct filtering parameters every time a new session is started is extremely inefficient for both the manager and the agent. Using sharable, NV-stored parameters on the agent, configured by the authoritative manager, applications are not forced to maintain the possibly massive set of notification filters on their own. It is very inefficient for the agent to parse, validate, setup and store all the filtering parameters, every time a session that wants notifications starts up, and duplicated for every session. IMO, these inefficiencies dwarf the task of removing NV-stored filters on the agent that are no longer of interest to any management application. > > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, June 22, 2006 11:20 AM > To: Chisholm, Sharon [CAR:ZZ00:EXCH] > Cc: netconf@ops.ietf.org > Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) > > > Sharon Chisholm wrote: >> hi >> >> If the working group gets too obsessed with architectural purity at >> the expense of usability to the operators and management applications >> trying to use an implementation of the protocol I think we are more in > >> trouble. >> > > I really disagree with this comment. > We spent about 5 years developing a set of standard operations for the > standard manipulation of NV-stored configuration data models encoded in > XML. Instead of using it, some people want to pretend that filtering > parameters do not fall in the category of NV-stored configuration data. > > >> I've suggested previously the following criteria before deciding >> whether it was appropriate to create a new verb: >> >> 1. Is it possible to perform this with existing verbs without >> exploiting data model side efforts or being ridiculously complicated? >> 2. Is this operation a management operation and if so does it make >> sense for a management protocol to provide this function natively? >> >> I think the argument for this verb falls more out of the second >> question. Providing it native in the protocol operation keeps it >> simple, easy to use and highlights its importance over arbitrary bits >> of configuration. >> > > I think you are missing the point. > Balazs and I are not saying that a verb to start > the delivery of notifications is a problem. > I totally agree with this approach, rather > than the SNMP MIB approach of turning the knob > to 'enabled' in the data model. Let's get past this point, okay? > > The problem is that many of the parameters > (especially the most complicated part -- the filters) > should be implemented as a read-create standard > data model using the existing operation, > and retrieval of these parameters and notification > state information should be done with the operation. > > >> And why do we have and again? > > To retrieve data > >> Sharon >> > > Andy > > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >> On Behalf Of Andy Bierman >> Sent: Thursday, June 22, 2006 10:22 AM >> To: Balazs Lengyel >> Cc: Phil Shafer; netconf@ops.ietf.org >> Subject: Re: draft-shafer-netconf-syslog-00.txt >> >> >> Balazs Lengyel wrote: >>> ... >>> 3) >>> > I'm not prepared to be the first lamb on that altar. ;^) Someone >>> has to be :-) otherwise NETCONF is dead already. >>> >> Agreed. >> What is especially depressing: >> >> 1) Notification filtering and delivery is a well understood problem, >> traditionally handled with NV-stored configuration on the >> notification generator. >> >> 2) This is a relatively simple configurable feature on a >> complex networking device such as a router. >> >> 3) If the NETCONF WG cannot (or does not) use the >> NETCONF protocol to configure the NETCONF protocol, >> then nobody else will use it either. >> >> 4) If something as basic as a filtering table and notification >> generation parameters are not appropriate for implementation as a >> standard data model (accessed with and > ), >> then what is an appropriate use of the NETCONF protocol >> standard operations and standard data models? >> >> 5) If you can define a representation of a 'feature' in a data model >> for monitoring, then you've already done most of the work for >> configuration. Read-only vs. read-write is an artificial >> attribute. >> >> >>> Balazs >> >> Andy >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the > >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the > >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >> > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Jun 22 12:57:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSUN-0006ge-Nv for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 12:57:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSUM-0000dM-EY for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 12:57:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtSRN-000One-Ot for netconf-data@psg.com; Thu, 22 Jun 2006 16:54:01 +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 1FtSRM-000OnK-TB for netconf@ops.ietf.org; Thu, 22 Jun 2006 16:54:01 +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 k5MGruSc028338 for ; Thu, 22 Jun 2006 12:53:57 -0400 Received: (qmail 27077 invoked by uid 78); 22 Jun 2006 16:53:56 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 22 Jun 2006 16:53:56 -0000 Message-ID: <449ACB5B.5060908@andybierman.com> Date: Thu, 22 Jun 2006 09:54:51 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: session-specific parameters 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: ea4ac80f790299f943f0a53be7e1a21a Hi, IMO, the only valid reason to pass parameters in the "start notifications" RPC is to send session-specific parameters that do not belong in the NV-stored data model for shared parameters. New term: session-specific parameter: A parameter, for which the particular value of this parameter can conceptually only be relevant to the specific session using the parameter. Examples: TimeFilter, retrieve notifications since time-N, requested max-buffer-size Note that the particular values of content filtering parameters are relevant across sessions, devices, and even vendors, and therefore are not session-specific parameters. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 13:35:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtT5r-00067W-Db for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 13:35:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtT5q-0002Yq-2P for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 13:35:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtT1m-0001mM-Ke for netconf-data@psg.com; Thu, 22 Jun 2006 17:31: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.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtT1l-0001m9-7B for netconf@ops.ietf.org; Thu, 22 Jun 2006 17:31:37 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5MHVYx20907 for ; Thu, 22 Jun 2006 13:31:34 -0400 (EDT) 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: Update to Netconf Notifications Draft Date: Thu, 22 Jun 2006 13:31:29 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4095C617F@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4095C5B02@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update to Netconf Notifications Draft Thread-Index: AcaV/rKl5rkt8OrbQcOoOn5AS8jbMgAItswg From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 hi The draft can now we found at =09 http://standards.nortel.com/netconf/docs/netconfEvent/pre_02-netconf-not ification.txt Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon [CAR:ZZ00:EXCH] Sent: Thursday, June 22, 2006 9:21 AM To: netconf@ops.ietf.org Subject: Update to Netconf Notifications Draft hi I have submitted the updated Netconf Event Notification Draft. There appears to be a problem with my website, so I can't post a version for people to read while waiting for real one. When the site is back up, I'll make a copy available. The update is as promised in the emails I sent with the proposed updates, with the following exceptions 1. I was hoping for some specific inputs to help flesh out the call home section but didn't receive it. These changes will have to wait for the next version. 2. I had said we would clarify that the filters would be applied against the content of the filters but when I went to make the change I realized the intention was that filters were applied against the notification itself, not the content. By this I mean that either through sub tree of XPath the element that defines the notification has a handle that we can use for filtering against the notification. I've added clarification around that instead, but in hindsight perhaps I could have explained it better. 3. It was suggested that instead of spreading the examples throughout the document that they get co-located in the document. In thinking about this more, I think it is useful to have examples in-line to help explain various ideas. This would not preclude having a more comprehensive example section though. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-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 Jun 22 14:10:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTdS-0008Ud-AI for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:10:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTdR-0004k9-QJ for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:10:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtTaD-0004US-Ho for netconf-data@psg.com; Thu, 22 Jun 2006 18:07: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtTaA-0004TR-9l for netconf@ops.ietf.org; Thu, 22 Jun 2006 18:07:10 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 22 Jun 2006 11:07:10 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="556960536:sNHT49440432" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 11:07:09 -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: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Date: Thu, 22 Jun 2006 11:07:08 -0700 Message-ID: In-Reply-To: <449AC703.3020301@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: AcaWGgf5xtv0HrMiQ7eFHU7Lsw+crQAClOTA From: "Kent Watsen" To: "Andy Bierman" , "Sharon Chisholm" Cc: X-OriginalArrivalTime: 22 Jun 2006 18:07:09.0696 (UTC) FILETIME=[ADE3F800:01C69626] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 I agree with Sharon on this. There are clear differences between session-specific and device-wide parameters. There is the obvious bit about session-specific parameters being cleared when the session drops; but more importantly is that no two sessions (i.e. applications) should be aware of what any other session/app is up to - this principle is violated if session-specific params are NV-stored Also, while Andy is correct that session-specific filters do require more parsing, validating, and setup - this overhead is dwarfed by the device actually forwarding the notifications to the client over the course of the session BTW, Phil's proposal is good wrt all this in that it uses device-wide streams (i.e. topics) on which session-specific filters can be applied. Kent -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Thursday, June 22, 2006 9:36 AM To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Sharon Chisholm wrote: > Eureka.=20 >=20 > So, we are closer then I thought. This is good to news. So, the current > proposal has two approaches: >=20 > 1) Provide the filters as parameters=20 > 2) Provide a pointer to the named profile which is a chunk of XML Schema >=20 > and you think that 1)is rubbish and much prefer 2). >=20 > My main problem with 2) is that it opens things up for over-engineering > and it also makes the network element the authoritative source of the > subscription parameters while I really want the netconf client to be. It > also has some garbage collection issues. Forcing every manager application to come up with the correct filtering parameters every time a new session is started is extremely inefficient for both the manager and the agent. Using sharable, NV-stored parameters on the agent, configured by the authoritative manager, applications are not forced to maintain the possibly massive set of notification filters on their own. It is very inefficient for the agent to parse, validate, setup and store all the filtering parameters, every time a session that wants notifications starts up, and duplicated for every session. IMO, these inefficiencies dwarf the task of removing NV-stored filters on the agent that are no longer of interest to any management application. >=20 > Sharon Andy >=20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Thursday, June 22, 2006 11:20 AM > To: Chisholm, Sharon [CAR:ZZ00:EXCH] > Cc: netconf@ops.ietf.org > Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >=20 >=20 > Sharon Chisholm wrote: >> hi >> >> If the working group gets too obsessed with architectural purity at=20 >> the expense of usability to the operators and management applications >> trying to use an implementation of the protocol I think we are more in >=20 >> trouble. >> >=20 > I really disagree with this comment. > We spent about 5 years developing a set of standard operations for the > standard manipulation of NV-stored configuration data models encoded in > XML. Instead of using it, some people want to pretend that filtering > parameters do not fall in the category of NV-stored configuration data. >=20 >=20 >> I've suggested previously the following criteria before deciding=20 >> whether it was appropriate to create a new verb: >> >> 1. Is it possible to perform this with existing verbs without=20 >> exploiting data model side efforts or being ridiculously complicated? >> 2. Is this operation a management operation and if so does it make=20 >> sense for a management protocol to provide this function natively? >> >> I think the argument for this verb falls more out of the second=20 >> question. Providing it native in the protocol operation keeps it=20 >> simple, easy to use and highlights its importance over arbitrary bits >> of configuration. >> >=20 > I think you are missing the point. > Balazs and I are not saying that a verb to start > the delivery of notifications is a problem. > I totally agree with this approach, rather > than the SNMP MIB approach of turning the knob > to 'enabled' in the data model. Let's get past this point, okay? >=20 > The problem is that many of the parameters > (especially the most complicated part -- the filters) > should be implemented as a read-create standard > data model using the existing operation, > and retrieval of these parameters and notification > state information should be done with the operation. >=20 >=20 >> And why do we have and again? >=20 > To retrieve data >=20 >> Sharon >> >=20 > Andy >=20 >=20 >=20 >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]=20 >> On Behalf Of Andy Bierman >> Sent: Thursday, June 22, 2006 10:22 AM >> To: Balazs Lengyel >> Cc: Phil Shafer; netconf@ops.ietf.org >> Subject: Re: draft-shafer-netconf-syslog-00.txt >> >> >> Balazs Lengyel wrote: >>> ... >>> 3) >>> > I'm not prepared to be the first lamb on that altar. ;^) Someone >>> has to be :-) otherwise NETCONF is dead already. >>> >> Agreed. >> What is especially depressing: >> >> 1) Notification filtering and delivery is a well understood problem, >> traditionally handled with NV-stored configuration on the >> notification generator. >> >> 2) This is a relatively simple configurable feature on a >> complex networking device such as a router. >> >> 3) If the NETCONF WG cannot (or does not) use the >> NETCONF protocol to configure the NETCONF protocol, >> then nobody else will use it either. >> >> 4) If something as basic as a filtering table and notification >> generation parameters are not appropriate for implementation as a >> standard data model (accessed with and > ), >> then what is an appropriate use of the NETCONF protocol >> standard operations and standard data models? >> >> 5) If you can define a representation of a 'feature' in a data model >> for monitoring, then you've already done most of the work for >> configuration. Read-only vs. read-write is an artificial >> attribute. >> >> >>> Balazs >> >> Andy >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the >=20 >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with the >=20 >> word 'unsubscribe' in a single line as the message text body. >> archive: >> >> >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=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 Thu Jun 22 14:23:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTqE-0005RI-6j for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:23:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTqD-0005z1-M6 for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:23:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtTn5-0005St-C7 for netconf-data@psg.com; Thu, 22 Jun 2006 18:20:31 +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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtTn4-0005Sf-7y for netconf@ops.ietf.org; Thu, 22 Jun 2006 18:20:30 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5MIKTH5005303 for ; Thu, 22 Jun 2006 14:20:29 -0400 Received: (qmail 4337 invoked by uid 78); 22 Jun 2006 18:20:04 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 22 Jun 2006 18:20:04 -0000 Message-ID: <449ADF98.3000005@andybierman.com> Date: Thu, 22 Jun 2006 11:21:12 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kent Watsen CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Kent Watsen wrote: > I agree with Sharon on this. There are clear differences between > session-specific and device-wide parameters. There is the obvious bit > about session-specific parameters being cleared when the session drops; > but more importantly is that no two sessions (i.e. applications) should > be aware of what any other session/app is up to - this principle is > violated if session-specific params are NV-stored > fine > Also, while Andy is correct that session-specific filters do require > more parsing, validating, and setup - this overhead is dwarfed by the > device actually forwarding the notifications to the client over the > course of the session > > BTW, Phil's proposal is good wrt all this in that it uses device-wide > streams (i.e. topics) on which session-specific filters can be applied. > Neither proposal allows for NV-storage of parameters which are not session-specific. This is a major problem. > Kent Andy > > > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, June 22, 2006 9:36 AM > To: Sharon Chisholm > Cc: netconf@ops.ietf.org > Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) > > Sharon Chisholm wrote: >> Eureka. >> >> So, we are closer then I thought. This is good to news. So, the > current >> proposal has two approaches: >> >> 1) Provide the filters as parameters >> 2) Provide a pointer to the named profile which is a chunk of XML > Schema >> and you think that 1)is rubbish and much prefer 2). >> >> My main problem with 2) is that it opens things up for > over-engineering >> and it also makes the network element the authoritative source of the >> subscription parameters while I really want the netconf client to be. > It >> also has some garbage collection issues. > > Forcing every manager application to come up with the correct > filtering parameters every time a new session is started is > extremely inefficient for both the manager and the agent. > > Using sharable, NV-stored parameters on the agent, configured by > the authoritative manager, applications are not forced to > maintain the possibly massive set of notification filters on their > own. > > It is very inefficient for the agent to parse, validate, setup > and store all the filtering parameters, every time a session > that wants notifications starts up, and duplicated for every session. > > IMO, these inefficiencies dwarf the task of removing > NV-stored filters on the agent that are no longer of interest > to any management application. > > >> Sharon > > Andy > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Thursday, June 22, 2006 11:20 AM >> To: Chisholm, Sharon [CAR:ZZ00:EXCH] >> Cc: netconf@ops.ietf.org >> Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >> >> >> Sharon Chisholm wrote: >>> hi >>> >>> If the working group gets too obsessed with architectural purity at >>> the expense of usability to the operators and management applications > >>> trying to use an implementation of the protocol I think we are more > in >>> trouble. >>> >> I really disagree with this comment. >> We spent about 5 years developing a set of standard operations for the >> standard manipulation of NV-stored configuration data models encoded > in >> XML. Instead of using it, some people want to pretend that filtering >> parameters do not fall in the category of NV-stored configuration > data. >> >>> I've suggested previously the following criteria before deciding >>> whether it was appropriate to create a new verb: >>> >>> 1. Is it possible to perform this with existing verbs without >>> exploiting data model side efforts or being ridiculously complicated? > >>> 2. Is this operation a management operation and if so does it make >>> sense for a management protocol to provide this function natively? >>> >>> I think the argument for this verb falls more out of the second >>> question. Providing it native in the protocol operation keeps it >>> simple, easy to use and highlights its importance over arbitrary bits > >>> of configuration. >>> >> I think you are missing the point. >> Balazs and I are not saying that a verb to start >> the delivery of notifications is a problem. >> I totally agree with this approach, rather >> than the SNMP MIB approach of turning the knob >> to 'enabled' in the data model. Let's get past this point, okay? >> >> The problem is that many of the parameters >> (especially the most complicated part -- the filters) >> should be implemented as a read-create standard >> data model using the existing operation, >> and retrieval of these parameters and notification >> state information should be done with the operation. >> >> >>> And why do we have and again? >> To retrieve data >> >>> Sharon >>> >> Andy >> >> >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>> On Behalf Of Andy Bierman >>> Sent: Thursday, June 22, 2006 10:22 AM >>> To: Balazs Lengyel >>> Cc: Phil Shafer; netconf@ops.ietf.org >>> Subject: Re: draft-shafer-netconf-syslog-00.txt >>> >>> >>> Balazs Lengyel wrote: >>>> ... >>>> 3) >>>> > I'm not prepared to be the first lamb on that altar. ;^) > Someone >>>> has to be :-) otherwise NETCONF is dead already. >>>> >>> Agreed. >>> What is especially depressing: >>> >>> 1) Notification filtering and delivery is a well understood > problem, >>> traditionally handled with NV-stored configuration on the >>> notification generator. >>> >>> 2) This is a relatively simple configurable feature on a >>> complex networking device such as a router. >>> >>> 3) If the NETCONF WG cannot (or does not) use the >>> NETCONF protocol to configure the NETCONF protocol, >>> then nobody else will use it either. >>> >>> 4) If something as basic as a filtering table and notification >>> generation parameters are not appropriate for implementation as > a >>> standard data model (accessed with and >> ), >>> then what is an appropriate use of the NETCONF protocol >>> standard operations and standard data models? >>> >>> 5) If you can define a representation of a 'feature' in a data > model >>> for monitoring, then you've already done most of the work for >>> configuration. Read-only vs. read-write is an artificial >>> attribute. >>> >>> >>>> Balazs >>> Andy >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with > the >>> word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with > the >>> word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >>> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> > > > -- > to 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 Jun 22 14:29:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTwB-0002Gh-Fy for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:29:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTwA-0006Nv-5r for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:29:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtTsh-0005wH-4x for netconf-data@psg.com; Thu, 22 Jun 2006 18:26: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.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtTsg-0005w2-CJ for netconf@ops.ietf.org; Thu, 22 Jun 2006 18:26:18 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5MIQH9C030594 for ; Thu, 22 Jun 2006 14:26:17 -0400 Received: (qmail 11064 invoked by uid 78); 22 Jun 2006 18:26:17 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 22 Jun 2006 18:26:17 -0000 Message-ID: <449AE10D.5010707@andybierman.com> Date: Thu, 22 Jun 2006 11:27:25 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kent Watsen CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Kent Watsen wrote: >... > > Also, while Andy is correct that session-specific filters do require > more parsing, validating, and setup - this overhead is dwarfed by the > device actually forwarding the notifications to the client over the > course of the session > >... This is irrelevant to the discussion because the agent has to send the notification regardless of how it is configured. We are comparing the relative overhead of different schemes to start notification delivery. > Kent Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 14:47:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUD4-0006ze-9F for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:47:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUD3-0008P6-0J for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 14:47:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtU9v-0007JD-2T for netconf-data@psg.com; Thu, 22 Jun 2006 18:44: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [209.128.82.1] (helo=shell4.bayarea.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtU9u-0007Iz-Hu for netconf@ops.ietf.org; Thu, 22 Jun 2006 18:44:06 +0000 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5MIi4m5021954; Thu, 22 Jun 2006 11:44:04 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5MIi4CL021944; Thu, 22 Jun 2006 11:44:04 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 22 Jun 2006 11:44:03 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Andy Bierman cc: netconf@ops.ietf.org Subject: Notification delivery In-Reply-To: <449AE10D.5010707@andybierman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d HI, I'm a little confused about the recent messages about notifications. It seems like there are at least two independent issues that are being mashed together. These are: 1) in real time - who do you send notification to, and what filtering (if any) do you apply before sending them? Also, in addition (or instead) of sending notifications, you might want put them in a log. To me, this is configuration of a) notification targets (a network entity or "local" log) b) filters c) log management 2) historical - on systems that have logs (with one being a notification log), extracting entries from the log. To me, this is state retrieval of: a) list of logs (and attributes) b) content of a log (specific log records) In both cases, there are security concerns, primarily access control to the notification info (in real-time, or later looking through a log). So, tell me, are they separate, or have I missed the connecting part. If so, what is it? Regards, /david t. perkins -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 15:03:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUSj-0002aE-9c for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 15:03:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUSh-0002Fl-Sn for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 15:03:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtUPa-0008Xi-Lh for netconf-data@psg.com; Thu, 22 Jun 2006 19:00:18 +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 [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtUPZ-0008XV-JB for netconf@ops.ietf.org; Thu, 22 Jun 2006 19:00:17 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) by mail.tail-f.com (Postfix) with ESMTP id A71811B8011; Thu, 22 Jun 2006 21:00:15 +0200 (CEST) Date: Thu, 22 Jun 2006 21:00:13 +0200 (CEST) Message-Id: <20060622.210013.11944118.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: Verbs Again From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4095C5D49@zcarhxm2.corp.nortel.com> References: <449AA791.4000408@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4095C5D49@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d "Sharon Chisholm" wrote: > hi > > If the working group gets too obsessed with architectural purity at the > expense of usability to the operators and management applications trying > to use an implementation of the protocol I think we are more in trouble. > > I've suggested previously the following criteria before deciding whether > it was appropriate to create a new verb: > > 1. Is it possible to perform this with existing verbs without exploiting > data model side efforts or being ridiculously complicated? > 2. Is this operation a management operation and if so does it make sense > for a management protocol to provide this function natively? > > I think the argument for this verb falls more out of the second > question. Are we still talking about from Phil's draft? That's the verb that some us thought was better done as a data model and and . /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 15:07:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUW8-0005q1-JI for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 15:07:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUW7-00033k-A8 for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 15:07:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtUSb-0008on-OK for netconf-data@psg.com; Thu, 22 Jun 2006 19:03:25 +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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtUSb-0008oZ-4j for netconf@ops.ietf.org; Thu, 22 Jun 2006 19:03:25 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5MJ3Ocp018844 for ; Thu, 22 Jun 2006 15:03:24 -0400 Received: (qmail 22569 invoked by uid 78); 22 Jun 2006 19:03:24 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 22 Jun 2006 19:03:24 -0000 Message-ID: <449AE9C6.6090402@andybierman.com> Date: Thu, 22 Jun 2006 12:04:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "David T. Perkins" CC: netconf@ops.ietf.org Subject: Re: Notification delivery 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: 8abaac9e10c826e8252866cbe6766464 David T. Perkins wrote: > HI, > > I'm a little confused about the recent messages about notifications. > > It seems like there are at least two independent issues > that are being mashed together. > > These are: > 1) in real time - who do you send notification to, and This part is already determined by the session. Left out of this entire discussion is the assumption that the Callhome mechanism will be generalized and fully specified in a separate document, so the agent can connect to the manager over SSH or BEEP and say "ask me to send you notifications". ... > Regards, > /david t. perkins > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 15:37:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUze-0007qz-52 for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 15:37:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUzd-0003HG-Hx for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 15:37:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtUvB-000BAY-He for netconf-data@psg.com; Thu, 22 Jun 2006 19:32: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 [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtUvA-000BAL-JZ for netconf@ops.ietf.org; Thu, 22 Jun 2006 19:32:56 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 22 Jun 2006 12:32:56 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="556980019:sNHT48950036" Received: from antitop.jnpr.net ([172.24.15.27]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 12:32:50 -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: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Date: Thu, 22 Jun 2006 12:32:49 -0700 Message-ID: In-Reply-To: <449ADF98.3000005@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: AcaWKKE5LYKiEst1Q/yXk94s17xcpAACS7zA From: "Kent Watsen" To: "Andy Bierman" Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 22 Jun 2006 19:32:50.0291 (UTC) FILETIME=[A5EC8430:01C69632] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e > Neither proposal allows for NV-storage of parameters > which are not session-specific. =20 There is nothing in either proposal that limits the device from also having static configuration for forwarding events to a standard syslog server - these proposals are specific to forwarding events over a NetConf session... Kent -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Thursday, June 22, 2006 11:21 AM To: Kent Watsen Cc: Sharon Chisholm; netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Kent Watsen wrote: > I agree with Sharon on this. There are clear differences between > session-specific and device-wide parameters. There is the obvious bit > about session-specific parameters being cleared when the session drops; > but more importantly is that no two sessions (i.e. applications) should > be aware of what any other session/app is up to - this principle is > violated if session-specific params are NV-stored >=20 fine > Also, while Andy is correct that session-specific filters do require > more parsing, validating, and setup - this overhead is dwarfed by the > device actually forwarding the notifications to the client over the > course of the session >=20 > BTW, Phil's proposal is good wrt all this in that it uses device-wide > streams (i.e. topics) on which session-specific filters can be applied. >=20 Neither proposal allows for NV-storage of parameters which are not session-specific. This is a major problem. > Kent Andy >=20 >=20 >=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, June 22, 2006 9:36 AM > To: Sharon Chisholm > Cc: netconf@ops.ietf.org > Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >=20 > Sharon Chisholm wrote: >> Eureka.=20 >> >> So, we are closer then I thought. This is good to news. So, the > current >> proposal has two approaches: >> >> 1) Provide the filters as parameters=20 >> 2) Provide a pointer to the named profile which is a chunk of XML > Schema >> and you think that 1)is rubbish and much prefer 2). >> >> My main problem with 2) is that it opens things up for > over-engineering >> and it also makes the network element the authoritative source of the >> subscription parameters while I really want the netconf client to be. > It >> also has some garbage collection issues. >=20 > Forcing every manager application to come up with the correct > filtering parameters every time a new session is started is > extremely inefficient for both the manager and the agent. >=20 > Using sharable, NV-stored parameters on the agent, configured by > the authoritative manager, applications are not forced to > maintain the possibly massive set of notification filters on their > own. >=20 > It is very inefficient for the agent to parse, validate, setup > and store all the filtering parameters, every time a session > that wants notifications starts up, and duplicated for every session. >=20 > IMO, these inefficiencies dwarf the task of removing > NV-stored filters on the agent that are no longer of interest > to any management application. >=20 >=20 >> Sharon >=20 > Andy >=20 >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com]=20 >> Sent: Thursday, June 22, 2006 11:20 AM >> To: Chisholm, Sharon [CAR:ZZ00:EXCH] >> Cc: netconf@ops.ietf.org >> Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >> >> >> Sharon Chisholm wrote: >>> hi >>> >>> If the working group gets too obsessed with architectural purity at=20 >>> the expense of usability to the operators and management applications >=20 >>> trying to use an implementation of the protocol I think we are more > in >>> trouble. >>> >> I really disagree with this comment. >> We spent about 5 years developing a set of standard operations for the >> standard manipulation of NV-stored configuration data models encoded > in >> XML. Instead of using it, some people want to pretend that filtering >> parameters do not fall in the category of NV-stored configuration > data. >> >>> I've suggested previously the following criteria before deciding=20 >>> whether it was appropriate to create a new verb: >>> >>> 1. Is it possible to perform this with existing verbs without=20 >>> exploiting data model side efforts or being ridiculously complicated? >=20 >>> 2. Is this operation a management operation and if so does it make=20 >>> sense for a management protocol to provide this function natively? >>> >>> I think the argument for this verb falls more out of the second=20 >>> question. Providing it native in the protocol operation keeps it=20 >>> simple, easy to use and highlights its importance over arbitrary bits >=20 >>> of configuration. >>> >> I think you are missing the point. >> Balazs and I are not saying that a verb to start >> the delivery of notifications is a problem. >> I totally agree with this approach, rather >> than the SNMP MIB approach of turning the knob >> to 'enabled' in the data model. Let's get past this point, okay? >> >> The problem is that many of the parameters >> (especially the most complicated part -- the filters) >> should be implemented as a read-create standard >> data model using the existing operation, >> and retrieval of these parameters and notification >> state information should be done with the operation. >> >> >>> And why do we have and again? >> To retrieve data >> >>> Sharon >>> >> Andy >> >> >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>> On Behalf Of Andy Bierman >>> Sent: Thursday, June 22, 2006 10:22 AM >>> To: Balazs Lengyel >>> Cc: Phil Shafer; netconf@ops.ietf.org >>> Subject: Re: draft-shafer-netconf-syslog-00.txt >>> >>> >>> Balazs Lengyel wrote: >>>> ... >>>> 3) >>>> > I'm not prepared to be the first lamb on that altar. ;^) > Someone >>>> has to be :-) otherwise NETCONF is dead already. >>>> >>> Agreed. >>> What is especially depressing: >>> >>> 1) Notification filtering and delivery is a well understood > problem, >>> traditionally handled with NV-stored configuration on the >>> notification generator. >>> >>> 2) This is a relatively simple configurable feature on a >>> complex networking device such as a router. >>> >>> 3) If the NETCONF WG cannot (or does not) use the >>> NETCONF protocol to configure the NETCONF protocol, >>> then nobody else will use it either. >>> >>> 4) If something as basic as a filtering table and notification >>> generation parameters are not appropriate for implementation as > a >>> standard data model (accessed with and >> ), >>> then what is an appropriate use of the NETCONF protocol >>> standard operations and standard data models? >>> >>> 5) If you can define a representation of a 'feature' in a data > model >>> for monitoring, then you've already done most of the work for >>> configuration. Read-only vs. read-write is an artificial >>> attribute. >>> >>> >>>> Balazs >>> Andy >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with > the >>> word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with > the >>> word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >>> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 16:28:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVmT-0003Wp-0M for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 16:28:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtVmR-0000KU-Dn for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 16:28:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtViL-000FD9-5o for netconf-data@psg.com; Thu, 22 Jun 2006 20:23: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.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtViJ-000FCl-N6 for netconf@ops.ietf.org; Thu, 22 Jun 2006 20:23:44 +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 k5MKNf4m005707 for ; Thu, 22 Jun 2006 16:23:42 -0400 Received: (qmail 10567 invoked by uid 78); 22 Jun 2006 20:23:41 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 22 Jun 2006 20:23:41 -0000 Message-ID: <449AFCA0.7000400@andybierman.com> Date: Thu, 22 Jun 2006 13:25:04 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kent Watsen CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Kent Watsen wrote: >> Neither proposal allows for NV-storage of parameters >> which are not session-specific. > > There is nothing in either proposal that limits the device from also > having static configuration for forwarding events to a standard syslog > server - these proposals are specific to forwarding events over a > NetConf session... I do not think we should replicate the mechanisms already in place for NV-config in any manner whatsoever in the standard. If vendors want to ignore the standard operations and invent their own, then they can do that. Defining new standard mechanisms to get and set specific chunks of standard data, and also defining a separate standard data model for use with the existing standard mechanisms, is a poor design choice. The most complicated part of the notification config is the filtering. This is clearly not a session-specific parameter, and something that several people have said they want to be able to NV-store on the agent. Saying that the standard solution for configuring the netconf standard does not preclude someone from defining additional solutions which provide for NV-storage does not really address the problem. > > Kent Andy > > > > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, June 22, 2006 11:21 AM > To: Kent Watsen > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) > > Kent Watsen wrote: >> I agree with Sharon on this. There are clear differences between >> session-specific and device-wide parameters. There is the obvious bit >> about session-specific parameters being cleared when the session > drops; >> but more importantly is that no two sessions (i.e. applications) > should >> be aware of what any other session/app is up to - this principle is >> violated if session-specific params are NV-stored >> > > fine > >> Also, while Andy is correct that session-specific filters do require >> more parsing, validating, and setup - this overhead is dwarfed by the >> device actually forwarding the notifications to the client over the >> course of the session >> >> BTW, Phil's proposal is good wrt all this in that it uses device-wide >> streams (i.e. topics) on which session-specific filters can be > applied. > > Neither proposal allows for NV-storage of parameters > which are not session-specific. This is a major problem. > >> Kent > > Andy > >> >> >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] > On >> Behalf Of Andy Bierman >> Sent: Thursday, June 22, 2006 9:36 AM >> To: Sharon Chisholm >> Cc: netconf@ops.ietf.org >> Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >> >> Sharon Chisholm wrote: >>> Eureka. >>> >>> So, we are closer then I thought. This is good to news. So, the >> current >>> proposal has two approaches: >>> >>> 1) Provide the filters as parameters >>> 2) Provide a pointer to the named profile which is a chunk of XML >> Schema >>> and you think that 1)is rubbish and much prefer 2). >>> >>> My main problem with 2) is that it opens things up for >> over-engineering >>> and it also makes the network element the authoritative source of the >>> subscription parameters while I really want the netconf client to be. >> It >>> also has some garbage collection issues. >> Forcing every manager application to come up with the correct >> filtering parameters every time a new session is started is >> extremely inefficient for both the manager and the agent. >> >> Using sharable, NV-stored parameters on the agent, configured by >> the authoritative manager, applications are not forced to >> maintain the possibly massive set of notification filters on their >> own. >> >> It is very inefficient for the agent to parse, validate, setup >> and store all the filtering parameters, every time a session >> that wants notifications starts up, and duplicated for every session. >> >> IMO, these inefficiencies dwarf the task of removing >> NV-stored filters on the agent that are no longer of interest >> to any management application. >> >> >>> Sharon >> Andy >> >>> -----Original Message----- >>> From: Andy Bierman [mailto:ietf@andybierman.com] >>> Sent: Thursday, June 22, 2006 11:20 AM >>> To: Chisholm, Sharon [CAR:ZZ00:EXCH] >>> Cc: netconf@ops.ietf.org >>> Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >>> >>> >>> Sharon Chisholm wrote: >>>> hi >>>> >>>> If the working group gets too obsessed with architectural purity at >>>> the expense of usability to the operators and management > applications >>>> trying to use an implementation of the protocol I think we are more >> in >>>> trouble. >>>> >>> I really disagree with this comment. >>> We spent about 5 years developing a set of standard operations for > the >>> standard manipulation of NV-stored configuration data models encoded >> in >>> XML. Instead of using it, some people want to pretend that filtering >>> parameters do not fall in the category of NV-stored configuration >> data. >>>> I've suggested previously the following criteria before deciding >>>> whether it was appropriate to create a new verb: >>>> >>>> 1. Is it possible to perform this with existing verbs without >>>> exploiting data model side efforts or being ridiculously > complicated? >>>> 2. Is this operation a management operation and if so does it make >>>> sense for a management protocol to provide this function natively? >>>> >>>> I think the argument for this verb falls more out of the second >>>> question. Providing it native in the protocol operation keeps it >>>> simple, easy to use and highlights its importance over arbitrary > bits >>>> of configuration. >>>> >>> I think you are missing the point. >>> Balazs and I are not saying that a verb to start >>> the delivery of notifications is a problem. >>> I totally agree with this approach, rather >>> than the SNMP MIB approach of turning the knob >>> to 'enabled' in the data model. Let's get past this point, okay? >>> >>> The problem is that many of the parameters >>> (especially the most complicated part -- the filters) >>> should be implemented as a read-create standard >>> data model using the existing operation, >>> and retrieval of these parameters and notification >>> state information should be done with the operation. >>> >>> >>>> And why do we have and again? >>> To retrieve data >>> >>>> Sharon >>>> >>> Andy >>> >>> >>> >>>> -----Original Message----- >>>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] > >>>> On Behalf Of Andy Bierman >>>> Sent: Thursday, June 22, 2006 10:22 AM >>>> To: Balazs Lengyel >>>> Cc: Phil Shafer; netconf@ops.ietf.org >>>> Subject: Re: draft-shafer-netconf-syslog-00.txt >>>> >>>> >>>> Balazs Lengyel wrote: >>>>> ... >>>>> 3) >>>>> > I'm not prepared to be the first lamb on that altar. ;^) >> Someone >>>>> has to be :-) otherwise NETCONF is dead already. >>>>> >>>> Agreed. >>>> What is especially depressing: >>>> >>>> 1) Notification filtering and delivery is a well understood >> problem, >>>> traditionally handled with NV-stored configuration on the >>>> notification generator. >>>> >>>> 2) This is a relatively simple configurable feature on a >>>> complex networking device such as a router. >>>> >>>> 3) If the NETCONF WG cannot (or does not) use the >>>> NETCONF protocol to configure the NETCONF protocol, >>>> then nobody else will use it either. >>>> >>>> 4) If something as basic as a filtering table and notification >>>> generation parameters are not appropriate for implementation as >> a >>>> standard data model (accessed with and >>> ), >>>> then what is an appropriate use of the NETCONF protocol >>>> standard operations and standard data models? >>>> >>>> 5) If you can define a representation of a 'feature' in a data >> model >>>> for monitoring, then you've already done most of the work for >>>> configuration. Read-only vs. read-write is an artificial >>>> attribute. >>>> >>>> >>>>> Balazs >>>> Andy >>>> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the >>>> word 'unsubscribe' in a single line as the message text body. >>>> archive: >>>> >>>> -- >>>> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the >>>> word 'unsubscribe' in a single line as the message text body. >>>> archive: >>>> >>>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >>> >> >> -- >> to 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 Jun 22 17:23:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWeU-0004id-5J for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 17:23:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtWeS-0005U0-PO for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 17:23:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtWbN-000JJK-15 for netconf-data@psg.com; Thu, 22 Jun 2006 21:20:37 +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 [209.128.82.1] (helo=shell4.bayarea.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtWbM-000JJ5-Aj for netconf@ops.ietf.org; Thu, 22 Jun 2006 21:20:36 +0000 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5MLKYFu028392 for ; Thu, 22 Jun 2006 14:20:34 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5MLKY4N028383 for ; Thu, 22 Jun 2006 14:20:34 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 22 Jun 2006 14:20:34 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: netconf@ops.ietf.org Subject: Tweeks to draft-shafer-netconf-syslog-00.txt In-Reply-To: <449AFCA0.7000400@andybierman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 HI, I'd like to reinforce my previous message with some tweeks to the conceptal model found in Phil's document. (Yes, already I've lost half or more of the readers.) There is the unmodified figure from section 2.1: +----+ | c1 |---+ +----+ | +------+ (off-box) +----+ | | | | c2 | +--->|syslog| +-------+ +-------+ +----+ | |daemon|--------->|netconf|<--->|netconf| ... | | | >|server | |client | System | +------+ / +-------+ +-------+ Components| \ / ... | v / +----+ | (----------) | cn |---+ (historical) +----+ ( events ) (e.g. log files) (----------) And here it is with a few modifications that change how you might want to look at it: off-box +----+ ------->collection of | c1 |---+ / "syslog servers" +----+ | +------+ (off-box) +----+ | | | | c2 | +--->|syslog| +-------+ +-------+ +----+ | |daemon| |netconf|<--->|netconf| ... | | | -|server | |client | System | +------+ />+-------+ +-------+ Components| \ // ... | v v/ +----+ | (----------) | cn |---+ (collection) +----+ (of on-box ) (log files ) (----------) The configuration for the syslog daemon is the addresses of the off box syslog servers, and the on-box "logs", and the filtering to apply before sending to a syslog server or saving in a log. The document calls each paired target and filter an "event stream". I see setting up the event streams as configuration. However, I see that getting syslog data as monitoring status (and state). If you compare the two pictures, you will notice that there is no longer a direct connection between the syslog daemon and the netconf server. I did this to clarify that getting syslog data via netconf was a "monitoring" operation and not a "configuration" operation. Note that the event streams may be filtered before saved in a log file, and that data from a log file may be filtered before it is returned to the netconf client. Now it seems like what is being argued about is how to specify a filter for a monitoring operation. And this could be done in two ways. First, one could configure named filter expressions on the system. Then when a monitor operation was started, it could specify the name of an existing filter expression. Secondly, one could allow a monitor operation to specify an unnamed filter expression as a parameter to the monitor operation. I believe that either one provides the same result. Hope this helps. Regards, /david t. perkins -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 17:58:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXCN-0007Wi-KC for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 17:58:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXCM-0001Cg-6Z for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 17:58:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtX8n-000LoB-CD for netconf-data@psg.com; Thu, 22 Jun 2006 21:55: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 [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtX8m-000Lny-HX for netconf@ops.ietf.org; Thu, 22 Jun 2006 21:55:08 +0000 Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5MLt7MG009334 for ; Thu, 22 Jun 2006 17:55:07 -0400 Received: (qmail 21351 invoked by uid 78); 22 Jun 2006 21:55:07 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 22 Jun 2006 21:55:07 -0000 Message-ID: <449B121E.5040004@andybierman.com> Date: Thu, 22 Jun 2006 14:56:46 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "David T. Perkins" CC: netconf@ops.ietf.org Subject: Re: Tweeks to draft-shafer-netconf-syslog-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 David T. Perkins wrote: > HI, > thanks for this email Dave. I think it helps a lot. Your diagram gets to the architecture issue that Dave H> and I have raised. but I don't see the key distinction as off-box or on-box, or historical vs. live events. IMO, if you change "off-box" to "traditional syslog service" (NV-configured syslog feature on a NE device) and "on-box" to "netconf session", it represents the real architecture that is going to be present in the agent: traditional +----+ ------->delivery via | c1 |---+ / syslog protocol +----+ | +------+ +----+ | | | | c2 | +--->|syslog| netconf +-------+ +-------+ +----+ | |daemon| session |netconf|<--->|netconf| ... | | | ----------> |server | |client | System | +------+ delivery +-------+ +-------+ Components| | // ... | | // +----+ | | (------------) | cn |---+ | (notification) +----+ +-----> ( logging ) ( service ) (------------) > I'd like to reinforce my previous message with some > tweeks to the conceptal model found in Phil's document. > (Yes, already I've lost half or more of the readers.) > > There is the unmodified figure from section 2.1: > > +----+ > | c1 |---+ > +----+ | +------+ (off-box) > +----+ | | | > | c2 | +--->|syslog| +-------+ +-------+ > +----+ | |daemon|--------->|netconf|<--->|netconf| > ... | | | >|server | |client | > System | +------+ / +-------+ +-------+ > Components| \ / > ... | v / > +----+ | (----------) > | cn |---+ (historical) > +----+ ( events ) (e.g. log files) > (----------) > > And here it is with a few modifications that change how > you might want to look at it: > > off-box > +----+ ------->collection of > | c1 |---+ / "syslog servers" > +----+ | +------+ (off-box) > +----+ | | | > | c2 | +--->|syslog| +-------+ +-------+ > +----+ | |daemon| |netconf|<--->|netconf| > ... | | | -|server | |client | > System | +------+ />+-------+ +-------+ > Components| \ // > ... | v v/ > +----+ | (----------) > | cn |---+ (collection) > +----+ (of on-box ) > (log files ) > (----------) > > The configuration for the syslog daemon is the > addresses of the off box syslog servers, and > the on-box "logs", and the filtering to apply > before sending to a syslog server or saving > in a log. The document calls each paired > target and filter an "event stream". > > I see setting up the event streams as > configuration. However, I see that getting > syslog data as monitoring status (and > state). > > If you compare the two pictures, you will notice > that there is no longer a direct connection > between the syslog daemon and the netconf server. > I did this to clarify that getting syslog > data via netconf was a "monitoring" operation > and not a "configuration" operation. > Note that the event streams may be filtered > before saved in a log file, and that data > from a log file may be filtered before > it is returned to the netconf client. > > Now it seems like what is being argued about > is how to specify a filter for a monitoring > operation. And this could be done in two > ways. First, one could configure named filter > expressions on the system. Then when a > monitor operation was started, it could specify > the name of an existing filter expression. > Secondly, one could allow a monitor operation > to specify an unnamed filter expression as > a parameter to the monitor operation. > > I believe that either one provides the same result. > > Hope this helps. > > Regards, > /david t. perkins Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jun 22 19:32:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYfB-0006w1-TH for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 19:32:41 -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 1FtYfB-0000n3-Rg for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 19:32:41 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtYXW-0001KM-Dt for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 19:24:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtYUM-0002cG-DU for netconf-data@psg.com; Thu, 22 Jun 2006 23:21:30 +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 1FtYUL-0002bz-8R for netconf@ops.ietf.org; Thu, 22 Jun 2006 23:21:29 +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 k5MNLMaY005411 for ; Thu, 22 Jun 2006 19:21:28 -0400 Received: (qmail 32647 invoked by uid 78); 22 Jun 2006 23:21:22 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 22 Jun 2006 23:21:22 -0000 Message-ID: <449B2662.2000208@andybierman.com> Date: Thu, 22 Jun 2006 16:23:14 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andy Bierman CC: Phil Shafer , "Netconf (E-mail)" Subject: Re: XML Namespace usage in NETCONF References: <200606161459.k5GEx8wn016305@idle.juniper.net> <4492CBA4.2020505@andybierman.com> In-Reply-To: <4492CBA4.2020505@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Andy Bierman wrote: > Phil Shafer wrote: Final clarification on this issue: If a particular filter node does not use any namespace, then it must match a corresponding node in the data model which also does not use any namespace. Use of the default namespace does not act as a wildcard to ask the agent to find the correct namespace. Andy >> Andy Bierman writes: >>> Your example obviously shows it doesn't matter where the xmlns >>> directives are in the PDU. All that matters is normal XML processing >>> rules are followed to determine the requested namepsace. >> >> Yup, the text is an encoding of the infoset, and there are >> multiple ways to encode it. >> >>> This does not work. >>> Although extremely stupid, empty strings and whitespace-only strings >>> are valid namespace names. (I wonder how many agents handle an empty >>> NS string correctly?) >> >> You sure? In section 5.2 of: >> >> http://www.w3.org/TR/1999/REC-xml-names-19990114/ >> >> it says: >> >> The default namespace can be set to the empty string. This has >> the same effect, within the scope of the declaration, of there >> being no default namespace. >> >> There's an example also. > > Okay, you are right. The libxml2 parser behaves this way: > > no namespace > > namespace = "" > > no namespace > > > One more weird XML corner case to deal with :-( > Is this supposed to be a feature? > > >> >> Thanks, >> Phil >> >> > > > Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Jun 22 20:15:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZKC-0006Y1-6Q for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 20:15:04 -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 1FtYUP-0008V9-3V for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 19:21:33 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtYCh-0007lL-CS for netconf-archive@lists.ietf.org; Thu, 22 Jun 2006 19:03:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0N-000PmK-5J for netconf-data@psg.com; Thu, 22 Jun 2006 22:50:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0K-000PjN-CG for netconf@ops.ietf.org; Thu, 22 Jun 2006 22:50:28 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2WR003658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007ta-7B; Thu, 22 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-notification-02.txt Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Event Notifications Author(s) : S. Chisholm, et al. Filename : draft-ietf-netconf-notification-02.txt Pages : 59 Date : 2006-6-22 This memo defines a framework for sending asynchronous messages, or event notifications in NETCONF. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to transport protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-notification-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-notification-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22160440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-notification-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-notification-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22160440.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 23 02:55:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtfZN-0005Ih-EP for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 02:55:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtfZL-0002lb-T9 for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 02:55:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtfVj-000AGb-JP for netconf-data@psg.com; Fri, 23 Jun 2006 06:51: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.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 1FtfVh-000AGM-Kf for netconf@ops.ietf.org; Fri, 23 Jun 2006 06:51:21 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A265356166; Fri, 23 Jun 2006 08:51:20 +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 15155-07; Fri, 23 Jun 2006 08:51:18 +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 54D2B560DD; Fri, 23 Jun 2006 08:51:18 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id F030875EE84; Fri, 23 Jun 2006 08:51:16 +0200 (CEST) Date: Fri, 23 Jun 2006 08:51:16 +0200 From: Juergen Schoenwaelder To: Rainer Gerhards Cc: netconf@ops.ietf.org Subject: Re: Tweeks to draft-shafer-netconf-syslog-00.txt Message-ID: <20060623065116.GA4901@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Rainer Gerhards , netconf@ops.ietf.org References: <449B121E.5040004@andybierman.com> <577465F99B41C842AAFBE9ED71E70ABA1749D2@grfint2.intern.adiscon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1749D2@grfint2.intern.adiscon.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: 769a46790fb42fbb0b0cc700c82f7081 On Fri, Jun 23, 2006 at 08:37:34AM +0200, Rainer Gerhards wrote: > I have made two other slight modification to the diagram: > > 1. I have removed the term "traditional", because that sounds like > it implies that only RFC 3164 syslog is supported. As far as I see > it, netconf-syslog can support any flavor of syslog, including the > upcoming standards. > > 2. I have added SYSLOG delivery on the receiving side of the > syslog daemon. > > delivery > +----+ ------->via syslog > | c1 |---+ / protocol > +----+ | +------+ > +----+ | | | > | c2 | +--->|syslog| netconf +-------+ +-------+ > +----+ | |daemon| session |netconf|<--->|netconf| > ... | | | ----------> |server | |client | > System | +------+ delivery +-------+ +-------+ > Components| | // > ... | | // > +----+ | | (------------) > | cn |---+ | (notification) > +----+ | +-----> ( logging ) > | ( service ) > delivery | (------------) > via syslog ---+ > protocol I do not understand what "netconf session delivery" means. For me, a netconf session exists between a netconf server and a netconf client. It is also unclear what the double lines // mean. If the figure is meant to indicate the syslog data flow, then also the double arrow between netconf server and netconf client is wrong. If the arrows are supposed to mean something else, I think a legend is required to discuss the figure. Well, a legend is required in any case. /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 Fri Jun 23 03:39:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgFt-0001NI-GW for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 03:39:05 -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 1Ftfiy-0003iY-5Z for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 03:05:04 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtfOy-0002vF-AN for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 02:44:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtfIh-0009B9-8c for netconf-data@psg.com; Fri, 23 Jun 2006 06:37:55 +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, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtfId-0009Aj-Fn for netconf@ops.ietf.org; Fri, 23 Jun 2006 06:37:51 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4A2A827C065; Fri, 23 Jun 2006 08:34:16 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04334-01; Fri, 23 Jun 2006 08:34:16 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D43F627C061; Fri, 23 Jun 2006 08:34:15 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 08:37:43 +0200 Content-class: urn:content-classes:message Subject: RE: Tweeks to draft-shafer-netconf-syslog-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jun 2006 08:37:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749D2@grfint2.intern.adiscon.com> In-Reply-To: <449B121E.5040004@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tweeks to draft-shafer-netconf-syslog-00.txt Thread-Index: AcaWR4VsaTyUf25mTP20KyMroCXnlQARwiMg From: "Rainer Gerhards" To: "Andy Bierman" Cc: X-OriginalArrivalTime: 23 Jun 2006 06:37:43.0182 (UTC) FILETIME=[87F09AE0:01C6968F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 I have made two other slight modification to the diagram: 1. I have removed the term "traditional", because that sounds like it implies that only RFC 3164 syslog is supported. As far as I see it, netconf-syslog can support any flavor of syslog, including the upcoming standards. 2. I have added SYSLOG delivery on the receiving side of the=20 syslog daemon.=20 delivery +----+ ------->via syslog | c1 |---+ / protocol +----+ | +------+ +----+ | | | | c2 | +--->|syslog| netconf +-------+ +-------+ +----+ | |daemon| session |netconf|<--->|netconf| ... | | | ----------> |server | |client | System | +------+ delivery +-------+ +-------+ Components| | // ... | | // +----+ | | (------------) | cn |---+ | (notification) +----+ | +-----> ( logging ) | ( service ) delivery | (------------) via syslog ---+=20 protocol Rainer > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, June 22, 2006 11:57 PM > To: David T. Perkins > Cc: netconf@ops.ietf.org > Subject: Re: Tweeks to draft-shafer-netconf-syslog-00.txt >=20 > David T. Perkins wrote: > > HI, > >=20 >=20 > thanks for this email Dave. > I think it helps a lot. > Your diagram gets to the architecture issue that > Dave H> and I have raised. > but I don't see the key distinction as off-box or on-box, > or historical vs. live events. >=20 >=20 > IMO, if you change "off-box" to "traditional syslog service" > (NV-configured syslog feature on a NE device) and "on-box" > to "netconf session", it represents the real architecture > that is going to be present in the agent: >=20 >=20 >=20 > traditional > +----+ ------->delivery via > | c1 |---+ / syslog protocol > +----+ | +------+ > +----+ | | | > | c2 | +--->|syslog| netconf +-------+ +-------+ > +----+ | |daemon| session |netconf|<--->|netconf| > ... | | | ----------> |server | |client | > System | +------+ delivery +-------+ +-------+ > Components| | // > ... | | // > +----+ | | (------------) > | cn |---+ | (notification) > +----+ +-----> ( logging ) > ( service ) > (------------) >=20 >=20 >=20 >=20 > > I'd like to reinforce my previous message with some > > tweeks to the conceptal model found in Phil's document. > > (Yes, already I've lost half or more of the readers.) > >=20 > > There is the unmodified figure from section 2.1: > >=20 > > +----+ > > | c1 |---+ > > +----+ | +------+ (off-box) > > +----+ | | | > > | c2 | +--->|syslog| +-------+ +-------+ > > +----+ | |daemon|--------->|netconf|<--->|netconf| > > ... | | | >|server | |client | > > System | +------+ / +-------+ +-------+ > > Components| \ / > > ... | v / > > +----+ | (----------) > > | cn |---+ (historical) > > +----+ ( events ) (e.g. log files) > > (----------) > >=20 > > And here it is with a few modifications that change how > > you might want to look at it: > >=20 > > off-box =20 > > +----+ ------->collection of > > | c1 |---+ / "syslog servers" > > +----+ | +------+ (off-box) > > +----+ | | | > > | c2 | +--->|syslog| +-------+ +-------+ > > +----+ | |daemon| |netconf|<--->|netconf| > > ... | | | -|server | |client | > > System | +------+ />+-------+ +-------+ > > Components| \ // > > ... | v v/ > > +----+ | (----------) > > | cn |---+ (collection) > > +----+ (of on-box ) > > (log files ) > > (----------) > >=20 > > The configuration for the syslog daemon is the > > addresses of the off box syslog servers, and > > the on-box "logs", and the filtering to apply > > before sending to a syslog server or saving > > in a log. The document calls each paired > > target and filter an "event stream".=20 > >=20 > > I see setting up the event streams as > > configuration. However, I see that getting > > syslog data as monitoring status (and > > state). > >=20 > > If you compare the two pictures, you will notice > > that there is no longer a direct connection > > between the syslog daemon and the netconf server. > > I did this to clarify that getting syslog > > data via netconf was a "monitoring" operation > > and not a "configuration" operation. > > Note that the event streams may be filtered > > before saved in a log file, and that data > > from a log file may be filtered before > > it is returned to the netconf client. > >=20 > > Now it seems like what is being argued about > > is how to specify a filter for a monitoring > > operation. And this could be done in two > > ways. First, one could configure named filter > > expressions on the system. Then when a > > monitor operation was started, it could specify > > the name of an existing filter expression. > > Secondly, one could allow a monitor operation > > to specify an unnamed filter expression as > > a parameter to the monitor operation. > >=20 > > I believe that either one provides the same result. > >=20 > > Hope this helps. > >=20 > > Regards, > > /david t. perkins >=20 > Andy >=20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 23 03:51:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgSJ-0006H5-Sl for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 03:51:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtgSI-0006T6-7j for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 03:51:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtgPE-000FY9-4s for netconf-data@psg.com; Fri, 23 Jun 2006 07:48:44 +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, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtgPD-000FXx-2W for netconf@ops.ietf.org; Fri, 23 Jun 2006 07:48:43 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4D92D27C065; Fri, 23 Jun 2006 09:45:13 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06254-02; Fri, 23 Jun 2006 09:45:13 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id EC1BA27C061; Fri, 23 Jun 2006 09:45:12 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:48:39 +0200 Content-class: urn:content-classes:message Subject: RE: Tweeks to draft-shafer-netconf-syslog-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jun 2006 09:48:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749D4@grfint2.intern.adiscon.com> In-Reply-To: <20060623065116.GA4901@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tweeks to draft-shafer-netconf-syslog-00.txt Thread-Index: AcaWkr8K8eg7nY+HRJWd6n03vJgLxQAAS9Ig From: "Rainer Gerhards" To: Cc: X-OriginalArrivalTime: 23 Jun 2006 07:48:39.0778 (UTC) FILETIME=[71119C20:01C69699] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 If I understood the spirit of the previous diagrams right, then how about that: remote +----+ --SYSLOG-->syslog | c1 |---+ / receiver +----+ | +------+ +----+ | | | | c2 | +--->|syslog| +-------+ +-------+ +----+ | |server| |netconf|<-NETCONF->|netconf| ... | | |------>|server | |client | System | +------+ +-------+ +-------+ Components| ^ | ^ ... | | | | +----+ | S | v=20 | cn |---+ Y | (------------) +----+ S +----->(notification) L ( repository ) O (------------) remote G syslog --------+ sender Arrows with protocol names indicate message transport via the named protocol. Arrows without names use no specific protocols and may be internal APIs. SYSLOG terminology (sender, receiver) is defined in draft-ietf-syslog-protocol-17. The arrow between the "netconf server" and the "notification repository" indicates that the netconf server accesses the repository. The arrow between "syslog server" and "notification repository" indicates that the syslog server submits data to the repository but is not expected to pull any data out of it. The data flow shown is informative, only. It does not demand any specific implementation. Some more points: 1. I have changed the "notification logging service" to "notification repository". IMO, the important point is that there is a repository for notifications. In actual software, I'd expect this to be a data store which is written by the syslogd and read by the netconf server. It could (should?) also be written to (configured) by the netconf server (e.g. expiration of log data, access policies). It could be discussed if the netconf server should have other write capabilities (e.g. delete events), but I think this is irrelevant wrt this draft). 2. I have replaced the term "syslog daemon" by "syslog server". Though the former is well-known, the later is more generic and platform-independent. 3. One word on the relationship of the syslog to the netconf server.There is no pure syslog or pure netconf server on either side. A pure syslog server can not talk netconf to a netconf server because it does not know about that. Actually, I would expect both of them to be inside a single app (at least from the architecture point of view), talking to each other via API, local RPC or simple internal function calls. Something like this: +---------------------------+ | syslog/netconf app | | +------+ +-------+ | =20 --SYSLOG->|syslog| |netconf|<-NETCONF-> | |server|-API->|server | | =20 | +------+ +-------+ | +---------------------------+ One might now argue that this is the reason that all events should go through the the event repository. IMHO this is not a practical option as we would like to see realtime delivery. In any case it is nothing that happens on the wire, so it is out of the scope of any IETF WG. I still find it useful to have the conceptual data flow in the diagram. Rainer > I do not understand what "netconf session delivery" means. For me, a > netconf session exists between a netconf server and a netconf client. > It is also unclear what the double lines // mean. If the figure is > meant to indicate the syslog data flow, then also the double arrow > between netconf server and netconf client is wrong. If the arrows are > supposed to mean something else, I think a legend is required to > discuss the figure. Well, a legend is required in any case. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 23 04:03:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgdN-0002Hq-OV for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:03:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtgdM-00084p-2H for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:03:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtgOj-000FUh-IA for netconf-data@psg.com; Fri, 23 Jun 2006 07:48: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.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 1FtgOi-000FUT-4g for netconf@ops.ietf.org; Fri, 23 Jun 2006 07:48:12 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ED4B8E39; Fri, 23 Jun 2006 09:48:08 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:48:08 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:48:08 +0200 Message-ID: <449B9CB8.7030807@ericsson.com> Date: Fri, 23 Jun 2006 09:48:08 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Verbs Again References: <449AA791.4000408@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B4095C5D49@zcarhxm2.corp.nortel.com> <20060622.210013.11944118.mbj@tail-f.com> In-Reply-To: <20060622.210013.11944118.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2006 07:48:08.0448 (UTC) FILETIME=[5E650800:01C69699] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 I think the problem is common for both drafts. You have to define a group of data to tell the netconf server which events to forward / filter (and for call home where to send them). Do we want to do this with a edit-config and get or do we want new protocol operations ? Balazs Martin Bjorklund wrote: > "Sharon Chisholm" wrote: >> hi >> >> If the working group gets too obsessed with architectural purity at the >> expense of usability to the operators and management applications trying >> to use an implementation of the protocol I think we are more in trouble. >> >> I've suggested previously the following criteria before deciding whether >> it was appropriate to create a new verb: >> >> 1. Is it possible to perform this with existing verbs without exploiting >> data model side efforts or being ridiculously complicated? >> 2. Is this operation a management operation and if so does it make sense >> for a management protocol to provide this function natively? >> >> I think the argument for this verb falls more out of the second >> question. > > Are we still talking about from Phil's draft? > That's the verb that some us thought was better done as a data model > and and . > > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 23 04:03:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgdQ-0002TF-5T for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:03:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtgdO-00084v-Iu for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:03:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtgO5-000FSg-7p for netconf-data@psg.com; Fri, 23 Jun 2006 07:47:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.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 1FtgO3-000FRD-Lr for netconf@ops.ietf.org; Fri, 23 Jun 2006 07:47:31 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EE0B44F0001; Fri, 23 Jun 2006 09:43:54 +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, 23 Jun 2006 09:43:54 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:43:54 +0200 Message-ID: <449B9BBA.4080804@ericsson.com> Date: Fri, 23 Jun 2006 09:43:54 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Kent Watsen CC: Andy Bierman , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2006 07:43:54.0195 (UTC) FILETIME=[C6D91A30:01C69698] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hello, IMO when designing a standard "does not preclude" is not enough. We should either define the NV configuration model or forget it altogether (which still does not prevent individual implementations but is clearly outside the standard). Balazs Kent Watsen wrote: > > There is nothing in either proposal that limits the device from also > having static configuration for forwarding events to a standard syslog > server - these proposals are specific to forwarding events over a > NetConf session... > > Kent > -- to unsubscribe send a message to netconf-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 Jun 23 04:06:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtggE-0005ME-RN for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:06:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtggD-0008Ci-DW for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:06:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtgZn-000GdK-Nl for netconf-data@psg.com; Fri, 23 Jun 2006 07:59:39 +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 1FtgZm-000Gd5-U4 for netconf@ops.ietf.org; Fri, 23 Jun 2006 07:59:39 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1100C520002 for ; Fri, 23 Jun 2006 09:59:38 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:59:37 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:59:37 +0200 Message-ID: <449B9F69.5090401@ericsson.com> Date: Fri, 23 Jun 2006 09:59:37 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt References: <44981592.5080906@loria.fr> <200606201618.k5KGIvwn034000@idle.juniper.net> <20060621.124127.96932914.mbj@tail-f.com> <44995A2A.3020305@andybierman.com> In-Reply-To: <44995A2A.3020305@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2006 07:59:37.0519 (UTC) FILETIME=[F91CEBF0:01C6969A] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hello, Some comments to the netconf-syslog draft: 1) If I want to refer to data in my configuration store how do I do that in the syslog solution? 2) If I want to refer to a previous Netconf operation in syslog I have to embed the Netconf sessionId, messageId and some additional XML in syslog in a proprietary way. Not so nice. 3) Do we need call-home for syslog? While this solution is good for nodes that already use syslog, for those that do not, this is an additional protocol layer that you have to wrap your information in. Additional work. Also I see a risk that we might delay standardizing a number of important features like: how to refer to the data model and other netconf operations in netconf notifications I would rather support Sharon's idea to provide syslog as one option for netconf notifications but definitely not the main method. Balazs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 23 04:42:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FthEq-0005ad-BM for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:42:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FthEp-0001r1-08 for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 04:42:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fth67-000JEa-3F for netconf-data@psg.com; Fri, 23 Jun 2006 08:33:03 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fth66-000JEO-75 for netconf@ops.ietf.org; Fri, 23 Jun 2006 08:33:02 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5N8X1MQ016603 for ; Fri, 23 Jun 2006 04:33:01 -0400 Received: (qmail 372 invoked by uid 78); 23 Jun 2006 08:33:01 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 23 Jun 2006 08:33:01 -0000 Message-ID: <449BA7B1.6030905@andybierman.com> Date: Fri, 23 Jun 2006 01:34:57 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rainer Gerhards , netconf@ops.ietf.org Subject: Re: Tweeks to draft-shafer-netconf-syslog-00.txt References: <449B121E.5040004@andybierman.com> <577465F99B41C842AAFBE9ED71E70ABA1749D2@grfint2.intern.adiscon.com> <20060623065116.GA4901@boskop.local> In-Reply-To: <20060623065116.GA4901@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Juergen Schoenwaelder wrote: > On Fri, Jun 23, 2006 at 08:37:34AM +0200, Rainer Gerhards wrote: >> I have made two other slight modification to the diagram: >> >> 1. I have removed the term "traditional", because that sounds like >> it implies that only RFC 3164 syslog is supported. As far as I see >> it, netconf-syslog can support any flavor of syslog, including the >> upcoming standards. >> >> 2. I have added SYSLOG delivery on the receiving side of the >> syslog daemon. >> >> delivery >> +----+ ------->via syslog >> | c1 |---+ / protocol >> +----+ | +------+ >> +----+ | | | >> | c2 | +--->|syslog| netconf +-------+ +-------+ >> +----+ | |daemon| session |netconf|<--->|netconf| >> ... | | | ----------> |server | |client | >> System | +------+ delivery +-------+ +-------+ >> Components| | // >> ... | | // >> +----+ | | (------------) >> | cn |---+ | (notification) >> +----+ | +-----> ( logging ) >> | ( service ) >> delivery | (------------) >> via syslog ---+ >> protocol > > I do not understand what "netconf session delivery" means. For me, a I like Rainer's latest diagram. I wanted the diagram to show is that syslog protocol does not go away in this new architecture. I wanted to the diagram to clearly show that the netconf syslog delivery service is a "nice-to-have" copy-service for the benefit of netconf NMS developers, not a "must-have" notification service for the benefit of network operators. > netconf session exists between a netconf server and a netconf client. > It is also unclear what the double lines // mean. If the figure is > meant to indicate the syslog data flow, then also the double arrow > between netconf server and netconf client is wrong. If the arrows are > supposed to mean something else, I think a legend is required to > discuss the figure. Well, a legend is required in any case. > > /js > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jun 23 07:39:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftk0e-0005tq-7V for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 07:39:36 -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 1FtjUz-0003Gp-8u for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 07:06:53 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ftj5R-0007tQ-7F for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 06:40:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftj0C-0003Hd-Kf for netconf-data@psg.com; Fri, 23 Jun 2006 10:35:04 +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 1Ftj0A-0003Gp-QV for netconf@ops.ietf.org; Fri, 23 Jun 2006 10:35:03 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C44ABFA1 for ; Fri, 23 Jun 2006 12:35:01 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 12:35:01 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 12:35:01 +0200 Message-ID: <449BC3D4.2020008@ericsson.com> Date: Fri, 23 Jun 2006 12:35:00 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Some thoughts about Call-home References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> In-Reply-To: <4458DDE9.8030506@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2006 10:35:01.0288 (UTC) FILETIME=[AE832A80:01C696B0] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Hello, Here are some thoughts about the call-home function. Sadly I was unable to complete it, but it might be still useful. ========================================================================= [NOTE] Subscription based notification is good if - the management application wants to receive notifications for a short period of time - if the set of notifications the management application is interested in changes frequently (changing filter) Statically configured notification delivery is best for management applications if - the manager is interested in the same set of notifications for a long time. - it does not want to reconfigure the managed device after eventual restarts, loss of connections etc. - the manager does not want to maintain a Netconf connection permanently, but still needs some notifications - the manager handles a big number of devices, so establishing Netconf session to each would be a major task 0. Call-Home Capability 0.1. Description 0.1.1 Overview Call-Home capability allows a Netconf server to send notifications to a client even if there is no Netconf live session between the client and the server initially when the server wants to send a notification. The capability can be useful for NAT traversal as in this model, the Netconf server initiates the Notification session. Another use case is when a manager handles a large number of devices that it only wants to deal with when there is a known issue. It is useful if it would be to much work for the manager to set up Netconf sessions to every device after e.g. a manager restart. The device has to configured with data about which clients(targets) should be contacted. Data about each target will include: - Target Name (key) - Target Transport Address - Transport type (SSH, BEEP, SOAP) - Target Security name to use - Security Credential Type - Security Credential - Notifications Filter associated - Use Mixed Notification Sessions (boolean) - Active/Passive - Removed With Session (sessionId) - Currently used sessionId (read-only) - Inactivity Timeout The above data will be stored for each target in non-volatile memory. [NOTE] This should be the same data model as used for subscriptions. Target name (human readable string) is the key that identifies the target. Transport Address is an IPv4 or IPv6 address or a fully qualified domain name and an optional port number. If the Netconf default port is used port can be set to zero. Transport Type identifies the underlying transport in case when multiple types are supported by the Netconf server. Security Name defines the security name to use when initiating a new session. Security credential type can be something like plain password, a certificate, [TODO] Security credential will be used to set up the session Filter will be used to decide whether an individual notification shall be sent to a target. Use Mixed Notification Sessions [TODO] Needed ? Active/Passive indicates whether notifications should be sent to this target. This allows managers to configure the Netconf server but still temporarily suspend notification delivery. Removed With Session indicates that the target was created by a subscription by the indicated session and it should be deleted when that session is closed. SessionId indicates the current session used for delivering notifications. This maybe null [TODO how to really indicate null] if there is no such session. Inactivity Timeout indicates that the time when the session should be automatically closed if it is not used. The session will be removed only if Removed With Session is null i.e. the session is not subscription based. Targets are created by normal configuration operations (, ). Any referenced filters must be created before the notification target. For short lived subscriptions either the Removed With Session field shall be used or the target shall be removed with a subsequent configuration operation. When an event of interest happens the Netconf server should go through the following steps: For each event { determine the targets, apply filters, send message request to message processing } For each message request { build notification, send message to transport mapping } For each message { Check if you have a CurrentlyUsedSessionId If not, create session UseMixedNotifictionSessions=false, RemovedWithSession=null, store used sessionId send message } If session setup fails, the target is simply skipped for this notification. The Netconf server may notify the individual targets in any order. [NOTE] A session for notifications can be started in two ways. - By call-home in which case we can reuse the session. - By subscription in which case we can again reuse the session. - However if there is a session to the same manager entity, but it did not subscriber to the target, it probably does not want to receive notifications, so we should not reuse that session i.e. we should not try to search for a session with the same transport address, security name etc. [NOTE] A slightly different approach then in SNMP TMSM was chosen. In TMSM session can be identified by transportAddress, securityName, securityModel, and securityLevel while In Netconf there is a possibility to have multiple logically separate sessions between a manager and an agent with the same security and transport data but e.g. different filters or one with need for notifications and one which does not want to receive notifications. Similarly to the SNMP TMSM Netconf Applications typically have no knowledge of whether the session that will be used to carry notifications was initially established due to a subscription or due to call-home, and SHOULD NOT make any assumptions based on knowing the direction of establishment of the session. 0.1.1.1 Session Lifecycle Session setup including authentication is seen as a somewhat expensive activity, so similarly to SNMP TMSM Netconf will allow the cost of authentication to be amortized over potentially many notification transfers. In order to avoid situations in which a session is continuously setup and torn down, an inactivity timer is configured on the server. By default the timeout interval is the same for all sessions (but can be modified) and each session has its own timer. Upon expiration of the inactivity timer, the connection is terminated, otherwise if a notification is sent on the session, the timer is reset. The session establishment procedure is as follows: 1) The NETCONF server initiates a session using a recognized application protocol (SSH, Beep, SOAP, etc). In order to "activate" this reverse behavior a new SSH subsystem may need to be defined. This is for further study. In addition, the NE hosting the NETCONF server must support both client and server modes in the case of SSH. 2) Client and server are authenticated according to the underlying application protocol (e.g. SSH, BEEP) 3) If using BEEP, as described in [NETCONF-BEEP] either party may initiate the BEEP session. Once this occurs, the assumption is that both parties know their roles. At this point, the NETCONF client, initiates NETCONF session establishment whether running SSH or BEEP. 0.2. Dependencies Possible dependencies dependent on other parts of the draft: - simple notifications (subscription based) without call-home - mixed session capability 0.3. Capability Identifier urn:ietf:params:xml:ns:netconf:callHomeNotification:1.0 0.4. New Operations None First information rpc ? 0.5 Modifications to Existing Operations None 0.6 New Data Model [TODO] 0.7 Interactions with Other Capabilities Simple notifications and Call-home notifications use the same data model. ============================================================================== who is the other side ? transport mapping ? SSH netconf-reverse subsystem ? agent should be able to act as client serverkey, password BEEP BEEP profiles plus some indication of role (either within protocol or outside)o SOAP Initial message needed ? -- to unsubscribe send a message to netconf-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 Jun 23 07:40:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftk1O-0006lx-Om for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 07:40:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftk1N-0000R4-ER for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 07:40:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtjwF-0008FS-4U for netconf-data@psg.com; Fri, 23 Jun 2006 11:35:03 +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 1FtjwE-0008Ei-5c for netconf@ops.ietf.org; Fri, 23 Jun 2006 11:35:02 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 15DA055E1B; Fri, 23 Jun 2006 13:35:01 +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 04960-01; Fri, 23 Jun 2006 13:34:59 +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 C37BF55F83; Fri, 23 Jun 2006 13:34:52 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 5A80B75F333; Fri, 23 Jun 2006 13:34:51 +0200 (CEST) Date: Fri, 23 Jun 2006 13:34:51 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: "Netconf (E-mail)" Subject: Re: Some thoughts about Call-home Message-ID: <20060623113451.GA5283@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Balazs Lengyel , "Netconf (E-mail)" References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <449BC3D4.2020008@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449BC3D4.2020008@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 Fri, Jun 23, 2006 at 12:35:00PM +0200, Balazs Lengyel wrote: > Here are some thoughts about the call-home function. Sadly I was > unable to complete it, but it might be still useful. [...] I hope we can get away with something much much simpler. I prefer a solution where the managed device essentially knows where to connect to and then the manager takes over the connection [and presumably the manager knows what to do with the device]. /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 Fri Jun 23 12:06:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtoB2-0007Kq-Cc for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 12:06:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtoB1-0007E3-OT for netconf-archive@lists.ietf.org; Fri, 23 Jun 2006 12:06:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fto53-0005Cv-1n for netconf-data@psg.com; Fri, 23 Jun 2006 16:00:25 +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 1Fto4z-0005CT-GU for netconf@ops.ietf.org; Fri, 23 Jun 2006 16:00:21 +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 k5NG0I8g012771 for ; Fri, 23 Jun 2006 12:00:19 -0400 Received: (qmail 11517 invoked by uid 78); 23 Jun 2006 15:49:25 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 23 Jun 2006 15:49:25 -0000 Message-ID: <449C0D4B.7020702@andybierman.com> Date: Fri, 23 Jun 2006 08:48:27 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: Some thoughts about Call-home References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <449BC3D4.2020008@ericsson.com> In-Reply-To: <449BC3D4.2020008@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: cdeeb24e6b743a852c396a4af0e53c8f Balazs Lengyel wrote: > Hello, > Here are some thoughts about the call-home function. Sadly I was unable > to complete it, but it might be still useful. Yes -- there is a lot of detail here. I still need to go through it all. The complexity of the callhome feature should be as low as possible. You are supporting some options that may or may not end up in the final standard (e.g. mixed-mode sessions). Up until now, it has been acceptable in the IETF to define a standard protocol such as callhome, but not define any standard way to configure it. I think the NETCONF WG has to break out of that mindset, and start thinking about complete NM standards that actually work. I applaud your effort towards this goal. I agree with you that a standard mechanism to call home is much more useful if you also have a standard way to tell the agent where home is. Andy > > ========================================================================= > > [NOTE] > Subscription based notification is good if > - the management application wants to receive notifications for a short > period of time > - if the set of notifications the management application is interested > in changes frequently (changing filter) > > Statically configured notification delivery is best for management > applications if > - the manager is interested in the same set of notifications for a long > time. > - it does not want to reconfigure the managed device after eventual > restarts, loss of connections etc. > - the manager does not want to maintain a Netconf connection > permanently, but still needs some notifications > - the manager handles a big number of devices, so establishing Netconf > session to each would be a major task > > 0. Call-Home Capability > > 0.1. Description > > 0.1.1 Overview > > Call-Home capability allows a Netconf server to send notifications to a > client even if there is no Netconf live session between the client > and the > server initially when the server wants to send a notification. > The capability can be useful for NAT traversal as in this model, the > Netconf server initiates the Notification session. Another use case is > when a manager handles a large number of devices that it > only wants to deal with when there is a known issue. It is useful if > it would be to much > work for the manager to set up Netconf sessions to every device after > e.g. a manager restart. > > The device has to configured with data about which clients(targets) > should be contacted. Data about each target will include: > - Target Name (key) > - Target Transport Address > - Transport type (SSH, BEEP, SOAP) > - Target Security name to use > - Security Credential Type > - Security Credential > - Notifications Filter associated > - Use Mixed Notification Sessions (boolean) > - Active/Passive > - Removed With Session (sessionId) > - Currently used sessionId (read-only) > - Inactivity Timeout > The above data will be stored for each target in non-volatile memory. > > [NOTE] This should be the same data model as used for subscriptions. > > Target name (human readable string) is the key that identifies the > target. > Transport Address is an IPv4 or IPv6 address or a fully qualified > domain name and an optional port number. If the Netconf default > port is used port can be set to zero. > Transport Type identifies the underlying transport in case when > multiple types are supported by the Netconf server. > Security Name defines the security name to use when initiating > a new session. > Security credential type can be something like plain password, a > certificate, [TODO] > Security credential will be used to set up the session > Filter will be used to decide whether an individual notification > shall be sent to a target. > Use Mixed Notification Sessions [TODO] Needed ? > Active/Passive indicates whether notifications should be sent to > this target. This allows managers to configure the Netconf > server but still temporarily suspend notification delivery. > Removed With Session indicates that the target was created by > a subscription by the indicated session and it should be deleted > when that session is closed. > SessionId indicates the current session used for delivering > notifications. This maybe null [TODO how to really indicate null] > if there is no such session. > Inactivity Timeout indicates that the time when the session > should be automatically closed if it is not used. The session will > be removed only if Removed With Session is null i.e. the session > is not subscription based. > > Targets are created by normal configuration operations > (, ). Any referenced filters must be created > before the notification target. For short lived subscriptions either > the Removed With Session field shall be used or the target shall be > removed with a subsequent configuration operation. > > When an event of interest happens the Netconf server should go > through the following steps: > > For each event { > determine the targets, > apply filters, > send message request to message processing > } > For each message request { > build notification, > send message to transport mapping > } > For each message { > Check if you have a CurrentlyUsedSessionId > If not, create session UseMixedNotifictionSessions=false, > RemovedWithSession=null, > store used sessionId > send message > } > > If session setup fails, the target is simply skipped for this > notification. The Netconf server may notify the individual > targets in any order. > > [NOTE] A session for notifications can be started in two ways. > - By call-home in which case we can reuse the session. > - By subscription in which case we can again reuse the session. > - However if there is a session to the same manager entity, but > it did not subscriber to the target, it probably does not want to > receive notifications, so we should not reuse that session > i.e. we should not try to search for a session with the same > transport address, security name etc. > > [NOTE] A slightly different approach then in SNMP TMSM was chosen. > In TMSM session can be identified by transportAddress, securityName, > securityModel, and securityLevel while In Netconf there is a > possibility to have multiple logically separate sessions between a > manager and an agent with the same security and transport data > but e.g. different filters or one with need for notifications and > one which does not want to receive notifications. > > Similarly to the SNMP TMSM Netconf Applications typically have no > knowledge of whether the session > that will be used to carry notifications was initially established due > to a subscription or due to call-home, and SHOULD NOT make any > assumptions based on knowing the direction of establishment of the > session. > > > 0.1.1.1 Session Lifecycle > > Session setup including authentication is seen as a somewhat expensive > activity, so similarly to SNMP TMSM Netconf will allow the cost of > authentication to be amortized over potentially many notification > transfers. > In order to avoid situations in which a session is continuously > setup and torn down, an inactivity timer is configured on the server. > By default the timeout interval is the same for all sessions (but can > be modified) and each session has its own timer. Upon expiration of the > inactivity timer, the connection is terminated, otherwise if a > notification > is sent on the session, the timer is reset. > > The session establishment procedure is as follows: > > 1) The NETCONF server initiates a session using a recognized > application protocol (SSH, Beep, SOAP, etc). In order to "activate" > this reverse behavior a new SSH subsystem may need to be defined. > > This is for further study. In addition, the NE hosting the NETCONF > server must support both client and server modes in the case of SSH. > > 2) Client and server are authenticated according to the underlying > application protocol (e.g. SSH, BEEP) > > 3) If using BEEP, as described in [NETCONF-BEEP] either party may > initiate the BEEP session. Once this occurs, the assumption is that > both parties know their roles. At this point, the NETCONF client, > initiates NETCONF session establishment whether running SSH or BEEP. > > > 0.2. Dependencies > > Possible dependencies dependent on other parts of the draft: > - simple notifications (subscription based) without call-home > - mixed session capability > > 0.3. Capability Identifier > > urn:ietf:params:xml:ns:netconf:callHomeNotification:1.0 > > 0.4. New Operations > > None > > First information rpc ? > > 0.5 Modifications to Existing Operations > > None > > 0.6 New Data Model > > > [TODO] > > > 0.7 Interactions with Other Capabilities > > Simple notifications and Call-home notifications use the same data > model. > > ============================================================================== > > > who is the other side ? > > transport mapping ? > > SSH > netconf-reverse subsystem ? > agent should be able to act as client > serverkey, password > > BEEP > BEEP profiles plus some indication of > role (either within protocol or outside)o > > SOAP > > Initial message needed ? > > -- > to 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 Jun 26 11:48:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutKQ-0005Kf-Mq for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 11:48:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutKO-0003C1-6M for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 11:48:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FutEN-000ECb-4D for netconf-data@psg.com; Mon, 26 Jun 2006 15:42:31 +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 [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FutEM-000ECP-5q for netconf@ops.ietf.org; Mon, 26 Jun 2006 15:42:30 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) by mail.tail-f.com (Postfix) with ESMTP id 05F221B8011; Mon, 26 Jun 2006 17:42:19 +0200 (CEST) Date: Mon, 26 Jun 2006 17:42:16 +0200 (CEST) Message-Id: <20060626.174216.54435920.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: Re: Update to Netconf Notifications Draft From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4095C617F@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4095C5B02@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4095C617F@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi, A comment on section 3.8, interleaving messages. Suppose the manager sends a large copy-config and at the same time the agent sends a large notification. If care is not taken, the write() call on each side can block, and we would get deadlock. To avoid this, the manager and/or agent could be required to use non-blocking io, and - while writing the large message - read from the session and buffer internally. Alternatively, the agent could use two threads. Should any of this be specified? Does a client application which supports interleaving messages have to use non-blocking io in order to be compliant (or should the agent handle this)? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 13:10:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuubb-0002Fj-DX for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 13:10:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuubY-0002Z9-0E for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 13:10:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuuX2-000Mmn-4t for netconf-data@psg.com; Mon, 26 Jun 2006 17:05:52 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuuWz-000Ml9-E9 for netconf@ops.ietf.org; Mon, 26 Jun 2006 17:05:49 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5QH5mpV017502 for ; Mon, 26 Jun 2006 13:05:48 -0400 Received: (qmail 21765 invoked by uid 78); 26 Jun 2006 17:05:44 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 26 Jun 2006 17:05:44 -0000 Message-ID: <44A01420.8000003@andybierman.com> Date: Mon, 26 Jun 2006 10:06:40 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Update to Netconf Notifications Draft References: <713043CE8B8E1348AF3C546DBE02C1B4095C5B02@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4095C617F@zcarhxm2.corp.nortel.com> <20060626.174216.54435920.mbj@tail-f.com> In-Reply-To: <20060626.174216.54435920.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Martin Bjorklund wrote: > Hi, > > A comment on section 3.8, interleaving messages. The larger issue that is still unresolved is how important this feature is to have. The extended RPC approach is much simpler, at the cost of the resources for an additional session. The extended RPC approach is also much better for the 'ping' scenario than a special notification type for 'RPC reply'. We still have a high-level disagreement on the relative engineering cost trade-offs of using 2 sessions vs. sharing 1 session for operations and notifications. IMO, we are pretty far from a clean standard. The eventual solution will need to provide for proper standard read-create data models, specify a reasonable architecture and security model, and be as simple as possible, with a small number of options. We also need to explain why it is so important that the NMS get copies of notifications in NETCONF sessions, as opposed to using a mgr-2-mgr API to get the same information from a notification receiver application (e.g., syslog + SNMP trap server). Some people have also suggested that we explain in the RFC why a special NETCONF notification system is needed in order to solve the network configuration problem. Andy > > Suppose the manager sends a large copy-config and at the same time the > agent sends a large notification. If care is not taken, the write() > call on each side can block, and we would get deadlock. To avoid > this, the manager and/or agent could be required to use non-blocking > io, and - while writing the large message - read from the session and > buffer internally. Alternatively, the agent could use two threads. > > Should any of this be specified? Does a client application which > supports interleaving messages have to use non-blocking io in order to > be compliant (or should the agent handle this)? > > > /martin > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Jun 26 15:41:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwxX-0006fl-Si for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 15:41:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwxW-0007KZ-FO for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 15:41:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuwtk-000ArV-HA for netconf-data@psg.com; Mon, 26 Jun 2006 19:37: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 autolearn=ham version=3.1.1 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuwtj-000ArG-I3 for netconf@ops.ietf.org; Mon, 26 Jun 2006 19:37:27 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) by mail.tail-f.com (Postfix) with ESMTP id 802CE1B8011; Mon, 26 Jun 2006 21:37:26 +0200 (CEST) Date: Mon, 26 Jun 2006 21:37:23 +0200 (CEST) Message-Id: <20060626.213723.39366307.mbj@tail-f.com> To: ietf@andybierman.com Cc: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Update to Netconf Notifications Draft From: Martin Bjorklund In-Reply-To: <44A01420.8000003@andybierman.com> References: <713043CE8B8E1348AF3C546DBE02C1B4095C617F@zcarhxm2.corp.nortel.com> <20060626.174216.54435920.mbj@tail-f.com> <44A01420.8000003@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > A comment on section 3.8, interleaving messages. > > The larger issue that is still unresolved is how > important this feature is to have. The extended RPC > approach is much simpler, at the cost of the resources > for an additional session. The extended RPC approach > is also much better for the 'ping' scenario than > a special notification type for 'RPC reply'. Altough I personally prefer the endless RPC model for events, I don't think it's "much simpler", at least not from an implementation point of view. The agent side might be simpler in some case (e.g. it doesn't have to deal with a modify command), but on the other hand the manager side needs to synchronize events if it wants to emulate a modify operation. Also, even if the model in Sharon's draft is used for events, the endless RPC can still be used for ping-like commands. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:17:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyT1-0006OE-Bg for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:17:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuySz-0007wA-WD for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:17:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyOS-000Ilm-6e for netconf-data@psg.com; Mon, 26 Jun 2006 21:13:16 +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 1FuyOR-000IlO-2j for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:13:15 +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 k5QLDCo2021016 for ; Mon, 26 Jun 2006 17:13:14 -0400 Received: (qmail 25478 invoked by uid 78); 26 Jun 2006 21:13:12 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 26 Jun 2006 21:13:12 -0000 Message-ID: <44A04E45.1090304@andybierman.com> Date: Mon, 26 Jun 2006 14:14:45 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Bjorklund CC: schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Update to Netconf Notifications Draft References: <713043CE8B8E1348AF3C546DBE02C1B4095C617F@zcarhxm2.corp.nortel.com> <20060626.174216.54435920.mbj@tail-f.com> <44A01420.8000003@andybierman.com> <20060626.213723.39366307.mbj@tail-f.com> In-Reply-To: <20060626.213723.39366307.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> >>> A comment on section 3.8, interleaving messages. >> The larger issue that is still unresolved is how >> important this feature is to have. The extended RPC >> approach is much simpler, at the cost of the resources >> for an additional session. The extended RPC approach >> is also much better for the 'ping' scenario than >> a special notification type for 'RPC reply'. > > Altough I personally prefer the endless RPC model for events, I don't > think it's "much simpler", at least not from an implementation point > of view. The agent side might be simpler in some case (e.g. it > doesn't have to deal with a modify command), but on the other hand the > manager side needs to synchronize events if it wants to emulate a > modify operation. The manager has to synch notifications to operations using 2 or 3 different protocols now. I am talking about 2 sessions of the same protocol instead. It is true that the manager design has to allow for more than one active session per agent. This doesn't seem much harder than allowing for more than one active session (to different agents). The agent already has code to keep multiple sessions from stepping on each other. For mixed-mode, it needs additional code to provide the same sort of safeguards within a session as well. I changed the name from "endless RPC" to "extended RPC" because it does end if so requested. BTW, there is absolutely no difference at all from a NMS implementation POV, between an agent that is sending an extended rpc-reply (e.g., element sent as needed) and an agent that is sending the contents of a reply really, really, slowly.... There is no requirement at all that any portion of a NETCONF PDU be transmitted within a certain period of time. Managers and agents need to deal with this fact. > > Also, even if the model in Sharon's draft is used for events, the > endless RPC can still be used for ping-like commands. Yes, you can already do this -- without changing a single word in the NETCONF spec. > > > /martin > Andy > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:24:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyZc-0004oI-Ib for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:24:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyZb-00084o-8o for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:24:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyWe-000JXG-8x for netconf-data@psg.com; Mon, 26 Jun 2006 21:21:44 +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 1FuyWd-000JX1-NP for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:21:43 +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 k5QLLf1Z086144; Mon, 26 Jun 2006 14:21:41 -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 k5QLLf584783; Mon, 26 Jun 2006 14:21:41 -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 k5QLLewn055980; Mon, 26 Jun 2006 17:21:40 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262121.k5QLLewn055980@idle.juniper.net> To: Balazs Lengyel cc: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Thu, 22 Jun 2006 11:55:04 +0200." <449A68F8.8010608@ericsson.com> Date: Mon, 26 Jun 2006 17:21:40 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Balazs Lengyel writes: >1) I want to fetch recorded data from yesterday 12:00Z till >13:00Z. The draft doesn't seem >to allow this as the stop time is already in the past. I would allow this! The draft allows this; see 3.2.1.1 (Closing the Response). >2) Same comments as for Sharon's draft: >Use a data model for streams and use the get and edit-config >operations instead of a custom operation for a small set of special >(?) data. Even if streams can be defined in multiple ways >(configuration, system default, etc.) they still can nicely be modeled >as read-only data. System defaults aren't read-only data; see 1.3 in the netconf-prot spec. > > I'm not prepared to be the first lamb on that altar. ;^) >Someone has to be :-) otherwise NETCONF is dead already. Nope, it's the opposite. NETCONF is in its infancy. The raw config parts are starting to gel and get widely implemented but the role of standard data models, how they are defined, where they fit, how and when the translation between the standard and the device-specific occurs, and what to do when things don't quite translate are all wide open areas which need tons of work. We should work to make our puppy grow up, but should continue to do reasonable work in parallel to allow the growing pup is useful asap for taming real world problems. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:25:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyZy-0005ZV-VC for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyZx-00085M-Lw for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyXj-000JdW-MN for netconf-data@psg.com; Mon, 26 Jun 2006 21:22:51 +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 1FuyXi-000JdK-MR for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:22:50 +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 k5QLMi1Z086165; Mon, 26 Jun 2006 14:22:44 -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 k5QLMh585056; Mon, 26 Jun 2006 14:22:43 -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 k5QLMhwn056000; Mon, 26 Jun 2006 17:22:43 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262122.k5QLMhwn056000@idle.juniper.net> To: "Sharon Chisholm" cc: netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Thu, 22 Jun 2006 11:58:49 EDT." <713043CE8B8E1348AF3C546DBE02C1B4095C5F20@zcarhxm2.corp.nortel.com> Date: Mon, 26 Jun 2006 17:22:43 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f "Sharon Chisholm" writes: >My main problem with 2) is that it opens things up for over-engineering >and it also makes the network element the authoritative source of the >subscription parameters while I really want the netconf client to be. It >also has some garbage collection issues. I go the other way, since I want the device to define what the client will be able to receive. I want to look at my device's config and know that I'm safe and sane. I don't want to have to depend on the safety and sanity of every application. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:25:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuya6-0006cU-Bh for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuya5-00085V-2q for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyY0-000Jf3-Ss for netconf-data@psg.com; Mon, 26 Jun 2006 21:23:08 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyY0-000Jep-91 for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:23:08 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5QLMZX04383; Mon, 26 Jun 2006 14:22:35 -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 k5QLMU584974; Mon, 26 Jun 2006 14:22:30 -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 k5QLMTwn055992; Mon, 26 Jun 2006 17:22:29 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262122.k5QLMTwn055992@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Thu, 22 Jun 2006 08:20:18 PDT." <449AB532.6030105@andybierman.com> Date: Mon, 26 Jun 2006 17:22:29 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Andy Bierman writes: >We spent about 5 years developing a set of standard operations >for the standard manipulation of NV-stored configuration data >models encoded in XML. Five years? Wow... "And thank you so much for bringing up such a painful subject. While you're at it, why don't you give me a nice paper cut and pour lemon juice on it?" (-- Miracle Max) ;^) >> And why do we have and again? >To retrieve data was the "thar be dragons" part of the spec. seemed so much safer. ;^) Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:25:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyaV-0006i1-3k for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyaT-00085z-Qk for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyYj-000JnD-1j for netconf-data@psg.com; Mon, 26 Jun 2006 21:23:53 +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 1FuyYi-000Jmu-J6 for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:23:52 +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 k5QLMx1Z086186; Mon, 26 Jun 2006 14:22:59 -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 k5QLMw585165; Mon, 26 Jun 2006 14:22:58 -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 k5QLMvwn056008; Mon, 26 Jun 2006 17:22:57 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262122.k5QLMvwn056008@idle.juniper.net> To: Andy Bierman cc: Kent Watsen , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Thu, 22 Jun 2006 11:21:12 PDT." <449ADF98.3000005@andybierman.com> Date: Mon, 26 Jun 2006 17:22:57 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Andy Bierman writes: >> BTW, Phil's proposal is good wrt all this in that it uses device-wide >> streams (i.e. topics) on which session-specific filters can be applied. >Neither proposal allows for NV-storage of parameters >which are not session-specific. This is a major problem. The netconf-syslog draft allows this, since it has a set of streams defined by the device which specify a set notification data available from the device. The stream may have filters (and other parameters) associated with it. Not every stream must exist in the device's configuration, but they are certainly allowed to. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:25:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuyad-0006if-L9 for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuyac-00086A-BB for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:25:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyYO-000Jhv-9W for netconf-data@psg.com; Mon, 26 Jun 2006 21:23:32 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyYN-000Jhf-PW for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:23:31 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5QLNTX04415; Mon, 26 Jun 2006 14:23:29 -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 k5QLNO585347; Mon, 26 Jun 2006 14:23:24 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k5QLNOwn056028; Mon, 26 Jun 2006 17:23:24 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262123.k5QLNOwn056028@idle.juniper.net> To: Balazs Lengyel cc: netconf@ops.ietf.org Subject: Re: draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Fri, 23 Jun 2006 09:59:37 +0200." <449B9F69.5090401@ericsson.com> Date: Mon, 26 Jun 2006 17:23:24 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Balazs Lengyel writes: >1) If I want to refer to data in my configuration store how do I do >that in the syslog solution? There's no current mechanism, but we should be able to use the from (with a different tag name). >2) If I want to refer to a previous Netconf operation in syslog >I have to embed the Netconf sessionId, messageId and some >additional XML in syslog in a proprietary way. Not so nice. We could do these as standard SD parameters. >3) Do we need call-home for syslog? They are complementary, but not prerequisites. >While this solution is good for nodes that already use syslog, >for those that do not, this is an additional protocol layer that >you have to wrap your information in. Additional work. Considering the overwhelming volume of syslog data and the minimal size of the wrapping, this seems like an easy call. >Also I see a risk that we might delay standardizing a number of >important features like: >how to refer to the data model and other netconf operations in >netconf notifications I don't really follow you here. How does this draft increase the risk of delay for standardizing other features? >I would rather support Sharon's idea to provide syslog as one option >for netconf notifications but definitely not the main method. The three options are snmp, syslog, and roll-your-own. Operators and vendors are fully invested in both snmp and syslog, so rolling your own really is not an acceptable option. The volume of existing syslog data, as well as the extensibility, make this my choice. Basically, my goal is to take the biggest available data set and move it onto the netconf. That's what the draft attempts to do. It's not an ideal solution, nor one that one would aim for on a green field world, but given the zillions of lines of syslog() calls and the current way that operators are using this data, it's the best path to the maximum content. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:26:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuybI-000759-Qq for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:26:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuybH-00086w-HT for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:26:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyZ5-000Jqp-1L for netconf-data@psg.com; Mon, 26 Jun 2006 21:24:15 +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 1FuyZ4-000JqV-Hm for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:24:14 +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 k5QLO91Z086224; Mon, 26 Jun 2006 14:24:09 -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 k5QLO9585563; Mon, 26 Jun 2006 14:24:09 -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 k5QLO9wn056052; Mon, 26 Jun 2006 17:24:09 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262124.k5QLO9wn056052@idle.juniper.net> To: Andy Bierman cc: Balazs Lengyel , "Netconf (E-mail)" Subject: Re: Some thoughts about Call-home In-Reply-To: Your message of "Fri, 23 Jun 2006 08:48:27 PDT." <449C0D4B.7020702@andybierman.com> Date: Mon, 26 Jun 2006 17:24:09 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Andy Bierman writes: >Up until now, it has been acceptable in the IETF to define a >standard protocol such as callhome, but not define any standard >way to configure it. A standard config is fine, but we've got a long way to go to get there. Developing the tools for data models (language, constraints, etc) will take a long time. If you are saying that these are required before other standard capabilities can be developed, then we need to stop talking about everything else and get to work on these tools immediately. We either need to migrate the MIB tools over, find existing tools for XML, or roll our own. None are simple options. This is the altar that I didn't want to get left on, since the lack of a standard mechanism for configuring event streams shouldn't block us from defining them and using them. We can make progress in parallel. >I agree with you >that a standard mechanism to call home is much more useful if >you also have a standard way to tell the agent where home is. Same scenario here. The ability of the device to reach home isn't gated by the manager being able to configure it. The mechanism for reaching the manager is useful in its own right. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:26:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuybQ-00075N-W9 for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:26:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuybP-00087B-NO for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:26:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyYc-000Jm5-5j for netconf-data@psg.com; Mon, 26 Jun 2006 21:23: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 [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 1FuyYb-000Jlt-PO for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:23:45 +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 k5QLNd1Z086212; Mon, 26 Jun 2006 14:23:39 -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 k5QLNd585380; Mon, 26 Jun 2006 14:23:39 -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 k5QLNcwn056040; Mon, 26 Jun 2006 17:23:38 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262123.k5QLNcwn056040@idle.juniper.net> To: j.schoenwaelder@iu-bremen.de cc: Balazs Lengyel , "Netconf (E-mail)" Subject: Re: Some thoughts about Call-home In-Reply-To: Your message of "Fri, 23 Jun 2006 13:34:51 +0200." <20060623113451.GA5283@boskop.local> Date: Mon, 26 Jun 2006 17:23:38 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Juergen Schoenwaelder writes: >I hope we can get away with something much much simpler. I prefer a >solution where the managed device essentially knows where to connect >to and then the manager takes over the connection [and presumably the >manager knows what to do with the device]. Loud Amens. If the manager doesn't know why the device called home, it can ask it using a operation. The results may include a number of recent call home reasons. The manager can review these to see which ones need tended to. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:27:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuybx-0007Jy-Rv for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:27:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuybv-00087i-Df for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:27:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyYJ-000JhF-Mq for netconf-data@psg.com; Mon, 26 Jun 2006 21:23: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuyYI-000Jgw-SL for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:23:26 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5QLNIX04411; Mon, 26 Jun 2006 14:23:18 -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 k5QLN8585270; Mon, 26 Jun 2006 14:23:08 -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 k5QLN7wn056016; Mon, 26 Jun 2006 17:23:08 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262123.k5QLN7wn056016@idle.juniper.net> To: "Rainer Gerhards" cc: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org Subject: Re: Tweeks to draft-shafer-netconf-syslog-00.txt In-Reply-To: Your message of "Fri, 23 Jun 2006 09:48:49 +0200." <577465F99B41C842AAFBE9ED71E70ABA1749D4@grfint2.intern.adiscon.com> Date: Mon, 26 Jun 2006 17:23:07 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Most excellent feedback. I'll update the draft accordingly. Thanks, Phil "Rainer Gerhards" writes: >If I understood the spirit of the previous diagrams right, then how >about that: > > remote > +----+ --SYSLOG-->syslog > | c1 |---+ / receiver > +----+ | +------+ > +----+ | | | > | c2 | +--->|syslog| +-------+ +-------+ > +----+ | |server| |netconf|<-NETCONF->|netconf| > ... | | |------>|server | |client | > System | +------+ +-------+ +-------+ > Components| ^ | ^ > ... | | | | > +----+ | S | v > | cn |---+ Y | (------------) > +----+ S +----->(notification) > L ( repository ) > O (------------) > remote G > syslog --------+ > sender > >Arrows with protocol names indicate message transport via the named >protocol. Arrows without names use no specific protocols and may be >internal APIs. SYSLOG terminology (sender, receiver) is defined in >draft-ietf-syslog-protocol-17. The arrow between the "netconf server" >and the "notification repository" indicates that the netconf server >accesses the repository. The arrow between "syslog server" and >"notification repository" indicates that the syslog server submits data >to the repository but is not expected to pull any data out of it. The >data flow shown is informative, only. It does not demand any specific >implementation. > >Some more points: > >1. I have changed the "notification logging service" to "notification >repository". IMO, the important point is that there is a repository for >notifications. In actual software, I'd expect this to be a data store >which is written by the syslogd and read by the netconf server. It could >(should?) also be written to (configured) by the netconf server (e.g. >expiration of log data, access policies). It could be discussed if the >netconf server should have other write capabilities (e.g. delete >events), but I think this is irrelevant wrt this draft). > >2. I have replaced the term "syslog daemon" by "syslog server". Though >the former is well-known, the later is more generic and >platform-independent. > >3. One word on the relationship of the syslog to the netconf >server.There is no pure syslog or pure netconf server on either side. A >pure syslog server can not talk netconf to a netconf server because it >does not know about that. Actually, I would expect both of them to be >inside a single app (at least from the architecture point of view), >talking to each other via API, local RPC or simple internal function >calls. Something like this: > > +---------------------------+ > | syslog/netconf app | > | +------+ +-------+ | > --SYSLOG->|syslog| |netconf|<-NETCONF-> > | |server|-API->|server | | > | +------+ +-------+ | > +---------------------------+ > One might now argue that this is the reason that all events should go >through the the event repository. IMHO this is not a practical option as >we would like to see realtime delivery. In any case it is nothing that >happens on the wire, so it is out of the scope of any IETF WG. I still >find it useful to have the conceptual data flow in the diagram. > >Rainer > >> I do not understand what "netconf session delivery" means. For me, a >> netconf session exists between a netconf server and a netconf client. >> It is also unclear what the double lines // mean. If the figure is >> meant to indicate the syslog data flow, then also the double arrow >> between netconf server and netconf client is wrong. If the arrows are >> supposed to mean something else, I think a legend is required to >> discuss the figure. Well, a legend is required in any case. >> >> /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: >> > >-- >to 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 Jun 26 17:27:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuybz-0007KB-Lc for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:27:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuyby-00087n-Bn for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:27:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuya5-000K5Z-Sy for netconf-data@psg.com; Mon, 26 Jun 2006 21:25:17 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuya5-000K5E-E0 for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:25:17 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5QLOuX04427; Mon, 26 Jun 2006 14:24:56 -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 k5QLOp585744; Mon, 26 Jun 2006 14:24:51 -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 k5QLOown056081; Mon, 26 Jun 2006 17:24:50 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606262124.k5QLOown056081@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Update to Netconf Notifications Draft In-Reply-To: Your message of "Mon, 26 Jun 2006 10:06:40 PDT." <44A01420.8000003@andybierman.com> Date: Mon, 26 Jun 2006 17:24:50 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d [back from vacation and kickstarting my brain (putt, putt)] Andy Bierman writes: >The eventual solution will need to provide for >proper standard read-create data models, specify >a reasonable architecture and security model, >and be as simple as possible, with a small number >of options. With the exception of the create (.vs. write?) data model, I think I cover most of this. What are you looking for wrt the security model? Security of the content of the data (permission to see bgp peer information) or just security of the data as a whole (as covered by the transport protocol)? >We also need to explain why it is so important that >the NMS get copies of notifications in NETCONF sessions, >as opposed to using a mgr-2-mgr API to get the same information >from a notification receiver application (e.g., syslog + >SNMP trap server). Syslog and snmp are traditionally preconfigured, with the device knowing (from config) who to aim notifications at. This works well in traditional environments but breaks in the "pop open my laptop and run my application locally" world. When configuring a device, access to the notifications it is sending gives valuable information about the state of the box, what's going on, and what you just broke. Being able to see this in your application (and being able to react to it automatically) is a win. I have some words about this in the draft; do I need more? Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jun 26 17:59:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz7G-0007KS-Qr for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:59:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuz7F-0003hN-Fw for netconf-archive@lists.ietf.org; Mon, 26 Jun 2006 17:59:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuz4O-000Mu8-DX for netconf-data@psg.com; Mon, 26 Jun 2006 21:56: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.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuz4M-000Mtv-Tb for netconf@ops.ietf.org; Mon, 26 Jun 2006 21:56:35 +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 k5QLuWx0030243 for ; Mon, 26 Jun 2006 17:56:33 -0400 Received: (qmail 27951 invoked by uid 78); 26 Jun 2006 21:56:32 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 26 Jun 2006 21:56:32 -0000 Message-ID: <44A05873.2080107@andybierman.com> Date: Mon, 26 Jun 2006 14:58:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <200606262122.k5QLMTwn055992@idle.juniper.net> In-Reply-To: <200606262122.k5QLMTwn055992@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Phil Shafer wrote: > Andy Bierman writes: >> We spent about 5 years developing a set of standard operations >> for the standard manipulation of NV-stored configuration data >> models encoded in XML. > > Five years? Wow... "And thank you so much for bringing up such a > painful subject. While you're at it, why don't you give me a nice > paper cut and pour lemon juice on it?" (-- Miracle Max) > > ;^) > >>> And why do we have and again? >> To retrieve data > > was the "thar be dragons" part of the spec. > seemed so much safer. ;^) Doesn't really matter if it's or . I'm not willing to accept a solution path that starts out with little piles of unrelated "pseudo-data models" which do not utilize the standard operations we already have. I think that managing 100s or 1000s of and even functions, which ignores the , , model variants, ignores , and does not show up at all when I do a , , or operation -- is a fairly broken design. This isn't a hard problem. We just define a data model and instead of reflexively labeling everything max-access read-only, we label it read-create instead. As far as data organization, again, not a hard problem. 1) Define a namespace for netconf data: urn:ietf:params:xml:ns:netconf:data:1.0 2) Define a structure to organize data and separate config from state data, e.g.: 3) Transfer the pseudo-data model to the appropriate container and call it a real data model. > > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 03:59:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8Td-0004X5-J3 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 03:59:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv8Tb-0005WO-L7 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 03:59:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv8Ni-000Np2-Hv for netconf-data@psg.com; Tue, 27 Jun 2006 07:53: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=BAYES_00,FORGED_RCVD_HELO, SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv8Ng-000Nod-Pt for netconf@ops.ietf.org; Tue, 27 Jun 2006 07:53:09 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DFEB827C065; Tue, 27 Jun 2006 09:49:25 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26232-05; Tue, 27 Jun 2006 09:49:25 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 8F71427C061; Tue, 27 Jun 2006 09:49:25 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 09:53:05 +0200 Content-class: urn:content-classes:message Subject: RE: draft-shafer-netconf-syslog-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 09:53:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174A21@grfint2.intern.adiscon.com> In-Reply-To: <200606262123.k5QLNOwn056028@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaZaD4xOc8MaA+GTVOOKsEqq2DFOAAUrpIg From: "Rainer Gerhards" To: "Phil Shafer" , "Balazs Lengyel" Cc: X-OriginalArrivalTime: 27 Jun 2006 07:53:05.0264 (UTC) FILETIME=[B8F68F00:01C699BE] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > >2) If I want to refer to a previous Netconf operation in syslog > >I have to embed the Netconf sessionId, messageId and some > >additional XML in syslog in a proprietary way. Not so nice. >=20 > We could do these as standard SD parameters. STRUCTURED-DATA in syslog was intentionally choosen to be not XML. The reason is that very low end receivers do not need to take care of XML and existing applications can quickly be adopted. It is arguable if that is the best choice (right now this topic is again brought up on the syslog mailing list). HOWEVER, that does not mean that STRUCTURED-DATA can not contain XML. It can, but as part of a value. So to embed NETCONF session information, you could use something like this in structured data: [netconf rpc=3D""] I agree it looks somewhat ugly, but it is an absolutely "clean" solution and in no way proprietary. You need to take into account message size limitations in syslog, which may limit your ability to use large chunks of XML inside the actual syslog message. If syslog is transported over netconf, this obviously is a no-issue, so you do not need to place restrictions here. All of this is in the spirit of the syslog I-Ds, which provision of highly different capablities of senders and receivers. syslog does this because these capability differences do exist in practice and we can not ignore them. > >I would rather support Sharon's idea to provide syslog as one option > >for netconf notifications but definitely not the main method. >=20 > The three options are snmp, syslog, and roll-your-own. Operators and > vendors are fully invested in both snmp and syslog, so rolling your > own really is not an acceptable option. The volume of existing syslog > data, as well as the extensibility, make this my choice. >=20 > Basically, my goal is to take the biggest available data set and move > it onto the netconf. That's what the draft attempts to do. It's not > an ideal solution, nor one that one would aim for on a green field > world, but given the zillions of lines of syslog() calls and the > current way that operators are using this data, it's the best path to > the maximum content. I support Phil's position. SYSLOG is a de-facto standard and very widely deployed. It seems irrealistically that any time soon the POSIX logging API *and* all applications using it will be upgrade to NETCONF (notifications) or whatever. Not even the syslog WG expects this for upcoming syslog changes. My personal position is that we will have legacy syslog for at least another 10 years, if not longer. The challenge is to mine syslog data while allowing to integrate it into a more sophisticated system. NETCONF seems to have some potential as a notification receiver (though I wouldn't have expected that from a network *configuration* protocol in the first place).=20 The most important thing obviously is a united event notification data model (for syslog, SNMP, netconf, name-your-own). But, IMHO, we are very far from that. Even if we had, we would need to use transforming gateways for quite a while. So before we go for this glory united data model, we should try to get all the data into a single location. That can only be done via an evolutionary approach (look at RFC 3195 in the syslog space and you'll see what happens if things are too different). This is where I see Phil's draft. It is better to have something not-so-perfect within a (relatively) short period of time than to wait many years for the ultimate solution. You always can upgrade the not-so-perfect one, but if you do it first, you can enjoy its benefits while upgrading it. Just my 2cts... Rainer >=20 > Thanks, > Phil >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 11:23:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFPZ-0004Kv-S4 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 11:23:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvFI8-0005mf-Ag for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 11:15:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvFBe-000LLT-4y for netconf-data@psg.com; Tue, 27 Jun 2006 15:09: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.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvFBb-000LLA-MQ for netconf@ops.ietf.org; Tue, 27 Jun 2006 15:09:07 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5RF96ei026655 for ; Tue, 27 Jun 2006 11:09:07 -0400 Received: (qmail 20042 invoked by uid 78); 27 Jun 2006 15:09:06 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.68 with SMTP; 27 Jun 2006 15:09:06 -0000 Message-ID: <44A149F4.1090403@andybierman.com> Date: Tue, 27 Jun 2006 08:08:36 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: projector for the interim meeting Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi, I never confirmed that somebody has a video projector for slides that we can use during the interim meeting. (I don't need to pay for a screen if we don't have a projector.) Any volunteers? thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 12:32:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGU7-0003fR-NO for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 12:32:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGU6-00065e-Af for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 12:32:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvGJI-0003wE-V0 for netconf-data@psg.com; Tue, 27 Jun 2006 16:21:08 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvGJI-0003w1-7B for netconf@ops.ietf.org; Tue, 27 Jun 2006 16:21:08 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5RGKSX24173; Tue, 27 Jun 2006 09:20:28 -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 k5RGKM504283; Tue, 27 Jun 2006 09:20:22 -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 k5RGKLwn058324; Tue, 27 Jun 2006 12:20:22 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606271620.k5RGKLwn058324@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Mon, 26 Jun 2006 14:58:11 PDT." <44A05873.2080107@andybierman.com> Date: Tue, 27 Jun 2006 12:20:21 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Andy Bierman writes: >I think that managing 100s or 1000s of and >even functions, which ignores the , >, model variants, ignores , >and does not show up at all when I do a , >, or operation -- is a fairly broken design. I don't think it's broken at all. I think this is the point of using an RPC-based design. There are two reasons that I think this is a win. First, it's a better match for applications. More specific information in the API makes it a better API, both more readable and more easily implemented. Your unix program doesn't get filesystem information using get() or even ioctl(). It uses statfs() to get this data. It's a direct, easily documented mechanism for getting this particular content. The same is true for RPCs. I'd rather have: $results = $dev->get_syslog_streams(); than: $results = $dev->get("netconf/notifcations/config/whatever"); (or worse, having to build the xml object) It's similar to calling read() verses calling syscall() with the SYS_read system call number. Second, we're not making a green field solution. Device vendors have a ton of code supporting existing CLI commands, all brimming with information accessible via the command line. So I go in and make a to "command line" mapping, and get all the fancy command line arguments, types, ranges, help strings, etc for free. All this is fairly trivial code. But to do this scoped generic stuff, I need to understand a _whole_ lot more about the output of the commands, including not only which commands make which output tags, but which _options_ to those commands make the output. "show interfaces extensive" .vs. "show interfaces statistics". This is an immense pain. I'd basically have to build a completely new management system. I've said it before, but I continue to believe that netconf will fail if it becomes the "third way" (where first=cli and second=snmp). In the real world, the CLI gets implemented first, then SNMP (first proprietary MIBs, then standard MIBs). A completely disjoint netconf implementation will a distant third. We need to maximize the leverage we can get off the existing implementations, not become the third way. This was discussed at length in the prelude to netconf's creation. One of our goals was allowing the vendor to reuse their cli implementation to the greatest extent possible. In addition, the use of explicit RPCs gives you explicit arguments, which you need (or may need in the future) to refine the information retrieved. Or you may want your API for retrieving data to match the API for manipulating it, in the same way the parameter for matches the parameter for , , , , etc. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 13:34:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHSQ-0001m5-31 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:34:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHSO-0003zK-QN for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:34:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHO9-000A79-VM for netconf-data@psg.com; Tue, 27 Jun 2006 17:30: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.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 1FvHO9-000A6x-D6 for netconf@ops.ietf.org; Tue, 27 Jun 2006 17:30:13 +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 k5RHSa1Z002662; Tue, 27 Jun 2006 10:28:37 -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 k5RHSa518690; Tue, 27 Jun 2006 10:28:36 -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 k5RHSZwn058588; Tue, 27 Jun 2006 13:28:35 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606271728.k5RHSZwn058588@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Update to Netconf Notifications Draft In-Reply-To: Your message of "Mon, 26 Jun 2006 14:14:45 PDT." <44A04E45.1090304@andybierman.com> Date: Tue, 27 Jun 2006 13:28:35 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Andy Bierman writes: >I changed the name from "endless RPC" to "extended RPC" >because it does end if so requested. I called them long-lived RPCs in the draft, which seems fairly accurate. >> Also, even if the model in Sharon's draft is used for events, the >> endless RPC can still be used for ping-like commands. >Yes, you can already do this -- without changing a single >word in the NETCONF spec. I think this is the big difference between the drafts. Use the existing netconf RPC mechanism to deliver existing syslog data versus use a new mechanism to delivery new content. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 13:41:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHZ6-0006ap-EH for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:41:32 -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 1FvHZ6-0004XP-Cr for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:41:32 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvHXB-0001uw-RZ for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:39:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHUB-000Ai4-0Q for netconf-data@psg.com; Tue, 27 Jun 2006 17:36: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.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHU9-000Ahi-39 for netconf@ops.ietf.org; Tue, 27 Jun 2006 17:36:26 +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 k5RHaEsv028941 for ; Tue, 27 Jun 2006 13:36:24 -0400 Received: (qmail 3681 invoked by uid 78); 27 Jun 2006 17:36:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.67 with SMTP; 27 Jun 2006 17:36:13 -0000 Message-ID: <44A16C67.7050904@andybierman.com> Date: Tue, 27 Jun 2006 10:35:35 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Martin Bjorklund , schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Update to Netconf Notifications Draft References: <200606271728.k5RHSZwn058588@idle.juniper.net> In-Reply-To: <200606271728.k5RHSZwn058588@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Phil Shafer wrote: > Andy Bierman writes: >> I changed the name from "endless RPC" to "extended RPC" >> because it does end if so requested. > > I called them long-lived RPCs in the draft, which seems fairly > accurate. > >>> Also, even if the model in Sharon's draft is used for events, the >>> endless RPC can still be used for ping-like commands. >> Yes, you can already do this -- without changing a single >> word in the NETCONF spec. > > I think this is the big difference between the drafts. Use the > existing netconf RPC mechanism to deliver existing syslog data > versus use a new mechanism to delivery new content. Agree 110% !!! I would even say that it is Bad Engineering to invent new mechanisms when the existing mechanisms will do the job. > > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 13:41:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHZD-0006bI-Aa for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:41:39 -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 1FvHZD-0004Z1-9G for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:41:39 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvHOl-0001mE-Jj for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:30:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHJ6-0009c1-Ci for netconf-data@psg.com; Tue, 27 Jun 2006 17:25: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 1FvHJ4-0009bf-L5 for netconf@ops.ietf.org; Tue, 27 Jun 2006 17:24:59 +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 k5RHOl4I025689 for ; Tue, 27 Jun 2006 13:24:52 -0400 Received: (qmail 9930 invoked by uid 78); 27 Jun 2006 17:24:47 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 27 Jun 2006 17:24:47 -0000 Message-ID: <44A169B9.60102@andybierman.com> Date: Tue, 27 Jun 2006 10:24:09 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <200606271620.k5RGKLwn058324@idle.juniper.net> In-Reply-To: <200606271620.k5RGKLwn058324@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Phil Shafer wrote: What vendors do with their proprietary CLI/XML data models does not have a significant impact on what the IETF or this WG should do wrt/ standard data models. One significant operator requirement that came out of RFC 3535 is that the entire device configuration and state information could be retrieved as a whole tree, or portions of the tree could be retrieved, in a single operation. The concept of an ad-hoc collection of specialized RPCs used INSTEAD of standard data models and standard operations does not meet this requirement. Unless standard data shows up in exactly the same place, with the same syntax and same semantics, using the operation, then it isn't a standard that meets this requirement. Data model discovery becomes quite a nightmare if a manager has to know priori, each different set of special RPCs to use for every device it manages, and try them all to discover the entire device configuration and state. Andy > Andy Bierman writes: >> I think that managing 100s or 1000s of and >> even functions, which ignores the , >> , model variants, ignores , >> and does not show up at all when I do a , >> , or operation -- is a fairly broken design. > > I don't think it's broken at all. I think this is the point of using > an RPC-based design. There are two reasons that I think this is a > win. First, it's a better match for applications. More specific > information in the API makes it a better API, both more readable and > more easily implemented. Your unix program doesn't get filesystem > information using get() or even ioctl(). It uses statfs() to get this > data. It's a direct, easily documented mechanism for getting > this particular content. The same is true for RPCs. I'd rather have: > > $results = $dev->get_syslog_streams(); > > than: > > $results = $dev->get("netconf/notifcations/config/whatever"); > > (or worse, having to build the xml object) > > It's similar to calling read() verses calling syscall() with the SYS_read > system call number. > > Second, we're not making a green field solution. Device vendors have > a ton of code supporting existing CLI commands, all brimming with > information accessible via the command line. So I go in and make a > to "command line" mapping, and get all the fancy command > line arguments, types, ranges, help strings, etc for free. All this > is fairly trivial code. > > But to do this scoped generic stuff, I need to understand a _whole_ > lot more about the output of the commands, including not only which > commands make which output tags, but which _options_ to those > commands make the output. "show interfaces extensive" .vs. "show > interfaces statistics". This is an immense pain. > > I'd basically have to build a completely new management system. I've > said it before, but I continue to believe that netconf will fail if it > becomes the "third way" (where first=cli and second=snmp). In the > real world, the CLI gets implemented first, then SNMP (first > proprietary MIBs, then standard MIBs). A completely disjoint netconf > implementation will a distant third. We need to maximize the leverage > we can get off the existing implementations, not become the third way. > > This was discussed at length in the prelude to netconf's creation. > One of our goals was allowing the vendor to reuse their cli > implementation to the greatest extent possible. > > In addition, the use of explicit RPCs gives you explicit arguments, > which you need (or may need in the future) to refine the information > retrieved. Or you may want your API for retrieving data to match the > API for manipulating it, in the same way the parameter for > matches the parameter for , > , , , etc. > > Thanks, > Phil > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 13:47:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHek-0002fK-42 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:47:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHei-0005b6-QU for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:47:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHbm-000BTh-UL for netconf-data@psg.com; Tue, 27 Jun 2006 17:44:18 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHbm-000BTO-FC for netconf@ops.ietf.org; Tue, 27 Jun 2006 17:44:18 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5RHiAX25779; Tue, 27 Jun 2006 10:44:10 -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 k5RHi4522122; Tue, 27 Jun 2006 10:44:04 -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 k5RHi4wn058709; Tue, 27 Jun 2006 13:44:04 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606271744.k5RHi4wn058709@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Tue, 27 Jun 2006 10:24:09 PDT." <44A169B9.60102@andybierman.com> Date: Tue, 27 Jun 2006 13:44:04 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Andy Bierman writes: >Unless standard data shows up in exactly the same place, >with the same syntax and same semantics, using the operation, >then it isn't a standard that meets this requirement. Does pass that test? >Data model discovery becomes quite a nightmare if a manager >has to know priori, each different set of special RPCs to >use for every device it manages, and try them all to discover >the entire device configuration and state. Yes, this is a hard problem. But thinking that all devices will instantly converge on a new standard data model won't fly. The difference between the model and the device can be ignored or painted over for monitoring (ala SNMP MIBs) but when you move into configuration, it's the details that matter. So my proposal is to fly little fish first. If your application wants to get notification data, it has to know a priori that it gets the list of streams via one RPC and gets the notification data via another RPC. Come to think of it, even if you had all this hidden under , your application would still have to know the magic filter to pass in to get the list of streams and the magic filter to pass in to get the notification data. The difference is whether you put this knowledge in the RPC (name and arguments) or the filter's XML content (and the schema that defines it). Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 13:59:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHq3-0001LQ-Bf for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:59:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHq2-0006oy-SL for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:59:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHmD-000CWi-5v for netconf-data@psg.com; Tue, 27 Jun 2006 17:55:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, MSGID_DOLLARS,RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME,SPF_PASS autolearn=no version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHmA-000CVn-MT for netconf@ops.ietf.org; Tue, 27 Jun 2006 17:55:03 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id F17E827C065; Tue, 27 Jun 2006 19:51:09 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10013-07; Tue, 27 Jun 2006 19:51:09 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9A7A927C061; Tue, 27 Jun 2006 19:51:09 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 19:54:50 +0200 Received: from 172.19.0.6 ([172.19.0.6]) by grfint2.intern.adiscon.com ([172.19.0.6]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Jun 2006 17:54:50 +0000 MIME-Version: 1.0 From: "Rainer Gerhards" Subject: AW: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Message-ID: <001101c69a12$c911137b$060013ac@intern.adiscon.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 19:54:32 +0200 Importance: normal X-Priority: 3 X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) To: "Andy Bierman" , "Phil Shafer" Thread-Index: AcaaEskQp2uH4859QX647KD91Sm+Mg== Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 27 Jun 2006 17:54:51.0006 (UTC) FILETIME=[C9A991E0:01C69A12] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 I am on the move, thus brief. I think Sharons comment below applies to netconf-syslog as well: Streams = need to be configured somewhere, so I think they are nv config data. = Thus, querying should be done via get. A data model, of course, is = required, but netconf-syslog should be a good starting point for that. Polling the events (get-syslog-events) IMHO naturally asks for a verb = and seems unnatural via get. Rainer=20 --- Sharon Chisholm, 2006-06-22 on netconf notifications --- I think you are missing the point. Balazs and I are not saying that a verb to start the delivery of notifications is a problem. I totally agree with this approach, rather than the SNMP MIB approach of turning the knob to 'enabled' in the data model. Let's get past this point, okay? The problem is that many of the parameters (especially the most complicated part -- the filters) should be implemented as a read-create standard data model using the existing operation, and retrieval of these parameters and notification state information should be done with the operation. --------- =20 ----- Urspr=C3=BCngliche Nachricht ----- Von: "Andy Bierman" An: "Phil Shafer" Cc: "Sharon Chisholm" ; "netconf@ops.ietf.org" = Gesendet: 27.06.06 19:36 Betreff: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Phil Shafer wrote: What vendors do with their proprietary CLI/XML data models does not have a significant impact on what the IETF or this WG should do wrt/ standard data models. One significant operator requirement that came out of RFC 3535 is that the entire device configuration and state information could be retrieved as a whole tree, or portions of the tree could be retrieved, in a single operation. The concept of an ad-hoc collection of specialized RPCs used INSTEAD of standard data models and standard operations does not meet this requirement. Unless standard data shows up in exactly the same place, with the same syntax and same semantics, using the operation, then it isn't a standard that meets this requirement. Data model discovery becomes quite a nightmare if a manager has to know priori, each different set of special RPCs to use for every device it manages, and try them all to discover the entire device configuration and state. Andy > Andy Bierman writes: >> I think that managing 100s or 1000s of and >> even functions, which ignores the , >> , model variants, ignores , >> and does not show up at all when I do a , >> , or operation -- is a fairly broken design. >=20 > I don't think it's broken at all. I think this is the point of using > an RPC-based design. There are two reasons that I think this is a > win. First, it's a better match for applications. More specific > information in the API makes it a better API, both more readable and > more easily implemented. Your unix program doesn't get filesystem > information using get() or even ioctl(). It uses statfs() to get this > data. It's a direct, easily documented mechanism for getting > this particular content. The same is true for RPCs. I'd rather have: >=20 > $results =3D $dev->get_syslog_streams(); >=20 > than: >=20 > $results =3D $dev->get("netconf/notifcations/config/whatever"); >=20 > (or worse, having to build the xml object) >=20 > It's similar to calling read() verses calling syscall() with the = SYS_read > system call number. >=20 > Second, we're not making a green field solution. Device vendors have > a ton of code supporting existing CLI commands, all brimming with > information accessible via the command line. So I go in and make a > to "command line" mapping, and get all the fancy command > line arguments, types, ranges, help strings, etc for free. All this > is fairly trivial code. >=20 > But to do this scoped generic stuff, I need to understand a _whole_ > lot more about the output of the commands, including not only which > commands make which output tags, but which _options_ to those > commands make the output. "show interfaces extensive" .vs. "show > interfaces statistics". This is an immense pain. >=20 > I'd basically have to build a completely new management system. I've > said it before, but I continue to believe that netconf will fail if it > becomes the "third way" (where first=3Dcli and second=3Dsnmp). In the > real world, the CLI gets implemented first, then SNMP (first > proprietary MIBs, then standard MIBs). A completely disjoint netconf > implementation will a distant third. We need to maximize the leverage > we can get off the existing implementations, not become the third way. >=20 > This was discussed at length in the prelude to netconf's creation. > One of our goals was allowing the vendor to reuse their cli > implementation to the greatest extent possible. >=20 > In addition, the use of explicit RPCs gives you explicit arguments, > which you need (or may need in the future) to refine the information > retrieved. Or you may want your API for retrieving data to match the > API for manipulating it, in the same way the parameter for > matches the parameter for , > , , , etc. >=20 > Thanks, > Phil >=20 >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 13:59:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHq7-0001NN-HT for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:59:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHq6-0006pB-8r for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 13:59:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvHnF-000Cdh-4L for netconf-data@psg.com; Tue, 27 Jun 2006 17:56: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 [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 1FvHnE-000CdV-G0 for netconf@ops.ietf.org; Tue, 27 Jun 2006 17:56:08 +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 k5RHrs1Z002997; Tue, 27 Jun 2006 10:53:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5RHro524452; Tue, 27 Jun 2006 10:53:50 -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 k5RHrown059027; Tue, 27 Jun 2006 13:53:50 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606271753.k5RHrown059027@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Tue, 27 Jun 2006 13:44:04 EDT." <200606271744.k5RHi4wn058709@idle.juniper.net> Date: Tue, 27 Jun 2006 13:53:50 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Phil Shafer writes: >So my proposal is to fly little fish first. Maybe "fry" those little fish, eh? Fry flying fish? Even the spellchecker can't help me...... Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 14:58:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIly-0003NY-UZ for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 14:58:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvIlx-0004II-Jn for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 14:58:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvIgw-000Ink-0n for netconf-data@psg.com; Tue, 27 Jun 2006 18:53:42 +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.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvIgt-000InM-4a for netconf@ops.ietf.org; Tue, 27 Jun 2006 18:53:39 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k5RIrchE021372 for ; Tue, 27 Jun 2006 14:53:38 -0400 Received: (qmail 2135 invoked by uid 78); 27 Jun 2006 18:53:38 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.66 with SMTP; 27 Jun 2006 18:53:38 -0000 Message-ID: <44A17E86.1080507@andybierman.com> Date: Tue, 27 Jun 2006 11:52:54 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <200606271744.k5RHi4wn058709@idle.juniper.net> In-Reply-To: <200606271744.k5RHi4wn058709@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Phil Shafer wrote: > Andy Bierman writes: >> Unless standard data shows up in exactly the same place, >> with the same syntax and same semantics, using the operation, >> then it isn't a standard that meets this requirement. > > Does pass that test? > >> Data model discovery becomes quite a nightmare if a manager >> has to know priori, each different set of special RPCs to >> use for every device it manages, and try them all to discover >> the entire device configuration and state. > > Yes, this is a hard problem. But thinking that all devices will > instantly converge on a new standard data model won't fly. This is where we strongly disagree. If they want to conform to the standard "notification" capability, then they will do everything that is specified, including implementing the tiny standard data model in the spec. I will be even more clear -- the standard data models for netconf will be usable with the existing standard netconf operations. I doubt the co-Chairs and ADs will except a solution that did otherwise. If the data is particularly complicated (e.g., deeply nested data structures with complex keys), then special RPCs in ADDITION to the standard RPCs may be useful, which do not redefine data, but rather simplify access to the nested data instances within the overall target data model. In this case, I don't think the notification data is complicated enough to warrant additional special RPCs, but we haven't finalized the data model at all, so who knows right now. Andy The > difference between the model and the device can be ignored or painted > over for monitoring (ala SNMP MIBs) but when you move into > configuration, it's the details that matter. > > So my proposal is to fly little fish first. If your application > wants to get notification data, it has to know a priori that it > gets the list of streams via one RPC and gets the notification data > via another RPC. Come to think of it, even if you had all this > hidden under , your application would still have to know the > magic filter to pass in to get the list of streams and the magic > filter to pass in to get the notification data. The difference is > whether you put this knowledge in the RPC (name and arguments) or > the filter's XML content (and the schema that defines it). > > Thanks, > Phil > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 16:29:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKBq-0008PD-Ls for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKBp-0006J0-Ca for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 16:29:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvK8w-0004ui-06 for netconf-data@psg.com; Tue, 27 Jun 2006 20:26:42 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvK8t-0004uE-CL for netconf@ops.ietf.org; Tue, 27 Jun 2006 20:26:39 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5RKQPX28586; Tue, 27 Jun 2006 13:26:25 -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 k5RKQI562101; Tue, 27 Jun 2006 13:26:19 -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 k5RKQHwn061814; Tue, 27 Jun 2006 16:26:17 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606272026.k5RKQHwn061814@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Tue, 27 Jun 2006 11:52:54 PDT." <44A17E86.1080507@andybierman.com> Date: Tue, 27 Jun 2006 16:26:17 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Andy Bierman writes: >If they want to conform to the standard "notification" capability, >then they will do everything that is specified, including >implementing the tiny standard data model in the spec. For netconf to be widely accepted we need to minimize the price of implementation, leveraging existing software features and configuration. For example, JUNOS configures its syslog logging under the "system syslog" statement, where a set of files (and remote destinations) are configured. Using the mechanism in the draft, I can expose these files as streams for netconf clients with fairly low implementation costs. If the cost of implementing netconf is moving every config statement to a new hierarchy and reimplement all software to fit this new netconf world, then netconf is going nowhere. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 16:34:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJf5-0006ns-F9 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 15:55:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJf3-00030W-Lw for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 15:55:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvJa8-0001EQ-9o for netconf-data@psg.com; Tue, 27 Jun 2006 19:50:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvJa6-0001Cq-El for netconf@ops.ietf.org; Tue, 27 Jun 2006 19:50:42 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 55BCF27C065; Tue, 27 Jun 2006 21:46:58 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12451-04; Tue, 27 Jun 2006 21:46:58 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 01A8727C061; Tue, 27 Jun 2006 21:46:57 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 21:50:41 +0200 Content-class: urn:content-classes:message Subject: RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 21:50:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174A4D@grfint2.intern.adiscon.com> In-Reply-To: <44A17E86.1080507@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: AcaaHDvRtYFNIVc0SuiuDoaLm3BT+QABXcDg From: "Rainer Gerhards" To: "Andy Bierman" , "Phil Shafer" Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 27 Jun 2006 19:50:41.0150 (UTC) FILETIME=[F84561E0:01C69A22] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Andy,=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, June 27, 2006 8:53 PM > To: Phil Shafer > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >=20 > Phil Shafer wrote: > > Andy Bierman writes: > >> Unless standard data shows up in exactly the same place, > >> with the same syntax and same semantics, using the operation, > >> then it isn't a standard that meets this requirement. > >=20 > > Does pass that test? > >=20 > >> Data model discovery becomes quite a nightmare if a manager > >> has to know priori, each different set of special RPCs to > >> use for every device it manages, and try them all to discover > >> the entire device configuration and state. > >=20 > > Yes, this is a hard problem. But thinking that all devices will > > instantly converge on a new standard data model won't fly.=20 >=20 >=20 > This is where we strongly disagree. > If they want to conform to the standard "notification" capability, > then they will do everything that is specified, including > implementing the tiny standard data model in the spec. Phil wants to transport syslog messages. I do not think there is a specific data model for a syslog messages needed, at least at this time and in the NETCONF WG alone. The entity "syslog message" is well-defined, so you do have a single element inside a syslog event notification. Over time, I agree, it would be useful to have an extended data model that specfies detailled semantics for syslog messages (and probably notifiation messages at all). This, however, I think is far beyond the current discussion. I consider it to be a separate effort, probably even in a separate WG that draws people from the syslog and netconf WGs. Syslog stream configuration, IMHO, could relatively quickly be done because this is something that merely happens in the netconf-syslog draft context. I can also envison that a generic syslog rule configuration data model can quickly be done. One, that takes into account what almost all syslogd implementations supports. It may require two optional capabilities, but you would immediately be able to capture the majority of syslog receivers and relays. I am not so experienced with schema defintion, but I am tempted to write a quick draft on a basic syslog config schema. I defintely know what is required inside the model (acting as a least common denominator approach). >=20 > I will be even more clear -- the standard data models > for netconf will be usable with the existing standard netconf > operations. I doubt the co-Chairs and ADs will except > a solution that did otherwise. >=20 > If the data is particularly complicated (e.g., deeply > nested data structures with complex keys), then special > RPCs in ADDITION to the standard RPCs may be useful, > which do not redefine data, but rather simplify access to > the nested data instances within the overall target data model. >=20 > In this case, I don't think the notification data is complicated > enough to warrant additional special RPCs, but we haven't finalized > the data model at all, so who knows right now. I think this is not just a data model question. Something like is not a datamodel thing, at least I think so. It definitely is not configuration data, so is out of question. I also do not consider it to be state data, so I have some concerns on . What else would be the right verb to transport notification data? Rainer >=20 >=20 > Andy >=20 >=20 >=20 >=20 > The > > difference between the model and the device can be ignored=20 > or painted > > over for monitoring (ala SNMP MIBs) but when you move into > > configuration, it's the details that matter. > >=20 > > So my proposal is to fly little fish first. If your application > > wants to get notification data, it has to know a priori that it > > gets the list of streams via one RPC and gets the notification data > > via another RPC. Come to think of it, even if you had all this > > hidden under , your application would still have to know the > > magic filter to pass in to get the list of streams and the magic > > filter to pass in to get the notification data. The difference is > > whether you put this knowledge in the RPC (name and arguments) or > > the filter's XML content (and the schema that defines it). > >=20 > > Thanks, > > Phil > >=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 -- to unsubscribe send a message to netconf-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 Jun 27 17:14:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKsz-0001D4-26 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 17:14:17 -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 1FvJvz-0005Ox-1u for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 16:13:19 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJmf-0004Rm-3r for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 16:03:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvJk7-0002Jb-Qc for netconf-data@psg.com; Tue, 27 Jun 2006 20:01:03 +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 1FvJk2-0002Iv-Vs for netconf@ops.ietf.org; Tue, 27 Jun 2006 20:00:59 +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 k5RK0sOF007815 for ; Tue, 27 Jun 2006 16:00:55 -0400 Received: (qmail 705 invoked by uid 78); 27 Jun 2006 20:00:54 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 27 Jun 2006 20:00:54 -0000 Message-ID: <44A18E45.9040709@andybierman.com> Date: Tue, 27 Jun 2006 13:00:05 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rainer Gerhards CC: Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <577465F99B41C842AAFBE9ED71E70ABA174A4D@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174A4D@grfint2.intern.adiscon.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: -2.4 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Rainer Gerhards wrote: > Andy, > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >> Sent: Tuesday, June 27, 2006 8:53 PM >> To: Phil Shafer >> Cc: Sharon Chisholm; netconf@ops.ietf.org >> Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >> >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Unless standard data shows up in exactly the same place, >>>> with the same syntax and same semantics, using the operation, >>>> then it isn't a standard that meets this requirement. >>> Does pass that test? >>> >>>> Data model discovery becomes quite a nightmare if a manager >>>> has to know priori, each different set of special RPCs to >>>> use for every device it manages, and try them all to discover >>>> the entire device configuration and state. >>> Yes, this is a hard problem. But thinking that all devices will >>> instantly converge on a new standard data model won't fly. >> >> This is where we strongly disagree. >> If they want to conform to the standard "notification" capability, >> then they will do everything that is specified, including >> implementing the tiny standard data model in the spec. > > Phil wants to transport syslog messages. I do not think there is a > specific data model for a syslog messages needed, at least at this time > and in the NETCONF WG alone. The entity "syslog message" is > well-defined, so you do have a single element inside a syslog event > notification. Over time, I agree, it would be useful to have an extended > data model that specfies detailled semantics for syslog messages (and > probably notifiation messages at all). This, however, I think is far > beyond the current discussion. I consider it to be a separate effort, > probably even in a separate WG that draws people from the syslog and > netconf WGs. I'm not sure there is WG consensus that the only type of notification data that can possibly be delivered in netconf is syslog/RAW. But you misunderstood my comments anyway. The netconf WG is defining standard parameters for the configuration of agent filtering of notification delivery. There is also the possibility of standard monitoring variables for netconf notifications. These are the standard data models that I am referring to, not the content of syslog messages or any other notification content. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 17:14:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKtQ-0002HS-FV for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 17:14:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKtP-0004p4-1y for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 17:14:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvKhs-0008g4-70 for netconf-data@psg.com; Tue, 27 Jun 2006 21:02: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 [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvKhr-0008fo-9I for netconf@ops.ietf.org; Tue, 27 Jun 2006 21:02:47 +0000 Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87]) by mail.tail-f.com (Postfix) with ESMTP id 2B8A11B8011; Tue, 27 Jun 2006 23:02:45 +0200 (CEST) Date: Tue, 27 Jun 2006 23:02:42 +0200 (CEST) Message-Id: <20060627.230242.00004471.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Verbs Again From: Martin Bjorklund In-Reply-To: <200606272026.k5RKQHwn061814@idle.juniper.net> References: <44A17E86.1080507@andybierman.com> <200606272026.k5RKQHwn061814@idle.juniper.net> X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Phil Shafer wrote: > Andy Bierman writes: > >If they want to conform to the standard "notification" capability, > >then they will do everything that is specified, including > >implementing the tiny standard data model in the spec. > > For netconf to be widely accepted we need to minimize the price of > implementation, leveraging existing software features and configuration. Again, suppose an agent actually did make this data configurable through NETCONF. First of all, it would have to do this in a vendor-specific way. Second, it would have to make this data available _both_ as a normal part, _and_ as a new RPC, . An agent that only provides read-only access to this data would provide the data as a new RPC instead of a part. I don't understand why the former would be easier to implement than the latter? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 17:52:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLUI-0002hO-TM for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 17:52:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLUH-0000WU-F5 for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 17:52:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvLOw-000Csn-W6 for netconf-data@psg.com; Tue, 27 Jun 2006 21:47:18 +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 1FvLOw-000Csb-5L for netconf@ops.ietf.org; Tue, 27 Jun 2006 21:47:18 +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 k5RLlGo5020917 for ; Tue, 27 Jun 2006 17:47:17 -0400 Received: (qmail 10310 invoked by uid 78); 27 Jun 2006 21:47:16 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 27 Jun 2006 21:47:16 -0000 Message-ID: <44A1A72C.5080501@andybierman.com> Date: Tue, 27 Jun 2006 14:46:20 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <200606272026.k5RKQHwn061814@idle.juniper.net> In-Reply-To: <200606272026.k5RKQHwn061814@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Phil Shafer wrote: > Andy Bierman writes: >> If they want to conform to the standard "notification" capability, >> then they will do everything that is specified, including >> implementing the tiny standard data model in the spec. > > For netconf to be widely accepted we need to minimize the price of > implementation, leveraging existing software features and configuration. > > For example, JUNOS configures its syslog logging under the "system > syslog" statement, where a set of files (and remote destinations) > are configured. Using the mechanism in the draft, I can expose > these files as streams for netconf clients with fairly low > implementation costs. > > If the cost of implementing netconf is moving every config statement > to a new hierarchy and reimplement all software to fit this new > netconf world, then netconf is going nowhere. This doesn't make a lot of sense. You are okay with standard parameters for syslog delivery when they are passed in a special RPC, but if those standard parameters are moved to a data model, suddenly you can't map your proprietary mechanism to the standard anymore. If you could handle the burden of standard parameters passed in a special RPC, then you can handle the burden if they are passed in a existing RPC. Remember that those existing RPCs represent the minimal conformance level for a netconf agent. An implementation MUST advertise the base capability, which includes all the operations we have been discussing. Any other capabilities MUST be in addition to the base capability. So it is not a burden for a conforming netconf agent or manager to use the base operations, since they are never optional. As for the need for standard data models at all... It doesn't really matter from a standards POV what any particular vendor has implemented for configuration. What matters is that an NMS developer can code to the standard, and it works. We are not chartered to produce standard data models for the entire IETF -- just the NETCONF protocol (just as the SNMP WG developed standard MIBs for the management of the SNMP protocol itself.) The bar has been raised in this WG. We are going to eat our own recipe. We are going to provide fully configurable features for the NETCONF protocol. It may be okay for other WGs to say "leave configuration to the vendors, that is not our focus", but not this WG. Standards based configuration is our focus. (Not syslog delivery, BTW.) > > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jun 27 23:32:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvQn4-0006AW-7P for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 23:32:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvQn1-0001yH-JG for netconf-archive@lists.ietf.org; Tue, 27 Jun 2006 23:32:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvQfj-000Di3-5E for netconf-data@psg.com; Wed, 28 Jun 2006 03:24: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.6 required=5.0 tests=BAYES_00,SPF_PASS, UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [210.138.20.174] (helo=otm-mgo00.iij.ad.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvQfh-000Dhq-AK for netconf@ops.ietf.org; Wed, 28 Jun 2006 03:24:57 +0000 Received: OTM-MO(otm-mgo00) id k5S3Oirl056380; Wed, 28 Jun 2006 12:24:44 +0900 (JST) Received: OTM-MIX(otm-mix01) id k5S3OiwQ057626; Wed, 28 Jun 2006 12:24:44 +0900 (JST) Received: from [192.168.190.169] (h169n190.iij.ad.jp [192.168.190.169]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k5S3OiAd024932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Jun 2006 12:24:44 +0900 (JST) Message-ID: <44A1F691.9050700@iijlab.net> Date: Wed, 28 Jun 2006 12:25:05 +0900 From: "Ray S. Atarashi" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: netconf@ops.ietf.org, netconfmodel@lists.nortel.com Subject: Update to Netmod Architecture Draft Content-Type: multipart/mixed; boundary="------------080909010901050503070905" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 This is a multi-part message in MIME format. --------------080909010901050503070905 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Dear all, We have submitted the updated Netmod Architecture Draft. We revised the draft drastically, added system models to implement the netconf system. And we discussed Event Notification in the draft. http://www.ietf.org/internet-drafts/draft-atarashi-netconfmodel-architecture-03.txt Regards, Ray Atarashi ray@iijlab.net --------------080909010901050503070905 Content-Type: message/rfc822; name*0="I-D ACTION:draft-atarashi-netconfmodel-architecture-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-atarashi-netconfmodel-architecture-03.txt" X-Account-Key: account4 Return-Path: Received: OTM-POFS id k5RL9BKg034341; Wed, 28 Jun 2006 06:09:11 +0900 (JST) Received: OTM-MD(otm-md01) id k5RL9BmV004919; Wed, 28 Jun 2006 06:09:11 +0900 (JST) Received: OTM-MIX(otm-mix00) id k5RL9A8q089912; Wed, 28 Jun 2006 06:09:10 +0900 (JST) Received: from unknown [192.168.176.53] (EHLO otm-mgi00.iij.ad.jp) by otm-mas00.iij.ad.jp (mxl_mta-2.14.0-06) with ESMTP id 67e91a44.851831728.412.otm-mas00.iij.ad.jp (envelope-from ); Wed, 28 Jun 2006 06:09:10 +0900 (JST) X-DNSRBL: OK 202.232.15.98 Authentication-Results: otm-mgi00.iij.ad.jp from=Internet-Drafts@ietf.org; sender-id=neutral; spf=neutral Received: from sh1.iijlab.net (sh1.iijlab.net [202.232.15.98]) by omgi.iij.ad.jp (OTM-MI/otm-mgi00) id k5RL9AvA054245 for ; Wed, 28 Jun 2006 06:09:10 +0900 (JST) Received: by sh1.iijlab.net (Postfix) id EA87DFB948; Wed, 28 Jun 2006 06:09:09 +0900 (JST) Delivered-To: ray@iijlab.net Received: from megatron.ietf.org (stiedprmman1.ietf.org [156.154.16.145]) by sh1.iijlab.net (Postfix) with ESMTP id 8573CFB943; Wed, 28 Jun 2006 06:09:09 +0900 (JST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKm1-0005HA-UN; Tue, 27 Jun 2006 17:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKm0-0005Fi-15 for i-d-announce@ietf.org; Tue, 27 Jun 2006 17:07:04 -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 1FvJwV-0005RX-9i for i-d-announce@ietf.org; Tue, 27 Jun 2006 16:13:51 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJZS-0003U2-Rl for i-d-announce@ietf.org; Tue, 27 Jun 2006 15:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo21u030560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005Hl-Go for i-d-announce@ietf.org; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: I-D ACTION:draft-atarashi-netconfmodel-architecture-03.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Spam: [F=0.0230263158; HS=0.500(200); S=0.010(2006062301); MH=0.700(2006062708); IIJ Custom Bayesian DB=0.500; SC=none] X-MAIL-FROM: X-SOURCE-IP: [192.168.176.53] X-NAS-BWL: No match found for 'Internet-Drafts@ietf.org' (0 addresses, 0 domains) X-NAS-Language: English X-NAS-Bayes: #0: 4.27926E-289; #1: 1 X-NAS-Classification: 0 X-NAS-MessageID: 8104 X-NAS-Validation: {B2A7F76B-68A9-4C99-B8C7-99C80D7EB2A7} --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Netconf System Architecture Author(s) : R. Atarashi, et al. Filename : draft-atarashi-netconfmodel-architecture-03.txt Pages : 30 Date : 2006-6-27 The NETwork CONFiguration (NETCONF) protocol has been designed to configure routers, switches, firewalls and other network devices. This document describes a high level description of the Netconf architecture and how the Netconf framework relates to other network management protocols and architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-atarashi-netconfmodel-architecture-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-atarashi-netconfmodel-architecture-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-atarashi-netconfmodel-architecture-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27131620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-atarashi-netconfmodel-architecture-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-atarashi-netconfmodel-architecture-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27131620.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------080909010901050503070905-- -- to unsubscribe send a message to netconf-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 Jun 28 03:40:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUf2-0007mP-Uj for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 03:40:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvUf1-0006wE-Jr for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 03:40:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvUXw-000B6i-8q for netconf-data@psg.com; Wed, 28 Jun 2006 07:33: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.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvUXv-000B6Q-7T for netconf@ops.ietf.org; Wed, 28 Jun 2006 07:33:11 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 2691327C065; Wed, 28 Jun 2006 09:29:20 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32037-10; Wed, 28 Jun 2006 09:29:20 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D9C9C27C061; Wed, 28 Jun 2006 09:29:19 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 09:33:01 +0200 Content-class: urn:content-classes:message Subject: RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jun 2006 09:33:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174A51@grfint2.intern.adiscon.com> In-Reply-To: <44A18E45.9040709@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: AcaaJGn2jwO3IF5zTh2IROAu75WfLQAXtCOw From: "Rainer Gerhards" To: "Andy Bierman" Cc: "Phil Shafer" , "Sharon Chisholm" , X-OriginalArrivalTime: 28 Jun 2006 07:33:01.0961 (UTC) FILETIME=[1626D790:01C69A85] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Andy, I have to admit that I actually misunderstood you. Both your reply below as well as the message sent somewhat later made this clear. If I now understand you correctly, you remind us that the charter calls for a standardized notification method and related data model - and not something syslog-specific. I see the reasoning for this position. HOWEVER, IMHO that implies the discussion about verbs vs. data model on Phil's draft is the wrong one. What should be discussed firsthand is if the draft itself is supported by the WG or not. Phil's draft is all about transporting syslog over netconf. The argument is that there is a wealth of information in syslog that a netconf manager might want to see (natively). But still, the focus of the draft is transporting syslog. The quesion of verbs vs. data model is a secondary one (and I think there my comments still applys). I would suggest that we first discuss if the overall idea (transporting syslog over netconf in *addition* to a generic event notification transport) is within the scope of this WG. If so, we can then look at the specifics (like verb usage). I am too inexperienced with netconf to offer a qualified opinion on that firsthand question. I can, however, contribute to the details if it is WG consensus to follow that route. Rainer >> Phil wants to transport syslog messages. I do not think there is a > > specific data model for a syslog messages needed, at least=20 > at this time > > and in the NETCONF WG alone. The entity "syslog message" is > > well-defined, so you do have a single element inside a syslog event > > notification. Over time, I agree, it would be useful to=20 > have an extended > > data model that specfies detailled semantics for syslog=20 > messages (and > > probably notifiation messages at all). This, however, I think is far > > beyond the current discussion. I consider it to be a=20 > separate effort, > > probably even in a separate WG that draws people from the syslog and > > netconf WGs. >=20 >=20 > I'm not sure there is WG consensus that the only type > of notification data that can possibly be delivered > in netconf is syslog/RAW. >=20 > But you misunderstood my comments anyway. >=20 > The netconf WG is defining standard parameters for the > configuration of agent filtering of notification delivery. > There is also the possibility of standard monitoring variables > for netconf notifications. >=20 > These are the standard data models that I am referring to, > not the content of syslog messages or any other notification > content. >=20 >=20 > Andy >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 10:10:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvakl-00051y-V2 for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 10:10:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvadM-00034c-BQ for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 10:03:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvaWz-000L0r-4I for netconf-data@psg.com; Wed, 28 Jun 2006 13:56:37 +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 1FvaWx-000L0X-Hj for netconf@ops.ietf.org; Wed, 28 Jun 2006 13:56:36 +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 k5SDuTxM023280 for ; Wed, 28 Jun 2006 09:56:34 -0400 Received: (qmail 25599 invoked by uid 78); 28 Jun 2006 13:56:13 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 28 Jun 2006 13:56:13 -0000 Message-ID: <44A28A77.60509@andybierman.com> Date: Wed, 28 Jun 2006 06:56:07 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rainer Gerhards CC: Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <577465F99B41C842AAFBE9ED71E70ABA174A51@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174A51@grfint2.intern.adiscon.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: 287c806b254c6353fcb09ee0e53bbc5e Rainer Gerhards wrote: > Andy, > You are correct. We have separate issues here, but we also do not all have the same end result in mind, and that is a problem. The WG meeting in Montreal will be devoted to reaching more agreement on the functional requirements. NETCONF is content-neutral protocol, so syslog content is certainly within scope, but so is anything else. If designed correctly (like the and PDUs) the notification content will just be "well formed XML payload" within the notification PDU. The namespace URI for the payload elements will identify the structure of its contents. As for verbs vs. data, there 2 points not open to debate wrt/ any standard mechanisms developed by the NETCONF WG: 1) Any NV-stored parameters will be defined in a standard data model suitable for use with the base protocol operations for manipulating NV-stored config data. 2) Any monitoring data (e.g., netconf protocol statistics and state) will be defined in a standard data model suitable for use with the operation. I have already asked the WG to comment on both the I-Ds as they pertain to the requirements list Juergen has been maintaining. There are (different) parts of both drafts I like and don't like. I don't think this is a "one draft or the other draft" situation across the board. There are many "1 or the other" decisions to make though. Andy > I have to admit that I actually misunderstood you. Both your reply below > as well as the message sent somewhat later made this clear. > > If I now understand you correctly, you remind us that the charter calls > for a standardized notification method and related data model - and not > something syslog-specific. I see the reasoning for this position. > > HOWEVER, IMHO that implies the discussion about verbs vs. data model on > Phil's draft is the wrong one. What should be discussed firsthand is if > the draft itself is supported by the WG or not. Phil's draft is all > about transporting syslog over netconf. The argument is that there is a > wealth of information in syslog that a netconf manager might want to see > (natively). But still, the focus of the draft is transporting syslog. > The quesion of verbs vs. data model is a secondary one (and I think > there my comments still applys). > > I would suggest that we first discuss if the overall idea (transporting > syslog over netconf in *addition* to a generic event notification > transport) is within the scope of this WG. If so, we can then look at > the specifics (like verb usage). I am too inexperienced with netconf to > offer a qualified opinion on that firsthand question. I can, however, > contribute to the details if it is WG consensus to follow that route. > > Rainer > >>> Phil wants to transport syslog messages. I do not think there is a >>> specific data model for a syslog messages needed, at least >> at this time >>> and in the NETCONF WG alone. The entity "syslog message" is >>> well-defined, so you do have a single element inside a syslog event >>> notification. Over time, I agree, it would be useful to >> have an extended >>> data model that specfies detailled semantics for syslog >> messages (and >>> probably notifiation messages at all). This, however, I think is far >>> beyond the current discussion. I consider it to be a >> separate effort, >>> probably even in a separate WG that draws people from the syslog and >>> netconf WGs. >> >> I'm not sure there is WG consensus that the only type >> of notification data that can possibly be delivered >> in netconf is syslog/RAW. >> >> But you misunderstood my comments anyway. >> >> The netconf WG is defining standard parameters for the >> configuration of agent filtering of notification delivery. >> There is also the possibility of standard monitoring variables >> for netconf notifications. >> >> These are the standard data models that I am referring to, >> not the content of syslog messages or any other notification >> content. >> >> >> Andy >> > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 11:13:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbji-0005Qe-Gb for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:13:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvbjg-0001yH-VP for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:13:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvbeb-0001SK-DA for netconf-data@psg.com; Wed, 28 Jun 2006 15:08:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_50_60,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvbea-0001S4-F3 for netconf@ops.ietf.org; Wed, 28 Jun 2006 15:08:32 +0000 Received: from rchemx01.fnc.net.local ([167.254.101.101]) by fncnmp04.fnc.fujitsu.com with ESMTP; 28 Jun 2006 10:08:32 -0500 X-IronPort-AV: i="4.06,189,1149483600"; d="vcf'?scan'208,217"; a="28221022:sNHT32603724" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C69AC4.B7D88281" Subject: What about the OAM in OAM&P Date: Wed, 28 Jun 2006 10:08:31 -0500 Message-ID: <50B73C8966FCF840BABA099651DBE060011AB391@rchemx01.fnc.net.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: What about the OAM in OAM&P Thread-Index: AcaaxLfIEqVr9/0sS0+XtkYQqnGNkw== From: "Hare, Michael" To: "Netconf Mailing List \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 This is a multi-part message in MIME format. ------_=_NextPart_001_01C69AC4.B7D88281 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C69AC4.B7D88281" ------_=_NextPart_002_01C69AC4.B7D88281 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please forgive me if this was covered. Netconf is doing a good job of covereing the 'P' and maybe some of the = 'A' and 'M', but what about the 'O'? Things like: Software Download (not really a , maybe just ?) Operating and Releasing Loopbacks/Test Signals (not really editing the = configuration, new verb-set?) Initializing PM Registers (again, not really editing the configuration) Protection Switching This may be outside the Netconf charter, but it seems the rpc framework = being used for netconf could be re-used to the other parts of network = management. --------------------------------- Michael Hare NMI Engineering GnuPG Key fingerprint =3D 1AD4 726D E359 A31D 05BF ACE5 CA93 7AD5 D8E3 = A876 <>=20 ------_=_NextPart_002_01C69AC4.B7D88281 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What about the OAM in OAM&P

Hi,

Please forgive me if this was = covered.

Netconf is doing a good job of = covereing the 'P' and maybe some of the 'A' and 'M', but what about the = 'O'?

Things like:

Software Download (not really a = <copy-config>, maybe just <copy>?)
Operating and Releasing Loopbacks/Test = Signals (not really editing the configuration, new verb-set?)
Initializing PM Registers (again, not = really editing the configuration)
Protection Switching


This may be outside the Netconf = charter, but it seems the rpc framework being used for netconf could be = re-used to the other parts of network management.


---------------------------------
Michael Hare
NMI Engineering

GnuPG Key fingerprint =3D 1AD4 726D = E359 A31D 05BF  ACE5 CA93 7AD5 D8E3 A876



<<Hare, = Michael.vcf>>

------_=_NextPart_002_01C69AC4.B7D88281-- ------_=_NextPart_001_01C69AC4.B7D88281 Content-Type: text/x-vcard; name="Hare, Michael.vcf" Content-Transfer-Encoding: base64 Content-Description: Hare, Michael.vcf Content-Disposition: attachment; filename="Hare, Michael.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkhhcmU7TWljaGFlbA0KRk46SGFyZSwgTWljaGFl bA0KT1JHOkZVSklUU1UgTkVUV09SSyBDT01NLiBJTkM7NjA1MQ0KVEVMO1dPUks7Vk9JQ0U6KDk3 MikgNDc5LTc3OTQNCkFEUjtXT1JLOjtTb2Z0d2FyZSBEZXZlbG9wbWVudCBNdWx0aS1TZXJ2aWNl czsyODAxIFRlbGVjb20gUGFya3dheTtSaWNoYXJkc29uO1RYOzc1MDgyO1VTDQpMQUJFTDtXT1JL O0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6U29mdHdhcmUgRGV2ZWxvcG1lbnQgTXVsdGktU2Vy dmljZXM9MEQ9MEEyODAxIFRlbGVjb20gUGFya3dheT0wRD0wQVJpY2hhcmRzbz0NCm4sIFRYIDc1 MDgyPTBEPTBBVVMNCkVNQUlMO1BSRUY7SU5URVJORVQ6TWljaGFlbC5IYXJlQGZuYy5mdWppdHN1 LmNvbQ0KUkVWOjIwMDMwOTA1VDIxMTUyMFoNCkVORDpWQ0FSRA0K ------_=_NextPart_001_01C69AC4.B7D88281-- -- to unsubscribe send a message to netconf-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 Jun 28 11:16:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbmF-0007J5-Ks for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:16:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbmD-00027t-87 for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:16:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvbhO-0001jx-K9 for netconf-data@psg.com; Wed, 28 Jun 2006 15:11:26 +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 1FvbhN-0001jb-Si for netconf@ops.ietf.org; Wed, 28 Jun 2006 15:11:25 +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 k5SF9s1Z017934; Wed, 28 Jun 2006 08:09:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5SF9r509358; Wed, 28 Jun 2006 08:09:53 -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 k5SF9qwn064307; Wed, 28 Jun 2006 11:09:52 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606281509.k5SF9qwn064307@idle.juniper.net> To: Martin Bjorklund cc: ietf@andybierman.com, schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Verbs Again In-Reply-To: Your message of "Tue, 27 Jun 2006 23:02:42 +0200." <20060627.230242.00004471.mbj@tail-f.com> Date: Wed, 28 Jun 2006 11:09:52 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Martin Bjorklund writes: >Again, suppose an agent actually did make this data configurable >through NETCONF. First of all, it would have to do this in a >vendor-specific way. Second, it would have to make this data >available _both_ as a normal part, _and_ as a new RPC, >. The config is vendor-specific, by nature, and the translation from this form to a standard data model isn't always straight-forward. Take a look at the config groups and commit scripts features in JUNOS and think about how the mapping from device config to standard config isn't trivial: http://www.juniperfederal.net/techpubs/software/junos/junos61/swconfig61-getting-started/html/cli-config-groups2.html http://www.juniper.fi/techpubs/software/junos/junos76/swconfig76-automation/html/commit-scripts-overview.html These are slick features that reduce the size and complexity of the configuration. The trade-off is that what you see from "show configuration" (or ) isn't the config the system components see (unless you use the "display" pipes). In addition, stuff like "inactive" configuration can cloud the issue further. http://www.juniper.net/techpubs/software/junos/junos57/swconfig57-getting-started/html/cli-configuration-mode43.html While these features are outside the WG's concerns, they are inside mine ;^) In operational mode, the user sees full operational impact of the expanded configuration, so the CLI's "show log" will see all the defined syslog streams, regardless of where they came from. This same information is available via the operation. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 11:45:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcE3-000890-SD for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:45:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcE1-00056o-EN for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:45:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcAe-0004Ql-Uo for netconf-data@psg.com; Wed, 28 Jun 2006 15:41:40 +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 1FvcAe-0004QX-2U for netconf@ops.ietf.org; Wed, 28 Jun 2006 15:41:40 +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 k5SFfavW015669 for ; Wed, 28 Jun 2006 11:41:38 -0400 Received: (qmail 13290 invoked by uid 78); 28 Jun 2006 15:41:10 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 28 Jun 2006 15:41:10 -0000 Message-ID: <44A2A30F.5000606@andybierman.com> Date: Wed, 28 Jun 2006 08:41:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <200606281518.k5SFIHwn064358@idle.juniper.net> In-Reply-To: <200606281518.k5SFIHwn064358@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Phil Shafer wrote: > Andy Bierman writes: >> You are okay with standard parameters for syslog delivery >> when they are passed in a special RPC, but if those standard >> parameters are moved to a data model, suddenly you can't >> map your proprietary mechanism to the standard anymore. > > Sure. I think mapping to an abstract model is reasonably > easy (think SNMP MIBs), but mapping from an abstract model > to device configuration is not easy (think SNMP MIBs). Think how unusable SNMP would be if the MIB objects didn't have OID assignments and therefore every NMS has to hard-code the vendor-assigned OID for every MIB object, for every version of every device for every vendor. Think how unusable SNMP would be if there was no MIB-walk, and instead the NMS had to hard-wire the special PDU to use for every MIB object, for every version of every device for every vendor. That's not exactly how standards are supposed to work. > >> So it is >> not a burden for a conforming netconf agent or manager >> to use the base operations, since they are never optional. > > The point is that and for device-specific > configuration is simple. Doing them for a data model that is not > implemented verbatim on the device is not. I think you imagine > people doing verbatim implementations of whatever data model that > netconf defines. I don't. I see a big network with lots of deployed > boxes and lots of configuration data that isn't doing to move to a > brave new world in my lifetime. I want to make something that's > useful in my lifetime, so mandating this isn't doing it for me. It doesn't matter what proprietary stuff you have on your router. There are zero standard data models for NETCONF. For new NETCONF features, you can expect new standard data models to configure them. We go from zero to one, then two, etc. We get WG consensus on the contents of every standard data model. This is no different than standard MIB modules. IETF WGs have managed for years to define standard MIB objects, even though proprietary MIB objects also exist. With SNMP you can use the same PDUs to access vendor data as standard data. > >> The bar has been raised in this WG. > > The goal is to make something that solves today's problems in > reasonably efficient, reasonably cost-effective ways, that > vendors will implement and operators will use. There are many people (including myself) who believe that standard configuration data models are a critical component to a complete standards based solution for network configuration. This will take time, but standard protocols should be configurable in a standard way. Vendor extensions to standards will always exist, as well as proprietary solutions. > > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 12:02:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcUl-0000wo-EE for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:02:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcUj-00072g-Vi for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:02:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcRE-0005vp-Rs for netconf-data@psg.com; Wed, 28 Jun 2006 15:58: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.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 1FvcQF-0005p7-2R for netconf@ops.ietf.org; Wed, 28 Jun 2006 15:58:48 +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 k5SFv0qW002557 for ; Wed, 28 Jun 2006 11:57:16 -0400 Received: (qmail 17554 invoked by uid 78); 28 Jun 2006 15:56:59 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.69 with SMTP; 28 Jun 2006 15:56:59 -0000 Message-ID: <44A2A6C2.3040208@andybierman.com> Date: Wed, 28 Jun 2006 08:56:50 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Martin Bjorklund , schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Verbs Again References: <200606281509.k5SF9qwn064307@idle.juniper.net> In-Reply-To: <200606281509.k5SF9qwn064307@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Phil Shafer wrote: > Martin Bjorklund writes: >> Again, suppose an agent actually did make this data configurable >> through NETCONF. First of all, it would have to do this in a >> vendor-specific way. Second, it would have to make this data >> available _both_ as a normal part, _and_ as a new RPC, >> . > > The config is vendor-specific, by nature, and the translation from > this form to a standard data model isn't always straight-forward. We spent a long time getting WG consensus, IESG consensus, and IETF consensus on the operations in prot-12. We are going to use them. The SNMP WG managed to define a standard data model to configure which SNMP notifications to send, and where to send them. If we can't do the same for NETCONF, then I don't see the point of this exercise at all. We managed to define a filtering mechanism (+ Xpath) for filtering XML payloads in and operations without too much trouble. Sharon managed to define some filtering mechanisms for notifications that are content-neutral. The NETCONF WG is not the right place to standardize syslog-specific details. We should only be defining netconf-specific notification delivery parameters. > > Take a look at the config groups and commit scripts features in JUNOS > and think about how the mapping from device config to standard config > isn't trivial: > > http://www.juniperfederal.net/techpubs/software/junos/junos61/swconfig61-getting-started/html/cli-config-groups2.html > > http://www.juniper.fi/techpubs/software/junos/junos76/swconfig76-automation/html/commit-scripts-overview.html > > These are slick features that reduce the size and complexity of the > configuration. The trade-off is that what you see from "show > configuration" (or ) isn't the config the system > components see (unless you use the "display" pipes). In addition, > stuff like "inactive" configuration can cloud the issue further. > > http://www.juniper.net/techpubs/software/junos/junos57/swconfig57-getting-started/html/cli-configuration-mode43.html > > While these features are outside the WG's concerns, they are inside > mine ;^) The WG is just trying to standardize what is common and has WG consensus. This process is independent of proprietary efforts that may overlap in some areas. > > In operational mode, the user sees full operational impact of the > expanded configuration, so the CLI's "show log" will see all the > defined syslog streams, regardless of where they came from. This > same information is available via the operation. > > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 12:02:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcUo-0000x5-6r for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:02:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcUm-00072r-H2 for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:02:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcQb-0005rh-OR for netconf-data@psg.com; Wed, 28 Jun 2006 15:58: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.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcQY-0005rC-Tu for netconf@ops.ietf.org; Wed, 28 Jun 2006 15:58:07 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4E28327C065; Wed, 28 Jun 2006 17:54:20 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13655-08; Wed, 28 Jun 2006 17:54:20 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id DEC4D27C061; Wed, 28 Jun 2006 17:54:19 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 17:58:06 +0200 Content-class: urn:content-classes:message Subject: RE: Verbs Again MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jun 2006 17:58:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174A7C@grfint2.intern.adiscon.com> In-Reply-To: <200606281509.k5SF9qwn064307@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again Thread-Index: AcaaxnNpQ6FE1Z3nTyKxesDk1oD5/AAAWrbw From: "Rainer Gerhards" To: "Phil Shafer" , "Martin Bjorklund" Cc: , , X-OriginalArrivalTime: 28 Jun 2006 15:58:06.0799 (UTC) FILETIME=[A53E25F0:01C69ACB] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Phil, I can not fully agree with you here. My understanding is that you can do something like this (probably with a different URN): I understood netconf-prot so that a config must not necessarily be writeable. Of course, that would be best. But looking at your scenario below: what if you create the syslog-streams object by whatever vendor-specific method you have but still provide read-only access to a standardized (but virtual) syslog-streams object? So even the configuration does not natively support syslog-streams, it still allows a manager to deal with your syslog-streams, provided you advertise the capability. If then I modify the stock linux syslogd to support netconf, I could also provide read-only access to a standardized syslog-streams object. Again, it would be virtual, because my stock syslogd config is quite different from what you have in your JUNOS config. The benefit of these virtual read-only syslog-streams config objects would still be that a manager could handle them in a vendor-neutral way. Even though different vendor-specific data models are required to setup that virtual config, it could be useed in a device-independent way. As far as syslog is concerned, I think a useful least common denominator writeable syslog-config object could also be defined. It is my firm belief that it would not be much of a burden to implement this even on very different configuration models (because the base objects are quite obvious and supported by all implementations anyway). I hope I have not overlooked anything obvious. Rainer > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Wednesday, June 28, 2006 5:10 PM > To: Martin Bjorklund > Cc: ietf@andybierman.com; schishol@nortel.com; netconf@ops.ietf.org > Subject: Re: Verbs Again=20 >=20 > Martin Bjorklund writes: > >Again, suppose an agent actually did make this data configurable > >through NETCONF. First of all, it would have to do this in a > >vendor-specific way. Second, it would have to make this data > >available _both_ as a normal part, _and_ as a new RPC, > >. >=20 > The config is vendor-specific, by nature, and the translation from > this form to a standard data model isn't always straight-forward. >=20 > Take a look at the config groups and commit scripts features in JUNOS > and think about how the mapping from device config to standard config > isn't trivial: >=20 > http://www.juniperfederal.net/techpubs/software/junos/junos61/ > swconfig61-getting-started/html/cli-config-groups2.html >=20 > http://www.juniper.fi/techpubs/software/junos/junos76/swconfig > 76-automation/html/commit-scripts-overview.html >=20 > These are slick features that reduce the size and complexity of the > configuration. The trade-off is that what you see from "show > configuration" (or ) isn't the config the system > components see (unless you use the "display" pipes). In addition, > stuff like "inactive" configuration can cloud the issue further. >=20 > http://www.juniper.net/techpubs/software/junos/junos57/swconfi > g57-getting-started/html/cli-configuration-mode43.html >=20 > While these features are outside the WG's concerns, they are inside > mine ;^) >=20 > In operational mode, the user sees full operational impact of the > expanded configuration, so the CLI's "show log" will see all the > defined syslog streams, regardless of where they came from. This > same information is available via the operation. >=20 > Thanks, > Phil >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 12:07:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcZL-0001z0-QF for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:07:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcZK-0007Bt-Gp for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:07:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcVJ-0006SA-08 for netconf-data@psg.com; Wed, 28 Jun 2006 16:03:01 +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 1FvcVI-0006Rv-FW for netconf@ops.ietf.org; Wed, 28 Jun 2006 16:03:00 +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 k5SG0g1Z020474; Wed, 28 Jun 2006 09:00:43 -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 k5SG0g526009; Wed, 28 Jun 2006 09:00:42 -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 k5SG0fwn064717; Wed, 28 Jun 2006 12:00:41 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606281600.k5SG0fwn064717@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Wed, 28 Jun 2006 08:41:03 PDT." <44A2A30F.5000606@andybierman.com> Date: Wed, 28 Jun 2006 12:00:41 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Andy Bierman writes: >This is no different than standard MIB modules. We _have_ to be different than the process that made standard MIBs if we want to be usable for configuration. We can't follow the same path and expect that folks will use ours just because it's in XML. There has to be more. >IETF WGs have managed for years to define standard MIB objects, >even though proprietary MIB objects also exist. If you see this as successful (for configuration), why are we here? >There are many people (including myself) who believe that >standard configuration data models are a critical component >to a complete standards based solution for network configuration. I completely agree that standard configuration data models are critical, but I do not agree that they are trivial. I think this is the next big hurdle for this working group. The question on the floor is whether we should stop other work until we have a real meta-model for configuration and a way of specifying standard data models that will work in the real world. If so, let's stop talking about notifications and get our butts in gear on modeling. Me, I don't want to wait for it. I want to see usable capabilities for doing operational tasks that applications need in order to manage devices. Things like file transfer, call-home, software installation, reboot, and system status. I think we can progress in these areas in parallel. But if the concensus if that we can't, we should stop talking about other topics while we work on modeling. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 12:14:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcgG-00084Q-Hs for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:14:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcgF-0007hy-9B for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:14:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvccv-0007L5-PZ for netconf-data@psg.com; Wed, 28 Jun 2006 16:10:53 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvccv-0007Kr-6h for netconf@ops.ietf.org; Wed, 28 Jun 2006 16:10:53 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5SG9QX49270; Wed, 28 Jun 2006 09:09: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 k5SG9K528335; Wed, 28 Jun 2006 09:09:20 -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 k5SG9Jwn064817; Wed, 28 Jun 2006 12:09:19 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606281609.k5SG9Jwn064817@idle.juniper.net> To: "Rainer Gerhards" cc: "Martin Bjorklund" , ietf@andybierman.com, schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Verbs Again In-Reply-To: Your message of "Wed, 28 Jun 2006 17:58:07 +0200." <577465F99B41C842AAFBE9ED71E70ABA174A7C@grfint2.intern.adiscon.com> Date: Wed, 28 Jun 2006 12:09:19 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 "Rainer Gerhards" writes: >The benefit of these virtual read-only syslog-streams config objects >would still be that a manager could handle them in a vendor-neutral way. The benefits of having this appear as config are lost if it's read-only. At the point, it becomes state data, where I agree, one should be able to reasonably represent device-specific state (whether from defaults or config) in a standard way. This is pretty much what does. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 12:38:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvd3n-0008II-Bl for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:38:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvd3m-0002Fl-0H for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:38:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvd0O-0009Xc-M3 for netconf-data@psg.com; Wed, 28 Jun 2006 16:35:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [85.10.201.79] (helo=hetzner.adiscon.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvd0L-0009X8-UJ for netconf@ops.ietf.org; Wed, 28 Jun 2006 16:35:06 +0000 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 40E9927C065; Wed, 28 Jun 2006 18:31:19 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14425-10; Wed, 28 Jun 2006 18:31:19 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id F15E327C061; Wed, 28 Jun 2006 18:31:18 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 18:35:01 +0200 Content-class: urn:content-classes:message Subject: RE: Verbs Again MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jun 2006 18:35:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174A7F@grfint2.intern.adiscon.com> In-Reply-To: <200606281609.k5SG9Jwn064817@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again Thread-Index: AcaazUEOCkGxhmK3TB2qgRWrcPKxGAAAmL2w From: "Rainer Gerhards" To: "Phil Shafer" Cc: "Martin Bjorklund" , , , X-OriginalArrivalTime: 28 Jun 2006 16:35:01.0814 (UTC) FILETIME=[CD7E9D60:01C69AD0] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Phil, I see one big difference between state data and config data that is read only on a *specific* device. My point is that config data is potentially writable, just not on the device in question. To keep with the syslog sample: I could modify stock syslogd to accept configuration via a hypothetical syslog-streams configuration object (the same that's queried). So in theory it is for read-write access. Some devices might actually grant read-write access, some just read access (because their vendor doesn't care about implementing write access for whatever reason) and some others do not implement it at all. I think this idea is beyond syslog. I agree with Andy that the netconf WG most probably is not the right place to discuss syslog data models. Unfortunately, the syslog-sec WG is also not the right place (being in the security area and chartered to just provide a secure transport). It might make sense to try to form a WG that looks at syslog configuration and content standardization. Rainer > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net]=20 > Sent: Wednesday, June 28, 2006 6:09 PM > To: Rainer Gerhards > Cc: Martin Bjorklund; ietf@andybierman.com;=20 > schishol@nortel.com; netconf@ops.ietf.org > Subject: Re: Verbs Again=20 >=20 > "Rainer Gerhards" writes: > >The benefit of these virtual read-only syslog-streams config objects > >would still be that a manager could handle them in a=20 > vendor-neutral way. >=20 > The benefits of having this appear as config are lost if it's > read-only. At the point, it becomes state data, where I agree, one > should be able to reasonably represent device-specific state (whether > from defaults or config) in a standard way. This is pretty much > what does. >=20 > Thanks, > Phil >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 12:38:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvd43-0008N5-II for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:38:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvd41-0002Gf-4j for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:38:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvd1Z-0009dI-Mn for netconf-data@psg.com; Wed, 28 Jun 2006 16:36:21 +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 1Fvd1J-0009cD-V9 for netconf@ops.ietf.org; Wed, 28 Jun 2006 16:36:21 +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 k5SGZxHF010456 for ; Wed, 28 Jun 2006 12:36:04 -0400 Received: (qmail 21619 invoked by uid 78); 28 Jun 2006 16:35:59 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 28 Jun 2006 16:35:59 -0000 Message-ID: <44A2AFE4.5080103@andybierman.com> Date: Wed, 28 Jun 2006 09:35:48 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Phil Shafer CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <200606281600.k5SG0fwn064717@idle.juniper.net> In-Reply-To: <200606281600.k5SG0fwn064717@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Phil Shafer wrote: > Andy Bierman writes: >> This is no different than standard MIB modules. > > We _have_ to be different than the process that made standard MIBs > if we want to be usable for configuration. We can't follow the > same path and expect that folks will use ours just because it's in > XML. There has to be more. > >> IETF WGs have managed for years to define standard MIB objects, >> even though proprietary MIB objects also exist. > > If you see this as successful (for configuration), why are we here? SNMP has problems as an API for configuration that NETCONF addresses fairly well. However, the basic concept of a WG reaching consensus on the syntax and semantics of individual standard knobs for standard protocols is still valid. > >> There are many people (including myself) who believe that >> standard configuration data models are a critical component >> to a complete standards based solution for network configuration. > > I completely agree that standard configuration data models are > critical, but I do not agree that they are trivial. I think this > is the next big hurdle for this working group. The question on the > floor is whether we should stop other work until we have a real > meta-model for configuration and a way of specifying standard data > models that will work in the real world. If so, let's stop talking > about notifications and get our butts in gear on modeling. > > Me, I don't want to wait for it. I want to see usable capabilities > for doing operational tasks that applications need in order to > manage devices. Things like file transfer, call-home, software > installation, reboot, and system status. I think we can progress > in these areas in parallel. > > But if the concensus if that we can't, we should stop talking about > other topics while we work on modeling. > I know we should be working on data modeling instead of notifications but we aren't. That is still no excuse for not using the standard and operations. I don't think data organization should be that hard, and we don't have to organize the entire world right now. We just have to organize the netconf protocol data. I use the following organization (which can be nested and repeat) E.g.; .... ... (read-only data can be defined in a parameter set, but the monitor set is supposed to be used instead for data sets that are all read-only) Something simple like this should be good enough to get us started. > Thanks, > Phil > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 12:42:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvd7v-0001Fb-RB for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:42:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvd7u-0002MG-G4 for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 12:42:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvd4m-0009vx-1i for netconf-data@psg.com; Wed, 28 Jun 2006 16:39:40 +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 1Fvd4k-0009vh-Gy for netconf@ops.ietf.org; Wed, 28 Jun 2006 16:39:38 +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 k5SGaKJo013398 for ; Wed, 28 Jun 2006 12:36:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Date: Wed, 28 Jun 2006 19:39:36 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: AcaaEXNamn6pdrwtRVK9iytltDcODgAv7W8g From: "Romascanu, Dan \(Dan\)" To: "Phil Shafer" , "Andy Bierman" Cc: "Sharon Chisholm" , X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b =20 =20 > -----Original Message----- >=20 > So my proposal is to fly little fish first. If your=20 > application wants to get notification data, it has to know a=20 > priori that it gets the list of streams via one RPC and gets=20 > the notification data via another RPC. Come to think of it,=20 > even if you had all this hidden under , your application=20 > would still have to know the magic filter to pass in to get=20 > the list of streams and the magic filter to pass in to get=20 > the notification data. The difference is whether you put=20 > this knowledge in the RPC (name and arguments) or the=20 > filter's XML content (and the schema that defines it). >=20 > Thanks, > Phil >=20 (speaking as a contributor) This seems to me contrary to the principle of separation between protocol operations and data models, which - if I read the Charter - is one of the basic design principles in Netconf.=20 'The Netconf protocol should be independent of the data definition language and data models used to describe configuration and state Data.' Dan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 13:13:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvdbn-0005oz-4O for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 13:13:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvdbl-0005Kp-S8 for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 13:13:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvdXR-000CUq-G7 for netconf-data@psg.com; Wed, 28 Jun 2006 17:09:17 +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 1FvdXR-000CUZ-0W for netconf@ops.ietf.org; Wed, 28 Jun 2006 17:09:17 +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 k5SH941Z021429; Wed, 28 Jun 2006 10:09:05 -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 k5SH8x542590; Wed, 28 Jun 2006 10:08:59 -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 k5SH8swn065134; Wed, 28 Jun 2006 13:08:54 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606281708.k5SH8swn065134@idle.juniper.net> To: "Rainer Gerhards" cc: "Martin Bjorklund" , ietf@andybierman.com, schishol@nortel.com, netconf@ops.ietf.org Subject: Re: Verbs Again In-Reply-To: Your message of "Wed, 28 Jun 2006 18:35:04 +0200." <577465F99B41C842AAFBE9ED71E70ABA174A7F@grfint2.intern.adiscon.com> Date: Wed, 28 Jun 2006 13:08:54 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 "Rainer Gerhards" writes: >Some devices might >actually grant read-write access, some just read access (because their >vendor doesn't care about implementing write access for whatever reason) >and some others do not implement it at all. If the goal is read-only access to config data, then the problem's not hard. But I think we're aiming for more. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 13:18:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvdgb-0000MN-9l for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 13:18:45 -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 1FvcAC-0004na-4J for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:41:12 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvbvC-0001Er-UX for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 11:25:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvbqg-0002cJ-1o for netconf-data@psg.com; Wed, 28 Jun 2006 15:21:02 +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.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvbqf-0002c5-I9 for netconf@ops.ietf.org; Wed, 28 Jun 2006 15:21:01 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5SFINX46045; Wed, 28 Jun 2006 08:18:23 -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 k5SFII512131; Wed, 28 Jun 2006 08:18:18 -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 k5SFIHwn064358; Wed, 28 Jun 2006 11:18:17 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606281518.k5SFIHwn064358@idle.juniper.net> To: Andy Bierman cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) In-Reply-To: Your message of "Tue, 27 Jun 2006 14:46:20 PDT." <44A1A72C.5080501@andybierman.com> Date: Wed, 28 Jun 2006 11:18:17 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Andy Bierman writes: >You are okay with standard parameters for syslog delivery >when they are passed in a special RPC, but if those standard >parameters are moved to a data model, suddenly you can't >map your proprietary mechanism to the standard anymore. Sure. I think mapping to an abstract model is reasonably easy (think SNMP MIBs), but mapping from an abstract model to device configuration is not easy (think SNMP MIBs). >So it is >not a burden for a conforming netconf agent or manager >to use the base operations, since they are never optional. The point is that and for device-specific configuration is simple. Doing them for a data model that is not implemented verbatim on the device is not. I think you imagine people doing verbatim implementations of whatever data model that netconf defines. I don't. I see a big network with lots of deployed boxes and lots of configuration data that isn't doing to move to a brave new world in my lifetime. I want to make something that's useful in my lifetime, so mandating this isn't doing it for me. >The bar has been raised in this WG. The goal is to make something that solves today's problems in reasonably efficient, reasonably cost-effective ways, that vendors will implement and operators will use. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 14:05:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvePh-0002hh-SF for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 14:05:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvePf-0002Wp-C2 for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 14:05:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FveKY-000GIs-Em for netconf-data@psg.com; Wed, 28 Jun 2006 18:00:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FveKX-000GI5-Jy for netconf@ops.ietf.org; Wed, 28 Jun 2006 18:00:01 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2006 11:00:02 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="431500221:sNHT40304172" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5SI00GY021965; Wed, 28 Jun 2006 11:00:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5SI009s025653; Wed, 28 Jun 2006 11:00:00 -0700 (PDT) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 11:00:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Date: Wed, 28 Jun 2006 10:59:59 -0700 Message-ID: <6E21698722408147BEA594E073E2B0AB021541E5@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) Thread-Index: Acaa0Q3bN+eypuJgTli7Tc3jDD0PtgACZgkw From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" , "Phil Shafer" Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 28 Jun 2006 18:00:00.0396 (UTC) FILETIME=[AC7C7CC0:01C69ADC] DKIM-Signature: a=rsa-sha1; q=dns; l=4269; t=1151517600; x=1152381600; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20 |Subject:RE=3A=20Verbs=20Again=20(was=20RE=3A=20draft-shafer-netconf-syslog-00.tx t); X=v=3Dcisco.com=3B=20h=3Dy4yI4Szl7FXIIPvlf7ZkSiFgpTU=3D; b=LVvdj7jkotdNaB97b1yaNecQ/pUl2FeqzqELfXua5qZCsAqguaIJxQ2a1iOj6j7tCoE+Anc0 or9OVz6m6+eXzYmQ+cbwLQAMn5yfeZR2U7IcHL6d5O18x/nrw7JmBMk9; Authentication-Results: sj-dkim-3.cisco.com; header.From=htrevino@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Andy, I'm finally catching up on e-mail. Looking at the discussions and the agenda for Montreal I was wondering if the data modeling discussion towards the end of the agenda is only wrt notifications or a more general discussion? "- Data Model and XSD Issues - Data model design - XSD correctness - Need for 'min-access' and 'max-access" thanks Hector =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, June 28, 2006 10:36 AM > To: Phil Shafer > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) >=20 > Phil Shafer wrote: > > Andy Bierman writes: > >> This is no different than standard MIB modules. > >=20 > > We _have_ to be different than the process that made=20 > standard MIBs if=20 > > we want to be usable for configuration. We can't follow=20 > the same path=20 > > and expect that folks will use ours just because it's in=20 > XML. There=20 > > has to be more. > >=20 > >> IETF WGs have managed for years to define standard MIB=20 > objects, even=20 > >> though proprietary MIB objects also exist. > >=20 > > If you see this as successful (for configuration), why are we here? >=20 >=20 > SNMP has problems as an API for configuration that NETCONF=20 > addresses fairly well. However, the basic concept of a WG=20 > reaching consensus on the syntax and semantics of individual=20 > standard knobs for standard protocols is still valid. >=20 >=20 > >=20 > >> There are many people (including myself) who believe that standard=20 > >> configuration data models are a critical component to a complete=20 > >> standards based solution for network configuration. > >=20 > > I completely agree that standard configuration data models are=20 > > critical, but I do not agree that they are trivial. I=20 > think this is=20 > > the next big hurdle for this working group. The question=20 > on the floor=20 > > is whether we should stop other work until we have a real=20 > meta-model=20 > > for configuration and a way of specifying standard data models that=20 > > will work in the real world. If so, let's stop talking about=20 > > notifications and get our butts in gear on modeling. > >=20 > > Me, I don't want to wait for it. I want to see usable capabilities=20 > > for doing operational tasks that applications need in order=20 > to manage=20 > > devices. Things like file transfer, call-home, software=20 > installation,=20 > > reboot, and system status. I think we can progress in=20 > these areas in=20 > > parallel. > >=20 > > But if the concensus if that we can't, we should stop talking about=20 > > other topics while we work on modeling. > >=20 >=20 > I know we should be working on data modeling instead of=20 > notifications but we aren't. That is still no excuse for not=20 > using the standard and operations. >=20 > I don't think data organization should be that hard, and we=20 > don't have to organize the entire world right now. > We just have to organize the netconf protocol data. >=20 > I use the following organization (which can be nested and repeat) >=20 > > > > > > > > >=20 >=20 > E.g.; >=20 > > > .... > > > ... > > >=20 > (read-only data can be defined in a parameter set, but the=20 > monitor set is supposed to be used instead for data sets that=20 > are all read-only) >=20 > Something simple like this should be good enough to get us started. >=20 >=20 > > Thanks, > > Phil > >=20 > >=20 >=20 > Andy >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jun 28 14:10:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveUt-0001bf-5W for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 14:10:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FveUr-0003E0-ST for netconf-archive@lists.ietf.org; Wed, 28 Jun 2006 14:10:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FveRs-000Gyi-HW for netconf-data@psg.com; Wed, 28 Jun 2006 18:07: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 1FveRr-000GyT-P7 for netconf@ops.ietf.org; Wed, 28 Jun 2006 18:07:36 +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 k5SI7YAT012960 for ; Wed, 28 Jun 2006 14:07:34 -0400 Received: (qmail 18623 invoked by uid 78); 28 Jun 2006 18:07:34 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 28 Jun 2006 18:07:34 -0000 Message-ID: <44A2C55F.3000907@andybierman.com> Date: Wed, 28 Jun 2006 11:07:27 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Hector Trevino (htrevino)" CC: Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt) References: <6E21698722408147BEA594E073E2B0AB021541E5@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB021541E5@xmb-sjc-223.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hector Trevino (htrevino) wrote: > Andy, > > I'm finally catching up on e-mail. Looking at the discussions and the > agenda for Montreal I was wondering if the data modeling discussion > towards the end of the agenda is only wrt notifications or a more > general discussion? > > > "- Data Model and XSD Issues > > - Data model design > - XSD correctness > - Need for 'min-access' and 'max-access" This just applies to notifications. The 3rd bullet is probably a general topic. > > thanks > Hector 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 Jun 30 20:13:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwT6i-0007VW-Mw for netconf-archive@lists.ietf.org; Fri, 30 Jun 2006 20:13:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwT6h-0004nL-Co for netconf-archive@lists.ietf.org; Fri, 30 Jun 2006 20:13:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwSzt-0007Q8-DT for netconf-data@psg.com; Sat, 01 Jul 2006 00:06: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.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwSzs-0007Pw-E6 for netconf@ops.ietf.org; Sat, 01 Jul 2006 00:06:05 +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 k61063sG026086 for ; Fri, 30 Jun 2006 20:06:03 -0400 Received: (qmail 27356 invoked by uid 78); 1 Jul 2006 00:06:03 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.65 with SMTP; 1 Jul 2006 00:06:03 -0000 Message-ID: <44A5BBEA.40306@andybierman.com> Date: Fri, 30 Jun 2006 17:03:54 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: our first CLR 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: 9182cfff02fae4f1b6e9349e01d62f32 Hi, Didn't anybody notice that the protocol spec makes a big deal about a mandatory message-id (and I made a big deal about limiting its length), but it isn't used anywhere in the document in a normative manner? Nope. We took out the only operation that depended on the message-id attribute a couple years ago. The agent totally ignores this attribute except to check if needs to generate an error if it is missing. If that isn't the essence of a Crappy Little Rule, I don't know what is. (I know, we may need the message-id someday, but not now.) 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: