From owner-netconf@ops.ietf.org Wed Dec 05 12:56:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyTh-0002tD-Vc for netconf-archive@lists.ietf.org; Wed, 05 Dec 2007 12:56:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzyTh-0002Gn-I4 for netconf-archive@lists.ietf.org; Wed, 05 Dec 2007 12:56:09 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzyJE-000FrD-40 for netconf-data@psg.com; Wed, 05 Dec 2007 17:45:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzyIq-000FoR-On for netconf@ops.ietf.org; Wed, 05 Dec 2007 17:45:09 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB5Hiro01747 for ; Wed, 5 Dec 2007 17:44:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments on Partial Locking -01 Date: Wed, 5 Dec 2007 12:44:48 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Partial Locking -01 Thread-Index: Acg3ZogOAenjY8HbR+25SscC912aGA== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi I assume since the new charter has been approved, this list is now the correct place to discuss the drafts proposing to address those items. Here are my comments on the latest partial locking draft. I continue to like the general approach. 1. Section 2.1, last paragraph, I assume multiple partial locks is achieved via multiple partial locking commands. This should be clarified. 2. Section 2.4.1, second paragraph, I assume the discussion of the partial lock not picking up new stuff to lock is done for simplicity? I am not sure it is what the user would want. I'd also be interested in an example of how new stuff get created if there is a lock. 3. Section 2.4.1, forth paragraph, is this defining a third way a partial lock can terminate (when what it is locking gets deleted) that should also be mentioned in the third paragraph of section 2.1? 4. Section 2.4.1, where it discusses that a partial lock will fail due to access rights, isn't that all we should say. "The lock will fail if the user does not have sufficient privileges ..." I don't think we should be talking about having enough privileges to read. We don't know what the access model will be and these could be separate attributes. 5. Section 2.4.1, where it talks about supporting XPATH when XPATH isn't supported. Do we really want this? Wouldn't it just be simpler to require XPATH. It seems people are supporting it anyway and if they don't, they don't get this optional capability. 6. Partial locks should be included in the NETCONF monitoring draft. 7. Section 5.1 (Open Issues), if I can't lock the thing I am about to create, then don't I need to lock its parent? This might be simpler, but at times might be locking other people out unnecessarily. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 05 16:40:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01yq-0005CH-Bh for netconf-archive@lists.ietf.org; Wed, 05 Dec 2007 16:40:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J01yp-0006GZ-Sl for netconf-archive@lists.ietf.org; Wed, 05 Dec 2007 16:40:32 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J01nN-000Anz-SW for netconf-data@psg.com; Wed, 05 Dec 2007 21:28:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J01mF-000Afx-Qq for netconf@ops.ietf.org; Wed, 05 Dec 2007 21:28:05 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB5LRS521043 for ; Wed, 5 Dec 2007 21:27:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on Partial Locking -01 Date: Wed, 5 Dec 2007 16:27:24 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41227010B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Partial Locking -01 Thread-Index: Acg3ZogOAenjY8HbR+25SscC912aGAAHwiJw References: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi Another comment, we may want to say that a partial lock can cause a full lock to fail. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, December 05, 2007 12:45 PM To: netconf@ops.ietf.org Subject: Comments on Partial Locking -01 Hi I assume since the new charter has been approved, this list is now the correct place to discuss the drafts proposing to address those items. Here are my comments on the latest partial locking draft. I continue to like the general approach. 1. Section 2.1, last paragraph, I assume multiple partial locks is achieved via multiple partial locking commands. This should be clarified. 2. Section 2.4.1, second paragraph, I assume the discussion of the partial lock not picking up new stuff to lock is done for simplicity? I am not sure it is what the user would want. I'd also be interested in an example of how new stuff get created if there is a lock. 3. Section 2.4.1, forth paragraph, is this defining a third way a partial lock can terminate (when what it is locking gets deleted) that should also be mentioned in the third paragraph of section 2.1? 4. Section 2.4.1, where it discusses that a partial lock will fail due to access rights, isn't that all we should say. "The lock will fail if the user does not have sufficient privileges ..." I don't think we should be talking about having enough privileges to read. We don't know what the access model will be and these could be separate attributes. 5. Section 2.4.1, where it talks about supporting XPATH when XPATH isn't supported. Do we really want this? Wouldn't it just be simpler to require XPATH. It seems people are supporting it anyway and if they don't, they don't get this optional capability. 6. Partial locks should be included in the NETCONF monitoring draft. 7. Section 5.1 (Open Issues), if I can't lock the thing I am about to create, then don't I need to lock its parent? This might be simpler, but at times might be locking other people out unnecessarily. Sharon Chisholm Nortel Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 05 17:25:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02gk-0004fY-GX for netconf-archive@lists.ietf.org; Wed, 05 Dec 2007 17:25:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02gj-0002Y7-H2 for netconf-archive@lists.ietf.org; Wed, 05 Dec 2007 17:25:54 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J02Zp-000HSg-Gu for netconf-data@psg.com; Wed, 05 Dec 2007 22:18:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [217.146.182.20] (helo=web27815.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J02ZL-000HOG-OG for netconf@ops.ietf.org; Wed, 05 Dec 2007 22:18:30 +0000 Received: (qmail 13854 invoked by uid 60001); 5 Dec 2007 22:18:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=2XGEhh4G2mjk3MqA30uzdmmKYaX4Yg6GVnf4nzodcbQTBN0I8RAEA3Drv54LKlrvV30ZX2KOjIg9hvSwcDlSL5UMNks/At7WDjjW2XHxIviKyPq8k0ZmYm/uqm5X5+q2kMOExUVUNY7X5qlQjnOLXTeZYqmwzxK4kC1Ls+h53tM=; X-YMail-OSG: dtntSPYVM1lQQTjlZRkHUj_NZOdAh8I7qvuocjI5pWPmznD1Yoi8QRQj1K0Ptr3E3xhpAQY_eE_Td3pSEDGWWThl6M26IDtT_GgAwAcAxlUKn99JfTbbWQo8Hxg- Received: from [217.115.75.229] by web27815.mail.ukl.yahoo.com via HTTP; Wed, 05 Dec 2007 22:18:13 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.157 Date: Wed, 5 Dec 2007 22:18:13 +0000 (GMT) From: Mehmet Ersue Subject: RE: Comments on Partial Locking -01 To: netconf@ops.ietf.org Cc: schishol@nortel.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1040371221-1196893093=:13851" Message-ID: <34492.13851.qm@web27815.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --0-1040371221-1196893093=:13851 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A> Another comment, we may want to say that a partial lock can =0A> cause= a full lock to fail.=0A> =0A> Sharon =0A=0AI wouldn't mind if the full loc= k does not fail when both of the locks have been initiated by the same sess= ion. =0AThen the question is whether the partial lock should survive which = seems to be useful.=0A=0ACheers,=0AMehmet=0A =0A> -----Original Message----= -=0A> From: owner-netconf@ops.ietf.org =0A> [mailto:owner-netconf@ops.ietf.= org] On=0A> Behalf Of Chisholm, Sharon (CAR:ZZ00)=0A> Sent: Wednesday, Dece= mber 05, 2007 12:45 PM=0A> To: netconf@ops.ietf.org=0A> Subject: Comments o= n Partial Locking -01=0A> =0A> Hi=0A> =0A> I assume since the new charter h= as been approved, this list is now the=0A> correct place to discuss the dra= fts proposing to address those items.=0A> Here are my comments on the lates= t partial locking draft.=0A> =0A> I continue to like the general approach.= =0A> =0A> 1. Section 2.1, last paragraph, I assume multiple partial locks i= s=0A> achieved via multiple partial locking commands. This should be=0A> cl= arified.=0A> =0A> 2. Section 2.4.1, second paragraph, I assume the discussi= on of the=0A> partial lock not picking up new stuff to lock is done for =0A= > simplicity? I=0A> am not sure it is what the user would want. I'd also be= =0A> interested in an=0A> example of how new stuff get created if there is= a lock.=0A> =0A> 3. Section 2.4.1, forth paragraph, is this defining a thi= rd way a=0A> partial lock can terminate (when what it is locking gets delet= ed) that=0A> should also be mentioned in the third paragraph of section 2.1= ?=0A> =0A> 4. Section 2.4.1, where it discusses that a partial lock will fa= il due=0A> to access rights, isn't that all we should say. "The lock will f= ail if=0A> the user does not have sufficient privileges ..." I don't think = we=0A> should be talking about having enough privileges to read. We =0A> do= n't know=0A> what the access model will be and these could be separate attr= ibutes.=0A> =0A> 5. Section 2.4.1, where it talks about supporting XPATH wh= en =0A> XPATH isn't=0A> supported. Do we really want this? Wouldn't it just= be simpler to=0A> require XPATH. It seems people are supporting it anyway = and if they=0A> don't, they don't get this optional capability.=0A> =0A> 6.= Partial locks should be included in the NETCONF monitoring draft.=0A> =0A>= 7. Section 5.1 (Open Issues), if I can't lock the thing I am about to=0A> = create, then don't I need to lock its parent? This might be =0A> simpler, b= ut=0A> at times might be locking other people out unnecessarily.=0A> =0A> S= haron Chisholm=0A> Nortel=0A> Ottawa, Ontario=0A> Canada=0A> =0A> --=0A> to= unsubscribe send a message to netconf-request@ops.ietf.org with the=0A> wo= rd 'unsubscribe' in a single line as the message text body.=0A> archive: =0A> =0A> --=0A> to unsubscribe send a me= ssage to netconf-request@ops.ietf.org with=0A> the word 'unsubscribe' in a = single line as the message text body.=0A> archive: =0A> =0A=0A=0A=0A=0A Jetzt Mails schnell in einem Vorschau= fenster =C3=BCberfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - = www.yahoo.de/mail --0-1040371221-1196893093=:13851 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

> Another comment, we may want to say that a partial lock ca= n
> cause a full lock to fail.
>
> Sharon

I wou= ldn't mind if the full lock does not fail when both of the locks have been = initiated by the same session.
Then the question is whether the partial= lock should survive which seems to be useful.

Cheers,
Mehmet
=  
> -----Original Message-----
> From: owner-netconf@ops.i= etf.org
> [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of C= hisholm, Sharon (CAR:ZZ00)
> Sent: Wednesday, December 05, 2007 12:45= PM
> To: netconf@ops.ietf.org
> Subject: Comments on Partial L= ocking -01
>
> Hi
>
> I assume since the new char= ter has been approved, this list is now the
> correct place to discuss the drafts proposing to address those items.
> Here are my c= omments on the latest partial locking draft.
>
> I continue to= like the general approach.
>
> 1. Section 2.1, last paragraph= , I assume multiple partial locks is
> achieved via multiple partial = locking commands. This should be
> clarified.
>
> 2. Sec= tion 2.4.1, second paragraph, I assume the discussion of the
> partia= l lock not picking up new stuff to lock is done for
> simplicity? I<= br>> am not sure it is what the user would want. I'd also be
> in= terested in an
> example of how new stuff get created if there is a l= ock.
>
> 3. Section 2.4.1, forth paragraph, is this defining a= third way a
> partial lock can terminate (when what it is locking ge= ts deleted) that
> should also be mentioned in the third paragraph of= section 2.1?
>
> 4. Section 2.4.1, where it discusses that a partial lock will fail due
> to access rights, isn't that all= we should say. "The lock will fail if
> the user does not have suffi= cient privileges ..." I don't think we
> should be talking about havi= ng enough privileges to read. We
> don't know
> what the acces= s model will be and these could be separate attributes.
>
> 5.= Section 2.4.1, where it talks about supporting XPATH when
> XPATH i= sn't
> supported. Do we really want this? Wouldn't it just be simpler= to
> require XPATH. It seems people are supporting it anyway and if = they
> don't, they don't get this optional capability.
>
&g= t; 6. Partial locks should be included in the NETCONF monitoring draft.
= >
> 7. Section 5.1 (Open Issues), if I can't lock the thing I am = about to
> create, then don't I need to lock its parent? This might b= e
> simpler, but
> at times might be locking other people out unnecessarily.
>
> Sharon Chisholm
> Nortel<= br>> Ottawa, Ontario
> Canada
>
> --
> to unsub= scribe send a message to netconf-request@ops.ietf.org with the
> word= 'unsubscribe' in a single line as the message text body.
> arc= hive: <= http://ops.ietf.org/lists/netconf/>
>
> --
&g= t; to unsubscribe send a message to netconf-request@ops.ietf.org with
&g= t; the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>

=0A=0A=0A
Beginnen Sie den Tag mit den neue= sten Nachrichten. Machen Sie Yahoo! zu Ihrer Startseite! --0-1040371221-1196893093=:13851-- -- to unsubscribe send a message to netconf-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 Dec 06 17:12:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OxL-0007qB-5k for netconf-archive@lists.ietf.org; Thu, 06 Dec 2007 17:12:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0OxK-0006SU-Gu for netconf-archive@lists.ietf.org; Thu, 06 Dec 2007 17:12:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0OgM-000BLT-Sq for netconf-data@psg.com; Thu, 06 Dec 2007 21:54:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0OfT-000BED-J8 for netconf@ops.ietf.org; Thu, 06 Dec 2007 21:54:32 +0000 X-IronPort-AV: E=Sophos;i="4.23,263,1194201000"; d="scan'208";a="92611368" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 07 Dec 2007 16:33:16 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB6Lrncb003793 for ; Fri, 7 Dec 2007 05:53:49 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB6Lrmjw007622 for ; Thu, 6 Dec 2007 21:53:49 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 05:53:48 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on Partial Locking -01 Date: Fri, 7 Dec 2007 05:53:56 +0800 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Partial Locking -01 Thread-Index: Acg3ZogOAenjY8HbR+25SscC912aGAA6MLtw References: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> From: "James Balestriere (jbalestr)" To: X-OriginalArrivalTime: 06 Dec 2007 21:53:48.0616 (UTC) FILETIME=[7B3D7C80:01C83852] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3235; t=1196978030; x=1197842030; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jbalestr@cisco.com; z=From:=20=22James=20Balestriere=20(jbalestr)=22=20 |Subject:=20RE=3A=20Comments=20on=20Partial=20Locking=20-01 |Sender:=20; bh=DKg307F00svjzMBzZceJiHeZiXYOZsDG41QGvcN0Qho=; b=NCkVHVwEhgl3qclVKH97QqlTdUAdiVYDOmRSoZXH/gqWW4YDR1Smeh+tqh ht26Leuxph6UFu4c4i2Xa6XdpsIAN7OMmWXlz0NtpqY99J1zIaocfJHGRnsD nPGpkjGnxwYplVt1iRKVxoU2y/QGZenD3cFC4+i7WXCEb9/Koo0oY=; Authentication-Results: hkg-dkim-1; header.From=jbalestr@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b To second some of Sharons items, the impression I got from the document was that configuration seems to be the only way resources on the box are created. We need to also consider hot insertion and removal of hardware. E.g. I lock an ethernet interface to get get exclusivity on the interface but someone physically removes the card. Is my lock persisted ? If that card is pushed back in what happens ? If a similar card is put in ? (e.g I pull out a 4 port card and put in an 8 port card) I also support Phil's concerns. Can I "read" a config when someone has locked a subtree ? The risk for me is I could extract a config which is in an intermediate state. We need some rules on reading such that I can only read a config which is in a know stable state (i.e. not locked) James. > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm > Sent: Wednesday, 5 December 2007 9:45 AM > To: netconf@ops.ietf.org > Subject: Comments on Partial Locking -01 >=20 > Hi >=20 > I assume since the new charter has been approved, this list is now the > correct place to discuss the drafts proposing to address those items. > Here are my comments on the latest partial locking draft. >=20 > I continue to like the general approach. >=20 > 1. Section 2.1, last paragraph, I assume multiple partial locks is > achieved via multiple partial locking commands. This should be > clarified. >=20 > 2. Section 2.4.1, second paragraph, I assume the discussion of the > partial lock not picking up new stuff to lock is done for=20 > simplicity? I > am not sure it is what the user would want. I'd also be=20 > interested in an > example of how new stuff get created if there is a lock. >=20 > 3. Section 2.4.1, forth paragraph, is this defining a third way a > partial lock can terminate (when what it is locking gets deleted) that > should also be mentioned in the third paragraph of section 2.1? >=20 > 4. Section 2.4.1, where it discusses that a partial lock will fail due > to access rights, isn't that all we should say. "The lock will fail if > the user does not have sufficient privileges ..." I don't think we > should be talking about having enough privileges to read. We=20 > don't know > what the access model will be and these could be separate attributes. >=20 > 5. Section 2.4.1, where it talks about supporting XPATH when=20 > XPATH isn't > supported. Do we really want this? Wouldn't it just be simpler to > require XPATH. It seems people are supporting it anyway and if they > don't, they don't get this optional capability. >=20 > 6. Partial locks should be included in the NETCONF monitoring draft. >=20 > 7. Section 5.1 (Open Issues), if I can't lock the thing I am about to > create, then don't I need to lock its parent? This might be=20 > simpler, but > at times might be locking other people out unnecessarily. >=20 > Sharon Chisholm > Nortel=20 > Ottawa, Ontario > Canada >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-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 Dec 06 17:54:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Pbw-0000nh-Nc for netconf-archive@lists.ietf.org; Thu, 06 Dec 2007 17:54:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Pbw-0001r2-Az for netconf-archive@lists.ietf.org; Thu, 06 Dec 2007 17:54:28 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0PQu-000HZ7-1L for netconf-data@psg.com; Thu, 06 Dec 2007 22:43:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0PQj-000HYP-6v for netconf@ops.ietf.org; Thu, 06 Dec 2007 22:42:58 +0000 Received: from localhost (dhcp-4752.ietf70.org [130.129.71.82]) by mail.tail-f.com (Postfix) with ESMTP id A83781B80C5; Thu, 6 Dec 2007 23:42:49 +0100 (CET) Date: Thu, 06 Dec 2007 23:42:46 +0100 (CET) Message-Id: <20071206.234246.192071233.mbj@tail-f.com> To: jbalestr@cisco.com Cc: netconf@ops.ietf.org Subject: Re: Comments on Partial Locking -01 From: Martin Bjorklund In-Reply-To: References: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi, "James Balestriere (jbalestr)" wrote: > To second some of Sharons items, the impression I got from the document > was that > configuration seems to be the only way resources on the box are > created. > We need to also consider hot insertion and removal of hardware. > E.g. I lock an ethernet interface to get get exclusivity on the > interface > but someone physically removes the card. Is my lock persisted ? > If that card is pushed back in what happens ? If a similar card is put > in ? > (e.g I pull out a 4 port card and put in an 8 port card) I don't think this is different from how the global lock works. If I lock the entire datastore, and someone removes a card, will the config be altered? > I also support Phil's concerns. Can I "read" a config when someone has > locked > a subtree ? The risk for me is I could extract a config which is in > an intermediate state. We need some rules on reading such that I can > only > read a config which is in a know stable state (i.e. not locked) The way it works right now is that you get what you ask for. If you lock /foo, then read from /bar and change /foo according to what you just read, then you may end up in an inconsistent state. If you want to do this consistently, either grab the global lock, or lock /foo and /bar. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 06 18:12:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Ptr-0005dZ-To for netconf-archive@lists.ietf.org; Thu, 06 Dec 2007 18:12:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Ptr-0002pU-Jb for netconf-archive@lists.ietf.org; Thu, 06 Dec 2007 18:12:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0Pn3-000K3r-LT for netconf-data@psg.com; Thu, 06 Dec 2007 23:05:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0Pms-000K3P-UJ for netconf@ops.ietf.org; Thu, 06 Dec 2007 23:05:52 +0000 Received: from localhost (dhcp-4752.ietf70.org [130.129.71.82]) by mail.tail-f.com (Postfix) with ESMTP id 6138B1B80C5 for ; Fri, 7 Dec 2007 00:05:45 +0100 (CET) Date: Fri, 07 Dec 2007 00:05:43 +0100 (CET) Message-Id: <20071207.000543.146792110.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: bug or feature? From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, The XSD in RFC 4741 allows as in an . It is not clear if this a bug in the XSD or a feature. Section 8.7.5.1 lists the operations the server MUST support for the :startup capability, but it doesn't say that the server MAY support others. So is this intentional or not? (if the intention was that the server MAY support this, how would a manager know?) Another related bug (or feature) is that the XSD supports as in . In section 7.4 there is actually an example where this is used. But is this really supposed to be supported? It is not listed in 8.7.5.1. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 08:40:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dRQ-0007aU-BJ for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 08:40:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0dRP-0004Wh-Rm for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 08:40:32 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0dHf-000Enj-0p for netconf-data@psg.com; Fri, 07 Dec 2007 13:30:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.169] (helo=exprod7og108.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0dHc-000En4-5Z for netconf@ops.ietf.org; Fri, 07 Dec 2007 13:30:25 +0000 Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 07 Dec 2007 05:30:14 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 05:28:09 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lB7DS6E14202; Fri, 7 Dec 2007 05:28:08 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lB7DOfo8023397; Fri, 7 Dec 2007 13:24:41 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712071324.lB7DOfo8023397@idle.juniper.net> To: Martin Bjorklund cc: netconf@ops.ietf.org Subject: Re: bug or feature? In-reply-to: <20071207.000543.146792110.mbj@tail-f.com> Date: Fri, 07 Dec 2007 08:24:40 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Dec 2007 13:28:09.0192 (UTC) FILETIME=[01F28680:01C838D5] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Martin Bjorklund writes: >The XSD in RFC 4741 allows as in an . >It is not clear if this a bug in the XSD or a feature. Section >8.7.5.1 lists the operations the server MUST support for the :startup >capability, but it doesn't say that the server MAY support others. So >is this intentional or not? (if the intention was that the server MAY >support this, how would a manager know?) This is definitely a bug. The intention was to not allow editing of the startup config, since it was really just a chunk of flash memory and isn't loaded into a real database. >Another related bug (or feature) is that the XSD supports as > in . In section 7.4 there is actually an >example where this is used. But is this really supposed to be >supported? It is not listed in 8.7.5.1. My initial reaction here is that this is a bug. Startup represents a section of flash memory, and deleting it IIRC isn't possible. My memory is fuzzy, but I don't think we intended to allow this. The fact that it's in an example conflicts this, so maybe my memory's off. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 10:48:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fRb-0006HQ-Hk for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 10:48:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0fRZ-0004M3-BZ for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 10:48:51 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0fCj-0006if-0J for netconf-data@psg.com; Fri, 07 Dec 2007 15:33:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [68.142.198.201] (helo=smtp102.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0fCg-0006hz-P0 for netconf@ops.ietf.org; Fri, 07 Dec 2007 15:33:27 +0000 Received: (qmail 52357 invoked from network); 7 Dec 2007 15:33:25 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 7 Dec 2007 15:33:25 -0000 X-YMail-OSG: 1jr77IUVM1n8MXRd8jmvqHj8S3Izx7578yu6NHQVyBWaWhq2 Message-ID: <475967D9.2010406@andybierman.com> Date: Fri, 07 Dec 2007 07:33:45 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Phil Shafer CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: bug or feature? References: <200712071324.lB7DOfo8023397@idle.juniper.net> In-Reply-To: <200712071324.lB7DOfo8023397@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Phil Shafer wrote: > Martin Bjorklund writes: >> The XSD in RFC 4741 allows as in an . >> It is not clear if this a bug in the XSD or a feature. Section >> 8.7.5.1 lists the operations the server MUST support for the :startup >> capability, but it doesn't say that the server MAY support others. So >> is this intentional or not? (if the intention was that the server MAY >> support this, how would a manager know?) > > This is definitely a bug. The intention was to not allow editing > of the startup config, since it was really just a chunk of flash > memory and isn't loaded into a real database. > >> Another related bug (or feature) is that the XSD supports as >> in . In section 7.4 there is actually an >> example where this is used. But is this really supposed to be >> supported? It is not listed in 8.7.5.1. > > My initial reaction here is that this is a bug. Startup represents > a section of flash memory, and deleting it IIRC isn't possible. My > memory is fuzzy, but I don't think we intended to allow this. The > fact that it's in an example conflicts this, so maybe my memory's off. > I remember many WG discussions about this. RFC 4741 is supposed to allow to be edited or deleted, but not mandate it by the agent implementor. IMO, there is absolutely no use case for editing the . There is some use for deleting a corrupted , but minor. If the agent SW is buggy, such that *it* is responsible for the corruption, then may not work to fix it. Perhaps something in the is causing the bug to show up, or even cause a reboot. Perhaps in some implementation, deleting the could allow the agent to boot 'far enough' to reload a previous SW image, and then recover the config to somehow. > Thanks, > Phil Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 11:03:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ffT-0001GR-IC for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 11:03:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ffT-0005VV-5m for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 11:03:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0fWS-0009tL-KG for netconf-data@psg.com; Fri, 07 Dec 2007 15:53:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.25.87.235] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0fWC-0009op-95 for netconf@ops.ietf.org; Fri, 07 Dec 2007 15:53:49 +0000 Received: from [130.129.64.71] (account margaret HELO [130.129.64.71]) by thingmagic.com (CommuniGate Pro SMTP 5.0.13) with ESMTPSA id 2412731; Fri, 07 Dec 2007 10:53:35 -0500 In-Reply-To: <475967D9.2010406@andybierman.com> References: <200712071324.lB7DOfo8023397@idle.juniper.net> <475967D9.2010406@andybierman.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <681B934E-BB3C-4703-BB4E-3D60EEB0AAEE@thingmagic.com> Cc: Phil Shafer , Martin Bjorklund , netconf@ops.ietf.org Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Re: bug or feature? Date: Fri, 7 Dec 2007 10:53:32 -0500 To: Andy Bierman X-Mailer: Apple Mail (2.752.3) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi Andy, On Dec 7, 2007, at 10:33 AM, Andy Bierman wrote: > There is some use for deleting a corrupted , but minor. > If the agent SW is buggy, such that *it* is responsible for the > corruption, then may not work to fix it. > Perhaps something in the is causing the bug to show up, > or even cause a reboot. > > Perhaps in some implementation, deleting the could allow > the agent to boot 'far enough' to reload a previous SW image, and > then recover the config to somehow. Practically, what would it mean to delete the configuration? To overwrite it with all zeros? Or do we require that the configuration include some type of flag indicating whether it is there or not? Margaret -- to unsubscribe send a message to netconf-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 Dec 07 11:21:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fxV-0000lz-Fd for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 11:21:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0fxT-00076J-CK for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 11:21:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0fqr-000CTf-6E for netconf-data@psg.com; Fri, 07 Dec 2007 16:14:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.88] (helo=smtp115.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0fqp-000CTO-IN for netconf@ops.ietf.org; Fri, 07 Dec 2007 16:14:56 +0000 Received: (qmail 92382 invoked from network); 7 Dec 2007 16:14:51 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2007 16:14:51 -0000 X-YMail-OSG: I7eS_ugVM1nSHYorSCrXx.Ndh2kS7zOtHNolwliWLbjQUnEEDcPdBUp.f9WTJWNmcw5iJ83.XfCPaZMUOULTIQWSd7HdjhxLBRclWEiUHF1tZh6SXp9sC3ZRmQ-- Message-ID: <4759718E.7080703@andybierman.com> Date: Fri, 07 Dec 2007 08:15:10 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Margaret Wasserman CC: Phil Shafer , Martin Bjorklund , netconf@ops.ietf.org Subject: Re: bug or feature? References: <200712071324.lB7DOfo8023397@idle.juniper.net> <475967D9.2010406@andybierman.com> <681B934E-BB3C-4703-BB4E-3D60EEB0AAEE@thingmagic.com> In-Reply-To: <681B934E-BB3C-4703-BB4E-3D60EEB0AAEE@thingmagic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Margaret Wasserman wrote: > Hi Andy, > > On Dec 7, 2007, at 10:33 AM, Andy Bierman wrote: >> There is some use for deleting a corrupted , but minor. >> If the agent SW is buggy, such that *it* is responsible for the >> corruption, then may not work to fix it. >> Perhaps something in the is causing the bug to show up, >> or even cause a reboot. >> >> Perhaps in some implementation, deleting the could allow >> the agent to boot 'far enough' to reload a previous SW image, and >> then recover the config to somehow. > > Practically, what would it mean to delete the configuration? > To overwrite it with all zeros? Or do we require that the > configuration include some type of flag indicating whether it is there > or not? > Sec. 8.7.5.1 does not list as a mandatory operation. In any case, this is clearly an implementation detail. The bug is the on . This text in sec. 7.1 was added to cover the text vs. XML format: If the configuration is available in multiple formats, such as XML and text, an XML namespace can be used to specify which format is desired. In the following example, the client uses a specific element () in a specific namespace to indicate to the server the desire to receive the configuration in an alternative format. The server may support any number of distinct formats or views into the configuration data, with the client using the parameter to select between them. I really don't like this approach at all. I really want to think of each configuration database as just a different instance of the same sort of database, like and . I would return 'operation-not-supported' for a on , instead of returning the text in a QName, as RFC 4741 suggests. Note the 'can be used' text instead of the more proper MUST/SHOULD/MAY. IMO, this text means MAY. > Margaret > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 11:53:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gRo-00039d-90 for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 11:53:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0gRm-0000xn-Q8 for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 11:53:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0gLZ-000G8m-Ez for netconf-data@psg.com; Fri, 07 Dec 2007 16:46:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.92] (helo=smtp119.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0gLU-000G8F-Aj for netconf@ops.ietf.org; Fri, 07 Dec 2007 16:46:40 +0000 Received: (qmail 83462 invoked from network); 7 Dec 2007 16:46:35 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2007 16:46:35 -0000 X-YMail-OSG: 8KoKntoVM1kCElF2nZY4bP0muAp0Y6UF7QpzzgVhaHx3TZP. Message-ID: <475978FF.2010708@andybierman.com> Date: Fri, 07 Dec 2007 08:46:55 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: partial lock security concerns Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi, I am somewhat concerned about the security vulnerabilities created by a partial-lock solution based on arbitrary Xpath expressions. I assure you that the Security Area Director will be even more concerned, once he hears about it. Granting access at the time the Xpath expression is configured, instead of when access is requested is not good enough security. Even if the Xpath expression was checked at access request time, there are still problems. Consider the possibility that the Xpath expression allows more nodes that the intended set to be accessed, under spurious conditions. The operator who wrote the Xpath expression is not aware this hole exists. Consider the possibility that a hacker knows the security configuration, and knows when and how to take advantage of the 'extra access'. The only safe solution is to base the locks on stable information, which cannot be edited under any circumstances by a user. Only the 'naming' information (QName path from root) meets this requirement. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 12:23:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gvX-0002hG-Jg for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 12:23:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0gvX-0003Uz-8w for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 12:23:51 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0gik-000Ip8-0U for netconf-data@psg.com; Fri, 07 Dec 2007 17:10:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.91] (helo=smtp118.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0gie-000Iob-NJ for netconf@ops.ietf.org; Fri, 07 Dec 2007 17:10:36 +0000 Received: (qmail 61006 invoked from network); 7 Dec 2007 17:10:32 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2007 17:10:31 -0000 X-YMail-OSG: uVAS.OQVM1n7ggz0MJXgU5mgFva.YTsi6KcmYsOjhec75bTf Message-ID: <47597E9C.6060505@andybierman.com> Date: Fri, 07 Dec 2007 09:10:52 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: partial locking and access control Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi, The requirement about 'must have enough access rights' to get a partial lock is problematic. In order to accept this requirement, I have to accept the fact that NETCONF has a proprietary access control model, instead of no access control model at all, and I don't. The standard access control model in NETCONF is that every user has access to every part of every configuration database. That means that any user can partial-lock anything, unless it is already locked. (BTW, checking partial locks at configure time doesn't work for nodes that match the Xpath expression at access time, but did not exist at partial-lock config-time. The config-time-only for arbitrary Xpath approach is completely broken for this reason.) Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 12:45:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hGJ-0002Fp-LN for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 12:45:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hGH-0005Al-FR for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 12:45:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0h0x-000KzZ-Ck for netconf-data@psg.com; Fri, 07 Dec 2007 17:29:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0h0v-000Kz3-HA for netconf@ops.ietf.org; Fri, 07 Dec 2007 17:29:26 +0000 Received: from localhost (dhcp-4752.ietf70.org [130.129.71.82]) by mail.tail-f.com (Postfix) with ESMTP id B51721B80C5; Fri, 7 Dec 2007 18:29:21 +0100 (CET) Date: Fri, 07 Dec 2007 18:29:13 +0100 (CET) Message-Id: <20071207.182913.251211491.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: partial lock security concerns From: Martin Bjorklund In-Reply-To: <475978FF.2010708@andybierman.com> References: <475978FF.2010708@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi, Andy Bierman wrote: > Hi, > > I am somewhat concerned about the security vulnerabilities > created by a partial-lock solution based on arbitrary Xpath expressions. > I assure you that the Security Area Director will be even more > concerned, once he hears about it. > > Granting access at the time the Xpath expression is configured, > instead of when access is requested is not good enough security. We don't grant access at the time the XPath expression is evaluated. We set the lock on the node set returned by the XPath evaluation. This lock may fail if the user does not have enough priviliges. After that, it works just like the global lock - you cannot change something you don't have access to, even if it is locked. Just like the global lock. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 12:48:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hJ8-0005fQ-8F for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 12:48:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hJ7-0005P0-Sn for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 12:48:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0hD1-000MVF-13 for netconf-data@psg.com; Fri, 07 Dec 2007 17:41:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0hCy-000MUm-0d for netconf@ops.ietf.org; Fri, 07 Dec 2007 17:41:53 +0000 Received: from localhost (dhcp-4752.ietf70.org [130.129.71.82]) by mail.tail-f.com (Postfix) with ESMTP id 989BA1B80C5; Fri, 7 Dec 2007 18:41:50 +0100 (CET) Date: Fri, 07 Dec 2007 18:41:42 +0100 (CET) Message-Id: <20071207.184142.231029358.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: partial locking and access control From: Martin Bjorklund In-Reply-To: <47597E9C.6060505@andybierman.com> References: <47597E9C.6060505@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Andy Bierman wrote: > Hi, > > The requirement about 'must have enough access rights' > to get a partial lock is problematic. > > In order to accept this requirement, I have to accept the fact > that NETCONF has a proprietary access control model, instead > of no access control model at all, and I don't. > > The standard access control model in NETCONF is that every user has > access to every part of every configuration database. Are you saying that in order to be RFC 4741 compliant, an implementation MUST NOT have a (proprietary) per-user access control model? That is definitely not my understanding, and I'd be very suprised if any netconf implemention works that way. > (BTW, checking partial locks at configure time doesn't work > for nodes that match the Xpath expression at access time, > but did not exist at partial-lock config-time. What do you mean "doesn't work"? When the XPath is evaluated, a node set is returned. Those node are locked. This is the design. What exactly "doesn't work"?? > The config-time-only > for arbitrary Xpath approach is completely broken for this reason.) Please clarify "completely broken". /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 13:14:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hiK-0007OW-3q for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 13:14:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hiI-0007NQ-SC for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 13:14:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0ha6-000Pc9-UD for netconf-data@psg.com; Fri, 07 Dec 2007 18:05:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.95] (helo=smtp122.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0hZx-000PaV-Ir for netconf@ops.ietf.org; Fri, 07 Dec 2007 18:05:39 +0000 Received: (qmail 93335 invoked from network); 7 Dec 2007 18:05:34 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2007 18:05:34 -0000 X-YMail-OSG: qmSw2H0VM1n2k9QemnytJWMzarE_2idVkfmRc6Ba6BIPSscz Message-ID: <47598B82.2040904@andybierman.com> Date: Fri, 07 Dec 2007 10:05:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: partial locking and access control References: <47597E9C.6060505@andybierman.com> <20071207.184142.231029358.mbj@tail-f.com> In-Reply-To: <20071207.184142.231029358.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> The requirement about 'must have enough access rights' >> to get a partial lock is problematic. >> >> In order to accept this requirement, I have to accept the fact >> that NETCONF has a proprietary access control model, instead >> of no access control model at all, and I don't. >> >> The standard access control model in NETCONF is that every user has >> access to every part of every configuration database. > > Are you saying that in order to be RFC 4741 compliant, an > implementation MUST NOT have a (proprietary) per-user access control > model? That is definitely not my understanding, and I'd be very > suprised if any netconf implemention works that way. > No, I am saying that if you want to make a standard for partial locking, that it can only rely on mechanisms defined in standards. Having an 'access-denied' error-tag in NETCONF that supports proprietary access control models is not the same thing as defining a requirement in a standard that assumes some unspecified access control model will be in place. >> (BTW, checking partial locks at configure time doesn't work >> for nodes that match the Xpath expression at access time, >> but did not exist at partial-lock config-time. > > What do you mean "doesn't work"? When the XPath is evaluated, a node > set is returned. Those node are locked. This is the design. What > exactly "doesn't work"?? There are Xpath expressions that can specify nodes without parent nodes. What if the agent adds nodes to the configuration database (e.g., card insertion), which adds nodes that match such an Xpath expression. Then a proprietary RPC is used to modify that node. Also, what if another session issues a that matches this new node, but none of the nodes locked in the first partial-lock RPC (by the other session). This new node would of matched the original Xpath expression had it existed at the time. When a manager application looks in the NETCONF monitoring DM and gets all the partial lock information, how does it know that this new node is not part of the partial-lock that the agent says matches the lock request? > >> The config-time-only >> for arbitrary Xpath approach is completely broken for this reason.) > > Please clarify "completely broken". A 2nd partial-lock request which matches a new node is granted, even though it also matches the first partial-lock that includes this new node in its Xpath expression, but not actually in the partial-lock. I think an operator issues a lock that matches the new node, it expects the lock to work when access to the locked data is requested, regardless of when the lock was granted. > > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 14:09:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iZJ-0002q4-RQ for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 14:09:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0iZJ-0003Bb-Bw for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 14:09:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0iTx-0006dO-OA for netconf-data@psg.com; Fri, 07 Dec 2007 19:03:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0iTu-0006cy-Lj for netconf@ops.ietf.org; Fri, 07 Dec 2007 19:03:28 +0000 Received: from localhost (dhcp-4752.ietf70.org [130.129.71.82]) by mail.tail-f.com (Postfix) with ESMTP id CC1EA1B80C5; Fri, 7 Dec 2007 20:03:24 +0100 (CET) Date: Fri, 07 Dec 2007 20:03:16 +0100 (CET) Message-Id: <20071207.200316.206726089.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: partial locking and access control From: Martin Bjorklund In-Reply-To: <47598B82.2040904@andybierman.com> References: <47597E9C.6060505@andybierman.com> <20071207.184142.231029358.mbj@tail-f.com> <47598B82.2040904@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> The requirement about 'must have enough access rights' > >> to get a partial lock is problematic. > >> > >> In order to accept this requirement, I have to accept the fact > >> that NETCONF has a proprietary access control model, instead > >> of no access control model at all, and I don't. > >> > >> The standard access control model in NETCONF is that every user has > >> access to every part of every configuration database. > > > > Are you saying that in order to be RFC 4741 compliant, an > > implementation MUST NOT have a (proprietary) per-user access control > > model? That is definitely not my understanding, and I'd be very > > suprised if any netconf implemention works that way. > > > > No, I am saying that if you want to make a standard > for partial locking, that it can only rely on mechanisms > defined in standards. Ok. I'd be happy to remove this text. > >> (BTW, checking partial locks at configure time doesn't work > >> for nodes that match the Xpath expression at access time, > >> but did not exist at partial-lock config-time. > > > > What do you mean "doesn't work"? When the XPath is evaluated, a node > > set is returned. Those node are locked. This is the design. What > > exactly "doesn't work"?? > > There are Xpath expressions that can specify nodes without parent > nodes. What if the agent adds nodes to the configuration database > (e.g., card insertion), which adds nodes that match such an > Xpath expression. Then a proprietary RPC > is used to modify that node. > > Also, what if another session issues a that matches > this new node, but none of the nodes locked in the first partial-lock > RPC (by the other session). This new node would of matched the > original Xpath expression had it existed at the time. Sure, but since it didn't, it wasn't locked. > When a manager application looks in the NETCONF monitoring DM > and gets all the partial lock information, how does it know > that this new node is not part of the partial-lock that > the agent says matches the lock request? This is an argument I understand :) And I even think that it is probably more useful to be able to monitor those locks correctly, then having the generic XPath lock feature. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 14:35:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iyc-0004CT-HG for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 14:35:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0iyb-0004eS-Sx for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 14:35:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0irI-0009Mp-GW for netconf-data@psg.com; Fri, 07 Dec 2007 19:27:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.89] (helo=smtp116.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0irF-0009MV-5L for netconf@ops.ietf.org; Fri, 07 Dec 2007 19:27:35 +0000 Received: (qmail 86443 invoked from network); 7 Dec 2007 19:27:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2007 19:27:15 -0000 X-YMail-OSG: UmLb1asVM1l0U4EriPjzD_wxFFvvDOWM49ysdSAe8ZbLw97J Message-ID: <47599EA7.3040203@andybierman.com> Date: Fri, 07 Dec 2007 11:27:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: partial locking and access control References: <47597E9C.6060505@andybierman.com> <20071207.184142.231029358.mbj@tail-f.com> <47598B82.2040904@andybierman.com> <20071207.200316.206726089.mbj@tail-f.com> In-Reply-To: <20071207.200316.206726089.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> The requirement about 'must have enough access rights' >>>> to get a partial lock is problematic. >>>> >>>> In order to accept this requirement, I have to accept the fact >>>> that NETCONF has a proprietary access control model, instead >>>> of no access control model at all, and I don't. >>>> >>>> The standard access control model in NETCONF is that every user has >>>> access to every part of every configuration database. >>> Are you saying that in order to be RFC 4741 compliant, an >>> implementation MUST NOT have a (proprietary) per-user access control >>> model? That is definitely not my understanding, and I'd be very >>> suprised if any netconf implemention works that way. >>> >> No, I am saying that if you want to make a standard >> for partial locking, that it can only rely on mechanisms >> defined in standards. > > Ok. I'd be happy to remove this text. > >>>> (BTW, checking partial locks at configure time doesn't work >>>> for nodes that match the Xpath expression at access time, >>>> but did not exist at partial-lock config-time. >>> What do you mean "doesn't work"? When the XPath is evaluated, a node >>> set is returned. Those node are locked. This is the design. What >>> exactly "doesn't work"?? >> There are Xpath expressions that can specify nodes without parent >> nodes. What if the agent adds nodes to the configuration database >> (e.g., card insertion), which adds nodes that match such an >> Xpath expression. Then a proprietary RPC >> is used to modify that node. >> >> Also, what if another session issues a that matches >> this new node, but none of the nodes locked in the first partial-lock >> RPC (by the other session). This new node would of matched the >> original Xpath expression had it existed at the time. > > Sure, but since it didn't, it wasn't locked. > >> When a manager application looks in the NETCONF monitoring DM >> and gets all the partial lock information, how does it know >> that this new node is not part of the partial-lock that >> the agent says matches the lock request? > > This is an argument I understand :) And I even think that it is > probably more useful to be able to monitor those locks correctly, then > having the generic XPath lock feature. > I want the partial lock to only be a super-simple Xpath expression that only includes the QNames and [index1='foo'][index2='bar'] type of expressions. It would be good if access-control works the same way, if there ever is a standard for NETCONF access control. Fancy stuff like "lock all the interfaces to Chicago that have the 'gold-service' feature enabled" can wait for Version 2 of the standard. Start simple and prove that this approach is secure and interoperable. I don't mind defining a safe subset of Xpath that MUST be supported by every agent, just like . I have an objection making full Xpath mandatory for RFC 4741 compliant agents. Unless the WG re-releases NETCONF-1 as a new version of the protocol, requiring full Xpath, and then obsoletes RFC 4741. > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 14:45:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j8J-0004qZ-3t for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 14:45:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0j8I-0004zP-Oo for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 14:45:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0j1f-000AjS-7p for netconf-data@psg.com; Fri, 07 Dec 2007 19:38:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0j1c-000Ait-Ey for netconf@ops.ietf.org; Fri, 07 Dec 2007 19:38:18 +0000 Received: from localhost (dhcp-4752.ietf70.org [130.129.71.82]) by mail.tail-f.com (Postfix) with ESMTP id 0CED11B80C5; Fri, 7 Dec 2007 20:38:14 +0100 (CET) Date: Fri, 07 Dec 2007 20:38:06 +0100 (CET) Message-Id: <20071207.203806.106245272.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: partial locking and access control From: Martin Bjorklund In-Reply-To: <47599EA7.3040203@andybierman.com> References: <47598B82.2040904@andybierman.com> <20071207.200316.206726089.mbj@tail-f.com> <47599EA7.3040203@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Andy Bierman wrote: > I want the partial lock to only be a super-simple Xpath > expression that only includes the QNames and [index1='foo'][index2='bar'] > type of expressions. It would be good if access-control works the > same way, if there ever is a standard for NETCONF access control. Agreed. > Fancy stuff like "lock all the interfaces to Chicago that > have the 'gold-service' feature enabled" can wait > for Version 2 of the standard. Start simple and prove > that this approach is secure and interoperable. Ok. > I don't mind defining a safe subset of Xpath that MUST be supported > by every agent, just like . I have an objection making > full Xpath mandatory for RFC 4741 compliant agents. That was never the intent of course. partial-locking is an optional capability. And the intention was also to support the general xpath part only if your implementation also supported the :xpath capability. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 15:07:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0jU4-0004LK-Kb for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 15:07:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0jU3-000670-76 for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 15:07:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0jJf-000DHP-B2 for netconf-data@psg.com; Fri, 07 Dec 2007 19:56:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.171] (helo=exprod7og109.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0jJc-000DDw-FL for netconf@ops.ietf.org; Fri, 07 Dec 2007 19:56:54 +0000 Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 07 Dec 2007 11:55:56 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:55:44 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lB7JthE99143; Fri, 7 Dec 2007 11:55:43 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lB7JqN8x025312; Fri, 7 Dec 2007 19:52:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712071952.lB7JqN8x025312@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: bug or feature? In-reply-to: <475967D9.2010406@andybierman.com> Date: Fri, 07 Dec 2007 14:52:23 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Dec 2007 19:55:44.0521 (UTC) FILETIME=[27341F90:01C8390B] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Andy Bierman writes: >RFC 4741 is supposed to allow to be edited or deleted, >but not mandate it by the agent implementor. edited? That's certainly not my recollection. >Perhaps something in the is causing the bug to show up, >or even cause a reboot. Trying to predict the likely work around for random bugs isn't a good idea. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 15:18:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0jeN-0005ET-Qe for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 15:18:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0jeN-0006oK-Gr for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 15:18:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0jQo-000EGZ-5Q for netconf-data@psg.com; Fri, 07 Dec 2007 20:04:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.167] (helo=exprod7og107.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0jQl-000EG9-Tx for netconf@ops.ietf.org; Fri, 07 Dec 2007 20:04:17 +0000 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Fri, 07 Dec 2007 12:04:11 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 12:03:25 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lB7K3OE01291; Fri, 7 Dec 2007 12:03:24 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lB7K04tP025380; Fri, 7 Dec 2007 20:00:04 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712072000.lB7K04tP025380@idle.juniper.net> To: Andy Bierman cc: "Netconf (E-mail)" Subject: Re: partial locking and access control In-reply-to: <47597E9C.6060505@andybierman.com> Date: Fri, 07 Dec 2007 15:00:03 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Dec 2007 20:03:25.0137 (UTC) FILETIME=[39C08C10:01C8390C] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Andy Bierman writes: >The standard access control model in NETCONF is that every user has >access to every part of every configuration database. If every user had access to every part of the config, we wouldn't need the "access-denied" error-app-tag. There is no standard access control model in NETCONF. Access control is left to the implementation, which will hopefully ape whatever's in the CLI. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 07 15:23:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0jiy-0006tC-Lp for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 15:23:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0jiy-00077N-9x for netconf-archive@lists.ietf.org; Fri, 07 Dec 2007 15:23:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0jZg-000FOz-5y for netconf-data@psg.com; Fri, 07 Dec 2007 20:13:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0jZb-000FOc-Ka for netconf@ops.ietf.org; Fri, 07 Dec 2007 20:13:27 +0000 Received: (qmail 59815 invoked from network); 7 Dec 2007 19:52:29 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2007 19:52:29 -0000 X-YMail-OSG: Pydql6QVM1kXhX5N5qeS5Xxjde.iLaLIcZJctLlX2FOPHzKf Message-ID: <4759A47C.7060800@andybierman.com> Date: Fri, 07 Dec 2007 11:52:28 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: partial locking and access control References: <47598B82.2040904@andybierman.com> <20071207.200316.206726089.mbj@tail-f.com> <47599EA7.3040203@andybierman.com> <20071207.203806.106245272.mbj@tail-f.com> In-Reply-To: <20071207.203806.106245272.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Martin Bjorklund wrote: > Andy Bierman wrote: >> I want the partial lock to only be a super-simple Xpath >> expression that only includes the QNames and [index1='foo'][index2='bar'] >> type of expressions. It would be good if access-control works the >> same way, if there ever is a standard for NETCONF access control. > > Agreed. > >> Fancy stuff like "lock all the interfaces to Chicago that >> have the 'gold-service' feature enabled" can wait >> for Version 2 of the standard. Start simple and prove >> that this approach is secure and interoperable. > > Ok. > >> I don't mind defining a safe subset of Xpath that MUST be supported >> by every agent, just like . I have an objection making >> full Xpath mandatory for RFC 4741 compliant agents. > > That was never the intent of course. partial-locking is an optional > capability. And the intention was also to support the general xpath > part only if your implementation also supported the :xpath > capability. > To be clear. I think it is a great draft and I hope it approved quickly. Starting simple will make that much easier. > > /martin > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 10 08:39:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1iqz-00058e-Je for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 08:39:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1iqz-000119-7B for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 08:39:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1ii1-000HXG-5y for netconf-data@psg.com; Mon, 10 Dec 2007 13:30:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1ihy-000HWM-IT for netconf@ops.ietf.org; Mon, 10 Dec 2007 13:30:07 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0511321B59 for ; Mon, 10 Dec 2007 14:29:32 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-fe-475d3f3b013f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E938021970 for ; Mon, 10 Dec 2007 14:29:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 14:29:31 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 14:29:31 +0100 Message-ID: <475D3F3A.9020507@ericsson.com> Date: Mon, 10 Dec 2007 14:29:30 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Comments on Schema-query References: <200712072000.lB7K04tP025380@idle.juniper.net> In-Reply-To: <200712072000.lB7K04tP025380@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2007 13:29:31.0608 (UTC) FILETIME=[B24F7580:01C83B30] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hello Mark, General) We retrieve a list of Netconf data model descriptions. These might be Yang modules or XML Schemas or something else. The document should be merged with the netconf-monitoring draft. Ch 1.) The Hello should contain the capabilities related to data models as well. See Netconf standard: 5.2. Data Modeling "The device uses capabilities to announce the set of data models that the device implements..." Ch. 1.1.1 last requirement) a means to advertise the availability/location of the formal data model descriptions Ch 3.1) Use simple get. We don't want new get-A, get-B, get-C operations for each new bit of data. Ch 3.2.1.1.1) I assume the identifier and version are unique only together not one-by-one. Define what is the identifier? Is it the capability string/XML namespace? The schemalist should be rather at the location netconf/schemalist similarly to the Notification model. Indent the RPC-reply example! Ch.4) Discovering the models supported by the node facilitates hacking the node, so access control must protect the schemalist. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 10 09:40:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1joP-000531-2A for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 09:40:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1joO-0002IF-9c for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 09:40:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1jeh-000OVs-3j for netconf-data@psg.com; Mon, 10 Dec 2007 14:30:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1jeZ-000ORs-M9 for netconf@ops.ietf.org; Mon, 10 Dec 2007 14:30:45 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D60A421DEC for ; Mon, 10 Dec 2007 15:29:10 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-f7-475d4d362407 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BD14821DEA for ; Mon, 10 Dec 2007 15:29:10 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 15:29:10 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 15:29:10 +0100 Message-ID: <475D4D35.7030602@ericsson.com> Date: Mon, 10 Dec 2007 15:29:09 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Comments on Netconf Monitoring Content-Type: multipart/mixed; boundary="------------020703090900040001060203" X-OriginalArrivalTime: 10 Dec 2007 14:29:10.0427 (UTC) FILETIME=[0773E6B0:01C83B39] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f This is a multi-part message in MIME format. --------------020703090900040001060203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Mark, General) Netconf related performance counters are needed. Eg.g. - number of sessions - number of current sessions - number of messages, per operation type - number of faults (authentication, XML, etc.) The data model is described in XML schema which is just one possibility. At the momwent it is missing real references for session and stream. I think a Yang model shall be added at least as a non-normative appendix (see attachment). Anyway we should clarify the content of the data model now, and hopefully by the next IETF we will know more about the modeling methodology. Chapter 1) Do we need this? I propose to remove it. Ch 1.1) Remove the last sentence for operation. Ch.1.2) Netconf state should not be the root level element, rather we should have something like netconf/netconfState. It is possible to have zero sessions in the datastore. However when we read it out we will always have the reading session. Still I would rather see minOccurs=0 How do we represent CLI/GUI/etc. sessions? If we are speaking about locking the session can be an internal process like backup or restart. What is a sourceIdentifier? Some description is needed. Or should we just call it sessionSourceAddress which does not need an explanation? Partial locking shall be included in the schema. The sessionId must be always present for the lock. A real reference (keyRef) to the session object would be even better. stream should have a type of ncEvent:streamNameType. A real reference to the stream in the Notification Management Schema would be even better. (keyRef) Remove namedProfile The transportType enumeration is not complete, and not prepared for future new transports. It should be extensible. Beep and SOAP missing. Console should be CLI via telnet or SSH. Add none for internal processes. SessionType: Change webui to GUI, add internal srcIdentifier: rename to srcAddress. IPv6 and none for internal sessions should be included. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com --------------020703090900040001060203 Content-Type: text/plain; name="netconf-state.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netconf-state.yang" module netconf-state { namespace "urn:ietf:params:xml:ns:netconf:state:1.0"; prefix "ns"; import yang-types { prefix yang; } import inet-types { prefix inet; } organization "IETF"; description "NetConf Monitoring Schema. All elements in this Schema are read-only."; revision "2007-11-12" { description "Updated to match draft-scott-netconf-monitoring-00.txt"; } revision "2007-07-22" { description "Initial revision."; } typedef SessionId { type uint32 { range "1..4294967295"; } reference "rfc4741"; } typedef ConfigName { type enumeration { enum "running"; enum "candidate"; enum "startup"; } reference "rfc4741"; } typedef transportType { type enumeration { enum "console"; enum "tcp"; enum "ssh"; enum "ssl"; } } typedef sessionType { type enumeration { enum "cli"; enum "netconf"; enum "webui"; } } grouping srcIdentifier { description "Information about source of the session."; leaf ipAddressTypev4 { type inet:ipv4-address; } leaf nodeName { type string; description "Name of the node."; } } container netconfState { config false; container capabilities { description "List of NETCONF capabilities supported by this device."; leaf-list capability { type yang:uri; min-elements 1; } } container sessions { description "List of NETCONF sessions currently active on this device."; list session { key sessionId; leaf sessionId { type SessionId; } leaf transport { type transportType; } leaf username { type string; } container sourceIdentifier { uses srcIdentifier; } leaf loginTime { type yang:date-and-time; } } } container configurations { description "List of NETCONF configuration datastores (e.g. running, startup, candidate) supported on this device and related information."; list config { key name; leaf name { type ConfigName; } container lockStatus { description "An indication of whether a resource is locked or unlocked. If locked, additional information about the locking such as user an time stamp is provided."; leaf lock-state { type enumeration { enum "locked"; enum "unlocked"; } } leaf lockedBySession { type SessionId; description "The session ID of the session that has locked this resource."; } leaf lockedTime { type yang:date-and-time; description "The date and time of when the resource was locked. If the resource is currently unlocked, this element will not be present."; } } } container subscriptions { description "List of NETCONF notification subscriptions active on this device and related information."; list subscription { key session-id; description "Information about Netconf Notification Subscriptions."; leaf session-id { type SessionId; description "The session id associated with this subscription."; } leaf stream { type string; description "The stream associated with this subscription."; } leaf filter { type anyxml; description "The filters associated with this subscription."; } leaf messagesSent { type yang:zero-based-counter32; description "A count of event notifications sent along this connection since the subscription was created."; } } } } } } --------------020703090900040001060203-- -- to unsubscribe send a message to netconf-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 Dec 10 15:31:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pHr-0006l7-So for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 15:31:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1pHq-0003MV-DZ for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 15:31:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1p8v-000Cm4-Sd for netconf-data@psg.com; Mon, 10 Dec 2007 20:22:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1p8t-000Cl4-3A for netconf@ops.ietf.org; Mon, 10 Dec 2007 20:22:20 +0000 Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id lBALJSeX307432 for ; Mon, 10 Dec 2007 21:19:31 GMT Received: from 86.72.162.23 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 10 Dec 2007 22:18:35 +0100 (CET) Message-ID: <62980.86.72.162.23.1197321515.squirrel@www.isima.fr> Date: Mon, 10 Dec 2007 22:18:35 +0100 (CET) Subject: Password-based user authentication with Netconf over TLS From: badra@isima.fr To: netconf@ops.ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 10 Dec 2007 21:19:31 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Dear all, To update the "NETCONF over TLS" with a password-based user authentication, you kindly find below three proposal profiles: RFC4279 enables pre-shared key (PSK) based user authentication. Thus: 1. The PSK within NETCONF can be generated from the password using one of the following ways: a. Apply the PKCS#5 KDF on the password, the ClientHello.Random and the ServerHello.Random, b. Replace the PSK (RFC4279) with the result of the KDF. 2. Apply a hash function a. MD5 or SHA1 on the password, b. Replace the PSK with the hash result. 3. Use the password "as it is" the PSK in RFC4279. Requirements for encoding and managment interfaces defined in RFC4279 apply for any of the above proposals. Please feel free to give yours preferences, suggestion or alternatives to the above ways of using passwords with RFC4279. With my best regards, Badra -- to unsubscribe send a message to netconf-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 Dec 10 18:46:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1sKI-0006SL-3g for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 18:46:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1sKG-00086D-0S for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 18:46:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1sCL-0008Xl-27 for netconf-data@psg.com; Mon, 10 Dec 2007 23:38:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1sCH-0008XL-PB for netconf@ops.ietf.org; Mon, 10 Dec 2007 23:38:03 +0000 Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id lBB0ZBfT307368; Tue, 11 Dec 2007 00:35:11 GMT Received: from 86.72.162.23 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 11 Dec 2007 01:34:15 +0100 (CET) Message-ID: <63793.86.72.162.23.1197333255.squirrel@www.isima.fr> In-Reply-To: <63784.86.72.162.23.1197333123.squirrel@www.isima.fr> References: <61552.86.72.162.23.1197230607.squirrel@www.isima.fr> <30C65F3A3407B943826897E025135BE6010544A5F3BB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <63784.86.72.162.23.1197333123.squirrel@www.isima.fr> Date: Tue, 11 Dec 2007 01:34:15 +0100 (CET) Subject: =?utf-8?Q?RE:=C2=A0Password-based=C2=A0user=C2=A0authentication=C2=A0with?= =?utf-8?Q?=C2=A0Netconf=C2=A0over=C2=A0TLS?= From: badra@isima.fr To: badra@isima.fr Cc: netconf@ops.ietf.org, charliek@exchange.microsoft.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 11 Dec 2007 00:35:11 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -3.8 (---) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Dear Charlie, I think the best way to do that is to follow section 5 of RFC4279 for formatting and section 7.2 for brute force and dictionary attacks. I totally agree with you on the psk_identity_hint and I would expect too that a DNS name for the server would be the common case. It is true that the password can be compromised by the compromise of this server, but it is the PSK case too, so I don't know if we can go far from what said on that in RFC4279. SHA-1 seems sufficient, and using the hash algorithm negotiated by TLS is also possible. (BTW, what do you mean by "Key Pad for Netconf", is it a ASCII string?) Best regards, Badra > How best to transform a password into a PSK depends on what attacks you're > trying to defend against, what formatting issues and constraints are > imposed by rfc4279. > > Your #3 below is the "obvious" approach; it has the virtue of simplicity. > Your modification #1 adds no cryptographic strength to the exchange (other > than making dictionary attacks slightly more CPU intensive) because > hashing the password and folding in ClientHello.Random and > ServerHello.Random is already done in the key derivation in rfc4279. #2 > does offer an advantage, but I think we can do better. > > There are some enhancements that I would suggest to deal with different > attacks. > > An administrator is likely to choose the same password for multiple uses > (in spite of all advice to the contrary). It is therefore undesirable to > save the administrator's password on the server, since anyone who > compromises the server could learn the administrator's password and use it > to authenticate to other systems where the administrator has rights. So > the first enhancement to consider is to have the PSK be a one way hash of > the password (per your #2) so the server only needs to store the one way > hash. > > That still has the problem that if other systems also authenticate based > on the one way hash of the password rather than the password itself, they > can be compromised by the compromise of this server (and vice versa). It > is better, then, that each server use a distinct hash function or some > "salting" of the password. In the protocol specified in rfc4279, the > client identity and proof of the PSK occur in the same message, so there > is no opportunity for the server to look up a "salt" specific to the user. > The only logical value for salt is the information specified in the > psk_identity_hint sent as part of the ServerKeyExchange. > > The psk_identity_hint can do double duty and also provide a form of server > authentication in the case where the user has the same password on a > number of NETCONF servers. The psk_identity_hint should be a string > representation of the name of the server recognizable to the administrator > or his software. In the case where the user types a server name to connect > to, it should be that string. If the string the user enters differs from > the one returned as psk_identity_hint, the software could display the > server's name and ask the user to confirm. For automated scripts, the > names could be expected to match. I don't know exactly where Netconf is > used, but I would expect that a DNS name for the server would be the > common case. > > Finally, both to keep the server's hashed password from being useful in > impersonating other services on the same host and to allow a centralized > password changing service to be able to update all of the Netconf services > without itself knowing the administrator's cleartext password, it would be > helpful to hash in something specific to the Netconf protocol. > > Taking all of these together, I'd recommend defining: > > PSK = Hash( Hash(Password || "Key Pad for Netconf") || psk_identity_hint) > > There is a politically thorny issue of what to use for a hash function. > SHA-1 is the "logical" candidate. From a security point of view, the > relevant attack is a "1st preimage attack" - learning the password from > the hash with less effort than a dictionary attack. This is the most > difficult attack to mount against a hash function, and I believe that even > MD4 would have adequate strength. Nevertheless, there is pressure to > discontinue use of SHA-1 (or at least have a plan for migrating away from > it) even in contexts where there is nothing wrong with it. While one could > imagine using whatever hash algorithm TLS negotiates (starting with > TLSv1.2), this does not provide an easy migration story in this context. > > So my technical recommendation would be to use SHA-1. If that fails for > political reasons, a second choice would be SHA-256, and a third would be > SHA-512. If forced to be "algorithm agile", you should probably specify > using the hash algorithm negotiated by TLS even though that will be > problematic to implement. > > --Charlie > > -----Original Message----- > From: badra@isima.fr [mailto:badra@isima.fr] > Sent: Sunday, December 09, 2007 12:03 PM > To: Charlie Kaufman > Cc: dromasca@avaya.com > Subject: Password-based user authentication with Netconf over TLS > > Dear Charlie and Dan, > > To continue our discussion regarding NETCONF over TLS with a > password-based user authentication, you kindly find below three proposals > (as we briefly discussed them at IETF-Vancouver). > > RFC4279 enables pre-shared key (PSK) based user authentication. Thus: > > 1. The PSK within NETCONF can be generated from the password using one of > the following ways: > a. Apply the PKCS#5 KDF on the password, the ClientHello.Random and > the ServerHello.Random, > b. Replace the PSK (RFC4279) with the result of the KDF. > > 2. Apply a hash function > a. MD5 or SHA1 on the password, > b. Replace the PSK with the hash result. > > 3. Use the password "as it is" the PSK in RFC4279. > > Please feel free to give yours preferences, suggestion or alternatives to > the above ways of using passwords with RFC4279. > > With my best regards, > Badra > -- to unsubscribe send a message to netconf-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 Dec 10 19:07:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1sf1-0001NO-B2 for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 19:07:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1sez-0000GP-1V for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 19:07:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1sY0-000AZ2-3t for netconf-data@psg.com; Tue, 11 Dec 2007 00:00:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1sXw-000AYW-FL for netconf@ops.ietf.org; Tue, 11 Dec 2007 00:00:26 +0000 Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id lBB0vWbe610552; Tue, 11 Dec 2007 00:57:32 GMT Received: from 86.72.162.23 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 11 Dec 2007 01:56:36 +0100 (CET) Message-ID: <63858.86.72.162.23.1197334596.squirrel@www.isima.fr> In-Reply-To: <63793.86.72.162.23.1197333255.squirrel@www.isima.fr> References: <61552.86.72.162.23.1197230607.squirrel@www.isima.fr> <30C65F3A3407B943826897E025135BE6010544A5F3BB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <63784.86.72.162.23.1197333123.squirrel@www.isima.fr> <63793.86.72.162.23.1197333255.squirrel@www.isima.fr> Date: Tue, 11 Dec 2007 01:56:36 +0100 (CET) Subject: =?utf-8?Q?RE:=C2=A0Password-based=C2=A0user=C2=A0authentication=C2=A0with?= =?utf-8?Q?=C2=A0Netconf=C2=A0over=C2=A0TLS?= From: badra@isima.fr To: charliek@exchange.microsoft.com Cc: dromasca@avaya.com, netconf@ops.ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 11 Dec 2007 00:57:33 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -3.8 (---) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Charlie and all, Please give your comments on the following section to be added to the document... Password-Based NETCONF manager Authentication: ---------------------------------------------- RFC4279 supports authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The PSK can be generated in many ways and its length is variable. Implementation of this document MAY rely on RFC4279 to enable password based user authentication. In this case, the password is used to generate the PSK. It is RECOMMENDED that implementations that allow the administrator to manually configure the password also provide a functionality for generating a new random password, taking RFC4086 into account. This document generates the PSK from the password as follow: PSK = SHA-1((password + "Key Pad for Netconf") + psk_identity_hint) Where: + means concatenation. The label "Key Pad for Netconf" is an ASCII string. psk_identity_hint is defined in section 5.1 of RFC4279, and it is set here to the DNS name of the NETCONF agent (i.e., the TLS server). Best regards, Badra >> How best to transform a password into a PSK depends on what attacks >> you're >> trying to defend against, what formatting issues and constraints are >> imposed by rfc4279. >> >> Your #3 below is the "obvious" approach; it has the virtue of >> simplicity. >> Your modification #1 adds no cryptographic strength to the exchange >> (other >> than making dictionary attacks slightly more CPU intensive) because >> hashing the password and folding in ClientHello.Random and >> ServerHello.Random is already done in the key derivation in rfc4279. #2 >> does offer an advantage, but I think we can do better. >> >> There are some enhancements that I would suggest to deal with different >> attacks. >> >> An administrator is likely to choose the same password for multiple uses >> (in spite of all advice to the contrary). It is therefore undesirable to >> save the administrator's password on the server, since anyone who >> compromises the server could learn the administrator's password and use >> it >> to authenticate to other systems where the administrator has rights. So >> the first enhancement to consider is to have the PSK be a one way hash >> of >> the password (per your #2) so the server only needs to store the one way >> hash. >> >> That still has the problem that if other systems also authenticate based >> on the one way hash of the password rather than the password itself, >> they >> can be compromised by the compromise of this server (and vice versa). It >> is better, then, that each server use a distinct hash function or some >> "salting" of the password. In the protocol specified in rfc4279, the >> client identity and proof of the PSK occur in the same message, so there >> is no opportunity for the server to look up a "salt" specific to the >> user. >> The only logical value for salt is the information specified in the >> psk_identity_hint sent as part of the ServerKeyExchange. >> >> The psk_identity_hint can do double duty and also provide a form of >> server >> authentication in the case where the user has the same password on a >> number of NETCONF servers. The psk_identity_hint should be a string >> representation of the name of the server recognizable to the >> administrator >> or his software. In the case where the user types a server name to >> connect >> to, it should be that string. If the string the user enters differs from >> the one returned as psk_identity_hint, the software could display the >> server's name and ask the user to confirm. For automated scripts, the >> names could be expected to match. I don't know exactly where Netconf is >> used, but I would expect that a DNS name for the server would be the >> common case. >> >> Finally, both to keep the server's hashed password from being useful in >> impersonating other services on the same host and to allow a centralized >> password changing service to be able to update all of the Netconf >> services >> without itself knowing the administrator's cleartext password, it would >> be >> helpful to hash in something specific to the Netconf protocol. >> >> Taking all of these together, I'd recommend defining: >> >> PSK = Hash( Hash(Password || "Key Pad for Netconf") || >> psk_identity_hint) >> >> There is a politically thorny issue of what to use for a hash function. >> SHA-1 is the "logical" candidate. From a security point of view, the >> relevant attack is a "1st preimage attack" - learning the password from >> the hash with less effort than a dictionary attack. This is the most >> difficult attack to mount against a hash function, and I believe that >> even >> MD4 would have adequate strength. Nevertheless, there is pressure to >> discontinue use of SHA-1 (or at least have a plan for migrating away >> from >> it) even in contexts where there is nothing wrong with it. While one >> could >> imagine using whatever hash algorithm TLS negotiates (starting with >> TLSv1.2), this does not provide an easy migration story in this context. >> >> So my technical recommendation would be to use SHA-1. If that fails for >> political reasons, a second choice would be SHA-256, and a third would >> be >> SHA-512. If forced to be "algorithm agile", you should probably specify >> using the hash algorithm negotiated by TLS even though that will be >> problematic to implement. >> >> --Charlie >> >> -----Original Message----- >> From: badra@isima.fr [mailto:badra@isima.fr] >> Sent: Sunday, December 09, 2007 12:03 PM >> To: Charlie Kaufman >> Cc: dromasca@avaya.com >> Subject: Password-based user authentication with Netconf over TLS >> >> Dear Charlie and Dan, >> >> To continue our discussion regarding NETCONF over TLS with a >> password-based user authentication, you kindly find below three >> proposals >> (as we briefly discussed them at IETF-Vancouver). >> >> RFC4279 enables pre-shared key (PSK) based user authentication. Thus: >> >> 1. The PSK within NETCONF can be generated from the password using one >> of >> the following ways: >> a. Apply the PKCS#5 KDF on the password, the ClientHello.Random and >> the ServerHello.Random, >> b. Replace the PSK (RFC4279) with the result of the KDF. >> >> 2. Apply a hash function >> a. MD5 or SHA1 on the password, >> b. Replace the PSK with the hash result. >> >> 3. Use the password "as it is" the PSK in RFC4279. >> >> Please feel free to give yours preferences, suggestion or alternatives >> to >> the above ways of using passwords with RFC4279. >> >> With my best regards, >> Badra >> > -- to unsubscribe send a message to netconf-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 Dec 10 22:39:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1vyA-0003n9-Sb for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 22:39:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1vy9-0004nB-Ao for netconf-archive@lists.ietf.org; Mon, 10 Dec 2007 22:39:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1vqW-0004qQ-6Q for netconf-data@psg.com; Tue, 11 Dec 2007 03:31:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.167] (helo=exprod7og107.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1vqT-0004q7-Gh for netconf@ops.ietf.org; Tue, 11 Dec 2007 03:31:46 +0000 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Mon, 10 Dec 2007 19:31:43 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 19:25:45 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBB3PjE21066; Mon, 10 Dec 2007 19:25:45 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lBB3MEPl044415; Tue, 11 Dec 2007 03:22:17 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712110322.lBB3MEPl044415@idle.juniper.net> To: badra@isima.fr cc: charliek@exchange.microsoft.com, dromasca@avaya.com, netconf@ops.ietf.org Subject: Re: =?utf-8?Q?RE:=C2=A0Password-based=C2=A0user=C2=A0authentication=C2=A0with?= =?utf-8?Q?=C2=A0Netconf=C2=A0over=C2=A0TLS?= In-reply-to: <63858.86.72.162.23.1197334596.squirrel@www.isima.fr> Date: Mon, 10 Dec 2007 22:22:14 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2007 03:25:45.0670 (UTC) FILETIME=[8461BE60:01C83BA5] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -3.8 (---) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f badra@isima.fr writes: >RFC4279 supports authentication based on pre-shared keys (PSKs). These >pre-shared keys are symmetric keys, shared in advance among the >communicating parties. I'm not a security dude, but just wanted to confirm that this is a new pre-shared key per user, and the normal CLI passwords will not be usable in this scheme, given that the passwords are not stored on the router (or anywhere else), rather the salted or hashed version of the password is stored, ala unix. Deploying new PSKs will be an impediment to deployment. Also: what is the impact of section 7.3 of rfc4279? 7.3. Identity Privacy The PSK identity is sent in cleartext. Although using a user name or other similar string as the PSK identity is the most straightforward option, it may lead to problems in some environments since an eavesdropper is able to identify the communicating parties. Even when the identity does not reveal any information itself, reusing the same identity over time may eventually allow an attacker to perform traffic analysis to identify the parties. It should be noted that this is no worse than client certificates, since they are also sent in cleartext. Does this mean we'll be announcing our netconf users' information to would-be crackers? Is this identity as in "phil" or something else? 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 Dec 11 04:50:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J21lI-0002GV-OY for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 04:50:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J21lI-000476-A1 for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 04:50:48 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J21dp-0004ee-Cz for netconf-data@psg.com; Tue, 11 Dec 2007 09:43:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J21dl-0004eF-GL for netconf@ops.ietf.org; Tue, 11 Dec 2007 09:43:03 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id lBBAe5dG593972; Tue, 11 Dec 2007 10:40:08 GMT Message-ID: <475E5B7F.9080803@isima.fr> Date: Tue, 11 Dec 2007 10:42:23 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Phil Shafer CC: charliek@exchange.microsoft.com, dromasca@avaya.com, netconf@ops.ietf.org Subject: Re: Password-based user authentication with Netconf over TLS References: <200712110322.lBB3MEPl044415@idle.juniper.net> In-Reply-To: <200712110322.lBB3MEPl044415@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 11 Dec 2007 10:40:08 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi Phil, Phil Shafer writes : > badra@isima.fr writes: >> RFC4279 supports authentication based on pre-shared keys (PSKs). These >> pre-shared keys are symmetric keys, shared in advance among the >> communicating parties. > > I'm not a security dude, but just wanted to confirm that this is a > new pre-shared key per user, and the normal CLI passwords will not > be usable in this scheme, given that the passwords are not stored > on the router (or anywhere else), rather the salted or hashed version > of the password is stored, ala unix. Deploying new PSKs will be > an impediment to deployment. > So what about using the stored hash or about replacing the password with the hash version as shown in the following formula? PSK = SHA-1(stored-hash + "Key Pad for Netconf" + psk_identity_hint) > Also: what is the impact of section 7.3 of rfc4279? > > 7.3. Identity Privacy > > The PSK identity is sent in cleartext. Although using a user name or > other similar string as the PSK identity is the most straightforward > option, it may lead to problems in some environments since an > eavesdropper is able to identify the communicating parties. Even > when the identity does not reveal any information itself, reusing the > same identity over time may eventually allow an attacker to perform > traffic analysis to identify the parties. It should be noted that > this is no worse than client certificates, since they are also sent > in cleartext. > > Does this mean we'll be announcing our netconf users' information > to would-be crackers? Is this identity as in "phil" or something > else? The traffic analysis by here means that an intruder can learn who is reaching the network, when, and from where, and hence can correlate the user identity to the connection location. RFC4279 does not provide credentials protection and then any info related to the user identity is sent in clear text. However TLS renegotiation (re-handshake) implements a way to avoid sending the user identity and credentials in clear text: doing a TLS Handshake with only server authentication, and then a second authentication with mutual authentication (all second handshake messages are sent encrypted). Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory -- to unsubscribe send a message to netconf-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 Dec 11 07:59:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J24hj-0001kq-BL for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 07:59:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J24hi-0007hM-QK for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 07:59:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J24ZP-000Hmd-3q for netconf-data@psg.com; Tue, 11 Dec 2007 12:50:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J24Z5-000Hje-AW for netconf@ops.ietf.org; Tue, 11 Dec 2007 12:50:34 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id C298F1B80C6 for ; Tue, 11 Dec 2007 13:50:21 +0100 (CET) Date: Tue, 11 Dec 2007 13:51:56 +0100 (CET) Message-Id: <20071211.135156.74918411.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: schema discovery From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Hi, I prefer the based approach for schema discovery. But I would also like to see a mechanism to retrieve the actual schema over NETCONF. The data model below supports those two concepts. It is also extensible so that new schema formats can be added without modifying this module. Usage example (namespace-simplified): netconf-schema 2007-12-11 http://foo/netconf-schema.yang netconf ... Since one location was 'netconf', we can use the new rpc to get it: netconf-schema 2007-12-11 module netconf-schema { namespace urn:ietf:params:xml:ns:netconf:schema; prefix schema; import yang-types { prefix yang; } organization "NETCONF WG, IETF"; description "NETCONF Schema Discovery."; revision "2007-12-11" { description "Initial revision."; } grouping schema-type { description "Reusable, extensible schema type definition."; container type { choice format { leaf xsd { type empty; } leaf yang { type empty; } } } } container schemas { config false; list schema { leaf identifier { type string; // should this be the model's namespace instead? } leaf version { type string; } uses schema-type; leaf-list location { type union { type enumeration { enum "netconf" { description "indicates that the schema can be retrieved using the get-schema rpc."; } } type yang:uri; } } } } rpc get-schema { description "RPC operation to get a schema over NETCONF."; input { leaf identifier { type string; } leaf version { type string; } // should this really be here?? uses schema-type; } output { leaf schema { type string; } } } } /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 08:44:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25P2-0007VE-75 for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 08:44:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J25P1-0000DK-Gf for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 08:44:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J25FJ-000LxM-OY for netconf-data@psg.com; Tue, 11 Dec 2007 13:34:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J25FF-000Lwq-JR for netconf@ops.ietf.org; Tue, 11 Dec 2007 13:34:00 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7847C21553; Tue, 11 Dec 2007 14:33:55 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-8e-475e91c34758 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6C6CB211AC; Tue, 11 Dec 2007 14:33:55 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:33:55 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:33:55 +0100 Message-ID: <475EA466.4010109@ericsson.com> Date: Tue, 11 Dec 2007 15:53:26 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Comments on Partial Locking -01 References: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B41227010B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41227010B@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 13:33:55.0249 (UTC) FILETIME=[79DDA210:01C83BFA] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hello Sharon, See below! Balazs Sharon Chisholm wrote: > Hi > > Another comment, we may want to say that a partial lock can cause a full > lock to fail. > [BALAZS]: From the main Netconf RFC chapter 7.5: An attempt to lock the configuration MUST fail if an existing session or other entity holds a lock on any portion of the lock target. -- to unsubscribe send a message to netconf-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 Dec 11 09:10:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25oG-0002Qe-Gu for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 09:10:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J25oE-0000nY-AR for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 09:10:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J25fI-000Ob5-TO for netconf-data@psg.com; Tue, 11 Dec 2007 14:00:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J25fB-000OZv-2U for netconf@ops.ietf.org; Tue, 11 Dec 2007 14:00:47 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9D4F32248C; Tue, 11 Dec 2007 14:58:28 +0100 (CET) X-AuditID: c1b4fb3e-afea1bb00000459d-34-475e97845893 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8707A22488; Tue, 11 Dec 2007 14:58:28 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:58:28 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:58:27 +0100 Message-ID: <475EAA27.2020705@ericsson.com> Date: Tue, 11 Dec 2007 16:17:59 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: partial locking and access control References: <47597E9C.6060505@andybierman.com> In-Reply-To: <47597E9C.6060505@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 13:58:27.0865 (UTC) FILETIME=[E79D0090:01C83BFD] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hello Andy, From RFC4741 security considerations: "Implementors SHOULD provide a comprehensive authorization scheme with NETCONF." It is true that here we have a SHOULD and not a MUST. So I propose to change the requirement to: A partial lock MUST fail if: - The NETCONF server implements access control and the locking user does not have at least some basic access rights, e.g., read rights, to all of the datastore section to be locked As I know our previous security adviser had serious problems with the missing link between locking and access control. Balazs Andy Bierman wrote: > Hi, > > The requirement about 'must have enough access rights' > to get a partial lock is problematic. > > In order to accept this requirement, I have to accept the fact > that NETCONF has a proprietary access control model, instead > of no access control model at all, and I don't. > > The standard access control model in NETCONF is that every user has > access to every part of every configuration database. That means > that any user can partial-lock anything, unless it is already locked. [BALAZS]: I think there is no standard access control model in NETCONF, but according to the standard there SHOULD be a some kind of access control in the device. > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 09:48:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J26PG-0000X1-Un for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 09:48:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J26PG-0001kT-E5 for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 09:48:22 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2697-0001Sm-UY for netconf-data@psg.com; Tue, 11 Dec 2007 14:31:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2691-0001SJ-LV for netconf@ops.ietf.org; Tue, 11 Dec 2007 14:31:40 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6E63021E15; Tue, 11 Dec 2007 15:31:16 +0100 (CET) X-AuditID: c1b4fb3e-afea1bb00000459d-c3-475e9f34e6ad Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4EFC2219A7; Tue, 11 Dec 2007 15:31:16 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 15:31:16 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 15:31:15 +0100 Message-ID: <475EB1D7.9000703@ericsson.com> Date: Tue, 11 Dec 2007 16:50:47 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Comments on Partial Locking -01 References: <713043CE8B8E1348AF3C546DBE02C1B41226FBA6@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B41227010B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41227010B@zcarhxm2.corp.nortel.com> Content-Type: multipart/mixed; boundary="------------030900000005010702050203" X-OriginalArrivalTime: 11 Dec 2007 14:31:15.0736 (UTC) FILETIME=[7C8E4980:01C83C02] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. --------------030900000005010702050203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, See answers below: Sharon Chisholm wrote: > 3. Section 2.4.1, forth paragraph, is this defining a third way a > partial lock can terminate (when what it is locking gets deleted) that > should also be mentioned in the third paragraph of section 2.1? [BALAZS]: No, the lock is still there. The idea is that the lock is created using XPATH. But the XPATH is only used at creation. Later the lock is maintained as a set of locked nodes. If you delete all the locked nodes, the lock is still present, but it does not cover anything anymore. > > 4. Section 2.4.1, where it discusses that a partial lock will fail due > to access rights, isn't that all we should say. "The lock will fail if > the user does not have sufficient privileges ..." I don't think we > should be talking about having enough privileges to read. We don't know > what the access model will be and these could be separate attributes. [BALAZS]: read is just an example. "at least some basic access rights, e.g., read rights" > > 5. Section 2.4.1, where it talks about supporting XPATH when XPATH isn't > supported. Do we really want this? Wouldn't it just be simpler to > require XPATH. It seems people are supporting it anyway and if they > don't, they don't get this optional capability. [BALAZS]: We don't want to mandate full XPATH support. What I heard from people not all devices will support full XPATH. However IMHO we must have at least this simplified XPATH otherwise there is no way to describe the scope. Then if a device wants to support full XPATH, so be it. > > 6. Partial locks should be included in the NETCONF monitoring draft. [BALAZS]: I attached an incomplete YANG model for it, but this is really a comment to Mark. > > 7. Section 5.1 (Open Issues), if I can't lock the thing I am about to > create, then don't I need to lock its parent? This might be simpler, but > at times might be locking other people out unnecessarily. [BALAZS]: Yes locking a parent might disturb others. So should we allow locking non-existing objects? > > Sharon Chisholm --------------030900000005010702050203 Content-Type: text/plain; name="partialLock.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="partialLock.yang" list locks { config false; key lockId; leaf lockId { type uint32; } leaf sessionId { description "The Id of the session owning the lock."; type uint32; // this should be a keyref really } leaf datastore { type enumeration { enum running; enum candidate; enum startup; } } leaf isGlobalLock { type boolean; } leaf-list originalLockScopeAsXpath { description "The XPATH expression used to request the lock, omitted for global locks."; type string; } --------------030900000005010702050203-- -- to unsubscribe send a message to netconf-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 Dec 11 11:10:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27gv-0006Jd-5N for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:10:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J27gs-0003Rg-VH for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:10:41 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J27SX-0007cv-EM for netconf-data@psg.com; Tue, 11 Dec 2007 15:55:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J27SU-0007cZ-FW for netconf@ops.ietf.org; Tue, 11 Dec 2007 15:55:47 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 407D721A57; Tue, 11 Dec 2007 16:55:44 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-62-475eb30069f1 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2B86F21501; Tue, 11 Dec 2007 16:55:44 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 16:55:42 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 16:55:42 +0100 Message-ID: <475EC5A2.1000501@ericsson.com> Date: Tue, 11 Dec 2007 18:15:14 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Mehmet Ersue CC: netconf@ops.ietf.org, Martin Bjorklund Subject: Re: Comments on Partial Locking -01 References: <34492.13851.qm@web27815.mail.ukl.yahoo.com> In-Reply-To: <34492.13851.qm@web27815.mail.ukl.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 15:55:42.0718 (UTC) FILETIME=[48B661E0:01C83C0E] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hello Mehmet, We could propose to allow a global lock after a partial lock by the same session, it is even logical in a way. However the main NETCONF standard says: " An attempt to lock the configuration MUST fail if an existing session or other entity holds a lock on any portion of the lock target." This means we can not allow the global lock. I think what you propose does not violate the spirit of the RFC4741, but it does violate the exact rule in the RFC. Also we would have to deal with some tricky cases: 1) session A issues partial-lock-A 2) session A issues global-lock - Should the partial-lock still be kept, or does this automatically remove all partial locks for session-A for the specified datastore? (propose YES) - after the successful global lock should it be possible to use a partial lock for the same datastore by the same session ? (propose NO) 3) session-A issues global-unlock - should the partial locks stay alive ? (propose NO) regards Balazs Mehmet Ersue wrote: > > I wouldn't mind if the full lock does not fail when both of the locks > have been initiated by the same session. > Then the question is whether the partial lock should survive which seems > to be useful. > > Cheers, > Mehmet -- to unsubscribe send a message to netconf-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 Dec 11 11:31:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J280e-0001zY-1S for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:31:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J280d-0003xH-K2 for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:31:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J27vL-0009z2-7Y for netconf-data@psg.com; Tue, 11 Dec 2007 16:25:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.88] (helo=smtp115.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J27vI-0009yk-Hq for netconf@ops.ietf.org; Tue, 11 Dec 2007 16:25:33 +0000 Received: (qmail 55776 invoked from network); 11 Dec 2007 16:25:31 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.122 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2007 16:25:31 -0000 X-YMail-OSG: gC0S204VM1mOdXCQwsbaf5DWSroOpFKWsp_EJ1nIvrxqxUC1 Message-ID: <475EBA39.1050404@andybierman.com> Date: Tue, 11 Dec 2007 08:26:33 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Balazs Lengyel CC: Mehmet Ersue , netconf@ops.ietf.org, Martin Bjorklund Subject: Re: Comments on Partial Locking -01 References: <34492.13851.qm@web27815.mail.ukl.yahoo.com> <475EC5A2.1000501@ericsson.com> In-Reply-To: <475EC5A2.1000501@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Balazs Lengyel wrote: > Hello Mehmet, > We could propose to allow a global lock after a partial lock by the same > session, it is even logical in a way. > > However the main NETCONF standard says: > " An attempt to lock the configuration MUST fail if an existing > session or other entity holds a lock on any portion of the lock > target." > This means we can not allow the global lock. I think what you propose > does not violate the spirit of the RFC4741, but it does violate the > exact rule in the RFC. > If you change the way global locks work, then RFC 4741 needs to be obsoleted and a new RFC published to replace it. The WG decided way back when was designed that it is usually a bug when a session locks the same thing twice, so the text above forces the agent to grant and release a lock just once per lock usage. This 'feature' implies over-lapping partial locks, which seems complicated, and not as likely to be inter-operable as non-overlapping partial locks, granted and released once per usage. > Also we would have to deal with some tricky cases: > 1) session A issues partial-lock-A > 2) session A issues global-lock > - Should the partial-lock still be kept, or does this automatically > remove all partial locks for session-A for the specified datastore? > (propose YES) > - after the successful global lock should it be possible to use a > partial lock for the same datastore by the same session ? (propose NO) > 3) session-A issues global-unlock > - should the partial locks stay alive ? (propose NO) > > regards Balazs > > Mehmet Ersue wrote: >> >> I wouldn't mind if the full lock does not fail when both of the locks >> have been initiated by the same session. >> Then the question is whether the partial lock should survive which >> seems to be useful. >> >> Cheers, >> Mehmet > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 11:42:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J28BT-0005Rp-Pe for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:42:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J28BR-0004BJ-Hn for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:42:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J27z1-000ALk-My for netconf-data@psg.com; Tue, 11 Dec 2007 16:29:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J27yx-000ALA-FQ for netconf@ops.ietf.org; Tue, 11 Dec 2007 16:29:21 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 599C620858; Tue, 11 Dec 2007 17:29:17 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-80-475ebadde894 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48015203F9; Tue, 11 Dec 2007 17:29:17 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 17:29:17 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 17:29:16 +0100 Message-ID: <475ECD80.1090300@ericsson.com> Date: Tue, 11 Dec 2007 18:48:48 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: Mehmet Ersue , netconf@ops.ietf.org, Martin Bjorklund Subject: Re: Comments on Partial Locking -01 References: <34492.13851.qm@web27815.mail.ukl.yahoo.com> <475EC5A2.1000501@ericsson.com> <475EBA39.1050404@andybierman.com> In-Reply-To: <475EBA39.1050404@andybierman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 16:29:16.0969 (UTC) FILETIME=[F94CB190:01C83C12] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hello, This would not allow overlapping partial-locks (I agree that would be nasty), just the single case, that a number of disjunct partial locks are replaced by one global lock. I don't see big complications. However I don't see this as important, so it is up to Mehmet to fight for it. For the time being I will not add it to the draft. Balazs Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello Mehmet, >> We could propose to allow a global lock after a partial lock by the >> same session, it is even logical in a way. >> >> However the main NETCONF standard says: >> " An attempt to lock the configuration MUST fail if an existing >> session or other entity holds a lock on any portion of the lock >> target." >> This means we can not allow the global lock. I think what you propose >> does not violate the spirit of the RFC4741, but it does violate the >> exact rule in the RFC. >> > > If you change the way global locks work, then RFC 4741 needs to be > obsoleted and a new RFC published to replace it. > > The WG decided way back when was designed that it > is usually a bug when a session locks the same thing twice, > so the text above forces the agent to grant and release a lock > just once per lock usage. > > This 'feature' implies over-lapping partial locks, which seems complicated, > and not as likely to be inter-operable as non-overlapping partial locks, > granted and released once per usage. > >> Also we would have to deal with some tricky cases: >> 1) session A issues partial-lock-A >> 2) session A issues global-lock >> - Should the partial-lock still be kept, or does this automatically >> remove all partial locks for session-A for the specified datastore? >> (propose YES) >> - after the successful global lock should it be possible to use a >> partial lock for the same datastore by the same session ? (propose NO) >> 3) session-A issues global-unlock >> - should the partial locks stay alive ? (propose NO) >> >> regards Balazs >> >> Mehmet Ersue wrote: >>> >>> I wouldn't mind if the full lock does not fail when both of the locks >>> have been initiated by the same session. >>> Then the question is whether the partial lock should survive which >>> seems to be useful. >>> >>> Cheers, >>> Mehmet >> > > > Andy -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 11:48:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J28Hl-0002bZ-MF for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:48:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J28Hj-0004Js-CU for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 11:48:45 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2897-000BGg-PJ for netconf-data@psg.com; Tue, 11 Dec 2007 16:39:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2894-000BGI-Te for netconf@ops.ietf.org; Tue, 11 Dec 2007 16:39:48 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1D0D120BB5; Tue, 11 Dec 2007 17:39:45 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-e1-475ebd5150a8 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0090420858; Tue, 11 Dec 2007 17:39:45 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 17:39:44 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 17:39:44 +0100 Message-ID: <475ECFF4.4050601@ericsson.com> Date: Tue, 11 Dec 2007 18:59:16 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: partial locking and access control References: <47597E9C.6060505@andybierman.com> <20071207.184142.231029358.mbj@tail-f.com> <47598B82.2040904@andybierman.com> <20071207.200316.206726089.mbj@tail-f.com> <47599EA7.3040203@andybierman.com> In-Reply-To: <47599EA7.3040203@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 16:39:44.0724 (UTC) FILETIME=[6F788140:01C83C14] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hello, I would also like to simplify locking. Also see below. Balazs Andy Bierman wrote: > > I want the partial lock to only be a super-simple Xpath > expression that only includes the QNames and [index1='foo'][index2='bar'] > type of expressions. It would be good if access-control works the > same way, if there ever is a standard for NETCONF access control. [BALAZS]: This means you would not allow something like lock all interfaces, or all users? (Naturally if there is a container above the individual users this could be still done.) If I understand you correctly you would only allow the locking of specific individual nodes (possibly multiple items). The user would have have to specify the nodes each individually and no "groups of nodes" like all interfaces should be allowed. Once you allow to lock "groups" you immediately have a lot of complications. > > Fancy stuff like "lock all the interfaces to Chicago that > have the 'gold-service' feature enabled" can wait > for Version 2 of the standard. Start simple and prove > that this approach is secure and interoperable. > > I don't mind defining a safe subset of Xpath that MUST be supported > by every agent, just like . I have an objection making > full Xpath mandatory for RFC 4741 compliant agents. > > Unless the WG re-releases NETCONF-1 as a new version of the protocol, > requiring full Xpath, and then obsoletes RFC 4741. [BALAZS]: Full XPATH will not be mandatory even if you support the partial-lock capability. It is still a separate decision if you want to (or not) support the XPATH capability. > > Andy > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 13:31:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29tO-00084Y-Nx for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 13:31:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J29tM-0006pU-DL for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 13:31:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J29c9-000JMf-UF for netconf-data@psg.com; Tue, 11 Dec 2007 18:13:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J29be-000JJb-K3 for netconf@ops.ietf.org; Tue, 11 Dec 2007 18:13:40 +0000 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 12 Dec 2007 12:53:50 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBBIDIUq023320; Wed, 12 Dec 2007 02:13:18 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBBIDDjW024940; Tue, 11 Dec 2007 18:13:17 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 02:13:13 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: schema discovery Date: Wed, 12 Dec 2007 02:13:23 +0800 Message-ID: In-Reply-To: <20071211.135156.74918411.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: schema discovery Thread-Index: Acg79MtdcjEPgK93QCWz4sYkR63mMAAK366g References: <20071211.135156.74918411.mbj@tail-f.com> From: "James Balestriere (jbalestr)" To: "Martin Bjorklund" , X-OriginalArrivalTime: 11 Dec 2007 18:13:13.0449 (UTC) FILETIME=[7E880590:01C83C21] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3935; t=1197396799; x=1198260799; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jbalestr@cisco.com; z=From:=20=22James=20Balestriere=20(jbalestr)=22=20 |Subject:=20RE=3A=20schema=20discovery |Sender:=20; bh=YcrKUokjOueUArDKRWdzKRUOqx3muGsBLqxnlMclECU=; b=UdnLXIILG0emPKqg8oTpBACLBB41pdOyS2ip8juzsdu0A7Yf8mWRSvjNaH LFC/eJUbuRXAo3HIdbhqJr54jAEFKxytdjkvW8HF5LnwlQIdVYvo/CSfUA/R H0f7asrKmQLA41ql1d6IYcJjmaRUnfeYf6qNarMxRRbxLjf0uKzIA=; Authentication-Results: hkg-dkim-1; header.From=jbalestr@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Hi Martin , I spoke to Mark after the meeting asking a similar thing. We need a directory listing of all schemas the box has, plus, we need a way to get a specific schema out of the box if the box has the schema definition. Should we allow the get of multiple schemas at the same time ? Why isn't the namespace of the schema definition of the module we are interested=20 sufficient ? I would have thought the namespace would have been globally unique enough. James. > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Martin Bjorklund > Sent: Tuesday, 11 December 2007 4:52 AM > To: netconf@ops.ietf.org > Subject: schema discovery >=20 > Hi, >=20 > I prefer the based approach for schema discovery. But I would > also like to see a mechanism to retrieve the actual schema over > NETCONF. The data model below supports those two concepts. It is > also extensible so that new schema formats can be added without > modifying this module. >=20 > Usage example (namespace-simplified): >=20 > > > > > > > >=20 > > > > > netconf-schema > 2007-12-11 > > > > http://foo/netconf-schema.yang > netconf > > > ... > > > > >=20 >=20 > Since one location was 'netconf', we can use the new rpc to get it: >=20 > > > netconf-schema > 2007-12-11 > > > > > =20 >=20 > > > >=20 >=20 > module netconf-schema { > namespace urn:ietf:params:xml:ns:netconf:schema; > prefix schema; >=20 > import yang-types { prefix yang; } >=20 > organization > "NETCONF WG, IETF"; >=20 > description > "NETCONF Schema Discovery."; >=20 > revision "2007-12-11" { > description "Initial revision."; > } >=20 > grouping schema-type { > description > "Reusable, extensible schema type definition."; > container type { > choice format { > leaf xsd { type empty; } > leaf yang { type empty; } > } > } > } >=20 > container schemas { > config false; > list schema { > leaf identifier { > type string; // should this be the model's namespace instead? > } > leaf version { > type string; > } > uses schema-type; > leaf-list location { > type union { > type enumeration { > enum "netconf" { > description > "indicates that the schema can be retrieved > using the get-schema rpc."; > } > } > type yang:uri; > } > } > } > } > =20 > rpc get-schema { > description > "RPC operation to get a schema over NETCONF."; > input { > leaf identifier { type string; } > leaf version { type string; } // should this really be here?? > uses schema-type; > } > output { > leaf schema { type string; } > } > } > } >=20 >=20 >=20 > > > >=20 >=20 >=20 > /martin > =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 Dec 11 14:50:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2B7T-0002o2-Qw for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 14:50:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2B7S-0000FO-Bj for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 14:50:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2AvO-0000iN-FV for netconf-data@psg.com; Tue, 11 Dec 2007 19:37:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [68.142.198.204] (helo=smtp105.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2AvL-0000i1-Rk for netconf@ops.ietf.org; Tue, 11 Dec 2007 19:37:49 +0000 Received: (qmail 6378 invoked from network); 11 Dec 2007 19:37:47 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.122 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 11 Dec 2007 19:37:46 -0000 X-YMail-OSG: WYzy_xgVM1l3P5EhRUycyoAhUIXAMDBJZbf2f_C6xiKfV9vM Message-ID: <475EE748.6020500@andybierman.com> Date: Tue, 11 Dec 2007 11:38:48 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: partial locking and access control References: <47597E9C.6060505@andybierman.com> <20071207.184142.231029358.mbj@tail-f.com> <47598B82.2040904@andybierman.com> <20071207.200316.206726089.mbj@tail-f.com> In-Reply-To: <20071207.200316.206726089.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Martin Bjorklund wrote: > Andy Bierman wrote: ..... >> Also, what if another session issues a that matches >> this new node, but none of the nodes locked in the first partial-lock >> RPC (by the other session). This new node would of matched the >> original Xpath expression had it existed at the time. > > Sure, but since it didn't, it wasn't locked. > This is an important issue, and demonstrates the problems with the current approach in the draft. Let's say an operator locks "*/ifAdminStatus" to make sure that nobody turns off any interfaces during some network test or big config change. Then a new card gets plugged in that creates some new interfaces like "/interfaces/interface[name='Ethernet1/0']". The operator wants all ifAdminStatus knobs to be locked. Except, it not true for this instance: /interfaces/interface[name='Ethernet1/0']/ifAdminStatus There are 2 separate issues here: 1) Designing a partial locking mechanism that meets operator expectations 2) Monitoring which nodes are actually locked by a partial-lock operation > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 15:23:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Bda-0006lH-Kx for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 15:23:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Bda-00010H-8k for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 15:23:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2BUA-0003Ie-2V for netconf-data@psg.com; Tue, 11 Dec 2007 20:13:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2BU7-0003IO-Ic for netconf@ops.ietf.org; Tue, 11 Dec 2007 20:13:44 +0000 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id BE3571B80CC; Tue, 11 Dec 2007 21:13:40 +0100 (CET) Date: Tue, 11 Dec 2007 21:09:50 +0100 (CET) Message-Id: <20071211.210950.216169531.mbj@tail-f.com> To: ietf@andybierman.com Cc: balazs.lengyel@ericsson.com, m_ersue@yahoo.de, netconf@ops.ietf.org Subject: Re: Comments on Partial Locking -01 From: Martin Bjorklund In-Reply-To: <475EBA39.1050404@andybierman.com> References: <34492.13851.qm@web27815.mail.ukl.yahoo.com> <475EC5A2.1000501@ericsson.com> <475EBA39.1050404@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Andy Bierman wrote: > If you change the way global locks work, then RFC 4741 needs to be > obsoleted and a new RFC published to replace it. I agree that we should not change RFC 4741 b/c of this. > The WG decided way back when was designed that it > is usually a bug when a session locks the same thing twice, > so the text above forces the agent to grant and release a lock > just once per lock usage. > > This 'feature' implies over-lapping partial locks, which seems complicated, > and not as likely to be inter-operable as non-overlapping partial locks, > granted and released once per usage. That was my initial thought as well. But then a reviewer of the draft commented that there is a use case for allowing overlapping partial locks, and that is modular code at the manager. Suppose you write a routine that grabs a lock of /foo/bar/baz, does something and then releases the lock. Later, you might call this routine from code that already have /foo/bar locked (or /foo/bar/baz/xxx/yyy). Thus one can argue that the code on the manager will get more complicated if we don't allow overlapping locks. I will also argue that the code in the agent does not necessarily become more complicated with overlapping locks (we have implemented overlapping locks actually). But maybe that wasn't your point. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 15:54:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2C7H-00057w-AE for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 15:54:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2C7G-0001g9-TD for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 15:54:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2BvB-0005Wh-Lo for netconf-data@psg.com; Tue, 11 Dec 2007 20:41:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.177] (helo=exprod7og112.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2Bv5-0005W6-J8 for netconf@ops.ietf.org; Tue, 11 Dec 2007 20:41:40 +0000 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Tue, 11 Dec 2007 12:36:11 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 12:40:29 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBBKeSE80249; Tue, 11 Dec 2007 12:40:29 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lBBKb45a050521; Tue, 11 Dec 2007 20:37:04 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712112037.lBBKb45a050521@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: partial locking and access control In-reply-to: <475EE748.6020500@andybierman.com> Date: Tue, 11 Dec 2007 15:37:04 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Dec 2007 20:40:29.0689 (UTC) FILETIME=[11573E90:01C83C36] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Andy Bierman writes: >Let's say an operator locks "*/ifAdminStatus" to make sure that >nobody turns off any interfaces during some network test >or big config change. This example and your "div 7" one both highlight one of the problems with partial locking. As a server, my data model may not support (and I don't want to support) random bits of XPath. Locking status fields, etc is just silliness not worth burning code on. IMHO the data model needs to define what's lockable. Supporting random XPath expression locking is way too expensive. 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 Dec 11 16:00:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CDV-0003X8-VF for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 16:00:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2CDT-0001op-Oz for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 16:00:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2C6v-0006b5-Tc for netconf-data@psg.com; Tue, 11 Dec 2007 20:53:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [217.146.182.12] (helo=web27807.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2C6P-0006Xg-MP for netconf@ops.ietf.org; Tue, 11 Dec 2007 20:53:34 +0000 Received: (qmail 14041 invoked by uid 60001); 11 Dec 2007 20:53:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=MyvfCihfmERpNV0oUTxAQmsS0+LGtTTFoYKQkL7mb/XLQM8mrIW7Mbw3s/QvrXcyFcfFatUc6DtQdbhiUuFMwI7EMfdexZgGvpElQ99x+IhKqWC4uak4g5PZnawCEzSDeAVdfX+f6i3E/0A9hXRT2JcsyF3ZqahBT1OwQZvbMpA=; X-YMail-OSG: UffNOn8VM1nlkBES5S4I9TGnppDprBkd8lbBIj7tuZvgE6ozmePSpOVUtAZCSFngojV..mWnzyisl41uODuby6ewCKNJ5gJCpx4JWpQKQ.cbCEeuxhcs2EloGew- Received: from [217.115.75.230] by web27807.mail.ukl.yahoo.com via HTTP; Tue, 11 Dec 2007 20:53:15 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Tue, 11 Dec 2007 20:53:15 +0000 (GMT) From: Mehmet Ersue Subject: RE: Comments on Partial Locking -01 To: balazs.lengyel@ericsson.com, mbj@tail-f.com, ietf@andybierman.com, netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-11784112-1197406395=:10727" Message-ID: <7944.10727.qm@web27807.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --0-11784112-1197406395=:10727 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi Balazs, Martin, Andy,=0A=0AI believe the rule in RFC4741 is correct a= nd should be kept if two subsequent locks are done by different sessions.= =0ALet us assume shortly ;-) that the rule wouldn't exist for two subsequen= t locks done by the same session.=0A=0AIMHO:=0Aa) A partial lock after a gl= obal lock MUST fail.=0Ab) A global lock after a partial lock SHOULD be allo= wed.=0AI) If above happens it is the easiest way of implementation (for the= managing session and the managed node) if the global lock and partial lock= are handled independently.=0AI.e. the proposal would be that the partial l= ock survives the global lock and can be freed when the session decides to d= o so in its sw module hierarchy (whereever in the module the decision is ta= ken). Since it is one session doing it I would assume the locks are done an= d released based on a FIFO principle.=0AII) The same behaviour I would also= assume in case of an overlapping partial lock.=0A=0AMartin Bjorklund wrote= :=0A> Sent: Tuesday, December 11, 2007 9:10 PM=0A> To: ietf@andybierman.com= =0A...=0A> Suppose you write a routine that grabs a lock of /foo/bar/baz, d= oes something and then=0A> releases the lock. Later, you might call this r= outine from code that=0A> already have /foo/bar locked (or /foo/bar/baz/xxx= /yyy). Thus one can=0A> argue that the code on the manager will get more c= omplicated if we=0A> don't allow overlapping locks.=0A> =0A> I will also ar= gue that the code in the agent does not necessarily=0A> become more complic= ated with overlapping locks (we have implemented=0A> overlapping locks actu= ally). But maybe that wasn't your point.=0A=0AThis is case II) and it seem= s to be the modular way of implementing a managing session.=0A=0A=0ABalazs = Lengyel wrote:=0A> Sent: Tuesday, December 11, 2007 6:49 PM=0A> To: Andy Bi= erman=0A... =0A> However I don't see this as important, so it is up to Mehm= et to fight for it. For the time being I will not add it to the draft.=0A> = Balazs=0A=0AI wasn't in the discussion when the clausel in RFC 4741 has bee= n finalized.=0AI believe it would make sense to allow case b).=0ANeverthele= ss if there is nobody then me supporting this kind of change then I am will= ing to accept the decision which has been taken in the WG at that time.=0A= =0ACheers, =0AMehmet =0A =0A=0A> -----Original Message-----=0A> From: ext B= alazs Lengyel [mailto:balazs.lengyel@ericsson.com] =0A> Sent: Tuesday, Dece= mber 11, 2007 6:15 PM=0A> To: Mehmet Ersue=0A> Cc: netconf@ops.ietf.org; Ma= rtin Bjorklund=0A> Subject: Re: Comments on Partial Locking -01=0A> =0A> He= llo Mehmet,=0A> We could propose to allow a global lock after a partial loc= k =0A> by the same session, it is even =0A> logical in a way.=0A> =0A> Howe= ver the main NETCONF standard says:=0A> " An attempt to lock the confi= guration MUST fail if an existing=0A> session or other entity holds = a lock on any portion of the lock=0A> target."=0A> This means we can= not allow the global lock. I think what you =0A> propose does not violate = the =0A> spirit of the RFC4741, but it does violate the exact rule in the R= FC.=0A> =0A> Also we would have to deal with some tricky cases:=0A> 1) sess= ion A issues partial-lock-A=0A> 2) session A issues global-lock=0A> - Shoul= d the partial-lock still be kept, or does this automatically remove all par= tial locks =0A> for session-A for the specified datastore? (propose YES)=0A= > - after the successful global lock should it be possible to use a partial= lock for the same =0A> datastore by the same session ? (propose NO)=0A> 3)= session-A issues global-unlock=0A> - should the partial locks stay alive ?= (propose NO)=0A> =0A> regards Balazs=0A> =0A> Mehmet Ersue wrote:=0A> > = =0A> > I wouldn't mind if the full lock does not fail when both of =0A> the= locks =0A> > have been initiated by the same session.=0A> > Then the quest= ion is whether the partial lock should =0A> survive which seems =0A> > to b= e useful.=0A> > =0A> > Cheers,=0A> > Mehmet=0A> =0A> =0A=0A=0A=0A=0A H= eute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail --0-11784112-1197406395=:10727 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Balazs, Martin, Andy,

I believe the rule in RFC4741 i= s correct and should be kept if two subsequent locks are done by different = sessions.
Let us assume shortly ;-) that the rule wouldn't exist for two= subsequent locks done by the same session.

IMHO:
a) A partial lo= ck after a global lock MUST fail.
b) A global lock after a partial lock = SHOULD be allowed.
I) If above happens it is the easiest way of implemen= tation (for the managing session and the managed node) if the global lock a= nd partial lock are handled independently.
I.e. the proposal would be th= at the partial lock survives the global lock and can be freed when the sess= ion decides to do so in its sw module hierarchy (whereever in the module th= e decision is taken). Since it is one session doing it I would assume the locks are done and released based on a FIFO principle.
II) The same= behaviour I would also assume in case of an overlapping partial lock.
<= br>Martin Bjorklund wrote:
> Sent: Tuesday, December 11, 2007 9:10 PM=
> To: ietf@andybierman.com
...
> Suppose you write a routin= e that grabs a lock of /foo/bar/baz, does something and then
> releas= es the lock.  Later, you might call this routine from code that
>= ; already have /foo/bar locked (or /foo/bar/baz/xxx/yyy).  Thus one ca= n
> argue that the code on the manager will get more complicated if w= e
> don't allow overlapping locks.
>
> I will also argue= that the code in the agent does not necessarily
> become more compli= cated with overlapping locks (we have implemented
> overlapping locks= actually).  But maybe that wasn't your point.

This is case II)= and it seems to be the modular way of implementing a managing session.


Balazs Lengyel wrote:
> Sent: Tuesday, December = 11, 2007 6:49 PM
> To: Andy Bierman
...
> However I don't s= ee this as important, so it is up to Mehmet to fight for it. For the time b= eing I will not add it to the draft.
> Balazs

I wasn't in the = discussion when the clausel in RFC 4741 has been finalized.
I believe it= would make sense to allow case b).
Nevertheless if there is nobody then= me supporting this kind of change then I am willing to accept the decision= which has been taken in the WG at that time.

Cheers,
Mehmet  

> -----Original Message-----
> From: ext Balazs Len= gyel [mailto:balazs.lengyel@ericsson.com]
> Sent: Tuesday, December = 11, 2007 6:15 PM
> To: Mehmet Ersue
> Cc: netconf@ops.ietf.org;= Martin Bjorklund
> Subject: Re: Comments on Partial Locking -01
&= gt;
> Hello Mehmet,
> We could propose to allow a global lock after a partial lock
> by the same session, it is even =
> logical in a way.
>
> However the main NETCONF standa= rd says:
> "      An attempt to lock the con= figuration MUST fail if an existing
>     &n= bsp;  session or other entity holds a lock on any portion of the lock<= br>>        target."
> This mea= ns we can not allow the global lock. I think what you
> propose does= not violate the
> spirit of the RFC4741, but it does violate the ex= act rule in the RFC.
>
> Also we would have to deal with some = tricky cases:
> 1) session A issues partial-lock-A
> 2) session= A issues global-lock
> - Should the partial-lock still be kept, or d= oes this automatically remove all partial locks
> for session-A for = the specified datastore? (propose YES)
> - after the successful global lock should it be possible to use a partial lock for the= same
> datastore by the same session ? (propose NO)
> 3) sess= ion-A issues global-unlock
> - should the partial locks stay alive ? = (propose NO)
>
> regards Balazs
>
> Mehmet Ersue = wrote:
> >
> > I wouldn't mind if the full lock does not= fail when both of
> the locks
> > have been initiated by = the same session.
> > Then the question is whether the partial loc= k should
> survive which seems
> > to be useful.
> &= gt;
> > Cheers,
> > Mehmet
>
>

=0A=0A=0A=0A
Heute schon einen Blick in die Zukun= ft von E-Mails wagen? Versuchen Sie=C2=B4s mit dem =0Aneuen Yahoo! Mail. =0A --0-11784112-1197406395=:10727-- -- to unsubscribe send a message to netconf-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 Dec 11 16:01:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CE9-0003Zt-5D for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 16:01:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2CE8-0001qQ-NE for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 16:01:17 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2C8x-0006or-Sn for netconf-data@psg.com; Tue, 11 Dec 2007 20:55:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2C8t-0006o8-QA for netconf@ops.ietf.org; Tue, 11 Dec 2007 20:55:54 +0000 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id E76CD1B80CC; Tue, 11 Dec 2007 21:55:50 +0100 (CET) Date: Tue, 11 Dec 2007 21:52:01 +0100 (CET) Message-Id: <20071211.215201.74133142.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: partial locking and access control From: Martin Bjorklund In-Reply-To: <475EE748.6020500@andybierman.com> References: <47598B82.2040904@andybierman.com> <20071207.200316.206726089.mbj@tail-f.com> <475EE748.6020500@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > > ..... > >> Also, what if another session issues a that matches > >> this new node, but none of the nodes locked in the first partial-lock > >> RPC (by the other session). This new node would of matched the > >> original Xpath expression had it existed at the time. > > > > Sure, but since it didn't, it wasn't locked. > > > > This is an important issue, and demonstrates the problems with > the current approach in the draft. > > Let's say an operator locks "*/ifAdminStatus" to make sure that > nobody turns off any interfaces during some network test > or big config change. Well, this simply doesn't lock all interfaces as you point out. This won't work with the plain instance identifier approach either, if the operator gets a list of all interfaces from the box and locks them all explicitly. > There are 2 separate issues here: > > 1) Designing a partial locking mechanism that meets operator expectations I agree that locking a simple subtree (instance identifier) is simple and easy to understand. > 2) Monitoring which nodes are actually locked by a partial-lock operation Actually, this can still be solved for the general XPath case. In the monitoring list of locks, we can simply list all instance identifiers held by a lock: leaf-list locked-subtree { type instance-identifier; } This is what we'd have to do for the instance-identifier only solution as well. This being said, I don't have a strong opinion on this issue. But I don't think the arguments I have seen so far says that general XPath cannot be used. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 16:05:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CII-0007u8-11 for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 16:05:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2CIH-0001x8-N7 for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 16:05:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2CDC-0007ID-30 for netconf-data@psg.com; Tue, 11 Dec 2007 21:00:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2CD7-0007Hi-A9 for netconf@ops.ietf.org; Tue, 11 Dec 2007 21:00:16 +0000 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 3C8951B80CC; Tue, 11 Dec 2007 22:00:12 +0100 (CET) Date: Tue, 11 Dec 2007 21:56:22 +0100 (CET) Message-Id: <20071211.215622.126980164.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, netconf@ops.ietf.org Subject: Re: partial locking and access control From: Martin Bjorklund In-Reply-To: <200712112037.lBBKb45a050521@idle.juniper.net> References: <475EE748.6020500@andybierman.com> <200712112037.lBBKb45a050521@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Phil Shafer wrote: > IMHO the data model needs to define what's lockable. Supporting > random XPath expression locking is way too expensive. Note that random XPath is only supported if the :xpath capability is supported. Implementation-wise, if your code handles :xpath, it will not be more expensive to handle random xpath for partial locking. (That's what we do in our implementation - we just send the xpath to our xpath evaluator, and it will return a node set. Each node in the node set will be locked. For a xpath filter in a , we just use the same xpath evaluator but sends the selected nodes in the rpc-reply). /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Dec 11 18:41:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2EjT-0003nc-SV for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 18:41:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2EjR-000615-LQ for netconf-archive@lists.ietf.org; Tue, 11 Dec 2007 18:41:47 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2EcU-000KE5-Jc for netconf-data@psg.com; Tue, 11 Dec 2007 23:34:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.88] (helo=smtp115.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2EcR-000KDi-Nr for netconf@ops.ietf.org; Tue, 11 Dec 2007 23:34:33 +0000 Received: (qmail 16435 invoked from network); 11 Dec 2007 23:34:27 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.122 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 11 Dec 2007 23:34:27 -0000 X-YMail-OSG: 9nqhvPoVM1koe8NMl1OR5gm1NJq9hgH9prJuVdwxeIYvfxPr Message-ID: <475F1E7C.8000603@andybierman.com> Date: Tue, 11 Dec 2007 15:34:20 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund CC: phil@juniper.net, netconf@ops.ietf.org Subject: Re: partial locking and access control References: <475EE748.6020500@andybierman.com> <200712112037.lBBKb45a050521@idle.juniper.net> <20071211.215622.126980164.mbj@tail-f.com> In-Reply-To: <20071211.215622.126980164.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Martin Bjorklund wrote: > Phil Shafer wrote: >> IMHO the data model needs to define what's lockable. Supporting >> random XPath expression locking is way too expensive. > > Note that random XPath is only supported if the :xpath capability is > supported. Implementation-wise, if your code handles :xpath, it will > not be more expensive to handle random xpath for partial locking. > (That's what we do in our implementation - we just send the xpath to > our xpath evaluator, and it will return a node set. Each node in the > node set will be locked. For a xpath filter in a , we just use > the same xpath evaluator but sends the selected nodes in the > rpc-reply). > IMO, random Xpath should be a vendor extension. Prove that it works for locking (I don't think it does.) Take the ifAdminStatus example. This is a valid use-case. The operator needs to specify the desired lock in a way that does not change between compile-time, rule-config-time, and permission-check-time. The ncx-acm access control model uses a list of QName strings as one way to specify an rule target. The QName 'itf:ifAdminStatus' is sufficient to satisfy this basic partial-lock requirement. (Maybe if I knew Xpath better I would think it was a hammer encrusted with such fantastic precious metals that I would clearly want to smash on more nails with it. ;-) > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 12 13:54:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Wj6-0004iV-2m for netconf-archive@lists.ietf.org; Wed, 12 Dec 2007 13:54:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Wj5-0006h1-1B for netconf-archive@lists.ietf.org; Wed, 12 Dec 2007 13:54:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2WU0-0001Hs-2N for netconf-data@psg.com; Wed, 12 Dec 2007 18:39:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [217.146.182.20] (helo=web27815.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2WTO-0001ES-Hl for netconf@ops.ietf.org; Wed, 12 Dec 2007 18:38:44 +0000 Received: (qmail 80344 invoked by uid 60001); 12 Dec 2007 18:38:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=nvBoVc9+8AxscgBn3jy48bcSyGG4gQ5rB/+jm4RWWCBjJn0Sx/FallIrDtU+DRISuX8CSCzPBEAJgVwDocQTpzNrnubsRiOwx0/wKWqKD0vDhKWxqF9NvQLB+pQQ9E8QmYxKlgaL0FN9tm6UvSCt+ojDmRYN/HuEwHRwCbw1iNo=; Received: from [217.115.75.232] by web27815.mail.ukl.yahoo.com via HTTP; Wed, 12 Dec 2007 18:38:20 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Wed, 12 Dec 2007 18:38:20 +0000 (GMT) From: Mehmet Ersue Subject: FW: Comments on Netconf Monitoring To: Balazs , NETCONF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-347812606-1197484700=:78851" Message-ID: <34897.78851.qm@web27815.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 --0-347812606-1197484700=:78851 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi Balazs,=0A=0Agood comments, see below.=0A=0ACheers, =0AMehmet =0A=0A= =0A-----Original Message-----=0AFrom: owner-netconf@ops.ietf.org [mailto:ow= ner-netconf@ops.ietf.org] On Behalf Of ext Balazs Lengyel=0ASent: Monday, D= ecember 10, 2007 3:29 PM=0ATo: Netconf (E-mail)=0ASubject: Comments on Netc= onf Monitoring=0A=0AHello Mark,=0A=0AGeneral)=0ANetconf related performance= counters are needed. Eg.g.=0A- number of sessions=0A- number of current se= ssions=0A[Mehmet:=0AYou differentiate here between 'sessions' and 'current = sessions'. I assume you mean with 'number of sessions' a historic count of = sessions. This has been precluded in the current document. The general ques= tions is whether we need historical information as monitoring data, at leas= t one step back, e.g. "last faulty session" or "last session duration" woul= d make sense.=0A=0APlease add also "operations started per session".=0A=0A= =0A- number of messages, per operation type=0A- number of faults (authentic= ation, XML, etc.)=0A[Mehmet:=0AIf historical data is relevant following dat= a would be interesting:=0A"last fault"=0A"last session duration"=0A"maximum= session duration"=0A"maximum # of parallel sessions per configuration stor= e" ]=0A=0AThe data model is described in XML schema which is just one possi= bility. At the momwent it is =0Amissing real references for session and str= eam. I think a Yang model shall be added at least as =0Aa non-normative app= endix (see attachment). Anyway we should clarify the content of the data = =0Amodel now, and hopefully by the next IETF we will know more about the mo= deling methodology.=0A=0AChapter 1)=0ADo we need this? I propose to remove = it.=0A[Mehmet:=0AI think we need an introduction, but the information here = is mainly available in base documents.]=0A=0ACh 1.1) Remove the last senten= ce for operation.=0A=0ACh.1.2)=0ANetconf state should not be the root level= element, rather we should have something like =0Anetconf/netconfState.=0A[= Mehmet:=0AAgree fully.]=0A=0AIt is possible to have zero sessions in the da= tastore. However when we read it out we will =0Aalways have the reading ses= sion. Still I would rather see minOccurs=3D0=0A=0AHow do we represent CLI/G= UI/etc. sessions? If we are speaking about locking the session can be =0A = an internal process like backup or restart.=0A=0AWhat is a sourceIdentifie= r? Some description is needed. Or should we just call it =0AsessionSourceAd= dress which does not need an explanation?=0A=0APartial locking shall be inc= luded in the schema.=0A[Mehmet:=0AWhat about "running transactions"? ]=0A= =0AThe sessionId must be always present for the lock. A real reference (key= Ref) to the session =0Aobject would be even better.=0A=0Astream should have= a type of ncEvent:streamNameType. A real reference to the stream in the = =0ANotification Management Schema would be even better. (keyRef)=0A=0ARemov= e namedProfile=0A=0AThe transportType enumeration is not complete, and not = prepared for future new transports. It =0Ashould be extensible. Beep and SO= AP missing. Console should be CLI via telnet or SSH. Add none =0Afor intern= al processes.=0A=0ASessionType: Change webui to GUI, add internal=0A=0AsrcI= dentifier: rename to srcAddress. IPv6 and none for internal sessions should= be included.=0A=0Aregards Balazs=0A-- =0ABalazs Lengyel = Ericsson Hungary Ltd.=0ATSP System Manager=0AECN: 831 7320 = Fax: +36 1 4377792=0ATel: +36-1-437-7320 email: Balazs.Lengy= el@ericsson.com=0A=0A=0A=0A=0A __________________________________ Ihr= erstes Fernweh? Wo gibt es den sch=C3=B6nsten Strand? www.yahoo.de/clever --0-347812606-1197484700=:78851 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Balazs,

good comments, see below.

Cheers,
= Mehmet


-----Original Message-----
From: owner-netconf@ops.ie= tf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Balazs Lengyel<= br>Sent: Monday, December 10, 2007 3:29 PM
To: Netconf (E-mail)
Subje= ct: Comments on Netconf Monitoring

Hello Mark,

General)
Ne= tconf related performance counters are needed. Eg.g.
- number of session= s
- number of current sessions
[Mehmet:
You differentiate here between 'sessions' and 'current ses= sions'. I assume you mean with 'number of sessions' a historic count of ses= sions. This has been precluded in the current document. The general questio= ns is whether we need historical information as monitoring data, at least one= step back, e.g. "last faulty session" or "last session duration" would mak= e sense.

Please add also "opera= tions started per session".


- number of messages, per ope= ration type
- number of faults (authentication, XML, etc.)
[Mehmet:
If historical data is relevant= following data would be interesting:
"last fault"
"last se= ssion duration"
"maximum session duration"
"maximum # of parallel sessi= ons per configuration store" ]
<= br>The data model is described in XML schema which is just one possibility.= At the momwent it is
missing real references for session and stream. I= think a Yang model shall be added at least as
a non-normative appendix= (see attachment). Anyway we should clarify the content of the data
mod= el now, and hopefully by the next IETF we will know more about the modeling= methodology.

Chapter 1)
Do we need this? I propose to remove it.=
[Mehmet:
I think we need = an introduction, but the information here is mainly available in base docum= ents.]

Ch 1.1) Remove the last sentence for operation.
Ch.1.2)
Netconf state should not be the root level element, rather we should have something like
netconf/netconfState.
[Mehmet:
Agree fully.]

It is possible to have zero sessions in the datastor= e. However when we read it out we will
always have the reading session.= Still I would rather see minOccurs=3D0

How do we represent CLI/GUI/= etc. sessions? If we are speaking about locking the session can be
&nbs= p;  an internal process like backup or restart.

What is a sourc= eIdentifier? Some description is needed. Or should we just call it
sess= ionSourceAddress which does not need an explanation?

Partial locking= shall be included in the schema.
[Mehmet:
What about "running transactions"? ]

The ses= sionId must be always present for the lock. A real reference (keyRef) to the sess= ion
object would be even better.

stream should have a type of nc= Event:streamNameType. A real reference to the stream in the
Notificatio= n Management Schema would be even better. (keyRef)

Remove namedProfi= le

The transportType enumeration is not complete, and not prepared f= or future new transports. It
should be extensible. Beep and SOAP missin= g. Console should be CLI via telnet or SSH. Add none
for internal proce= sses.

SessionType: Change webui to GUI, add internal

srcIdent= ifier: rename to srcAddress. IPv6 and none for internal sessions should be = included.

regards Balazs
--
Balazs Lengyel   &= nbsp;           &nbs= p;       Ericsson Hungary Ltd.
TSP System = Manager
ECN: 831 7320           &nbs= p;            Fax: += 36 1 4377792
Tel: +36-1-437-7320     email: Balazs.L= engyel@ericsson.com

=0A=0A=0A=0A
Heute= schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie=C2=B4s m= it dem =0Aneuen Yahoo! Mail. =0A= --0-347812606-1197484700=:78851-- -- to unsubscribe send a message to netconf-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 Dec 13 03:18:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jH5-0003Uc-4B for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:18:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2jH2-0001lw-RN for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:18:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2j5Y-000IIf-NK for netconf-data@psg.com; Thu, 13 Dec 2007 08:06:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2j5W-000IIM-9N for netconf@ops.ietf.org; Thu, 13 Dec 2007 08:06:35 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 692D722503 for ; Thu, 13 Dec 2007 09:06:30 +0100 (CET) X-AuditID: c1b4fb3e-b0ea3bb00000459d-df-4760e8067f38 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5782A2178B for ; Thu, 13 Dec 2007 09:06:30 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 09:06:30 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 09:06:30 +0100 Message-ID: <4760E801.2080305@ericsson.com> Date: Thu, 13 Dec 2007 09:06:25 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: Comments on Partial Locking -01 References: <34492.13851.qm@web27815.mail.ukl.yahoo.com> <475EC5A2.1000501@ericsson.com> <475EBA39.1050404@andybierman.com> <20071211.210950.216169531.mbj@tail-f.com> In-Reply-To: <20071211.210950.216169531.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 08:06:30.0057 (UTC) FILETIME=[113EB990:01C83D5F] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 I don't want to change RFC 4741 b/c of this, but I am sure, the intent of locking is to protect a session from other sessions/interfaces/protocols, and not to decide what the session itself should do. It is not the job of a protocol designer to tell management application designers how to work. This it why I think overlapping locks by the same session might go against the word of the RFC, but not against the spirit. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> If you change the way global locks work, then RFC 4741 needs to be >> obsoleted and a new RFC published to replace it. > > I agree that we should not change RFC 4741 b/c of this. > > > > /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 03:18:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jHR-0003XQ-BY for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:18:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2jHQ-0001mN-L5 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:18:53 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2jBL-000IhJ-Nl for netconf-data@psg.com; Thu, 13 Dec 2007 08:12:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [209.85.146.180] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2jBI-000Ih1-VS for netconf@ops.ietf.org; Thu, 13 Dec 2007 08:12:34 +0000 Received: by wa-out-1112.google.com with SMTP id v27so930242wah.23 for ; Thu, 13 Dec 2007 00:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kyxcDU8uy5aBCbR6TxGJ4uawAC8avEih3t0ommuKihU=; b=p/U0jCaFm9GbnXPP6QupKT++xU+jacD7keOIESlDrz2gDt+PTnfDBk1GN74hzK4cDDB70dqVOZ+f23rKQZHwxHcI0wFdnlLJrDXNdhnVRZ63Iocao1WGPWhL2UXL05TJ7gHnwmYN7mKEPZHJR4svepk+V6+UrKXdip8U668Vmco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iY747jjbd2DkIIZWUkRg62CcOkzEQkttX3xNEJhFjgIwrxqvcwlcWkJC3CCnNNb4GY+tAyhRPcGp9j3eVZFI0rCgt04oFpko1cmOtCCas64l1N8WQxU2sKsPhcAxvyNB/wty/wL4KSk8Rxse1QO+0ICTEbLPQJUlb5VXm189eaw= Received: by 10.115.90.1 with SMTP id s1mr1950823wal.50.1197533552670; Thu, 13 Dec 2007 00:12:32 -0800 (PST) Received: by 10.114.170.14 with HTTP; Thu, 13 Dec 2007 00:12:32 -0800 (PST) Message-ID: <604272210712130012j56faf432l93e2c059af11d510@mail.gmail.com> Date: Thu, 13 Dec 2007 09:12:32 +0100 From: "=?ISO-8859-2?Q?Tomasz_Miko=B3ajczyk?=" To: netconf@ops.ietf.org, "Mehmet Ersue" Subject: Re: Comments on Partial Locking -01 In-Reply-To: <7944.10727.qm@web27807.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7944.10727.qm@web27807.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede On Dec 11, 2007 9:53 PM, Mehmet Ersue wrote: > IMHO: > a) A partial lock after a global lock MUST fail. > b) A global lock after a partial lock SHOULD be allowed. I don't agree with the point a). In the case when a session A wants to lock (partial lock) /foo/bar and /foo/baz, it can execute the global lock first to protect against the situation, when during partial locking /foo/bar another session (B) would lock partially /foo/baz. It means that after the following steps: 1) global lock 2) partial lock of /foo/bar 3) partial lock of /foo/baz 4) global unlock session A keeps lock on /foo/bar and /foo/baz. Regards Tomasz Mikolajczyk > I) If above happens it is the easiest way of implementation (for the > managing session and the managed node) if the global lock and partial lock > are handled independently. > I.e. the proposal would be that the partial lock survives the global lock > and can be freed when the session decides to do so in its sw module > hierarchy (whereever in the module the decision is taken). Since it is one > session doing it I would assume the locks are done and released based on a > FIFO principle. > II) The same behaviour I would also assume in case of an overlapping partial > lock. > > Martin Bjorklund wrote: > > Sent: Tuesday, December 11, 2007 9:10 PM > > To: ietf@andybierman.com > ... > > > Suppose you write a routine that grabs a lock of /foo/bar/baz, does > something and then > > releases the lock. Later, you might call this routine from code that > > already have /foo/bar locked (or /foo/bar/baz/xxx/yyy). Thus one can > > argue that the code on the manager will get more complicated if we > > don't allow overlapping locks. > > > > I will also argue that the code in the agent does not necessarily > > become more complicated with overlapping locks (we have implemented > > overlapping locks actually). But maybe that wasn't your point. > > This is case II) and it seems to be the modular way of implementing a > managing session. > > > Balazs Lengyel wrote: > > Sent: Tuesday, December 11, 2007 6:49 PM > > To: Andy Bierman > ... > > > However I don't see this as important, so it is up to Mehmet to fight for > it. For the time being I will not add it to the draft. > > Balazs > > I wasn't in the discussion when the clausel in RFC 4741 has been finalized. > I believe it would make sense to allow case b). > Nevertheless if there is nobody then me supporting this kind of change then > I am willing to accept the decision which has been taken in the WG at that > time. > > Cheers, > Mehmet > > > > > -----Original Message----- > > From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > > Sent: Tuesday, December 11, 2007 6:15 PM > > To: Mehmet Ersue > > Cc: netconf@ops.ietf.org; Martin Bjorklund > > Subject: Re: Comments on Partial Locking -01 > > > > Hello Mehmet, > > We could propose to allow a global lock after a partial lock > > by the same session, it is even > > logical in a way. > > > > However the main NETCONF standard says: > > " An attempt to lock the configuration MUST fail if an existing > > session or other entity holds a lock on any portion of the lock > > target." > > This means we can not allow the global lock. I think what you > > propose does not violate the > > spirit of the RFC4741, but it does violate the exact rule in the RFC. > > > > Also we would have to deal with some tricky cases: > > 1) session A issues partial-lock-A > > 2) session A issues global-lock > > - Should the partial-lock still be kept, or does this automatically remove > all partial locks > > for session-A for the specified datastore? (propose YES) > > - after the successful global lock should it be possible to use a partial > lock for the same > > datastore by the same session ? (propose NO) > > 3) session-A issues global-unlock > > - should the partial locks stay alive ? (propose NO) > > > > regards Balazs > > > > Mehmet Ersue wrote: > > > > > > I wouldn't mind if the full lock does not fail when both of > > the locks > > > have been initiated by the same session. > > > Then the question is whether the partial lock should > > survive which seems > > > to be useful. > > > > > > Cheers, > > > Mehmet > > -- to unsubscribe send a message to netconf-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 Dec 13 03:21:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jJs-0005sg-VM for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:21:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2jJs-0001qH-H5 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:21:24 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2jES-000IwD-8S for netconf-data@psg.com; Thu, 13 Dec 2007 08:15:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2jEN-000Ivn-VI for netconf@ops.ietf.org; Thu, 13 Dec 2007 08:15:47 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 84116227D5 for ; Thu, 13 Dec 2007 09:13:12 +0100 (CET) X-AuditID: c1b4fb3e-b0ea3bb00000459d-16-4760e998c7dd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 76B15227D3 for ; Thu, 13 Dec 2007 09:13:12 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 09:13:12 +0100 Received: from [159.107.198.61] ([159.107.198.61]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 09:13:12 +0100 Message-ID: <4760E997.3020508@ericsson.com> Date: Thu, 13 Dec 2007 09:13:11 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Dynamic lock scope or simple lock scope ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 08:13:12.0184 (UTC) FILETIME=[00EE6F80:01C83D60] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hello Sharon, You touch one of the most interesting issues here. If we allow to lock "groups of nodes" e.g. all interfaces not just one or more individual nodes then we have a problem. However you define the group it is possible that new members will be created. Now you might pick up these members dynamically or not. If not then your XPATH expression will be slightly misleading when new nodes are created. If yes you have a lock in which the nodes are dynamically changing. This could be most confusing. Imagine that you use the position() function to select a node, and someone adds or deletes a node before your node. If we have dynamic nodes you suddenly lock something you never intended, while your intended node is not locked. The same situation might arise with the use of the following or preceding axis. I see two ways to avoid this unacceptable situation: 1) Use an extremely simple XPATH like what Andy is proposing, so that you can avoid dynamic changes. This forbids stuff like lock all interfaces. It only gives us a basic functionality. Some people might say we need a more flexible solution. 2) Evaluate XPATH only once and accept that the XPATH might become outdated. The real lock should be maintained as a set of nodes that were originally selected by the XPATH. In the netconf monitoring data model we should probably have a list of nodes instead/beside the original XPATH expression for partial locks. Balazs > Sharon Chisholm wrote: > > > > 2. Section 2.4.1, second paragraph, I assume the discussion of the > > partial lock not picking up new stuff to lock is done for simplicity? I > > am not sure it is what the user would want. I'd also be interested in an > > example of how new stuff get created if there is a lock. > -- to unsubscribe send a message to netconf-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 Dec 13 03:31:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jU4-0007Uv-MG for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:31:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2jU4-0002EH-B8 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 03:31:56 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2jOU-000JpX-Se for netconf-data@psg.com; Thu, 13 Dec 2007 08:26:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2jOS-000JpC-4A for netconf@ops.ietf.org; Thu, 13 Dec 2007 08:26:09 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 55C061B80C5; Thu, 13 Dec 2007 09:26:05 +0100 (CET) Date: Thu, 13 Dec 2007 09:27:44 +0100 (CET) Message-Id: <20071213.092744.181358846.mbj@tail-f.com> To: miksiu@gmail.com Cc: netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 From: Martin Bjorklund In-Reply-To: <604272210712130012j56faf432l93e2c059af11d510@mail.gmail.com> References: <7944.10727.qm@web27807.mail.ukl.yahoo.com> <604272210712130012j56faf432l93e2c059af11d510@mail.gmail.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f "Tomasz_Miko=B3ajczyk" wrote: > On Dec 11, 2007 9:53 PM, Mehmet Ersue wrote: > > IMHO: > > a) A partial lock after a global lock MUST fail. > > b) A global lock after a partial lock SHOULD be allowed. > = > I don't agree with the point a). In the case when a session A wants t= o > lock (partial lock) /foo/bar and /foo/baz, it can execute the global > lock first to protect against the situation, when during partial > locking /foo/bar another session (B) would lock partially /foo/baz. I= t > means that after the following steps: > 1) global lock > 2) partial lock of /foo/bar > 3) partial lock of /foo/baz > 4) global unlock > session A keeps lock on /foo/bar and /foo/baz. This particular use case is actually handled in the current draft by doing a single operation: = partial-lock(/foo/bar, /foo/baz) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 06:03:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2lqQ-00042x-Q5 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 06:03:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2lqQ-0006qx-3h for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 06:03:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2lgm-0004V4-DQ for netconf-data@psg.com; Thu, 13 Dec 2007 10:53:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [217.146.182.19] (helo=web27814.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2lgG-0004Sr-MZ for netconf@ops.ietf.org; Thu, 13 Dec 2007 10:52:57 +0000 Received: (qmail 87245 invoked by uid 60001); 13 Dec 2007 10:52:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=lvo+RaeIp1F72eCLPD5XyMjierb4Pv6Uj22r4G/s048oRuRPrbxW9ZAP6TrxChOHFIH8XyH6G0saIJT5qwijFSL956DSYnWBJSyPE0bJopSN1/MXGWJFVl1j+FDhx+zg7N+jUCKVOVHPgKVKNs85Kl7SoZgGmZMknR+d/SqC+qg=; X-YMail-OSG: F1YIibcVM1kVmnilQSFJ9a_nkrbgjyWoQ4DnDNaXrgMRxkV1.QObulkgWDJ.9j33ydcPkU1wwVeTKtmx4H3znKvSZnBOK__BCzSKuUK05mgJpniBoRQ37jU9drg- Received: from [217.115.75.232] by web27814.mail.ukl.yahoo.com via HTTP; Thu, 13 Dec 2007 10:52:38 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Thu, 13 Dec 2007 10:52:38 +0000 (GMT) From: Mehmet Ersue Subject: RE: Comments on Partial Locking -01 To: miksiu@gmail.com, Martin , NETCONF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1498721591-1197543158=:86801" Message-ID: <231897.86801.qm@web27814.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --0-1498721591-1197543158=:86801 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A> > > a) A partial lock after a global lock MUST fail.=0A> > > b) A glob= al lock after a partial lock SHOULD be allowed.=0A> > =0A> > I don't agree = with the point a). In the case when a session A wants to=0A> > lock (partia= l lock) /foo/bar and /foo/baz, it can execute the global=0A> > lock first t= o protect against the situation, when during partial=0A> > locking /foo/bar= another session (B) would lock partially /foo/baz. It=0A> > means that aft= er the following steps:=0A> > 1) global lock=0A> > 2) partial lock of /foo/= bar=0A> > 3) partial lock of /foo/baz=0A> > 4) global unlock=0A> > session = A keeps lock on /foo/bar and /foo/baz.=0A> =0A> This particular use case is= actually handled in the current draft by=0A> doing a single operation:=0A>= =0A> partial-lock(/foo/bar, /foo/baz)=0A=0AI agree, this is the atomi= c way to partial lock two areas at once. Three =0Alock operations before we= can be sure the session can start working =0A(global lock, partial lock of= /foo/bar, partial lock of /foo/baz) wouldn't be efficient.=0A=0AMehmet=0A= =0A> =0A> =0A> /martin=0A=0A=0A=0A=0A=0A Heute schon einen Blick in di= e Zukunft von E-Mails wagen? www.yahoo.de/mail --0-1498721591-1197543158=:86801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

> > > a) A partial lock after a global lock MUST fail.=
> > > b) A global lock after a partial lock SHOULD be allowed.=
> >
> > I don't agree with the point a). In the case wh= en a session A wants to
> > lock (partial lock) /foo/bar and /foo/= baz, it can execute the global
> > lock first to protect against t= he situation, when during partial
> > locking /foo/bar another ses= sion (B) would lock partially /foo/baz. It
> > means that after th= e following steps:
> > 1) global lock
> > 2) partial lock= of /foo/bar
> > 3) partial lock of /foo/baz
> > 4) globa= l unlock
> > session A keeps lock on /foo/bar and /foo/baz.
>= ;
> This particular use case is actually handled in the current draft by
> doing a single operation:
>   
&= gt;   partial-lock(/foo/bar, /foo/baz)

I agree, this is th= e atomic way to partial lock two areas at once. Three
lock operations b= efore we can be sure the session can start working
(global lock, partia= l lock of /foo/bar, partial lock of /foo/baz) wouldn't be efficient.
Mehmet

>
>
> /martin


=0A=0A= =0A
Beginnen Sie den Tag mit den neuesten Nachrichten. Machen Sie Yahoo! zu Ihrer Startseite! --0-1498721591-1197543158=:86801-- -- to unsubscribe send a message to netconf-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 Dec 13 08:42:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oKA-00060v-1M for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 08:42:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2oK5-0002N8-4j for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 08:42:02 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2oAZ-000IxC-9g for netconf-data@psg.com; Thu, 13 Dec 2007 13:32:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.157] (helo=exprod7og102.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2oAW-000Iwm-AU for netconf@ops.ietf.org; Thu, 13 Dec 2007 13:32:05 +0000 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 13 Dec 2007 05:32:01 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Dec 2007 05:32:01 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBDDW0E96169; Thu, 13 Dec 2007 05:32:00 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lBDDSYOI063360; Thu, 13 Dec 2007 13:28:34 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712131328.lBDDSYOI063360@idle.juniper.net> To: "=?ISO-8859-2?Q?Tomasz_Miko=B3ajczyk?=" cc: netconf@ops.ietf.org, "Mehmet Ersue" Subject: Re: Comments on Partial Locking -01 In-reply-to: <604272210712130012j56faf432l93e2c059af11d510@mail.gmail.com> Date: Thu, 13 Dec 2007 08:28:34 -0500 From: Phil Shafer X-OriginalArrivalTime: 13 Dec 2007 13:32:01.0061 (UTC) FILETIME=[8AA16D50:01C83D8C] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 "=?ISO-8859-2?Q?Tomasz_Miko=B3ajczyk?=" writes: >On Dec 11, 2007 9:53 PM, Mehmet Ersue wrote: >> IMHO: >> a) A partial lock after a global lock MUST fail. Agree. >> b) A global lock after a partial lock SHOULD be allowed. Disagree. A global lock means that I own the store and can do whatever I want with it. I can perform my work knowing that no one else will change the config during the lifetime of my lock. If you give me a lock after giving someone else a lock, then we _both_ think we are safe (which is bad), and I think I can completely change the entire config (which is either not true or the other guy is busted). Bad news all around. The global lock must trump all partial locks, so a global lock after a partial lock MUST NOT be allowed. >I don't agree with the point a). In the case when a session A wants to >lock (partial lock) /foo/bar and /foo/baz, it can execute the global >lock first to protect against the situation, when during partial >locking /foo/bar another session (B) would lock partially /foo/baz. Is this a real-world use case? Why would anyone do this? This isn't an scenario worth our discussion. If you get the global lock, you have no further need of partial locks. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 09:07:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oii-00073m-9x for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 09:07:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2oie-00036p-3e for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 09:07:24 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2obK-000MC6-6v for netconf-data@psg.com; Thu, 13 Dec 2007 13:59:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2obB-000MBF-Nt for netconf@ops.ietf.org; Thu, 13 Dec 2007 13:59:42 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 081CD1B80C5; Thu, 13 Dec 2007 14:59:36 +0100 (CET) Date: Thu, 13 Dec 2007 15:01:16 +0100 (CET) Message-Id: <20071213.150116.191929922.mbj@tail-f.com> To: phil@juniper.net Cc: miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 From: Martin Bjorklund In-Reply-To: <200712131328.lBDDSYOI063360@idle.juniper.net> References: <604272210712130012j56faf432l93e2c059af11d510@mail.gmail.com> <200712131328.lBDDSYOI063360@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Phil Shafer wrote: > "=?ISO-8859-2?Q?Tomasz_Miko=B3ajczyk?=" writes: > >On Dec 11, 2007 9:53 PM, Mehmet Ersue wrote: > >> IMHO: > >> a) A partial lock after a global lock MUST fail. > > Agree. > > >> b) A global lock after a partial lock SHOULD be allowed. > > Disagree. > > A global lock means that I own the store and can do whatever I want > with it. I can perform my work knowing that no one else will change > the config during the lifetime of my lock. If you give me a lock > after giving someone else a lock, then we _both_ think we are safe > (which is bad), In both these cases, the discussion is what happens when the same session performs these requests. In all cases, as soon as there are any overlaps in locks from different sessions, the request MUST fail. This being said, I think it is ok to not allow any overlaps between the global lock and the partial locks, b/c we do not want to modify rfc4741. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 09:34:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2p8V-0007KI-JJ for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 09:34:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2p8R-0003wy-9J for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 09:34:03 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2ouw-000O6S-K7 for netconf-data@psg.com; Thu, 13 Dec 2007 14:20:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2out-000O5h-Vl for netconf@ops.ietf.org; Thu, 13 Dec 2007 14:20:01 +0000 Received: (qmail 96935 invoked from network); 13 Dec 2007 14:19:59 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.165.67 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 13 Dec 2007 14:19:59 -0000 X-YMail-OSG: N1udwmQVM1m01wJtXYEdgrPRmn5247qR9umOgtiitXQgpht1 Message-ID: <47613F8D.9010305@andybierman.com> Date: Thu, 13 Dec 2007 06:19:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: partial lock access rights Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, I do not not understand why the session requesting a partial lock must have "at least read access" to the data indicated by the request. Since locks in NETCONF have no affect whatsoever on reading data, I do not see the purpose of this requirement. I could see the increased security achieved by requiring write access to all the data that a partial-lock covers, but I don't see the point of checking read access, in order to grant a partial lock. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 09:55:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pTg-0008JY-S9 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 09:55:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2pTg-00053U-FN for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 09:55:56 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2pLL-0000un-4x for netconf-data@psg.com; Thu, 13 Dec 2007 14:47:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2pKx-0000ra-Pi for netconf@ops.ietf.org; Thu, 13 Dec 2007 14:47:03 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4E23520438; Thu, 13 Dec 2007 15:46:32 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-fc-476145c8a996 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3851B2001D; Thu, 13 Dec 2007 15:46:32 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 15:46:31 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 15:46:31 +0100 Message-ID: <476145C7.2090502@ericsson.com> Date: Thu, 13 Dec 2007 15:46:31 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" Subject: Re: partial lock access rights References: <47613F8D.9010305@andybierman.com> In-Reply-To: <47613F8D.9010305@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 14:46:31.0809 (UTC) FILETIME=[F3676F10:01C83D96] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hello, The draft is careful and only says: for example read rights. What it really says is: you must have some rights. As you have pointed out, we do not know what the access control model is, but we can assume that there is some kind of access model in place. Balazs Andy Bierman wrote: > Hi, > > I do not not understand why the session requesting a partial lock > must have "at least read access" to the data indicated by the request. > Since locks in NETCONF have no affect whatsoever on reading data, > I do not see the purpose of this requirement. > > I could see the increased security achieved by requiring write access > to all the data that a partial-lock covers, but I don't see the point > of checking read access, in order to grant a partial lock. > > > Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 10:14:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pls-0003iL-Sc for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 10:14:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2plr-0006SP-Hs for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 10:14:44 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2pbl-0002p4-Kr for netconf-data@psg.com; Thu, 13 Dec 2007 15:04:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [135.245.0.37] (helo=ihemail3.lucent.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2pbZ-0002nc-8f for netconf@ops.ietf.org; Thu, 13 Dec 2007 15:04:16 +0000 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lBDF325P018127; Thu, 13 Dec 2007 09:03:48 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 09:03:26 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 16:03:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on Partial Locking -01 Date: Thu, 13 Dec 2007 16:03:18 +0100 Message-ID: In-Reply-To: <20071213.150116.191929922.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Partial Locking -01 Thread-Index: Acg9kLDHJ5CVKd8zSReSrCqZHWjumgACIMFQ References: <604272210712130012j56faf432l93e2c059af11d510@mail.gmail.com><200712131328.lBDDSYOI063360@idle.juniper.net> <20071213.150116.191929922.mbj@tail-f.com> From: "WIJNEN, Bert \(Bert\)" To: "Martin Bjorklund" , Cc: , , X-OriginalArrivalTime: 13 Dec 2007 15:03:24.0782 (UTC) FILETIME=[4F2ED8E0:01C83D99] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > In both these cases, the discussion is what happens when the=20 > same session performs these requests. >=20 > In all cases, as soon as there are any overlaps in locks from=20 > different sessions, the request MUST fail. >=20 > This being said, I think it is ok to not allow any overlaps=20 > between the global lock and the partial locks, b/c we do not=20 > want to modify rfc4741. >=20 A more compelling erason for me is: KISS i.e. no overlaping locks. Period. Bert >=20 > /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 10:16:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pn6-0004jl-Jj for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 10:16:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2pn6-0006UN-63 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 10:16:00 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2phs-0003Vk-8U for netconf-data@psg.com; Thu, 13 Dec 2007 15:10:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.93] (helo=smtp120.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2phM-0003RN-Uf for netconf@ops.ietf.org; Thu, 13 Dec 2007 15:10:20 +0000 Received: (qmail 39406 invoked from network); 13 Dec 2007 15:10:04 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.165.67 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 13 Dec 2007 15:10:04 -0000 X-YMail-OSG: Bp96GWsVM1mNwBACzGLl105vwVQVqMABrf38WqTK1bQi2EQbOqo9ySW5l2upAERu4VyYxCXlg.H5KBzjKxbaROcn Message-ID: <47614B4A.20501@andybierman.com> Date: Thu, 13 Dec 2007 07:10:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Balazs Lengyel CC: "Netconf (E-mail)" Subject: Re: partial lock access rights References: <47613F8D.9010305@andybierman.com> <476145C7.2090502@ericsson.com> In-Reply-To: <476145C7.2090502@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Balazs Lengyel wrote: > Hello, > The draft is careful and only says: for example read rights. What it > really says is: you must have some rights. > As you have pointed out, we do not know what the access control model > is, but we can assume that there is some kind of access model in place. I think the requirement should be removed because this document is supposed to be a standard. I don't see how "assume some rights in some sort of access control model" is supposed to be inter-operable. > Balazs Andy > > Andy Bierman wrote: >> Hi, >> >> I do not not understand why the session requesting a partial lock >> must have "at least read access" to the data indicated by the request. >> Since locks in NETCONF have no affect whatsoever on reading data, >> I do not see the purpose of this requirement. >> >> I could see the increased security achieved by requiring write access >> to all the data that a partial-lock covers, but I don't see the point >> of checking read access, in order to grant a partial lock. >> >> >> Andy >> >> -- >> to unsubscribe send a message to netconf-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 11:03:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qXO-0006gh-OE for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 11:03:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2qXN-0007ij-Aw for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 11:03:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2qJl-0007RT-2O for netconf-data@psg.com; Thu, 13 Dec 2007 15:49:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2qJi-0007R2-4o for netconf@ops.ietf.org; Thu, 13 Dec 2007 15:49:43 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 16A831B80C5; Thu, 13 Dec 2007 16:49:41 +0100 (CET) Date: Thu, 13 Dec 2007 16:51:21 +0100 (CET) Message-Id: <20071213.165121.111033228.mbj@tail-f.com> To: bwijnen@alcatel-lucent.com Cc: phil@juniper.net, miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 From: Martin Bjorklund In-Reply-To: References: <200712131328.lBDDSYOI063360@idle.juniper.net> <20071213.150116.191929922.mbj@tail-f.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi, "WIJNEN, Bert (Bert)" wrote: > A more compelling erason for me is: KISS > i.e. no overlaping locks. Period. Simple for who? I would argue that it's not necessarily simpler on the agent implementation, and maybe even more difficult on the manager implementation (see my earlier posting in this thread.) /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 11:35:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2r20-00033F-7o for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 11:35:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2r1z-0000n8-RK for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 11:35:28 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2qul-000BOb-FL for netconf-data@psg.com; Thu, 13 Dec 2007 16:27:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.93] (helo=smtp120.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2quh-000BNy-7t for netconf@ops.ietf.org; Thu, 13 Dec 2007 16:27:58 +0000 Received: (qmail 11780 invoked from network); 13 Dec 2007 16:27:54 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.165.67 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 13 Dec 2007 16:27:54 -0000 X-YMail-OSG: 4vYbQOUVM1noQ45sDpOhwFnXNSJuE8pNekHOy7.Rehnf_e41 Message-ID: <47615D89.5030403@andybierman.com> Date: Thu, 13 Dec 2007 08:27:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: when to use special RPC methods Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi, This issue that Phil raised about never using special get functions because we already defined , is not quite accurate. There are lots of use cases where a special get function would be better than using : - get-my-session-config paired with set-my-session-config Setting per-session knobs are not really supported in NETCONF. This would require a table of all the sessions, and then lots of access-control configuration to make sure that only session X got to access session[X].knobs. It is much easier to use dedicated RPCs and not use or the config database at all, for 'my-session' sort of features. - deep nested tables with complex keys would be good candidates for additional functions. - Info which might require the manager to retrieve a lot of data, scan it, follow data pointers, and retrieve secondary data. - Special reports that are gathered, based on some input parameters, processed by the agent (e.g., aggregation), and then some data is returned. The example at hand is some plain-old statistics in a container, root under the /netconf element. The Xpath and subtree filtering is sufficient for this data, and a special for '/netconf/foo' seems rather excessive. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 11:51:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rH4-0005fG-Qg for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 11:51:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2rH4-0001Gi-F9 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 11:51:02 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2r0t-000CDJ-QA for netconf-data@psg.com; Thu, 13 Dec 2007 16:34:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.90] (helo=smtp117.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2r0q-000CBG-Qe for netconf@ops.ietf.org; Thu, 13 Dec 2007 16:34:18 +0000 Received: (qmail 51786 invoked from network); 13 Dec 2007 16:34:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.165.67 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 13 Dec 2007 16:34:16 -0000 X-YMail-OSG: nJjD_tMVM1lxqrkNCaM4hUXouaiLyb0ejEBs03Giu4L737No Message-ID: <47615F06.1090209@andybierman.com> Date: Thu, 13 Dec 2007 08:34:14 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund CC: bwijnen@alcatel-lucent.com, phil@juniper.net, miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 References: <200712131328.lBDDSYOI063360@idle.juniper.net> <20071213.150116.191929922.mbj@tail-f.com> <20071213.165121.111033228.mbj@tail-f.com> In-Reply-To: <20071213.165121.111033228.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Martin Bjorklund wrote: > Hi, > > "WIJNEN, Bert (Bert)" wrote: >> A more compelling erason for me is: KISS >> i.e. no overlaping locks. Period. > > Simple for who? I would argue that it's not necessarily simpler on > the agent implementation, and maybe even more difficult on the manager > implementation (see my earlier posting in this thread.) > IMO, it is simpler for the agent implementer to tag each locked node with just one lock-id, but is not much harder to use a Q of lock-id structs, just a lot more memory. Tool implementation is not the key factor. (That interoperability thing again!) IMO over-lapping locks are OK if they can be easily implemented with the same behavior, and the partial-lock monitoring is complete enough to tell exactly what is locked by each lock-id. > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 13:31:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2sqd-0004M0-Kb for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 13:31:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2sqd-0004YS-97 for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 13:31:51 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2sfn-000N5Q-Ct for netconf-data@psg.com; Thu, 13 Dec 2007 18:20:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2sfk-000N56-Rf for netconf@ops.ietf.org; Thu, 13 Dec 2007 18:20:38 +0000 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 13 Dec 2007 10:20:30 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Dec 2007 10:18:37 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBDIIaE57782; Thu, 13 Dec 2007 10:18:36 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lBDIFAN9065412; Thu, 13 Dec 2007 18:15:10 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712131815.lBDIFAN9065412@idle.juniper.net> To: Martin Bjorklund cc: miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 In-reply-to: <20071213.150116.191929922.mbj@tail-f.com> Date: Thu, 13 Dec 2007 13:15:10 -0500 From: Phil Shafer X-OriginalArrivalTime: 13 Dec 2007 18:18:37.0560 (UTC) FILETIME=[948AEF80:01C83DB4] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Martin Bjorklund writes: >In both these cases, the discussion is what happens when the same >session performs these requests. Tomasz mentioned session A and session B: >I don't agree with the point a). In the case when a session A wants to >lock (partial lock) /foo/bar and /foo/baz, it can execute the global >lock first to protect against the situation, when during partial >locking /foo/bar another session (B) would lock partially /foo/baz. And WRT the same session: I'm not seeing the global/partial lock overlaps within the same session as something that's worthy of more words than "DON'T". The app should know what it's locking, why it's locking it, and which type of lock it needs. It shouldn't be changing it's mind in the middle of the transaction. >This being said, I think it is ok to not allow any overlaps between >the global lock and the partial locks, b/c we do not want to modify >rfc4741. Cool. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 13:36:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2svF-0001k5-2X for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 13:36:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2svE-0004gZ-Lb for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 13:36:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2snJ-000Nmo-G5 for netconf-data@psg.com; Thu, 13 Dec 2007 18:28:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.157] (helo=exprod7og102.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2snH-000NmO-11 for netconf@ops.ietf.org; Thu, 13 Dec 2007 18:28:24 +0000 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 13 Dec 2007 10:28:03 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 10:26:44 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBDIQhE59805; Thu, 13 Dec 2007 10:26:43 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lBDINHiu065531; Thu, 13 Dec 2007 18:23:17 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712131823.lBDINHiu065531@idle.juniper.net> To: Andy Bierman cc: Martin Bjorklund , bwijnen@alcatel-lucent.com, miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 In-reply-to: <47615F06.1090209@andybierman.com> Date: Thu, 13 Dec 2007 13:23:16 -0500 From: Phil Shafer X-OriginalArrivalTime: 13 Dec 2007 18:26:44.0581 (UTC) FILETIME=[B6D47150:01C83DB5] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Andy Bierman writes: >IMO, it is simpler for the agent implementer to tag each >locked node with just one lock-id, but is not much harder >to use a Q of lock-id structs, just a lot more memory. Amen. Another point of view: when you put complexity in places it will never be exercised, the likelihood of bugs increases. So if the amount of code I have to write to handle a broken app is large (assuming apps with overlapping locks are likely broken ;^), then my most broken app writers will be tickling code that never gets tickled. And the feedback from such app writers is often limited to "it doesn't work", making debugging more difficult. Don't put complexity into corner cases. KISS. Thanks, Phil P.s.: Not that my code ever has bugs..... -- to unsubscribe send a message to netconf-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 Dec 13 16:40:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vmu-0000Ef-6t for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 16:40:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vmt-0002ia-RQ for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 16:40:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2vZw-000GiE-39 for netconf-data@psg.com; Thu, 13 Dec 2007 21:26:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2vZB-000Gbt-Be for netconf@ops.ietf.org; Thu, 13 Dec 2007 21:26:16 +0000 Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 664FF1B80C5; Thu, 13 Dec 2007 22:25:56 +0100 (CET) Date: Thu, 13 Dec 2007 22:22:01 +0100 (CET) Message-Id: <20071213.222201.47171781.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, bwijnen@alcatel-lucent.com, miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 From: Martin Bjorklund In-Reply-To: <200712131823.lBDINHiu065531@idle.juniper.net> References: <47615F06.1090209@andybierman.com> <200712131823.lBDINHiu065531@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Phil Shafer wrote: > Andy Bierman writes: > >IMO, it is simpler for the agent implementer to tag each > >locked node with just one lock-id, but is not much harder > >to use a Q of lock-id structs, just a lot more memory. ^^^^^^^^^^^^^^^^^ Well... yes if there will be a lot of partial locks. But an implementation can of course always return resource-denied if necessary. Note that an application that puts a partial lock on every leaf in the entire config datastore also use lots of memory... > Another point of view: when you put complexity in places it will > never be exercised, the likelihood of bugs increases. So if the > amount of code I have to write to handle a broken app is large > (assuming apps with overlapping locks are likely broken ;^), I mentioned a possible use case in http://ops.ietf.org/lists/netconf/netconf.2007/msg00708.html Maybe you'd call it broken. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 13 17:11:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wH9-0006xw-Cs for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 17:11:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2wH8-0003Ql-KP for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 17:11:27 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2w86-000Kv8-3R for netconf-data@psg.com; Thu, 13 Dec 2007 22:02:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [217.146.182.20] (helo=web27815.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2w7k-000KsU-DU for netconf@ops.ietf.org; Thu, 13 Dec 2007 22:01:55 +0000 Received: (qmail 92175 invoked by uid 60001); 13 Dec 2007 22:01:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=xuctZ1xavTx10d/xkz00jfVX8S1ld8IDf0souw0uMJVXZANuc0Hu+7VakLTglqHE4q2Ajkf6bbOiF2JYuXadq4+kWAvG7Q4eB2K52UPJEBloh4VJwrzfPQEVek5D/62669C8EegC75XZ17R+CgegJdZRJMUE+db3WrzEgL6drAs=; X-YMail-OSG: rqBkoecVM1nbIgHCmdgObK3lTWm08heGL0M_7ci4cmV8DIv09uGF43S8wl7vq7gVDHmOi64JYiGGzfEhHusplTtnTuWttjNBa_aH8L3xfqaGKXgxhxmXazHXJlo- Received: from [217.115.75.232] by web27815.mail.ukl.yahoo.com via HTTP; Thu, 13 Dec 2007 22:01:40 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Thu, 13 Dec 2007 22:01:40 +0000 (GMT) From: Mehmet Ersue Subject: RE: Comments on Partial Locking -01 To: Martin , phil@juniper.net Cc: NETCONF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1364967072-1197583300=:89144" Message-ID: <812172.89144.qm@web27815.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a --0-1364967072-1197583300=:89144 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, Phil,=0A=0AMartin Bjorklund wrote:=0A> Phil Shafer wrote:=0A> > Andy Bierman writes:=0A> > >IMO, it is simpler for the a= gent implementer to tag each=0A> > >locked node with just one lock-id, but = is not much harder=0A> > >to use a Q of lock-id structs, just a lot more me= mory.=0A> ^^^^^^^^^^^^^^^^^=0A> =0A>= Well... yes if there will be a lot of partial locks. But an=0A> implement= ation can of course always return resource-denied if=0A> necessary. Note t= hat an application that puts a partial lock on every=0A> leaf in the entire= config datastore also use lots of memory...=0A> =0A> =0A> > Another point = of view: when you put complexity in places it will=0A> > never be exercised= , the likelihood of bugs increases. So if the=0A> > amount of code I have = to write to handle a broken app is large=0A> > (assuming apps with overlapp= ing locks are likely broken ;^),=0A> =0A> I mentioned a possible use case i= n=0A> http://ops.ietf.org/lists/netconf/netconf.2007/msg00708.html=0A> =0A>= Maybe you'd call it broken.=0A> =0A> /martin=0A=0AIf you implement a huge = amount of modular code for configuration management =0A(which is probably s= plit into different threads) =0Ayou don't want to keep a tally of already e= xecuted partial locks =0Anor do you want to lock strongly sequentially and = step by step. =0AIMO it is indeed more complicated to handle the situation = when overlapping locks are not allowed.=0A=0AAs long as the partial locks a= re executed from the same session and simple rules are followed (e.g. last = lock-first release) =0Ayou are on the safe side and have the flexibility fo= r the implementation of a modular manager.=0A=0AMehmet=0A=0A=0A=0A=0A=0A = __________________________________ Ihre erste Baustelle? Wissenswertes= f=C3=BCr Bastler und Hobby Handwerker. www.yahoo.de/clever --0-1364967072-1197583300=:89144 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Martin, Phil,

Martin Bjorklund wrote:
> Phil Shafer= <phil@juniper.net> wrote:
> > Andy Bierman writes:
> = > >IMO, it is simpler for the agent implementer to tag each
> &= gt; >locked node with just one lock-id, but is not much harder
> &= gt; >to use a Q of lock-id structs, just a lot more memory.
> = ;            &n= bsp;            = ;            &n= bsp; ^^^^^^^^^^^^^^^^^
>
> Well... yes if there will be a lot = of partial locks.  But an
> implementation can of course always = return resource-denied if
> necessary.  Note that an application that puts a partial lock on every
> leaf in the entire c= onfig datastore also use lots of memory...
>
>
> > A= nother point of view: when you put complexity in places it will
> >= ; never be exercised, the likelihood of bugs increases.  So if the
= > > amount of code I have to write to handle a broken app is large> > (assuming apps with overlapping locks are likely broken ;^),
= >
> I mentioned a possible use case in
> http://ops.ietf.org/lists/netconf/netconf.2007/msg00708.html=
>
> Maybe you'd call it broken.
>
> /martin
<= br>If you implement a huge amount of modular code for configuration managem= ent
(which is probably split into different threads)
you don't want= to keep a tally of already executed partial locks
nor do you want to lock strongly sequentially and step by step.
IMO it is indeed more = complicated to handle the situation when overlapping locks are not allowed.=

As long as the partial locks are executed from the same session and= simple rules are followed (e.g. last lock-first release)
you are on th= e safe side and have the flexibility for the implementation of a modular ma= nager.

Mehmet


=0A=0A=0A
Beg= innen Sie den Tag mit den neuesten Nachrichten. Machen Sie Yaho= o! zu Ihrer Startseite! --0-1364967072-1197583300=:89144-- -- to unsubscribe send a message to netconf-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 Dec 13 22:13:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J30zA-000835-Ob for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 22:13:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J30z9-0001Hr-BH for netconf-archive@lists.ietf.org; Thu, 13 Dec 2007 22:13:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J30nc-000OAJ-7D for netconf-data@psg.com; Fri, 14 Dec 2007 03:01:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.18.2.163] (helo=exprod7og105.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J30n7-000O6K-HQ for netconf@ops.ietf.org; Fri, 14 Dec 2007 03:01:00 +0000 Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 13 Dec 2007 19:00:30 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 18:57:24 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBE2vNE81859; Thu, 13 Dec 2007 18:57:24 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lBE2rux7068711; Fri, 14 Dec 2007 02:53:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200712140253.lBE2rux7068711@idle.juniper.net> To: Martin Bjorklund cc: ietf@andybierman.com, bwijnen@alcatel-lucent.com, miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 In-reply-to: <20071213.222201.47171781.mbj@tail-f.com> Date: Thu, 13 Dec 2007 21:53:56 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Dec 2007 02:57:24.0927 (UTC) FILETIME=[0DE634F0:01C83DFD] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Martin Bjorklund writes: >I mentioned a possible use case in >http://ops.ietf.org/lists/netconf/netconf.2007/msg00708.html My concern is less with overlapping partial locks than with the interaction between global and partial locks. In your use case, the modular code should know whether it has already grabbed the global lock. Thanks, Phil -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 14 07:04:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39Gv-00059k-3S for netconf-archive@lists.ietf.org; Fri, 14 Dec 2007 07:04:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J39Gt-0003Be-LE for netconf-archive@lists.ietf.org; Fri, 14 Dec 2007 07:04:05 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J397D-000LL5-P6 for netconf-data@psg.com; Fri, 14 Dec 2007 11:54:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J396j-000LG1-2p for netconf@ops.ietf.org; Fri, 14 Dec 2007 11:53:48 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id ABEB91B80F1; Fri, 14 Dec 2007 12:35:18 +0100 (CET) Date: Fri, 14 Dec 2007 12:37:00 +0100 (CET) Message-Id: <20071214.123700.198101330.mbj@tail-f.com> To: phil@juniper.net Cc: ietf@andybierman.com, bwijnen@alcatel-lucent.com, miksiu@gmail.com, netconf@ops.ietf.org, m_ersue@yahoo.de Subject: Re: Comments on Partial Locking -01 From: Martin Bjorklund In-Reply-To: <200712140253.lBE2rux7068711@idle.juniper.net> References: <20071213.222201.47171781.mbj@tail-f.com> <200712140253.lBE2rux7068711@idle.juniper.net> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Phil Shafer wrote: > Martin Bjorklund writes: > >I mentioned a possible use case in > >http://ops.ietf.org/lists/netconf/netconf.2007/msg00708.html > > My concern is less with overlapping partial locks than with > the interaction between global and partial locks. Good! I think we all agree that we don't want to change rfc4741, and thus we should not allow any overlaps between partial locks and the global locks. A global lock MUST fail even if the same session has a partial lock and a partial lock MUST fail even if the same session has the global lock. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 17 03:22:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4BEz-0003sO-76 for netconf-archive@lists.ietf.org; Mon, 17 Dec 2007 03:22:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4BEy-00047k-Mb for netconf-archive@lists.ietf.org; Mon, 17 Dec 2007 03:22:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4B6T-000IbO-OJ for netconf-data@psg.com; Mon, 17 Dec 2007 08:13:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [209.85.146.180] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4B6Q-000Ib5-3c for netconf@ops.ietf.org; Mon, 17 Dec 2007 08:13:32 +0000 Received: by wa-out-1112.google.com with SMTP id v27so3209581wah.23 for ; Mon, 17 Dec 2007 00:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xNnsXDln8EdqarhOAX4lfVfSsDMmrGgwPlIk6Idc+iw=; b=c3TEdoxDqEg4qzxl94FWYLUgN+/mYxT46esaDIA4DYJXcY/hIcbr9CDNhfvGG8GfjzGZUfhzoUBE82lFUqd4LlLsGw8qtQ2zpMTam0u1iSyTfuicR4tV5VDwjRPZMTY524wEQV7s4hqsJLKPSJ82muB5M3E3ma5/Hp1avHmRAWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KEb5G+ECzqRXc6z6rnUfHSaLnaTtcecYx22mDWkcJ12sZsDBxb1wQcre0PuDJakqn6B3rEwS4rQxvkthNF2XOmJlfRHK/lES94eyOgZ/krZ3wXAjYvAPZnySPw+Ykvdk2w9mUMepDD6T3tgIBIzQpaTW/xMEwUkLdD57zfTWns0= Received: by 10.115.77.1 with SMTP id e1mr379006wal.103.1197879209604; Mon, 17 Dec 2007 00:13:29 -0800 (PST) Received: by 10.114.170.14 with HTTP; Mon, 17 Dec 2007 00:13:29 -0800 (PST) Message-ID: <604272210712170013qa81d415od9e88160df69713a@mail.gmail.com> Date: Mon, 17 Dec 2007 09:13:29 +0100 From: "Tomasz Mikolajczyk" To: netconf@ops.ietf.org Subject: Re: Comments on Partial Locking -01 In-Reply-To: <604272210712140003h1a62776dy9e0cf5eeddc557c8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <231897.86801.qm@web27814.mail.ukl.yahoo.com> <604272210712140003h1a62776dy9e0cf5eeddc557c8@mail.gmail.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Dec 13, 2007 11:52 AM, Mehmet Ersue wrote: > > > > > > > a) A partial lock after a global lock MUST fail. > > > > b) A global lock after a partial lock SHOULD be allowed. > > > > > > I don't agree with the point a). In the case when a session A wants to > > > lock (partial lock) /foo/bar and /foo/baz, it can execute the global > > > lock first to protect against the situation, when during partial > > > locking /foo/bar another session (B) would lock partially /foo/baz. It > > > means that after the following steps: > > > 1) global lock > > > 2) partial lock of /foo/bar > > > 3) partial lock of /foo/baz > > > 4) global unlock > > > session A keeps lock on /foo/bar and /foo/baz. > > > > This particular use case is actually handled in the current draft by > > doing a single operation: > > > > partial-lock(/foo/bar, /foo/baz) > > I agree, this is the atomic way to partial lock two areas at once. Three > lock operations before we can be sure the session can start working > (global lock, partial lock of /foo/bar, partial lock of /foo/baz) wouldn't > be efficient. > > Mehmet Assuming that partial locks on a few resources is an atomic operation, we don't have to worry about situation described by me. Regards Tomasz -- to unsubscribe send a message to netconf-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 Dec 17 13:34:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4KnG-0002xO-Fh for netconf-archive@lists.ietf.org; Mon, 17 Dec 2007 13:34:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4KnE-0003U8-UZ for netconf-archive@lists.ietf.org; Mon, 17 Dec 2007 13:34:22 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4Kcz-00038z-G9 for netconf-data@psg.com; Mon, 17 Dec 2007 18:23:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.74.114.6] (helo=mk-outboundfilter-2-a-1.mail.uk.tiscali.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4KcT-00035F-I9 for netconf@ops.ietf.org; Mon, 17 Dec 2007 18:23:30 +0000 X-Trace: 1399564/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMtNZkc+8aMG/2dsb2JhbACqQQ X-IronPort-AV: E=Sophos;i="4.24,177,1196640000"; d="scan'208";a="1399564" Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 17 Dec 2007 18:23:09 +0000 Received: from pc6 (1Cust115.tnt24.lnd4.gbr.da.uu.net [62.188.151.115]) by astro.systems.pipex.net (Postfix) with SMTP id 346FCE000091; Mon, 17 Dec 2007 18:23:01 +0000 (GMT) Message-ID: <02e701c840d1$5d512280$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" , "Netconf \(E-mail\)" References: <4738B469.8060208@andybierman.com> Subject: Re: quick check of notification-11 Date: Mon, 17 Dec 2007 16:17:54 +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 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -102.6 (---------------------------------------------------) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 A minor quirk - I see a missing solidus in 3.2.5.1 " " and an uncertainty - the I-D does not register the XML Schema defined in sections 4 and 3.4, just their targetNamespace; is this intentional? Also in IANA considerations, it might be clearer if the registration of the capability urn refers to the named registry created by RFC4741 s.10.3; obvious to those up to their ears in netconf, perhaps less so to those with an IANA-wide remit. Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Netconf (E-mail)" Sent: Monday, November 12, 2007 9:15 PM Subject: quick check of notification-11 > Hi, > > The new Notifications draft is out: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-11.txt > > Could the people who made comments on -10 check that their bugs/issues > were properly addressed? > > Unless there are no objections, the 1 hour NETCONF meeting in Vancouver > dedicated to Notification issues will be canceled, because we are done. (!) > > Many thanks to Sharon and Hector for all their hard work, > and to all the people who reviewed and improved it along the way. > > > thanks, > Andy > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 19 09:07:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zZk-0002jw-2G for netconf-archive@lists.ietf.org; Wed, 19 Dec 2007 09:07:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4zZj-0006HQ-EC for netconf-archive@lists.ietf.org; Wed, 19 Dec 2007 09:07:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4zQU-000Kij-Su for netconf-data@psg.com; Wed, 19 Dec 2007 13:57:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4zPx-000Kff-GY for netconf@ops.ietf.org; Wed, 19 Dec 2007 13:57:15 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 709288A32C for ; Wed, 19 Dec 2007 14:56:57 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30429-06-15; Wed, 19 Dec 2007 14:56:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48CD18A1B6; Wed, 19 Dec 2007 14:53:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 357E142D9A5; Wed, 19 Dec 2007 14:53:33 +0100 (CET) Date: Wed, 19 Dec 2007 14:53:33 +0100 From: Juergen Schoenwaelder To: netconf@ops.ietf.org Subject: netconf error handling Message-ID: <20071219135333.GB4569@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi, I recently looked into NETCONF [RFC4741] error handling and I have two questions. a) The 'error-type' distinguishes between 'transport', 'rpc', 'protocol' and 'application'. This is inconsistent with the layering model shown in section 1.1. It would make more sense to distinguish 'transport', 'rpc', 'operations' and 'application' since the term protocol is used in most parts of the document to refer to the sum of these four layers. b) I fail to understand the usefulness of the 'error-severity' which has the two values 'warning' and 'error'. Section 4.3 starts with: The element is sent in messages if an error occurs during the processing of an request. So what is the purpose of an error that is a warning? If I choose to ignore the warning, how can I do that? Digging deeper, I find: A server MUST return an element if any error conditions occur during processing and SHOULD return an element if any warning conditions occur during processing. What is the use case of a warning error? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 19 10:38:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5101-0007gt-T2 for netconf-archive@lists.ietf.org; Wed, 19 Dec 2007 10:38:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5101-00009k-Fw for netconf-archive@lists.ietf.org; Wed, 19 Dec 2007 10:38:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J50tZ-0002Jb-MM for netconf-data@psg.com; Wed, 19 Dec 2007 15:31:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.96] (helo=smtp123.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J50tS-0002IA-35 for netconf@ops.ietf.org; Wed, 19 Dec 2007 15:31:36 +0000 Received: (qmail 39453 invoked from network); 19 Dec 2007 15:31:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@68.120.85.7 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 19 Dec 2007 15:31:33 -0000 X-YMail-OSG: NhGfu0sVM1mCE2UdbRqG_EtEJqAiHTACArv6RJMEK.4WIdO1 Message-ID: <47693953.5090007@andybierman.com> Date: Wed, 19 Dec 2007 07:31:31 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: netconf error handling References: <20071219135333.GB4569@elstar.local> In-Reply-To: <20071219135333.GB4569@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Juergen Schoenwaelder wrote: > Hi, > > I recently looked into NETCONF [RFC4741] error handling and I have two > questions. > > a) The 'error-type' distinguishes between 'transport', 'rpc', > 'protocol' and 'application'. This is inconsistent with the > layering model shown in section 1.1. It would make more sense to > distinguish 'transport', 'rpc', 'operations' and 'application' > since the term protocol is used in most parts of the document to > refer to the sum of these four layers. kind of late to change it now. Protocol/protocol operation/operation are used loosely throughout all the NETCONF documents. > > b) I fail to understand the usefulness of the 'error-severity' which > has the two values 'warning' and 'error'. Section 4.3 starts with: > > The element is sent in messages if an > error occurs during the processing of an request. > > So what is the purpose of an error that is a warning? If I choose > to ignore the warning, how can I do that? Digging deeper, I find: > > A server MUST return an element if any error > conditions occur during processing and SHOULD return an > element if any warning conditions occur during > processing. > > What is the use case of a warning error? It is there for future WG use or vendor use. I don't know it this will ever get used. I have the same concerns as you -- that applications will treat 'warning-only' responses as errors instead of the intended 'ok'. (My mgr code looks for a element even if there are s, but does not treat 'missing element' as success). > > /js > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Dec 19 11:04:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51Pc-0005zG-Hq for netconf-archive@lists.ietf.org; Wed, 19 Dec 2007 11:04:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J51Pb-0000f0-V9 for netconf-archive@lists.ietf.org; Wed, 19 Dec 2007 11:04:48 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J51Fi-00047s-7G for netconf-data@psg.com; Wed, 19 Dec 2007 15:54:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J51FK-00046O-SE for netconf@ops.ietf.org; Wed, 19 Dec 2007 15:54:22 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B53558A175; Wed, 19 Dec 2007 16:54:07 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14641-02-3; Wed, 19 Dec 2007 16:54:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B1B255E42; Wed, 19 Dec 2007 16:54:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0028F42DD46; Wed, 19 Dec 2007 16:54:00 +0100 (CET) Date: Wed, 19 Dec 2007 16:54:00 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: netconf error handling Message-ID: <20071219155400.GA4830@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <20071219135333.GB4569@elstar.local> <47693953.5090007@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47693953.5090007@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 On Wed, Dec 19, 2007 at 07:31:31AM -0800, Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> Hi, >> >> I recently looked into NETCONF [RFC4741] error handling and I have two >> questions. >> >> a) The 'error-type' distinguishes between 'transport', 'rpc', >> 'protocol' and 'application'. This is inconsistent with the >> layering model shown in section 1.1. It would make more sense to >> distinguish 'transport', 'rpc', 'operations' and 'application' >> since the term protocol is used in most parts of the document to >> refer to the sum of these four layers. > > kind of late to change it now. > Protocol/protocol operation/operation are used loosely throughout > all the NETCONF documents. Even if people do now want to change the one the wire encoding, I think at least the text should be clarified in a revised version of the document so that it is clear what is meant. (I would even go as far as changing the protocol encoding with a note that older definitions may still use 'protocol'; the number of widely deployed code bases still seems to be small and a Proposed Standard is well a Proposed Standard...) >> b) I fail to understand the usefulness of the 'error-severity' which >> has the two values 'warning' and 'error'. Section 4.3 starts with: >> >> The element is sent in messages if an >> error occurs during the processing of an request. >> >> So what is the purpose of an error that is a warning? If I choose >> to ignore the warning, how can I do that? Digging deeper, I find: >> >> A server MUST return an element if any error >> conditions occur during processing and SHOULD return an >> element if any warning conditions occur during >> processing. >> >> What is the use case of a warning error? > > It is there for future WG use or vendor use. > > I don't know it this will ever get used. > I have the same concerns as you -- that applications > will treat 'warning-only' responses as errors > instead of the intended 'ok'. (My mgr code looks > for a element even if there are s, > but does not treat 'missing element' as success). To me, this error severity thing sounds like a broken feature to be removed in 4741 bis. Anyway, do we have a process in place how we deal with errors we have found or wordings that need to be improved? Would it not make sense to start a 4741bis ID so that we can keep track of things more easily? I know this has been discussed before but I lost the status / conclusion of the discussion... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Dec 20 11:19:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5O7E-0002oP-9w for netconf-archive@lists.ietf.org; Thu, 20 Dec 2007 11:19:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5O7D-0004ko-T3 for netconf-archive@lists.ietf.org; Thu, 20 Dec 2007 11:19:20 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5NuW-0003hH-BW for netconf-data@psg.com; Thu, 20 Dec 2007 16:06:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [194.9.94.113] (helo=s87.loopia.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5NuO-0003fv-RP for netconf@ops.ietf.org; Thu, 20 Dec 2007 16:06:10 +0000 Received: (qmail 9489 invoked from network); 20 Dec 2007 15:58:59 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Dec 2007 15:58:59 -0000 Received: (qmail 52458 invoked from network); 20 Dec 2007 15:59:00 -0000 Received: from mail.verismo.se (HELO [192.168.99.223]) (johan.rydberg@edgeware.tv@[213.115.45.46]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Dec 2007 15:59:00 -0000 Message-ID: <476A90E1.5050200@edgeware.tv> Date: Thu, 20 Dec 2007 16:57:21 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: netconf@ops.ietf.org CC: cridligv@loria.fr Subject: draft-cridlig-netconf-rbac-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb [subject] states that for and all subtrees without read access should be filtered out of the result. In other words, the data is in the configuration but the user can never read it out. This applies to any configuration, not just ''running''. In respect to [subject] specifies: [...] On receipt of an edit-config request, the agent applies the XPath expressions of the write "w" permissions set on the request. All children and parents of the selected nodes are marked as authorized nodes. If a "replace", "create", "delete", or "merge" operation is set in one of the parents of the selected nodes, access is denied. My understanding is that this renders the 'replace' value for the default-operation parameter useless, since the user will try to delete all config data for parts of the data model that he or she don't have access to. I can imagine that the normal workflow for an operator using a simple netconf tool is that he first fetches the whole configuration using , edits the result, and then updates the candidate with either or and finally commits it using . The problem is that he will not be able to do that if he don't have access to the whole data model. He would have to set an xc:operation='replace' on all top elements and then merge the changes into ''candidate'' with . Far from user friendly. How would you implement partial access to the data model? Esp where you can control if a user can read data or not. best regards, Johan -- to unsubscribe send a message to netconf-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 Dec 21 11:06:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kOA-0001IL-CA for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 11:06:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5kO9-0001qQ-UQ for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 11:06:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5kFn-000Pbr-Qc for netconf-data@psg.com; Fri, 21 Dec 2007 15:57:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5kFZ-000PZu-2S for netconf@ops.ietf.org; Fri, 21 Dec 2007 15:57:30 +0000 X-IronPort-AV: E=Sophos;i="4.24,194,1196658000"; d="scan'208";a="87376148" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 21 Dec 2007 10:57:20 -0500 X-IronPort-AV: E=Sophos;i="4.24,194,1196658000"; d="scan'208";a="143569328" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Dec 2007 10:57:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: design team Date: Fri, 21 Dec 2007 16:56:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: design team Thread-Index: AchD6Az1ZAH14EdKQMS/DPXYNOjETQ== From: "Romascanu, Dan (Dan)" To: Cc: "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Lisa Dusseault" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 (resending with correct netconf address) Following the discussions in Vancouver we are creating a design team to = work on Requirements for a Configuration Data Modeling Language (RCDML) = with participation from OPS and APPS.=20 The principal goal of the design team activity is to increase the = chances for a successful BOF in Philadelphia which should decide on what = needs to be done to standardize data models for configuration in the = IETF with focus on the immediate requirements for the NETCONF protocol. = We recommend that in order to expedite the process the team will look at = the existing requirements for data modeling languages coming from the = various teams working on new solutions or reusing existing data modeling = languages and tools, identify the common set of requirements and the = principal specific requirements that led to each one of the solutions. = The focus of the requirements should be on the immediate needs of the = OPS area and NETCONF protocol, and should use precedent work done in the = area as RFC 3535, but take into consideration the need for extensibility = and the opportunity of providing one data modeling language solution for = different other IETF problems in APPS and other area like application = servers, so that any solution that is engaged does not preclude the = extensibility and broader applicability.=20 Team leader is Randy Presuhn whom we thank for accepting this task and = we welcome back as an active participant in the IETF. We trust that his = experience and expertise will be of great help. Members in the team will = be Martin Bj=F6rklund, Alex Clemm, Rohan Mahy, Chris Newman, and David = Partain As time frame we suggest that the team targets February 15, 2008 as a = date for the principal deliverable which should be an Internet-Draft = with a taxonomy of RDCML to be used as entry and reference at a CDML BOF = at IETF 71 in Philadelphia.=20 We wish success to the team and Happy Holidays for all.=20 Ron and Dan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 21 13:26:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ma5-0003u6-Sp for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 13:26:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5ma5-0005os-Ej for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 13:26:45 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5mOd-000AvM-2Q for netconf-data@psg.com; Fri, 21 Dec 2007 18:14:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5mOZ-000AuK-HT for netconf@ops.ietf.org; Fri, 21 Dec 2007 18:14:53 +0000 X-IronPort-AV: E=Sophos;i="4.24,195,1196658000"; d="scan'208";a="81518371" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Dec 2007 13:14:42 -0500 X-IronPort-AV: E=Sophos;i="4.24,195,1196658000"; d="scan'208";a="143615229" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Dec 2007 13:14:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: design team Date: Fri, 21 Dec 2007 19:13:58 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: design team Thread-Index: AchD6Az1ZAH14EdKQMS/DPXYNOjETQ== From: "Romascanu, Dan (Dan)" To: Cc: "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Lisa Dusseault" , "Sharon Chisholm" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 (resending with correct netconf address and full team membership) Following the discussions in Vancouver we are creating a design team to = work on Requirements for a Configuration Data Modeling Language (RCDML) = with participation from OPS and APPS.=20 The principal goal of the design team activity is to increase the = chances for a successful BOF in Philadelphia which should decide on what = needs to be done to standardize data models for configuration in the = IETF with focus on the immediate requirements for the NETCONF protocol. = We recommend that in order to expedite the process the team will look at = the existing requirements for data modeling languages coming from the = various teams working on new solutions or reusing existing data modeling = languages and tools, identify the common set of requirements and the = principal specific requirements that led to each one of the solutions. = The focus of the requirements should be on the immediate needs of the = OPS area and NETCONF protocol, and should use precedent work done in the = area as RFC 3535, but take into consideration the need for extensibility = and the opportunity of providing one data modeling language solution for = different other IETF problems in APPS and other area like application = servers, so that any solution that is engaged does not preclude the = extensibility and broader applicability.=20 Team leader is Randy Presuhn whom we thank for accepting this task and = we welcome back as an active participant in the IETF. We trust that his = experience and expertise will be of great help. Members in the team will = be Martin Bj=F6rklund, Sharon Chisholm, Alex Clemm, Rohan Mahy, Chris = Newman, and David Partain As time frame we suggest that the team targets February 15, 2008 as a = date for the principal deliverable which should be an Internet-Draft = with a taxonomy of RDCML to be used as entry and reference at a CDML BOF = at IETF 71 in Philadelphia.=20 We wish success to the team and Happy Holidays for all.=20 Ron and Dan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 21 14:03:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nA6-00011k-IF for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 14:03:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5nA5-0006fq-Ve for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 14:03:58 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5n2f-000F2r-EY for netconf-data@psg.com; Fri, 21 Dec 2007 18:56:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.96] (helo=smtp123.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5n2V-000F1v-EQ for netconf@ops.ietf.org; Fri, 21 Dec 2007 18:56:11 +0000 Received: (qmail 74323 invoked from network); 21 Dec 2007 18:56:06 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@207.215.248.208 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 21 Dec 2007 18:56:06 -0000 X-YMail-OSG: vt7VKb4VM1lYOsKUPUcSVFS0n8zim9gWRa8w7LEYFngxN0wv Message-ID: <476C0C3E.4020305@andybierman.com> Date: Fri, 21 Dec 2007 10:55:58 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: netconf@ops.ietf.org, Randy Presuhn , mbj@tail-f.com, alex@cisco.com, Rohan Mahy , Chris Newman , David Partain , Ron Bonica , Lisa Dusseault , Sharon Chisholm Subject: Re: design team References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Romascanu, Dan (Dan) wrote: > (resending with correct netconf address and full team membership) > > Following the discussions in Vancouver we are creating a design team to work on Requirements for > a Configuration Data Modeling Language (RCDML) with participation from OPS and APPS. > > The principal goal of the design team activity is to increase the chances for a successful BOF > in Philadelphia which should decide on what needs to be done to standardize data models for > configuration in the IETF with focus on the immediate requirements for the NETCONF protocol. We > recommend that in order to expedite the process the team will look at the existing requirements > for data modeling languages coming from the various teams working on new solutions or reusing > existing data modeling languages and tools, identify the common set of requirements and the > principal specific requirements that led to each one of the solutions. The focus of the > requirements should be on the immediate needs of the OPS area and NETCONF protocol, and should > use precedent work done in the area as RFC 3535, but take into consideration the need for > extensibility and the opportunity of providing one data modeling language solution for different > other IETF problems in APPS and other area like application servers, so that any solution that > is engaged does not preclude the extensibility and broader applicability. > I would like to object to this charter text. The name of the presumed BoF (CDML) means Configuration DML, not NETCONF DML. This implies that the IESG thinks that all configuration is the same, and any sort of application with configurable parameters of any sort could use the same data modeling language, regardless of the configuration protocol being used (if any). This last phrase is rather vague and open-ended: ...opportunity of providing one data modeling language solution for different other IETF problems in APPS and other area like application servers, so that any solution that is engaged does not preclude the extensibility and broader applicability This sure looks like a "boil the ocean" kind of charter. Does this include my Apache configuration? bind config? Windows hosts? Printers? Is '/sbin/ifconfig' an application included in the charter? I was at the IAB NM workshop that led to RFC 3535. The operators made it clear at that meeting they did not mix router/switch configuration with 'desktop support', and did not ask for anything of the sort. > Team leader is Randy Presuhn whom we thank for accepting this task and we welcome back as an > active participant in the IETF. We trust that his experience and expertise will be of great > help. Members in the team will be Martin Björklund, Sharon Chisholm, Alex Clemm, Rohan Mahy, > Chris Newman, and David Partain > > As time frame we suggest that the team targets February 15, 2008 as a date for the principal > deliverable which should be an Internet-Draft with a taxonomy of RDCML to be used as entry and > reference at a CDML BOF at IETF 71 in Philadelphia. > > We wish success to the team and Happy Holidays for all. > > Ron and Dan > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 21 14:31:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nb4-0000La-NO for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 14:31:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5nb2-0007LK-Ut for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 14:31:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5nUk-000Ih4-H5 for netconf-data@psg.com; Fri, 21 Dec 2007 19:25:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.62.209.30] (helo=bender-mail.tigertech.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5nUE-000IeH-Vd for netconf@ops.ietf.org; Fri, 21 Dec 2007 19:25:03 +0000 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id AA6AF7E2E; Fri, 21 Dec 2007 11:24:46 -0800 (PST) Received: from [192.168.0.100] (pool-70-104-229-199.fred.east.verizon.net [70.104.229.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 230B57E38; Fri, 21 Dec 2007 11:24:43 -0800 (PST) Message-ID: <476C12F6.908@joelhalpern.com> Date: Fri, 21 Dec 2007 14:24:38 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andy Bierman Cc: "Romascanu, Dan (Dan)" , netconf@ops.ietf.org, Randy Presuhn , mbj@tail-f.com, alex@cisco.com, Rohan Mahy , Chris Newman , David Partain , Ron Bonica , Lisa Dusseault , Sharon Chisholm Subject: Re: design team References: <476C0C3E.4020305@andybierman.com> In-Reply-To: <476C0C3E.4020305@andybierman.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 By the way, while I don't expect NETCONF to use the forces XML modeling (the forces representation is very focussed on the internals, not the CLI view,) I would be very unhappy if someone were to claim that ForCES had to start over (we are very close to completing our two primary drafts and sending them to the IESG) because we "should" use some other model. Yours, Joel M. Halpern Andy Bierman wrote: > Romascanu, Dan (Dan) wrote: >> (resending with correct netconf address and full team membership) >> >> Following the discussions in Vancouver we are creating a design team >> to work on Requirements for >> a Configuration Data Modeling Language (RCDML) with participation from >> OPS and APPS. >> >> The principal goal of the design team activity is to increase the >> chances for a successful BOF >> in Philadelphia which should decide on what needs to be done to >> standardize data models for >> configuration in the IETF with focus on the immediate requirements for >> the NETCONF protocol. We >> recommend that in order to expedite the process the team will look at >> the existing requirements >> for data modeling languages coming from the various teams working on >> new solutions or reusing >> existing data modeling languages and tools, identify the common set of >> requirements and the >> principal specific requirements that led to each one of the solutions. >> The focus of the >> requirements should be on the immediate needs of the OPS area and >> NETCONF protocol, and should >> use precedent work done in the area as RFC 3535, but take into >> consideration the need for >> extensibility and the opportunity of providing one data modeling >> language solution for different >> other IETF problems in APPS and other area like application servers, >> so that any solution that >> is engaged does not preclude the extensibility and broader applicability. >> > > > I would like to object to this charter text. > The name of the presumed BoF (CDML) means Configuration DML, not NETCONF > DML. > This implies that the IESG thinks that all configuration is the same, > and any sort of application with configurable parameters of any sort > could use the same data modeling language, regardless of the configuration > protocol being used (if any). > > This last phrase is rather vague and open-ended: > ...opportunity of providing one data modeling language solution for > different > other IETF problems in APPS and other area like application servers, > so that > any solution that is engaged does not preclude the extensibility and > broader > applicability > > This sure looks like a "boil the ocean" kind of charter. > Does this include my Apache configuration? bind config? Windows hosts? > Printers? > Is '/sbin/ifconfig' an application included in the charter? > > I was at the IAB NM workshop that led to RFC 3535. > The operators made it clear at that meeting they did not > mix router/switch configuration with 'desktop support', > and did not ask for anything of the sort. > > >> Team leader is Randy Presuhn whom we thank for accepting this task and >> we welcome back as an >> active participant in the IETF. We trust that his experience and >> expertise will be of great >> help. Members in the team will be Martin Björklund, Sharon Chisholm, >> Alex Clemm, Rohan Mahy, >> Chris Newman, and David Partain >> >> As time frame we suggest that the team targets February 15, 2008 as a >> date for the principal >> deliverable which should be an Internet-Draft with a taxonomy of RDCML >> to be used as entry and >> reference at a CDML BOF at IETF 71 in Philadelphia. >> >> We wish success to the team and Happy Holidays for all. >> >> Ron and Dan >> > > > Andy > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Dec 21 18:13:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5r3m-0005ID-9W for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 18:13:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5r3k-0006C8-Fk for netconf-archive@lists.ietf.org; Fri, 21 Dec 2007 18:13:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5qw0-000Cv2-VR for netconf-data@psg.com; Fri, 21 Dec 2007 23:05:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5qvJ-000CpS-Vs for netconf@ops.ietf.org; Fri, 21 Dec 2007 23:05:16 +0000 X-IronPort-AV: E=Sophos;i="4.24,196,1196658000"; d="scan'208";a="81581520" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Dec 2007 18:04:54 -0500 X-IronPort-AV: E=Sophos;i="4.24,196,1196658000"; d="scan'208";a="143684387" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Dec 2007 18:04:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: design team Date: Sat, 22 Dec 2007 00:04:04 +0100 Message-ID: In-Reply-To: <476C0C3E.4020305@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: design team Thread-Index: AchEAypjyKixQhMEQyiVLrrrTPjM7wAIJC6A References: <476C0C3E.4020305@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: , "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Lisa Dusseault" , "Sharon Chisholm" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Andy, I would not spend to much time with exact wordsmithing, because this is = not really a 'charter'. A design team does not need an IESG approved = charter. This wording rather reflects the discussions that we as ADs had = in Vancouver and what I believe the participants in these discussions = agreed would be a good way to help a BOF in Philadelphia have more = chances to be successful by identifying what are the agreed requirements = and what are the requirements that are different. If you want to discuss = the words however, the last phrase that you quote and consider = 'open-ended' starts with a clear statement that 'the focus of the = requirements should be on the immediate needs of the OPS area and = NETCONF protocol'.=20 Dan =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Friday, December 21, 2007 8:56 PM > To: Romascanu, Dan (Dan) > Cc: netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com;=20 > alex@cisco.com; Rohan Mahy; Chris Newman; David Partain; Ron=20 > Bonica; Lisa Dusseault; Sharon Chisholm > Subject: Re: design team >=20 > Romascanu, Dan (Dan) wrote: > > (resending with correct netconf address and full team membership) > >=20 > > Following the discussions in Vancouver we are creating a=20 > design team=20 > > to work on Requirements for a Configuration Data Modeling=20 > Language (RCDML) with participation from OPS and APPS. > >=20 > > The principal goal of the design team activity is to increase the=20 > > chances for a successful BOF in Philadelphia which should decide on=20 > > what needs to be done to standardize data models for=20 > configuration in=20 > > the IETF with focus on the immediate requirements for the NETCONF=20 > > protocol. We recommend that in order to expedite the=20 > process the team=20 > > will look at the existing requirements for data modeling languages=20 > > coming from the various teams working on new solutions or reusing=20 > > existing data modeling languages and tools, identify the=20 > common set of=20 > > requirements and the principal specific requirements that=20 > led to each=20 > > one of the solutions. The focus of the requirements should=20 > be on the=20 > > immediate needs of the OPS area and NETCONF protocol, and=20 > should use=20 > > precedent work done in the area as RFC 3535, but take into=20 > consideration the need for extensibility and the opportunity=20 > of providing one data modeling language solution for=20 > different other IETF problems in APPS and other area like=20 > application servers, so that any solution that is engaged=20 > does not preclude the extensibility and broader applicability. > >=20 >=20 >=20 > I would like to object to this charter text. > The name of the presumed BoF (CDML) means Configuration DML,=20 > not NETCONF DML. > This implies that the IESG thinks that all configuration is=20 > the same, and any sort of application with configurable=20 > parameters of any sort could use the same data modeling=20 > language, regardless of the configuration protocol being used=20 > (if any). >=20 > This last phrase is rather vague and open-ended: > ...opportunity of providing one data modeling language=20 > solution for different > other IETF problems in APPS and other area like=20 > application servers, so that > any solution that is engaged does not preclude the=20 > extensibility and broader > applicability >=20 > This sure looks like a "boil the ocean" kind of charter. > Does this include my Apache configuration? bind config?=20 > Windows hosts? Printers? > Is '/sbin/ifconfig' an application included in the charter? >=20 > I was at the IAB NM workshop that led to RFC 3535. > The operators made it clear at that meeting they did not mix=20 > router/switch configuration with 'desktop support', and did=20 > not ask for anything of the sort. >=20 >=20 > > Team leader is Randy Presuhn whom we thank for accepting=20 > this task and=20 > > we welcome back as an active participant in the IETF. We trust that=20 > > his experience and expertise will be of great help. Members in the=20 > > team will be Martin Bj=F6rklund, Sharon Chisholm, Alex Clemm, Rohan=20 > > Mahy, Chris Newman, and David Partain > >=20 > > As time frame we suggest that the team targets February 15,=20 > 2008 as a=20 > > date for the principal deliverable which should be an=20 > Internet-Draft=20 > > with a taxonomy of RDCML to be used as entry and reference=20 > at a CDML BOF at IETF 71 in Philadelphia. > >=20 > > We wish success to the team and Happy Holidays for all. > >=20 > > Ron and Dan > >=20 >=20 >=20 > Andy >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Dec 22 04:25:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J60bS-0000AG-3w for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 04:25:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J60bR-00023g-75 for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 04:25:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J60UN-0003U4-UY for netconf-data@psg.com; Sat, 22 Dec 2007 09:17:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J60To-0003Qx-CR for netconf@ops.ietf.org; Sat, 22 Dec 2007 09:17:32 +0000 Received: (qmail 78003 invoked from network); 22 Dec 2007 09:17:07 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Dec 2007 09:17:07 -0000 From: "Bert Wijnen - IETF" To: "Romascanu, Dan \(Dan\)" , "Andy Bierman" Cc: , "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Lisa Dusseault" , "Sharon Chisholm" Subject: RE: design team Date: Sat, 22 Dec 2007 10:17:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 In Vancouver, I objected quite a bit to doing a "requirements phase". I am OK with doing a Design Team approach to that. With a clear deadline of Feb 15 that would be OK and limit the open-ended-ness. I must say that the charter text does not state it as a "clear deadline", but rather as a "target". I hope that the intention is that it is a SERIOUS DEADLINE. The text of the charter also speaks about "focus on NETCONF requirements" as per thsi text: The focus of the requirements should be on the immediate needs of the OPS area and NETCONF protocol, and should use precedent work done in the area as RFC 3535, but take into consideration the need for extensibility and the opportunity of providing one data modeling language solution for different other IETF problems in APPS and other area like application servers, so that any solution that is engaged does not preclude the extensibility and broader applicability. And as you can see, it also mentions RFC3535. But I sort have to agree with Andy that already do we see text in here that asks for "externsibility and the opportunity ...." That is where I worry. Now... given the limited time the DT has, they can't really boil the ocean. And if they do not FOCUS on NETCONF requirements, then they will miss their target of 15 feb or they will fail. I indeed hope thtat the DT will STAY FOCUSED and in addition I hope that when the DT finishes, that we do not go through endless discussions (as has been done for so many other "requirements phases" in the IETF). With that, I would Go DT Go! Show us you can do it! Bert Wijnen > -----Oorspronkelijk bericht----- > Van: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]Namens Romascanu, Dan (Dan) > Verzonden: zaterdag 22 december 2007 0:04 > Aan: Andy Bierman > CC: netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com; alex@cisco.com; > Rohan Mahy; Chris Newman; David Partain; Ron Bonica; Lisa Dusseault; > Sharon Chisholm > Onderwerp: RE: design team > > > Andy, > > I would not spend to much time with exact wordsmithing, because > this is not really a 'charter'. A design team does not need an > IESG approved charter. This wording rather reflects the > discussions that we as ADs had in Vancouver and what I believe > the participants in these discussions agreed would be a good way > to help a BOF in Philadelphia have more chances to be successful > by identifying what are the agreed requirements and what are the > requirements that are different. If you want to discuss the words > however, the last phrase that you quote and consider 'open-ended' > starts with a clear statement that 'the focus of the requirements > should be on the immediate needs of the OPS area and NETCONF protocol'. > > Dan > > > > > > > -----Original Message----- > > From: Andy Bierman [mailto:ietf@andybierman.com] > > Sent: Friday, December 21, 2007 8:56 PM > > To: Romascanu, Dan (Dan) > > Cc: netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com; > > alex@cisco.com; Rohan Mahy; Chris Newman; David Partain; Ron > > Bonica; Lisa Dusseault; Sharon Chisholm > > Subject: Re: design team > > > > Romascanu, Dan (Dan) wrote: > > > (resending with correct netconf address and full team membership) > > > > > > Following the discussions in Vancouver we are creating a > > design team > > > to work on Requirements for a Configuration Data Modeling > > Language (RCDML) with participation from OPS and APPS. > > > > > > The principal goal of the design team activity is to increase the > > > chances for a successful BOF in Philadelphia which should decide on > > > what needs to be done to standardize data models for > > configuration in > > > the IETF with focus on the immediate requirements for the NETCONF > > > protocol. We recommend that in order to expedite the > > process the team > > > will look at the existing requirements for data modeling languages > > > coming from the various teams working on new solutions or reusing > > > existing data modeling languages and tools, identify the > > common set of > > > requirements and the principal specific requirements that > > led to each > > > one of the solutions. The focus of the requirements should > > be on the > > > immediate needs of the OPS area and NETCONF protocol, and > > should use > > > precedent work done in the area as RFC 3535, but take into > > consideration the need for extensibility and the opportunity > > of providing one data modeling language solution for > > different other IETF problems in APPS and other area like > > application servers, so that any solution that is engaged > > does not preclude the extensibility and broader applicability. > > > > > > > > > I would like to object to this charter text. > > The name of the presumed BoF (CDML) means Configuration DML, > > not NETCONF DML. > > This implies that the IESG thinks that all configuration is > > the same, and any sort of application with configurable > > parameters of any sort could use the same data modeling > > language, regardless of the configuration protocol being used > > (if any). > > > > This last phrase is rather vague and open-ended: > > ...opportunity of providing one data modeling language > > solution for different > > other IETF problems in APPS and other area like > > application servers, so that > > any solution that is engaged does not preclude the > > extensibility and broader > > applicability > > > > This sure looks like a "boil the ocean" kind of charter. > > Does this include my Apache configuration? bind config? > > Windows hosts? Printers? > > Is '/sbin/ifconfig' an application included in the charter? > > > > I was at the IAB NM workshop that led to RFC 3535. > > The operators made it clear at that meeting they did not mix > > router/switch configuration with 'desktop support', and did > > not ask for anything of the sort. > > > > > > > Team leader is Randy Presuhn whom we thank for accepting > > this task and > > > we welcome back as an active participant in the IETF. We trust that > > > his experience and expertise will be of great help. Members in the > > > team will be Martin Björklund, Sharon Chisholm, Alex Clemm, Rohan > > > Mahy, Chris Newman, and David Partain > > > > > > As time frame we suggest that the team targets February 15, > > 2008 as a > > > date for the principal deliverable which should be an > > Internet-Draft > > > with a taxonomy of RDCML to be used as entry and reference > > at a CDML BOF at IETF 71 in Philadelphia. > > > > > > We wish success to the team and Happy Holidays for all. > > > > > > Ron and Dan > > > > > > > > > Andy > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Dec 22 05:44:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J61qN-0004CW-FZ for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 05:44:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J61qM-0003Oy-Fv for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 05:44:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J61eW-0008hO-8k for netconf-data@psg.com; Sat, 22 Dec 2007 10:32:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J61e0-0008ff-ES for netconf@ops.ietf.org; Sat, 22 Dec 2007 10:32:05 +0000 X-IronPort-AV: E=Sophos;i="4.24,198,1196658000"; d="scan'208";a="93296028" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 22 Dec 2007 05:31:38 -0500 X-IronPort-AV: E=Sophos;i="4.24,198,1196658000"; d="scan'208";a="136607688" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Dec 2007 05:30:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: design team Date: Sat, 22 Dec 2007 11:30:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: design team Thread-Index: AchEe3DKtQ/L/ZjnSsC0ylyyRI2NjQACVG2Q References: From: "Romascanu, Dan (Dan)" To: "Bert Wijnen - IETF" , "Andy Bierman" Cc: , "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Lisa Dusseault" , "Sharon Chisholm" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Well, again, it's not a charter, but rather a summary of what we = discussed in Vancouver with the different participants. A design team = does not need one. And it's up to the design team to focus the work. The = deadline should be seriously taken into consideration. If there is no = draft to use as a reference for requirements in Philadelphia a BOF the = chances for success are much lessened IMO. The submission deadline for = 00 drafts is February 18.=20 ... And yes, Go DT GO! ... And of course, Happy Holidays! Dan =20 =20 > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]=20 > Sent: Saturday, December 22, 2007 11:17 AM > To: Romascanu, Dan (Dan); Andy Bierman > Cc: netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com;=20 > alex@cisco.com; Rohan Mahy; Chris Newman; David Partain; Ron=20 > Bonica; Lisa Dusseault; Sharon Chisholm > Subject: RE: design team >=20 > In Vancouver, I objected quite a bit to doing a "requirements phase". > I am OK with doing a Design Team approach to that. With a=20 > clear deadline of Feb 15 that would be OK and limit the=20 > open-ended-ness. I must say that the charter text does not=20 > state it as a "clear deadline", but rather as a "target". I=20 > hope that the intention is that it is a SERIOUS DEADLINE. >=20 > The text of the charter also speaks about "focus on NETCONF=20 > requirements" > as per thsi text: >=20 > The focus of the requirements should be on the immediate needs of > the OPS area and NETCONF protocol, and should use precedent work > done in the area as RFC 3535, but take into consideration the need > for extensibility and the opportunity of providing one=20 > data modeling > language solution for different other IETF problems in APPS and > other area like application servers, so that any solution that is > engaged does not preclude the extensibility and broader=20 > applicability. >=20 > And as you can see, it also mentions RFC3535. > But I sort have to agree with Andy that already do we see=20 > text in here that asks for "externsibility and the opportunity ...." > That is where I worry. Now... given the limited time the DT=20 > has, they can't really boil the ocean. And if they do not=20 > FOCUS on NETCONF requirements, then they will miss their=20 > target of 15 feb or they will fail. I indeed hope thtat the=20 > DT will STAY FOCUSED and in addition I hope that when the DT=20 > finishes, that we do not go through endless discussions (as=20 > has been done for so many other "requirements phases" > in the IETF). >=20 > With that, I would Go DT Go! Show us you can do it! >=20 >=20 > Bert Wijnen >=20 > > -----Oorspronkelijk bericht----- > > Van: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org]Namens Romascanu, Dan (Dan) > > Verzonden: zaterdag 22 december 2007 0:04 > > Aan: Andy Bierman > > CC: netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com;=20 > > alex@cisco.com; Rohan Mahy; Chris Newman; David Partain;=20 > Ron Bonica;=20 > > Lisa Dusseault; Sharon Chisholm > > Onderwerp: RE: design team > > > > > > Andy, > > > > I would not spend to much time with exact wordsmithing,=20 > because this=20 > > is not really a 'charter'. A design team does not need an IESG=20 > > approved charter. This wording rather reflects the=20 > discussions that we=20 > > as ADs had in Vancouver and what I believe the participants=20 > in these=20 > > discussions agreed would be a good way to help a BOF in=20 > Philadelphia=20 > > have more chances to be successful by identifying what are=20 > the agreed=20 > > requirements and what are the requirements that are=20 > different. If you=20 > > want to discuss the words however, the last phrase that you=20 > quote and=20 > > consider 'open-ended' > > starts with a clear statement that 'the focus of the requirements=20 > > should be on the immediate needs of the OPS area and=20 > NETCONF protocol'. > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > From: Andy Bierman [mailto:ietf@andybierman.com] > > > Sent: Friday, December 21, 2007 8:56 PM > > > To: Romascanu, Dan (Dan) > > > Cc: netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com;=20 > > > alex@cisco.com; Rohan Mahy; Chris Newman; David Partain;=20 > Ron Bonica;=20 > > > Lisa Dusseault; Sharon Chisholm > > > Subject: Re: design team > > > > > > Romascanu, Dan (Dan) wrote: > > > > (resending with correct netconf address and full team=20 > membership) > > > > > > > > Following the discussions in Vancouver we are creating a > > > design team > > > > to work on Requirements for a Configuration Data Modeling > > > Language (RCDML) with participation from OPS and APPS. > > > > > > > > The principal goal of the design team activity is to=20 > increase the=20 > > > > chances for a successful BOF in Philadelphia which=20 > should decide=20 > > > > on what needs to be done to standardize data models for > > > configuration in > > > > the IETF with focus on the immediate requirements for=20 > the NETCONF=20 > > > > protocol. We recommend that in order to expedite the > > > process the team > > > > will look at the existing requirements for data=20 > modeling languages=20 > > > > coming from the various teams working on new solutions=20 > or reusing=20 > > > > existing data modeling languages and tools, identify the > > > common set of > > > > requirements and the principal specific requirements that > > > led to each > > > > one of the solutions. The focus of the requirements should > > > be on the > > > > immediate needs of the OPS area and NETCONF protocol, and > > > should use > > > > precedent work done in the area as RFC 3535, but take into > > > consideration the need for extensibility and the opportunity of=20 > > > providing one data modeling language solution for different other=20 > > > IETF problems in APPS and other area like application servers, so=20 > > > that any solution that is engaged does not preclude the=20 > > > extensibility and broader applicability. > > > > > > > > > > > > > I would like to object to this charter text. > > > The name of the presumed BoF (CDML) means Configuration DML, not=20 > > > NETCONF DML. > > > This implies that the IESG thinks that all configuration is the=20 > > > same, and any sort of application with configurable parameters of=20 > > > any sort could use the same data modeling language, regardless of=20 > > > the configuration protocol being used (if any). > > > > > > This last phrase is rather vague and open-ended: > > > ...opportunity of providing one data modeling=20 > language solution=20 > > > for different > > > other IETF problems in APPS and other area like application=20 > > > servers, so that > > > any solution that is engaged does not preclude the=20 > extensibility=20 > > > and broader > > > applicability > > > > > > This sure looks like a "boil the ocean" kind of charter. > > > Does this include my Apache configuration? bind config? > > > Windows hosts? Printers? > > > Is '/sbin/ifconfig' an application included in the charter? > > > > > > I was at the IAB NM workshop that led to RFC 3535. > > > The operators made it clear at that meeting they did not mix=20 > > > router/switch configuration with 'desktop support', and=20 > did not ask=20 > > > for anything of the sort. > > > > > > > > > > Team leader is Randy Presuhn whom we thank for accepting > > > this task and > > > > we welcome back as an active participant in the IETF. We trust=20 > > > > that his experience and expertise will be of great=20 > help. Members=20 > > > > in the team will be Martin Bj=F6rklund, Sharon Chisholm,=20 > Alex Clemm,=20 > > > > Rohan Mahy, Chris Newman, and David Partain > > > > > > > > As time frame we suggest that the team targets February 15, > > > 2008 as a > > > > date for the principal deliverable which should be an > > > Internet-Draft > > > > with a taxonomy of RDCML to be used as entry and reference > > > at a CDML BOF at IETF 71 in Philadelphia. > > > > > > > > We wish success to the team and Happy Holidays for all. > > > > > > > > Ron and Dan > > > > > > > > > > > > > Andy > > > > > > > -- > > to unsubscribe send a message to=20 > netconf-request@ops.ietf.org with the=20 > > 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 Sat Dec 22 06:42:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J62k3-0003ZK-8O for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 06:42:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J62k1-0004FT-0A for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 06:42:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J62dy-000Du9-CQ for netconf-data@psg.com; Sat, 22 Dec 2007 11:35:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J62dV-000DsI-W4 for netconf@ops.ietf.org; Sat, 22 Dec 2007 11:35:39 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69A6D8A14E; Sat, 22 Dec 2007 12:35:20 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11343-02; Sat, 22 Dec 2007 12:35:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C4525ADF8; Sat, 22 Dec 2007 12:35:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B359449AC2; Sat, 22 Dec 2007 12:35:10 +0100 (CET) Date: Sat, 22 Dec 2007 12:35:10 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Cc: Bert Wijnen - IETF , Andy Bierman , netconf@ops.ietf.org, Randy Presuhn , mbj@tail-f.com, alex@cisco.com, Rohan Mahy , Chris Newman , David Partain , Ron Bonica , Lisa Dusseault , Sharon Chisholm Subject: Re: design team Message-ID: <20071222113510.GA9622@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "Romascanu, Dan (Dan)" , Bert Wijnen - IETF , Andy Bierman , netconf@ops.ietf.org, Randy Presuhn , mbj@tail-f.com, alex@cisco.com, Rohan Mahy , Chris Newman , David Partain , Ron Bonica , Lisa Dusseault , Sharon Chisholm References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Sat, Dec 22, 2007 at 11:30:47AM +0100, Romascanu, Dan (Dan) wrote: > If there is no draft to use as a reference for requirements in > Philadelphia a BOF the chances for success are much lessened > IMO. The submission deadline for 00 drafts is February 18. I hope the BoF at the IETF 71 will focus on discussing solutions addressing the requirements. Your messages worry me because they can be read like there will be a requirements discussion at IETF 71, which means another 3-4 months of lost time. In other words, we not only need a deadline for the design team output, we also need a clear deadline for the solutions input so that at the IETF 71 a decision can be taken. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Dec 22 06:43:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J62ld-00060K-DK for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 06:43:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J62lc-0004Gu-0L for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 06:43:45 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J62fL-000E0I-PD for netconf-data@psg.com; Sat, 22 Dec 2007 11:37:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J62ez-000DyL-3A for netconf@ops.ietf.org; Sat, 22 Dec 2007 11:37:04 +0000 Received: (qmail 49915 invoked from network); 22 Dec 2007 11:36:49 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Dec 2007 11:36:49 -0000 From: "Bert Wijnen - IETF" To: , "Romascanu, Dan \(Dan\)" Cc: , "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Lisa Dusseault" , "Sharon Chisholm" Subject: RE: design team Date: Sat, 22 Dec 2007 12:36:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20071222113510.GA9622@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Very well stated! Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Verzonden: zaterdag 22 december 2007 12:35 > Aan: Romascanu, Dan (Dan) > CC: Bert Wijnen - IETF; Andy Bierman; netconf@ops.ietf.org; Randy > Presuhn; mbj@tail-f.com; alex@cisco.com; Rohan Mahy; Chris Newman; David > Partain; Ron Bonica; Lisa Dusseault; Sharon Chisholm > Onderwerp: Re: design team > > > On Sat, Dec 22, 2007 at 11:30:47AM +0100, Romascanu, Dan (Dan) wrote: > > > If there is no draft to use as a reference for requirements in > > Philadelphia a BOF the chances for success are much lessened > > IMO. The submission deadline for 00 drafts is February 18. > > I hope the BoF at the IETF 71 will focus on discussing solutions > addressing the requirements. Your messages worry me because they can > be read like there will be a requirements discussion at IETF 71, which > means another 3-4 months of lost time. In other words, we not only > need a deadline for the design team output, we also need a clear > deadline for the solutions input so that at the IETF 71 a decision can > be taken. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Dec 22 11:43:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67RW-0007Nr-4t for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 11:43:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J67RT-0002Ha-LV for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 11:43:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J67Iy-000FvT-U4 for netconf-data@psg.com; Sat, 22 Dec 2007 16:34:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J67Ia-000FsV-GW for netconf@ops.ietf.org; Sat, 22 Dec 2007 16:34:17 +0000 X-IronPort-AV: E=Sophos;i="4.24,199,1196658000"; d="scan'208";a="81731362" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Dec 2007 11:34:01 -0500 X-IronPort-AV: E=Sophos;i="4.24,199,1196658000"; d="scan'208";a="143942659" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Dec 2007 11:33:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: design team Date: Sat, 22 Dec 2007 17:33:08 +0100 Message-ID: In-Reply-To: <20071222113510.GA9622@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: design team Thread-Index: AchEjr4fxQZTXioGSmCx7R9BHzBx3wAKS2Aw References: <20071222113510.GA9622@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: "Bert Wijnen - IETF" , "Andy Bierman" , , "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Lisa Dusseault" , "Sharon Chisholm" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Saturday, December 22, 2007 1:35 PM > To: Romascanu, Dan (Dan) > Cc: Bert Wijnen - IETF; Andy Bierman; netconf@ops.ietf.org;=20 > Randy Presuhn; mbj@tail-f.com; alex@cisco.com; Rohan Mahy;=20 > Chris Newman; David Partain; Ron Bonica; Lisa Dusseault;=20 > Sharon Chisholm > Subject: Re: design team >=20 > On Sat, Dec 22, 2007 at 11:30:47AM +0100, Romascanu, Dan (Dan) wrote: >=20 > > If there is no draft to use as a reference for requirements in=20 > > Philadelphia a BOF the chances for success are much=20 > lessened IMO. The=20 > > submission deadline for 00 drafts is February 18. >=20 > I hope the BoF at the IETF 71 will focus on discussing=20 > solutions addressing the requirements. Your messages worry=20 > me because they can be read like there will be a requirements=20 > discussion at IETF 71, which means another 3-4 months of lost=20 > time. In other words, we not only need a deadline for the=20 > design team output, we also need a clear deadline for the=20 > solutions input so that at the IETF 71 a decision can be taken. >=20 > /js >=20 The design team role is exactly to make much of the work about requirements in advance, before Philadelphia, so that at Philadelphia we do not start from zero and argue again about requirements. So let us give it a chance.=20 Nobody prevents people who work on solutions to work in parallel to improve and bring their solutions in best shape for Philadelphia as (Internet-Draft, tools, software). Dan =20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=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 Sat Dec 22 11:50:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67Y5-0002UI-Qz for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 11:50:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J67Y5-0002W1-DV for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 11:50:05 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J67Qe-000GjX-Jz for netconf-data@psg.com; Sat, 22 Dec 2007 16:42:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J67QK-000GgZ-6z for netconf@ops.ietf.org; Sat, 22 Dec 2007 16:42:20 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E2898A143; Sat, 22 Dec 2007 17:42:03 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29023-04; Sat, 22 Dec 2007 17:41:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4C378A116; Sat, 22 Dec 2007 17:41:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8059A44A898; Sat, 22 Dec 2007 17:41:56 +0100 (CET) Date: Sat, 22 Dec 2007 17:41:56 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Cc: Bert Wijnen - IETF , Andy Bierman , netconf@ops.ietf.org, Randy Presuhn , mbj@tail-f.com, alex@cisco.com, Rohan Mahy , Chris Newman , David Partain , Ron Bonica , Lisa Dusseault , Sharon Chisholm Subject: Re: design team Message-ID: <20071222164156.GA515@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "Romascanu, Dan (Dan)" , Bert Wijnen - IETF , Andy Bierman , netconf@ops.ietf.org, Randy Presuhn , mbj@tail-f.com, alex@cisco.com, Rohan Mahy , Chris Newman , David Partain , Ron Bonica , Lisa Dusseault , Sharon Chisholm References: <20071222113510.GA9622@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Sat, Dec 22, 2007 at 05:33:08PM +0100, Romascanu, Dan (Dan) wrote: > The design team role is exactly to make much of the work about > requirements in advance, before Philadelphia, so that at Philadelphia we > do not start from zero and argue again about requirements. So let us > give it a chance. Sure. > Nobody prevents people who work on solutions to work in parallel to > improve and bring their solutions in best shape for Philadelphia as > (Internet-Draft, tools, software). All fine. But I would really dislike that in Philadelphia we say "nice, now we have some requirements, lets until the next IETF get proposals on the table and then we discuss proposals". I like the proposals be discussed in Philadelphia. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Dec 22 12:13:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67v6-0001XJ-Pm for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 12:13:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J67v6-0002sD-7p for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 12:13:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J67pq-000JCH-64 for netconf-data@psg.com; Sat, 22 Dec 2007 17:08:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.94] (helo=smtp121.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J67pm-000JBt-ME for netconf@ops.ietf.org; Sat, 22 Dec 2007 17:08:24 +0000 Received: (qmail 79234 invoked from network); 22 Dec 2007 17:08:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@207.215.248.208 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 22 Dec 2007 17:08:18 -0000 X-YMail-OSG: oNUwxk4VM1l5Ut8j_sMRM_yfj_4wYMtmamWSrNaH035WZztZ Message-ID: <476D4480.1070603@andybierman.com> Date: Sat, 22 Dec 2007 09:08:16 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: j.schoenwaelder@jacobs-university.de, Bert Wijnen - IETF , netconf@ops.ietf.org, Randy Presuhn , mbj@tail-f.com, alex@cisco.com, Rohan Mahy , Chris Newman , David Partain , Ron Bonica , Lisa Dusseault , Sharon Chisholm Subject: Re: design team References: <20071222113510.GA9622@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Romascanu, Dan (Dan) wrote: > > > > >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Saturday, December 22, 2007 1:35 PM >> To: Romascanu, Dan (Dan) >> Cc: Bert Wijnen - IETF; Andy Bierman; netconf@ops.ietf.org; >> Randy Presuhn; mbj@tail-f.com; alex@cisco.com; Rohan Mahy; >> Chris Newman; David Partain; Ron Bonica; Lisa Dusseault; >> Sharon Chisholm >> Subject: Re: design team >> >> On Sat, Dec 22, 2007 at 11:30:47AM +0100, Romascanu, Dan (Dan) wrote: >> >>> If there is no draft to use as a reference for requirements in >>> Philadelphia a BOF the chances for success are much >> lessened IMO. The >>> submission deadline for 00 drafts is February 18. >> I hope the BoF at the IETF 71 will focus on discussing >> solutions addressing the requirements. Your messages worry >> me because they can be read like there will be a requirements >> discussion at IETF 71, which means another 3-4 months of lost >> time. In other words, we not only need a deadline for the >> design team output, we also need a clear deadline for the >> solutions input so that at the IETF 71 a decision can be taken. >> >> /js >> > > The design team role is exactly to make much of the work about > requirements in advance, before Philadelphia, so that at Philadelphia we > do not start from zero and argue again about requirements. So let us > give it a chance. > But the design team has been formed by the IESG, and given a set of criteria by the IESG, for creating the measuring stick by which the candidate proposals will be judged. If there are specific applications server requirements that the Configuration Data Modeling WG needs to address, then they need to be identified and discussed. (We will let the design team have a chance to write specific requirements.) If there are no specific application server requirements, then the discussion of solution proposals cannot be very objective. How can somebody prove that a solution will or will not meet some unspecified extensibility needs in the future? I am objecting to the very notion that the NETCONF WG should compromise the DML needed ASAP for standard NETCONF data models, for some unspecified 'maybe others will find a use for this someday' kind of requirements. If specific WGs (from any area) want a DML very similar in nature to what the NETCONF WG is pursuing, and domain experts are willing to help throughout the entire process, then I totally support a combined solution, instead of N solutions. > Nobody prevents people who work on solutions to work in parallel to > improve and bring their solutions in best shape for Philadelphia as > (Internet-Draft, tools, software). > > Dan Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Dec 22 13:51:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J69RA-0007oj-6X for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 13:51:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J69R8-0005Fn-9W for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 13:51:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J69KV-0002Zs-KP for netconf-data@psg.com; Sat, 22 Dec 2007 18:44:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J69KR-0002ZW-RM for netconf@ops.ietf.org; Sat, 22 Dec 2007 18:44:09 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rCpabUHQwSElSbzrcni3T3P4c0SKzZw3eSUWoeaYDRDvTxg8ITYm2ogUMUpNGeDG; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.93] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J69KQ-0003Br-Nz for netconf@ops.ietf.org; Sat, 22 Dec 2007 13:44:07 -0500 Message-ID: <002201c844ca$ffa44f60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20071222113510.GA9622@elstar.local> <476D4480.1070603@andybierman.com> Subject: Re: design team Date: Sat, 22 Dec 2007 10:46:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31ac0653e1a3b41152805f4deeef7c0ea08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.93 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hi - > From: "Andy Bierman" ... > Sent: Saturday, December 22, 2007 9:08 AM > Subject: Re: design team ... > But the design team has been formed by the IESG, and given a set > of criteria by the IESG, for creating the measuring stick by which > the candidate proposals will be judged. That *still* gives no special status to the work. A design team is merely that, no matter how it came into being. If someone starts treating the design team's output as somehow privileged, that behaviour is not justified by IETF process. As anyone who's been around for a while surely knows, the output of a design team isn't binding on anyone. > If there are specific applications server requirements that the > Configuration Data Modeling WG needs to address, then they need > to be identified and discussed. (We will let the design team > have a chance to write specific requirements.) I certainly hope no one reads this as meaning that anyone should *wait* for the design team. Additional work identifying requirements and refining solutions should continue apace, in my opinion. The design teams' work should be helpful to the BOF, but is no replacement for other folks' homework. > If there are no specific application server requirements, then > the discussion of solution proposals cannot be very objective. > How can somebody prove that a solution will or will not meet > some unspecified extensibility needs in the future? The logical conclusion of such a line of argument is that the IETF should do nothing because we cannot prove that all our solutions will be eternally useful. However, I do agree that it would be most helpful for *everyone* who has specific requirements to state what they are. > I am objecting to the very notion that the NETCONF WG should > compromise the DML needed ASAP for standard NETCONF data models, > for some unspecified 'maybe others will find a use for this someday' > kind of requirements. No one is proposing that we do this. > If specific WGs (from any area) want a DML very similar in nature > to what the NETCONF WG is pursuing, and domain experts are willing > to help throughout the entire process, then I totally support a combined > solution, instead of N solutions. While this would be nice, there are good reasons to be skeptical about the feasability of such a thing. The design team doesn't plan to even try to do this, although the requirements from other application spaces that do configuration will be worth perusing, to identify things applicable in the netconf domain that may have gone unmentioned. > > Nobody prevents people who work on solutions to work in parallel to > > improve and bring their solutions in best shape for Philadelphia as > > (Internet-Draft, tools, software). > > > > Dan Absolutely. And I strongly encourage folks to speak up about their requirements and use cases. > Andy 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 Sat Dec 22 16:03:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6BVe-0007PV-Pi for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 16:03:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6BVe-0008De-Av for netconf-archive@lists.ietf.org; Sat, 22 Dec 2007 16:03:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6BNX-000DC6-P6 for netconf-data@psg.com; Sat, 22 Dec 2007 20:55:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6BNU-000DBZ-4I for netconf@ops.ietf.org; Sat, 22 Dec 2007 20:55:25 +0000 X-IronPort-AV: E=Sophos;i="4.24,199,1196658000"; d="scan'208,217";a="87673071" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Dec 2007 15:55:19 -0500 X-IronPort-AV: E=Sophos;i="4.24,199,1196658000"; d="scan'208,217";a="143979018" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Dec 2007 15:55:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C844DC.F47BEBBF" Subject: RE: design team Date: Sat, 22 Dec 2007 21:55:11 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: design team Thread-Index: AchEyJmUAEhGwjgiTIqx3SxU32KRzAAFFKAQ References: <20071222113510.GA9622@elstar.local> <476D4480.1070603@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Lisa Dusseault" , "Andy Bierman" Cc: , "Bert Wijnen - IETF" , , "Randy Presuhn" , , , "Rohan Mahy" , "Chris Newman" , "David Partain" , "Ron Bonica" , "Sharon Chisholm" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multi-part message in MIME format. ------_=_NextPart_001_01C844DC.F47BEBBF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Exactly.=20 =20 Dan =20 =20 =20 =20 ________________________________ From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 Sent: Saturday, December 22, 2007 8:29 PM To: Andy Bierman Cc: Romascanu, Dan (Dan); j.schoenwaelder@jacobs-university.de; Bert Wijnen - IETF; netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com; alex@cisco.com; Rohan Mahy; Chris Newman; David Partain; Ron Bonica; Sharon Chisholm Subject: Re: design team =09 =09 On Dec 22, 2007, at 9:08 AM, Andy Bierman wrote: But the design team has been formed by the IESG, and given a set of criteria by the IESG, for creating the measuring stick by which the candidate proposals will be judged. No, the design team was formed by Dan and Ron, or rather with the help of Dan and Ron. I agree there needs to be space for other designs, other measuring sticks. Lisa ------_=_NextPart_001_01C844DC.F47BEBBF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Exactly.
 
Dan
 
 
 
 

From: Lisa Dusseault=20 [mailto:lisa@osafoundation.org]
Sent: Saturday, December = 22, 2007=20 8:29 PM
To: Andy Bierman
Cc: Romascanu, Dan (Dan); = j.schoenwaelder@jacobs-university.de; Bert Wijnen - IETF;=20 netconf@ops.ietf.org; Randy Presuhn; mbj@tail-f.com; alex@cisco.com; = Rohan=20 Mahy; Chris Newman; David Partain; Ron Bonica; Sharon=20 Chisholm
Subject: Re: design team


On Dec 22, 2007, at 9:08 AM, Andy Bierman wrote:

But the design team has been formed by the IESG, and given = a=20 set

of criteria by the IESG, for creating the measuring stick = by=20 which

the candidate proposals will be=20 judged.


No, the design team was formed by Dan and Ron, or rather with the = help of=20 Dan and Ron.  I agree there needs to be space for other designs, = other=20 measuring sticks.

Lisa
------_=_NextPart_001_01C844DC.F47BEBBF-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From netconf@pella.com Sun Dec 23 15:42:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Xef-0000DY-0o for netconf-archive@lists.ietf.org; Sun, 23 Dec 2007 15:42:37 -0500 Received: from dial-426.vl-cen-as1.avtlg.ru ([83.239.133.171] helo=vl-cen-ce1.avtlg.ru) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6Xeb-0003iV-Vr for netconf-archive@lists.ietf.org; Sun, 23 Dec 2007 15:42:36 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 7154 by uid 512); Sat, 22 Dec 2007 11:42:39 +0300 Message-Id: <20071222144239.7156.qmail@vl-cen-ce1.avtlg.ru> To: Subject: RE: December 70% OFF From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Men's Health Daily Dose
12/12/07
MAKE YOUR OWN TESTOSTERONE
Get big results the right way, with no risk

Steriods

For P.E.D. users, it's D-Day: After 20 months, Major League Baseball is releasing the Mitchell Report, its drug abuse rundown that will reportedly finger-point as many as 70 players as steroid, HGH, and amphetamine users.

These guys have put their reps on the line not just to get bigger and faster, but because they've heard it can help their hand-eye coordination. MensHealth.com has tapped three experts to separate fact from phooey: Read our rundown with them here.

The players implicated risked more than their livelihoods. They're also increasing their risk of heart disease, elevating their blood pressure, and, in the case of HGH, potentially throwing themselves in cancer's path. Not to mention back acne and shrunken testicles.

The ladies aren't going to love those last two, so get juiced the natural way: Read these rules for exercise selection to maximize your energy use with exercises that will pump you up most. Then try this workout guaranteed to make your biggest muscle groups grow.

Once you've worked yourself into a healthy frenzy, try these power foods of real pros — 11 muscle secrets from the NFL that will fill you with muscle-building protein and energy for your own two-a-days.

With help from Men's Health, you can be large and lean — legally. Your unshrunken boys will thank you.
11 QUESTIONS ABOUT PERFORMANCE-ENHANCING DRUGS
The Mitchell Report fingers more ballplayers as cheats — but we have more questions
'ROID RAGE
Men's Health answers your questions about steriod abuse
THE SKINNY ON GETTING BIG
Don't even think about using 'roids. We'll help you bulk up naturally
BIG MUSCLES, MADE BIGGER
Your 4 largest muscle groups deserve special attention
THE NFL'S SECRET MUSCLE FOODS
Eat and drink these 11 foods and beverages and, you too, will learn to treat your body like your business
MEN'S HEALTH NEWS & ADVICE:
Get the world's greatest fitness, diet, and sex advice delivered to your inbox 3 times a week.

ABS DIET NEWSLETTER:
The latest scientific research, newest abs exercises, meal plans, success stories and cutting-edge advice for getting a 6-pack and keeping it!

BEST LIFE NEWSLETTER:
Powerful advice from the top doctors, trainers, brokers, career coaches, relationships experts, and entrepreneurs. It's free, it's smart, it's useful.
Tell a friend
Find out more at MensHealth.com

Men's Health Personal Trainer - get in shape now!
Fitness Sex & Relationships Health Guy Wisdom Weight Loss Nutrition Style Video

PRIVACY POLICY  |  CONTACT US  |  UNSUBSCRIBE
COPYRIGHT RODALE, INC. 2007
33 East Minor Street, Emmaus, PA 18098, Attn: Customer Service
Check out the
Men's Health Minute
Tech Guide 2008
MH Today: The Latest Health News
The Fitness Insider
The MH Life
Man and Machine
Click Here!
From owner-netconf@ops.ietf.org Thu Dec 27 19:22:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J82zK-00061r-E2 for netconf-archive@lists.ietf.org; Thu, 27 Dec 2007 19:22:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J82zH-0004SC-Vc for netconf-archive@lists.ietf.org; Thu, 27 Dec 2007 19:22:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J82ps-000JAp-3k for netconf-data@psg.com; Fri, 28 Dec 2007 00:12:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J82pS-000J8E-Hg for netconf@ops.ietf.org; Fri, 28 Dec 2007 00:12:13 +0000 X-IronPort-AV: E=Sophos;i="4.24,213,1196636400"; d="scan'208,217";a="1808641" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Dec 2007 01:11:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBS0BvDi002542; Fri, 28 Dec 2007 01:11:57 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBS0BugE005797; Fri, 28 Dec 2007 00:11:56 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 01:11:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C848E6.41AF1484" Subject: RE: draft-cridlig-netconf-rbac-00.txt Date: Fri, 28 Dec 2007 01:08:03 +0100 Message-ID: <991411C8E365AB4199C60DA70B3B063D070CD1@xmb-ams-33d.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-cridlig-netconf-rbac-00.txt Thread-Index: AchDIoGCSWSYcnw9RuW/f9YWzVDtYAFwzWaE References: <476A90E1.5050200@edgeware.tv> From: "Vincent Cridlig (vcridlig)" To: "Johan Rydberg" , Cc: X-OriginalArrivalTime: 28 Dec 2007 00:11:56.0775 (UTC) FILETIME=[420AEF70:01C848E6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7966; t=1198800717; x=1199664717; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vcridlig@cisco.com; z=From:=20=22Vincent=20Cridlig=20(vcridlig)=22=20 |Subject:=20RE=3A=20draft-cridlig-netconf-rbac-00.txt |Sender:=20; bh=agNlNFihYo7XL8uJZZ8CW8lWHbAwIVAZgfOEVGf9AJ8=; b=CFfCmnaBx3cRsr/bnwrqALLnljzVg0pAfr+AAfa76nSKb5lt9DvvgSqGbq g0Yl9aMZSK4PHmG8yk/PyU/2KfctqY0LSrQb7rXuavJORRrklbQ8txwfnkum 3tx6Drr/iO; Authentication-Results: ams-dkim-1; header.From=vcridlig@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 This is a multi-part message in MIME format. ------_=_NextPart_001_01C848E6.41AF1484 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In my understanding, the normal workflow is that: 1. The client first fetches the whole config (even though a smaller = scope for get is probably much better). By the way, this get will show = only what the user is allowed to. Typically, you won't give write access = on something that the user has no read access!! 2. The user edit the config 3. The client is clever enough to send a more specific request to update = what needs to be (rather than sending back the whole config like in a = copy-config). To control what a user can read or not, you have to use XPath = expressions and the "r" attribute (at least or "rw"). To implement the partial access to the data model, you can just apply = the "r" XPath expressions to the result of a get-config request before = sending it back to the manager. The selected nodes are the allowed = nodes. Then you can propagate the allowed nodes to their children and = their parents. You get a new set of nodes. The nodes that are not in = this set are discarded, because access is denied by default. This is implemented in the open-source Netconf agent (yencap) that I did = 18 months ago (http://ensuite.sourceforge.net/). Not sure if this answers your questions. Vincent -----Original Message----- From: owner-netconf@ops.ietf.org on behalf of Johan Rydberg Sent: Thu 12/20/2007 7:57 AM To: netconf@ops.ietf.org Cc: cridligv@loria.fr Subject: draft-cridlig-netconf-rbac-00.txt =20 [subject] states that for and all subtrees without read access should be filtered out of the result. In other words, the data is in the configuration but the user can never read it out. This applies to any configuration, not just ''running''. In respect to [subject] specifies: [...] On receipt of an edit-config request, the agent applies the XPath expressions of the write "w" permissions set on the request. All children and parents of the selected nodes are marked as authorized nodes. If a "replace", "create", "delete", or "merge" operation is set in one of the parents of the selected nodes, access is denied. My understanding is that this renders the 'replace' value for the default-operation parameter useless, since the user will try to delete all config data for parts of the data model that he or she don't have access to. I can imagine that the normal workflow for an operator using a simple netconf tool is that he first fetches the whole configuration using , edits the result, and then updates the candidate with either or and finally commits it using . The problem is that he will not be able to do that if he don't have access to the whole data model. He would have to set an xc:operation=3D'replace' on all top elements and then merge the changes into ''candidate'' with . Far from user friendly. How would you implement partial access to the data model? Esp where you can control if a user can read data or not. best regards, Johan -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C848E6.41AF1484 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-cridlig-netconf-rbac-00.txt

In my understanding, the normal workflow is that:
1. The client first fetches the whole config (even though a smaller = scope for get is probably much better). By the way, this get will show = only what the user is allowed to. Typically, you won't give write access = on something that the user has no read access!!
2. The user edit the config
3. The client is clever enough to send a more specific request to update = what needs to be (rather than sending back the whole config like in a = copy-config).

To control what a user can read or not, you have to use XPath = expressions and the "r" attribute (at least or = "rw").
To implement the partial access to the data model, you can just apply = the "r" XPath expressions to the result of a get-config = request before sending it back to the manager. The selected nodes are = the allowed nodes. Then you can propagate the allowed nodes to their = children and their parents. You get a new set of nodes. The nodes that = are not in this set are discarded, because access is denied by = default.
This is implemented in the open-source Netconf agent (yencap) that I did = 18 months ago (http://ensuite.sourceforge.net/<= /A>).

Not sure if this answers your questions.

Vincent


-----Original Message-----
From: owner-netconf@ops.ietf.org on behalf of Johan Rydberg
Sent: Thu 12/20/2007 7:57 AM
To: netconf@ops.ietf.org
Cc: cridligv@loria.fr
Subject: draft-cridlig-netconf-rbac-00.txt

[subject] states that for <get/> and <get-config/> all = subtrees
without read access should be filtered out of the result.

In other words, the data is in the configuration but the user can
never read it out.  This applies to any configuration, not just
''running''.

In respect to <edit-config/> [subject] specifies:

    [...] On receipt of an edit-config request, the agent = applies
    the XPath expressions of the write "w" = permissions set on the
    request.  All children and parents of the = selected nodes are
    marked as authorized nodes.  If a = "replace", "create", "delete",
    or "merge" operation is set in one of the = parents of the
    selected nodes, access is denied.

My understanding is that this renders the 'replace' value for
the default-operation parameter useless, since the user will try
to delete all config data for parts of the data model that he or
she don't have access to.

I can imagine that the normal workflow for an operator using a = simple
netconf tool is that he first fetches the whole configuration using
<get/>, edits the result, and then updates the candidate with = either
<edit-config(default-operation=3Dreplace) /> or = <copy-config/> and
finally commits it using <commit/>.  The problem is that he = will not
be able to do that if he don't have access to the whole data model.
He would have to set an xc:operation=3D'replace' on all top elements
and then merge the changes into ''candidate'' with = <edit-config/>.
Far from user friendly.

How would you implement partial access to the data model?  Esp = where
you can control if a user can read data or not.

best regards,
Johan

--
to 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/net= conf/>

------_=_NextPart_001_01C848E6.41AF1484-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Dec 30 09:28:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8z93-0001LQ-3w for netconf-archive@lists.ietf.org; Sun, 30 Dec 2007 09:28:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8z91-0003Fx-JL for netconf-archive@lists.ietf.org; Sun, 30 Dec 2007 09:28:05 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8yzv-0008yB-JC for netconf-data@psg.com; Sun, 30 Dec 2007 14:18:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8yzP-0008wQ-NH for netconf@ops.ietf.org; Sun, 30 Dec 2007 14:18:24 +0000 Received: from diotima (localhost [IPv6:::1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id lBUEI1wF012560; Sun, 30 Dec 2007 15:18:01 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18295.43161.567159.879612@switch.ch> Date: Sun, 30 Dec 2007 15:18:01 +0100 To: netconf@ops.ietf.org Subject: FYI: Slides from Tim Bray's XML tutorial X-Mailer: VM 8.1.0-devo-484 under Emacs 22.1.1 (sparc-sun-solaris2.11) X-Face:1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 For those who are interested, the slides from Tim Bray's Sunday tutorial at IETF 70, "Using XML in Internet Protocols", have been posted on the proceedings site: http://www3.ietf.org/proceedings/07dec/slides/xmltut-0.pdf -- Simon. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Dec 31 17:42:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9TKp-0001UJ-Hw for netconf-archive@lists.ietf.org; Mon, 31 Dec 2007 17:42:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9TKo-00007p-8h for netconf-archive@lists.ietf.org; Mon, 31 Dec 2007 17:42:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9TBL-0009wf-Nq for netconf-data@psg.com; Mon, 31 Dec 2007 22:32:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9TAn-0009uR-21 for netconf@ops.ietf.org; Mon, 31 Dec 2007 22:32:10 +0000 Received: from diotima (localhost [IPv6:::1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id lBVMVn3P027736; Mon, 31 Dec 2007 23:31:49 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18297.28117.324037.143910@switch.ch> Date: Mon, 31 Dec 2007 23:31:49 +0100 To: netconf@ops.ietf.org Subject: DRAFT minutes from NETCONF meeting at IETF 70 X-Mailer: VM 8.1.0-devo-484 under Emacs 22.1.1 (sparc-sun-solaris2.11) X-Face:1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.8 (--) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Draft minutes have been posted to the IETF proceedings site on http://www3.ietf.org/proceedings/07dec/minutes/netconf.html Please check them and send me your corrections. I'll try to make sure that those are applied quickly. Thanks in advance! Plain-text version of the draft minutes follows. -- Simon. NETCONF Working Group meeting IETF 70, Vancouver, B.C., Canada Wednesday, 5 December 2007 Minutes by Simon Leinen based on notes from David Partain. Administrativia ([1]slides) NETCONF is 4.5 years old! Dan Romascanu: Applause for outgoing chairs! The process is ongoing for selecting new chairs. Notifications Document (draft-ietf-netconf-notifications) The notification document passed WG last call, and is pending proto writeup, to then be handed to the IESG. Dan Romascanu mentions that the writeup can be done by one of the new chairs or someone else. Bert Wijnen: Shouldn't the proto write-up be written by one of the outgoing chairs? Simon: That might be an option. Use of Mailing Lists Mailing lists: Many mailing lists are used for NETCONF-related discussions right now, including the APPS area mailing list. One proposal: move all netconf-related discussions into the main netconf list. Sharon Chisholm: keep netconf for chartered items, and keep NGO for non-chartered discussion. Axe all the others. After discussion, the new proposal is to keep all lists except for the netmod list at Nortel (netconfmodel@lists.nortel.com). Proposed usage guidelines: netconf@ops.ietf.org For discussions related to work on whatever is the current NETCONF charter. ngo@ietf.org For discussions about unchartered NETCONF-related work, including data-model proposals in general. yang@ietf.org For discussion about the YANG data-modeling language proposal. netconfmodel@lists.nortel.com Can be abandoned. New Security Advisor Charlie Kaufman agreed to serve as the new security advisor for the working group. New charter items The new charter was accepted by the IESG in November. One goal of this meeting is to determine whether input documents are in a good enough state for their change control to be moved to the working group. __________________________________________________________________ Mohamad Badra on NETCONF over TLS ([2]slides) Balazs Lengyel: The authentication part is welcome, but access control is outside our current charter. Dan Romascanu: This is the document that drew the most attention from the IESG when the charter came up. There was an early review in the IESG to make sure that there weren't any red flags. Show of hands 8-10 people present have read this document, almost the same number thinks this should be adopted as a WG item, with no-one objecting. Will confirm this decision on the mailing list. Not terribly wide review. __________________________________________________________________ Balazs Lengyel on partial locking ([3]slides) Balazs Lengyel spent more time explaining the YANG module that he has written for maintaining configuration of the locks on a system. Full XPath support vs. (Instance Identifier) XPath subset Sharon Chisholm: have sent a bunch of comments to the list. One of them is around XPath: "if you don't support XPath, then you can support this smaller subset". Should we just mandate XPath if you support this capability (fine-grained locking)? Andy Bierman: absolutely doesn't want to use full XPath. The XPath expression can be dynamic. Balazs: the XPath is only evaluated once. Andy: that's a security hole -- if you don't apply it when it's evaluated. Andy wants the Use of YANG to describe locking data model Dan Romascanu: about the use of YANG: Not sure whether it will be in the final draft, but as long as it's not a standard, we cannot use it normatively - although perhaps in an annex. For normatively describing the data model, we'd need to use something else. Balazs agrees that we'll have to deal with this problem. Lock semantics, interactions, and security Phil Shafer: Please talk about the interactions between partial locks, get-config, and commit. Phil thinks there are interactions that Balazs doesn't. If two users have locked two different parts of the database with dependencies between the two, and I change mine based on your values which then are not committed, what happens? Balazs: there are issues; we need to describe this carefully. Wes Hardaker: if you do a partial lock on part of the config but then try to edit outside that part that you've locked, do you get feedback on that? Balazs: no, not at this point. Wes: only an interesting management error to consider. Wes Hardaker reiterates that he's worried about evaluation of XPath expressions taking place at a time other than when it's being applied. Andy: what if one of the things you are changing is in the lock expression? Balazs: having a very dynamic lock has its own set of problems. Phil Shafer: Lifespan of the lock, in terms of how long they're supposed to last. The global lock was intended to cover the duration of your edit, whereas you are talking about longer times. Balazs: it would be possible to add a timeout to the partial lock. Phil: are you intending these to be short-term or long-term locks? Balazs: I can't control it, but my intention is that they be short-term. Balazs will add a comment to the draft. Wes Hardaker: one question about the partial lock of a tree. If I lock the user table, can someone else add a user? Balazs: no. Mark Scott: why can a lock only be unlocked in the same session? Balazs: even today, if you have locked (the global lock) in one session, you can't unlock it in a different user session and we're continuing that. David Harrington: What session does SNMP lock? Balazs: one idea is that all non-NETCONF protocols might have a reserved session id range. Sharon: the monitoring draft is a good place to report these sessions. Phil Shafer: you mentioned being able to do locks on startup configuration, but that config is not writable. Balazs: you're probably right. Show of hands 11-12 people present have read this document. Nearly all of those favor WG adoption, with one person against it. __________________________________________________________________ Mark Scott on monitoring NETCONF ([4]slides) Balazs Lengyel: the GUI / CLI / locks inside are very much needed. Consider locks that are "internal" like a backup process. Why aren't any counters included? Mark: simply because it's a different area, and it would be hard to get it standardized in the short term. We don't think that the operational data is not relevant to making the configuration process more bug-free. There is a minimal set still included. Show of hands About 8 people present have read this, about 6 in favor of adoption, no objections. __________________________________________________________________ Hideki Okita: schema advertisement with WSDL and XSD ([5]slides) Rohan Mahy: Are you assuming that schemas be transient? Hideki Okita: mostly interested in knowing where the information is and how to get to it. Rohan: if I go to my device and ask it about its schemas, and there are YANG modules, XSD, and there's a RelaxNG schema. Will the query tell me about all three or only one of them? Simon: are you saying it would be useful to be able to get the schemas in different forms? Rohan: yes, it'd be useful. David Perkins: the user wants to know what the device does, not what the standards document says it's supposed to do. If the device doesn't fully comply, you want to know that. Dan Romascanu reminds presenters to avoid putting company names on slides. Show of hands About 11 people present have read this document. Polling on WG adoption is deferred to after the next draft's discussion. __________________________________________________________________ Mark Scott on schema query ([6]slides) Scope perhaps a bit narrower than the previous proposal. Balazs: are you opposed to merging the two drafts? Mark: not opposed. Hideki Okita: what is the use case for the work? Specific operations () vs. Phil Shafer: have we abandoned dedicated RPCs and gone to the all-powerful get? Balazs: I have some rules in my mind when to use them. Can the normal RPCs accomplish them, then why not use it? Mark: I had the same question. Maybe we should write down when it should be new ones and when not. David Harrington: I thought NETCONF was going to be "task-based" and I think it would make it unfortunate if this became Andy: when you are actually adding a new verb, then do so. If you're just changing what you're getting, then don't add a new verb. Sharon: CLIs have a single verb for a show but not for changes. I agree that there are cases where we should create new verbs. Don't see that this is a case where a new verb is needed. Finer-grained semantics David Perkins: How do you specify that a device has implemented a subset of a schema? Mark: you'd have to put your own sub-set schema somewhere and publish that subset somewhere. Sharon: not sure that we need this for our requirements unless they're non-conformant. The manager should be able to handle that non-mandatory objects aren't there. For the most part, the high-level information (name, version number) is sufficient. We're getting 90% of the value without getting into the specifics. Wes: David Perkins is absolutely right. NM applications can't figure out how things are broken. David Harrington: concerned that this sounds like AGENT-CAPABILITIES, which failed. Dan Romascanu: This looks more like the RMON capabilities stuff. Show of hands 10-11 people present have read Mark's document. In order to gauge the relative preference, Simon asked for a show of hands in favor of WG adoption for each of the drafts. Because the sample size is small, the results cannot be used to make a decision. Five people think Hideki's draft should be adopted, 6-7 people think Mark's draft should be adopted. Dan Romascanu: A suggestion as a contributor: Since there doesn't seem to be a clear-cut answer, maybe the two groups should try to work together. Andy Bierman: concerned that a NETCONF agent would have to use HTTP. A lot of overhead for not much information instead of using NETCONF to get it. David Harrington: concerned about introducing dependencies on other protocols. Hideki Okita: we have HTTP already, so it's not a concern to us, but I understand your concern. Simon: it's clear why your approach is attractive given that you've used SOAP. Phil Shafer: operators often do not enable HTTP on their devices. __________________________________________________________________ Other business Sharon: there's some work that's not in the charter because we didn't know if this would be a new WG or if it'd be in a 1. Clarifications of implementation issues in a bis of the NETCONF RFC 2. Update on transport documents __________________________________________________________________ Tomoyuki Iijima on experience of implementing a SOAP-based NETCONF client-server ([7]slides) Please contact him if you'd like to see a demonstration. References 1. http://www3.ietf.org/proceedings/07dec/slides/netconf-0/sld1.htm 2. http://www3.ietf.org/proceedings/07dec/slides/netconf-3/sld1.htm 3. http://www3.ietf.org/proceedings/07dec/slides/netconf-1/sld1.htm 4. http://www3.ietf.org/proceedings/07dec/slides/netconf-6/sld1.htm 5. http://www3.ietf.org/proceedings/07dec/slides/netconf-4/sld1.htm 6. http://www3.ietf.org/proceedings/07dec/slides/netconf-5/sld1.htm 7. http://www3.ietf.org/proceedings/07dec/slides/netconf-2/sld1.htm -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: