From owner-netconf@ops.ietf.org Tue Mar 1 09:05:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27098 for ; Tue, 1 Mar 2005 09:05:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D67r7-000L8e-C3 for netconf-data@psg.com; Tue, 01 Mar 2005 13:56:09 +0000 Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D67r6-000L8O-BP for netconf@ops.ietf.org; Tue, 01 Mar 2005 13:56:08 +0000 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DB4A99C84 for ; Tue, 1 Mar 2005 14:57:19 +0100 (CET) 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: bidirectionality Date: Tue, 1 Mar 2005 14:56:06 +0100 Message-ID: Thread-Topic: bidirectionality Thread-Index: AcUd5Ib6UAaumjMEQNqx0yDppCROKQAgPKMQ From: "Cristian Cadar" To: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 Hi I would have a question. Is there any possibility for the server to initiate a netconf session with the client over SSH or this is manageable only when the BEEP protocol is implemented? Thanks in advance Cristian -- to unsubscribe send a message to netconf-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 Mar 1 10:39:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07441 for ; Tue, 1 Mar 2005 10:39:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D69MT-000BhQ-6f for netconf-data@psg.com; Tue, 01 Mar 2005 15:32:37 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D69MS-000Bfk-4B for netconf@ops.ietf.org; Tue, 01 Mar 2005 15:32:36 +0000 Received: from [24.61.30.237] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 297320; Tue, 01 Mar 2005 10:30:37 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 1 Mar 2005 10:32:14 -0500 To: "Cristian Cadar" , From: Margaret Wasserman Subject: Re: bidirectionality Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk As specified, NETCONF over SSH does not provide bidirectionality. The SSH client is always the NETCONF manager. Margaret At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: > >Hi > >I would have a question. Is there any possibility for the server to >initiate a netconf session >with the client over SSH or this is manageable only when the BEEP >protocol is implemented? > >Thanks in advance >Cristian > > > >-- >to 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 Mar 1 11:15:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10708 for ; Tue, 1 Mar 2005 11:15:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D69vk-000KJg-78 for netconf-data@psg.com; Tue, 01 Mar 2005 16:09:04 +0000 Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D69vh-000KIq-AD for netconf@ops.ietf.org; Tue, 01 Mar 2005 16:09:01 +0000 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D3AEA9C84; Tue, 1 Mar 2005 17:10:14 +0100 (CET) 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: bidirectionality Date: Tue, 1 Mar 2005 17:09:00 +0100 Message-ID: Thread-Topic: bidirectionality Thread-Index: AcUedNaieYsD9f6dR86iKStxB7hg6QAAvhXQ From: "Cristian Cadar" To: "Margaret Wasserman" , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Margaret, Thanks for the reply, I'm asking this because in my scenario what I have to implement, the server=20 has to notify the client in order to "refresh" some specific information through a netconf session. Does it make sense to extend the netconf protocol to allow this? I mean implementing the BEEP protocol=20 just for having bidirectionality it seems for me a little bit burdensome and inconvenient. Thanks=20 Cristian -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Margaret Wasserman Sent: Tuesday, March 01, 2005 4:32 PM To: Cristian Cadar; netconf@ops.ietf.org Subject: Re: bidirectionality As specified, NETCONF over SSH does not provide bidirectionality.=20 The SSH client is always the NETCONF manager. Margaret At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: > >Hi > >I would have a question. Is there any possibility for the server to=20 >initiate a netconf session with the client over SSH or this is=20 >manageable only when the BEEP protocol is implemented? > >Thanks in advance >Cristian > > > >-- >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 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 Mar 1 12:42:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21036 for ; Tue, 1 Mar 2005 12:42:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6BF6-000Fx1-1W for netconf-data@psg.com; Tue, 01 Mar 2005 17:33:08 +0000 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6B6Z-000Duz-Gi for netconf@ops.ietf.org; Tue, 01 Mar 2005 17:24:19 +0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j21HOFj15897 for ; Tue, 1 Mar 2005 12:24:15 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLT6ZJ>; Tue, 1 Mar 2005 12:24:15 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402B07026@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf@ops.ietf.org Subject: RE: bidirectionality Date: Tue, 1 Mar 2005 12:24:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk hi This is similar to the asynchronous messaging issue which many people have been discussing in the hallways. I've been looking into this offline. There is nothing in the specifications that I can tell that precludes this, it would just be a matter of defining it. The model that seems the most straightforward is for the manager to initiate the session, but to send a command that triggers these refresh messages to come from the network element. If there is interest in how to do this, we could create a draft or do a presentation. I believe it is important to get Netconf 1.0 out the door first and then build on top of this though. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Cristian Cadar Sent: Tuesday, March 01, 2005 11:09 AM To: Margaret Wasserman; netconf@ops.ietf.org Subject: RE: bidirectionality Hi Margaret, Thanks for the reply, I'm asking this because in my scenario what I have to implement, the server has to notify the client in order to "refresh" some specific information through a netconf session. Does it make sense to extend the netconf protocol to allow this? I mean implementing the BEEP protocol just for having bidirectionality it seems for me a little bit burdensome and inconvenient. Thanks Cristian -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Margaret Wasserman Sent: Tuesday, March 01, 2005 4:32 PM To: Cristian Cadar; netconf@ops.ietf.org Subject: Re: bidirectionality As specified, NETCONF over SSH does not provide bidirectionality. The SSH client is always the NETCONF manager. Margaret At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: > >Hi > >I would have a question. Is there any possibility for the server to >initiate a netconf session with the client over SSH or this is >manageable only when the BEEP protocol is implemented? > >Thanks in advance >Cristian > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 1 17:06:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15749 for ; Tue, 1 Mar 2005 17:06:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6FMl-000K2G-P8 for netconf-data@psg.com; Tue, 01 Mar 2005 21:57:19 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6FMh-000K1d-Q3 for netconf@ops.ietf.org; Tue, 01 Mar 2005 21:57:15 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 01 Mar 2005 13:57:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,127,1107763200"; d="scan'208"; a="241857233:sNHT29380820" Received: from gluon.jnpr.net ([172.24.15.23]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 13:57:15 -0800 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: bidirectionality Date: Tue, 1 Mar 2005 13:57:14 -0800 Message-ID: Thread-Topic: bidirectionality Thread-Index: AcUehQfDT+Ir4zYZQsy0cdFbOCLC1QAJI/fA From: "Faye Ly" To: "Sharon Chisholm" , X-OriginalArrivalTime: 01 Mar 2005 21:57:15.0184 (UTC) FILETIME=[A125C300:01C51EA9] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Sharon, Yes, there is interest for this. -faye -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm Sent: Tuesday, March 01, 2005 9:24 AM To: netconf@ops.ietf.org Subject: RE: bidirectionality hi This is similar to the asynchronous messaging issue which many people have been discussing in the hallways. I've been looking into this offline. There is nothing in the specifications that I can tell that precludes this, it would just be a matter of defining it.=20 The model that seems the most straightforward is for the manager to initiate the session, but to send a command that triggers these refresh messages to come from the network element. If there is interest in how to do this, we could create a draft or do a presentation. I believe it is important to get Netconf 1.0 out the door first and then build on top of this though. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Cristian Cadar Sent: Tuesday, March 01, 2005 11:09 AM To: Margaret Wasserman; netconf@ops.ietf.org Subject: RE: bidirectionality Hi Margaret, Thanks for the reply, I'm asking this because in my scenario what I have to implement, the server=20 has to notify the client in order to "refresh" some specific information through a netconf session. Does it make sense to extend the netconf protocol to allow this? I mean implementing the BEEP protocol=20 just for having bidirectionality it seems for me a little bit burdensome and inconvenient. Thanks=20 Cristian -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Margaret Wasserman Sent: Tuesday, March 01, 2005 4:32 PM To: Cristian Cadar; netconf@ops.ietf.org Subject: Re: bidirectionality As specified, NETCONF over SSH does not provide bidirectionality.=20 The SSH client is always the NETCONF manager. Margaret At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: > >Hi > >I would have a question. Is there any possibility for the server to >initiate a netconf session with the client over SSH or this is=20 >manageable only when the BEEP protocol is implemented? > >Thanks in advance >Cristian > > > >-- >to 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 Tue Mar 1 20:16:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00464 for ; Tue, 1 Mar 2005 20:16:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6IND-0002x2-HE for netconf-data@psg.com; Wed, 02 Mar 2005 01:09:59 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D6INB-0002wc-GP for netconf@ops.ietf.org; Wed, 02 Mar 2005 01:09:57 +0000 Received: (qmail 20772 invoked by uid 78); 2 Mar 2005 01:09:31 -0000 Received: from unknown (HELO DELL700M.andybierman.com) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 2 Mar 2005 01:09:31 -0000 Message-Id: <6.2.1.2.0.20050302010821.02166b30@mail.andybierman.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 02 Mar 2005 01:09:29 -0800 To: agenda@ietf.org From: Andy Bierman Subject: agenda for NETCONF meeting at IETF #62 Cc: netconf@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_12490910==_" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_06_12 autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --=====================_12490910==_ Content-Type: text/plain; charset="us-ascii" --=====================_12490910==_ Content-Type: text/plain; charset="us-ascii" Network Configuration WG (netconf) IETF #62 March 8, 2005 : 0900 - 1130 =============================== Chairs: Simon Leinen Andy Bierman Agenda: - Discussion of WG Documents - NETCONF Configuration Protocol - Using the NETCONF Protocol over BEEP - Using the NETCONF Protocol over SOAP - Using the NETCONF Protocol over SSH These documents are all in WG Last Call. All significant issues have been addressed, although some minor issues still exist and some minor corrections have been identified. The group will hopefully finalize all remaining details and submit the followup drafts to the IESG. - Status of NETCONF Data Modeling Efforts - Possible ad-hoc discussion on NETCONF data modeling may occur if there is time remaining Internet Drafts: NETCONF Configuration Protocol http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-03.txt Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-04.txt Using the NETCONF Configuration Protocol over Secure Shell (SSH) http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-03.txt --=====================_12490910==_-- -- to unsubscribe send a message to netconf-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 Mar 2 04:23:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16533 for ; Wed, 2 Mar 2005 04:23:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6PtM-000AUa-Fd for netconf-data@psg.com; Wed, 02 Mar 2005 09:11:40 +0000 Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6PtK-000AUM-Aj for netconf@ops.ietf.org; Wed, 02 Mar 2005 09:11:38 +0000 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 341F0FF1A; Wed, 2 Mar 2005 10:12:58 +0100 (CET) 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: bidirectionality Date: Wed, 2 Mar 2005 10:11:32 +0100 Message-ID: Thread-Topic: bidirectionality Thread-Index: AcUehQfDT+Ir4zYZQsy0cdFbOCLC1QAJI/fAABdW1NA= From: "Cristian Cadar" To: "Faye Ly" , "Sharon Chisholm" , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Great, is it possible to have a presentation on this issue next week at IETF? or would it be better after the IETF to come up with a draft? Thanks Cristian -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Faye Ly Sent: Tuesday, March 01, 2005 10:57 PM To: Sharon Chisholm; netconf@ops.ietf.org Subject: RE: bidirectionality Sharon, Yes, there is interest for this. -faye -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm Sent: Tuesday, March 01, 2005 9:24 AM To: netconf@ops.ietf.org Subject: RE: bidirectionality hi This is similar to the asynchronous messaging issue which many people have been discussing in the hallways. I've been looking into this offline. There is nothing in the specifications that I can tell that precludes this, it would just be a matter of defining it.=20 The model that seems the most straightforward is for the manager to initiate the session, but to send a command that triggers these refresh messages to come from the network element. If there is interest in how to do this, we could create a draft or do a presentation. I believe it is important to get Netconf 1.0 out the door first and then build on top of this though. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Cristian Cadar Sent: Tuesday, March 01, 2005 11:09 AM To: Margaret Wasserman; netconf@ops.ietf.org Subject: RE: bidirectionality Hi Margaret, Thanks for the reply, I'm asking this because in my scenario what I have to implement, the server has to notify the client in order to "refresh" some specific information through a netconf session. Does it make sense to extend the netconf protocol to allow this? I mean implementing the BEEP protocol just for having bidirectionality it seems for me a little bit burdensome and inconvenient. Thanks Cristian -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Margaret Wasserman Sent: Tuesday, March 01, 2005 4:32 PM To: Cristian Cadar; netconf@ops.ietf.org Subject: Re: bidirectionality As specified, NETCONF over SSH does not provide bidirectionality.=20 The SSH client is always the NETCONF manager. Margaret At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: > >Hi > >I would have a question. Is there any possibility for the server to=20 >initiate a netconf session with the client over SSH or this is=20 >manageable only when the BEEP protocol is implemented? > >Thanks in advance >Cristian > > > >-- >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 word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 2 10:24:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21614 for ; Wed, 2 Mar 2005 10:24:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6VWr-0001Kg-EP for netconf-data@psg.com; Wed, 02 Mar 2005 15:12:49 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D6VWq-0001KT-HC for netconf@ops.ietf.org; Wed, 02 Mar 2005 15:12:48 +0000 Received: (qmail 11620 invoked by uid 78); 2 Mar 2005 15:07:53 -0000 Received: from unknown (HELO DELL700M.andybierman.com) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 2 Mar 2005 15:07:53 -0000 Message-Id: <6.2.1.2.0.20050303070019.02187df8@mail.andybierman.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 03 Mar 2005 07:07:25 -0800 To: "Cristian Cadar" , "Faye Ly" , "Sharon Chisholm" , From: Andy Bierman Subject: RE: bidirectionality In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_12_24 autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 01:11 AM 3/2/2005, Cristian Cadar wrote: >Hi, > >Great, is it possible to have a presentation on this issue next week at >IETF? or would it be better after the IETF to come up with a draft? We had notifications in the protocol and took them out because there wasn't agreement on the value vs. complexity, and there was concern about a protocol that worked very differently over different application transports. Actually, we agreed to defer the notification work. It can be addressed after the NETCONF v1.0 RFCs are out. IMO, the same issues will come up again, with similar results, unless somebody has a new approach. >Thanks >Cristian Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Faye Ly >Sent: Tuesday, March 01, 2005 10:57 PM >To: Sharon Chisholm; netconf@ops.ietf.org >Subject: RE: bidirectionality > >Sharon, > >Yes, there is interest for this. > >-faye > > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Sharon Chisholm >Sent: Tuesday, March 01, 2005 9:24 AM >To: netconf@ops.ietf.org >Subject: RE: bidirectionality > >hi > >This is similar to the asynchronous messaging issue which many people >have been discussing in the hallways. I've been looking into this >offline. >There >is nothing in the specifications that I can tell that precludes this, it >would just be a matter of defining it. > >The model that seems the most straightforward is for the manager to >initiate the session, but to send a command that triggers these refresh >messages to come from the network element. If there is interest in how >to do this, we could create a draft or do a presentation. I believe it >is important to get Netconf 1.0 out the door first and then build on top >of this though. > >Sharon > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Cristian Cadar >Sent: Tuesday, March 01, 2005 11:09 AM >To: Margaret Wasserman; netconf@ops.ietf.org >Subject: RE: bidirectionality > > >Hi Margaret, > >Thanks for the reply, I'm asking this because in my scenario what I have >to implement, the server has to notify the client in order to "refresh" >some specific information through a netconf session. Does it make sense >to extend the netconf protocol to allow this? I mean implementing the >BEEP protocol just for having bidirectionality it seems for me a little >bit burdensome and inconvenient. > >Thanks >Cristian > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Margaret Wasserman >Sent: Tuesday, March 01, 2005 4:32 PM >To: Cristian Cadar; netconf@ops.ietf.org >Subject: Re: bidirectionality > > >As specified, NETCONF over SSH does not provide bidirectionality. >The SSH client is always the NETCONF manager. > >Margaret > >At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: >> >>Hi >> >>I would have a question. Is there any possibility for the server to >>initiate a netconf session with the client over SSH or this is >>manageable only when the BEEP protocol is implemented? >> >>Thanks in advance >>Cristian >> >> >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with the >>word 'unsubscribe' in a single line as the message text body. >>archive: > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 2 16:10:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27062 for ; Wed, 2 Mar 2005 16:10:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6ay9-000DOz-Ts for netconf-data@psg.com; Wed, 02 Mar 2005 21:01:21 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6VsU-0005dr-N8 for netconf@ops.ietf.org; Wed, 02 Mar 2005 15:35:10 +0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j22FZ8d04308 for ; Wed, 2 Mar 2005 10:35:09 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJL4PNM>; Wed, 2 Mar 2005 10:35:08 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402B07754@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf@ops.ietf.org Subject: RE: bidirectionality Date: Wed, 2 Mar 2005 10:35:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk hi Deferring to get Netconf 1.0 out the door was the correct decision. I think now that we are all more familiar with all this we do actually have a much much better idea how Notifications and other asynchronous messages should be done. Since we seem to want to focus on getting 1.0 out the door for this meeting, then I would propose that we discuss this in the hallways and aim for an internet draft after this meeting for discussion in Paris. Could we have this discussion on this mailing list or should I set up a list of private interested parties to not distract from Netconf 1.0? Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Thursday, March 03, 2005 10:07 AM To: Cristian Cadar; Faye Ly; Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org Subject: RE: bidirectionality At 01:11 AM 3/2/2005, Cristian Cadar wrote: >Hi, > >Great, is it possible to have a presentation on this issue next week at >IETF? or would it be better after the IETF to come up with a draft? We had notifications in the protocol and took them out because there wasn't agreement on the value vs. complexity, and there was concern about a protocol that worked very differently over different application transports. Actually, we agreed to defer the notification work. It can be addressed after the NETCONF v1.0 RFCs are out. IMO, the same issues will come up again, with similar results, unless somebody has a new approach. >Thanks >Cristian Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Faye Ly >Sent: Tuesday, March 01, 2005 10:57 PM >To: Sharon Chisholm; netconf@ops.ietf.org >Subject: RE: bidirectionality > >Sharon, > >Yes, there is interest for this. > >-faye > > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Sharon Chisholm >Sent: Tuesday, March 01, 2005 9:24 AM >To: netconf@ops.ietf.org >Subject: RE: bidirectionality > >hi > >This is similar to the asynchronous messaging issue which many people >have been discussing in the hallways. I've been looking into this >offline. There >is nothing in the specifications that I can tell that precludes this, it >would just be a matter of defining it. > >The model that seems the most straightforward is for the manager to >initiate the session, but to send a command that triggers these refresh >messages to come from the network element. If there is interest in how >to do this, we could create a draft or do a presentation. I believe it >is important to get Netconf 1.0 out the door first and then build on >top of this though. > >Sharon > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Cristian Cadar >Sent: Tuesday, March 01, 2005 11:09 AM >To: Margaret Wasserman; netconf@ops.ietf.org >Subject: RE: bidirectionality > > >Hi Margaret, > >Thanks for the reply, I'm asking this because in my scenario what I >have to implement, the server has to notify the client in order to >"refresh" some specific information through a netconf session. Does it >make sense to extend the netconf protocol to allow this? I mean >implementing the BEEP protocol just for having bidirectionality it >seems for me a little bit burdensome and inconvenient. > >Thanks >Cristian > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Margaret Wasserman >Sent: Tuesday, March 01, 2005 4:32 PM >To: Cristian Cadar; netconf@ops.ietf.org >Subject: Re: bidirectionality > > >As specified, NETCONF over SSH does not provide bidirectionality. >The SSH client is always the NETCONF manager. > >Margaret > >At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: >> >>Hi >> >>I would have a question. Is there any possibility for the server to >>initiate a netconf session with the client over SSH or this is >>manageable only when the BEEP protocol is implemented? >> >>Thanks in advance >>Cristian >> >> >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with the >>word 'unsubscribe' in a single line as the message text body. >>archive: > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 2 16:10:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27080 for ; Wed, 2 Mar 2005 16:10:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6ayI-000DQL-Az for netconf-data@psg.com; Wed, 02 Mar 2005 21:01:30 +0000 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6Zbb-000OT1-LM for netconf@ops.ietf.org; Wed, 02 Mar 2005 19:34:00 +0000 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j22JXt722327 for ; Wed, 2 Mar 2005 14:33:56 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJL4XBK>; Wed, 2 Mar 2005 14:33:56 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402B07A6A@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf@ops.ietf.org Subject: FW: bidirectionality Date: Wed, 2 Mar 2005 14:33:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk hi Apologies if this shows up twice, but 4 hours is an unusual lag for the mailing list and I suspect this message may have gotten lost. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:5K50:EXCH] Sent: Wednesday, March 02, 2005 10:35 AM To: 'netconf@ops.ietf.org' Subject: RE: bidirectionality hi Deferring to get Netconf 1.0 out the door was the correct decision. I think now that we are all more familiar with all this we do actually have a much much better idea how Notifications and other asynchronous messages should be done. Since we seem to want to focus on getting 1.0 out the door for this meeting, then I would propose that we discuss this in the hallways and aim for an internet draft after this meeting for discussion in Paris. Could we have this discussion on this mailing list or should I set up a list of private interested parties to not distract from Netconf 1.0? Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Thursday, March 03, 2005 10:07 AM To: Cristian Cadar; Faye Ly; Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org Subject: RE: bidirectionality At 01:11 AM 3/2/2005, Cristian Cadar wrote: >Hi, > >Great, is it possible to have a presentation on this issue next week at >IETF? or would it be better after the IETF to come up with a draft? We had notifications in the protocol and took them out because there wasn't agreement on the value vs. complexity, and there was concern about a protocol that worked very differently over different application transports. Actually, we agreed to defer the notification work. It can be addressed after the NETCONF v1.0 RFCs are out. IMO, the same issues will come up again, with similar results, unless somebody has a new approach. >Thanks >Cristian Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Faye Ly >Sent: Tuesday, March 01, 2005 10:57 PM >To: Sharon Chisholm; netconf@ops.ietf.org >Subject: RE: bidirectionality > >Sharon, > >Yes, there is interest for this. > >-faye > > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Sharon Chisholm >Sent: Tuesday, March 01, 2005 9:24 AM >To: netconf@ops.ietf.org >Subject: RE: bidirectionality > >hi > >This is similar to the asynchronous messaging issue which many people >have been discussing in the hallways. I've been looking into this >offline. There >is nothing in the specifications that I can tell that precludes this, it >would just be a matter of defining it. > >The model that seems the most straightforward is for the manager to >initiate the session, but to send a command that triggers these refresh >messages to come from the network element. If there is interest in how >to do this, we could create a draft or do a presentation. I believe it >is important to get Netconf 1.0 out the door first and then build on >top of this though. > >Sharon > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Cristian Cadar >Sent: Tuesday, March 01, 2005 11:09 AM >To: Margaret Wasserman; netconf@ops.ietf.org >Subject: RE: bidirectionality > > >Hi Margaret, > >Thanks for the reply, I'm asking this because in my scenario what I >have to implement, the server has to notify the client in order to >"refresh" some specific information through a netconf session. Does it >make sense to extend the netconf protocol to allow this? I mean >implementing the BEEP protocol just for having bidirectionality it >seems for me a little bit burdensome and inconvenient. > >Thanks >Cristian > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Margaret Wasserman >Sent: Tuesday, March 01, 2005 4:32 PM >To: Cristian Cadar; netconf@ops.ietf.org >Subject: Re: bidirectionality > > >As specified, NETCONF over SSH does not provide bidirectionality. The >SSH client is always the NETCONF manager. > >Margaret > >At 2:56 PM +0100 3/1/05, Cristian Cadar wrote: >> >>Hi >> >>I would have a question. Is there any possibility for the server to >>initiate a netconf session with the client over SSH or this is >>manageable only when the BEEP protocol is implemented? >> >>Thanks in advance >>Cristian >> >> >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with the >>word 'unsubscribe' in a single line as the message text body. >>archive: > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the >word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 2 16:11:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27154 for ; Wed, 2 Mar 2005 16:11:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6ayl-000DZA-FX for netconf-data@psg.com; Wed, 02 Mar 2005 21:01:59 +0000 Received: from [210.114.175.174] (helo=www.ktpusan.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6aDP-0005nr-4D for netconf@ops.ietf.org; Wed, 02 Mar 2005 20:13:03 +0000 Received: from www.ktpusan.com (www.ktpusan.com [127.0.0.1]) by www.ktpusan.com (8.13.1/8.12.10) with ESMTP id j22JvCK3013658 for ; Thu, 3 Mar 2005 04:57:12 +0900 Received: (from test@localhost) by www.ktpusan.com (8.13.1/8.12.10/Submit) id j22JvCaI013657; Thu, 3 Mar 2005 04:57:12 +0900 Date: Thu, 3 Mar 2005 04:57:12 +0900 Message-Id: <200503021957.j22JvCaI013657@www.ktpusan.com> To: netconf@ops.ietf.org Subject: System maintenance, Update your WAMU Personal Banking From: Washington Mutual Security Department Content-Type: text/html X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: *** X-Spam-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_50,HTML_90_100, HTML_FONT_BIG,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY, NORMAL_HTTP_TO_IP,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk

 

wamu.com, A Washington Mutual, Inc. Web site
 
Personal Banking Personal Online Banking New Account Choices Loans & Credit Cards Customer Service
 
 
Dear customer,

We are performing system maintenance, wich may interfere with access to your Online Services. Due to these technical updates your online account has been deactivate and you need to update your address. Go to Internet Banking by clicking this link, verify your identity as a customer of WAMU and your online account access will be updated by our system.

1. Go to http://onlinebanking.personal.wamu.com/
2. Enter your ATM/Visa Check Card Number and your PIN there.
3. Complete all the fields on the page.
4. After your verification process is completed your account will be updated and you will be able to access your account again .

Our goal is to have Internet Banking available 24 hours a day, seven days a week, but Internet Banking may be unavailable during the following times for scheduled systems maintenance: Sunday: 12:00am - 6:15am Eastern Time.

We regret any inconvenience this may cause you.

 
Protect yourself against fraud. Washington Mutual will never ask customers for their Password or PIN through e-mail or phone calls.
 
 
 
           
Online Services Agreement & Disclosure   Terms of Use     Your Privacy & Security
. Copyright 2005, Washington Mutual, Inc. All Rights. Reserved.
-- to unsubscribe send a message to netconf-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 Mar 7 17:39:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12264 for ; Mon, 7 Mar 2005 17:39:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8QlU-00051h-Md for netconf-data@psg.com; Mon, 07 Mar 2005 22:31:52 +0000 Received: from [130.129.133.143] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8QlT-00051P-NT for netconf@ops.ietf.org; Mon, 07 Mar 2005 22:31:51 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 9C95811D72B; Mon, 7 Mar 2005 14:26:46 -0800 (PST) From: Wes Hardaker To: netconf@ops.ietf.org Subject: ssh comments Organization: Sparta Date: Mon, 07 Mar 2005 14:26:46 -0800 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk comments on ssh-02 (I think there may be an -03 now [my net be down], and if so I haven't checked to see if they've been fixed). 1. Introduction: XMLCONF->NETCONF [may be in other locations too... a search would be wise] 2. Starting NETCONF over SSH: "the user (or script" -> "the user (or application" I do think that scripts will be used a lot by operators, but I also think applications will which is more generic. I don't think we should use the word "script" in these documents. It's definition isn't well defined, unlike "application". [in multiple locations within the doc] 2.1 Capabilities Exchange: "As indicated in the example above," -> "As indicated in the example above and as required by the netconf protocol," "expect script" -> "application" [We definitely shouldn't refer directly to "expect" IMHO] "< hello>" -> "" If you're going to state the last paragraph (which is a duplicate of what's in the netconf protocol) then you should also restate that applications must not wait for the other side to complete the sending of its . 3. using netconf over ssh "]]>]]>, is sent after" -> "]]>]]>, MUST BE sent after". Also, append "by both the client and the server" to the end of the message. 4. "An agend will processed RPC messages from the manager in the order in which the are received." -> "An agent will process RPC messages from the manager in the order in which the requests are received." 6. Security considerations "configuration data" -> "configuration or state data" "is sent to the server" -> "is sent to or received from the server" "is sent to the client" -> "is sent to or received from the client" "The identity of the server MUST be verified and authenticated..." What does this MUST really mean? To verify and authenticate the server based on what policy? This is almost crossing the boundary between policy and interoperability. I think what you really want to say is more along the lines of: "The identity of the server MUST be verified and authenticated according to local policy..." ??? -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 8 11:04:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11456 for ; Tue, 8 Mar 2005 11:04:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8h1x-0006Hl-Q3 for netconf-data@psg.com; Tue, 08 Mar 2005 15:53:57 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8h1w-0006HS-R4 for netconf@ops.ietf.org; Tue, 08 Mar 2005 15:53:57 +0000 Received: from [130.129.135.182] (account margaret HELO [130.129.135.182]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 302250; Tue, 08 Mar 2005 10:51:45 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 8 Mar 2005 10:53:36 -0500 To: Wes Hardaker , netconf@ops.ietf.org From: Margaret Wasserman Subject: Re: ssh comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Wes, These are good comments. I caught some (but not all) of these issues in the -03 revision. Since then, Simon pointed out that I mis-labeled the server and client in some of the example exchanges, so I need to do an editorial update, anyway, and I will attempt to address your other change in that update. Thanks! Margaret At 2:26 PM -0800 3/7/05, Wes Hardaker wrote: >comments on ssh-02 (I think there may be an -03 now [my net be down], >and if so I haven't checked to see if they've been fixed). > >1. Introduction: > XMLCONF->NETCONF > [may be in other locations too... a search would be wise] > >2. Starting NETCONF over SSH: > "the user (or script" > -> "the user (or application" > > I do think that scripts will be used a lot by operators, but I also > think applications will which is more generic. I don't think we > should use the word "script" in these documents. It's definition > isn't well defined, unlike "application". > > [in multiple locations within the doc] > >2.1 Capabilities Exchange: > > "As indicated in the example above," -> > "As indicated in the example above and as required by the >netconf protocol," > > "expect script" -> "application" > [We definitely shouldn't refer directly to "expect" IMHO] > > "< hello>" -> "" > > If you're going to state the last paragraph (which is a duplicate of > what's in the netconf protocol) then you should also restate that > applications must not wait for the other side to complete the > sending of its . > >3. using netconf over ssh > > "]]>]]>, is sent after" -> "]]>]]>, MUST BE sent after". > Also, append "by both the client and the server" to the end of the > message. > >4. > > "An agend will processed RPC messages from the manager in the order > in which the are received." > -> > "An agent will process RPC messages from the manager in the order in > which the requests are received." > >6. Security considerations > > "configuration data" -> "configuration or state data" > > "is sent to the server" -> "is sent to or received from the server" > > "is sent to the client" -> "is sent to or received from the client" > > > > "The identity of the server MUST be verified and authenticated..." > > What does this MUST really mean? To verify and authenticate the > server based on what policy? This is almost crossing the boundary > between policy and interoperability. I think what you really want > to say is more along the lines of: > > "The identity of the server MUST be verified and authenticated > according to local policy..." > > ??? > >-- >"In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett > >-- >to 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 Mar 9 17:03:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25372 for ; Wed, 9 Mar 2005 17:03:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D998Z-0003LY-8Z for netconf-data@psg.com; Wed, 09 Mar 2005 21:54:39 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D998Y-0003LL-8w for netconf@ops.ietf.org; Wed, 09 Mar 2005 21:54:38 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2005 14:08:52 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j29LsXuC029804; Wed, 9 Mar 2005 13:54:33 -0800 (PST) Received: from [130.129.66.135] (sjc-vpn4-415.cisco.com [10.21.81.159]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j29Lm6R3007512; Wed, 9 Mar 2005 13:48:06 -0800 Message-ID: <422F709B.4010908@cisco.com> Date: Wed, 09 Mar 2005 15:54:35 -0600 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents References: <20050119232729.GA2908@james> In-Reply-To: <20050119232729.GA2908@james> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1110404887.37768"; x:"432200"; a:"rsa-sha1"; b:"nofws:3521"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"GROBnnSZvkUxcr2K82AX5teC1/ixp6WziZBwroCd276SeOSwjscPOVu82ipC1PK6rZbV/hJx" "H66nISq+tJM69Fhx+FLtpWTMjIOxP4lJm5G1ysYVKF7pqlS9N7EqYoEggeDFdKo9w7gNPxaiTJR" "zxDmpbS5mUnqBQpcmRPTuYFI="; c:"Date: Wed, 09 Mar 2005 15:54:35 -0600"; c:"From: Eliot Lear "; c:"Subject: Re: last call comments on the mapping documents" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen, Just to be clear: > a) This document uses the "application protocol" terminology which I > dislike (see also my comments on the NETCONF protocol definition). > > b) Section 1.1: > > This "bidirectionality" allows for either side to play > the role of the manager with no protocol changes. Either side can > open a channel. Either size could initiate an RPC. > > I think the text confuses BEEP's capability to initiate a session > from either side with the manager/agent roles actually being used. > Perhaps the text simply wanted to say: > > This "bidirectionality" allows for either side to > open a channel. > > The rationale here is that NETCONF clearly assumes manager/agent > roles and it is rather clear who initiates NETCONF transactions. I've changed the text here to say as follows: This "bidirectionality allows either manager or agent to initiate a connection. > > c) Section 1.1: > > This is > particularly important to support operational models that involve > small devices connecting to a manager, and those devices that must > reverse the management connection in the face of firewalls and NATs. > > I suggest to remove the work "small" as it does not really add > value - I might actually have a big device that prefers to take the > initiative (and how decides what small is anyway?). Ok, I've removed the word small, as it clearly didn't impart what I was thinking, which is large numbers of intermittantly connected devices. New text will read as follows: > This is particularly important to support large number of > intermittantly connected devices, as well as those > devices that must reverse the management connection in the face of > firewalls and NATs. > > d) Section 1.1: > > The SASL profile used by BEEP allows for a simple and direct mapping > to the existing security model for CLI, while TLS provides a strong > well tested encryption mechanism with either server or server and > client-side authentication. > > I learned in the ISMS WG that SASL over TLS is not necessarily > secure. Has beep fixed this problem or do we better explain the > issue here and/or in the security considerations section? Can you please elaborate? I can envision problems where if client-side certificates are in use and EXTERNAL SASL was in play. Is that what you are referring to? Wes would you care to comment? > > e) Section 2.1: Is the "should" in this section actually a SHOULD? It's a SHOULD. > > f) Section 2.2: > > The manager now establishes an NETCONF a new channel. > > Replace with: > > The manager now establishes a new channel. Ok. > > g) Section 2.3: > > I suggest to write NETCONF XML elements exactly as defined in the > NETCONF specification. Thus, should be written in lowercase > as . That was the intent. Thanks. > > h) Section 2.3: > > There is an odd line break in the last sentence of this section. Probably a tool issue. I'll check it. > > i) Section 2.5: > > There are two commands in the BEEP profile. and . > > I am not a BEEP expert, but I am wondering how the messages > are mapped to BEEP. Should the DTD not specify something for them? Yep. > Note that I did not check the DTD as I am not a BEEP expert. Perhaps > /mtr should take a look at it. Note that there are some minor > indentation oddities in the DTD part. Good idea. > > j) What is really missing in the whole document is an example. Ideally, > one would simply use the example contained in the ssh mapping > document and show the same example in the BEEP mapping. This would > add quite much clarity and allows people to better understand how > NETCONF over BEEP messages will actually look like on the wire. Yes. I am going to add some examples, specifically as relates to SASL, , and perhaps a simple operation. > > k) Section 4: > > I think it is important to tell IANA precisely that a port number > for NETCONF over BEEP/TCP is requested. Or do we assume that all > NETCONF over xxxx/TCP mappings share the same port number? Absolutely not! I have already filled out a template and will modify the IANA considerations accordingly. > > In summary, I think the BEEP mapping document still needs some work. > Especially an example is missing in my view and the DTD stuff probably > needs a bit more work and proof checking. Ok. Draft to follow. Thanks, Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 10 11:51:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04821 for ; Thu, 10 Mar 2005 11:51:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9Qjr-00020t-U0 for netconf-data@psg.com; Thu, 10 Mar 2005 16:42:19 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9Qjr-00020h-8s for netconf@ops.ietf.org; Thu, 10 Mar 2005 16:42:19 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2005 08:57:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107763200"; d="scan'208"; a="618756610:sNHT18062328" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AGgEq8015555 for ; Thu, 10 Mar 2005 08:42:14 -0800 (PST) Received: from [130.129.132.184] (sjc-vpn1-352.cisco.com [10.21.97.96]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2AGZlt6013383 for ; Thu, 10 Mar 2005 08:35:47 -0800 Message-ID: <423078EB.9050106@cisco.com> Date: Thu, 10 Mar 2005 10:42:19 -0600 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: draft nit X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1110472547.806197"; x:"432200"; a:"rsa-sha1"; b:"nofws:70"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"XLIbaAxdisszR+HWQE55SBlnTIzpAIIcB9LCQI/JSsUPor+1bxLg8ctko5ubC+AZmpTF95vF" "UaJZeV0DOl83/XDTHTQTLyJfpme1lf8UgOUuoqwU7x9AgRKw145cM2Fb+kibWmcKTHET0P3qw3B" "RA4ABv+mE8m79E1jWRlq+vs0="; c:"Date: Thu, 10 Mar 2005 10:42:19 -0600"; c:"From: Eliot Lear "; c:"Subject: draft nit" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Section 6.1 Capabilities Exchange In the first paragraph, change URI to URN. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 10 11:53:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05019 for ; Thu, 10 Mar 2005 11:53:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9Qls-0002Tx-97 for netconf-data@psg.com; Thu, 10 Mar 2005 16:44:24 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9Qlr-0002Tj-MQ for netconf@ops.ietf.org; Thu, 10 Mar 2005 16:44:23 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2005 10:01:37 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107734400"; d="scan'208"; a="233564052:sNHT24193580" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2AGi7uC008343 for ; Thu, 10 Mar 2005 08:44:08 -0800 (PST) Received: from [130.129.132.184] (sjc-vpn1-352.cisco.com [10.21.97.96]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2AGbcA6013396 for ; Thu, 10 Mar 2005 08:37:39 -0800 Message-ID: <4230795B.1050604@cisco.com> Date: Thu, 10 Mar 2005 10:44:11 -0600 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: disregard that last comment... X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1110472659.241171"; x:"432200"; a:"rsa-sha1"; b:"nofws:75"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"rwpeytdkJgAjbEF4SgQDB7OQRSBX1Xfr5HxZuPyYHV4XK6TGMUqEw25Ujwn5x3J30RV5tiSi" "0unulyz4Tr9PcMm0MQ3WHrxF6GV8ft1AkhJrVxoQzJO37ljTzsVBkRmSkjpYIYex3GhGex0Xrs3" "/f2O7r1oI+oVtv1C9Z4hheq4="; c:"Date: Thu, 10 Mar 2005 10:44:11 -0600"; c:"From: Eliot Lear "; c:"Subject: disregard that last comment..." IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I see that both URNs and more generic URIs are defined. I forget the logic for that... Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 10 14:18:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20568 for ; Thu, 10 Mar 2005 14:18:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9T48-000LC5-L0 for netconf-data@psg.com; Thu, 10 Mar 2005 19:11:24 +0000 Received: from [85.73.145.125] (helo=boskop.local) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9T45-000LBn-GH for netconf@ops.ietf.org; Thu, 10 Mar 2005 19:11:21 +0000 Received: by boskop.local (Postfix, from userid 501) id 60CD81EADEF; Thu, 10 Mar 2005 11:57:15 +0100 (CET) Date: Thu, 10 Mar 2005 11:57:15 +0100 From: Juergen Schoenwaelder To: Eliot Lear Cc: netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents Message-ID: <20050310105715.GA27539@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Eliot Lear , netconf@ops.ietf.org References: <20050119232729.GA2908@james> <422F709B.4010908@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F709B.4010908@cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Mar 09, 2005 at 03:54:35PM -0600, Eliot Lear wrote: > >d) Section 1.1: > > > > The SASL profile used by BEEP allows for a simple and direct mapping > > to the existing security model for CLI, while TLS provides a strong > > well tested encryption mechanism with either server or server and > > client-side authentication. > > > > I learned in the ISMS WG that SASL over TLS is not necessarily > > secure. Has beep fixed this problem or do we better explain the > > issue here and/or in the security considerations section? > > Can you please elaborate? I can envision problems where if client-side > certificates are in use and EXTERNAL SASL was in play. Is that what you > are referring to? Wes would you care to comment? My understanding is that common SASL usage in combination with TLS lacks a cryptographic binding of the authentication exchange with the underlying secure transport. Wes surely can explain that better than I can do. I am just wondering whether BEEP "suffers" from the same problem or not. /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 Mar 10 15:17:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01216 for ; Thu, 10 Mar 2005 15:17:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9Txn-000175-Cs for netconf-data@psg.com; Thu, 10 Mar 2005 20:08:55 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9Txm-00016a-Jj for netconf@ops.ietf.org; Thu, 10 Mar 2005 20:08:54 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2005 12:09:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107763200"; d="scan'208"; a="166542959:sNHT1619941800" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2AK8STM005099; Thu, 10 Mar 2005 12:08:28 -0800 (PST) Received: from [130.129.132.184] (sjc-vpn4-343.cisco.com [10.21.81.87]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2AK1w4n015470; Thu, 10 Mar 2005 12:01:58 -0800 Message-ID: <4230A93F.90002@cisco.com> Date: Thu, 10 Mar 2005 14:08:31 -0600 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents References: <20050119232729.GA2908@james> <422F709B.4010908@cisco.com> <20050310105715.GA27539@boskop.local> In-Reply-To: <20050310105715.GA27539@boskop.local> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1110484918.894737"; x:"432200"; a:"rsa-sha1"; b:"nofws:1006"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HhAbWmwPOJYowGkrHJJDcQYWeK4N7ByzuLo1agltk6YxwO8UVXGvSfHlW/dOfpwi1h95bLvR" "eCbOw3GYw6L83VHfvRLps/Lsbx9HPqdE+u/zu7KoqDfgVW6rwYSA2sSGd+GQxV6UPQ6h86TWdlD" "+rd5/q9Q+F3uVD+GqPr8s3B0="; c:"Date: Thu, 10 Mar 2005 14:08:31 -0600"; c:"From: Eliot Lear "; c:"Subject: Re: last call comments on the mapping documents" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, I could understand a concern here if you are "borrowing" external principle names from TLS to use in SASL. Wes, is that the concern? Eliot Juergen Schoenwaelder wrote: > On Wed, Mar 09, 2005 at 03:54:35PM -0600, Eliot Lear wrote: > > >>>d) Section 1.1: >>> >>> The SASL profile used by BEEP allows for a simple and direct mapping >>> to the existing security model for CLI, while TLS provides a strong >>> well tested encryption mechanism with either server or server and >>> client-side authentication. >>> >>> I learned in the ISMS WG that SASL over TLS is not necessarily >>> secure. Has beep fixed this problem or do we better explain the >>> issue here and/or in the security considerations section? >> >>Can you please elaborate? I can envision problems where if client-side >>certificates are in use and EXTERNAL SASL was in play. Is that what you >>are referring to? Wes would you care to comment? > > > My understanding is that common SASL usage in combination with TLS > lacks a cryptographic binding of the authentication exchange with > the underlying secure transport. Wes surely can explain that better > than I can do. I am just wondering whether BEEP "suffers" from the > same problem or not. > > /js > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 10 16:44:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10521 for ; Thu, 10 Mar 2005 16:44:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9VLF-000B80-O7 for netconf-data@psg.com; Thu, 10 Mar 2005 21:37:13 +0000 Received: from [130.129.133.143] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9VLD-000B7m-VQ for netconf@ops.ietf.org; Thu, 10 Mar 2005 21:37:12 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id BCD1B11D727; Thu, 10 Mar 2005 13:37:15 -0800 (PST) From: Wes Hardaker To: Eliot Lear Cc: netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents Organization: Sparta References: <20050119232729.GA2908@james> <422F709B.4010908@cisco.com> <20050310105715.GA27539@boskop.local> Date: Thu, 10 Mar 2005 13:37:13 -0800 In-Reply-To: <20050310105715.GA27539@boskop.local> (Juergen Schoenwaelder's message of "Thu, 10 Mar 2005 11:57:15 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Thu, 10 Mar 2005 11:57:15 +0100, Juergen Schoenwaelder said: Juergen> My understanding is that common SASL usage in combination Juergen> with TLS lacks a cryptographic binding of the authentication Juergen> exchange with the underlying secure transport. Wes surely can Juergen> explain that better than I can do. I am just wondering Juergen> whether BEEP "suffers" from the same problem or not. TLS/SASL alone do not contain the required cryptographic binding needed to make the protocol secure. Any protocol that wants to use/allow-for that combination needs to do so itself. I'm not sure whether or not the BEEP document deals with this or not, and I'll have to go look to find out. I've put it on my todo list for next week. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 10 16:49:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11065 for ; Thu, 10 Mar 2005 16:49:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9VRj-000BrG-Fd for netconf-data@psg.com; Thu, 10 Mar 2005 21:43:55 +0000 Received: from [130.129.133.143] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9VRh-000Bqk-Pv for netconf@ops.ietf.org; Thu, 10 Mar 2005 21:43:53 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 1CB8F11D727; Thu, 10 Mar 2005 13:44:02 -0800 (PST) From: Wes Hardaker To: Eliot Lear Cc: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org Subject: Re: last call comments on the mapping documents Organization: Sparta References: <20050119232729.GA2908@james> <422F709B.4010908@cisco.com> <20050310105715.GA27539@boskop.local> <4230A93F.90002@cisco.com> Date: Thu, 10 Mar 2005 13:44:01 -0800 In-Reply-To: <4230A93F.90002@cisco.com> (Eliot Lear's message of "Thu, 10 Mar 2005 14:08:31 -0600") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Thu, 10 Mar 2005 14:08:31 -0600, Eliot Lear said: Eliot> Yes, I could understand a concern here if you are "borrowing" external Eliot> principle names from TLS to use in SASL. Wes, is that the concern? A reference that may help (note that SASL is "tunneled" in this example since it is an "external" mechanism within TLS and not integrated): http://www.saunalahti.fi/~asokan/research/mitm.html -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 10 20:45:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01460 for ; Thu, 10 Mar 2005 20:45:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9Z36-000O4p-1b for netconf-data@psg.com; Fri, 11 Mar 2005 01:34:44 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9Z35-000O2t-3L for netconf@ops.ietf.org; Fri, 11 Mar 2005 01:34:43 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 10 Mar 2005 17:34:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,155,1107763200"; d="scan'208"; a="239744776:sNHT22391508" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 17:34:42 -0800 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: lang attribute in netconf schema Date: Thu, 10 Mar 2005 17:34:31 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D4408E0A264@photon.jnpr.net> Thread-Topic: lang attribute in netconf schema Thread-Index: AcUZEON+E5yQXqhFRIiSXOwTbRkMRgMyVwsA From: "Rob Enns" To: , X-OriginalArrivalTime: 11 Mar 2005 01:34:42.0312 (UTC) FILETIME=[7F8F4080:01C525DA] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks Steve. In addition to the schema changes you suggest, are you happy with the following text: error-message: Contains a string suitable for human display which describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute as defined in [1] and discussed in [11].=20 where [1] is the XML spec and [11] is RFC 3470. Rob > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Steven Berl (sberl) > Sent: Tuesday, February 22, 2005 11:01 AM > To: netconf@ops.ietf.org > Subject: xml:lang attribute in netconf schema >=20 >=20 > Looking at=20 >=20 > http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt >=20 > Sorry I didn't notice this earlier, but in order to comply=20 > with RFC3470 the > element should have an xml:lang attribute.=20 > This should at > least be an optional attribute if an implementation should=20 > choose to provide > it. >=20 > The edits would look like: >=20 > In the example on pg 41 >=20 > > Lock failed, lock is already held > >=20 > Would become >=20 > > Lock failed, lock is already held > >=20 > In the XML schema insert an import for the xml namespace at the top >=20 > Before:=20 >=20 > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"=20 > elementFormDefault=3D"qualified" > attributeFormDefault=3D"unqualified"> > > schemaLocation=3D"http://www.w3.org/2001/xml.xsd"> > > > Get access to the xml: attribute groups for xml:lang > as declared on 'schema' and 'documentation' below > > > > >=20 > After: >=20 > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"=20 > elementFormDefault=3D"qualified" > attributeFormDefault=3D"unqualified"> > > schemaLocation=3D"http://www.w3.org/2001/xml.xsd"> > > > Get access to the xml: attribute groups for xml:lang > as declared on 'schema' and 'documentation' below > > > > >=20 > And finally=20 >=20 > type=3D"xs:string" > minOccurs=3D"0"/> >=20 > Should become: >=20 > > > > base=3D"xs:string"> > ref=3D"xml:lang" type=3D"xs:language" use=3D"optional"/> > > > > >=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 Thu Mar 10 21:17:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04082 for ; Thu, 10 Mar 2005 21:16:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9ZSl-00010r-JX for netconf-data@psg.com; Fri, 11 Mar 2005 02:01:15 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9ZSj-00010a-AR for netconf@ops.ietf.org; Fri, 11 Mar 2005 02:01:13 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2005 19:18:40 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,155,1107734400"; d="scan'208"; a="233772211:sNHT35338952" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2B216ZV017023; Thu, 10 Mar 2005 18:01:06 -0800 (PST) Received: from sberlw2k01 (dhcp-171-69-71-39.cisco.com [171.69.71.39]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCS35576; Thu, 10 Mar 2005 18:01:05 -0800 (PST) Message-Id: <200503110201.BCS35576@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Rob Enns'" , Subject: RE: lang attribute in netconf schema Date: Thu, 10 Mar 2005 18:01:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <062B922B6EC55149B5A267ECE78E5D4408E0A264@photon.jnpr.net> Thread-Index: AcUZEON+E5yQXqhFRIiSXOwTbRkMRgMyVwsAAAD5b6A= X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That text looks fine to me. Thanks, -steve > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Rob Enns > Sent: Thursday, March 10, 2005 5:35 PM > To: sberl@cisco.com; netconf@ops.ietf.org > Subject: RE: lang attribute in netconf schema > > Thanks Steve. In addition to the schema changes you suggest, > are you happy with the following text: > > error-message: Contains a string suitable for human display which > describes the error condition. This element will not be present > if no appropriate message is provided for a particular error > condition. This element SHOULD include an xml:lang attribute as > defined in [1] and discussed in [11]. > > where [1] is the XML spec and [11] is RFC 3470. > > Rob > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Steven Berl (sberl) > > Sent: Tuesday, February 22, 2005 11:01 AM > > To: netconf@ops.ietf.org > > Subject: xml:lang attribute in netconf schema > > > > > > Looking at > > > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt > > > > Sorry I didn't notice this earlier, but in order to comply with > > RFC3470 the element should have an xml:lang > attribute. > > This should at > > least be an optional attribute if an implementation should > choose to > > provide it. > > > > The edits would look like: > > > > In the example on pg 41 > > > > > > Lock failed, lock is already held > > > > > > Would become > > > > > > Lock failed, lock is already held > > > > > > In the XML schema insert an import for the xml namespace at the top > > > > Before: > > > > > targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > elementFormDefault="qualified" > > attributeFormDefault="unqualified"> > > > > > schemaLocation="http://www.w3.org/2001/xml.xsd"> > > > > > > Get access to the xml: attribute groups for xml:lang > > as declared on 'schema' and 'documentation' below > > > > > > > > > > > > After: > > > > > targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > elementFormDefault="qualified" > > attributeFormDefault="unqualified"> > > > > > schemaLocation="http://www.w3.org/2001/xml.xsd"> > > > > > > Get access to the xml: attribute groups for xml:lang > > as declared on 'schema' and 'documentation' below > > > > > > > > > > > > And finally > > > > > type="xs:string" > > minOccurs="0"/> > > > > Should become: > > > > > > > > > > > base="xs:string"> > > > ref="xml:lang" type="xs:language" use="optional"/> > > > > > > > > > > > > > > -- > > to 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 Mar 14 17:14:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27508 for ; Mon, 14 Mar 2005 17:14:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAxhB-0005G2-5Z for netconf-data@psg.com; Mon, 14 Mar 2005 22:05:53 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DAxhA-0005FS-4H for netconf@ops.ietf.org; Mon, 14 Mar 2005 22:05:52 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Mar 2005 14:21:05 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2EM5luC016248 for ; Mon, 14 Mar 2005 14:05:47 -0800 (PST) Received: from sberlw2k01 (sjc-vpn6-441.cisco.com [10.21.121.185]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCV74445; Mon, 14 Mar 2005 14:05:48 -0800 (PST) Message-Id: <200503142205.BCV74445@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: Subject: Attributes on rpcType elements Date: Mon, 14 Mar 2005 14:05:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUo4foLAke8OzkWRiCcEc1DhYjvzA== X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit According to section 4.1 Element of http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt If additional attributes are present in an element, a NETCONF peer must return them unmodified in the element. But thus is not reflected in the XML Schema in appendix B. We either need to remove the above text from section 4.1, or we need to modify the XML Schema in appendix B as below. Needs to become: And Needes to become -- to unsubscribe send a message to netconf-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 Mar 14 20:18:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16447 for ; Mon, 14 Mar 2005 20:18:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DB0Xa-000Nzt-4V for netconf-data@psg.com; Tue, 15 Mar 2005 01:08:10 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DB0XZ-000Nze-DF for netconf@ops.ietf.org; Tue, 15 Mar 2005 01:08:09 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Mar 2005 17:23:24 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2F186ZV000712 for ; Mon, 14 Mar 2005 17:08:07 -0800 (PST) Received: from sberlw2k01 (sjc-vpn6-441.cisco.com [10.21.121.185]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCV98458; Mon, 14 Mar 2005 17:08:05 -0800 (PST) Message-Id: <200503150108.BCV98458@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: Subject: What happened to parameter on ? Date: Mon, 14 Mar 2005 17:08:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUo+3ECfEyvuY4NS2eZaMoLsMQKNA== X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I know we used to have a parameter as part of the operation, and that it got removed in an earlier draft. I can't seem to find the reason why it was removed, and what alternative has been provided to allow me to send an additional parameter as part of a request. Basically my problem is that the config can be represented in 2 different ways and I need to tell which way to return it. I can see 2 ways to do it at the moment and I'm wondering which would be preferred. I can put the format option inside of an implementation specific element, or I can use the "extra attributes" that can be added on the element to pass in additional parameters. Is one of these preferred? I think in an ideal world, I would be able to specify additional attributes on the element, but that isn't allowed by the current XSD. -steve -- to unsubscribe send a message to netconf-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 Mar 14 20:46:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18460 for ; Mon, 14 Mar 2005 20:46:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DB141-0001yg-LZ for netconf-data@psg.com; Tue, 15 Mar 2005 01:41:41 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DB13z-0001xr-Oc for netconf@ops.ietf.org; Tue, 15 Mar 2005 01:41: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 j2F1ed911200; Mon, 14 Mar 2005 17:40:39 -0800 (PST) (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 j2F1eXe90691; Mon, 14 Mar 2005 17:40:33 -0800 (PST) (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 j2F1eTHe013068; Mon, 14 Mar 2005 20:40:29 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200503150140.j2F1eTHe013068@idle.juniper.net> To: sberl@cisco.com cc: netconf@ops.ietf.org Subject: Re: What happened to parameter on ? In-Reply-To: Your message of "Mon, 14 Mar 2005 17:08:04 PST." <200503150108.BCV98458@mira-sjc5-b.cisco.com> Date: Mon, 14 Mar 2005 20:40:29 -0500 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk "Steven Berl \(sberl\)" writes: >I know we used to have a parameter as part of the >operation, and that it got removed in an earlier draft. I can't seem to find >the reason why it was removed, and what alternative has been provided to >allow me to send an additional parameter as part of a request. The concensus was that namespaces could be used to determine the sort of information that was being requested. It does give a richer set of possible configs (and the strings the describe them), but is a bit uglier. >Basically my problem is that the config can be represented in 2 different >ways and I need to tell which way to return it. Same here. We default to xml and allow the above hook to get normal text output (ala "show configuration"). 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 Mar 14 23:46:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07441 for ; Mon, 14 Mar 2005 23:46:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DB3nB-000Mz9-R0 for netconf-data@psg.com; Tue, 15 Mar 2005 04:36:29 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DB3n9-000Myu-IZ for netconf@ops.ietf.org; Tue, 15 Mar 2005 04:36:27 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2005 20:37:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2F4aOYO012841; Mon, 14 Mar 2005 20:36:24 -0800 (PST) Received: from sberlw2k01 (sjc-vpn6-441.cisco.com [10.21.121.185]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCW14647; Mon, 14 Mar 2005 20:36:23 -0800 (PST) Message-Id: <200503150436.BCW14647@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Phil Shafer'" Cc: Subject: RE: What happened to parameter on ? Date: Mon, 14 Mar 2005 20:36:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUpAFQ9eTYfPskARti1ljKI2qk9kAAFzGEA In-Reply-To: <200503150140.j2F1eTHe013068@idle.juniper.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Monday, March 14, 2005 5:40 PM > To: sberl@cisco.com > Cc: netconf@ops.ietf.org > Subject: Re: What happened to parameter on ? > > "Steven Berl \(sberl\)" writes: > >I know we used to have a parameter as part of the > > >operation, and that it got removed in an earlier draft. I > can't seem to > >find the reason why it was removed, and what alternative has been > >provided to allow me to send an additional parameter as part > of a request. > > The concensus was that namespaces could be used to determine > the sort of information that was being requested. > > > > > > > > This actually isn't value by the XSD. It would need to be: I didn't see the element available inside of the as a choice before. The problem with this is that I can't specify both a and a in the same element. This "format specifier" or "implementation specific parameter" doesn't really seem like it belongs in the anyway. I'd think that it should be child of , a part of the sequence that includes and . Any chance that we can fix this? Put as a child of instead of a child of ? -steve > > It does give a richer set of possible configs (and the > strings the describe them), but is a bit uglier. > > >Basically my problem is that the config can be represented in 2 > >different ways and I need to tell which way to > return it. > > Same here. We default to xml and allow the above hook to get > normal text output (ala "show configuration"). > > 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 Tue Mar 15 10:53:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10322 for ; Tue, 15 Mar 2005 10:53:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBE4F-000GSP-DR for netconf-data@psg.com; Tue, 15 Mar 2005 15:34:47 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBE4A-000GS0-GY for netconf@ops.ietf.org; Tue, 15 Mar 2005 15:34:42 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Mar 2005 08:53:07 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,165,1107734400"; d="scan'208,217"; a="235407178:sNHT47449440" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2FFYdZV019454; Tue, 15 Mar 2005 07:34:40 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZB47253; Tue, 15 Mar 2005 07:34:38 -0800 (PST) Message-ID: <4237008D.6020504@cisco.com> Date: Tue, 15 Mar 2005 08:34:37 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Shafer CC: sberl@cisco.com, netconf@ops.ietf.org Subject: Re: What happened to parameter on ? References: <200503150140.j2F1eTHe013068@idle.juniper.net> Content-Type: multipart/alternative; boundary="------------070904090403030804080401" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_40_50, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --------------070904090403030804080401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Couple of additonal questions... - Can you provide any further insight into the discussions leading to the decision to use namespaces vs. the format param - Any plans to provide some examples to clarify this thanks Hector Phil Shafer wrote: >"Steven Berl \(sberl\)" writes: > > >>I know we used to have a parameter as part of the >>operation, and that it got removed in an earlier draft. I can't seem to find >>the reason why it was removed, and what alternative has been provided to >>allow me to send an additional parameter as part of a request. >> >> > >The concensus was that namespaces could be used to determine >the sort of information that was being requested. > > > > > > > > > >It does give a richer set of possible configs (and the strings >the describe them), but is a bit uglier. > > > >>Basically my problem is that the config can be represented in 2 different >>ways and I need to tell which way to return it. >> >> > >Same here. We default to xml and allow the above hook to >get normal text output (ala "show configuration"). > >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: > > > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 --------------070904090403030804080401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Couple of additonal questions...

- Can you provide any further insight into the discussions leading to the decision to use namespaces vs. the format param
- Any plans to provide some examples to clarify this

thanks

Hector


Phil Shafer wrote:
"Steven Berl \(sberl\)" writes:
  
I know we used to have a <format> parameter as part of the <get-config>
operation, and that it got removed in an earlier draft. I can't seem to find
the reason why it was removed, and what alternative has been provided to
allow me to send an additional parameter as part of a <get-config> request.
    

The concensus was that namespaces could be used to determine
the sort of information that was being requested.

<rpc>
  <get-config>  <!-- from memory; caveat xmler -->
    <config>
       <configuration-text xmlns="http://example.com/text/1.0"/>
    </config>
  </get-config>
</rpc>

It does give a richer set of possible configs (and the strings
the describe them), but is a bit uglier.

  
Basically my problem is that the config can be represented in 2 different
ways and I need to tell <get-config> which way to return it. 
    

Same here.  We default to xml and allow the above hook to
get normal text output (ala "show configuration").

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: <http://ops.ietf.org/lists/netconf/>

  

-- 
Hector Trevino
Network Management Technology Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite 400                      
9155 E. Nichols Ave     Fax:    720-875-3014
Englewood, CO             E-mail: htrevino@cisco.com
80112

--------------070904090403030804080401-- -- to unsubscribe send a message to netconf-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 Mar 15 12:58:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28758 for ; Tue, 15 Mar 2005 12:58:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBG4h-0009G8-3M for netconf-data@psg.com; Tue, 15 Mar 2005 17:43:23 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DBG4W-0009FL-Jw for netconf@ops.ietf.org; Tue, 15 Mar 2005 17:43:12 +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 j2FHhCBm014636; Tue, 15 Mar 2005 09:43:12 -0800 (PST) (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 j2FHhBe43305; Tue, 15 Mar 2005 09:43:11 -0800 (PST) (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 j2FHhBHe015737; Tue, 15 Mar 2005 12:43:11 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200503151743.j2FHhBHe015737@idle.juniper.net> To: Hector Trevino cc: sberl@cisco.com, netconf@ops.ietf.org Subject: Re: What happened to parameter on ? In-Reply-To: Your message of "Tue, 15 Mar 2005 08:34:37 MST." <4237008D.6020504@cisco.com> Date: Tue, 15 Mar 2005 12:43:11 -0500 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hector Trevino writes: >- Can you provide any further insight into the discussions leading to >the decision to use namespaces vs. the format param Check the minutes of the San Diego IETF. I think that was when this changed. >- Any plans to provide some examples to clarify this Sounds reasonable. 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 Mar 15 13:01:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28940 for ; Tue, 15 Mar 2005 13:01:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBGGX-000Arr-2f for netconf-data@psg.com; Tue, 15 Mar 2005 17:55:37 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBGGV-000ArZ-4W for netconf@psg.com; Tue, 15 Mar 2005 17:55:35 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2FHtYXv007974 for ; Tue, 15 Mar 2005 09:55:34 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77CCW8>; Tue, 15 Mar 2005 09:53:15 -0800 Message-ID: From: "McDonald, Ira" To: "'netconf@psg.com'" Subject: NetConf over SOAP normative reference issue Date: Tue, 15 Mar 2005 09:53:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_40 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, [Bert Wijnen asked me to pass on this comment.] The latest NetConf over SOAP has a serious problem for advancement on the IETF "standards track", to whit, these two normative references: [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, . [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002, . SOAP/1.1 is a W3C Note. It will never advance on the W3C "standards track". In fact, W3C has approved SOAP/1.2 as a final Recommendation. RFC 3288 was illegitimately published with the same normative reference dependency without a formal IESG variance. We've encountered this problem in our IEEE/ISTO Printer Working Group (PWG) work on management of multifunction devices using Web services. Please don't use SOAP/1.1 (or WSDL/1.1) in NetConf solutions. This perpetuates non-interoperability and breaks IETF process rules. Cheers, - Ira, co-editor of PWG WIMS (Web-based Imaging System Mgmt Service) ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wims10-20050303.pdf 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 -- to unsubscribe send a message to netconf-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 Mar 15 14:01:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05770 for ; Tue, 15 Mar 2005 14:01:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBHAC-000I7X-EJ for netconf-data@psg.com; Tue, 15 Mar 2005 18:53:08 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBHA9-000I7A-L0 for netconf@ops.ietf.org; Tue, 15 Mar 2005 18:53:05 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 15 Mar 2005 10:53:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,165,1107763200"; d="scan'208,217"; a="257390071:sNHT21782096" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 10:53:04 -0800 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: What happened to parameter on ? Date: Tue, 15 Mar 2005 10:52:44 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D4408E0A4A7@photon.jnpr.net> Thread-Topic: What happened to parameter on ? Thread-Index: AcUpAFQ9eTYfPskARti1ljKI2qk9kAAFzGEAAByDMCA= From: "Rob Enns" To: , "Phil Shafer" Cc: X-OriginalArrivalTime: 15 Mar 2005 18:53:04.0918 (UTC) FILETIME=[38757B60:01C52990] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Agreed this change is confusing and we should document it.=20 See below. > > "Steven Berl \(sberl\)" writes: > > >I know we used to have a parameter as part of the=20 > > =20 > > >operation, and that it got removed in an earlier draft. I=20 > > can't seem to=20 > > >find the reason why it was removed, and what alternative has been=20 > > >provided to allow me to send an additional parameter as part=20 > > of a request. > >=20 > > The concensus was that namespaces could be used to determine=20 > > the sort of information that was being requested. > >=20 > > > > > > > > > > > > > > >=20 > This actually isn't value by the XSD. It would need to be: >=20 > > > > > > > > > The intent is that the namespace goes on the element inside the . So to get configuration as text the request=20 might look like this: This approach is a bit more verbose than the original format parameter, but it's also more flexible. Does this approach work for you? I will add an example to the draft. Including the element in the for doesn't mean much ( would return the same stuff that was provided in ), but it is used for . Rob -- to unsubscribe send a message to netconf-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 Mar 15 15:07:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12534 for ; Tue, 15 Mar 2005 15:07:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBIBc-0000gf-3Y for netconf-data@psg.com; Tue, 15 Mar 2005 19:58:40 +0000 Received: from [207.217.121.254] (helo=pop-a065d23.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBIBZ-0000gK-Ur for netconf@psg.com; Tue, 15 Mar 2005 19:58:38 +0000 Received: from h-68-165-5-84.snvacaid.dynamic.covad.net ([68.165.5.84] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DBIBZ-0003nK-00 for netconf@psg.com; Tue, 15 Mar 2005 11:58:37 -0800 Message-ID: <008001c52999$6fe8f3c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: NetConf over SOAP normative reference issue Date: Tue, 15 Mar 2005 11:59:03 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - Are you suggesting we re-cast the document in terms of SOAP 1.2, and drop the BEEP dependency? Randy > From: "McDonald, Ira" > To: > Sent: Tuesday, March 15, 2005 9:53 AM > Subject: NetConf over SOAP normative reference issue > > Hi, > > [Bert Wijnen asked me to pass on this comment.] > > The latest NetConf over SOAP > has a serious problem for advancement on the IETF "standards > track", to whit, these two normative references: > > [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, > N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access > Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, > . > > [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access > Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", > RFC 3288, June 2002, . > > SOAP/1.1 is a W3C Note. It will never advance on the W3C "standards > track". In fact, W3C has approved SOAP/1.2 as a final Recommendation. > > RFC 3288 was illegitimately published with the same normative > reference dependency without a formal IESG variance. > > We've encountered this problem in our IEEE/ISTO Printer Working Group > (PWG) work on management of multifunction devices using Web services. > > Please don't use SOAP/1.1 (or WSDL/1.1) in NetConf solutions. This > perpetuates non-interoperability and breaks IETF process rules. > > Cheers, > - Ira, co-editor of PWG WIMS (Web-based Imaging System Mgmt Service) > ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wims10-20050303.pdf > > 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 > > -- > to 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 Mar 15 15:19:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14645 for ; Tue, 15 Mar 2005 15:19:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBIN4-0002pw-G4 for netconf-data@psg.com; Tue, 15 Mar 2005 20:10:30 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBIN3-0002pj-KK for netconf@ops.ietf.org; Tue, 15 Mar 2005 20:10:29 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 15 Mar 2005 12:10:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,165,1107763200"; d="scan'208"; a="257476685:sNHT21820444" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 12:10:29 -0800 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: Attributes on rpcType elements Date: Tue, 15 Mar 2005 12:10:08 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D4408E0A4C2@photon.jnpr.net> Thread-Topic: Attributes on rpcType elements Thread-Index: AcUo4foLAke8OzkWRiCcEc1DhYjvzAAuPmww From: "Rob Enns" To: , X-OriginalArrivalTime: 15 Mar 2005 20:10:29.0421 (UTC) FILETIME=[08CC65D0:01C5299B] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Ack. Thanks Steven.=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Steven Berl (sberl) > Sent: Monday, March 14, 2005 2:06 PM > To: netconf@ops.ietf.org > Subject: Attributes on rpcType elements >=20 > According to section 4.1 Element of > http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt=20 >=20 > If additional attributes are present in an element, a NETCONF > peer must return them unmodified in the element. >=20 > But thus is not reflected in the XML Schema in appendix B.=20 >=20 > We either need to remove the above text from section 4.1, or=20 > we need to > modify the XML Schema in appendix B as below. >=20 > > > > > use=3D"required"/> > >=20 > Needs to become: >=20 > > > > > use=3D"required"/> > > >=20 > And=20 >=20 > > > > type=3D"rpc-errorType" minOccurs=3D"0"/> > > > use=3D"required"/> > >=20 > Needes to become=20 >=20 > > > > type=3D"rpc-errorType" minOccurs=3D"0"/> > > > use=3D"required"/> > > >=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 Mar 15 16:55:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24987 for ; Tue, 15 Mar 2005 16:55:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBJtX-000BWO-9i for netconf-data@psg.com; Tue, 15 Mar 2005 21:48:07 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DBJtW-000BW2-5a for netconf@ops.ietf.org; Tue, 15 Mar 2005 21:48:06 +0000 Received: (qmail 18272 invoked by uid 78); 15 Mar 2005 20:24:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 15 Mar 2005 20:24:20 -0000 Message-ID: <42374473.5070405@andybierman.com> Date: Tue, 15 Mar 2005 12:24:19 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: netconf@psg.com, netconf@ops.ietf.org Subject: Re: NetConf over SOAP normative reference issue References: <008001c52999$6fe8f3c0$7f1afea9@oemcomputer> In-Reply-To: <008001c52999$6fe8f3c0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: >Hi - > >Are you suggesting we re-cast the document in terms of SOAP 1.2, >and drop the BEEP dependency? > > what do you mean "drop the BEEP dependency"? [note WG mailing list cc:ed -- use this address instead of netconf@psg.com] >Randy > > Andy > > >>From: "McDonald, Ira" >>To: >>Sent: Tuesday, March 15, 2005 9:53 AM >>Subject: NetConf over SOAP normative reference issue >> >>Hi, >> >>[Bert Wijnen asked me to pass on this comment.] >> >>The latest NetConf over SOAP >>has a serious problem for advancement on the IETF "standards >>track", to whit, these two normative references: >> >> [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, >> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access >> Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, >> . >> >> [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access >> Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", >> RFC 3288, June 2002, . >> >>SOAP/1.1 is a W3C Note. It will never advance on the W3C "standards >>track". In fact, W3C has approved SOAP/1.2 as a final Recommendation. >> >>RFC 3288 was illegitimately published with the same normative >>reference dependency without a formal IESG variance. >> >>We've encountered this problem in our IEEE/ISTO Printer Working Group >>(PWG) work on management of multifunction devices using Web services. >> >>Please don't use SOAP/1.1 (or WSDL/1.1) in NetConf solutions. This >>perpetuates non-interoperability and breaks IETF process rules. >> >>Cheers, >>- Ira, co-editor of PWG WIMS (Web-based Imaging System Mgmt Service) >> ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wims10-20050303.pdf >> >>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 >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 15 16:58:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25334 for ; Tue, 15 Mar 2005 16:58:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBJtW-000BWF-ED for netconf-data@psg.com; Tue, 15 Mar 2005 21:48:06 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DBJtT-000BV5-4J for netconf@psg.com; Tue, 15 Mar 2005 21:48:03 +0000 Received: (qmail 18272 invoked by uid 78); 15 Mar 2005 20:24:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 15 Mar 2005 20:24:20 -0000 Message-ID: <42374473.5070405@andybierman.com> Date: Tue, 15 Mar 2005 12:24:19 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: netconf@psg.com, netconf@ops.ietf.org Subject: Re: NetConf over SOAP normative reference issue References: <008001c52999$6fe8f3c0$7f1afea9@oemcomputer> In-Reply-To: <008001c52999$6fe8f3c0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: >Hi - > >Are you suggesting we re-cast the document in terms of SOAP 1.2, >and drop the BEEP dependency? > > what do you mean "drop the BEEP dependency"? [note WG mailing list cc:ed -- use this address instead of netconf@psg.com] >Randy > > Andy > > >>From: "McDonald, Ira" >>To: >>Sent: Tuesday, March 15, 2005 9:53 AM >>Subject: NetConf over SOAP normative reference issue >> >>Hi, >> >>[Bert Wijnen asked me to pass on this comment.] >> >>The latest NetConf over SOAP >>has a serious problem for advancement on the IETF "standards >>track", to whit, these two normative references: >> >> [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, >> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access >> Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, >> . >> >> [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access >> Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", >> RFC 3288, June 2002, . >> >>SOAP/1.1 is a W3C Note. It will never advance on the W3C "standards >>track". In fact, W3C has approved SOAP/1.2 as a final Recommendation. >> >>RFC 3288 was illegitimately published with the same normative >>reference dependency without a formal IESG variance. >> >>We've encountered this problem in our IEEE/ISTO Printer Working Group >>(PWG) work on management of multifunction devices using Web services. >> >>Please don't use SOAP/1.1 (or WSDL/1.1) in NetConf solutions. This >>perpetuates non-interoperability and breaks IETF process rules. >> >>Cheers, >>- Ira, co-editor of PWG WIMS (Web-based Imaging System Mgmt Service) >> ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wims10-20050303.pdf >> >>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 >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> > > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 15 19:36:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08965 for ; Tue, 15 Mar 2005 19:36:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBMLb-0000Y8-Df for netconf-data@psg.com; Wed, 16 Mar 2005 00:25:15 +0000 Received: from [207.217.121.252] (helo=pop-a065d14.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBMLX-0000XI-96 for netconf@ops.ietf.org; Wed, 16 Mar 2005 00:25:12 +0000 Received: from h-64-105-136-163.snvacaid.dynamic.covad.net ([64.105.136.163] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DBMLW-000151-00 for netconf@ops.ietf.org; Tue, 15 Mar 2005 16:25:11 -0800 Message-ID: <000801c529be$ad290980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <008001c52999$6fe8f3c0$7f1afea9@oemcomputer> <42374473.5070405@andybierman.com> Subject: Re: NetConf over SOAP normative reference issue Date: Tue, 15 Mar 2005 16:25:33 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: ; > Sent: Tuesday, March 15, 2005 12:24 PM > Subject: Re: NetConf over SOAP normative reference issue ... > >Are you suggesting we re-cast the document in terms of SOAP 1.2, > >and drop the BEEP dependency? > > > > > what do you mean "drop the BEEP dependency"? Ira's note said there was a normative reference to RFC 3288. Randy > >>From: "McDonald, Ira" > >>To: > >>Sent: Tuesday, March 15, 2005 9:53 AM > >>Subject: NetConf over SOAP normative reference issue > >> > >>Hi, > >> > >>[Bert Wijnen asked me to pass on this comment.] > >> > >>The latest NetConf over SOAP > >>has a serious problem for advancement on the IETF "standards > >>track", to whit, these two normative references: > >> > >> [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, > >> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access > >> Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, > >> . > >> > >> [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access > >> Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", > >> RFC 3288, June 2002, . ... -- to unsubscribe send a message to netconf-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 Mar 16 11:52:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09115 for ; Wed, 16 Mar 2005 11:52:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBbbs-000N7F-Rr for netconf-data@psg.com; Wed, 16 Mar 2005 16:43:04 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBbbq-000N6i-QJ for netconf@ops.ietf.org; Wed, 16 Mar 2005 16:43:02 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2GGh1l8014471; Wed, 16 Mar 2005 08:43:01 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77CR62>; Wed, 16 Mar 2005 08:43:01 -0800 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , netconf@ops.ietf.org Subject: RE: NetConf over SOAP normative reference issue Date: Wed, 16 Mar 2005 08:42:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I'm agnostic about the use or non-use of BEEP in NetConf. But, yes I am urging you to change to SOAP/1.2 and NOT use the SOAP/1.1 mapping over BEEP defined in RFC 3288. RFC 3288 slipped through the side door somehow and got published without the IESG objecting to the RFC 3288 normative dependency on the non-standards-track SOAP/1.1 W3C Note. The IESG (or at least Bert Wijnen) is now aware of this same normative dependency (SOAP/1.1) in the NetConf over SOAP I-D. I submit this issue as a last call comment. Could someone please update the "Goals and Milestones" on the IETF main page for NetConf WG, so that outsiders could tell what's going on? 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: Tuesday, March 15, 2005 7:26 PM To: netconf@ops.ietf.org Subject: Re: NetConf over SOAP normative reference issue Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: ; > Sent: Tuesday, March 15, 2005 12:24 PM > Subject: Re: NetConf over SOAP normative reference issue ... > >Are you suggesting we re-cast the document in terms of SOAP 1.2, > >and drop the BEEP dependency? > > > > > what do you mean "drop the BEEP dependency"? Ira's note said there was a normative reference to RFC 3288. Randy > >>From: "McDonald, Ira" > >>To: > >>Sent: Tuesday, March 15, 2005 9:53 AM > >>Subject: NetConf over SOAP normative reference issue > >> > >>Hi, > >> > >>[Bert Wijnen asked me to pass on this comment.] > >> > >>The latest NetConf over SOAP > >>has a serious problem for advancement on the IETF "standards > >>track", to whit, these two normative references: > >> > >> [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, > >> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access > >> Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, > >> . > >> > >> [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access > >> Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", > >> RFC 3288, June 2002, . ... -- to 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 Mar 16 12:36:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13735 for ; Wed, 16 Mar 2005 12:36:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBcJf-0003Vd-Gg for netconf-data@psg.com; Wed, 16 Mar 2005 17:28:19 +0000 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DBcJd-0003VN-4D for netconf@ops.ietf.org; Wed, 16 Mar 2005 17:28:17 +0000 Received: from [10.18.39.60] ([68.146.204.134]) by www.icesoft.com (Kerio MailServer 6.0.6) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Wed, 16 Mar 2005 09:26:23 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v712) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69386033-71BD-4E38-9123-348CA3015737@icesoft.com> Cc: "'Randy Presuhn'" , netconf@ops.ietf.org Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: NetConf over SOAP normative reference issue Date: Wed, 16 Mar 2005 10:28:14 -0700 To: "McDonald, Ira" X-Mailer: Apple Mail (2.712) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of the original concerns about SOAP 1.2 was the lack of available implementations and the lack of compliance exhibited by SOAP 1.2 implementations. It seems that SOAP 1.2 is now implemented widely enough to insist on it. Are there any comments on the current implementation status of SOAP 1.2 vs SOAP 1.1? (Is this even open to discussion, given the standards status of SOAP 1.2 vs SOAP 1.1?) Thanks, Ted. On 16-Mar-05, at 9:42 AM, McDonald, Ira wrote: > Hi, > > I'm agnostic about the use or non-use of BEEP in NetConf. > > But, yes I am urging you to change to SOAP/1.2 and NOT use > the SOAP/1.1 mapping over BEEP defined in RFC 3288. > > RFC 3288 slipped through the side door somehow and got published > without the IESG objecting to the RFC 3288 normative dependency > on the non-standards-track SOAP/1.1 W3C Note. > > The IESG (or at least Bert Wijnen) is now aware of this same > normative dependency (SOAP/1.1) in the NetConf over SOAP I-D. > > I submit this issue as a last call comment. > > Could someone please update the "Goals and Milestones" on the > IETF main page for NetConf WG, so that outsiders could tell > what's going on? > > 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: Tuesday, March 15, 2005 7:26 PM > To: netconf@ops.ietf.org > Subject: Re: NetConf over SOAP normative reference issue > > > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: ; >> Sent: Tuesday, March 15, 2005 12:24 PM >> Subject: Re: NetConf over SOAP normative reference issue > ... >>> Are you suggesting we re-cast the document in terms of SOAP 1.2, >>> and drop the BEEP dependency? >>> >>> >> what do you mean "drop the BEEP dependency"? > > Ira's note said there was a normative reference to RFC 3288. > > Randy > >>>> From: "McDonald, Ira" >>>> To: >>>> Sent: Tuesday, March 15, 2005 9:53 AM >>>> Subject: NetConf over SOAP normative reference issue >>>> >>>> Hi, >>>> >>>> [Bert Wijnen asked me to pass on this comment.] >>>> >>>> The latest NetConf over SOAP >>>> has a serious problem for advancement on the IETF "standards >>>> track", to whit, these two normative references: >>>> >>>> [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., >>>> Mendelsohn, >>>> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object >>>> Access >>>> Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May >>>> 2000, >>>> . >>>> >>>> [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access >>>> Protocol (SOAP) in Blocks Extensible Exchange Protocol >>>> (BEEP)", >>>> RFC 3288, June 2002, . > ... > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 16 14:06:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25192 for ; Wed, 16 Mar 2005 14:06:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBdgy-000IbU-Vi for netconf-data@psg.com; Wed, 16 Mar 2005 18:56:28 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DBdgw-000Ib9-Jf for netconf@ops.ietf.org; Wed, 16 Mar 2005 18:56:26 +0000 Received: (qmail 21831 invoked by uid 78); 16 Mar 2005 18:56:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 16 Mar 2005 18:56:20 -0000 Message-ID: <42388153.3040601@andybierman.com> Date: Wed, 16 Mar 2005 10:56:19 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Goddard CC: "McDonald, Ira" , "'Randy Presuhn'" , netconf@ops.ietf.org Subject: Re: NetConf over SOAP normative reference issue References: <69386033-71BD-4E38-9123-348CA3015737@icesoft.com> In-Reply-To: <69386033-71BD-4E38-9123-348CA3015737@icesoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Goddard wrote: > > One of the original concerns about SOAP 1.2 was the lack of > available implementations and the lack of compliance exhibited > by SOAP 1.2 implementations. I don't remember this being discussed by the WG > > It seems that SOAP 1.2 is now implemented widely enough to insist > on it. Are there any comments on the current implementation status > of SOAP 1.2 vs SOAP 1.1? (Is this even open to discussion, given > the standards status of SOAP 1.2 vs SOAP 1.1?) It's an issue that needs to be addressed. Here are the differences between SOAP 1.1 and 1.2: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L4697 Are there any differences that impact NETCONF? It doesn't seem like we can remove reference [16] (RFC 3288) without removing all of section 2.6. Is there an update planned for SOAP over BEEP? > > Thanks, > Ted. Andy > > On 16-Mar-05, at 9:42 AM, McDonald, Ira wrote: > >> Hi, >> >> I'm agnostic about the use or non-use of BEEP in NetConf. >> >> But, yes I am urging you to change to SOAP/1.2 and NOT use >> the SOAP/1.1 mapping over BEEP defined in RFC 3288. >> >> RFC 3288 slipped through the side door somehow and got published >> without the IESG objecting to the RFC 3288 normative dependency >> on the non-standards-track SOAP/1.1 W3C Note. >> >> The IESG (or at least Bert Wijnen) is now aware of this same >> normative dependency (SOAP/1.1) in the NetConf over SOAP I-D. >> >> I submit this issue as a last call comment. >> >> Could someone please update the "Goals and Milestones" on the >> IETF main page for NetConf WG, so that outsiders could tell >> what's going on? >> >> 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: Tuesday, March 15, 2005 7:26 PM >> To: netconf@ops.ietf.org >> Subject: Re: NetConf over SOAP normative reference issue >> >> >> Hi - >> >>> From: "Andy Bierman" >>> To: "Randy Presuhn" >>> Cc: ; >>> Sent: Tuesday, March 15, 2005 12:24 PM >>> Subject: Re: NetConf over SOAP normative reference issue >> >> ... >> >>>> Are you suggesting we re-cast the document in terms of SOAP 1.2, >>>> and drop the BEEP dependency? >>>> >>>> >>> what do you mean "drop the BEEP dependency"? >> >> >> Ira's note said there was a normative reference to RFC 3288. >> >> Randy >> >>>>> From: "McDonald, Ira" >>>>> To: >>>>> Sent: Tuesday, March 15, 2005 9:53 AM >>>>> Subject: NetConf over SOAP normative reference issue >>>>> >>>>> Hi, >>>>> >>>>> [Bert Wijnen asked me to pass on this comment.] >>>>> >>>>> The latest NetConf over SOAP >>>>> has a serious problem for advancement on the IETF "standards >>>>> track", to whit, these two normative references: >>>>> >>>>> [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, >>>>> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object >>>>> Access >>>>> Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, >>>>> . >>>>> >>>>> [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access >>>>> Protocol (SOAP) in Blocks Extensible Exchange Protocol >>>>> (BEEP)", >>>>> RFC 3288, June 2002, . >>>> >> ... >> >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 16 17:12:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04275 for ; Wed, 16 Mar 2005 17:12:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBgbM-0003JL-O4 for netconf-data@psg.com; Wed, 16 Mar 2005 22:02:52 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBgbK-0003Ii-IO for netconf@ops.ietf.org; Wed, 16 Mar 2005 22:02:50 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2GM2Vm6000950; Wed, 16 Mar 2005 14:02:35 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77CVXX>; Wed, 16 Mar 2005 14:02:31 -0800 Message-ID: From: "McDonald, Ira" To: "'Andy Bierman'" , Ted Goddard Cc: "'Randy Presuhn'" , netconf@ops.ietf.org Subject: RE: NetConf over SOAP normative reference issue Date: Wed, 16 Mar 2005 14:02:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, Andy - thanks for that direct link to the SOAP/1.1 and SOAP/1.2 differences list in the SOAP/1.2 Primer. WG - please note that the bottom line is that a SOAP/1.1 receiver will NOT interoperate with a SOAP/1.2 sender (the serializations are different, key attributes are renamed, etc.). There may be an update planned for RFC 3288, but no I-D has been posted, so it won't be timely for NetConf. New dumb questions Does NetConf even need BEEP? Why not use a WebDAV-like binding over HTTP/1.1? 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: Andy Bierman [mailto:ietf@andybierman.com] Sent: Wednesday, March 16, 2005 1:56 PM To: Ted Goddard Cc: McDonald, Ira; 'Randy Presuhn'; netconf@ops.ietf.org Subject: Re: NetConf over SOAP normative reference issue Ted Goddard wrote: > > One of the original concerns about SOAP 1.2 was the lack of > available implementations and the lack of compliance exhibited > by SOAP 1.2 implementations. I don't remember this being discussed by the WG > > It seems that SOAP 1.2 is now implemented widely enough to insist > on it. Are there any comments on the current implementation status > of SOAP 1.2 vs SOAP 1.1? (Is this even open to discussion, given > the standards status of SOAP 1.2 vs SOAP 1.1?) It's an issue that needs to be addressed. Here are the differences between SOAP 1.1 and 1.2: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L4697 Are there any differences that impact NETCONF? It doesn't seem like we can remove reference [16] (RFC 3288) without removing all of section 2.6. Is there an update planned for SOAP over BEEP? > > Thanks, > Ted. Andy > > On 16-Mar-05, at 9:42 AM, McDonald, Ira wrote: > >> Hi, >> >> I'm agnostic about the use or non-use of BEEP in NetConf. >> >> But, yes I am urging you to change to SOAP/1.2 and NOT use >> the SOAP/1.1 mapping over BEEP defined in RFC 3288. >> >> RFC 3288 slipped through the side door somehow and got published >> without the IESG objecting to the RFC 3288 normative dependency >> on the non-standards-track SOAP/1.1 W3C Note. >> >> The IESG (or at least Bert Wijnen) is now aware of this same >> normative dependency (SOAP/1.1) in the NetConf over SOAP I-D. >> >> I submit this issue as a last call comment. >> >> Could someone please update the "Goals and Milestones" on the >> IETF main page for NetConf WG, so that outsiders could tell >> what's going on? >> >> 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: Tuesday, March 15, 2005 7:26 PM >> To: netconf@ops.ietf.org >> Subject: Re: NetConf over SOAP normative reference issue >> >> >> Hi - >> >>> From: "Andy Bierman" >>> To: "Randy Presuhn" >>> Cc: ; >>> Sent: Tuesday, March 15, 2005 12:24 PM >>> Subject: Re: NetConf over SOAP normative reference issue >> >> ... >> >>>> Are you suggesting we re-cast the document in terms of SOAP 1.2, >>>> and drop the BEEP dependency? >>>> >>>> >>> what do you mean "drop the BEEP dependency"? >> >> >> Ira's note said there was a normative reference to RFC 3288. >> >> Randy >> >>>>> From: "McDonald, Ira" >>>>> To: >>>>> Sent: Tuesday, March 15, 2005 9:53 AM >>>>> Subject: NetConf over SOAP normative reference issue >>>>> >>>>> Hi, >>>>> >>>>> [Bert Wijnen asked me to pass on this comment.] >>>>> >>>>> The latest NetConf over SOAP >>>>> has a serious problem for advancement on the IETF "standards >>>>> track", to whit, these two normative references: >>>>> >>>>> [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, >>>>> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object >>>>> Access >>>>> Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, >>>>> . >>>>> >>>>> [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access >>>>> Protocol (SOAP) in Blocks Extensible Exchange Protocol >>>>> (BEEP)", >>>>> RFC 3288, June 2002, . >>>> >> ... >> >> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 16 20:55:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25488 for ; Wed, 16 Mar 2005 20:55:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBk6K-000Kmr-5O for netconf-data@psg.com; Thu, 17 Mar 2005 01:47:04 +0000 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBk6J-000Kmf-ES for netconf@ops.ietf.org; Thu, 17 Mar 2005 01:47:03 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by borg.juniper.net with ESMTP; 16 Mar 2005 17:47:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,96,1110182400"; d="scan'208"; a="242038455:sNHT20250808" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Mar 2005 17:47:02 -0800 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: NetConf over SOAP normative reference issue Date: Wed, 16 Mar 2005 17:47:01 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D4408E0A657@photon.jnpr.net> Thread-Topic: NetConf over SOAP normative reference issue Thread-Index: AcUqgXi+curjB2LeQ/ud2HYcaiBgagAEOhEA From: "Rob Enns" To: "McDonald, Ira" , "Andy Bierman" , "Ted Goddard" Cc: "Randy Presuhn" , X-OriginalArrivalTime: 17 Mar 2005 01:47:02.0678 (UTC) FILETIME=[3754A360:01C52A93] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > New dumb questions Does NetConf even need BEEP? =20 > Why not use a WebDAV-like binding over HTTP/1.1? There was a fair bit of discussion about this. Definitely lots of good reasons to do it either way. RFC 3205 discusses some pros/cons of HTTP as a substrate, and much of the NETCONF related discussion is captured in the WG minutes and=20 mailing list archive. In the end the WG picked SSH as=20 the mandatory to implement transport, but given the interest in web services I expect to see NETCONF over SOAP/HTTP implementations as well. Rob -- to unsubscribe send a message to netconf-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 Mar 16 22:00:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00632 for ; Wed, 16 Mar 2005 22:00:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBl4B-00043D-SN for netconf-data@psg.com; Thu, 17 Mar 2005 02:48:55 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DBl47-00042p-19 for netconf@ops.ietf.org; Thu, 17 Mar 2005 02:48:51 +0000 Received: (qmail 12956 invoked by uid 78); 17 Mar 2005 02:48:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 17 Mar 2005 02:48:50 -0000 Message-ID: <4238F00B.9060405@andybierman.com> Date: Wed, 16 Mar 2005 18:48:43 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: netconf engine ID Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can anyone remember why we don't have a netconf engine ID defined, and why it isn't exchanged in the message? Is this too hard for 1.0? From an NMS POV, it would be nice to tell different netconf agents apart with something other than the transport address. Comments? 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 Mar 16 22:27:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02488 for ; Wed, 16 Mar 2005 22:27:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBlXw-0009Oh-NA for netconf-data@psg.com; Thu, 17 Mar 2005 03:19:40 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DBlXs-0009Ld-QQ for netconf@ops.ietf.org; Thu, 17 Mar 2005 03:19:36 +0000 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j2H3JX9s021817; Wed, 16 Mar 2005 19:19:33 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2H3Jfjl007079; Wed, 16 Mar 2005 19:19:41 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2H3Je0k007074; Wed, 16 Mar 2005 19:19:41 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 16 Mar 2005 19:19:40 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Andy Bierman cc: netconf@ops.ietf.org Subject: Re: netconf engine ID In-Reply-To: <4238F00B.9060405@andybierman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk HI, On the research that I've done for SNMPv3/ISMS, I've come to the belief that the SNMP engineID is just extra work. In SNMPv3, it's "only" use is for proxies. However, SNMPv3 to SNMPv3 proxy has not seen widestread usage (let me know if this is not the case). It's a pain to set up, and I don't know of any tools to help. The other use of SNMP engineID is for use in SNMPv3/USM to qualify user names. This has proved problematic, and is the motivation for the ISMS WG. So, is there a particular use that you want for a netcond engineID? Then we can try to figure out if the benefit exceeds the cost. On Wed, 16 Mar 2005, Andy Bierman wrote: > Hi, > > Can anyone remember why we don't have a netconf engine ID defined, > and why it isn't exchanged in the message? Is this too > hard for 1.0? From an NMS POV, it would be nice to tell different > netconf agents apart with something other than the transport address. > > Comments? > > 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 Wed Mar 16 23:07:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06431 for ; Wed, 16 Mar 2005 23:07:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBmAy-000Fqa-Vw for netconf-data@psg.com; Thu, 17 Mar 2005 04:00:00 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DBmAx-000Fpp-SE for netconf@ops.ietf.org; Thu, 17 Mar 2005 04:00:00 +0000 Received: (qmail 20109 invoked by uid 78); 17 Mar 2005 03:59:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 17 Mar 2005 03:59:58 -0000 Message-ID: <423900BD.3080601@andybierman.com> Date: Wed, 16 Mar 2005 19:59:57 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David T. Perkins" CC: netconf@ops.ietf.org Subject: Re: netconf engine ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David T. Perkins wrote: >HI, > >On the research that I've done for SNMPv3/ISMS, I've come to >the belief that the SNMP engineID is just extra work. In >SNMPv3, it's "only" use is for proxies. However, SNMPv3 to >SNMPv3 proxy has not seen widestread usage (let me know if >this is not the case). It's a pain to set up, and I don't >know of any tools to help. The other use of SNMP engineID >is for use in SNMPv3/USM to qualify user names. This has >proved problematic, and is the motivation for the ISMS WG. > >So, is there a particular use that you want for a >netcond engineID? Then we can try to figure out >if the benefit exceeds the cost. > > I'd like to have a standard identifier for a particular netconf agent, independent of the agent's network address. This can be deferred until the data modeling work I guess. Andy >On Wed, 16 Mar 2005, Andy Bierman wrote: > > > >>Hi, >> >>Can anyone remember why we don't have a netconf engine ID defined, >>and why it isn't exchanged in the message? Is this too >>hard for 1.0? From an NMS POV, it would be nice to tell different >>netconf agents apart with something other than the transport address. >> >>Comments? >> >>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: > > > > -- to unsubscribe send a message to netconf-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 Mar 18 00:31:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03116 for ; Fri, 18 Mar 2005 00:30:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DC9pa-000FGX-Go for netconf-data@psg.com; Fri, 18 Mar 2005 05:15:30 +0000 Received: from [168.150.236.44] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DC9pY-000FGI-Bk for netconf@ops.ietf.org; Fri, 18 Mar 2005 05:15:28 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 7020911D860; Thu, 17 Mar 2005 21:15:21 -0800 (PST) From: Wes Hardaker To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List Organization: Sparta References: <4.3.2.7.2.20050211124136.0270e4a8@fedex.cisco.com> Date: Thu, 17 Mar 2005 21:15:20 -0800 In-Reply-To: <4.3.2.7.2.20050211124136.0270e4a8@fedex.cisco.com> (Andy Bierman's message of "Fri, 11 Feb 2005 12:48:37 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,USERPASS autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Andy> I012) Wes> 7.3 example shows the use of ftp. Can we use something more secure in Wes> the example please? Andy> ** CLOSED ** Andy> No change; no suggested replacement text provided Suggested new text: Example: https://user@example.com:passphrase/configs/testbed-dec10.txt -------------------- Andy> I013) Andy> I014) Andy> I015) Wes> 7.4: #url allows a url to appear as a delete. doing remote file Wes> management using netconf is questionable at best. From a security Wes> point of view, it makes me cringe. ... Andy> ** CLOSED ** Andy> No change; no suggested replacement text provided Suggested text: Add to 8.8.5.1: If this parameter contains a URL, then it should identify a local configuration file. (this text exists for delete-config already) ---------------------- New text for the beginning of appendix B: The following XML schema is for informational purposes. It has reviewed but there is no guarantee that the schema exactly matches the definitions defined in the protocol description above. Implementations MUST NOT assume that an incoming message is free from malicious intent because it has been successfully verified against this schema. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 18 12:11:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29056 for ; Fri, 18 Mar 2005 12:11:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCKsN-0000mA-Bu for netconf-data@psg.com; Fri, 18 Mar 2005 17:03:07 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCKsL-0000lj-Lh for netconf@ops.ietf.org; Fri, 18 Mar 2005 17:03:05 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 18 Mar 2005 09:04:21 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2IH32gS027924; Fri, 18 Mar 2005 09:03:03 -0800 (PST) Received: from sberlw2k01 (sjc-vpn1-605.cisco.com [10.21.98.93]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDA78279; Fri, 18 Mar 2005 09:03:01 -0800 (PST) Message-Id: <200503181703.BDA78279@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Wes Hardaker'" , "'Andy Bierman'" Cc: Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Fri, 18 Mar 2005 09:03:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: Thread-Index: AcUreeowptb7xxUNR1epcnY4IfPYXAAYWPrg X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ---------------------- > > New text for the beginning of appendix B: > > The following XML schema is for informational purposes. It > has reviewed but there is no guarantee that the schema > exactly matches the definitions defined in the protocol > description above. > Implementations MUST NOT assume that an incoming message is > free from malicious intent because it has been successfully > verified against this schema. > Are you saying that we have a formal language description of the syntax of the protocol messages, but that is there just for information? The real definition of the syntax is in the narrative text? It seems to me that this is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there just for information and the real description of the MIB is in the text? The normative reference for message syntax should be the schema, and the text should be there to describe the schema, and to explain things that are not expressed in the schema such as the sequence of messages, or additional constrains. -steve -- to unsubscribe send a message to netconf-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 Mar 18 14:02:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11255 for ; Fri, 18 Mar 2005 14:02:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCMcr-000Dzp-Co for netconf-data@psg.com; Fri, 18 Mar 2005 18:55:13 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCMcp-000Dyq-E1 for netconf@ops.ietf.org; Fri, 18 Mar 2005 18:55:11 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2IIt4cQ022364; Fri, 18 Mar 2005 10:55:04 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77DRKF>; Fri, 18 Mar 2005 10:55:04 -0800 Message-ID: From: "McDonald, Ira" To: "'sberl@cisco.com'" , "'Wes Hardaker'" , "'Andy Bierman'" Cc: netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Fri, 18 Mar 2005 10:54:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Steve, I agree that the XML Schema should be normative and that the body text should say that a received message that does not parse _perfectly_ under the XML Schema is corrupt and should be subject to some appropriate error handling (but never quietly accepted). Reconfiguration of network systems is not a use case for "close enough for rock and roll". 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 Steven Berl (sberl) Sent: Friday, March 18, 2005 12:03 PM To: 'Wes Hardaker'; 'Andy Bierman' Cc: netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List > ---------------------- > > New text for the beginning of appendix B: > > The following XML schema is for informational purposes. It > has reviewed but there is no guarantee that the schema > exactly matches the definitions defined in the protocol > description above. > Implementations MUST NOT assume that an incoming message is > free from malicious intent because it has been successfully > verified against this schema. > Are you saying that we have a formal language description of the syntax of the protocol messages, but that is there just for information? The real definition of the syntax is in the narrative text? It seems to me that this is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there just for information and the real description of the MIB is in the text? The normative reference for message syntax should be the schema, and the text should be there to describe the schema, and to explain things that are not expressed in the schema such as the sequence of messages, or additional constrains. -steve -- to 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 Mar 18 14:28:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13842 for ; Fri, 18 Mar 2005 14:28:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCN43-000IAZ-TA for netconf-data@psg.com; Fri, 18 Mar 2005 19:23:19 +0000 Received: from [207.217.121.170] (helo=pop-a065b10.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCN42-000I9O-08 for netconf@ops.ietf.org; Fri, 18 Mar 2005 19:23:18 +0000 Received: from h-64-105-136-105.snvacaid.dynamic.covad.net ([64.105.136.105] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCN3z-0004ZY-00 for netconf@ops.ietf.org; Fri, 18 Mar 2005 11:23:16 -0800 Message-ID: <005501c52bf0$0373e700$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: Proposed Resolution to PROT I-D Issues List Date: Fri, 18 Mar 2005 11:23:49 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "McDonald, Ira" > To: ; "'Wes Hardaker'" ; "'Andy Bierman'" > Cc: > Sent: Friday, March 18, 2005 10:54 AM > Subject: RE: Proposed Resolution to PROT I-D Issues List ... > I agree that the XML Schema should be normative and that > the body text should say that a received message that does > not parse _perfectly_ under the XML Schema is corrupt and > should be subject to some appropriate error handling (but > never quietly accepted). I'm inclined to agree, but we should be mindful of http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt which gives primacy to the English text. > Reconfiguration of network systems is not a use case for > "close enough for rock and roll". ... Agreed, and let's not lose sight of the point of the passage Steve Berl cited: ... > > Implementations MUST NOT assume that an incoming message is > > free from malicious intent because it has been successfully > > verified against this schema. ... Simply passing XML validation does not guarantee that the message is benign. 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 Mar 18 14:41:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15721 for ; Fri, 18 Mar 2005 14:41:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCNFy-000Jfw-8I for netconf-data@psg.com; Fri, 18 Mar 2005 19:35:38 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCNFs-000Jer-HA for netconf@ops.ietf.org; Fri, 18 Mar 2005 19:35:37 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2IJZQpg024561; Fri, 18 Mar 2005 11:35:26 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77DRZP>; Fri, 18 Mar 2005 11:35:26 -0800 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Fri, 18 Mar 2005 11:35:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Randy, I'm aware of that bizarre policy of the IESG on the primacy of the English language text. It's wrong and indefensible. 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, March 18, 2005 2:24 PM To: netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List Hi - > From: "McDonald, Ira" > To: ; "'Wes Hardaker'" ; "'Andy Bierman'" > Cc: > Sent: Friday, March 18, 2005 10:54 AM > Subject: RE: Proposed Resolution to PROT I-D Issues List ... > I agree that the XML Schema should be normative and that > the body text should say that a received message that does > not parse _perfectly_ under the XML Schema is corrupt and > should be subject to some appropriate error handling (but > never quietly accepted). I'm inclined to agree, but we should be mindful of http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt which gives primacy to the English text. > Reconfiguration of network systems is not a use case for > "close enough for rock and roll". ... Agreed, and let's not lose sight of the point of the passage Steve Berl cited: ... > > Implementations MUST NOT assume that an incoming message is > > free from malicious intent because it has been successfully > > verified against this schema. ... Simply passing XML validation does not guarantee that the message is benign. 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: -- to unsubscribe send a message to netconf-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 Mar 18 15:34:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23060 for ; Fri, 18 Mar 2005 15:34:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCO6D-0000cW-1d for netconf-data@psg.com; Fri, 18 Mar 2005 20:29:37 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DCO6B-0000cK-Tu for netconf@ops.ietf.org; Fri, 18 Mar 2005 20:29:36 +0000 Received: (qmail 18270 invoked by uid 78); 18 Mar 2005 20:29:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 18 Mar 2005 20:29:35 -0000 Message-ID: <423B3A2B.9030208@andybierman.com> Date: Fri, 18 Mar 2005 12:29:31 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sberl@cisco.com CC: "'Wes Hardaker'" , "'Andy Bierman'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <200503181703.BDA78279@mira-sjc5-b.cisco.com> In-Reply-To: <200503181703.BDA78279@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steven Berl (sberl) wrote: > > > > > >>---------------------- >> >>New text for the beginning of appendix B: >> >>The following XML schema is for informational purposes. It >>has reviewed but there is no guarantee that the schema >>exactly matches the definitions defined in the protocol >>description above. >>Implementations MUST NOT assume that an incoming message is >>free from malicious intent because it has been successfully >>verified against this schema. >> >> I think we should make the text normative and the XSD as correct as possible, but not intended to override the text. The exact standard netconf XSD that an agent should accept is different depending on the exact set of capability values supported by that agent for a particular session. The XSD represents a superset of all base + standard capability variants. I think this is good enough. Andy >> >> > >Are you saying that we have a formal language description of the syntax of >the protocol messages, but that is there just for information? The real >definition of the syntax is in the narrative text? It seems to me that this >is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there >just for information and the real description of the MIB is in the text? The >normative reference for message syntax should be the schema, and the text >should be there to describe the schema, and to explain things that are not >expressed in the schema such as the sequence of messages, or additional >constrains. > >-steve > >-- >to 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 Mar 18 15:46:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26372 for ; Fri, 18 Mar 2005 15:46:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCOHI-0001ss-Oz for netconf-data@psg.com; Fri, 18 Mar 2005 20:41:04 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCOHG-0001sQ-SN for netconf@ops.ietf.org; Fri, 18 Mar 2005 20:41:02 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2005 12:40:59 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2IKerDr011538; Fri, 18 Mar 2005 12:40:54 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZF08079; Fri, 18 Mar 2005 12:40:55 -0800 (PST) Message-ID: <423B3CD7.3020406@cisco.com> Date: Fri, 18 Mar 2005 13:40:55 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman CC: sberl@cisco.com, "'Wes Hardaker'" , "'Andy Bierman'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <200503181703.BDA78279@mira-sjc5-b.cisco.com> <423B3A2B.9030208@andybierman.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit in-line Hector Andy Bierman wrote: > Steven Berl (sberl) wrote: > >> >> >> >> >> >>> ---------------------- >>> >>> New text for the beginning of appendix B: >>> >>> The following XML schema is for informational purposes. It has >>> reviewed but there is no guarantee that the schema exactly matches >>> the definitions defined in the protocol description above. >>> Implementations MUST NOT assume that an incoming message is free >>> from malicious intent because it has been successfully verified >>> against this schema. >>> >> > I think we should make the text normative and the XSD as correct as > possible, > but not intended to override the text. The exact standard netconf XSD > that > an agent should accept is different depending on the exact set of > capability > values supported by that agent for a particular session. > > The XSD represents a superset of all base + standard capability variants. > I think this is good enough. Why couldn't the operation defintions in the XSDs be normative as well? Seems this is a way to help with interoperability. I agree that "The XSD represents a superset of all base + standard capability variants" and it is an implementation decision as to what capabilities are supported/implemented but the definitions themselves should be normative. I guess I don't understand the objection to making the schemas normative. > > > > Andy > >>> >> >> >> Are you saying that we have a formal language description of the >> syntax of >> the protocol messages, but that is there just for information? The real >> definition of the syntax is in the narrative text? It seems to me >> that this >> is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there >> just for information and the real description of the MIB is in the >> text? The >> normative reference for message syntax should be the schema, and the >> text >> should be there to describe the schema, and to explain things that >> are not >> expressed in the schema such as the sequence of messages, or additional >> constrains. >> >> -steve >> >> -- >> to 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: > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 -- to unsubscribe send a message to netconf-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 Mar 18 17:01:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13513 for ; Fri, 18 Mar 2005 17:01:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCPPu-0009wJ-Ax for netconf-data@psg.com; Fri, 18 Mar 2005 21:54:02 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCPPs-0009vM-9A for netconf@ops.ietf.org; Fri, 18 Mar 2005 21:54:00 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2ILqitK001009; Fri, 18 Mar 2005 13:52:44 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77DT1Y>; Fri, 18 Mar 2005 13:52:45 -0800 Message-ID: From: "McDonald, Ira" To: "'Hector Trevino'" , Andy Bierman Cc: sberl@cisco.com, "'Wes Hardaker'" , "'Andy Bierman'" , netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Fri, 18 Mar 2005 13:52:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, Agreed - XSD is not informal like pseudo-code (which is an eye of the beholder term). XSD is a formal language, just like the ASN.1 we all darn well depend on in MIBs (which ASN.1 _does_ override any error in descriptive text in the MIB body or preface - an ASN.1 type definition is a hard mathematical fact). Conformance to an XSD is not sufficient to prove that a message is valid (in most cases) or that it is not malicious. But non-conformance to a well-written XSD should always be treated as a mandatory failure in a protocol. 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 Hector Trevino Sent: Friday, March 18, 2005 3:41 PM To: Andy Bierman Cc: sberl@cisco.com; 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List in-line Hector Andy Bierman wrote: > Steven Berl (sberl) wrote: > >> >> >> >> >> >>> ---------------------- >>> >>> New text for the beginning of appendix B: >>> >>> The following XML schema is for informational purposes. It has >>> reviewed but there is no guarantee that the schema exactly matches >>> the definitions defined in the protocol description above. >>> Implementations MUST NOT assume that an incoming message is free >>> from malicious intent because it has been successfully verified >>> against this schema. >>> >> > I think we should make the text normative and the XSD as correct as > possible, > but not intended to override the text. The exact standard netconf XSD > that > an agent should accept is different depending on the exact set of > capability > values supported by that agent for a particular session. > > The XSD represents a superset of all base + standard capability variants. > I think this is good enough. Why couldn't the operation defintions in the XSDs be normative as well? Seems this is a way to help with interoperability. I agree that "The XSD represents a superset of all base + standard capability variants" and it is an implementation decision as to what capabilities are supported/implemented but the definitions themselves should be normative. I guess I don't understand the objection to making the schemas normative. > > > > Andy > >>> >> >> >> Are you saying that we have a formal language description of the >> syntax of >> the protocol messages, but that is there just for information? The real >> definition of the syntax is in the narrative text? It seems to me >> that this >> is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there >> just for information and the real description of the MIB is in the >> text? The >> normative reference for message syntax should be the schema, and the >> text >> should be there to describe the schema, and to explain things that >> are not >> expressed in the schema such as the sequence of messages, or additional >> constrains. >> >> -steve >> >> -- >> to 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: > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 -- to 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 Mar 18 17:49:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18077 for ; Fri, 18 Mar 2005 17:49:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCQCf-000Ew7-Qy for netconf-data@psg.com; Fri, 18 Mar 2005 22:44:25 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCQCe-000Evl-0d for netconf@ops.ietf.org; Fri, 18 Mar 2005 22:44:24 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j2IMiLDg028557 for ; Fri, 18 Mar 2005 16:44:22 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1Z0M7FTN>; Fri, 18 Mar 2005 23:44:20 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15506AD7601@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: NetConf over SOAP normative reference issue Date: Fri, 18 Mar 2005 23:44:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk FYI, RFC3288 authors comments. Bert -----Original Message----- From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Thursday, March 17, 2005 00:00 To: Wijnen, Bert (Bert) Cc: 'eamon.otuathail@clipcode.com'; Scott Hollenbeck (E-mail) Subject: Re: NetConf over SOAP normative reference issue On Mar 16, 2005, at 13:54, Wijnen, Bert (Bert) wrote: > RFC3288 authors/editors, may I ask: > > What is the opinion of the authors of RFC3288 on the below? > > Is it time to do another revision of the RFC and reference the > new version of SOAP? i think it would be fine to use 1.2 in both 3288bis and in netconf. there appears to be sufficient market penetration of 1.2. it may be worthwhile to have some kind of version indicator somewhere so that we don't have someone running their mouths three years from now about not supporting 1.x /mtr -- to unsubscribe send a message to netconf-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 Mar 21 12:55:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00783 for ; Mon, 21 Mar 2005 12:55:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDQsR-000ORg-CZ for netconf-data@psg.com; Mon, 21 Mar 2005 17:39:43 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DDQsL-000OQF-V8 for netconf@ops.ietf.org; Mon, 21 Mar 2005 17:39:38 +0000 Received: (qmail 19254 invoked by uid 78); 21 Mar 2005 17:39:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 21 Mar 2005 17:39:31 -0000 Message-ID: <423F06D2.8000808@andybierman.com> Date: Mon, 21 Mar 2005 09:39:30 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" CC: "'Hector Trevino'" , sberl@cisco.com, "'Wes Hardaker'" , "'Andy Bierman'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: >Hi, > >Agreed - XSD is not informal like pseudo-code (which is an eye >of the beholder term). > >XSD is a formal language, just like the ASN.1 we all darn well >depend on in MIBs (which ASN.1 _does_ override any error in >descriptive text in the MIB body or preface - an ASN.1 type >definition is a hard mathematical fact). > >Conformance to an XSD is not sufficient to prove that a message >is valid (in most cases) or that it is not malicious. But >non-conformance to a well-written XSD should always be treated >as a mandatory failure in a protocol. > > The difference here is the use of capabilities, not ASN.1 vs. XSD. I don't mind if the NETCONF XSD is normative, as long as it's understood that XSD is not expressive enough to fully describe the precise set of XML instance documents that a NETCONF agent will accept, and the text is assumed to be the authoritative definition if there are conflicts discovered in the future. >Cheers, >- Ira > > Andy >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 Hector Trevino >Sent: Friday, March 18, 2005 3:41 PM >To: Andy Bierman >Cc: sberl@cisco.com; 'Wes Hardaker'; 'Andy Bierman'; >netconf@ops.ietf.org >Subject: Re: Proposed Resolution to PROT I-D Issues List > > > > >in-line >Hector > >Andy Bierman wrote: > > > >>Steven Berl (sberl) wrote: >> >> >> >>> >>> >>> >>> >>> >>> >>>>---------------------- >>>> >>>>New text for the beginning of appendix B: >>>> >>>>The following XML schema is for informational purposes. It has >>>>reviewed but there is no guarantee that the schema exactly matches >>>>the definitions defined in the protocol description above. >>>>Implementations MUST NOT assume that an incoming message is free >>>>from malicious intent because it has been successfully verified >>>>against this schema. >>>> >>>> >>>> >>I think we should make the text normative and the XSD as correct as >>possible, >>but not intended to override the text. The exact standard netconf XSD >>that >>an agent should accept is different depending on the exact set of >>capability >>values supported by that agent for a particular session. >> >>The XSD represents a superset of all base + standard capability variants. >>I think this is good enough. >> >> > >Why couldn't the operation defintions in the XSDs be normative as well? >Seems this is a way to help with interoperability. >I agree that "The XSD represents a superset of all base + standard >capability variants" and it is an implementation decision as to what >capabilities are supported/implemented but the definitions themselves >should be normative. I guess I don't understand the objection to making >the schemas normative. > > > >> >>Andy >> >> >> >>>> >>>> >>>> >>>Are you saying that we have a formal language description of the >>>syntax of >>>the protocol messages, but that is there just for information? The real >>>definition of the syntax is in the narrative text? It seems to me >>>that this >>>is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there >>>just for information and the real description of the MIB is in the >>>text? The >>>normative reference for message syntax should be the schema, and the >>>text >>>should be there to describe the schema, and to explain things that >>>are not >>>expressed in the schema such as the sequence of messages, or additional >>>constrains. >>> >>>-steve >>> >>>-- >>>to 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 Mar 21 13:01:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01345 for ; Mon, 21 Mar 2005 13:01:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDR8P-0003jt-TB for netconf-data@psg.com; Mon, 21 Mar 2005 17:56:13 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDR8H-0003gx-G4 for netconf@ops.ietf.org; Mon, 21 Mar 2005 17:56:05 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 21 Mar 2005 09:56:05 -0800 X-IronPort-AV: i="3.91,107,1110182400"; d="scan'208,217"; a="621462173:sNHT86673918" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2LHtx3U029211; Mon, 21 Mar 2005 09:56:02 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZG28012; Mon, 21 Mar 2005 09:55:59 -0800 (PST) Message-ID: <423F0AAF.20602@cisco.com> Date: Mon, 21 Mar 2005 10:55:59 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" CC: Andy Bierman , sberl@cisco.com, "'Wes Hardaker'" , "'Andy Bierman'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: Content-Type: multipart/alternative; boundary="------------020006030304070403010508" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --------------020006030304070403010508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, thanks for the response. in-line Hector McDonald, Ira wrote: >Hi, > >Agreed - XSD is not informal like pseudo-code (which is an eye >of the beholder term). > >XSD is a formal language, just like the ASN.1 we all darn well >depend on in MIBs (which ASN.1 _does_ override any error in >descriptive text in the MIB body or preface - an ASN.1 type >definition is a hard mathematical fact). > right & that's what I would've thought the messages defined in netconf should be as well. > >Conformance to an XSD is not sufficient to prove that a message >is valid (in most cases) or that it is not malicious. > I agree that with he current definitions this is the case but seems to me they could be tighten up so that they enforce validity of the message (syntactically). Or is there something else I'm missing here? >But >non-conformance to a well-written XSD should always be treated >as a mandatory failure in a protocol. > Agree > >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 Hector Trevino >Sent: Friday, March 18, 2005 3:41 PM >To: Andy Bierman >Cc: sberl@cisco.com; 'Wes Hardaker'; 'Andy Bierman'; >netconf@ops.ietf.org >Subject: Re: Proposed Resolution to PROT I-D Issues List > > > > >in-line >Hector > >Andy Bierman wrote: > > > >>Steven Berl (sberl) wrote: >> >> >> >>> >>> >>> >>> >>> >>> >>>>---------------------- >>>> >>>>New text for the beginning of appendix B: >>>> >>>>The following XML schema is for informational purposes. It has >>>>reviewed but there is no guarantee that the schema exactly matches >>>>the definitions defined in the protocol description above. >>>>Implementations MUST NOT assume that an incoming message is free >>>>from malicious intent because it has been successfully verified >>>>against this schema. >>>> >>>> >>>> >>I think we should make the text normative and the XSD as correct as >>possible, >>but not intended to override the text. The exact standard netconf XSD >>that >>an agent should accept is different depending on the exact set of >>capability >>values supported by that agent for a particular session. >> >>The XSD represents a superset of all base + standard capability variants. >>I think this is good enough. >> >> > >Why couldn't the operation defintions in the XSDs be normative as well? >Seems this is a way to help with interoperability. >I agree that "The XSD represents a superset of all base + standard >capability variants" and it is an implementation decision as to what >capabilities are supported/implemented but the definitions themselves >should be normative. I guess I don't understand the objection to making >the schemas normative. > > > >> >>Andy >> >> >> >>>> >>>> >>>> >>>Are you saying that we have a formal language description of the >>>syntax of >>>the protocol messages, but that is there just for information? The real >>>definition of the syntax is in the narrative text? It seems to me >>>that this >>>is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there >>>just for information and the real description of the MIB is in the >>>text? The >>>normative reference for message syntax should be the schema, and the >>>text >>>should be there to describe the schema, and to explain things that >>>are not >>>expressed in the schema such as the sequence of messages, or additional >>>constrains. >>> >>>-steve >>> >>>-- >>>to 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: >> >> >> > > > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 --------------020006030304070403010508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi, thanks for the response.
in-line
Hector


McDonald, Ira wrote:
Hi,

Agreed - XSD is not informal like pseudo-code (which is an eye 
of the beholder term).  

XSD is a formal language, just like the ASN.1 we all darn well 
depend on in MIBs (which ASN.1 _does_ override any error in 
descriptive text in the MIB body or preface - an ASN.1 type
definition is a hard mathematical fact).
right & that's what I would've thought the messages defined in netconf should be as well. 

Conformance to an XSD is not sufficient to prove that a message
is valid (in most cases) or that it is not malicious.
 I agree that with he current definitions this is the case but seems to me they could be tighten up so that they enforce validity of the message (syntactically).
Or is there something else I'm missing here?
But 
non-conformance to a well-written XSD should always be treated 
as a mandatory failure in a protocol.
Agree

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 Hector Trevino
Sent: Friday, March 18, 2005 3:41 PM
To: Andy Bierman
Cc: sberl@cisco.com; 'Wes Hardaker'; 'Andy Bierman';
netconf@ops.ietf.org
Subject: Re: Proposed Resolution to PROT I-D Issues List




in-line
Hector

Andy Bierman wrote:

  
Steven Berl (sberl) wrote:

    
<snip>

 

      
----------------------

New text for the beginning of appendix B:

The following XML schema is for informational purposes.  It has 
reviewed but there is no guarantee that the schema exactly matches 
the definitions defined in the protocol description above.
Implementations MUST NOT assume that an incoming message is free 
from malicious intent because it has been successfully verified 
against this schema.
  
        
I think we should make the text normative and the XSD as correct as 
possible,
but not intended to override the text.  The exact standard netconf XSD 
that
an agent should accept is different depending on the exact set of 
capability
values supported by that agent for a particular session.

The XSD represents a superset of all base + standard capability variants.
I think this is good enough. 
    

Why couldn't the operation defintions in the XSDs be normative as well? 
Seems this is a way to help with interoperability.
I agree that "The XSD represents a superset of all base + standard 
capability variants" and it is an implementation decision as to what 
capabilities are supported/implemented but the definitions themselves 
should be normative. I guess I don't understand the objection to making 
the schemas normative.

  

Andy

    
  
        
Are you saying that we have a formal language description of the 
syntax of
the protocol messages, but that is there just for information? The real
definition of the syntax is in the narrative text? It seems to me 
that this
is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there
just for information and the real description of the MIB is in the 
text? The
normative reference for message syntax should be the schema, and the 
text
should be there to describe the schema, and to explain things that 
are not
expressed in the schema such as the sequence of messages, or additional
constrains.

-steve

-- 
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


 

      
-- 
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

    

  

-- 
Hector Trevino
Network Management Technology Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite 400                      
9155 E. Nichols Ave     Fax:    720-875-3014
Englewood, CO             E-mail: htrevino@cisco.com
80112

--------------020006030304070403010508-- -- to unsubscribe send a message to netconf-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 Mar 21 13:07:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01830 for ; Mon, 21 Mar 2005 13:07:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDRBn-00050y-JU for netconf-data@psg.com; Mon, 21 Mar 2005 17:59:43 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDRBm-00050N-6J for netconf@ops.ietf.org; Mon, 21 Mar 2005 17:59:42 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2005 09:59:42 -0800 X-IronPort-AV: i="3.91,107,1110182400"; d="scan'208"; a="238309682:sNHT29477316" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2LHxdZV028945; Mon, 21 Mar 2005 09:59:39 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZG28398; Mon, 21 Mar 2005 09:59:38 -0800 (PST) Message-ID: <423F0B8A.1060104@cisco.com> Date: Mon, 21 Mar 2005 10:59:38 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman CC: "McDonald, Ira" , sberl@cisco.com, "'Wes Hardaker'" , "'Andy Bierman'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <423F06D2.8000808@andybierman.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, in-line Hector Andy Bierman wrote: > McDonald, Ira wrote: > >> Hi, >> >> Agreed - XSD is not informal like pseudo-code (which is an eye of the >> beholder term). >> XSD is a formal language, just like the ASN.1 we all darn well depend >> on in MIBs (which ASN.1 _does_ override any error in descriptive text >> in the MIB body or preface - an ASN.1 type >> definition is a hard mathematical fact). >> >> Conformance to an XSD is not sufficient to prove that a message >> is valid (in most cases) or that it is not malicious. But >> non-conformance to a well-written XSD should always be treated as a >> mandatory failure in a protocol. >> >> > The difference here is the use of capabilities, not ASN.1 vs. XSD. I > don't mind if the NETCONF XSD is normative, as long as it's understood > that XSD is not expressive enough to fully describe the precise set of > XML > instance documents that a NETCONF agent will accept, and the text is > assumed > to be the authoritative definition if there are conflicts discovered > in the future. If I compare the netconf capabilities to the old CMIS functional units... they are the same type of approach. That is, some implementation either support or not the functionality above an beyond the required base set. Determination of whether or not & which ones of these bonus capabilities/functions are supported is negotiated/learned at session establishment and it is not tied to the syntactical defintion of the messages. > > >> Cheers, >> - Ira >> >> > Andy > >> 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 Hector Trevino >> Sent: Friday, March 18, 2005 3:41 PM >> To: Andy Bierman >> Cc: sberl@cisco.com; 'Wes Hardaker'; 'Andy Bierman'; >> netconf@ops.ietf.org >> Subject: Re: Proposed Resolution to PROT I-D Issues List >> >> >> >> >> in-line >> Hector >> >> Andy Bierman wrote: >> >> >> >>> Steven Berl (sberl) wrote: >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> ---------------------- >>>>> >>>>> New text for the beginning of appendix B: >>>>> >>>>> The following XML schema is for informational purposes. It has >>>>> reviewed but there is no guarantee that the schema exactly matches >>>>> the definitions defined in the protocol description above. >>>>> Implementations MUST NOT assume that an incoming message is free >>>>> from malicious intent because it has been successfully verified >>>>> against this schema. >>>>> >>>>> >>>> >>> I think we should make the text normative and the XSD as correct as >>> possible, >>> but not intended to override the text. The exact standard netconf >>> XSD that >>> an agent should accept is different depending on the exact set of >>> capability >>> values supported by that agent for a particular session. >>> >>> The XSD represents a superset of all base + standard capability >>> variants. >>> I think this is good enough. >> >> >> Why couldn't the operation defintions in the XSDs be normative as >> well? Seems this is a way to help with interoperability. >> I agree that "The XSD represents a superset of all base + standard >> capability variants" and it is an implementation decision as to what >> capabilities are supported/implemented but the definitions themselves >> should be normative. I guess I don't understand the objection to >> making the schemas normative. >> >> >> >>> >>> Andy >>> >>> >>> >>>>> >>>>> >>>> >>>> Are you saying that we have a formal language description of the >>>> syntax of >>>> the protocol messages, but that is there just for information? The >>>> real >>>> definition of the syntax is in the narrative text? It seems to me >>>> that this >>>> is kind of backwards. Is this the way that MIBs work? Is the ASN.1 >>>> there >>>> just for information and the real description of the MIB is in the >>>> text? The >>>> normative reference for message syntax should be the schema, and >>>> the text >>>> should be there to describe the schema, and to explain things that >>>> are not >>>> expressed in the schema such as the sequence of messages, or >>>> additional >>>> constrains. >>>> >>>> -steve >>>> >>>> -- >>>> to 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: >>> >>> >> >> >> >> > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 -- to unsubscribe send a message to netconf-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 Mar 21 15:22:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14238 for ; Mon, 21 Mar 2005 15:22:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDTIK-0009ZE-Ff for netconf-data@psg.com; Mon, 21 Mar 2005 20:14:36 +0000 Received: from [207.217.121.249] (helo=pop-a065d05.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDTII-0009YN-Hr for netconf@ops.ietf.org; Mon, 21 Mar 2005 20:14:34 +0000 Received: from h-68-166-189-165.snvacaid.dynamic.covad.net ([68.166.189.165] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DDTIH-0003GY-00 for netconf@ops.ietf.org; Mon, 21 Mar 2005 12:14:33 -0800 Message-ID: <005701c52e52$b1e380c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <423F0AAF.20602@cisco.com> Subject: Re: Proposed Resolution to PROT I-D Issues List Date: Mon, 21 Mar 2005 12:15:15 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Hector Trevino" > To: "McDonald, Ira" > Cc: "Andy Bierman" ; ; "'Wes Hardaker'" ; "'Andy Bierman'" ; > Sent: Monday, March 21, 2005 9:55 AM > Subject: Re: Proposed Resolution to PROT I-D Issues List ... > I agree that with he current definitions this is the case but seems to > me they could be tighten up so that they enforce validity of the message > (syntactically). > Or is there something else I'm missing here? ... The point is that there is more to a protocol than syntax. There are constraints on the validity of a message that cannot be enforced by syntactic means alone. 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 Mon Mar 21 15:37:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16118 for ; Mon, 21 Mar 2005 15:37:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDTYY-000DpL-LX for netconf-data@psg.com; Mon, 21 Mar 2005 20:31:22 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDTYW-000DoW-Lo for netconf@ops.ietf.org; Mon, 21 Mar 2005 20:31:20 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2005 12:31:20 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2LKVIgS016618; Mon, 21 Mar 2005 12:31:18 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZG50007; Mon, 21 Mar 2005 12:31:17 -0800 (PST) Message-ID: <423F2F15.4020306@cisco.com> Date: Mon, 21 Mar 2005 13:31:17 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <423F0AAF.20602@cisco.com> <005701c52e52$b1e380c0$7f1afea9@oemcomputer> Content-Type: multipart/alternative; boundary="------------060605080505010100010106" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --------------060605080505010100010106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randy Presuhn wrote: >Hi - > > > >>From: "Hector Trevino" >>To: "McDonald, Ira" >>Cc: "Andy Bierman" ; ; "'Wes Hardaker'" ; "'Andy Bierman'" >> >> >; > > >>Sent: Monday, March 21, 2005 9:55 AM >>Subject: Re: Proposed Resolution to PROT I-D Issues List >> >> >... > > >> I agree that with he current definitions this is the case but seems to >>me they could be tighten up so that they enforce validity of the message >>(syntactically). >>Or is there something else I'm missing here? >> >> >... > >The point is that there is more to a protocol than syntax. >There are constraints on the validity of a message that >cannot be enforced by syntactic means alone. > Right. All I was asking for is to tighthen up the definitions to enforce syntax - at least that's what I tried to say -. > >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: > > > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 --------------060605080505010100010106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Randy Presuhn wrote:
Hi -

  
From: "Hector Trevino" <htrevino@cisco.com>
To: "McDonald, Ira" <imcdonald@sharplabs.com>
Cc: "Andy Bierman" <ietf@andybierman.com>; <sberl@cisco.com>; "'Wes Hardaker'" <wjhns1@hardakers.net>; "'Andy Bierman'"
    
<abierman@cisco.com>; <netconf@ops.ietf.org>
  
Sent: Monday, March 21, 2005 9:55 AM
Subject: Re: Proposed Resolution to PROT I-D Issues List
    
...
  
 I agree that with he current definitions this is the case but seems to
me they could be tighten up so that they enforce validity of the message
(syntactically).
Or is there something else I'm missing here?
    
...

The point is that there is more to a protocol than syntax.
There are constraints on the validity of a message that
cannot be enforced by syntactic means alone.
Right. All I was asking for is to tighthen up the definitions to enforce syntax - at least that's what I tried to say -. 

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: <http://ops.ietf.org/lists/netconf/>

  

-- 
Hector Trevino
Network Management Technology Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite 400                      
9155 E. Nichols Ave     Fax:    720-875-3014
Englewood, CO             E-mail: htrevino@cisco.com
80112

--------------060605080505010100010106-- -- to unsubscribe send a message to netconf-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 Mar 21 17:08:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01975 for ; Mon, 21 Mar 2005 17:08:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDUwS-0009q3-OB for netconf-data@psg.com; Mon, 21 Mar 2005 22:00:08 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDUwQ-0009pO-HB for netconf@ops.ietf.org; Mon, 21 Mar 2005 22:00:06 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 47D6911D89C; Mon, 21 Mar 2005 14:00:00 -0800 (PST) From: Wes Hardaker To: Cc: "'Wes Hardaker'" , "'Andy Bierman'" , Subject: Re: Proposed Resolution to PROT I-D Issues List Organization: Sparta References: <200503181703.BDA78279@mira-sjc5-b.cisco.com> Date: Mon, 21 Mar 2005 13:59:59 -0800 In-Reply-To: <200503181703.BDA78279@mira-sjc5-b.cisco.com> (Steven Berl's message of "Fri, 18 Mar 2005 09:03:01 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)" said: Steven> Are you saying that we have a formal language description of Steven> the syntax of the protocol messages, but that is there just Steven> for information? My only intent was to state that it hasn't been proven to be perfect, and thus implementers should not rely on it as a check that an incoming packet is indeed perfect. The problem I've seen with XML applications is that many of them pass an incoming packet to a validator (which is merely validating the XML, not the data within) and then doesn't implement its own sanity error checking afterward. Thus, I've actually seen many security problems in XML applications because they assume that the packet contains everything it needs in the exact form it needs when in fact it may not. Andy is right, however, that an XSD probably couldn't be written which meet every implementations requirements. If you're going to make it normative, I don't think it should go into the appendix as it is currently. (If memory serves, appendices in RFCs are supposed to be normative). -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 21 18:12:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09780 for ; Mon, 21 Mar 2005 18:12:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDVyX-0000sN-W6 for netconf-data@psg.com; Mon, 21 Mar 2005 23:06:21 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDVyV-0000pz-H7 for netconf@ops.ietf.org; Mon, 21 Mar 2005 23:06:19 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2LN6Fg1004532; Mon, 21 Mar 2005 15:06:15 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B771QPN>; Mon, 21 Mar 2005 15:06:15 -0800 Message-ID: From: "McDonald, Ira" To: "'Wes Hardaker'" , sberl@cisco.com Cc: "'Andy Bierman'" , netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Mon, 21 Mar 2005 15:06:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I've been having a long, fruitless offline discussion with Joel Halpern about this. The results may be summarized as follows: (1) The IESG policy is that the plaintext English is always normative. (2) The IESG policy does NOT allow an appendix of XSD (or any other relatively formal language) to override the plaintext English, because then _parts_ of plaintext English sentences or paragraphs might become invalid. I'm strongly opposed to this logic, because it implies that an RFC should not include any formal language appendices, since they're to be ignored anyway. Analogy - In English and US contract law, if an illegal or invalid statement is later found, then the clause or the subclause is invalid, but the rest of the contract remains legally valid. I suggest deleting all XSD from Appendices and references. It won't do you any good anyway. And changing the IESG policy is just hopeless. Discouraged, - 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 Wes Hardaker Sent: Monday, March 21, 2005 5:00 PM To: sberl@cisco.com Cc: 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List >>>>> On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)" said: Steven> Are you saying that we have a formal language description of Steven> the syntax of the protocol messages, but that is there just Steven> for information? My only intent was to state that it hasn't been proven to be perfect, and thus implementers should not rely on it as a check that an incoming packet is indeed perfect. The problem I've seen with XML applications is that many of them pass an incoming packet to a validator (which is merely validating the XML, not the data within) and then doesn't implement its own sanity error checking afterward. Thus, I've actually seen many security problems in XML applications because they assume that the packet contains everything it needs in the exact form it needs when in fact it may not. Andy is right, however, that an XSD probably couldn't be written which meet every implementations requirements. If you're going to make it normative, I don't think it should go into the appendix as it is currently. (If memory serves, appendices in RFCs are supposed to be normative). -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to 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 Mar 21 18:22:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11071 for ; Mon, 21 Mar 2005 18:22:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDW7g-0003a7-3i for netconf-data@psg.com; Mon, 21 Mar 2005 23:15:48 +0000 Received: from [208.184.15.238] (helo=EXECDSL.COM) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDW7e-0003Ze-Fp for netconf@ops.ietf.org; Mon, 21 Mar 2005 23:15:46 +0000 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9660863; Mon, 21 Mar 2005 18:15:45 -0500 Message-Id: <6.2.1.2.0.20050321181334.02f5edd8@mail.stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 21 Mar 2005 18:15:44 -0500 To: "McDonald, Ira" , "'Wes Hardaker'" , sberl@cisco.com From: "Joel M. Halpern" Subject: RE: Proposed Resolution to PROT I-D Issues List Cc: "'Andy Bierman'" , netconf@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Just to be clear, I certainly never claimed to speak for the IESG. I did describe IETF and IESG practice. And I certainly never suggested that removing the XSD would in any way help the situation. I objected privately to Ira's claim that making the English normative and the XSD informative was indefensible. He seems to be taking objection to my attempting to illustrate other points of view which have a lot of history and are well tested in our community. Yours, Joel M. Halpern At 06:06 PM 3/21/2005, McDonald, Ira wrote: >Hi, > >I've been having a long, fruitless offline discussion with Joel >Halpern about this. The results may be summarized as follows: > >(1) The IESG policy is that the plaintext English is always > normative. > >(2) The IESG policy does NOT allow an appendix of XSD (or any > other relatively formal language) to override the plaintext > English, because then _parts_ of plaintext English sentences > or paragraphs might become invalid. > >I'm strongly opposed to this logic, because it implies that an RFC >should not include any formal language appendices, since they're >to be ignored anyway. > >Analogy - In English and US contract law, if an illegal or invalid >statement is later found, then the clause or the subclause is >invalid, but the rest of the contract remains legally valid. > >I suggest deleting all XSD from Appendices and references. It >won't do you any good anyway. And changing the IESG policy >is just hopeless. > >Discouraged, >- 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 Wes Hardaker >Sent: Monday, March 21, 2005 5:00 PM >To: sberl@cisco.com >Cc: 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org >Subject: Re: Proposed Resolution to PROT I-D Issues List > > > >>>>> On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)" > said: > >Steven> Are you saying that we have a formal language description of >Steven> the syntax of the protocol messages, but that is there just >Steven> for information? > >My only intent was to state that it hasn't been proven to be perfect, >and thus implementers should not rely on it as a check that an >incoming packet is indeed perfect. > >The problem I've seen with XML applications is that many of them pass >an incoming packet to a validator (which is merely validating the XML, >not the data within) and then doesn't implement its own sanity error >checking afterward. Thus, I've actually seen many security problems >in XML applications because they assume that the packet contains >everything it needs in the exact form it needs when in fact it may >not. > >Andy is right, however, that an XSD probably couldn't be written which >meet every implementations requirements. > >If you're going to make it normative, I don't think it should go into >the appendix as it is currently. (If memory serves, appendices in >RFCs are supposed to be normative). > >-- >"In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett > >-- >to 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 Mar 21 18:29:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11971 for ; Mon, 21 Mar 2005 18:29:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDWGi-0006Cp-2H for netconf-data@psg.com; Mon, 21 Mar 2005 23:25:08 +0000 Received: from [85.73.143.253] (helo=boskop.local) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDWGf-0006CJ-O5 for netconf@ops.ietf.org; Mon, 21 Mar 2005 23:25:06 +0000 Received: by boskop.local (Postfix, from userid 501) id 4DABF1F9162; Tue, 22 Mar 2005 00:25:03 +0100 (CET) Date: Tue, 22 Mar 2005 00:25:03 +0100 From: Juergen Schoenwaelder To: "McDonald, Ira" Cc: "'Wes Hardaker'" , sberl@cisco.com, "'Andy Bierman'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List Message-ID: <20050321232503.GC4765@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "McDonald, Ira" , 'Wes Hardaker' , sberl@cisco.com, 'Andy Bierman' , 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.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Mar 21, 2005 at 03:06:15PM -0800, McDonald, Ira wrote: > I've been having a long, fruitless offline discussion with Joel > Halpern about this. The results may be summarized as follows: > > (1) The IESG policy is that the plaintext English is always > normative. > > (2) The IESG policy does NOT allow an appendix of XSD (or any > other relatively formal language) to override the plaintext > English, because then _parts_ of plaintext English sentences > or paragraphs might become invalid. > > I'm strongly opposed to this logic, because it implies that an RFC > should not include any formal language appendices, since they're > to be ignored anyway. Perhaps the conclusion is to remove all English plaintext and then we can publish normative formal notations. Perhaps this is the real explanation why MIB modules like to hide the English text inside of DESCRIPTION clauses. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 01:43:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17407 for ; Tue, 22 Mar 2005 01:43:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDczE-0004q5-7K for netconf-data@psg.com; Tue, 22 Mar 2005 06:35:32 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDczA-0004pI-7o for netconf@ops.ietf.org; Tue, 22 Mar 2005 06:35:28 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 008AB11D89C; Mon, 21 Mar 2005 22:35:21 -0800 (PST) From: Wes Hardaker To: "McDonald, Ira" Cc: "'Wes Hardaker'" , sberl@cisco.com, "'Andy Bierman'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List Organization: Sparta References: Date: Mon, 21 Mar 2005 22:35:20 -0800 In-Reply-To: (Ira McDonald's message of "Mon, 21 Mar 2005 15:06:15 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Mon, 21 Mar 2005 15:06:15 -0800, "McDonald, Ira" said: Ira> I suggest deleting all XSD from Appendices and references. It Ira> won't do you any good anyway. And changing the IESG policy is Ira> just hopeless. There are too many times where English text must be used because it can't be codified without 100000 lines of code. That doesn't make the few usable elements less useful. Thus, the XSD will always be useful even if the text is "more important". People will still use it in beneficial ways. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 22 03:15:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14647 for ; Tue, 22 Mar 2005 03:15:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDeSh-000LHp-To for netconf-data@psg.com; Tue, 22 Mar 2005 08:10:03 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDTax-000ERQ-BF for netconf@ops.ietf.org; Mon, 21 Mar 2005 20:33:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15276; Mon, 21 Mar 2005 15:33:48 -0500 (EST) Message-Id: <200503212033.PAA15276@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-beep-04.txt Date: Mon, 21 Mar 2005 15:33:47 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) Author(s) : E. Lear, K. Crozier Filename : draft-ietf-netconf-beep-04.txt Pages : 14 Date : 2005-3-21 This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-beep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-beep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-21154313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-beep-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-beep-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154313.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 04:35:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21794 for ; Tue, 22 Mar 2005 04:35:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDfc8-0005Hu-CG for netconf-data@psg.com; Tue, 22 Mar 2005 09:23:52 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDfc6-0005HY-FR for netconf@ops.ietf.org; Tue, 22 Mar 2005 09:23:50 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 22 Mar 2005 01:23:50 -0800 X-IronPort-AV: i="3.91,110,1110182400"; d="scan'208"; a="621707206:sNHT97611752" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2M9NlZV011778 for ; Tue, 22 Mar 2005 01:23:48 -0800 (PST) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4549.cisco.com [10.61.81.196]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2M9GZ5j012342 for ; Tue, 22 Mar 2005 01:16:35 -0800 Message-ID: <423FE420.1000702@cisco.com> Date: Tue, 22 Mar 2005 10:23:44 +0100 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: latest beep draft X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111482996.438649"; x:"432200"; a:"rsa-sha1"; b:"nofws:343"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"RM011iRQTOGp7of4JNJTq5bPeME1OMC0GafhgBondoHSojrQ2PG7PaXlkC7uU5heJTXcwREw" "u6lYRp5YSY2xkCDBpP0nDBEb7XgN+me3rUHUQEs30GIaz9lWMfTdA3caSo8UXXJ17f6tKimGcug" "0tLSN5t94j93c6iEzZkcvKgE="; c:"Date: Tue, 22 Mar 2005 10:23:44 +0100"; c:"From: Eliot Lear "; c:"Subject: latest beep draft" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I believe I have addressed issues raised in the WG last call. Can those who had comments (Juergen, Wes) take a quick scan? In particular: - addressed security issues regarding SASL & TLS - added examples - are these enough? - clarified use of and The draft is at the following URL and is still relatively short: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 08:36:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12117 for ; Tue, 22 Mar 2005 08:36:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDjQn-000KFE-3x for netconf-data@psg.com; Tue, 22 Mar 2005 13:28:25 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDjQe-000KEX-GY for netconf@ops.ietf.org; Tue, 22 Mar 2005 13:28:16 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2MDS8bF023204; Tue, 22 Mar 2005 05:28:10 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B7715HS>; Tue, 22 Mar 2005 05:28:05 -0800 Message-ID: From: "McDonald, Ira" To: "'Joel M. Halpern'" , "'Wes Hardaker'" , sberl@cisco.com Cc: "'Andy Bierman'" , netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 05:27:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, My apologies to Joel for misrepresenting our offline discussion and his point of view. I meant only to summarize what Joel was trying to explain to me about IESG policy. [Juergen - I made that MIB ASN.1 argument offline to Joel - and was told that the ASN.1 loses and the plaintext wins - which I utterly disbelieve. No MIB implementor ever ignored a SYNTAX or MAX-ACCESS clause in favor of some plaintext. And certainly no MIB compiler ever did this.] But this list is still not addressing Hector's real question, to whit: Will the IESG allow the NetConf XSD to be used in the protocol as a Normative _part_ of the incoming message validation logic? Joel, Randy, Wes, et al - could you please explain to this list how XSD is useful in NetConf if it's not Normative? 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: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Monday, March 21, 2005 6:16 PM To: McDonald, Ira; 'Wes Hardaker'; sberl@cisco.com Cc: 'Andy Bierman'; netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Just to be clear, I certainly never claimed to speak for the IESG. I did describe IETF and IESG practice. And I certainly never suggested that removing the XSD would in any way help the situation. I objected privately to Ira's claim that making the English normative and the XSD informative was indefensible. He seems to be taking objection to my attempting to illustrate other points of view which have a lot of history and are well tested in our community. Yours, Joel M. Halpern At 06:06 PM 3/21/2005, McDonald, Ira wrote: >Hi, > >I've been having a long, fruitless offline discussion with Joel >Halpern about this. The results may be summarized as follows: > >(1) The IESG policy is that the plaintext English is always > normative. > >(2) The IESG policy does NOT allow an appendix of XSD (or any > other relatively formal language) to override the plaintext > English, because then _parts_ of plaintext English sentences > or paragraphs might become invalid. > >I'm strongly opposed to this logic, because it implies that an RFC >should not include any formal language appendices, since they're >to be ignored anyway. > >Analogy - In English and US contract law, if an illegal or invalid >statement is later found, then the clause or the subclause is >invalid, but the rest of the contract remains legally valid. > >I suggest deleting all XSD from Appendices and references. It >won't do you any good anyway. And changing the IESG policy >is just hopeless. > >Discouraged, >- 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 Wes Hardaker >Sent: Monday, March 21, 2005 5:00 PM >To: sberl@cisco.com >Cc: 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org >Subject: Re: Proposed Resolution to PROT I-D Issues List > > > >>>>> On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)" > said: > >Steven> Are you saying that we have a formal language description of >Steven> the syntax of the protocol messages, but that is there just >Steven> for information? > >My only intent was to state that it hasn't been proven to be perfect, >and thus implementers should not rely on it as a check that an >incoming packet is indeed perfect. > >The problem I've seen with XML applications is that many of them pass >an incoming packet to a validator (which is merely validating the XML, >not the data within) and then doesn't implement its own sanity error >checking afterward. Thus, I've actually seen many security problems >in XML applications because they assume that the packet contains >everything it needs in the exact form it needs when in fact it may >not. > >Andy is right, however, that an XSD probably couldn't be written which >meet every implementations requirements. > >If you're going to make it normative, I don't think it should go into >the appendix as it is currently. (If memory serves, appendices in >RFCs are supposed to be normative). > >-- >"In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 11:18:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00433 for ; Tue, 22 Mar 2005 11:18:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDlv2-000K0G-Al for netconf-data@psg.com; Tue, 22 Mar 2005 16:07:48 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DDlur-000Jz0-N0 for netconf@ops.ietf.org; Tue, 22 Mar 2005 16:07:37 +0000 Received: (qmail 4458 invoked by uid 78); 22 Mar 2005 16:07:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 22 Mar 2005 16:07:33 -0000 Message-ID: <424042C4.5030900@andybierman.com> Date: Tue, 22 Mar 2005 08:07:32 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" CC: "'Joel M. Halpern'" , "'Wes Hardaker'" , sberl@cisco.com, netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: >Hi, > >My apologies to Joel for misrepresenting our offline >discussion and his point of view. I meant only to >summarize what Joel was trying to explain to me about >IESG policy. > >[Juergen - I made that MIB ASN.1 argument offline >to Joel - and was told that the ASN.1 loses and >the plaintext wins - which I utterly disbelieve. >No MIB implementor ever ignored a SYNTAX or >MAX-ACCESS clause in favor of some plaintext. >And certainly no MIB compiler ever did this.] > > MIB developers routinely interpret plaintext and SYNTAX together in order to correctly implement a specification. For example, the MAX-ACCESS clause is not expressive enough to specify the allowable write operation set for MIB tables which lock columns if the row is active. The sentence "This object may not be modified if the associated fooRowStatus object is equal to 'active'" appears in many DESCRIPTION clauses to get around this problem. In the case of the NETCONF XSD, an implementor better understand how capabilities affect the operation set that an agent accepts, the transaction model it uses, etc., in order to do anything useful. >But this list is still not addressing Hector's real >question, to whit: > >Will the IESG allow the NetConf XSD to be used in >the protocol as a Normative _part_ of the incoming >message validation logic? > >Joel, Randy, Wes, et al - could you please explain >to this list how XSD is useful in NetConf if it's >not Normative? > > I don't think there is WG consensus to add the "informative only" text that Wes proposed. I think the "continuing WG consensus" is that we need an XSD and namespace definition for the NETCONF protocol. I don't know why we need to add text to declare the XSD as normative or informative anyway. This issue was already declared closed with "no changes required", and I don't see any reason to change that now. The XSD is a superset of all syntax allowed for the base plus standard capabilities. A real agent is not likely to support all the standard capabilities (e.g., agent will allow writes to the or to , but not both). So it's true that "if it's not in the XSD, it's not in NETCONF", however no real agent will ever support the full XSD. >Cheers, >- Ira > > Andy >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: Joel M. Halpern [mailto:joel@stevecrocker.com] >Sent: Monday, March 21, 2005 6:16 PM >To: McDonald, Ira; 'Wes Hardaker'; sberl@cisco.com >Cc: 'Andy Bierman'; netconf@ops.ietf.org >Subject: RE: Proposed Resolution to PROT I-D Issues List > > >Just to be clear, I certainly never claimed to speak for the IESG. I did >describe IETF and IESG practice. > >And I certainly never suggested that removing the XSD would in any way help >the situation. > >I objected privately to Ira's claim that making the English normative and >the XSD informative was indefensible. He seems to be taking objection to >my attempting to illustrate other points of view which have a lot of >history and are well tested in our community. > >Yours, >Joel M. Halpern > >At 06:06 PM 3/21/2005, McDonald, Ira wrote: > > >>Hi, >> >>I've been having a long, fruitless offline discussion with Joel >>Halpern about this. The results may be summarized as follows: >> >>(1) The IESG policy is that the plaintext English is always >> normative. >> >>(2) The IESG policy does NOT allow an appendix of XSD (or any >> other relatively formal language) to override the plaintext >> English, because then _parts_ of plaintext English sentences >> or paragraphs might become invalid. >> >>I'm strongly opposed to this logic, because it implies that an RFC >>should not include any formal language appendices, since they're >>to be ignored anyway. >> >>Analogy - In English and US contract law, if an illegal or invalid >>statement is later found, then the clause or the subclause is >>invalid, but the rest of the contract remains legally valid. >> >>I suggest deleting all XSD from Appendices and references. It >>won't do you any good anyway. And changing the IESG policy >>is just hopeless. >> >>Discouraged, >>- 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 Wes Hardaker >>Sent: Monday, March 21, 2005 5:00 PM >>To: sberl@cisco.com >>Cc: 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org >>Subject: Re: Proposed Resolution to PROT I-D Issues List >> >> >> >> >>>>>>>On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)" >>>>>>> >>>>>>> >> said: >> >>Steven> Are you saying that we have a formal language description of >>Steven> the syntax of the protocol messages, but that is there just >>Steven> for information? >> >>My only intent was to state that it hasn't been proven to be perfect, >>and thus implementers should not rely on it as a check that an >>incoming packet is indeed perfect. >> >>The problem I've seen with XML applications is that many of them pass >>an incoming packet to a validator (which is merely validating the XML, >>not the data within) and then doesn't implement its own sanity error >>checking afterward. Thus, I've actually seen many security problems >>in XML applications because they assume that the packet contains >>everything it needs in the exact form it needs when in fact it may >>not. >> >>Andy is right, however, that an XSD probably couldn't be written which >>meet every implementations requirements. >> >>If you're going to make it normative, I don't think it should go into >>the appendix as it is currently. (If memory serves, appendices in >>RFCs are supposed to be normative). >> >>-- >>"In the bathtub of history the truth is harder to hold than the soap, >> and much more difficult to find." -- Terry Pratchett >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 11:58:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04820 for ; Tue, 22 Mar 2005 11:58:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDmYD-0000Oa-UA for netconf-data@psg.com; Tue, 22 Mar 2005 16:48:17 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDmXH-0000Dj-7i for netconf@ops.ietf.org; Tue, 22 Mar 2005 16:47:19 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2005 08:47:08 -0800 X-IronPort-AV: i="3.91,111,1110182400"; d="scan'208"; a="238848928:sNHT881459436" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2MGkwgE022520; Tue, 22 Mar 2005 08:46:58 -0800 (PST) Received: from sberlw2k01 (sjc-vpn6-13.cisco.com [10.21.120.13]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDE40727; Tue, 22 Mar 2005 08:47:00 -0800 (PST) Message-Id: <200503221647.BDE40727@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Andy Bierman'" , "'McDonald, Ira'" Cc: "'Joel M. Halpern'" , "'Wes Hardaker'" , Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 08:46:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUu+YabeL7GEvuJTPCihB6AByLCHwAAbmdw In-Reply-To: <424042C4.5030900@andybierman.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think what you are saying is that first a received message has to be valid with respect to the XSD. Then, and only then, can further validity checks be applied to determine whether the message can be accepted or not. Perhaps text something like this could be added: "The XSD expresses a subset of the constraints that define a valid message. If it doesn't pass that subset, then the message is not valid. The particular subset of constraints expressed in the XSD are interesting because the code to do the checking can be completely machine generated. This doesn't mean that you don't need to do additional constraint checking based on rules described in the text, the set of capabilities supported by your implementation, and any other implementation imposed constraint rules." If I could draw a Venn diagram of this in email I would. It would have 3 concentric circles that don't overlap at all. The outermost would be the set of all well-formed XML messages. The next in would be the set of messages that are valid with respect to the netconf XSD. The innermost would be the subset of those valid messages that meet the additional constraints expressed in the text. The edges of the circles never cross. Nothing outside of the "valid against the XSD" circle can be part of the inner circle of accepted messages. Depending on the way the XSD is designed and developed it can express more or less of the constraints. For example I could declare that an element is just a xs:string, or I can add additional resrictions to say it must be a string that matches a regular express. This changes the size of the "valid against the XSD" circle, but it doesn't change the relationships described in the paragraph above. In a perfect world, the "valid" circle and the "accepted" circle would be the same, but because some of the constraints can't be expressed in the XSD constraint language they are not. The "valid" circle will always be bigger, and the rest of the rules will need to be expressed in a different language, which in our case is english prose. -steve > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, March 22, 2005 8:08 AM > To: McDonald, Ira > Cc: 'Joel M. Halpern'; 'Wes Hardaker'; sberl@cisco.com; > netconf@ops.ietf.org > Subject: Re: Proposed Resolution to PROT I-D Issues List > > McDonald, Ira wrote: > > >Hi, > > > >My apologies to Joel for misrepresenting our offline > discussion and his > >point of view. I meant only to summarize what Joel was trying to > >explain to me about IESG policy. > > > >[Juergen - I made that MIB ASN.1 argument offline to Joel - and was > >told that the ASN.1 loses and the plaintext wins - which I utterly > >disbelieve. > >No MIB implementor ever ignored a SYNTAX or MAX-ACCESS > clause in favor > >of some plaintext. > >And certainly no MIB compiler ever did this.] > > > > > MIB developers routinely interpret plaintext and SYNTAX together > in order to correctly implement a specification. For example, > the MAX-ACCESS clause is not expressive enough to specify the > allowable write operation set for MIB tables which lock > columns if the row is active. The sentence "This object may > not be modified if the associated fooRowStatus object is > equal to 'active'" appears in many DESCRIPTION clauses to get > around this problem. > > In the case of the NETCONF XSD, an implementor better > understand how capabilities affect the operation set that an > agent accepts, the transaction model it uses, etc., in order > to do anything useful. > > >But this list is still not addressing Hector's real > question, to whit: > > > >Will the IESG allow the NetConf XSD to be used in the protocol as a > >Normative _part_ of the incoming message validation logic? > > > >Joel, Randy, Wes, et al - could you please explain to this > list how XSD > >is useful in NetConf if it's not Normative? > > > > > I don't think there is WG consensus to add the "informative > only" text that Wes proposed. I think the "continuing WG > consensus" is that we need an XSD and namespace definition > for the NETCONF protocol. I don't know why we need to add > text to declare the XSD as normative or informative anyway. > This issue was already declared closed with "no changes > required", and I don't see any reason to change that now. > > The XSD is a superset of all syntax allowed for the base plus > standard capabilities. > A real agent is not likely to support all the standard > capabilities (e.g., agent will allow writes to the > or to , but not both). So it's true > that "if it's not in the XSD, it's not in NETCONF", however > no real agent will ever support the full XSD. > > >Cheers, > >- Ira > > > > > Andy > > >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: Joel M. Halpern [mailto:joel@stevecrocker.com] > >Sent: Monday, March 21, 2005 6:16 PM > >To: McDonald, Ira; 'Wes Hardaker'; sberl@cisco.com > >Cc: 'Andy Bierman'; netconf@ops.ietf.org > >Subject: RE: Proposed Resolution to PROT I-D Issues List > > > > > >Just to be clear, I certainly never claimed to speak for the > IESG. I > >did describe IETF and IESG practice. > > > >And I certainly never suggested that removing the XSD would > in any way > >help the situation. > > > >I objected privately to Ira's claim that making the English > normative > >and the XSD informative was indefensible. He seems to be taking > >objection to my attempting to illustrate other points of view which > >have a lot of history and are well tested in our community. > > > >Yours, > >Joel M. Halpern > > > >At 06:06 PM 3/21/2005, McDonald, Ira wrote: > > > > > >>Hi, > >> > >>I've been having a long, fruitless offline discussion with Joel > >>Halpern about this. The results may be summarized as follows: > >> > >>(1) The IESG policy is that the plaintext English is always > >> normative. > >> > >>(2) The IESG policy does NOT allow an appendix of XSD (or any > >> other relatively formal language) to override the plaintext > >> English, because then _parts_ of plaintext English sentences > >> or paragraphs might become invalid. > >> > >>I'm strongly opposed to this logic, because it implies that an RFC > >>should not include any formal language appendices, since > they're to be > >>ignored anyway. > >> > >>Analogy - In English and US contract law, if an illegal or invalid > >>statement is later found, then the clause or the subclause > is invalid, > >>but the rest of the contract remains legally valid. > >> > >>I suggest deleting all XSD from Appendices and references. > It won't > >>do you any good anyway. And changing the IESG policy is just > >>hopeless. > >> > >>Discouraged, > >>- 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 Wes Hardaker > >>Sent: Monday, March 21, 2005 5:00 PM > >>To: sberl@cisco.com > >>Cc: 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org > >>Subject: Re: Proposed Resolution to PROT I-D Issues List > >> > >> > >> > >> > >>>>>>>On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)" > >>>>>>> > >>>>>>> > >> said: > >> > >>Steven> Are you saying that we have a formal language > description of > >>Steven> the syntax of the protocol messages, but that is there just > >>Steven> for information? > >> > >>My only intent was to state that it hasn't been proven to > be perfect, > >>and thus implementers should not rely on it as a check that an > >>incoming packet is indeed perfect. > >> > >>The problem I've seen with XML applications is that many of > them pass > >>an incoming packet to a validator (which is merely > validating the XML, > >>not the data within) and then doesn't implement its own > sanity error > >>checking afterward. Thus, I've actually seen many security > problems > >>in XML applications because they assume that the packet contains > >>everything it needs in the exact form it needs when in fact it may > >>not. > >> > >>Andy is right, however, that an XSD probably couldn't be > written which > >>meet every implementations requirements. > >> > >>If you're going to make it normative, I don't think it > should go into > >>the appendix as it is currently. (If memory serves, appendices in > >>RFCs are supposed to be normative). > >> > >>-- > >>"In the bathtub of history the truth is harder to hold than > the soap, > >>and much more difficult to find." -- Terry Pratchett > >> > >>-- > >>to 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 Tue Mar 22 12:19:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07199 for ; Tue, 22 Mar 2005 12:19:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDmua-0004dq-OJ for netconf-data@psg.com; Tue, 22 Mar 2005 17:11:24 +0000 Received: from [208.184.15.238] (helo=EXECDSL.COM) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDmuZ-0004dd-Jj for netconf@ops.ietf.org; Tue, 22 Mar 2005 17:11:23 +0000 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9671520; Tue, 22 Mar 2005 12:11:22 -0500 Message-Id: <6.2.1.2.0.20050322120327.02d78aa8@mail.stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Mar 2005 12:11:22 -0500 To: "McDonald, Ira" , "'Wes Hardaker'" , sberl@cisco.com From: "Joel M. Halpern" Subject: RE: Proposed Resolution to PROT I-D Issues List Cc: "'Andy Bierman'" , netconf@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk The simplest answer is to look at other cases. The IEEE 802.1d bridging spec was quite clear that the English was normative. Nonetheless it include code for all the procedures, and that code was quite useful to people. I think that it is more helpful to look at the question differently. One expects even informative language in a specification to be helpful. There is often a lot of informative language to help the reader understand the intent of the specification, and to help get effective results in the real world. The only question under discussion is, if there is a disagreement between the English and the formal specification, which one should the reader assume was intended. Such a disagreement is a bug in the spec, even if the part that is wrong is not normative. In the absence of a disagreement, having the XSD will enable implementors to more reliably implement the intent of the specification. This is helpful. It can be argued that we should elevate it further. We could go down the path of insisting that all normative behavior must be described either in the formal portions of the XSD or in comments explicitly part of the XSD. That would make reading the specification and understanding it hard, but it would mean that we would be clear about what was intended to be binding. We could say that the English is binding for semantics, but the XSD is binding for those things which it specifies. This would make things very confusing. There is admittedly also confusion in having the XSD but not making it normative. Feel free to pick your confusion. But please do not assert that having a differing viewpoint is nonsensical. Yours, Joel M. Halpern At 08:27 AM 3/22/2005, McDonald, Ira wrote: >Joel, Randy, Wes, et al - could you please explain >to this list how XSD is useful in NetConf if it's >not Normative? -- to unsubscribe send a message to netconf-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 Mar 22 12:25:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07748 for ; Tue, 22 Mar 2005 12:25:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDn24-0005ce-Du for netconf-data@psg.com; Tue, 22 Mar 2005 17:19:08 +0000 Received: from [208.184.15.238] (helo=EXECDSL.COM) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDn23-0005cN-3t for netconf@ops.ietf.org; Tue, 22 Mar 2005 17:19:07 +0000 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9671586; Tue, 22 Mar 2005 12:19:05 -0500 Message-Id: <6.2.1.2.0.20050322121636.02ee3c80@mail.stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Mar 2005 12:18:53 -0500 To: "McDonald, Ira" , "'Wes Hardaker'" , sberl@cisco.com From: "Joel M. Halpern" Subject: RE: Proposed Resolution to PROT I-D Issues List Cc: "'Andy Bierman'" , netconf@ops.ietf.org In-Reply-To: <6.2.1.2.0.20050322120327.02d78aa8@mail.stevecrocker.com> References: <6.2.1.2.0.20050322120327.02d78aa8@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk The other point is to echo Andy's comment. Except in how we use captialized MUST, MAY, SHOULD wording, the IETF does not make a strong distinction in our specifications between normative and informative text. (This is largely because we are not in the conformance testing business.) As such, there is likely no reason to make an issue in the RFC of the question of what meaning applies in the event of conflict between text and the XSD. There is a very good reason to make sure to the best of our ability that there is no such contradiction. Yours, Joel M. Halpern At 12:11 PM 3/22/2005, Joel M. Halpern wrote: >The simplest answer is to look at other cases. >The IEEE 802.1d bridging spec was quite clear that the English was >normative. Nonetheless it include code for all the procedures, and that >code was quite useful to people. > >I think that it is more helpful to look at the question differently. >One expects even informative language in a specification to be >helpful. There is often a lot of informative language to help the reader >understand the intent of the specification, and to help get effective >results in the real world. > >The only question under discussion is, if there is a disagreement between >the English and the formal specification, which one should the reader >assume was intended. Such a disagreement is a bug in the spec, even if >the part that is wrong is not normative. > >In the absence of a disagreement, having the XSD will enable implementors >to more reliably implement the intent of the specification. This is helpful. > >It can be argued that we should elevate it further. >We could go down the path of insisting that all normative behavior must be >described either in the formal portions of the XSD or in comments >explicitly part of the XSD. That would make reading the specification and >understanding it hard, but it would mean that we would be clear about what >was intended to be binding. >We could say that the English is binding for semantics, but the XSD is >binding for those things which it specifies. This would make things very >confusing. >There is admittedly also confusion in having the XSD but not making it >normative. > >Feel free to pick your confusion. >But please do not assert that having a differing viewpoint is nonsensical. > >Yours, >Joel M. Halpern > >At 08:27 AM 3/22/2005, McDonald, Ira wrote: >>Joel, Randy, Wes, et al - could you please explain >>to this list how XSD is useful in NetConf if it's >>not Normative? > > >-- >to 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 Mar 22 13:45:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17150 for ; Tue, 22 Mar 2005 13:45:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDoDo-000GY7-5k for netconf-data@psg.com; Tue, 22 Mar 2005 18:35:20 +0000 Received: from [207.217.121.249] (helo=pop-a065d05.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDoDm-000GXn-65 for netconf@ops.ietf.org; Tue, 22 Mar 2005 18:35:18 +0000 Received: from h-64-105-136-204.snvacaid.dynamic.covad.net ([64.105.136.204] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DDoDk-000789-00 for netconf@ops.ietf.org; Tue, 22 Mar 2005 10:35:17 -0800 Message-ID: <000801c52f0d$feedba00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 10:35:37 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "McDonald, Ira" > To: "'Joel M. Halpern'" ; "'Wes Hardaker'" ; > Cc: "'Andy Bierman'" ; > Sent: Tuesday, March 22, 2005 5:27 AM > Subject: RE: Proposed Resolution to PROT I-D Issues List ... > Joel, Randy, Wes, et al - could you please explain > to this list how XSD is useful in NetConf if it's > not Normative? ... It *is* normative. It's just that in the case of conflict or ambiguity, the English takes precedence. This is as it should be. I recall fixing errors in ASN.1 and MIB modules, where the fix was justified by the fact that the English text captured the WG intent and the formal notation said something else. This routinely happens during MIB review cycles. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 15:11:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26266 for ; Tue, 22 Mar 2005 15:11:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDpcs-0004DD-8c for netconf-data@psg.com; Tue, 22 Mar 2005 20:05:18 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDpcp-0004Cl-RU for netconf@ops.ietf.org; Tue, 22 Mar 2005 20:05:15 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2MK5DOK013144; Tue, 22 Mar 2005 12:05:13 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B7719PD>; Tue, 22 Mar 2005 12:05:14 -0800 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 12:05:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, It would be nice if there were some agreement in this advice. Randy says the XSD *is* normative, but the plaintext wins in conflicts (which Joel says is not true under the prevailing IESG policy, because nothing but plaintext can be normative). Joel says the IESG doesn't bother much about labelling parts of RFCs normative or informative (the RFC Editor certainly doesn't agree with this one - a number of RFC's and I-Ds on proper RFC style address which body parts and appendices are or should be normative). I liked Steve's formulation very much, but it's broken by the "plaintext always wins" rule. An incoming message could _fail_ the XSD check and still be valid under ambiguously written plaintext body parts... 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: Tuesday, March 22, 2005 1:36 PM To: netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List Hi - > From: "McDonald, Ira" > To: "'Joel M. Halpern'" ; "'Wes Hardaker'" ; > Cc: "'Andy Bierman'" ; > Sent: Tuesday, March 22, 2005 5:27 AM > Subject: RE: Proposed Resolution to PROT I-D Issues List ... > Joel, Randy, Wes, et al - could you please explain > to this list how XSD is useful in NetConf if it's > not Normative? ... It *is* normative. It's just that in the case of conflict or ambiguity, the English takes precedence. This is as it should be. I recall fixing errors in ASN.1 and MIB modules, where the fix was justified by the fact that the English text captured the WG intent and the formal notation said something else. This routinely happens during MIB review cycles. 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: -- to unsubscribe send a message to netconf-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 Mar 22 16:06:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05228 for ; Tue, 22 Mar 2005 16:06:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDqSR-000BWL-4a for netconf-data@psg.com; Tue, 22 Mar 2005 20:58:35 +0000 Received: from [207.217.121.249] (helo=pop-a065d05.pas.sa.earthlink.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDqSM-000BVL-U9 for netconf@ops.ietf.org; Tue, 22 Mar 2005 20:58:31 +0000 Received: from h-64-105-136-204.snvacaid.dynamic.covad.net ([64.105.136.204] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DDqSL-0002Vo-00 for netconf@ops.ietf.org; Tue, 22 Mar 2005 12:58:29 -0800 Message-ID: <005e01c52f22$00be6b40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 12:59:13 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "McDonald, Ira" > To: "'Randy Presuhn'" ; > Sent: Tuesday, March 22, 2005 12:05 PM > Subject: RE: Proposed Resolution to PROT I-D Issues List ? > Hi, > > It would be nice if there were some agreement in this advice. > > Randy says the XSD *is* normative, but the plaintext wins in > conflicts (which Joel says is not true under the prevailing > IESG policy, because nothing but plaintext can be normative). I base my claim on the statement "We therefore expect that people will continue using English to describe protocols, with formal languages as a supporting mechanism" from http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt > Joel says the IESG doesn't bother much about labelling parts > of RFCs normative or informative (the RFC Editor certainly > doesn't agree with this one - a number of RFC's and I-Ds on > proper RFC style address which body parts and appendices are > or should be normative). Even within a normative section, there may be material which is obviously non-normative. Phrases like "for example" are frequently a clue. The normal MIB boilerplate contains non-normative material: "For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]." Helpful background material is a Good Thing, even though it may be non-normative. > I liked Steve's formulation very much, but it's broken by > the "plaintext always wins" rule. An incoming message could > _fail_ the XSD check and still be valid under ambiguously > written plaintext body parts... ... When such cases arise, the document should go back to the WG. However, to make up an example, if the English says "it MAY contain an optional element Z", but the XSD says Z is mandatory, then I think the burden of proof is clearly on those who would claim that the XSD is not in error. I trust humans to spot errors in human- readable text more than I trust them to spot semantic errors in formal notations. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 19:58:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01098 for ; Tue, 22 Mar 2005 19:58:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDu2q-000IEJ-R6 for netconf-data@psg.com; Wed, 23 Mar 2005 00:48:24 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DDu2o-000IDC-8N for netconf@ops.ietf.org; Wed, 23 Mar 2005 00:48:22 +0000 Received: (qmail 8554 invoked by uid 78); 23 Mar 2005 00:48:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 00:48:18 -0000 Message-ID: <4240BCD1.7040102@andybierman.com> Date: Tue, 22 Mar 2005 16:48:17 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" CC: "'Randy Presuhn'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: >Hi, > >It would be nice if there were some agreement in this advice. > >Randy says the XSD *is* normative, but the plaintext wins in >conflicts (which Joel says is not true under the prevailing >IESG policy, because nothing but plaintext can be normative). > >Joel says the IESG doesn't bother much about labelling parts >of RFCs normative or informative (the RFC Editor certainly >doesn't agree with this one - a number of RFC's and I-Ds on >proper RFC style address which body parts and appendices are >or should be normative). > >I liked Steve's formulation very much, but it's broken by >the "plaintext always wins" rule. An incoming message could >_fail_ the XSD check and still be valid under ambiguously >written plaintext body parts... > > Are there specific portions of text that you are making objections or suggestions for changes? We aren't going to change IESG policy on this mailing list. Unless there are specific changes to the -05 draft to discuss here, I think this topic is closed. >Cheers, >- Ira > > Andy >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: Tuesday, March 22, 2005 1:36 PM >To: netconf@ops.ietf.org >Subject: Re: Proposed Resolution to PROT I-D Issues List > > >Hi - > > > >>From: "McDonald, Ira" >>To: "'Joel M. Halpern'" ; "'Wes Hardaker'" >> >> >; > > >>Cc: "'Andy Bierman'" ; >>Sent: Tuesday, March 22, 2005 5:27 AM >>Subject: RE: Proposed Resolution to PROT I-D Issues List >> >> >... > > >>Joel, Randy, Wes, et al - could you please explain >>to this list how XSD is useful in NetConf if it's >>not Normative? >> >> >... > >It *is* normative. It's just that in the case of conflict or ambiguity, >the English takes precedence. This is as it should be. I recall >fixing errors in ASN.1 and MIB modules, where the fix was justified >by the fact that the English text captured the WG intent and the >formal notation said something else. This routinely happens during >MIB review cycles. > >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: > >-- >to 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 Mar 22 20:51:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04349 for ; Tue, 22 Mar 2005 20:51:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDurt-0000Ij-1f for netconf-data@psg.com; Wed, 23 Mar 2005 01:41:09 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDurq-0000IP-Ph for netconf@ops.ietf.org; Wed, 23 Mar 2005 01:41:06 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2005 17:41:00 -0800 X-IronPort-AV: i="3.91,112,1110182400"; d="scan'208"; a="239132763:sNHT877863352" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2N1evDr011856; Tue, 22 Mar 2005 17:40:58 -0800 (PST) Received: from sberlw2k01 (dhcp-171-69-222-243.cisco.com [171.69.222.243]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDF05768; Tue, 22 Mar 2005 17:40:57 -0800 (PST) Message-Id: <200503230140.BDF05768@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Andy Bierman'" , "'McDonald, Ira'" Cc: "'Randy Presuhn'" , Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 17:40:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4240BCD1.7040102@andybierman.com> Thread-Index: AcUvQmimDQNpUNNKTsWuxRCwV8d4cgABZdFw X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to see text in the document that says something like: Any message that is not valid with respect to the XML schema in appendix B, is not a valid netconf message and MUST be rejected by the netconf server that receives it. In the the MUST be set to "error" and the MUST contain one of INVALID_VALUE, MISSING_ATTRIBUTE, BAD_ATTRIBUTE, UNKNOWN_ATTRIBUTE, MISSING_ELEMENT, BAD_ELEMENT, or UNKNOWN_ELEMENT. -steve > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, March 22, 2005 4:48 PM > To: McDonald, Ira > Cc: 'Randy Presuhn'; netconf@ops.ietf.org > Subject: Re: Proposed Resolution to PROT I-D Issues List > > McDonald, Ira wrote: > > >Hi, > > > >It would be nice if there were some agreement in this advice. > > > >Randy says the XSD *is* normative, but the plaintext wins in > conflicts > >(which Joel says is not true under the prevailing IESG > policy, because > >nothing but plaintext can be normative). > > > >Joel says the IESG doesn't bother much about labelling parts of RFCs > >normative or informative (the RFC Editor certainly doesn't > agree with > >this one - a number of RFC's and I-Ds on proper RFC style > address which > >body parts and appendices are or should be normative). > > > >I liked Steve's formulation very much, but it's broken by the > >"plaintext always wins" rule. An incoming message could > _fail_ the XSD > >check and still be valid under ambiguously written plaintext body > >parts... > > > > > Are there specific portions of text that you are making > objections or suggestions > for changes? We aren't going to change IESG policy on this mailing > list. Unless > there are specific changes to the -05 draft to discuss here, > I think this topic is closed. > > >Cheers, > >- Ira > > > > > Andy > > >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: Tuesday, March 22, 2005 1:36 PM > >To: netconf@ops.ietf.org > >Subject: Re: Proposed Resolution to PROT I-D Issues List > > > > > >Hi - > > > > > > > >>From: "McDonald, Ira" > >>To: "'Joel M. Halpern'" ; "'Wes Hardaker'" > >> > >> > >; > > > > > >>Cc: "'Andy Bierman'" ; > >>Sent: Tuesday, March 22, 2005 5:27 AM > >>Subject: RE: Proposed Resolution to PROT I-D Issues List > >> > >> > >... > > > > > >>Joel, Randy, Wes, et al - could you please explain to this list how > >>XSD is useful in NetConf if it's not Normative? > >> > >> > >... > > > >It *is* normative. It's just that in the case of conflict or > >ambiguity, the English takes precedence. This is as it > should be. I > >recall fixing errors in ASN.1 and MIB modules, where the fix was > >justified by the fact that the English text captured the WG > intent and > >the formal notation said something else. This routinely > happens during > >MIB review cycles. > > > >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: > > > >-- > >to unsubscribe send a message to > netconf-request@ops.ietf.org with the > >word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org > with the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 22:24:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24547 for ; Tue, 22 Mar 2005 22:24:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDwNO-000Bcc-VG for netconf-data@psg.com; Wed, 23 Mar 2005 03:17:46 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DDwNL-000Bal-FY for netconf@ops.ietf.org; Wed, 23 Mar 2005 03:17:43 +0000 Received: (qmail 310 invoked by uid 78); 23 Mar 2005 03:17:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 03:17:42 -0000 Message-ID: <4240DFD5.2050307@andybierman.com> Date: Tue, 22 Mar 2005 19:17:41 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sberl@cisco.com CC: "'McDonald, Ira'" , "'Randy Presuhn'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <200503230140.BDF05768@mira-sjc5-b.cisco.com> In-Reply-To: <200503230140.BDF05768@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steven Berl (sberl) wrote: >I would like to see text in the document that says something like: > >Any message that is not valid with respect to the XML schema in appendix B, >is not a valid netconf message and MUST be rejected by the netconf server >that receives it. In the the MUST be set to >"error" and the MUST contain one of INVALID_VALUE, >MISSING_ATTRIBUTE, BAD_ATTRIBUTE, UNKNOWN_ATTRIBUTE, MISSING_ELEMENT, >BAD_ELEMENT, or UNKNOWN_ELEMENT. > > This is fine with me. Echoing one last word on XSD vs. plaintext -- if the XSD doesn't match the text then we fix whichever one is broken. BTW, the draft already says the XSD is normative for syntax. (I think I wrote this paragraph ;-) From PROT-05, sec. 7, last para: The syntax and XML encoding of the protocol operations are formally defined in the XML schema in Appendix B. The following sections describe the semantics of each protocol operation. I think it would help if the XSD was annotated to indicate which elements/values are associated with which capabilities. >-steve > > Andy > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>Sent: Tuesday, March 22, 2005 4:48 PM >>To: McDonald, Ira >>Cc: 'Randy Presuhn'; netconf@ops.ietf.org >>Subject: Re: Proposed Resolution to PROT I-D Issues List >> >>McDonald, Ira wrote: >> >> >> >>>Hi, >>> >>>It would be nice if there were some agreement in this advice. >>> >>>Randy says the XSD *is* normative, but the plaintext wins in >>> >>> >>conflicts >> >> >>>(which Joel says is not true under the prevailing IESG >>> >>> >>policy, because >> >> >>>nothing but plaintext can be normative). >>> >>>Joel says the IESG doesn't bother much about labelling parts of RFCs >>>normative or informative (the RFC Editor certainly doesn't >>> >>> >>agree with >> >> >>>this one - a number of RFC's and I-Ds on proper RFC style >>> >>> >>address which >> >> >>>body parts and appendices are or should be normative). >>> >>>I liked Steve's formulation very much, but it's broken by the >>>"plaintext always wins" rule. An incoming message could >>> >>> >>_fail_ the XSD >> >> >>>check and still be valid under ambiguously written plaintext body >>>parts... >>> >>> >>> >>> >>Are there specific portions of text that you are making >>objections or suggestions >>for changes? We aren't going to change IESG policy on this mailing >>list. Unless >>there are specific changes to the -05 draft to discuss here, >>I think this topic is closed. >> >> >> >>>Cheers, >>>- Ira >>> >>> >>> >>> >>Andy >> >> >> >>>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: Tuesday, March 22, 2005 1:36 PM >>>To: netconf@ops.ietf.org >>>Subject: Re: Proposed Resolution to PROT I-D Issues List >>> >>> >>>Hi - >>> >>> >>> >>> >>> >>>>From: "McDonald, Ira" >>>>To: "'Joel M. Halpern'" ; "'Wes Hardaker'" >>>> >>>> >>>> >>>> >>>; >>> >>> >>> >>> >>>>Cc: "'Andy Bierman'" ; >>>>Sent: Tuesday, March 22, 2005 5:27 AM >>>>Subject: RE: Proposed Resolution to PROT I-D Issues List >>>> >>>> >>>> >>>> >>>... >>> >>> >>> >>> >>>>Joel, Randy, Wes, et al - could you please explain to this list how >>>>XSD is useful in NetConf if it's not Normative? >>>> >>>> >>>> >>>> >>>... >>> >>>It *is* normative. It's just that in the case of conflict or >>>ambiguity, the English takes precedence. This is as it >>> >>> >>should be. I >> >> >>>recall fixing errors in ASN.1 and MIB modules, where the fix was >>>justified by the fact that the English text captured the WG >>> >>> >>intent and >> >> >>>the formal notation said something else. This routinely >>> >>> >>happens during >> >> >>>MIB review cycles. >>> >>>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: >>> >>>-- >>>to unsubscribe send a message to >>> >>> >>netconf-request@ops.ietf.org with the >> >> >>>word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >>> >>> >>> >>> >>> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org >>with the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> >> > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 22 23:19:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20002 for ; Tue, 22 Mar 2005 23:19:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDxEw-000Ivs-H4 for netconf-data@psg.com; Wed, 23 Mar 2005 04:13:06 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDxEu-000Iv5-CE for netconf@ops.ietf.org; Wed, 23 Mar 2005 04:13:04 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id AFBF211D89B; Tue, 22 Mar 2005 20:12:58 -0800 (PST) From: Wes Hardaker To: "Randy Presuhn" Cc: Subject: Re: Proposed Resolution to PROT I-D Issues List Organization: Sparta References: <005e01c52f22$00be6b40$7f1afea9@oemcomputer> Date: Tue, 22 Mar 2005 20:12:58 -0800 In-Reply-To: <005e01c52f22$00be6b40$7f1afea9@oemcomputer> (Randy Presuhn's message of "Tue, 22 Mar 2005 12:59:13 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Tue, 22 Mar 2005 12:59:13 -0800, "Randy Presuhn" said: Randy> When such cases arise, the document should go back to the WG. Randy> However, to make up an example, if the English says "it MAY Randy> contain an optional element Z", but the XSD says Z is Randy> mandatory, then I think the burden of proof is clearly on those Randy> who would claim that the XSD is not in error. I trust humans Randy> to spot errors in human- readable text more than I trust them Randy> to spot semantic errors in formal notations. It's actually the reverse that caused me to post the original message. I've seen stupid programmers do validation against an XSD and assume that because the results came back positive that they don't have to do error checking. That got me to thinking that I doubt you want to readers to assume that the XSD included with the RFC is perfectly sufficient for validation and is 100% error free. It's when the RFC text says MUST but the XSD says MAY that worries me because programmers will assume the XSD is sufficient and then they fail to check in code against the NULL for that tag because they assumed the XSD would have caught the error and then BOOM. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 22 23:32:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21117 for ; Tue, 22 Mar 2005 23:32:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDxS0-000Kh6-3c for netconf-data@psg.com; Wed, 23 Mar 2005 04:26:36 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDxRy-000Kgu-Vz for netconf@ops.ietf.org; Wed, 23 Mar 2005 04:26:35 +0000 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <2005032304263401100sshjne>; Wed, 23 Mar 2005 04:26:34 +0000 Reply-To: From: "David B Harrington" To: "'Wes Hardaker'" , "'Randy Presuhn'" Cc: Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 23:26:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: thread-index: AcUvX41cMiP/SjyAQmK60mpKLOfylQAANA3w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit If XSDs are anything like MIB modules, the XSD will probably be distributed without the accompanying text. Sigh. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Wes Hardaker > Sent: Tuesday, March 22, 2005 11:13 PM > To: Randy Presuhn > Cc: netconf@ops.ietf.org > Subject: Re: Proposed Resolution to PROT I-D Issues List > > >>>>> On Tue, 22 Mar 2005 12:59:13 -0800, "Randy Presuhn" > said: > > Randy> When such cases arise, the document should go back to the WG. > Randy> However, to make up an example, if the English says "it MAY > Randy> contain an optional element Z", but the XSD says Z is > Randy> mandatory, then I think the burden of proof is clearly on those > Randy> who would claim that the XSD is not in error. I trust humans > Randy> to spot errors in human- readable text more than I trust them > Randy> to spot semantic errors in formal notations. > > It's actually the reverse that caused me to post the original > message. I've seen stupid programmers do validation against an XSD > and assume that because the results came back positive that they don't > have to do error checking. That got me to thinking that I doubt you > want to readers to assume that the XSD included with the RFC is > perfectly sufficient for validation and is 100% error free. It's when > the RFC text says MUST but the XSD says MAY that worries me because > programmers will assume the XSD is sufficient and then they fail to > check in code against the NULL for that tag because they assumed the > XSD would have caught the error and then BOOM. > > -- > "In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett > > -- > to 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 Mar 23 01:41:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01612 for ; Wed, 23 Mar 2005 01:41:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDzMv-000D3i-NZ for netconf-data@psg.com; Wed, 23 Mar 2005 06:29:29 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDzMu-000D3W-RM for netconf@ops.ietf.org; Wed, 23 Mar 2005 06:29:28 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 7ECD011D724; Tue, 22 Mar 2005 22:29:23 -0800 (PST) From: Wes Hardaker To: Andy Bierman Cc: sberl@cisco.com, "'McDonald, Ira'" , "'Randy Presuhn'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List Organization: Sparta References: <200503230140.BDF05768@mira-sjc5-b.cisco.com> <4240DFD5.2050307@andybierman.com> Date: Tue, 22 Mar 2005 22:29:22 -0800 In-Reply-To: <4240DFD5.2050307@andybierman.com> (Andy Bierman's message of "Tue, 22 Mar 2005 19:17:41 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Andy> Echoing one last word on XSD vs. plaintext -- if the XSD doesn't Andy> match the text then we fix whichever one is broken. Nice in theory, but not nice in the IETF. 1) the IETF standards track provides strict controls on updating documents. 2) updates never happen quickly. The editor queue alone would be too long to change something. One solution would be to host the XSD elsewhere and reference it, but that's likely not acceptable from a standards process either. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 23 09:52:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21414 for ; Wed, 23 Mar 2005 09:52:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE72u-000Mtf-2J for netconf-data@psg.com; Wed, 23 Mar 2005 14:41:20 +0000 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE72i-000Msy-7B for netconf@ops.ietf.org; Wed, 23 Mar 2005 14:41:08 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2NEegZo003139; Wed, 23 Mar 2005 06:40:42 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77F2X3>; Wed, 23 Mar 2005 06:40:42 -0800 Message-ID: From: "McDonald, Ira" To: "'Wes Hardaker'" , Andy Bierman Cc: sberl@cisco.com, "'Randy Presuhn'" , netconf@ops.ietf.org Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Wed, 23 Mar 2005 06:40:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, About hosting the NetConf XSD elsewhere (than just the RFC): (1) As David Harrington just observed, this will be done anyway, just as now happens with MIBs (2) Even an 'official' hosting elsewhere (per the eventual NetConf RFC) isn't any help - because really almost no one _does_ read the RFC - they read the machine-readable portions out of context. (3) Repairing bugs in XSD hosted elsewhere is tricky, because XML in general and XSD in particular have serious unsolved problems of version control and identification - just overwriting an undated generic link for the XSD 'works', but not in any predictable way - each implementation may have picked up the XSD via that link at a different point in time. (4) If the 'bug' is determined to be in the sainted plaintext, then fixing the outboard XSD won't help at all. (5) As Wes Hardaker alludes to below, the RFC update, approval, and publication process is an order of magnitude too slow to be helpful. Cheers, - Ira PS - Separately from "version" in XML documents, the problem of "namespace" is awful. W3C and other standards organizations have no concensus solution. The current most widespread kludge is to _never_ change the "namespace" - but just keep putting more stuff in the latest "version" of the XSD in the same namespace. 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: Wes Hardaker [mailto:wjhns1@hardakers.net] Sent: Wednesday, March 23, 2005 1:29 AM To: Andy Bierman Cc: sberl@cisco.com; 'McDonald, Ira'; 'Randy Presuhn'; netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List Andy> Echoing one last word on XSD vs. plaintext -- if the XSD doesn't Andy> match the text then we fix whichever one is broken. Nice in theory, but not nice in the IETF. 1) the IETF standards track provides strict controls on updating documents. 2) updates never happen quickly. The editor queue alone would be too long to change something. One solution would be to host the XSD elsewhere and reference it, but that's likely not acceptable from a standards process either. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to netconf-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 Mar 23 10:22:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24686 for ; Wed, 23 Mar 2005 10:22:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE7ZI-0000sc-AV for netconf-data@psg.com; Wed, 23 Mar 2005 15:14:48 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DE7ZH-0000rb-3z for netconf@ops.ietf.org; Wed, 23 Mar 2005 15:14:47 +0000 Received: (qmail 26526 invoked by uid 78); 23 Mar 2005 15:14:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 15:14:40 -0000 Message-ID: <424187DC.3000904@andybierman.com> Date: Wed, 23 Mar 2005 07:14:36 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker CC: sberl@cisco.com, "'McDonald, Ira'" , "'Randy Presuhn'" , netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <200503230140.BDF05768@mira-sjc5-b.cisco.com> <4240DFD5.2050307@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Wes Hardaker wrote: >Andy> Echoing one last word on XSD vs. plaintext -- if the XSD doesn't >Andy> match the text then we fix whichever one is broken. > >Nice in theory, but not nice in the IETF. > >1) the IETF standards track provides strict controls on updating documents. > >2) updates never happen quickly. The editor queue alone would be too > long to change something. > >One solution would be to host the XSD elsewhere and reference it, but >that's likely not acceptable from a standards process either. > > Solution? What problem are we trying to solve here? Have you found a problem with the XSD and text in disagreement? If so, post it to the list. This whole thread feels like an SNMP CLR discussion. You want to protect stupid programmers from themselves. If developers ignore arbitrary portions of the specification then their code probably won't work. 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 Mar 23 11:13:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01110 for ; Wed, 23 Mar 2005 11:13:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE8Kh-0006W2-2j for netconf-data@psg.com; Wed, 23 Mar 2005 16:03:47 +0000 Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE8KY-0006VK-Ft for netconf@ops.ietf.org; Wed, 23 Mar 2005 16:03:38 +0000 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <20050323160337016007quafe>; Wed, 23 Mar 2005 16:03:37 +0000 Reply-To: From: "David B Harrington" To: "'Wes Hardaker'" , "'Andy Bierman'" Cc: , "'McDonald, Ira'" , "'Randy Presuhn'" , Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Wed, 23 Mar 2005 11:03:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: thread-index: AcUvc1Vf4uDsZz42TKG8/LEFl85ZSAASq2TQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Hi, Since this group works on consensus, let me speak up and say I'm tired of this discussion and would like to move on. I suspect that is the consensus of the WG. I favor following the IETF standards track process: When the WG consensus is that the specification is sufficiently clear that people can implement the specs, then we should ask it to be published as a Proposed Standard. If the people in this thread find **specific** text or XSD or a combination of the two that they believe are ambiguous, please point out the relevant faulty clause and propose an alternative. The WG can decide whether to accept the proposed revision or not, and we can move on. If we miss ambiguities in the spec after publishing as a PS, we should fix the specs until we are satisfied we have resolved the ambiguities, and then should recycle the specs at Proposed. Does this take time? You betcha! That's why the IETF is respected as a standards body; they don't just rush things out the door, they take the time to test it for certain characteristics between stages in the process. If you think the process is too slow, then I suggest spending FAR less time in meta-discussions like this one, and focus on getting the specs right in the first place. This WG is not chartered to redesign the IETF process, or to impose new requirements on the existing IETF process. If you don't like the IETF standards track process, then I suggest you a) try to get the process changed by participating in the newtrk WG (rather than raising the issues in this WG), or b) develop your standards in other standards development organizations that are more to your liking. Can we move on now? David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Wes Hardaker > Sent: Wednesday, March 23, 2005 1:29 AM > To: Andy Bierman > Cc: sberl@cisco.com; 'McDonald, Ira'; 'Randy Presuhn'; > netconf@ops.ietf.org > Subject: Re: Proposed Resolution to PROT I-D Issues List > > > Andy> Echoing one last word on XSD vs. plaintext -- if the XSD doesn't > Andy> match the text then we fix whichever one is broken. > > Nice in theory, but not nice in the IETF. > > 1) the IETF standards track provides strict controls on > updating documents. > > 2) updates never happen quickly. The editor queue alone would be too > long to change something. > > One solution would be to host the XSD elsewhere and reference it, but > that's likely not acceptable from a standards process either. > > -- > "In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett > > -- > to 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 Mar 23 11:35:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03340 for ; Wed, 23 Mar 2005 11:35:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE8et-0008bS-7o for netconf-data@psg.com; Wed, 23 Mar 2005 16:24:39 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE8ee-0008aJ-5l for netconf@ops.ietf.org; Wed, 23 Mar 2005 16:24:24 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2005 08:24:24 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NGOLZV014230 for ; Wed, 23 Mar 2005 08:24:22 -0800 (PST) Received: from sberlw2k01 (sjc-vpn5-672.cisco.com [10.21.90.160]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDF51932; Wed, 23 Mar 2005 08:24:20 -0800 (PST) Message-Id: <200503231624.BDF51932@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Wed, 23 Mar 2005 08:24:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <4240DFD5.2050307@andybierman.com> thread-index: AcUvVxiFYOC287UJSEylXd/bnpxSpwAbKUvQ X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After a little more thought, the list of values needs to be more open ended. Can we just leave out that list. Here's some new replacement text: Any message that is not valid with respect to the XML schema in appendix B, is not a valid netconf message and MUST be rejected by the netconf server that receives it. In the the MUST be set to "error" and the MUST contain an error code indicating the reason for rejecting the message. -steve > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Tuesday, March 22, 2005 7:18 PM > To: sberl@cisco.com > Cc: 'McDonald, Ira'; 'Randy Presuhn'; netconf@ops.ietf.org > Subject: Re: Proposed Resolution to PROT I-D Issues List > > Steven Berl (sberl) wrote: > > >I would like to see text in the document that says something like: > > > >Any message that is not valid with respect to the XML schema in > >appendix B, is not a valid netconf message and MUST be > rejected by the > >netconf server that receives it. In the the > > MUST be set to "error" and the MUST > >contain one of INVALID_VALUE, MISSING_ATTRIBUTE, BAD_ATTRIBUTE, > >UNKNOWN_ATTRIBUTE, MISSING_ELEMENT, BAD_ELEMENT, or UNKNOWN_ELEMENT. > > > > > This is fine with me. > Echoing one last word on XSD vs. plaintext -- if the XSD > doesn't match the text then we fix whichever one is broken. > > BTW, the draft already says the XSD is normative for syntax. > (I think I wrote this paragraph ;-) > > From PROT-05, sec. 7, last para: > > The syntax and XML encoding of the protocol operations are formally > defined in the XML schema in Appendix B. The following sections > describe the semantics of each protocol operation. > > I think it would help if the XSD was annotated to indicate > which elements/values are associated with which capabilities. > > >-steve > > > > > Andy > > > > > > >>-----Original Message----- > >>From: owner-netconf@ops.ietf.org > >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > >>Sent: Tuesday, March 22, 2005 4:48 PM > >>To: McDonald, Ira > >>Cc: 'Randy Presuhn'; netconf@ops.ietf.org > >>Subject: Re: Proposed Resolution to PROT I-D Issues List > >> > >>McDonald, Ira wrote: > >> > >> > >> > >>>Hi, > >>> > >>>It would be nice if there were some agreement in this advice. > >>> > >>>Randy says the XSD *is* normative, but the plaintext wins in > >>> > >>> > >>conflicts > >> > >> > >>>(which Joel says is not true under the prevailing IESG > >>> > >>> > >>policy, because > >> > >> > >>>nothing but plaintext can be normative). > >>> > >>>Joel says the IESG doesn't bother much about labelling > parts of RFCs > >>>normative or informative (the RFC Editor certainly doesn't > >>> > >>> > >>agree with > >> > >> > >>>this one - a number of RFC's and I-Ds on proper RFC style > >>> > >>> > >>address which > >> > >> > >>>body parts and appendices are or should be normative). > >>> > >>>I liked Steve's formulation very much, but it's broken by the > >>>"plaintext always wins" rule. An incoming message could > >>> > >>> > >>_fail_ the XSD > >> > >> > >>>check and still be valid under ambiguously written plaintext body > >>>parts... > >>> > >>> > >>> > >>> > >>Are there specific portions of text that you are making > objections or > >>suggestions > >>for changes? We aren't going to change IESG policy on > this mailing > >>list. Unless > >>there are specific changes to the -05 draft to discuss > here, I think > >>this topic is closed. > >> > >> > >> > >>>Cheers, > >>>- Ira > >>> > >>> > >>> > >>> > >>Andy > >> > >> > >> > >>>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: Tuesday, March 22, 2005 1:36 PM > >>>To: netconf@ops.ietf.org > >>>Subject: Re: Proposed Resolution to PROT I-D Issues List > >>> > >>> > >>>Hi - > >>> > >>> > >>> > >>> > >>> > >>>>From: "McDonald, Ira" > >>>>To: "'Joel M. Halpern'" ; "'Wes Hardaker'" > >>>> > >>>> > >>>> > >>>> > >>>; > >>> > >>> > >>> > >>> > >>>>Cc: "'Andy Bierman'" ; > >>>>Sent: Tuesday, March 22, 2005 5:27 AM > >>>>Subject: RE: Proposed Resolution to PROT I-D Issues List > >>>> > >>>> > >>>> > >>>> > >>>... > >>> > >>> > >>> > >>> > >>>>Joel, Randy, Wes, et al - could you please explain to > this list how > >>>>XSD is useful in NetConf if it's not Normative? > >>>> > >>>> > >>>> > >>>> > >>>... > >>> > >>>It *is* normative. It's just that in the case of conflict or > >>>ambiguity, the English takes precedence. This is as it > >>> > >>> > >>should be. I > >> > >> > >>>recall fixing errors in ASN.1 and MIB modules, where the fix was > >>>justified by the fact that the English text captured the WG > >>> > >>> > >>intent and > >> > >> > >>>the formal notation said something else. This routinely > >>> > >>> > >>happens during > >> > >> > >>>MIB review cycles. > >>> > >>>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: > >>> > >>>-- > >>>to unsubscribe send a message to > >>> > >>> > >>netconf-request@ops.ietf.org with the > >> > >> > >>>word 'unsubscribe' in a single line as the message text body. > >>>archive: > >>> > >>> > >>> > >>> > >>> > >>> > >>-- > >>to unsubscribe send a message to > netconf-request@ops.ietf.org with the > >>word 'unsubscribe' in a single line as the message text body. > >>archive: > >> > >> > >> > > > >-- > >to unsubscribe send a message to > netconf-request@ops.ietf.org with the > >word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 23 12:16:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08174 for ; Wed, 23 Mar 2005 12:16:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE9JW-000ESx-Qf for netconf-data@psg.com; Wed, 23 Mar 2005 17:06:38 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE9J7-000EPU-RT for netconf@ops.ietf.org; Wed, 23 Mar 2005 17:06:13 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2005 09:06:10 -0800 X-IronPort-AV: i="3.91,115,1110182400"; d="scan'208"; a="239489438:sNHT4956302442" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NH67ZV000858 for ; Wed, 23 Mar 2005 09:06:08 -0800 (PST) Received: from sberlw2k01 (sjc-vpn5-672.cisco.com [10.21.90.160]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDF55646; Wed, 23 Mar 2005 09:06:06 -0800 (PST) Message-Id: <200503231706.BDF55646@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: Subject: Expected behavior when XML is not well formed? Date: Wed, 23 Mar 2005 09:06:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 thread-index: AcUvyphBb59gSedSTNi28CgOPQuo/Q== X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit - Should a netconf server require messages it receives to contain the XML declaration ()? I think the answer is no. But to quote RFC3470: Protocol specifications must be clear about use of XML declarations. XML [8] notes that "XML documents should begin with an XML declaration which specifies the version of XML being used." In general, an XML declaration should be encouraged ("SHOULD be present") and must always be allowed ("MAY be sent"). An XML declaration should be required in cases where, if allowed, the character encoding is anything other than UTF-8 or UTF-16. So we probably want to include some text like: Netconf messages MAY contain an XML declaration. If it is not present, the server is to assume that the messages is xml version="1.0" and the encoding="UTF-8". If the XML declaration is present, it is left to the implementation to decide if the values of version and encoding are acceptable. If the implementation chooses to reject the message it should do so by sending an with an value of ??? (INVALID_VALUE?) - Should a netconf server include the XML declaration in messages that it sends out? Is it left to the implementation to decide this? I think it is left to the implemenation, but we probably need to say that explicitly someplace. What should a netconf server do when it receives an XML message that is not well formed? Should it send an or not? If it does: - Should it leave out the message-id attribute? Probably yes - What value should it use? I don't see any particular error code in appendix A that seems to fit this case of XML that is not well formed. Do we need to add another error to the list? Do we want to add a generic OTHER_ERROR to the list in appendix B for things that don't fit cleanly into the defined values? -- to unsubscribe send a message to netconf-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 Mar 23 12:18:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08657 for ; Wed, 23 Mar 2005 12:18:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE9Ia-000EKt-Ng for netconf-data@psg.com; Wed, 23 Mar 2005 17:05:40 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DE9IT-000EJF-El for netconf@ops.ietf.org; Wed, 23 Mar 2005 17:05:33 +0000 Received: (qmail 5366 invoked by uid 78); 23 Mar 2005 16:55:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 16:55:05 -0000 Message-ID: <42419F68.5010603@andybierman.com> Date: Wed, 23 Mar 2005 08:55:04 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: reporting multiple rpc-errors Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The section on and its XSD fragment are wrong in the -05 draft. The following text (or something like it) should be added to sec. 4.3: If an agent encounters multiple errors during the processing of an request, the MAY contain multiple elements. However, an agent is not required to detect or report more than one element, if a request contains multiple errors. An agent is not required to check for particular error conditions in a specific sequence. An agent MUST return an element if any error conditions occur during processing, and SHOULD return an element if any warning conditions occur during processing. Here is the XSD for : 1) The element should have maxOccurs="unbounded" specified. 2) This XSD design 'choice' doesn't allow for errors/warnings and data to be returned (just one or the other). This is broken. It doesn't allow for the 'ignore-error' error-option in the operation. I think this XSD is more what we wanted when we designed the operation: Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 23 12:20:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09108 for ; Wed, 23 Mar 2005 12:20:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE9OT-000F77-Kq for netconf-data@psg.com; Wed, 23 Mar 2005 17:11:45 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE9OS-000F6u-No for netconf@ops.ietf.org; Wed, 23 Mar 2005 17:11:44 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2005 09:11:45 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NHBgZV008731 for ; Wed, 23 Mar 2005 09:11:42 -0800 (PST) Received: from sberlw2k01 (sjc-vpn5-672.cisco.com [10.21.90.160]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDF56370; Wed, 23 Mar 2005 09:11:41 -0800 (PST) Message-Id: <200503231711.BDF56370@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: Subject: Unknown xmlns? Date: Wed, 23 Mar 2005 09:11:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 thread-index: AcUvy2GA7Aex8csjRAWSHCVeH7378w== X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit What should the contain if an rpc request contains an xmlns declaration refering to a namespace that is unknown to the server? Is this another INVALID_VALUE? -steve -- to unsubscribe send a message to netconf-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 Mar 23 12:28:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09938 for ; Wed, 23 Mar 2005 12:28:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE9WQ-000GKi-Lb for netconf-data@psg.com; Wed, 23 Mar 2005 17:19:58 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE9WM-000GJy-JA for netconf@ops.ietf.org; Wed, 23 Mar 2005 17:19:54 +0000 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <2005032317195301100suiqqe>; Wed, 23 Mar 2005 17:19:54 +0000 Reply-To: From: "David B Harrington" To: "'McDonald, Ira'" , "'Wes Hardaker'" , "'Andy Bierman'" Cc: , "'Randy Presuhn'" , Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Wed, 23 Mar 2005 12:19:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: thread-index: AcUvt/JE1d0d98FeSsO3NX4T9bWLNAACrhuA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Hi, Let me expand on my earlier comment. The XSD will likely be distributed separated from the RFC, just as happens with MIB modules, if certain conditions arise, which have arisen with MIB modules. Separate distribution is likely to occur if: 1) compilers and tools do not adequately distinguish the XSD from the rest of the document programmatically, and require that the XSD be separated from the surrounding text before processing, 2) multiple XSD specifications can exist within a document and available tools are not able to deal with this, 3) XSDs are fairly easy to produce that are good enough for most use cases, but RFCs are burdensome to produce because of boilerplates, id-nits, MIB Doctor reviews, and other IETF-publication-process CLRs, 4) XSDs are fairly easy to produce that are good enough for most use cases, and vendor-specific XSDs are produced without all the unnecessary boilerplates, id-nits, MIB Doctor reviews, and other junk that do not necessarily help vendors implement products, sell products and get them to market before their competitors, and the extra junk does not actually help their customers manage their networks, and 5) XSDs are unambiguous enough for operators to use, and operators' tools to use programmatically, even if correct implementation might have required referencing the surrounding text. I think this last point is very important - I do not believe most implementors work with only the MIB module; they also read the RFC. Vendors distribute the stripped MIB modules to operators, because the MIB modules alone are often good enough to meet the requirements of operators and operators' tools, and the extra stuff is often available in RFCs or product release notes or customer support. But these points are all meta-discussion mostly unrelated to this WG's deliverables. I suggest that this WG develop specs that **support** the separate distribution of the XSD from the RFC, and design the XSD to address the potential issues caused by separate distribution. Let's make sure 1) the XSD contains a clearly marked version, preferably machine-parseable. 2) the XSD can be programmtically separated from the surrounding RFC text reliably. 3) the XSD contains enough information to be meaningful to operators and their tools. David Harrington dbharrington@comcast.net -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 23 12:43:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11376 for ; Wed, 23 Mar 2005 12:43:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE9n3-000Inp-S3 for netconf-data@psg.com; Wed, 23 Mar 2005 17:37:09 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE9n2-000InZ-VG for netconf@ops.ietf.org; Wed, 23 Mar 2005 17:37:08 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2005 09:36:50 -0800 X-IronPort-AV: i="3.91,115,1110182400"; d="scan'208"; a="622264225:sNHT1685397004" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2NHamDr027277 for ; Wed, 23 Mar 2005 09:36:48 -0800 (PST) Received: from [212.254.247.4] (ams-clip-vpn-dhcp287.cisco.com [10.61.65.31]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2NHTUrL024805 for ; Wed, 23 Mar 2005 09:29:31 -0800 Message-ID: <4241A92E.1070902@cisco.com> Date: Wed, 23 Mar 2005 18:36:46 +0100 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: notifications X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111598971.871653"; x:"432200"; a:"rsa-sha1"; b:"nofws:500"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"l44Qnfx+CBLp3ovJa3QdKhwrGQC/g/k+6NMCyrqu4WJzCB/in/K3IsxoSL2jt+BsKnC8VWFQ" "r62/8oVtJq+JPSnsiuM3VyosTZNyMzfRFqXLZQDQDDvQt83vknu73GHZ5YySP8zxxvxE0OVwd58" "qObyxg+avFPr1bFkIgDyw8QE="; c:"Date: Wed, 23 Mar 2005 18:36:46 +0100"; c:"From: Eliot Lear "; c:"Subject: notifications" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, We had notifications in the core document, but we removed them. In addition, the SSH mapping will not support them, as I recall. At one point notifications were based on the RFC 3195 BEEP Profile. As we begin to look at new capabilities, we need to figure out how the documents need to appear. As it currently stands, I have developed two documents, one which describes a very generic capability, and a BEEP mapping that can refer to RFC 3195. Referring to that RFC, there are two defined profiles defined - raw and cooked. Both are a bit raw :-( I do not believe we want to define a new profile. Do we? Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 23 12:46:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11684 for ; Wed, 23 Mar 2005 12:46:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE9qo-000JNq-51 for netconf-data@psg.com; Wed, 23 Mar 2005 17:41:02 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE9qm-000JMd-3v for netconf@ops.ietf.org; Wed, 23 Mar 2005 17:41:00 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2005 09:40:14 -0800 X-IronPort-AV: i="3.91,115,1110182400"; d="scan'208"; a="239511617:sNHT4672258938" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2NHe9gE002550 for ; Wed, 23 Mar 2005 09:40:10 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZI39072; Wed, 23 Mar 2005 09:40:11 -0800 (PST) Message-ID: <4241A9FA.5080506@cisco.com> Date: Wed, 23 Mar 2005 10:40:10 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Netconf operation definitions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, following up on the previous discussions and the suggestion to identify areas where there may be discrepancies between the text and the XSD. 1) The current get-config definition for source says: "source: Name of the configuration datastore being queried, such as . If this element is unspecified, the configuration is used." The definition for get-config the XSD includes element source which is of type rpcOperationSourceType. One of the choices is "config" which is config-inlineType My suggestion would be for the XSD definition to be modified to not allow this since a definition change can be made to enforce what the text says. 2) rpc element description. I think this was already brought up but just to make sure it's captured "If additional attributes are present in an element, a NETCONF peer must return them unmodified in the element." The XSD does not include definitions for additional attributes Slightly out of subject but related to XSDs 3) Naming conventions There seems to be two different naming conventions followed in the XSD (for first word first letter is lower case then use upper case for first letter of sub-sequent words - rpcOperationSourceType) and also dash "-" separated words (config-inlineType and get-config) For consistency purposes it may be good if one of the naming conventions was followed instead of inter-mixing. The former? -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 -- to unsubscribe send a message to netconf-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 Mar 23 12:58:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12949 for ; Wed, 23 Mar 2005 12:58:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEA1e-000LEY-Fp for netconf-data@psg.com; Wed, 23 Mar 2005 17:52:14 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEA1d-000LEC-FN for netconf@ops.ietf.org; Wed, 23 Mar 2005 17:52:13 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2005 09:50:10 -0800 X-IronPort-AV: i="3.91,115,1110182400"; d="scan'208"; a="622273879:sNHT1862928712" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NHo7ZV021081 for ; Wed, 23 Mar 2005 09:50:08 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZI40419; Wed, 23 Mar 2005 09:50:07 -0800 (PST) Message-ID: <4241AC4D.50301@cisco.com> Date: Wed, 23 Mar 2005 10:50:05 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: Netconf operation definitions References: <4241A9FA.5080506@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hector Trevino wrote: > > Hi, following up on the previous discussions and the suggestion to > identify areas where there may be discrepancies between the text and > the XSD. > > > 1) The current get-config definition for source says: > > "source: > > Name of the configuration datastore being queried, such as > . If this element is unspecified, the > configuration is used." > > The definition for get-config the XSD includes element source which is > of type rpcOperationSourceType. One of the choices is "config" which > is config-inlineType Forgot to include the url element here > > > > > > > > > > > My suggestion would be for the XSD definition to be modified to not > allow this since a definition change can be made to enforce what the > text says. > > > 2) rpc element description. I think this was already brought up but > just to make sure it's captured > > "If additional attributes are present in an element, a NETCONF > peer must return them unmodified in the element." > > The XSD does not include definitions for additional attributes > > > Slightly out of subject but related to XSDs > > 3) Naming conventions > There seems to be two different naming conventions followed in the XSD > (for first word first letter is lower case then use upper case for > first letter of sub-sequent words - rpcOperationSourceType) and also > dash "-" separated words (config-inlineType and get-config) > > For consistency purposes it may be good if one of the naming > conventions was followed instead of inter-mixing. The former? > > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 -- to unsubscribe send a message to netconf-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 Mar 23 13:15:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15268 for ; Wed, 23 Mar 2005 13:15:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEAHc-000O2j-46 for netconf-data@psg.com; Wed, 23 Mar 2005 18:08:44 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DEAHW-000O25-KB for netconf@ops.ietf.org; Wed, 23 Mar 2005 18:08:38 +0000 Received: (qmail 29524 invoked by uid 78); 23 Mar 2005 17:43:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 17:43:11 -0000 Message-ID: <4241AAAE.9070303@andybierman.com> Date: Wed, 23 Mar 2005 09:43:10 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sberl@cisco.com CC: netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <200503231624.BDF51932@mira-sjc5-b.cisco.com> In-Reply-To: <200503231624.BDF51932@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steven Berl (sberl) wrote: >After a little more thought, the list of values needs to be more >open ended. Can we just leave out that list. Here's some new replacement >text: > >Any message that is not valid with respect to the XML schema in appendix B, >is not a valid netconf message and MUST be rejected by the netconf server >that receives it. In the the MUST be set to >"error" and the MUST contain an error code indicating the reason >for rejecting the message. > > I strongly object to this proposal to remove the standard errors from NETCONF. There are plenty of ways for vendors to add their own error information if they want. >-steve > > Andy > > >>-----Original Message----- >>From: Andy Bierman [mailto:ietf@andybierman.com] >>Sent: Tuesday, March 22, 2005 7:18 PM >>To: sberl@cisco.com >>Cc: 'McDonald, Ira'; 'Randy Presuhn'; netconf@ops.ietf.org >>Subject: Re: Proposed Resolution to PROT I-D Issues List >> >>Steven Berl (sberl) wrote: >> >> >> >>>I would like to see text in the document that says something like: >>> >>>Any message that is not valid with respect to the XML schema in >>>appendix B, is not a valid netconf message and MUST be >>> >>> >>rejected by the >> >> >>>netconf server that receives it. In the the >>> MUST be set to "error" and the MUST >>>contain one of INVALID_VALUE, MISSING_ATTRIBUTE, BAD_ATTRIBUTE, >>>UNKNOWN_ATTRIBUTE, MISSING_ELEMENT, BAD_ELEMENT, or UNKNOWN_ELEMENT. >>> >>> >>> >>> >>This is fine with me. >>Echoing one last word on XSD vs. plaintext -- if the XSD >>doesn't match the text then we fix whichever one is broken. >> >>BTW, the draft already says the XSD is normative for syntax. >>(I think I wrote this paragraph ;-) >> >> From PROT-05, sec. 7, last para: >> >> The syntax and XML encoding of the protocol operations are formally >> defined in the XML schema in Appendix B. The following sections >> describe the semantics of each protocol operation. >> >>I think it would help if the XSD was annotated to indicate >>which elements/values are associated with which capabilities. >> >> >> >>>-steve >>> >>> >>> >>> >>Andy >> >> >> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: owner-netconf@ops.ietf.org >>>>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>>>Sent: Tuesday, March 22, 2005 4:48 PM >>>>To: McDonald, Ira >>>>Cc: 'Randy Presuhn'; netconf@ops.ietf.org >>>>Subject: Re: Proposed Resolution to PROT I-D Issues List >>>> >>>>McDonald, Ira wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>It would be nice if there were some agreement in this advice. >>>>> >>>>>Randy says the XSD *is* normative, but the plaintext wins in >>>>> >>>>> >>>>> >>>>> >>>>conflicts >>>> >>>> >>>> >>>> >>>>>(which Joel says is not true under the prevailing IESG >>>>> >>>>> >>>>> >>>>> >>>>policy, because >>>> >>>> >>>> >>>> >>>>>nothing but plaintext can be normative). >>>>> >>>>>Joel says the IESG doesn't bother much about labelling >>>>> >>>>> >>parts of RFCs >> >> >>>>>normative or informative (the RFC Editor certainly doesn't >>>>> >>>>> >>>>> >>>>> >>>>agree with >>>> >>>> >>>> >>>> >>>>>this one - a number of RFC's and I-Ds on proper RFC style >>>>> >>>>> >>>>> >>>>> >>>>address which >>>> >>>> >>>> >>>> >>>>>body parts and appendices are or should be normative). >>>>> >>>>>I liked Steve's formulation very much, but it's broken by the >>>>>"plaintext always wins" rule. An incoming message could >>>>> >>>>> >>>>> >>>>> >>>>_fail_ the XSD >>>> >>>> >>>> >>>> >>>>>check and still be valid under ambiguously written plaintext body >>>>>parts... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Are there specific portions of text that you are making >>>> >>>> >>objections or >> >> >>>>suggestions >>>>for changes? We aren't going to change IESG policy on >>>> >>>> >>this mailing >> >> >>>>list. Unless >>>>there are specific changes to the -05 draft to discuss >>>> >>>> >>here, I think >> >> >>>>this topic is closed. >>>> >>>> >>>> >>>> >>>> >>>>>Cheers, >>>>>- Ira >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Andy >>>> >>>> >>>> >>>> >>>> >>>>>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: Tuesday, March 22, 2005 1:36 PM >>>>>To: netconf@ops.ietf.org >>>>>Subject: Re: Proposed Resolution to PROT I-D Issues List >>>>> >>>>> >>>>>Hi - >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>From: "McDonald, Ira" >>>>>>To: "'Joel M. Halpern'" ; "'Wes Hardaker'" >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>; >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Cc: "'Andy Bierman'" ; >>>>>>Sent: Tuesday, March 22, 2005 5:27 AM >>>>>>Subject: RE: Proposed Resolution to PROT I-D Issues List >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Joel, Randy, Wes, et al - could you please explain to >>>>>> >>>>>> >>this list how >> >> >>>>>>XSD is useful in NetConf if it's not Normative? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>... >>>>> >>>>>It *is* normative. It's just that in the case of conflict or >>>>>ambiguity, the English takes precedence. This is as it >>>>> >>>>> >>>>> >>>>> >>>>should be. I >>>> >>>> >>>> >>>> >>>>>recall fixing errors in ASN.1 and MIB modules, where the fix was >>>>>justified by the fact that the English text captured the WG >>>>> >>>>> >>>>> >>>>> >>>>intent and >>>> >>>> >>>> >>>> >>>>>the formal notation said something else. This routinely >>>>> >>>>> >>>>> >>>>> >>>>happens during >>>> >>>> >>>> >>>> >>>>>MIB review cycles. >>>>> >>>>>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: >>>>> >>>>>-- >>>>>to unsubscribe send a message to >>>>> >>>>> >>>>> >>>>> >>>>netconf-request@ops.ietf.org with the >>>> >>>> >>>> >>>> >>>>>word 'unsubscribe' in a single line as the message text body. >>>>>archive: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>to unsubscribe send a message to >>>> >>>> >>netconf-request@ops.ietf.org with the >> >> >>>>word 'unsubscribe' in a single line as the message text body. >>>>archive: >>>> >>>> >>>> >>>> >>>> >>>-- >>>to unsubscribe send a message to >>> >>> >>netconf-request@ops.ietf.org with the >> >> >>>word 'unsubscribe' in a single line as the message text body. >>>archive: >>> >>> >>> >>> >>> >>> > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 23 13:22:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15820 for ; Wed, 23 Mar 2005 13:22:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEAQB-000PLn-4c for netconf-data@psg.com; Wed, 23 Mar 2005 18:17:35 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DEAQ9-000PLX-V8 for netconf@ops.ietf.org; Wed, 23 Mar 2005 18:17:34 +0000 Received: (qmail 4863 invoked by uid 78); 23 Mar 2005 18:17:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 18:17:25 -0000 Message-ID: <4241B2B4.1080306@andybierman.com> Date: Wed, 23 Mar 2005 10:17:24 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: netconf Subject: Re: notifications References: <4241A92E.1070902@cisco.com> In-Reply-To: <4241A92E.1070902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: > All, > > We had notifications in the core document, but we removed them. In > addition, the SSH mapping will not support them, as I recall. > > At one point notifications were based on the RFC 3195 BEEP Profile. > As we begin to look at new capabilities, we need to figure out how the > documents need to appear. > > As it currently stands, I have developed two documents, one which > describes a very generic capability, and a BEEP mapping that can refer > to RFC 3195. Referring to that RFC, there are two defined profiles > defined - raw and cooked. Both are a bit raw :-( > > I do not believe we want to define a new profile. Do we? No. I would really like to get our 4 WG drafts done before discussing extensions. We can't change the BEEP draft now for features we will consider adding in the future. > > Eliot Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Mar 23 13:25:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16075 for ; Wed, 23 Mar 2005 13:25:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEARm-000PWJ-V6 for netconf-data@psg.com; Wed, 23 Mar 2005 18:19:14 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEARl-000PVv-GJ for netconf@ops.ietf.org; Wed, 23 Mar 2005 18:19:13 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2005 10:18:44 -0800 X-IronPort-AV: i="3.91,115,1110182400"; d="scan'208"; a="239530105:sNHT1085556026" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2NIIcDr009222; Wed, 23 Mar 2005 10:18:39 -0800 (PST) Received: from sberlw2k01 (sjc-vpn5-672.cisco.com [10.21.90.160]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDF64445; Wed, 23 Mar 2005 10:18:40 -0800 (PST) Message-Id: <200503231818.BDF64445@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Andy Bierman'" Cc: Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Wed, 23 Mar 2005 10:18:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <4241AAAE.9070303@andybierman.com> thread-index: AcUv02UO9TE3y6ZEQv6jfO3QDz6eHgAAIogw X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Wednesday, March 23, 2005 9:43 AM > To: sberl@cisco.com > Cc: netconf@ops.ietf.org > Subject: Re: Proposed Resolution to PROT I-D Issues List > > Steven Berl (sberl) wrote: > > >After a little more thought, the list of values > needs to be > >more open ended. Can we just leave out that list. Here's some new > >replacement > >text: > > > >Any message that is not valid with respect to the XML schema in > >appendix B, is not a valid netconf message and MUST be > rejected by the > >netconf server that receives it. In the the > > MUST be set to "error" and the MUST > >contain an error code indicating the reason for rejecting > the message. > > > > > I strongly object to this proposal to remove the standard > errors from NETCONF. > There are plenty of ways for vendors to add their own error > information if they want. I think you misunderstood what I was proposing. I am not suggesting to remove the errors from NETCONF. I am just suggesting that we not be too specific about which subset of those errors are allowed to be returned in this particular error situation (XML not valid with respect to the schema). The reason I want to leave this clause out is that the list I sent in the original proposed replacement text 1) doesn't cover all cases where the XML is not valid, and 2) the granularity of how specific the error which can be reported will depend on the details of the implementations XML parser. -steve > > >-steve > > > > > Andy > > > > > > >>-----Original Message----- > >>From: Andy Bierman [mailto:ietf@andybierman.com] > >>Sent: Tuesday, March 22, 2005 7:18 PM > >>To: sberl@cisco.com > >>Cc: 'McDonald, Ira'; 'Randy Presuhn'; netconf@ops.ietf.org > >>Subject: Re: Proposed Resolution to PROT I-D Issues List > >> > >>Steven Berl (sberl) wrote: > >> > >> > >> > >>>I would like to see text in the document that says something like: > >>> > >>>Any message that is not valid with respect to the XML schema in > >>>appendix B, is not a valid netconf message and MUST be > >>> > >>> > >>rejected by the > >> > >> > >>>netconf server that receives it. In the the > >>> MUST be set to "error" and the MUST > >>>contain one of INVALID_VALUE, MISSING_ATTRIBUTE, BAD_ATTRIBUTE, > >>>UNKNOWN_ATTRIBUTE, MISSING_ELEMENT, BAD_ELEMENT, or > UNKNOWN_ELEMENT. > >>> > >>> > >>> > >>> > >>This is fine with me. > >>Echoing one last word on XSD vs. plaintext -- if the XSD > doesn't match > >>the text then we fix whichever one is broken. > >> > >>BTW, the draft already says the XSD is normative for syntax. > >>(I think I wrote this paragraph ;-) > >> > >> From PROT-05, sec. 7, last para: > >> > >> The syntax and XML encoding of the protocol operations > are formally > >> defined in the XML schema in Appendix B. The following sections > >> describe the semantics of each protocol operation. > >> > >>I think it would help if the XSD was annotated to indicate which > >>elements/values are associated with which capabilities. > >> > >> > >> > >>>-steve > >>> > >>> > >>> > >>> > >>Andy > >> > >> > >> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: owner-netconf@ops.ietf.org > >>>>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > >>>>Sent: Tuesday, March 22, 2005 4:48 PM > >>>>To: McDonald, Ira > >>>>Cc: 'Randy Presuhn'; netconf@ops.ietf.org > >>>>Subject: Re: Proposed Resolution to PROT I-D Issues List > >>>> > >>>>McDonald, Ira wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>It would be nice if there were some agreement in this advice. > >>>>> > >>>>>Randy says the XSD *is* normative, but the plaintext wins in > >>>>> > >>>>> > >>>>> > >>>>> > >>>>conflicts > >>>> > >>>> > >>>> > >>>> > >>>>>(which Joel says is not true under the prevailing IESG > >>>>> > >>>>> > >>>>> > >>>>> > >>>>policy, because > >>>> > >>>> > >>>> > >>>> > >>>>>nothing but plaintext can be normative). > >>>>> > >>>>>Joel says the IESG doesn't bother much about labelling > >>>>> > >>>>> > >>parts of RFCs > >> > >> > >>>>>normative or informative (the RFC Editor certainly doesn't > >>>>> > >>>>> > >>>>> > >>>>> > >>>>agree with > >>>> > >>>> > >>>> > >>>> > >>>>>this one - a number of RFC's and I-Ds on proper RFC style > >>>>> > >>>>> > >>>>> > >>>>> > >>>>address which > >>>> > >>>> > >>>> > >>>> > >>>>>body parts and appendices are or should be normative). > >>>>> > >>>>>I liked Steve's formulation very much, but it's broken by the > >>>>>"plaintext always wins" rule. An incoming message could > >>>>> > >>>>> > >>>>> > >>>>> > >>>>_fail_ the XSD > >>>> > >>>> > >>>> > >>>> > >>>>>check and still be valid under ambiguously written > plaintext body > >>>>>parts... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Are there specific portions of text that you are making > >>>> > >>>> > >>objections or > >> > >> > >>>>suggestions > >>>>for changes? We aren't going to change IESG policy on > >>>> > >>>> > >>this mailing > >> > >> > >>>>list. Unless > >>>>there are specific changes to the -05 draft to discuss > >>>> > >>>> > >>here, I think > >> > >> > >>>>this topic is closed. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Cheers, > >>>>>- Ira > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Andy > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>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: Tuesday, March 22, 2005 1:36 PM > >>>>>To: netconf@ops.ietf.org > >>>>>Subject: Re: Proposed Resolution to PROT I-D Issues List > >>>>> > >>>>> > >>>>>Hi - > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>From: "McDonald, Ira" > >>>>>>To: "'Joel M. Halpern'" ; "'Wes > Hardaker'" > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>; > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Cc: "'Andy Bierman'" ; > > >>>>>>Sent: Tuesday, March 22, 2005 5:27 AM > >>>>>>Subject: RE: Proposed Resolution to PROT I-D Issues List > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Joel, Randy, Wes, et al - could you please explain to > >>>>>> > >>>>>> > >>this list how > >> > >> > >>>>>>XSD is useful in NetConf if it's not Normative? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>... > >>>>> > >>>>>It *is* normative. It's just that in the case of conflict or > >>>>>ambiguity, the English takes precedence. This is as it > >>>>> > >>>>> > >>>>> > >>>>> > >>>>should be. I > >>>> > >>>> > >>>> > >>>> > >>>>>recall fixing errors in ASN.1 and MIB modules, where the fix was > >>>>>justified by the fact that the English text captured the WG > >>>>> > >>>>> > >>>>> > >>>>> > >>>>intent and > >>>> > >>>> > >>>> > >>>> > >>>>>the formal notation said something else. This routinely > >>>>> > >>>>> > >>>>> > >>>>> > >>>>happens during > >>>> > >>>> > >>>> > >>>> > >>>>>MIB review cycles. > >>>>> > >>>>>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: > >>>>> > >>>>>-- > >>>>>to unsubscribe send a message to > >>>>> > >>>>> > >>>>> > >>>>> > >>>>netconf-request@ops.ietf.org with the > >>>> > >>>> > >>>> > >>>> > >>>>>word 'unsubscribe' in a single line as the message text body. > >>>>>archive: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>to unsubscribe send a message to > >>>> > >>>> > >>netconf-request@ops.ietf.org with the > >> > >> > >>>>word 'unsubscribe' in a single line as the message text body. > >>>>archive: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>-- > >>>to unsubscribe send a message to > >>> > >>> > >>netconf-request@ops.ietf.org with the > >> > >> > >>>word 'unsubscribe' in a single line as the message text body. > >>>archive: > >>> > >>> > >>> > >>> > >>> > >>> > > > >-- > >to unsubscribe send a message to > netconf-request@ops.ietf.org with the > >word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Mar 23 13:51:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18983 for ; Wed, 23 Mar 2005 13:51:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEAoc-0003Mc-RV for netconf-data@psg.com; Wed, 23 Mar 2005 18:42:50 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DEAoT-0003Ln-H8 for netconf@ops.ietf.org; Wed, 23 Mar 2005 18:42:41 +0000 Received: (qmail 19275 invoked by uid 78); 23 Mar 2005 18:41:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 18:41:30 -0000 Message-ID: <4241B859.5010202@andybierman.com> Date: Wed, 23 Mar 2005 10:41:29 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sberl@cisco.com CC: netconf@ops.ietf.org Subject: Re: Proposed Resolution to PROT I-D Issues List References: <200503231818.BDF64445@mira-sjc5-b.cisco.com> In-Reply-To: <200503231818.BDF64445@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steven Berl (sberl) wrote: > > > > >>-----Original Message----- >>From: Andy Bierman [mailto:ietf@andybierman.com] >>Sent: Wednesday, March 23, 2005 9:43 AM >>To: sberl@cisco.com >>Cc: netconf@ops.ietf.org >>Subject: Re: Proposed Resolution to PROT I-D Issues List >> >>Steven Berl (sberl) wrote: >> >> >> >>>After a little more thought, the list of values >>> >>> >>needs to be >> >> >>>more open ended. Can we just leave out that list. Here's some new >>>replacement >>>text: >>> >>>Any message that is not valid with respect to the XML schema in >>>appendix B, is not a valid netconf message and MUST be >>> >>> >>rejected by the >> >> >>>netconf server that receives it. In the the >>> MUST be set to "error" and the MUST >>>contain an error code indicating the reason for rejecting >>> >>> >>the message. >> >> >>> >>> >>> >>> >>I strongly object to this proposal to remove the standard >>errors from NETCONF. >>There are plenty of ways for vendors to add their own error >>information if they want. >> >> > >I think you misunderstood what I was proposing. I am not suggesting to >remove the errors from NETCONF. I am just suggesting that we not be too >specific about which subset of those errors are allowed to be returned in >this particular error situation (XML not valid with respect to the schema). > >The reason I want to leave this clause out is that the list I sent in the >original proposed replacement text 1) doesn't cover all cases where the XML >is not valid, and 2) the granularity of how specific the error which can be >reported will depend on the details of the implementations XML parser. > > Okay. I thought you wanted to remove the error list appendix. I'm not clear about the exact text you want to replace. As per my previous email on multiple rpc-errors, I am not that concerned that every agent process messages and return errors in exactly the same manner. I want to avoid implementation specification in the standard. The important thing is that it is clear in the standard what constitutes valid and invalid messages. Do you think we need any special error codes for namespaces? (e.g., MISSING_NAMESPACE, UNKNOWN_NAMESPACE) >-steve > > 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 Mar 23 14:05:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20319 for ; Wed, 23 Mar 2005 14:05:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEB2X-0005aI-CJ for netconf-data@psg.com; Wed, 23 Mar 2005 18:57:13 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DEB2W-0005a0-5c for netconf@ops.ietf.org; Wed, 23 Mar 2005 18:57:12 +0000 Received: (qmail 5035 invoked by uid 78); 23 Mar 2005 18:57:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 23 Mar 2005 18:57:11 -0000 Message-ID: <4241BC07.2060506@andybierman.com> Date: Wed, 23 Mar 2005 10:57:11 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hector Trevino CC: netconf@ops.ietf.org Subject: Re: Netconf operation definitions References: <4241A9FA.5080506@cisco.com> In-Reply-To: <4241A9FA.5080506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hector Trevino wrote: > > Hi, following up on the previous discussions and the suggestion to > identify areas where there may be discrepancies between the text and > the XSD. > > > 1) The current get-config definition for source says: > > "source: > > Name of the configuration datastore being queried, such as > . If this element is unspecified, the > configuration is used." > > The definition for get-config the XSD includes element source which is > of type rpcOperationSourceType. One of the choices is "config" which > is config-inlineType > > > > > > > > > > My suggestion would be for the XSD definition to be modified to not > allow this since a definition change can be made to enforce what the > text says. I think the text and XSD are both wrong here, since we changed the operation to add the parameter. It doesn't make sense for the source to be inline configuration XML (choice=config). That made sense before we moved the filter specification to its own parameter. The 'source' parameter needs to be changed to 'target', and the type is changed from rpcOperationSourceType to rpcOperationTargetType. Here is the XSD from the draft to point out the difference: > > > 2) rpc element description. I think this was already brought up but > just to make sure it's captured > > "If additional attributes are present in an element, a NETCONF > peer must return them unmodified in the element." > > The XSD does not include definitions for additional attributes Perhaps all other (non-standard) attributes would need to be specified with a namespace prefix? > > > Slightly out of subject but related to XSDs > > 3) Naming conventions > There seems to be two different naming conventions followed in the XSD > (for first word first letter is lower case then use upper case for > first letter of sub-sequent words - rpcOperationSourceType) and also > dash "-" separated words (config-inlineType and get-config) > > For consistency purposes it may be good if one of the naming > conventions was followed instead of inter-mixing. The former? I agree. We're only talking about changing the names of some complexTypes, not changing any on-the-wire syntax (elements names). The complexType naming should be more consistent. The "rpcOperationSourceType" style naming convention should be used throughout the XSD. (Not very important but this is the only chance to fix it.) > > 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 Mar 23 17:19:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29818 for ; Wed, 23 Mar 2005 17:19:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEE60-000Dk2-Oc for netconf-data@psg.com; Wed, 23 Mar 2005 22:13:00 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEE5y-000Djn-QE for netconf@ops.ietf.org; Wed, 23 Mar 2005 22:12:58 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2005 14:12:45 -0800 X-IronPort-AV: i="3.91,116,1110182400"; d="scan'208"; a="622390431:sNHT12884683598" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NMCfZV000603; Wed, 23 Mar 2005 14:12:42 -0800 (PST) Received: from sberlw2k01 (sjc-vpn5-672.cisco.com [10.21.90.160]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDF93916; Wed, 23 Mar 2005 14:12:40 -0800 (PST) Message-Id: <200503232212.BDF93916@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Andy Bierman'" , "'Hector Trevino'" Cc: Subject: RE: Netconf operation definitions Date: Wed, 23 Mar 2005 14:12:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <4241BC07.2060506@andybierman.com> thread-index: AcUv2lxtPuzP0Q3iR/qr/MD8vg2ubAAGpXcQ X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > > > 2) rpc element description. I think this was already brought up but > > just to make sure it's captured > > > > "If additional attributes are present in an element, a NETCONF > > peer must return them unmodified in the element." > > > > The XSD does not include definitions for additional attributes > > Perhaps all other (non-standard) attributes would need to be > specified with a namespace prefix? > This one is already dealt with in email "RE: Attributes on rpcType elements" on 3/15/05. Rob is adding xs:anyAttribute to the rpcType. -steve -- to unsubscribe send a message to netconf-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 Mar 23 17:28:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00527 for ; Wed, 23 Mar 2005 17:28:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEEEz-000FHe-JX for netconf-data@psg.com; Wed, 23 Mar 2005 22:22:17 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEEEw-000FHM-Cc for netconf@ops.ietf.org; Wed, 23 Mar 2005 22:22:14 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2005 14:22:09 -0800 X-IronPort-AV: i="3.91,116,1110182400"; d="scan'208"; a="239671748:sNHT10948747026" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NMM6ZV012960; Wed, 23 Mar 2005 14:22:07 -0800 (PST) Received: from sberlw2k01 (sjc-vpn5-672.cisco.com [10.21.90.160]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDF94968; Wed, 23 Mar 2005 14:22:05 -0800 (PST) Message-Id: <200503232222.BDF94968@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Andy Bierman'" Cc: Subject: RE: Proposed Resolution to PROT I-D Issues List Date: Wed, 23 Mar 2005 14:22:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <4241B859.5010202@andybierman.com> thread-index: AcUv2IRcWcqiELUiQlC98SsfoMAQLQAHRSsQ X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, March 23, 2005 10:41 AM > To: sberl@cisco.com > Cc: netconf@ops.ietf.org > Subject: Re: Proposed Resolution to PROT I-D Issues List > > Steven Berl (sberl) wrote: > > > > > > > > > > >>-----Original Message----- > >>From: Andy Bierman [mailto:ietf@andybierman.com] > >>Sent: Wednesday, March 23, 2005 9:43 AM > >>To: sberl@cisco.com > >>Cc: netconf@ops.ietf.org > >>Subject: Re: Proposed Resolution to PROT I-D Issues List > >> > >>Steven Berl (sberl) wrote: > >> > >> > >> > >>>After a little more thought, the list of values > >>> > >>> > >>needs to be > >> > >> > >>>more open ended. Can we just leave out that list. Here's some new > >>>replacement > >>>text: > >>> > >>>Any message that is not valid with respect to the XML schema in > >>>appendix B, is not a valid netconf message and MUST be > >>> > >>> > >>rejected by the > >> > >> > >>>netconf server that receives it. In the the > >>> MUST be set to "error" and the MUST > >>>contain an error code indicating the reason for rejecting > >>> > >>> > >>the message. > >> > >> > >>> > >>> > >>> > >>> > >>I strongly object to this proposal to remove the standard > errors from > >>NETCONF. > >>There are plenty of ways for vendors to add their own error > >>information if they want. > >> > >> > > > >I think you misunderstood what I was proposing. I am not > suggesting to > >remove the errors from NETCONF. I am just suggesting that we > not be too > >specific about which subset of those errors are allowed to > be returned > >in this particular error situation (XML not valid with > respect to the schema). > > > >The reason I want to leave this clause out is that the list > I sent in > >the original proposed replacement text 1) doesn't cover all > cases where > >the XML is not valid, and 2) the granularity of how specific > the error > >which can be reported will depend on the details of the > implementations XML parser. > > > > > Okay. I thought you wanted to remove the error list appendix. > I'm not clear about the exact text you want to replace. Well I'm not sure exactly where it should go, but I do think we need a statement like the above someplace. Perhaps at the beginning of appendix B? > > As per my previous email on multiple rpc-errors, I am not > that concerned that every agent process messages and return > errors in exactly the same manner. I want to avoid > implementation specification in the standard. The important > thing is that it is clear in the standard what constitutes > valid and invalid messages. > > Do you think we need any special error codes for namespaces? > (e.g., MISSING_NAMESPACE, UNKNOWN_NAMESPACE) I think that these would be good errors in a multivendor environment. I can see it being confusing when I send an edit-config to 2 different devices from 2 different vendors, and I accidentally send XML with the Cisco namespace to a Juniper box or visa versa. I think that UNKNOWN_NAMESPACE is a good one when a parse doesn't recognize the value of the xmlns attribute and that should be added to the list. I'm not as sure about the MISSING_NAMESPACE error. I'm not sure what the XML rules are, but isn't everything in the document in some namespace? I think it would be hard to tell the difference between a missing namespace qualifier, and an misspelled element or attribute name in a known namespace. Someone that knows more about XML than me might be able to comment on this. -steve > > >-steve > > > > > 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 Mar 23 18:38:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07777 for ; Wed, 23 Mar 2005 18:38:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEFKM-0000ev-6h for netconf-data@psg.com; Wed, 23 Mar 2005 23:31:54 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEFKL-0000eg-8k for netconf@ops.ietf.org; Wed, 23 Mar 2005 23:31:53 +0000 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 23 Mar 2005 15:31:53 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,116,1110182400"; d="scan'208,217"; a="282617352:sNHT22507356" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 15:31:52 -0800 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: Netconf operation definitions Date: Wed, 23 Mar 2005 15:30:23 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D4408E0AB2C@photon.jnpr.net> Thread-Topic: Netconf operation definitions Thread-Index: AcUvz6rxsA/KQ5ufTcOSSeA3nANAPgALlqXQ From: "Rob Enns" To: "Hector Trevino" , X-OriginalArrivalTime: 23 Mar 2005 23:31:52.0448 (UTC) FILETIME=[7E260000:01C53000] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks for the comments Hector.=20 > 1) The current get-config definition for source says: >=20 > "source: >=20 > Name of the configuration datastore being queried, such as > . If this element is unspecified, the > configuration is used." >=20 > The definition for get-config the XSD includes element source=20 > which is=20 > of type rpcOperationSourceType. One of the choices is=20 > "config" which is=20 > config-inlineType >=20 > > > > > > > >=20 > My suggestion would be for the XSD definition to be modified to not=20 > allow this since a definition change can be made to enforce what the=20 > text says. Yep, take a look back in the archive for the subject "What happened to the parameter on " for more discussion on this. We need rpcOperationSourceType to remain the same since it's used by copy-config, but we should use a different type for get-config.=20 > 2) rpc element description. I think this was already brought=20 > up but just=20 > to make sure it's captured >=20 > "If additional attributes are present in an element, a NETCONF > peer must return them unmodified in the element." >=20 > The XSD does not include definitions for additional attributes Thanks, is fixed in -06 based on some XSD supplied by Steve Berl. > Slightly out of subject but related to XSDs >=20 > 3) Naming conventions > There seems to be two different naming conventions followed=20 > in the XSD=20 > (for first word first letter is lower case then use upper=20 > case for first=20 > letter of sub-sequent words - rpcOperationSourceType) and=20 > also dash "-"=20 > separated words (config-inlineType and get-config) >=20 > For consistency purposes it may be good if one of the naming=20 > conventions=20 > was followed instead of inter-mixing. The former? This bugs me too, and in the NETCONF RNG schema (which won't be in the draft/rfc) a common approach was used. I'll make the naming in the XSD consistent. FWIW I believe the original approach was to use dashes for the NETCONF names (get-config) and the lower/upper case style for type names. Picking one (lower/upper case sounds fine to me) makes sense. Rob -- to unsubscribe send a message to netconf-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 Mar 23 18:38:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07822 for ; Wed, 23 Mar 2005 18:38:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEFLu-0000yn-S1 for netconf-data@psg.com; Wed, 23 Mar 2005 23:33:30 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEFLu-0000yb-1I for netconf@ops.ietf.org; Wed, 23 Mar 2005 23:33:30 +0000 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by kremlin.juniper.net with ESMTP; 23 Mar 2005 15:33:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,116,1110182400"; d="scan'208"; a="282620799:sNHT21274432" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 15:33:29 -0800 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: Netconf operation definitions Date: Wed, 23 Mar 2005 15:33:14 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D4408E0AB2D@photon.jnpr.net> Thread-Topic: Netconf operation definitions Thread-Index: AcUv2k/t2j1wSFGmQ42HDVQ7W0XfQAAJf4OQ From: "Rob Enns" To: "Andy Bierman" , "Hector Trevino" Cc: X-OriginalArrivalTime: 23 Mar 2005 23:33:29.0415 (UTC) FILETIME=[B7F1FD70:01C53000] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > 1) The current get-config definition for source says: > > > > "source: > > > > Name of the configuration datastore being queried, such as > > . If this element is unspecified, the > > configuration is used." > > > > The definition for get-config the XSD includes element=20 > source which is=20 > > of type rpcOperationSourceType. One of the choices is=20 > "config" which=20 > > is config-inlineType > > > > > > > > > > > > > > > > > > > > My suggestion would be for the XSD definition to be modified to not=20 > > allow this since a definition change can be made to=20 > enforce what the=20 > > text says. >=20 > I think the text and XSD are both wrong here, since we changed the=20 > > operation to add the parameter. It doesn't make=20 > sense for the=20 > source > to be inline configuration XML (choice=3Dconfig). That made=20 > sense before=20 > we moved > the filter specification to its own parameter.=20 >=20 > The 'source' parameter needs to be changed to 'target', and > the type is changed from rpcOperationSourceType to=20 > rpcOperationTargetType. I'd prefer to use a new type, rather than rename source to target, since it seems like one should "get" from a "source". Cool? thanks, Rob -- to unsubscribe send a message to netconf-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 Mar 23 19:10:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10832 for ; Wed, 23 Mar 2005 19:10:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEFpf-0006ln-AL for netconf-data@psg.com; Thu, 24 Mar 2005 00:04:15 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEFpc-0006lO-Br for netconf@ops.ietf.org; Thu, 24 Mar 2005 00:04:12 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2005 16:04:12 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2O047Dr002427; Wed, 23 Mar 2005 16:04:08 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZI89260; Wed, 23 Mar 2005 16:04:09 -0800 (PST) Message-ID: <424203F8.3080004@cisco.com> Date: Wed, 23 Mar 2005 17:04:08 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman CC: netconf@ops.ietf.org Subject: Re: Netconf operation definitions References: <4241A9FA.5080506@cisco.com> <4241BC07.2060506@andybierman.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Andy Just catching up on e-mail and read Rob's response also. I'll send one more comment there. Hector Andy Bierman wrote: > Hector Trevino wrote: > >> >> Hi, following up on the previous discussions and the suggestion to >> identify areas where there may be discrepancies between the text and >> the XSD. >> >> >> 1) The current get-config definition for source says: >> >> "source: >> >> Name of the configuration datastore being queried, such as >> . If this element is unspecified, the >> configuration is used." >> >> The definition for get-config the XSD includes element source which >> is of type rpcOperationSourceType. One of the choices is "config" >> which is config-inlineType >> >> >> >> >> >> >> >> >> >> My suggestion would be for the XSD definition to be modified to not >> allow this since a definition change can be made to enforce what the >> text says. > > > I think the text and XSD are both wrong here, since we changed the > > operation to add the parameter. It doesn't make sense for > the source > to be inline configuration XML (choice=config). That made sense > before we moved > the filter specification to its own parameter. > The 'source' parameter needs to be changed to 'target', and > the type is changed from rpcOperationSourceType to > rpcOperationTargetType. > > Here is the XSD from the draft to point out the difference: > > > > > > > > >> >> >> 2) rpc element description. I think this was already brought up but >> just to make sure it's captured >> >> "If additional attributes are present in an element, a NETCONF >> peer must return them unmodified in the element." >> >> The XSD does not include definitions for additional attributes > > > Perhaps all other (non-standard) attributes would need to be specified > with a namespace prefix? > >> >> >> Slightly out of subject but related to XSDs >> >> 3) Naming conventions >> There seems to be two different naming conventions followed in the >> XSD (for first word first letter is lower case then use upper case >> for first letter of sub-sequent words - rpcOperationSourceType) and >> also dash "-" separated words (config-inlineType and get-config) >> >> For consistency purposes it may be good if one of the naming >> conventions was followed instead of inter-mixing. The former? > > > I agree. We're only talking about changing the names of some > complexTypes, not changing > any on-the-wire syntax (elements names). The complexType naming > should be more consistent. > The "rpcOperationSourceType" style naming convention should be used > throughout the XSD. > (Not very important but this is the only chance to fix it.) > >> >> > Andy > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 -- to unsubscribe send a message to netconf-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 Mar 23 19:29:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12682 for ; Wed, 23 Mar 2005 19:29:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEG9y-000AjS-8w for netconf-data@psg.com; Thu, 24 Mar 2005 00:25:14 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEG9w-000Aj5-3B for netconf@ops.ietf.org; Thu, 24 Mar 2005 00:25:12 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2005 16:25:12 -0800 X-IronPort-AV: i="3.91,116,1110182400"; d="scan'208,217"; a="239748824:sNHT53013000" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2O0P9ZV012552; Wed, 23 Mar 2005 16:25:10 -0800 (PST) Received: from cisco.com (dhcp-64-101-64-139.cisco.com [64.101.64.139]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZI91470; Wed, 23 Mar 2005 16:25:09 -0800 (PST) Message-ID: <424208E4.1090500@cisco.com> Date: Wed, 23 Mar 2005 17:25:08 -0700 From: Hector Trevino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: netconf@ops.ietf.org Subject: Re: Netconf operation definitions References: <062B922B6EC55149B5A267ECE78E5D4408E0AB2C@photon.jnpr.net> Content-Type: multipart/alternative; boundary="------------090308030506000101010607" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk --------------090308030506000101010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This sounds good. Thanks for the responses Rob. Hector P.S. Changed my mind about additional comments on item #1 I said in e-mail to Andy I'd provide. Rob Enns wrote: >Thanks for the comments Hector. > > > >>1) The current get-config definition for source says: >> >>"source: >> >> Name of the configuration datastore being queried, such as >> . If this element is unspecified, the >> configuration is used." >> >>The definition for get-config the XSD includes element source >>which is >>of type rpcOperationSourceType. One of the choices is >>"config" which is >>config-inlineType >> >> >> >> >> >> >> >> >> >>My suggestion would be for the XSD definition to be modified to not >>allow this since a definition change can be made to enforce what the >>text says. >> >> > >Yep, take a look back in the archive for the subject "What happened >to the parameter on " for more discussion on this. >We need rpcOperationSourceType to remain the same since it's used >by copy-config, but we should use a different type for get-config. > > > > >>2) rpc element description. I think this was already brought >>up but just >>to make sure it's captured >> >>"If additional attributes are present in an element, a NETCONF >> peer must return them unmodified in the element." >> >>The XSD does not include definitions for additional attributes >> >> > >Thanks, is fixed in -06 based on some XSD supplied by Steve Berl. > > > > >>Slightly out of subject but related to XSDs >> >>3) Naming conventions >>There seems to be two different naming conventions followed >>in the XSD >>(for first word first letter is lower case then use upper >>case for first >>letter of sub-sequent words - rpcOperationSourceType) and >>also dash "-" >>separated words (config-inlineType and get-config) >> >>For consistency purposes it may be good if one of the naming >>conventions >>was followed instead of inter-mixing. The former? >> >> > >This bugs me too, and in the NETCONF RNG schema (which won't >be in the draft/rfc) a common approach was used. I'll make the >naming in the XSD consistent. FWIW I believe the original >approach was to use dashes for the NETCONF names (get-config) >and the lower/upper case style for type names. Picking one >(lower/upper case sounds fine to me) makes sense. > >Rob > > > -- Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 9155 E. Nichols Ave Fax: 720-875-3014 Englewood, CO E-mail: htrevino@cisco.com 80112 --------------090308030506000101010607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

This sounds good. Thanks for the responses Rob.

Hector

P.S. Changed my mind about additional comments on item #1 I said in e-mail to Andy I'd provide. 


Rob Enns wrote:
Thanks for the comments Hector. 

  
1) The current get-config definition for source says:

"source:

         Name of the configuration datastore being queried, such as
         <running/>.  If this element is unspecified, the <running/>
         configuration is used."

The definition for get-config the XSD includes element source 
which is 
of type rpcOperationSourceType. One of the choices is 
"config" which is 
config-inlineType

     <xs:complexType name="rpcOperationSourceType">
       <xs:choice>
         <xs:element ref="config"/>
         <xs:element ref="config-name"/>
         <xs:element ref="url"/>
       </xs:choice>
     </xs:complexType>

My suggestion would be for the XSD definition to be modified to not 
allow this  since a definition change can be made to enforce what the 
text says.
    

Yep, take a look back in the archive for the subject "What happened
to the <format> parameter on <get-config>" for more discussion on this.
We need rpcOperationSourceType to remain the same since it's used
by copy-config, but we should use a different type for get-config. 


  
2) rpc element description. I think this was already brought 
up but just 
to make sure it's captured

"If additional attributes are present in an <rpc> element, a NETCONF
   peer must return them unmodified in the <rpc-reply> element."

The XSD does not include definitions for additional attributes
    

Thanks, is fixed in -06 based on some XSD supplied by Steve Berl.


  
Slightly out of subject but related to XSDs

3) Naming conventions
There seems to be two different naming conventions followed 
in the XSD 
(for first word first letter is lower case then use upper 
case for first 
letter of sub-sequent words - rpcOperationSourceType) and 
also dash "-" 
separated words (config-inlineType and get-config)

For consistency purposes it may be good if one of the naming 
conventions 
was followed instead of inter-mixing. The former?
    

This bugs me too, and in the NETCONF RNG schema (which won't
be in the draft/rfc) a common approach was used. I'll make the
naming in the XSD consistent. FWIW I believe the original
approach was to use dashes for the NETCONF names (get-config)
and the lower/upper case style for type names. Picking one
(lower/upper case sounds fine to me) makes sense.

Rob

  

-- 
Hector Trevino
Network Management Technology Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite 400                      
9155 E. Nichols Ave     Fax:    720-875-3014
Englewood, CO             E-mail: htrevino@cisco.com
80112

--------------090308030506000101010607-- -- to unsubscribe send a message to netconf-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 Mar 23 19:42:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13813 for ; Wed, 23 Mar 2005 19:42:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEGIu-000CcS-Ng for netconf-data@psg.com; Thu, 24 Mar 2005 00:34:28 +0000 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEGIk-000Cbr-Ng for netconf@ops.ietf.org; Thu, 24 Mar 2005 00:34:18 +0000 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 23 Mar 2005 16:34:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,116,1110182400"; d="scan'208"; a="282743566:sNHT23190678" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 16:34:17 -0800 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: reporting multiple rpc-errors Date: Wed, 23 Mar 2005 16:34:17 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D4408E0AB35@photon.jnpr.net> Thread-Topic: reporting multiple rpc-errors Thread-Index: AcUvy0wjRnhVMn8uTa2Xhhvp3CO8/gAFDqtw From: "Rob Enns" To: "Andy Bierman" , X-OriginalArrivalTime: 24 Mar 2005 00:34:17.0951 (UTC) FILETIME=[36A466F0:01C53009] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks for the text Andy. With the modification to allow additional attributes, it looks like this. Note that message-id is optional on the rpc-reply because an error must be returned if is sent without a message-id. =20 Rob > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, March 23, 2005 8:55 AM > To: netconf@ops.ietf.org > Subject: reporting multiple rpc-errors >=20 > Hi, >=20 > The section on and its XSD fragment are wrong in=20 > the -05 draft. >=20 > The following text (or something like it) should be added to sec. 4.3: >=20 > If an agent encounters multiple errors during the=20 > processing of an > request, the MAY contain multiple elements. > However, an agent is not required to detect or report more than one > element, if a request contains multiple=20 > errors. An agent > is not required to check for particular error conditions=20 > in a specific > sequence. An agent MUST return an element if any error > conditions occur during processing, and SHOULD return an=20 > > element if any warning conditions occur during processing. > =20 >=20 > Here is the XSD for : >=20 > > > > type=3D"rpc-errorType" minOccurs=3D"0"/> > > > use=3D"required"/> > >=20 > 1) The element should have maxOccurs=3D"unbounded"=20 > specified. > 2) This XSD design 'choice' doesn't allow for errors/warnings=20 > and data to be > returned (just one or the other). This is broken. It doesn't > allow for the 'ignore-error' error-option in the=20 > operation. >=20 > I think this XSD is more what we wanted when we designed the=20 > > operation: >=20 > > > > > > use=3D"required"/> > >=20 > > > type=3D"rpc-errorType" minOccurs=3D"0" = maxOccurs=3D"unbounded"/> > > > >=20 >=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 -- to unsubscribe send a message to netconf-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 Mar 24 05:00:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21552 for ; Thu, 24 Mar 2005 05:00:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEOzk-0008oR-RO for netconf-data@psg.com; Thu, 24 Mar 2005 09:51:16 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEOzh-0008o3-Q3 for netconf@ops.ietf.org; Thu, 24 Mar 2005 09:51:14 +0000 Received: from pc6 (1Cust124.tnt104.lnd4.gbr.da.uu.net [213.116.56.124]) by ranger.systems.pipex.net (Postfix) with SMTP id 39A29E0000F9; Thu, 24 Mar 2005 09:50:59 +0000 (GMT) Message-ID: <003601c5304e$3789fea0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Joel M. Halpern" Cc: References: <6.2.1.2.0.20050322120327.02d78aa8@mail.stevecrocker.com> <6.2.1.2.0.20050322121636.02ee3c80@mail.stevecrocker.com> Subject: Re: Proposed Resolution to PROT I-D Issues List Date: Tue, 22 Mar 2005 18:37:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48 autolearn=no version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This issue surfaced just recently on another list and I am racking my brains to remember where (I thought IPv6 but cannot see it there). As I recall, it was a discrepancy between ABNF and text with substantial disagreement as to which had precedence; I think the ABNF won. Tom Petch ----- Original Message ----- From: "Joel M. Halpern" To: "McDonald, Ira" ; "'Wes Hardaker'" ; Cc: "'Andy Bierman'" ; Sent: Tuesday, March 22, 2005 6:18 PM Subject: RE: Proposed Resolution to PROT I-D Issues List > The other point is to echo Andy's comment. > Except in how we use captialized MUST, MAY, SHOULD wording, the IETF does > not make a strong distinction in our specifications between normative and > informative text. (This is largely because we are not in the conformance > testing business.) > > As such, there is likely no reason to make an issue in the RFC of the > question of what meaning applies in the event of conflict between text and > the XSD. There is a very good reason to make sure to the best of our > ability that there is no such contradiction. > > Yours, > Joel M. Halpern > > At 12:11 PM 3/22/2005, Joel M. Halpern wrote: > >The simplest answer is to look at other cases. > >The IEEE 802.1d bridging spec was quite clear that the English was > >normative. Nonetheless it include code for all the procedures, and that > >code was quite useful to people. > > > >I think that it is more helpful to look at the question differently. > >One expects even informative language in a specification to be > >helpful. There is often a lot of informative language to help the reader > >understand the intent of the specification, and to help get effective > >results in the real world. > > > >The only question under discussion is, if there is a disagreement between > >the English and the formal specification, which one should the reader > >assume was intended. Such a disagreement is a bug in the spec, even if > >the part that is wrong is not normative. > > > >In the absence of a disagreement, having the XSD will enable implementors > >to more reliably implement the intent of the specification. This is helpful. > > > >It can be argued that we should elevate it further. > >We could go down the path of insisting that all normative behavior must be > >described either in the formal portions of the XSD or in comments > >explicitly part of the XSD. That would make reading the specification and > >understanding it hard, but it would mean that we would be clear about what > >was intended to be binding. > >We could say that the English is binding for semantics, but the XSD is > >binding for those things which it specifies. This would make things very > >confusing. > >There is admittedly also confusion in having the XSD but not making it > >normative. > > > >Feel free to pick your confusion. > >But please do not assert that having a differing viewpoint is nonsensical. > > > >Yours, > >Joel M. Halpern > > > >At 08:27 AM 3/22/2005, McDonald, Ira wrote: > >>Joel, Randy, Wes, et al - could you please explain > >>to this list how XSD is useful in NetConf if it's > >>not Normative? > > > > > >-- > >to unsubscribe send a message to netconf-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 29 08:47:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28215 for ; Tue, 29 Mar 2005 08:47:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGGv3-000JDd-KS for netconf-data@psg.com; Tue, 29 Mar 2005 13:38:09 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGGv2-000JDP-Id for netconf@ops.ietf.org; Tue, 29 Mar 2005 13:38:08 +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 j2TDc66g028439 for ; Tue, 29 Mar 2005 07:38:06 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1Z0NBARW>; Tue, 29 Mar 2005 15:38:05 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15506AD764E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: Last Call: 'Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard Date: Tue, 29 Mar 2005 15:38:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Just to make sure this WG is aware of this. Bert -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org]On Behalf Of The IESG Sent: Monday, March 28, 2005 19:42 To: IETF-Announce Subject: Last Call: 'Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-mrose-rfc3288bis-00.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 29 10:14:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06766 for ; Tue, 29 Mar 2005 10:14:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGIIU-0007PX-8Y for netconf-data@psg.com; Tue, 29 Mar 2005 15:06:26 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DGIIJ-0007OT-R6 for netconf@ops.ietf.org; Tue, 29 Mar 2005 15:06:15 +0000 Received: (qmail 11688 invoked by uid 78); 29 Mar 2005 15:06:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 29 Mar 2005 15:06:14 -0000 Message-ID: <42496EE1.70800@andybierman.com> Date: Tue, 29 Mar 2005 07:06:09 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Enns CC: netconf@ops.ietf.org Subject: Re: reporting multiple rpc-errors References: <062B922B6EC55149B5A267ECE78E5D4408E0AB35@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D4408E0AB35@photon.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Enns wrote: >Thanks for the text Andy. > >With the modification to allow additional attributes, it looks like >this. >Note that message-id is optional on the rpc-reply because an error must >be returned if is sent without a message-id. > > > > > > > > > > > > > > type="rpc-errorType" minOccurs="0" maxOccurs="unbounded"/> > > > > > This XSD still allows for an empty . I think the text says the agent must send one of these non-empty permutations: + (+ ) . Andy >Rob > > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>Sent: Wednesday, March 23, 2005 8:55 AM >>To: netconf@ops.ietf.org >>Subject: reporting multiple rpc-errors >> >>Hi, >> >>The section on and its XSD fragment are wrong in >>the -05 draft. >> >>The following text (or something like it) should be added to sec. 4.3: >> >> If an agent encounters multiple errors during the >>processing of an >> request, the MAY contain multiple elements. >> However, an agent is not required to detect or report more than one >> element, if a request contains multiple >>errors. An agent >> is not required to check for particular error conditions >>in a specific >> sequence. An agent MUST return an element if any error >> conditions occur during processing, and SHOULD return an >> >> element if any warning conditions occur during processing. >> >> >>Here is the XSD for : >> >> >> >> >> > type="rpc-errorType" minOccurs="0"/> >> >> >> >use="required"/> >> >> >>1) The element should have maxOccurs="unbounded" >>specified. >>2) This XSD design 'choice' doesn't allow for errors/warnings >>and data to be >> returned (just one or the other). This is broken. It doesn't >> allow for the 'ignore-error' error-option in the >> operation. >> >> I think this XSD is more what we wanted when we designed the >> >> operation: >> >> >> >> >> >> >> >use="required"/> >> >> >> >> >> > type="rpc-errorType" minOccurs="0" maxOccurs="unbounded"/> >> >> >> >> >> >>Andy >> >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> >> > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 29 12:17:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03520 for ; Tue, 29 Mar 2005 12:17:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGKD7-0000hc-1E for netconf-data@psg.com; Tue, 29 Mar 2005 17:09:01 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DGKD2-0000h8-VI for netconf@ops.ietf.org; Tue, 29 Mar 2005 17:08:57 +0000 Received: (qmail 25359 invoked by uid 78); 29 Mar 2005 17:08:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 29 Mar 2005 17:08:55 -0000 Message-ID: <42498BA4.7000509@andybierman.com> Date: Tue, 29 Mar 2005 09:08:52 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf CC: Rob Enns Subject: sec. 6 update (subtree filtering) Content-Type: multipart/mixed; boundary="------------080209070902080402070608" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080209070902080402070608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is my attempt to cleanup section 6. I found a couple of issues (see [ed. note ] inline) which should get separate email threads. I think Rob is holding up prot-06 for this text, so we need to quickly resolve these issues: I025: Filter by namespace only (retrieve entire data model without knowing the top-level element(s)) I026: subtree filter top-level elements should not be considered in the same sibling set. They should be independent to allow retrieval of multiple partial data models thanks, Andy --------------080209070902080402070608 Content-Type: text/plain; name="netconf_sec6_update.txt" Content-Disposition: inline; filename="netconf_sec6_update.txt" Content-Transfer-Encoding: 7bit 6. Subtree Filtering 6.1 Overview XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited selection mechanisms. The agent does not need to utilize any data-model specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree (and path to the root) are included in the filter output. All elements present in a particular subtree within a filter must match associated nodes present in the server's conceptual data model. 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. Note that prefix values for qualified namespaces are not relevant when comparing filter elements to elements in the underlying data model. Only data associated with a specified namespace will be included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified configuration datastore on the server are selected by the filter. A node must exactly match the namespace and absolute path name of the filter data, except the filter absolute path name is adjusted to start from the layer below . Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, is also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event the request contains multiple filter subtree expressions which select the same data. 6.2 Subtree Filter Components A subtree filter is comprised of XML elements and their XML attributes. There are five types of components that may be present in a subtree filter: - Namespace Selection - Attribute Match Expressions - Containment Nodes - Selection Nodes - Content Match Nodes 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 in order for any elements to selected in the filter output. Example: In this example the 'top' element is a selection node, and only this node and any child nodes (from the underlying data model) in the 'http://example.com/schema/1.2/config' namespace will be included in the filter output. [ed. - It would be nice to allow filter by namespace only, so the NMS does not have to know the top-level elements in the namespace (e.g., 'top' in our examples). Perhaps: http://example.com/schema/1.2/config ] 6.2.2 Attribute Match Expressions An attribute which appears in a subtree filter is part of an "attribute match expression". Any number of (unqualified or qualified) XML attributes may be present in any type of filter node. In addition to the selection criteria normally applicable to that node, the selected data must have matching values for every attribute specified in the node. If an element is not defined to include a specified attribute, then it is not selected in the filter output. Example: In this example the 'top', 'interfaces' and 'interface' elements are containment nodes, and 'ifName' is an attribute match expression. Only nodes in the 'http://example.com/schema/1.2/config' namespace, which match the absolute path '/top/interfaces/interface', and the 'interface' element has an 'ifName' attribute defined with the value 'eth0', will be included in the filter output, 6.2.3 Containment Nodes Nodes which contain child elements within a subtree filter are called "containment nodes". Each child element can be any type of node, including another containment node. For each containment node specified in a subtree filter, all data model instances which exactly match the specified namespaces, absolute path, and any attribute match expressions within this node, are included in the filter output. Example: In this example the 'top', element is a containment node, and the 'users' element is a selection node. Only nodes in the 'http://example.com/schema/1.2/config' namespace, which match the absolute path '/top/users' will be included in the filter output. 6.2.2 Selection Nodes An empty leaf node within a filter is called a "selection node", and it represents an "explicit selection" filter on the underlying data model. Presence of any selection nodes within a set of sibling nodes will cause the filter to select the specified subtree(s), and suppress automatic selection of the entire set of sibling nodes in the underlying data model. For filtering purposes, an empty leaf node can be declared with either an empty tag (e.g., ) or with explicit start and end tags (e.g., ). Any whitespace characters are ignored in this form. Example: In this example the 'top' element is a containment node, and the 'users' element is a selection node. Only nodes in the 'http://example.com/schema/1.2/config' namespace, which match the absolute path '/top/users' will be included in the filter output. 6.2.5 Content Match Nodes A leaf node which contains simple content is called a "content match node". It is used to select some or all of its sibling nodes for filter output, and represents an exact-match filter on the leaf node element content. The following constraints apply to content match nodes: o A content match node must not contain nested elements (i.e., must resolve to a simpleType in XSD). o Multiple content match nodes (i.e., sibling nodes) are logically combined in an "AND" expression. o Filtering of mixed content is not supported. o Filtering of list content is not supported. o Filtering of whitespace only content is not supported. o A content match node must contain non-whitespace characters. An empty element (e.g., ) will interpreted as a selection node (e.g., ). o Leading and trailing whitespace characters are ignored, but any whitespace characters within a block of text characters are not ignored or modified. If all specified sibling content match nodes in a subtree filter expression are 'true', then the filter output nodes are selected in the following manner: o Each content match node in the sibling set is included in the filter output. o If any containment nodes are present in the sibling set then they are processed further, and included if any nested filter criteria is also met. o If any selection nodes are present in the sibling set then all of them are included in the filter output. o Otherwise (i.e., there are no selection or containment nodes in the filter sibling set) all the nodes defined at this level in the underlying data model (and their subtrees, if any) are returned in the filter output. If any of the sibling content match node tests are 'false', then no further filter processing is performed on that sibling set, and none of the sibling subtrees are selected by the filter, including the content match node(s). Example: fred In this example the 'users' and 'user' nodes are both containment nodes, and 'name' is a content match node. Since no sibling nodes of 'name' are specified (and therefore no containment or selection nodes) all of the sibling nodes of 'name' are returned in the filter output. Only nodes in the 'http://example.com/schema/1.2/config' namespace, which match the absolute path '/top/users/user', and for which the 'name' element is equal to 'fred', will be included in the filter output. 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 which 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. [ed. I think the paragraph above is broken. The top level should be a special case -- each top level element should be independent, in order to allow partial retrival from multiple data models in the same or operation.] For each sibling set, the server determines which nodes are included (or potentially included) in the filter output, and which sibling subtrees are excluded (pruned) from the filter output. The server first determines which types of nodes are present in the sibling set, and processes the nodes according to the rules for their type. If any nodes in the sibling set are selected, then the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. 6.4 Subtree Filtering Examples 6.4.1 No filter Leaving out the filter on the get operation returns the entire data model. 6.4.2 Empty filter An empty filter will select nothing because no content match or selection nodes are present. This is not an error. The filter type attribute used in these examples is discussed further in Section 7.1. 6.4.3 Select the entire subtree This filter in this example contains one selection node (), so just that subtree is selected by the filter. This example represents the fully-populated data model in most of the filter examples that follow. In a real data model, the 'company-info' would not likely be returned with the list of users for a particular host or network. NOTE: The filtering and configuration examples used in this document appear in the namespace "http://example.com/schema/1.2/config". The root element of this namespace is . The element and its descendents represent an example configuration data model only. root superuser Charlie Root 1 1 fred admin Fred Flintstone 2 2 barney admin Barney Rubble 2 3 The following filter request would have produced the same result, but only because the container defines one child element () 6.4.4 Select all elements within the subtree This filter contains two containment nodes (, ), and one selector node (). All instances of the element in the same sibling set are selected in the filter output. The manager may need to know that is used as an instance identifier in this particular data structure, but the server does not need to know that meta-data in order to process the request. root fred barney 6.4.5 One specific entry This filter contains two containment nodes (, ) and one content match node (). All instances of the sibling set containing , for which the value of equals "fred", are selected in the filter output. fred fred admin Fred Flintstone 2 2 6.4.6 Specific elements from a specific entry This filter contains two containment nodes (, ), one content match node (), and two selector nodes (, ). All instances of the and elements in the same sibling set containing , for which the value of equals "fred", are selected in the filter output. The element is not included because the sibling set contains selection nodes. fred fred admin Fred Flintstone 6.4.7 Multiple Subtrees This filter contains three subtrees (name=root, fred, barney) The "root" subtree filter contains two containment nodes (, ), one content match node (), and one selector node (). The subtree selection criteria is met, and just the company-info subtree for "root" is selected in the filter output. The "fred" subtree filter contains three containment nodes (, , ), one content match node (), and one selector node (). The subtree selection criteria is met, and just the element within the company-info subtree for "fred" is selected in the filter output. The "barney" subtree filter contains three containment nodes (, , ), two content match nodes (, ), and one selector node (). The subtree selection criteria is not met because user "barney" is not a "superuser", and the entire subtree for "barney" (including its parent entry) is excluded from the filter output. root fred barney superuser root 1 1 fred 2 6.4.8 Elements with attribute naming In this example, the filter contains one containment node (), one attribute match expression (ifName), and one selector node (). All instances of the subtree which have an ifName attribute equal to "eth0" are selected in the filter output. The filter data elements and attributes must be qualified because the ifName attribute will not be considered part of the 'schema/1.2' namespace if it is unqualified. 45621 774344 If ifName were a child node instead of an attribute, then the following request would produce similar results. eth0 [end - sec. 6] --------------080209070902080402070608-- -- to unsubscribe send a message to netconf-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 Mar 29 13:16:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08527 for ; Tue, 29 Mar 2005 13:16:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGL8f-000AXP-GQ for netconf-data@psg.com; Tue, 29 Mar 2005 18:08:29 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGL8V-000AVI-Sv for netconf@ops.ietf.org; Tue, 29 Mar 2005 18:08:19 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2005 10:08:19 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2TI8HgS003433; Tue, 29 Mar 2005 10:08:17 -0800 (PST) Received: from sberlw2k01 (dhcp-171-69-222-243.cisco.com [171.69.222.243]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDK70099; Tue, 29 Mar 2005 10:08:16 -0800 (PST) Message-Id: <200503291808.BDK70099@mira-sjc5-b.cisco.com> Reply-To: From: "Steven Berl \(sberl\)" To: "'Eliot Lear'" , "'netconf'" Subject: RE: latest beep draft Date: Tue, 29 Mar 2005 10:08:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <423FE420.1000702@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUuwS7huAk5JWjGT9G5JpejVXqmcAFx7hzQ X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not sure if it is too late for comments on this doc, but here it is anyway. Section 2.1 last paragraph "it is assumed that each knows its role in the conversation." What happens when this assumption is wrong? How is it detected, and what actions are to be taken? If I am a manager and I receive a from someone I thought was an agent, what should I do? Probably close the channel. If 2 agents connect to each other, they can exchange messages and then sit there forever waiting for the other to send an of some sort. I suppose the agents could detect this by noticing that the received has a element, and that only other agents send this element. The action again should probably be to close the channel. This situation is specific to BEEP because the SSH mapping specifies that only managers can initiate sessions. -steve > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear > Sent: Tuesday, March 22, 2005 1:24 AM > To: netconf > Subject: latest beep draft > > I believe I have addressed issues raised in the WG last call. > Can those who had comments (Juergen, Wes) take a quick scan? > In particular: > > - addressed security issues regarding SASL & TLS > - added examples - are these enough? > - clarified use of and > > The draft is at the following URL and is still relatively short: > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt > > Eliot > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org > with the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 29 13:30:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09790 for ; Tue, 29 Mar 2005 13:30:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGLME-000DjR-JQ for netconf-data@psg.com; Tue, 29 Mar 2005 18:22:30 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGLMB-000Dir-EB for netconf@ops.ietf.org; Tue, 29 Mar 2005 18:22:27 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2005 10:22:27 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2TIMOgS013505; Tue, 29 Mar 2005 10:22:24 -0800 (PST) Received: from [10.20.17.14] (ams-clip-vpn-dhcp569.cisco.com [10.61.66.57]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2TIEhxn007118; Tue, 29 Mar 2005 10:14:43 -0800 Message-ID: <42499CDC.1040104@cisco.com> Date: Tue, 29 Mar 2005 22:22:20 +0400 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sberl@cisco.com CC: "'netconf'" Subject: Re: latest beep draft References: <200503291808.BDK70099@mira-sjc5-b.cisco.com> In-Reply-To: <200503291808.BDK70099@mira-sjc5-b.cisco.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1112120084.648663"; x:"432200"; a:"rsa-sha1"; b:"nofws:2104"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"aYoAquYaNui5Osqku88Eegz/bfvlan6FDJ+AMP4RXHVyRcTa0qr+dNriDhPaX5n4KGH4laJT" "Qy/dF5sGjU8jq/pgv8h8QslmJZS3IrhKFM2N1sZ5RNJJKNNUJrV5G2Tz8ViRKIW3DMYRWEv+2wo" "p4cWPiVXa8v9rhibmf7lJORc="; c:"Date: Tue, 29 Mar 2005 22:22:20 +0400"; c:"From: Eliot Lear "; c:"Subject: Re: latest beep draft" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We talked about this. A netconf manager is certainly going to know it is a netconf manager and a netconf agent is certainly going to know it's a netconf agent. This leaves two cases: o where the server is also a client o where a client is misconfigured I think this could be handled with a netconf capability that says "iam-manager" or "iam-agent", but as I recall consensus was against me. Now, I could introduce that concept as an option in the in the BEEP protocol mappin if there are no objections. That would handle the corner case... Eliot Steven Berl (sberl) wrote: > Not sure if it is too late for comments on this doc, but here it is anyway. > > Section 2.1 last paragraph > "it is assumed that each knows its role in the conversation." > > What happens when this assumption is wrong? How is it detected, and what > actions are to be taken? > > If I am a manager and I receive a from someone I thought was an agent, > what should I do? Probably close the channel. > > If 2 agents connect to each other, they can exchange messages and > then sit there forever waiting for the other to send an of some sort. > I suppose the agents could detect this by noticing that the received > has a element, and that only other agents send this element. > The action again should probably be to close the channel. > > This situation is specific to BEEP because the SSH mapping specifies that > only managers can initiate sessions. > > -steve > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear >>Sent: Tuesday, March 22, 2005 1:24 AM >>To: netconf >>Subject: latest beep draft >> >>I believe I have addressed issues raised in the WG last call. >> Can those who had comments (Juergen, Wes) take a quick scan? >> In particular: >> >> - addressed security issues regarding SASL & TLS >> - added examples - are these enough? >> - clarified use of and >> >>The draft is at the following URL and is still relatively short: >> >>http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt >> >>Eliot >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org >>with the word 'unsubscribe' in a single line as the message text body. >>archive: >> > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-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 Mar 29 14:36:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16411 for ; Tue, 29 Mar 2005 14:36:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGMOr-000PIB-5Z for netconf-data@psg.com; Tue, 29 Mar 2005 19:29:17 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DGMOp-000PHq-Th for netconf@ops.ietf.org; Tue, 29 Mar 2005 19:29:16 +0000 Received: (qmail 25971 invoked by uid 78); 29 Mar 2005 19:29:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 29 Mar 2005 19:29:14 -0000 Message-ID: <4249AC87.7030605@andybierman.com> Date: Tue, 29 Mar 2005 11:29:11 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: sberl@cisco.com, "'netconf'" Subject: Re: latest beep draft References: <200503291808.BDK70099@mira-sjc5-b.cisco.com> <42499CDC.1040104@cisco.com> In-Reply-To: <42499CDC.1040104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: > We talked about this. A netconf manager is certainly going to know it > is a netconf manager and a netconf agent is certainly going to know > it's a netconf agent. This leaves two cases: > o where the server is also a client > o where a client is misconfigured > > I think this could be handled with a netconf capability that says > "iam-manager" or "iam-agent", but as I recall consensus was against > me. Now, I could introduce that concept as an option in the > in the BEEP protocol mappin if there are no objections. > That would handle the corner case... I don't want special-case handling for BEEP. Steve already provided the answer -- only a NETCONF peer acting in the agent role should send the element in the capabilities exchange. If neither send it or both send it, then the session should be shut down immediately. Andy > > Eliot > > Steven Berl (sberl) wrote: > >> Not sure if it is too late for comments on this doc, but here it is >> anyway. >> >> Section 2.1 last paragraph >> "it is assumed that each knows its role in the conversation." >> >> What happens when this assumption is wrong? How is it detected, and what >> actions are to be taken? >> >> If I am a manager and I receive a from someone I thought was an >> agent, >> what should I do? Probably close the channel. >> If 2 agents connect to each other, they can exchange messages >> and >> then sit there forever waiting for the other to send an of some >> sort. >> I suppose the agents could detect this by noticing that the received >> >> has a element, and that only other agents send this >> element. >> The action again should probably be to close the channel. >> >> This situation is specific to BEEP because the SSH mapping specifies >> that >> only managers can initiate sessions. >> -steve >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>> On Behalf Of Eliot Lear >>> Sent: Tuesday, March 22, 2005 1:24 AM >>> To: netconf >>> Subject: latest beep draft >>> >>> I believe I have addressed issues raised in the WG last call. Can >>> those who had comments (Juergen, Wes) take a quick scan? In particular: >>> >>> - addressed security issues regarding SASL & TLS >>> - added examples - are these enough? >>> - clarified use of and >>> >>> The draft is at the following URL and is still relatively short: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt >>> >>> Eliot >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> > > -- > to 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 Mar 31 14:43:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27077 for ; Thu, 31 Mar 2005 14:43:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH5PH-0007ib-P2 for netconf-data@psg.com; Thu, 31 Mar 2005 19:32:43 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH5PF-0007iA-NN for netconf@ops.ietf.org; Thu, 31 Mar 2005 19:32:41 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2005 11:32:41 -0800 X-IronPort-AV: i="3.91,138,1110182400"; d="scan'208"; a="624805476:sNHT39431388" Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2VJWcDr009170; Thu, 31 Mar 2005 11:32:39 -0800 (PST) Received: from ajamwalw2k03 (dhcp-171-71-131-4.cisco.com [171.71.131.4]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BFI15128; Thu, 31 Mar 2005 11:32:37 -0800 (PST) Message-Id: <200503311932.BFI15128@mira-sjc5-c.cisco.com> Reply-To: From: "Arvind Jamwal" To: "'Andy Bierman'" , "'Eliot Lear'" Cc: , "'netconf'" Subject: RE: latest beep draft Date: Thu, 31 Mar 2005 11:32:37 -0800 Organization: Cisco Systems Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Thread-Index: AcU0le4jqpzN4/qaShCXBg/snZz0GQBkjrwA In-Reply-To: <4249AC87.7030605@andybierman.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Andy, Would it make sense to specify the role as part of the hello message rather than relying on the presense/absense of session-id element? What I am proposing is the following change to the hello message: urn:ietf:params:xml:ns:netconf:base:1.0 ... agent <------- new role element 4 Comments? -Arvind Jamwal -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, March 29, 2005 11:29 AM To: Eliot Lear Cc: sberl@cisco.com; 'netconf' Subject: Re: latest beep draft Eliot Lear wrote: > We talked about this. A netconf manager is certainly going to know it > is a netconf manager and a netconf agent is certainly going to know > it's a netconf agent. This leaves two cases: > o where the server is also a client > o where a client is misconfigured > > I think this could be handled with a netconf capability that says > "iam-manager" or "iam-agent", but as I recall consensus was against > me. Now, I could introduce that concept as an option in the > in the BEEP protocol mappin if there are no objections. > That would handle the corner case... I don't want special-case handling for BEEP. Steve already provided the answer -- only a NETCONF peer acting in the agent role should send the element in the capabilities exchange. If neither send it or both send it, then the session should be shut down immediately. Andy > > Eliot > > Steven Berl (sberl) wrote: > >> Not sure if it is too late for comments on this doc, but here it is >> anyway. >> >> Section 2.1 last paragraph >> "it is assumed that each knows its role in the conversation." >> >> What happens when this assumption is wrong? How is it detected, and >> what actions are to be taken? >> >> If I am a manager and I receive a from someone I thought was an >> agent, what should I do? Probably close the channel. >> If 2 agents connect to each other, they can exchange messages >> and then sit there forever waiting for the other to send an of >> some sort. >> I suppose the agents could detect this by noticing that the received >> has a element, and that only other agents send >> this element. >> The action again should probably be to close the channel. >> >> This situation is specific to BEEP because the SSH mapping specifies >> that only managers can initiate sessions. >> -steve >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>> On Behalf Of Eliot Lear >>> Sent: Tuesday, March 22, 2005 1:24 AM >>> To: netconf >>> Subject: latest beep draft >>> >>> I believe I have addressed issues raised in the WG last call. Can >>> those who had comments (Juergen, Wes) take a quick scan? In particular: >>> >>> - addressed security issues regarding SASL & TLS >>> - added examples - are these enough? >>> - clarified use of and >>> >>> The draft is at the following URL and is still relatively short: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt >>> >>> Eliot >>> >>> -- >>> to unsubscribe send a message to netconf-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>> >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> > > -- > to 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 Mar 31 21:11:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06190 for ; Thu, 31 Mar 2005 21:11:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHBVi-0003Dt-Hc for netconf-data@psg.com; Fri, 01 Apr 2005 02:03:46 +0000 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DHBVg-0003DR-4L for netconf@ops.ietf.org; Fri, 01 Apr 2005 02:03:44 +0000 Received: (qmail 13621 invoked by uid 78); 31 Mar 2005 20:30:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (70.32.250.209) by mail.networksolutionsemail.com with SMTP; 31 Mar 2005 20:30:22 -0000 Message-ID: <424C5DDC.9030007@andybierman.com> Date: Thu, 31 Mar 2005 12:30:20 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ajamwal@cisco.com CC: "'Eliot Lear'" , sberl@cisco.com, "'netconf'" Subject: Re: latest beep draft References: <200503311932.BFI15128@mira-sjc5-c.cisco.com> In-Reply-To: <200503311932.BFI15128@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Arvind Jamwal wrote: >Hi Andy, > >Would it make sense to specify the role as part of the hello message rather >than relying on the presense/absense of session-id element? > > Why? Can you think of a reason why the can't be used? By design, the agent gives out the session ID. This isn't something that can change once decided. The WG already decided that it would be a very rare case (e.g., misconfiguration) in which an agent connects to another agent or mgr to mgr. And if this ever happens, the worst case scenario is that it uses up 1 TCP control block on an idle connection. That's why the #manager and #agent capabilities were removed from an early draft. Andy >What I am proposing is the following change to the hello message: > > > > > urn:ietf:params:xml:ns:netconf:base:1.0 > > ... > > agent <------- new role element > 4 > > >Comments? > >-Arvind Jamwal > > > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Tuesday, March 29, 2005 11:29 AM >To: Eliot Lear >Cc: sberl@cisco.com; 'netconf' >Subject: Re: latest beep draft > >Eliot Lear wrote: > > > >>We talked about this. A netconf manager is certainly going to know it >>is a netconf manager and a netconf agent is certainly going to know >>it's a netconf agent. This leaves two cases: >> o where the server is also a client >> o where a client is misconfigured >> >>I think this could be handled with a netconf capability that says >>"iam-manager" or "iam-agent", but as I recall consensus was against >>me. Now, I could introduce that concept as an option in the >> in the BEEP protocol mappin if there are no objections. >>That would handle the corner case... >> >> > >I don't want special-case handling for BEEP. >Steve already provided the answer -- only a NETCONF peer acting in the agent >role should send the element in the capabilities exchange. If >neither send it or both send it, then the session should be shut down >immediately. > >Andy > > > >>Eliot >> >>Steven Berl (sberl) wrote: >> >> >> >>>Not sure if it is too late for comments on this doc, but here it is >>>anyway. >>> >>>Section 2.1 last paragraph >>>"it is assumed that each knows its role in the conversation." >>> >>>What happens when this assumption is wrong? How is it detected, and >>>what actions are to be taken? >>> >>>If I am a manager and I receive a from someone I thought was an >>>agent, what should I do? Probably close the channel. >>>If 2 agents connect to each other, they can exchange messages >>>and then sit there forever waiting for the other to send an of >>>some sort. >>>I suppose the agents could detect this by noticing that the received >>> has a element, and that only other agents send >>>this element. >>>The action again should probably be to close the channel. >>> >>>This situation is specific to BEEP because the SSH mapping specifies >>>that only managers can initiate sessions. >>>-steve >>> >>> >>> >>>>-----Original Message----- >>>>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>>>On Behalf Of Eliot Lear >>>>Sent: Tuesday, March 22, 2005 1:24 AM >>>>To: netconf >>>>Subject: latest beep draft >>>> >>>>I believe I have addressed issues raised in the WG last call. Can >>>>those who had comments (Juergen, Wes) take a quick scan? In particular: >>>> >>>> - addressed security issues regarding SASL & TLS >>>> - added examples - are these enough? >>>> - clarified use of and >>>> >>>>The draft is at the following URL and is still relatively short: >>>> >>>>http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-04.txt >>>> >>>>Eliot >>>> >>>> -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: