From owner-netconf@ops.ietf.org Tue Jan 02 13:14:33 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1o9h-0000SQ-HW for netconf-archive@lists.ietf.org; Tue, 02 Jan 2007 13:14:33 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H1o9f-0005Mr-3l for netconf-archive@lists.ietf.org; Tue, 02 Jan 2007 13:14:33 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H1o3f-0001wN-70 for netconf-data@psg.com; Tue, 02 Jan 2007 18:08:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H1o3P-0001um-Tb for netconf@ops.ietf.org; Tue, 02 Jan 2007 18:08:09 +0000 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l02I833B007163 for ; Tue, 2 Jan 2007 13:08:03 -0500 Received: (qmail 4973 invoked by uid 78); 2 Jan 2007 18:08:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 2 Jan 2007 18:08:02 -0000 Message-ID: <459A9F79.30905@andybierman.com> Date: Tue, 02 Jan 2007 10:07:53 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: comments on notification-05 References: <20061228.094637.74216736.mbj@tail-f.com> <20061228.222515.56091458.mbj@tail-f.com> In-Reply-To: <20061228.222515.56091458.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Martin Bjorklund wrote: > I forgot one comment. > > The schema for Named Profiles has been removed. It seems a bit odd > that this mechanism is defined as configuration data, but no schema > (data model) exists for manipulating these Named Profiles. > It is more than odd - it is broken. The WG already decided (2 IETFs ago) that the named profile must not be a pointer to unspecified contents. The protocol already has mechanisms for extending the standard definitions with proprietary constructs. There are essentially 2 solution paths here: 1) remove named profiles completely. The RPC method parameters are always passed at invocation time, without storing some of them 'offline' in a named-profile. 2) define a proper standard data-model for the named profile contents, which is accessible to the standard operations (e.g., edit-config, get-config), and rooted at a specific point in the Netconf Standard Data Tree (that doesn't exist yet). I thought we agreed on (2) awhile ago. Perhaps this was just over-active cut-and-paste editing. > > /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 Jan 05 04:46:36 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2lem-0005DK-Fj for netconf-archive@lists.ietf.org; Fri, 05 Jan 2007 04:46:36 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2lek-0000Kn-OW for netconf-archive@lists.ietf.org; Fri, 05 Jan 2007 04:46:36 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H2lWN-0008vR-0A for netconf-data@psg.com; Fri, 05 Jan 2007 09:37:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE autolearn=ham version=3.1.7 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H2lOL-0008Tb-Qc for netconf@ops.ietf.org; Fri, 05 Jan 2007 09:37:54 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBE00MW61LHR6@szxga02-in.huawei.com> for netconf@ops.ietf.org; Fri, 05 Jan 2007 17:12:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBE002UX1LFFX@szxga02-in.huawei.com> for netconf@ops.ietf.org; Fri, 05 Jan 2007 17:12:52 +0800 (CST) Received: from l48181 ([10.111.12.59]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBE00E6N1LBQ5@szxml04-in.huawei.com> for netconf@ops.ietf.org; Fri, 05 Jan 2007 17:12:51 +0800 (CST) Date: Fri, 05 Jan 2007 17:12:47 +0800 From: Li Yan Subject: a comment on schema in notification-05 To: netconf@ops.ietf.org Message-id: <001f01c730a9$aae5ed70$3b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_La8AB/u2KLlH94+2t9X3Nw)" Thread-index: Accwqap6HdovfLHBTIKTJmvRP9u45A== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.9 (+) X-Scan-Signature: 8427182ba6fa72a12b6a04e63d6f913d This is a multi-part message in MIME format. --Boundary_(ID_La8AB/u2KLlH94+2t9X3Nw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT o 3.2.5.2 o 4 Should the two schemaLocation be the same? --Boundary_(ID_La8AB/u2KLlH94+2t9X3Nw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

o 3.2.5.2

   <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"

              schemaLocation="./draft-ietf-netconf-prot-12.xsd"/>

o 4

   <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"

              schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0" />

Should the two schemaLocation be the same?

--Boundary_(ID_La8AB/u2KLlH94+2t9X3Nw)-- -- to unsubscribe send a message to netconf-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 Jan 05 12:27:13 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sqX-0002qc-1K for netconf-archive@lists.ietf.org; Fri, 05 Jan 2007 12:27:13 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2sqV-0004Qe-Hz for netconf-archive@lists.ietf.org; Fri, 05 Jan 2007 12:27:12 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H2sdN-000AwJ-7M for netconf-data@psg.com; Fri, 05 Jan 2007 17:13:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H2sdK-000Aw1-MY for netconf@ops.ietf.org; Fri, 05 Jan 2007 17:13:36 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l05HDX8C017439 for ; Fri, 5 Jan 2007 12:13:34 -0500 Received: (qmail 20842 invoked by uid 78); 5 Jan 2007 17:13:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 5 Jan 2007 17:13:21 -0000 Message-ID: <459E872A.5020607@andybierman.com> Date: Fri, 05 Jan 2007 09:13:14 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: 2 Notification draft comments Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi, (1) Sec 3.2.5.2 of notification-05 contains a stream retrieval schema with an appinfo element that is relying on the non-existent 'netmod template' standard. NetconfNotificationSchema 2006-09-06T09:30:47-05:00 IETF A schema that can be used to learn about current event streams. All of this 'extra' info should be put in a element or removed, like the XSD in section 4. (2) I think the filter examples in sec. 5 need some sort of explanation of the assumed data model (i.e., the one with 'eventClasses' and 'card' as top-level siblings). thanks, Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 08 08:33:49 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3udI-0002R2-Lj for netconf-archive@lists.ietf.org; Mon, 08 Jan 2007 08:33:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3udH-0003Je-Aq for netconf-archive@lists.ietf.org; Mon, 08 Jan 2007 08:33:48 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H3uVe-0001gy-Hn for netconf-data@psg.com; Mon, 08 Jan 2007 13:25:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,PLING_PLING autolearn=no version=3.1.7 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H3uVb-0001ge-9X for netconf@ops.ietf.org; Mon, 08 Jan 2007 13:25:53 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l08DPm5v019213 for ; Mon, 8 Jan 2007 08:25:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Please review new Notifications draft!!! Date: Mon, 8 Jan 2007 15:25:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please review new Notifications draft!!! Thread-Index: AccpI2LKTNVVASTlQMmilNozdDVdDAKBMeDA From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Netconf \(E-mail\)" X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I believe that the document can be sent to the WGLC. There have been comments from Andy and Martin, can we consider them as initial WGLC comments?=20 Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, December 26, 2006 9:17 PM > To: Netconf (E-mail) > Subject: Please review new Notifications draft!!! >=20 > Hi, >=20 > The new notifications draft has been out for about a week and=20 > so far, no comments. Not surprising, given the holidays, and=20 > lots of people on vacation. >=20 > In case you missed the I-D announcement: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notific > ation-05.txt >=20 > Please try to read it in the next 2 weeks, and send comments=20 > to the WG mailing list. We need to know if you think this=20 > document is done and ready for WG Last Call. >=20 > thanks, > Andy >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 09 09:51:07 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IJf-0002Dv-GX for netconf-archive@lists.ietf.org; Tue, 09 Jan 2007 09:51:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4IJZ-0003Eb-Td for netconf-archive@lists.ietf.org; Tue, 09 Jan 2007 09:51:07 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H4I8z-0008vZ-IH for netconf-data@psg.com; Tue, 09 Jan 2007 14:40:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,PLING_PLING, SPF_PASS autolearn=no version=3.1.7 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H4I8v-0008tw-Il for netconf@ops.ietf.org; Tue, 09 Jan 2007 14:40:04 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 04AB64F0001; Tue, 9 Jan 2007 15:40:00 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 15:39:58 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 12:46:37 +0100 Message-ID: <45A3809C.1050406@ericsson.com> Date: Tue, 09 Jan 2007 12:46:36 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: Andy Bierman , "Netconf (E-mail)" Subject: Re: Please review new Notifications draft!!! References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2007 11:46:37.0538 (UTC) FILETIME=[D1E4E420:01C733E3] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Hello, Some more comments: General: I thought we agreed on having just one schema instead of many small ones, but if must I can live with this. Chapter 1.2) Please describe that any RPC requests received on a notification session may be discarded silently, without any response message. Chapter 2.3) Mention termination due to closing the transport session or stop-time. Chapter 3.2.5.2 Here in the nm:Name element we have NetconfNotificationSchema which is not describing the content of this specific schema. Chapter 3.3) "While it is possible ..." We do not provide a schema to retrieve this information, so I would formulate this as "While it might be possible ..." Chapter 6.2) Start and stop times should relate to generation time "whenever possible". Shouldn't we send back in the error info the date/time of the earliest available notification. Chapter 6.3) Please indicate what happens with the session after the replayComplete notification is sent. Is it terminated on transport level? Does it become a normal session? Is it some kind of stale/ useless session? What options might a device choose? I feel terminate SSH/SOAP/BEEP is the best. After updating according to Martin's Andy's etc. comments I agree with the last call. Balazs Romascanu, Dan (Dan) wrote: > I believe that the document can be sent to the WGLC. There have been > comments from Andy and Martin, can we consider them as initial WGLC > comments? > > Dan > > > > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >> Sent: Tuesday, December 26, 2006 9:17 PM >> To: Netconf (E-mail) >> Subject: Please review new Notifications draft!!! >> >> Hi, >> >> The new notifications draft has been out for about a week and >> so far, no comments. Not surprising, given the holidays, and >> lots of people on vacation. >> >> In case you missed the I-D announcement: >> >> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notific >> ation-05.txt >> >> Please try to read it in the next 2 weeks, and send comments >> to the WG mailing list. We need to know if you think this >> document is done and ready for WG Last Call. >> >> 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: -- 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 888momo444@docomo.ne.jp Fri Jan 12 20:33:09 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Xld-0002tB-UQ for netconf-archive@lists.ietf.org; Fri, 12 Jan 2007 20:33:09 -0500 Received: from [220.194.46.217] (helo=kimu01.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Xlb-0002Ss-JI for netconf-archive@lists.ietf.org; Fri, 12 Jan 2007 20:33:09 -0500 Subject: =?ISO-2022-JP?B?g4GBW4OLkniCrYLIgsGCxIK3gt2C3IK5gvGBQoFCkJCK84LFgreBQg==?= From: 瑞希 To: netconf-archive@lists.ietf.org Message-ID: 20070113100156 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Sat, 13 Jan 2007 10:02:00 +0900 (JST) X-Spam-Score: 1.6 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 はじめまして。瑞希といいます('-') 東京都内に住んでいます。35才で宝石店オーナーしてます。 今日メールしたのは1月に入って少し寂しくなって…土曜日か日曜日に会ってみませんか？ 場所を聞いてなかったからもし遠方の方だと失礼かなと思いましたが、もし都内近郊でしたら この週末に私と会ってくださいませんか？新宿か池袋あたりだと嬉しいです。 http://hie.holy.jp/mizuki/ どうしてもここの紹介所さんに恩義があるので、ここから一度だけメールをもらえませんか？ 今、mixiとかではやっている紹介制型になってるんです。女性の年齢層は30代みたいです('-') メールアドレスは新しくつくってからの私書箱を作ってもらえませんか？？ 私も友達から紹介されてここのサークルに入ってますが、新しくメアド作りました。 From Mizuki 瑞希 From owner-netconf@ops.ietf.org Tue Jan 16 10:58:39 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qhr-0002mG-3H for netconf-archive@lists.ietf.org; Tue, 16 Jan 2007 10:58:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qhp-0005Pr-07 for netconf-archive@lists.ietf.org; Tue, 16 Jan 2007 10:58:39 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H6qRA-000Bx0-6L for netconf-data@psg.com; Tue, 16 Jan 2007 15:41:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE autolearn=ham version=3.1.7 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H6qQx-000Bw1-ER for netconf@ops.ietf.org; Tue, 16 Jan 2007 15:41:18 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0GFf7Dg000687 for ; Tue, 16 Jan 2007 10:41:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73984.BD08B4CA" Subject: FW: [Notifications] Setting up email event streams Date: Tue, 16 Jan 2007 17:41:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Setting up email event streams Thread-Index: Acc4+0bvmKvI+wdvRGqxnpDUxDSyQQAiR19A From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , "Netconf \(E-mail\)" Cc: "Lisa Dusseault" X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7ddf3da2e36bf1816c08a54f16fcec30 This is a multi-part message in MIME format. ------_=_NextPart_001_01C73984.BD08B4CA Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C73984.BD08B4CA" ------_=_NextPart_002_01C73984.BD08B4CA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I apologize for the cross-posting, but the theme has some similarities with discussions that happened in the OPS area and specifically in NETCONF.=20 =20 Subscribing to the notifications list is probably the right way to follow this discussion or even contribute to it.=20 =20 Dan =20 =20 =20 =20 _____ =20 From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 Sent: Tuesday, January 16, 2007 1:16 AM To: Message Notifications interest group discussion list Subject: [Notifications] Setting up email event streams I've been meaning to send this out more broadly after a bit of private comment: two quite different models for setting up event streams based on what's easier to authenticate -- the event stream "owner" (in this case the mailbox owner) or the stream recipient. I hope it helps compare different approaches. Lisa --- The goal is to start (and stop) events flowing from an event source (in our case, an email server) to the event sink, frequently using a system with an explicit event relay. Because there are often three parties required in an event flow , we have to pick some way for the three parties to coordinate. The three parties are the event source (an email server), the event sink (a client, perhaps not an email client) and an event relay. The event relay has many users thus it has addresses for each user and possibly also addresses for devices/clients. Two kinds of application-layer explicit event relays are starting to be common: XMPP and SIP. For the purposes of considering an event feed setup model, we do not want to be concerned about the mostly orthogonal issue of what protocol to use to talk to event relay. So for now we assume that event relays have all features common to XMPP and SIP (addresses, pub/sub features, event stream aggregation). Choosing between two event stream setup models requires assumptions about - what kind of authorization is easier or more important to provide - whether there are a lot of different event sink addressess - whether direct access to the event source is always/usually available (can be affected by whether the event source is publicly available) - whether event flows stop and start frequently, or can simply be turned on for a very long term MODEL A. SUBSCRIBE Chain A-1 Description In this model, when a user decides to get an email event flow to a particular device or piece of software, the user typically works with the event sink interface to indicate where to get the events from. Then a SUBSCRIBE message of some kind gets generated by the event sink, sent to the event relay and is handled by the event source. A-2 Authorization issue The authorization problem here is to determine if the address that the SUBSCRIBE message comes from is permitted to receive these events. In the case of a publicly-subscribable resource this problem disappears. In many email use cases, only a small number of event sink addresses will be authorized to receive event notifications -- perhaps the event source (the email server) can simply be configured with a short allowed list of event recipients that doesn't change often (e.g. my personal IM address, my work address, and the one used by my phone provided by my phone service provider). Some SUBSCRIBE systems have the ability to provide a PENDING response to a subscription. This is used when an out-of-band mechanism is initiated to authorize the subscribing address. In an email event source use case, one obvious out-of-band mechanism is for the email server to create an email with a link saying "Click here to authorize this subscription". It's also possible to use a mechanism like URLAUTH to prove authorization -- in this approach, the subscriber provides a URL that has a secret token in it authorizing the subscription. It's possible that this would authorize the subscribing address for future subscriptions as well, or only for a limited period. A-3 Drawbacks: a) Only some notification protocols support SUBSCRIBE semantics. b) Complicated filters and event types (to support use cases like "Alert me on event type 'email arrives' if it is from my boss, has my full email address or the address of the developer list on the to line, and the subject does not begin with 'FUNNY'..." ) might need a little extra work. Both SIP and XMPP subscriptions can be extended in such a way that existing notification relays would pass on a filter specification in whatever language/format most appropriate for email. It might even be possible to send SIEVE conditionals in the body of the SUBSCRIBE message. XMPP has notification nodes in XEP-0060 and notification filters in XEP-0163. A-4 Advantages b) Allows for frequent starting and stopping of subscriptions, possibly an efficiency/scaling concern MODEL B. Sender RULES B-1 Description In this model, the user typically works with the event source in order to configure it to send events to a given set of addresses. For example, the user might have access to a Web interface to an email server where it can say "Send new message notifications to=20 xmpp://lisa@psg.com " or someday use MANAGESIEVE. B-2 Authorization issue The authorization problem here is to determine if the user creating the sending rule is authorized to send an event stream to the receiving address. If anybody can send to the receiving address (e.g. email) then it's publicly addressable and the problem disappears. Many kinds of addresses are publicly addressable and use whitelisting together with asking permission ("do you wish to allow messages from this source in the future"). B-3 Drawbacks: a) Only some event sources support RULE systems. We are building SIEVE for email clients and servers but it may be harder to generalize this beyond email clients and servers. Even sticking strictly the proposed scope of email server sources, we have to consider whether a client such as a calendar client (subscribing for IMIP messages) or a time-management dashboard (subscribes to "unread" counts but doesn't otherwise read email) are going to be able to implement SIEVE, authenticate to mail servers etc. b) If sender rules are setup through Web interfaces, users are definitely not going to turn them on and off frequently. c) Failure feedback: how does the event source let the user know that some address keeps bouncing? =20 ------_=_NextPart_002_01C73984.BD08B4CA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I apologize for the cross-posting, but the = theme has=20 some similarities with discussions that happened in the OPS area and=20 specifically in NETCONF.
 
Subscribing to the notifications list is = probably the=20 right way to follow this discussion or even contribute to it.=20
 
Dan
 
 
 
 

From: Lisa Dusseault=20 [mailto:lisa@osafoundation.org]
Sent: Tuesday, January 16, = 2007 1:16=20 AM
To: Message Notifications interest group discussion=20 list
Subject: [Notifications] Setting up email event=20 streams

I've been meaning to send this out more broadly after a bit of = private=20 comment: two quite different models for setting up event streams based = on what's=20 easier to authenticate -- the event stream "owner" (in this case the = mailbox=20 owner) or the stream recipient.  I hope it helps compare different=20 approaches.

Lisa

---

The goal is=20 to start (and stop) events flowing from an event source (in our case, an = email=20 server) to the event sink, frequently using a system with an explicit = event=20 relay.   = Because there are often three = parties=20 required in an event flow , we have to pick some way for the three = parties to=20 coordinate.

The three=20 parties are the event source (an email server), the event sink (a = client,=20 perhaps not an email client)  and an=20 event relay.  = The event relay = has many users=20 thus it has addresses for each user and possibly also addresses for=20 devices/clients. =20 Two kinds of = application-layer=20 explicit event relays are starting to be common: XMPP and = SIP.  For the purposes of considering an event feed setup = model, we do=20 not want to be concerned about the mostly orthogonal issue of what = protocol to=20 use to talk to event relay.  So for=20 now we assume that event relays have all features common to XMPP and SIP = (addresses, pub/sub features, event stream aggregation).

Choosing=20 between two event stream setup models requires assumptions = about
-=20 what kind of authorization is easier or more important to = provide
-=20 whether there are a lot of different event sink addressess
-=20 whether direct access to the event source is always/usually available = (can be=20 affected by whether the event source is publicly available)
-=20 whether event flows stop and start frequently, or can simply be turned = on for a=20 very long term

MODEL=20 A.  = SUBSCRIBE Chain

A-1=20 Description

In this=20 model, when a user decides to get an email event flow to a particular = device or=20 piece of software, the user typically works with the event sink = interface to=20 indicate where to get the events from.  Then a=20 SUBSCRIBE message of some kind gets generated by the event sink, sent to = the=20 event relay and is handled by the event source.

A-2=20 Authorization issue

The=20 authorization problem here is to determine if the address that the = SUBSCRIBE=20 message comes from is permitted to receive these events.  In the case of a publicly-subscribable resource this = problem=20 disappears.  = In many email use cases, only a = small=20 number of event sink addresses will be authorized to receive event = notifications=20 -- perhaps the event source (the email server) can simply be configured = with a=20 short allowed list of event recipients that doesn't change often (e.g. = my=20 personal IM address, my work address, and the one used by my phone = provided by=20 my phone service provider).

Some=20 SUBSCRIBE systems have the ability to provide a PENDING response to a=20 subscription. =20 This is used when = an=20 out-of-band mechanism is initiated to authorize the subscribing=20 address.  = In an email event source use = case, one=20 obvious out-of-band mechanism is for the email server to create an email = with a=20 link saying "Click here to authorize this subscription".

It's also=20 possible to use a mechanism like URLAUTH to prove authorization -- in = this=20 approach, the subscriber provides a URL that has a secret token in it=20 authorizing the subscription.  It's=20 possible that this would authorize the subscribing address for future=20 subscriptions as well, or only for a limited period.

A-3=20 Drawbacks:
  =20 a)  Only some notification protocols support SUBSCRIBE=20 semantics.

  =20 b)  Complicated filters and event types (to support use = cases like=20 "Alert me on event type 'email arrives' if it is from my boss, has my = full email=20 address or the address of the developer list on the to line, and the = subject=20 does not begin with 'FUNNY'..." )  might=20 need a little extra work.  Both SIP=20 and XMPP subscriptions can be extended in such a way that existing = notification=20 relays would pass on a filter specification in whatever language/format = most=20 appropriate for email. =20 It might even be = possible to=20 send SIEVE conditionals in the body of the SUBSCRIBE = message.  XMPP has notification nodes in XEP-0060 and notification = filters=20 in XEP-0163.

A-4=20 Advantages
  =20 b) Allows for = frequent=20 starting and stopping of subscriptions, possibly an efficiency/scaling=20 concern


MODEL B.=20 Sender RULES

B-1=20 Description

In this=20 model, the user typically works with the event source in order to = configure it=20 to send events to a given set of addresses.  For=20 example, the user might have access to a Web interface to an email = server where=20 it can say "Send new message notifications to xmpp://lisa@psg.com" or someday use MANAGESIEVE.

B-2=20 Authorization issue

The=20 authorization problem here is to determine if the user creating the = sending rule=20 is authorized to send an event stream to the receiving = address.  If anybody can send to the receiving address (e.g. = email) then=20 it's publicly addressable and the problem disappears.  Many kinds of addresses are publicly addressable and use = whitelisting together with asking permission ("do you wish to allow = messages=20 from this source in the future").

B-3=20 Drawbacks:
  =20 a) Only some event = sources=20 support RULE systems. =20 We are building = SIEVE for=20 email clients and servers but it may be harder to generalize this beyond = email=20 clients and servers. =20 Even sticking = strictly the=20 proposed scope of email server sources, we have to consider whether a = client=20 such as a calendar client (subscribing for IMIP messages) or a = time-management=20 dashboard (subscribes to "unread" counts but doesn't otherwise read = email) are=20 going to be able to implement SIEVE, authenticate to mail servers=20 etc.

  =20 b) If sender rules = are setup=20 through Web interfaces, users are definitely not going to turn them on = and off=20 frequently.

  =20 c) Failure = feedback: how does=20 the event source let the user know that some address keeps=20 bouncing?

 =20





------_=_NextPart_002_01C73984.BD08B4CA-- ------_=_NextPart_001_01C73984.BD08B4CA Content-Type: text/plain; name="ATT81747.txt" Content-Transfer-Encoding: base64 Content-Description: ATT81747.txt Content-Disposition: inline; filename="ATT81747.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5vdGlmaWNh dGlvbnMgbWFpbGluZyBsaXN0DQpOb3RpZmljYXRpb25zQGlldGYub3JnDQpodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ub3RpZmljYXRpb25zDQo= ------_=_NextPart_001_01C73984.BD08B4CA-- -- to unsubscribe send a message to netconf-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 Jan 18 07:48:45 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WhB-0007u8-4f for netconf-archive@lists.ietf.org; Thu, 18 Jan 2007 07:48:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Wh9-0005YN-Fy for netconf-archive@lists.ietf.org; Thu, 18 Jan 2007 07:48:45 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H7WV4-0009jx-3I for netconf-data@psg.com; Thu, 18 Jan 2007 12:36:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE autolearn=ham version=3.1.7 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H7WUz-0009ii-8T for netconf@ops.ietf.org; Thu, 18 Jan 2007 12:36:12 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JC200J6GD8U39@szxga02-in.huawei.com> for netconf@ops.ietf.org; Thu, 18 Jan 2007 20:26:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JC200K7MD8S6B@szxga02-in.huawei.com> for netconf@ops.ietf.org; Thu, 18 Jan 2007 20:26:53 +0800 (CST) Received: from l48181 ([10.111.12.59]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JC200D8ED8LNS@szxml04-in.huawei.com> for netconf@ops.ietf.org; Thu, 18 Jan 2007 20:26:52 +0800 (CST) Date: Thu, 18 Jan 2007 20:26:45 +0800 From: Li Yan Subject: a subtree filtering question To: netconf@ops.ietf.org Message-id: <000001c73afb$eb20dbf0$3b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_En0tb4ErKC3+eMs0afTY8Q)" Thread-index: Acc6++qPps7MSMQPQdGULRCyKT6/GQ== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.9 (+) X-Scan-Signature: 59da4bdfb55194488c2119a3e9cb65b0 This is a multi-part message in MIME format. --Boundary_(ID_En0tb4ErKC3+eMs0afTY8Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I don't understand the following two sentences in rfc4741. 6.2.5. o Filtering of mixed content is not supported. o Filtering of list content is not supported. Who can show me two examples to explain what are 'mixed content' and 'list content' respectively? Thanks Yan --Boundary_(ID_En0tb4ErKC3+eMs0afTY8Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I don’t understand the following two sentences in rfc4741.

6.2.5.

   o  Filtering of mixed content is not supported.

   o  Filtering of list content is not supported.

Who can show me two examples to explain what are ‘mixed content’ and ‘list content’ respectively?

Thanks

 

Yan

--Boundary_(ID_En0tb4ErKC3+eMs0afTY8Q)-- -- to unsubscribe send a message to netconf-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 Jan 29 08:06:20 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWDE-0007n0-M1 for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 08:06:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBWDD-0008Hl-9l for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 08:06:20 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBW0R-000KVI-OY for netconf-data@psg.com; Mon, 29 Jan 2007 12:53:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, FORGED_RCVD_HELO autolearn=no version=3.1.7 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBW0N-000KUo-4B for netconf@ops.ietf.org; Mon, 29 Jan 2007 12:53:06 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TCqvmY027290 for ; Mon, 29 Jan 2007 07:53:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [PEPPERMINT] new BoF proposal Date: Mon, 29 Jan 2007 14:52:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] new BoF proposal Thread-Index: AcdDC0Dz81DdNwmoTKK6DZe/P8REuQAmQ4Mg From: "Romascanu, Dan \(Dan\)" To: "Netconf \(E-mail\)" X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 =20 Please see the following BOF proposal.=20 Should we tell them to have a look at NETCONF?=20 Dan =20 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Sunday, January 28, 2007 8:36 PM To: peppermint@ietf.org Subject: [PEPPERMINT] new BoF proposal All, A tightened up version of the PEPPERMINT BoF proposal has been formulated. The major changes since the last version are: 1) some language has been changed or eliminated that was construed to give PEPPERMINT a larger scope than intended, and 2) the input documents are listed. The text is below. Comments, questions, and suggestions welcomed. -andy Peppermint BOF Provisioning Extensions in Peering Registries for Multimedia INTerconnection. Mailing Lists: BOF chairs: Andrew Newton [andy@hxr.us] Richard Shockey [rich.shockey@neustar.biz] Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD BOF Purpose. The ENUM and SPEERMINT working groups are working on various aspects of Multi Media Interconnection. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. =20 SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across domain boundaries. It is clear from discussions in both working groups that Multi-Media Interconnection will require address of record data to be provisioned among administrative domains outside the normal scope of establishing a SIP session. The purpose of the BOF is to determine the need and scope for such data exchanges, what existing protocols need to be adapted to meet those needs and the appropriate schema and queries are needed to facilitate such exchanges. The IETF has in the past done significant work on data exchanges among various administrative entities. In particular the PROVREG working group developed various schema and query mechanisms to facilitate the exchange of data among domain name registries and registrars. The ENUM Working group has adapted PROVREG working group protocols to develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS tree. However, there has been little adoption of RFC 4114, and many in the operator community require both data models and protocol features not found in RFC 4114. The proposed PEPPERMINT working group will build upon the knowledge gained from those efforts, and the intent of this proposed working group is to find a provisioning solution for peering as defined by SPEERMINT. The final work product(s) from this working group will be based upon XML. =20 Additionally, bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or HTTP/SOAP. Proposed Deliverables: 1) Requirements for SPEERMINT data exchange. 2) Provisioning of SPEERMINT data registries. 3) Provisioning of SPEERMINT/ENUM data caches. Input Documents: 1) PEPPERMINT Problem Statement draft-newton-peppermint-problem-statement-00.txt 2) E.164 Number Provisioning Requirements - Data Set Requirements draft-schwartz-peppermint-e164-provisioning-data-set-00.txt 3) ENUM Registry Interface Requirements draft-lewis-peppermint-enum-reg-if-00.txt _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint -- to unsubscribe send a message to netconf-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 Jan 29 09:23:07 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXPX-0003DY-SF for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 09:23:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXPW-00021T-IM for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 09:23:07 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBXGl-0000Wc-7L for netconf-data@psg.com; Mon, 29 Jan 2007 14:14:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBXGi-0000WJ-So for netconf@ops.ietf.org; Mon, 29 Jan 2007 14:14:02 +0000 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2007 15:14:00 +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 l0TEDxNi016481; Mon, 29 Jan 2007 15:13:59 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4249.cisco.com [10.61.80.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0TEDsC8013293; Mon, 29 Jan 2007 15:13:55 +0100 (MET) Message-ID: <45BE0122.4000908@cisco.com> Date: Mon, 29 Jan 2007 15:13:54 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: "Netconf (E-mail)" Subject: Re: FW: [PEPPERMINT] new BoF proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=328; t=1170080039; x=1170944039; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20FW=3A=20[PEPPERMINT]=20new=20BoF=20proposal |Sender:=20; bh=WHXu0RtiSLnD2qX9F8PExSOost4lQfKNFvCzDYepAoM=; b=H00U7dcsHm2amxkE5hfbjv3uyKyAThmozZZ1u+TAcJADU6NLFqJLEgp8lPmnL6bcQjT7+wGN FALCXPdiCOwlgdSL8zNWDDpmkAAReOrOOyRXtD1JYIcJcxrt9b8q5so9; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Hi Dan, I don't understand enough about the requirements for PEPPERMINT to say whether NETCONF is appropriate. For high volume provisioning perhaps there are better alternatives (for instance, radius and diameter come to mind). Then again, for low volume device configuration, we'd be right in NETCONF's ballpark. -- to unsubscribe send a message to netconf-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 Jan 29 13:30:10 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbGc-0001eU-By for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 13:30:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbGb-00024X-1z for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 13:30:10 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBb7A-000JiZ-If for netconf-data@psg.com; Mon, 29 Jan 2007 18:20:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBb73-000Ji3-QI for netconf@ops.ietf.org; Mon, 29 Jan 2007 18:20:23 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0TIK7qW017377 for ; Mon, 29 Jan 2007 13:20:11 -0500 Received: (qmail 13187 invoked by uid 78); 29 Jan 2007 18:05:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 29 Jan 2007 18:05:27 -0000 Message-ID: <45BE375F.7010809@andybierman.com> Date: Mon, 29 Jan 2007 10:05:19 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Eliot Lear CC: "Romascanu, Dan \(Dan\)" , "Netconf (E-mail)" Subject: Re: FW: [PEPPERMINT] new BoF proposal References: <45BE0122.4000908@cisco.com> In-Reply-To: <45BE0122.4000908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Eliot Lear wrote: > Hi Dan, > > I don't understand enough about the requirements for PEPPERMINT to say > whether NETCONF is appropriate. For high volume provisioning perhaps > there are better alternatives (for instance, radius and diameter come to > mind). Then again, for low volume device configuration, we'd be right > in NETCONF's ballpark. I sort of disagree. The volume of changes (i.e., performance issues) can be addressed in the implementation. I don't know enough about PEPPERMINT either, but IMO NETCONF could be used very effectively for provisioning, with some specialized RPC methods (for performance and ease of use) and a multi-user locking mechanism. The protocol already supports arbitrary new RPC methods, but the 'partial lock' feature is still TBD of course. 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 Jan 29 13:53:54 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbda-0002v7-4K for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 13:53:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbdY-0004gV-KY for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 13:53:54 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBbWH-000M13-Vy for netconf-data@psg.com; Mon, 29 Jan 2007 18:46:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, FORGED_RCVD_HELO autolearn=no version=3.1.7 Received: from [209.86.89.68] (helo=elasmtp-masked.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBbWE-000M0g-SK for netconf@ops.ietf.org; Mon, 29 Jan 2007 18:46:20 +0000 Received: from [71.254.17.176] (helo=JMHLap3.stevecrocker.com) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HBbW9-0008F3-PL for netconf@ops.ietf.org; Mon, 29 Jan 2007 13:46:14 -0500 Message-Id: <7.0.1.0.0.20070129134501.03533ab8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 29 Jan 2007 13:45:45 -0500 To: "Netconf \(E-mail\)" From: "Joel M. Halpern" Subject: Re: FW: [PEPPERMINT] new BoF proposal In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711208344eb9d8c45bba30c47dad9fb4f72a47ea3a3c712ed9601350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.17.176 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 You should only point them at NETCONF if we are prepared to help them define a data model that actually works with NETCONF, instead of the working groups perpetual arguments about what a data model might look like, or why we won't define a data model, or ... A way of encapsulating CLI (which is all that NETCONF has so far managed to provide) does not solve the problem at all. Yours, Joel M. Halpern At 07:52 AM 1/29/2007, Romascanu, Dan \(Dan\) wrote: > >Please see the following BOF proposal. > >Should we tell them to have a look at NETCONF? > >Dan > > > > >-----Original Message----- >From: Andrew Newton [mailto:andy@hxr.us] >Sent: Sunday, January 28, 2007 8:36 PM >To: peppermint@ietf.org >Subject: [PEPPERMINT] new BoF proposal > >All, > >A tightened up version of the PEPPERMINT BoF proposal has been >formulated. The major changes since the last version are: 1) some >language has been changed or eliminated that was construed to give >PEPPERMINT a larger scope than intended, and 2) the input documents are >listed. > >The text is below. Comments, questions, and suggestions welcomed. > >-andy > >Peppermint BOF > >Provisioning Extensions in Peering Registries for Multimedia >INTerconnection. > >Mailing Lists: > >BOF chairs: > >Andrew Newton [andy@hxr.us] > >Richard Shockey [rich.shockey@neustar.biz] > >Temporary Area Directorate: Real Time Applications (RAI) > >Ultimate Area Directorate: TBD > > >BOF Purpose. > >The ENUM and SPEERMINT working groups are working on various aspects of >Multi Media Interconnection. ENUM is specifically chartered to develop >protocols that involve the translation of E.164 numbers to URI's. >SPEERMINT >has been chartered to develop best current practices among real-time >application service providers and how such services interconnect across >domain boundaries. > >It is clear from discussions in both working groups that Multi-Media >Interconnection will require address of record data to be provisioned >among administrative domains outside the normal scope of establishing a >SIP session. > >The purpose of the BOF is to determine the need and scope for such data >exchanges, what existing protocols need to be adapted to meet those >needs and the appropriate schema and queries are needed to facilitate >such exchanges. > >The IETF has in the past done significant work on data exchanges among >various administrative entities. In particular the PROVREG working group >developed various schema and query mechanisms to facilitate the exchange >of data among domain name registries and registrars. > >The ENUM Working group has adapted PROVREG working group protocols to >develop RFC 4114, which facilitates the provisioning of ENUM data in the >DNS tree. However, there has been little adoption of RFC 4114, and many >in the operator community require both data models and protocol features >not found in RFC 4114. > >The proposed PEPPERMINT working group will build upon the knowledge >gained from those efforts, and the intent of this proposed working group >is to find a provisioning solution for peering as defined by SPEERMINT. >The final work >product(s) from this working group will be based upon XML. >Additionally, >bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or >HTTP/SOAP. > >Proposed Deliverables: > >1) Requirements for SPEERMINT data exchange. >2) Provisioning of SPEERMINT data registries. >3) Provisioning of SPEERMINT/ENUM data caches. > >Input Documents: > >1) PEPPERMINT Problem Statement >draft-newton-peppermint-problem-statement-00.txt > >2) E.164 Number Provisioning Requirements - Data Set Requirements >draft-schwartz-peppermint-e164-provisioning-data-set-00.txt > >3) ENUM Registry Interface Requirements >draft-lewis-peppermint-enum-reg-if-00.txt > > >_______________________________________________ >PEPPERMINT mailing list >PEPPERMINT@ietf.org >https://www1.ietf.org/mailman/listinfo/peppermint > > >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 29 14:58:01 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcdd-0001uS-Es for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 14:58:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBcdc-0005lR-4e for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 14:58:01 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBcWN-0002jV-B9 for netconf-data@psg.com; Mon, 29 Jan 2007 19:50:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBcWF-0002h8-Fi for netconf@ops.ietf.org; Mon, 29 Jan 2007 19:50:25 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0TJoMN9025673 for ; Mon, 29 Jan 2007 14:50:22 -0500 Received: (qmail 9504 invoked by uid 78); 29 Jan 2007 19:50:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 29 Jan 2007 19:50:15 -0000 Message-ID: <45BE4FED.8070602@andybierman.com> Date: Mon, 29 Jan 2007 11:50:05 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Joel M. Halpern" CC: "Netconf (E-mail)" Subject: Re: FW: [PEPPERMINT] new BoF proposal References: <7.0.1.0.0.20070129134501.03533ab8@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20070129134501.03533ab8@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Joel M. Halpern wrote: > You should only point them at NETCONF if we are prepared to help them > define a data model that actually works with NETCONF, instead of the > working groups perpetual arguments about what a data model might look > like, or why we won't define a data model, or ... > A way of encapsulating CLI (which is all that NETCONF has so far managed > to provide) does not solve the problem at all. I'm not writing off NETCONF a month after the RFCs are published. I expect early NE implementations to be "wide and shallow" mappings from proprietary CLI to proprietary encapsulated CLI. More interesting implementations will follow later. IMO, the real issue is whether any WG in question can agree on the information model and operational model for a particular feature. If you can get that far, then many different protocols and encodings will work. We have very few standards for configuration because vendors have not agreed on very many common 'knobs', let alone common operational procedures. The overhead of sessions, configuration databases, and other NETCONF-centric details may be reason enough to create something new, but even NE provisioning apps today have to integrate with CLI-based configuration management. The non-volatile config file on the device usually needs to be updated, regardless of the API. NETCONF is designed to work with this type of device. > > Yours, > Joel M. Halpern 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 Jan 29 15:06:01 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBclN-0005kz-Tl for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 15:06:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBclL-0006zU-G8 for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 15:06:01 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBcem-0003dz-Gz for netconf-data@psg.com; Mon, 29 Jan 2007 19:59:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBceg-0003dD-Tp for netconf@ops.ietf.org; Mon, 29 Jan 2007 19:59:11 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TJx2V5000393 for ; Mon, 29 Jan 2007 14:59:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [PEPPERMINT] new BoF proposal Date: Mon, 29 Jan 2007 21:59:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [PEPPERMINT] new BoF proposal Thread-Index: AcdD3wn2CiFvc+uXR+GiyPCgAqiJYwAAGNIA References: <7.0.1.0.0.20070129134501.03533ab8@stevecrocker.com> <45BE4FED.8070602@andybierman.com> From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Joel M. Halpern" Cc: "Netconf \(E-mail\)" X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Andy, NETCONF was designed to solve real-life problems. Here is a real-life problem. Are we ready to go and say 'look at NETCONF' as to a possible solution? Are you or somebody willing to go to the peppermint BOF (assuming it is approved) and explain this?=20 Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Monday, January 29, 2007 9:50 PM > To: Joel M. Halpern > Cc: Netconf (E-mail) > Subject: Re: FW: [PEPPERMINT] new BoF proposal >=20 > Joel M. Halpern wrote: > > You should only point them at NETCONF if we are prepared to=20 > help them=20 > > define a data model that actually works with NETCONF,=20 > instead of the=20 > > working groups perpetual arguments about what a data model=20 > might look=20 > > like, or why we won't define a data model, or ... > > A way of encapsulating CLI (which is all that NETCONF has so far=20 > > managed to provide) does not solve the problem at all. >=20 > I'm not writing off NETCONF a month after the RFCs are published. > I expect early NE implementations to be "wide and shallow"=20 > mappings from proprietary CLI to proprietary encapsulated=20 > CLI. More interesting implementations will follow later. >=20 > IMO, the real issue is whether any WG in question can agree=20 > on the information model and operational model for a=20 > particular feature. > If you can get that far, then many different protocols and=20 > encodings will work. We have very few standards for=20 > configuration because vendors have not agreed on very many=20 > common 'knobs', let alone common operational procedures. >=20 > The overhead of sessions, configuration databases, and other=20 > NETCONF-centric details may be reason enough to create=20 > something new, but even NE provisioning apps today have to=20 > integrate with CLI-based configuration management. > The non-volatile config file on the device usually needs to=20 > be updated, regardless of the API. NETCONF is designed to=20 > work with this type of device. >=20 > >=20 > > Yours, > > Joel M. Halpern >=20 > Andy >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 29 16:22:27 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdxL-0003np-4D for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 16:22:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdxI-0004Wo-Fn for netconf-archive@lists.ietf.org; Mon, 29 Jan 2007 16:22:27 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBdpH-000AHL-R1 for netconf-data@psg.com; Mon, 29 Jan 2007 21:14:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBdpF-000AH6-8h for netconf@ops.ietf.org; Mon, 29 Jan 2007 21:14:06 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l0TLE2tp025860 for ; Mon, 29 Jan 2007 16:14:03 -0500 Received: (qmail 28139 invoked by uid 78); 29 Jan 2007 21:13:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 29 Jan 2007 21:13:51 -0000 Message-ID: <45BE638C.7030908@andybierman.com> Date: Mon, 29 Jan 2007 13:13:48 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: "Joel M. Halpern" , "Netconf (E-mail)" Subject: Re: FW: [PEPPERMINT] new BoF proposal References: <7.0.1.0.0.20070129134501.03533ab8@stevecrocker.com> <45BE4FED.8070602@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Romascanu, Dan (Dan) wrote: > Andy, > > NETCONF was designed to solve real-life problems. Here is a real-life > problem. Are we ready to go and say 'look at NETCONF' as to a possible > solution? Are you or somebody willing to go to the peppermint BOF > (assuming it is approved) and explain this? I will go to the BOF and try to read and understand the drafts. If I think NETCONF applies, I'll suggest it. > > 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 Tue Jan 30 01:31:16 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBmWS-0006EQ-Tt for netconf-archive@lists.ietf.org; Tue, 30 Jan 2007 01:31:16 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBmWR-0004Ig-G2 for netconf-archive@lists.ietf.org; Tue, 30 Jan 2007 01:31:16 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBmJa-000L14-TH for netconf-data@psg.com; Tue, 30 Jan 2007 06:17:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBmJY-000L0r-If for netconf@ops.ietf.org; Tue, 30 Jan 2007 06:17:57 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0U6HnDC029381 for ; Tue, 30 Jan 2007 01:17:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [PEPPERMINT] new BoF proposal Date: Tue, 30 Jan 2007 08:17:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [PEPPERMINT] new BoF proposal Thread-Index: AcdD6oFcEjxRoutFRl+jkZjnoJ/pNwAS28uw References: <7.0.1.0.0.20070129134501.03533ab8@stevecrocker.com> <45BE4FED.8070602@andybierman.com> <45BE638C.7030908@andybierman.com> From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" Cc: "Joel M. Halpern" , "Netconf \(E-mail\)" X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Monday, January 29, 2007 11:14 PM > To: Romascanu, Dan (Dan) > Cc: Joel M. Halpern; Netconf (E-mail) > Subject: Re: FW: [PEPPERMINT] new BoF proposal >=20 > Romascanu, Dan (Dan) wrote: > > Andy, > >=20 > > NETCONF was designed to solve real-life problems. Here is a=20 > real-life=20 > > problem. Are we ready to go and say 'look at NETCONF' as to a=20 > > possible solution? Are you or somebody willing to go to the=20 > peppermint=20 > > BOF (assuming it is approved) and explain this? >=20 > I will go to the BOF and try to read and understand the drafts. > If I think NETCONF applies, I'll suggest it. >=20 > >=20 > > Dan >=20 > Andy Sounds good. I will send them a comment in the meantime asking for NETCONF to be included in the list of technologies to look at, so that maybe some will look at it from their perspective, or at least it does not sound totally unknown to everybody there.=20 Dan >=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 Jan 30 15:38:49 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzkf-0005yf-Qg for netconf-archive@lists.ietf.org; Tue, 30 Jan 2007 15:38:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBzkd-0005Ba-Nl for netconf-archive@lists.ietf.org; Tue, 30 Jan 2007 15:38:49 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBzPJ-0008Hm-1v for netconf-data@psg.com; Tue, 30 Jan 2007 20:16:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.7 Received: from [63.240.77.83] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HBzPB-0008Gw-5e for netconf@ops.ietf.org; Tue, 30 Jan 2007 20:16:42 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007013020163401300i1brue>; Tue, 30 Jan 2007 20:16:34 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'OPS Area'" , "'Netconf \(E-mail\)'" Cc: "'Lisa Dusseault'" References: Subject: RE: [Notifications] Setting up email event streams Date: Tue, 30 Jan 2007 15:12:48 -0500 Message-ID: <07f601c744ab$03c30f80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07F7_01C74481.1AED0780" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-reply-to: Thread-index: Acc4+0bvmKvI+wdvRGqxnpDUxDSyQQAiR19AAskTnTA= Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c333e139fa2e0789f26c027c47be6c7f This is a multi-part message in MIME format. ------=_NextPart_000_07F7_01C74481.1AED0780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, A third common application-layer explicit event relay is syslog, and the syslog-security WG just submitted a spec for a standardized protocol and standardized transports over udp and tls to the IESG for advancement. They are resolving WGLC issues related to syslog-sign, a mechanism that "signs" messages to ensure they have not been modified in transit, and workin gon an update to RFC3195 which provides reliable in-order transport. A fourth is SNMP. The ISMS WG is dealing with the authentication/authorization issues of sending notifications, as well as request/response messages, sometimes through a proxy forwarder (relay). The netconf WG is also dealing with subscribe/unsubscribe issues and event stream aggregation issues. dbh _____ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, January 16, 2007 10:41 AM To: OPS Area; Netconf (E-mail) Cc: Lisa Dusseault Subject: FW: [Notifications] Setting up email event streams I apologize for the cross-posting, but the theme has some similarities with discussions that happened in the OPS area and specifically in NETCONF. Subscribing to the notifications list is probably the right way to follow this discussion or even contribute to it. Dan _____ From: Lisa Dusseault [mailto:lisa@osafoundation.org] Sent: Tuesday, January 16, 2007 1:16 AM To: Message Notifications interest group discussion list Subject: [Notifications] Setting up email event streams I've been meaning to send this out more broadly after a bit of private comment: two quite different models for setting up event streams based on what's easier to authenticate -- the event stream "owner" (in this case the mailbox owner) or the stream recipient. I hope it helps compare different approaches. Lisa --- The goal is to start (and stop) events flowing from an event source (in our case, an email server) to the event sink, frequently using a system with an explicit event relay. Because there are often three parties required in an event flow , we have to pick some way for the three parties to coordinate. The three parties are the event source (an email server), the event sink (a client, perhaps not an email client) and an event relay. The event relay has many users thus it has addresses for each user and possibly also addresses for devices/clients. Two kinds of application-layer explicit event relays are starting to be common: XMPP and SIP. For the purposes of considering an event feed setup model, we do not want to be concerned about the mostly orthogonal issue of what protocol to use to talk to event relay. So for now we assume that event relays have all features common to XMPP and SIP (addresses, pub/sub features, event stream aggregation). Choosing between two event stream setup models requires assumptions about - what kind of authorization is easier or more important to provide - whether there are a lot of different event sink addressess - whether direct access to the event source is always/usually available (can be affected by whether the event source is publicly available) - whether event flows stop and start frequently, or can simply be turned on for a very long term MODEL A. SUBSCRIBE Chain A-1 Description In this model, when a user decides to get an email event flow to a particular device or piece of software, the user typically works with the event sink interface to indicate where to get the events from. Then a SUBSCRIBE message of some kind gets generated by the event sink, sent to the event relay and is handled by the event source. A-2 Authorization issue The authorization problem here is to determine if the address that the SUBSCRIBE message comes from is permitted to receive these events. In the case of a publicly-subscribable resource this problem disappears. In many email use cases, only a small number of event sink addresses will be authorized to receive event notifications -- perhaps the event source (the email server) can simply be configured with a short allowed list of event recipients that doesn't change often (e.g. my personal IM address, my work address, and the one used by my phone provided by my phone service provider). Some SUBSCRIBE systems have the ability to provide a PENDING response to a subscription. This is used when an out-of-band mechanism is initiated to authorize the subscribing address. In an email event source use case, one obvious out-of-band mechanism is for the email server to create an email with a link saying "Click here to authorize this subscription". It's also possible to use a mechanism like URLAUTH to prove authorization -- in this approach, the subscriber provides a URL that has a secret token in it authorizing the subscription. It's possible that this would authorize the subscribing address for future subscriptions as well, or only for a limited period. A-3 Drawbacks: a) Only some notification protocols support SUBSCRIBE semantics. b) Complicated filters and event types (to support use cases like "Alert me on event type 'email arrives' if it is from my boss, has my full email address or the address of the developer list on the to line, and the subject does not begin with 'FUNNY'..." ) might need a little extra work. Both SIP and XMPP subscriptions can be extended in such a way that existing notification relays would pass on a filter specification in whatever language/format most appropriate for email. It might even be possible to send SIEVE conditionals in the body of the SUBSCRIBE message. XMPP has notification nodes in XEP-0060 and notification filters in XEP-0163. A-4 Advantages b) Allows for frequent starting and stopping of subscriptions, possibly an efficiency/scaling concern MODEL B. Sender RULES B-1 Description In this model, the user typically works with the event source in order to configure it to send events to a given set of addresses. For example, the user might have access to a Web interface to an email server where it can say "Send new message notifications to xmpp://lisa@psg.com" or someday use MANAGESIEVE. B-2 Authorization issue The authorization problem here is to determine if the user creating the sending rule is authorized to send an event stream to the receiving address. If anybody can send to the receiving address (e.g. email) then it's publicly addressable and the problem disappears. Many kinds of addresses are publicly addressable and use whitelisting together with asking permission ("do you wish to allow messages from this source in the future"). B-3 Drawbacks: a) Only some event sources support RULE systems. We are building SIEVE for email clients and servers but it may be harder to generalize this beyond email clients and servers. Even sticking strictly the proposed scope of email server sources, we have to consider whether a client such as a calendar client (subscribing for IMIP messages) or a time-management dashboard (subscribes to "unread" counts but doesn't otherwise read email) are going to be able to implement SIEVE, authenticate to mail servers etc. b) If sender rules are setup through Web interfaces, users are definitely not going to turn them on and off frequently. c) Failure feedback: how does the event source let the user know that some address keeps bouncing? ------=_NextPart_000_07F7_01C74481.1AED0780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A third common application-layer explicit event = relay is=20 syslog, and the syslog-security WG just submitted a spec for a = standardized=20 protocol and standardized transports over udp and tls to the IESG for=20 advancement. They are resolving WGLC issues related to syslog-sign, a = mechanism=20 that "signs" messages to ensure they have not been modified in transit, = and=20 workin gon an update to RFC3195 which provides reliable in-order=20 transport.
 
A fourth is SNMP. The ISMS WG is dealing with = the=20 authentication/authorization issues of sending notifications, as well as = request/response messages, sometimes through a proxy forwarder=20 (relay).
 
The netconf WG is also dealing with = subscribe/unsubscribe=20 issues and event stream aggregation issues.
 
dbh

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Tuesday, January 16, 2007 10:41 AM
To: = OPS=20 Area; Netconf (E-mail)
Cc: Lisa Dusseault
Subject: = FW:=20 [Notifications] Setting up email event streams

I apologize for the cross-posting, but the = theme has=20 some similarities with discussions that happened in the OPS area and=20 specifically in NETCONF.
 
Subscribing to the notifications list is = probably the=20 right way to follow this discussion or even contribute to it.=20
 
Dan
 
 
 
 

From: Lisa Dusseault=20 [mailto:lisa@osafoundation.org]
Sent: Tuesday, January 16, = 2007=20 1:16 AM
To: Message Notifications interest group discussion=20 list
Subject: [Notifications] Setting up email event=20 streams

I've been meaning to send this out more broadly after a bit of = private=20 comment: two quite different models for setting up event streams based = on=20 what's easier to authenticate -- the event stream "owner" (in this = case the=20 mailbox owner) or the stream recipient.  I hope it helps compare=20 different approaches.

Lisa

---

The goal=20 is to start (and stop) events flowing from an event source (in our = case, an=20 email server) to the event sink, frequently using a system with an = explicit=20 event relay.  =20 Because there = are often=20 three parties required in an event flow , we have to pick some way for = the=20 three parties to coordinate.

The three=20 parties are the event source (an email server), the event sink (a = client,=20 perhaps not an email client)  and an=20 event relay. =20 The event relay = has many=20 users thus it has addresses for each user and possibly also addresses = for=20 devices/clients. =20 Two kinds of=20 application-layer explicit event relays are starting to be common: = XMPP and=20 SIP.  = For the purposes of = considering an event=20 feed setup model, we do not want to be concerned about the mostly = orthogonal=20 issue of what protocol to use to talk to event relay.  So for now we assume that = event relays=20 have all features common to XMPP and SIP (addresses, pub/sub features, = event=20 stream aggregation).

Choosing=20 between two event stream setup models requires assumptions = about
-=20 what kind of authorization is easier or more important to = provide
-=20 whether there are a lot of different event sink = addressess
-=20 whether direct access to the event source is always/usually available = (can be=20 affected by whether the event source is publicly = available)
-=20 whether event flows stop and start frequently, or can simply be turned = on for=20 a very long term

MODEL=20 A.  = SUBSCRIBE Chain

A-1=20 Description

In this=20 model, when a user decides to get an email event flow to a particular = device=20 or piece of software, the user typically works with the event sink = interface=20 to indicate where to get the events from.  Then a=20 SUBSCRIBE message of some kind gets generated by the event sink, sent = to the=20 event relay and is handled by the event source.

A-2=20 Authorization issue

The=20 authorization problem here is to determine if the address that the = SUBSCRIBE=20 message comes from is permitted to receive these events.  In the case of a = publicly-subscribable=20 resource this problem disappears.  In many=20 email use cases, only a small number of event sink addresses will be=20 authorized to receive event notifications -- perhaps the event source = (the=20 email server) can simply be configured with a short allowed list of = event=20 recipients that doesn't change often (e.g. my personal IM address, my = work=20 address, and the one used by my phone provided by my phone service=20 provider).

Some=20 SUBSCRIBE systems have the ability to provide a PENDING response to a=20 subscription. =20 This is used = when an=20 out-of-band mechanism is initiated to authorize the subscribing=20 address.  = In an email event source use = case, one=20 obvious out-of-band mechanism is for the email server to create an = email with=20 a link saying "Click here to authorize this = subscription".

It's also=20 possible to use a mechanism like URLAUTH to prove authorization -- in = this=20 approach, the subscriber provides a URL that has a secret token in it=20 authorizing the subscription.  It's=20 possible that this would authorize the subscribing address for future=20 subscriptions as well, or only for a limited period.

A-3=20 Drawbacks:
   a) =20 Only some = notification=20 protocols support SUBSCRIBE semantics.

   b) =20 Complicated = filters and=20 event types (to support use cases like "Alert me on event type 'email = arrives'=20 if it is from my boss, has my full email address or the address of the = developer list on the to line, and the subject does not begin with = 'FUNNY'..."=20 )  = might need a little extra=20 work.  = Both SIP and XMPP = subscriptions can be=20 extended in such a way that existing notification relays would pass on = a=20 filter specification in whatever language/format most appropriate for=20 email.  = It might even be possible to = send SIEVE=20 conditionals in the body of the SUBSCRIBE message.  XMPP has notification nodes = in XEP-0060=20 and notification filters in XEP-0163.

A-4=20 Advantages
   b) Allows for frequent starting and stopping of = subscriptions,=20 possibly an efficiency/scaling concern


MODEL B.=20 Sender RULES

B-1=20 Description

In this=20 model, the user typically works with the event source in order to = configure it=20 to send events to a given set of addresses.  For=20 example, the user might have access to a Web interface to an email = server=20 where it can say "Send new message notifications to xmpp://lisa@psg.com" or someday use MANAGESIEVE.

B-2=20 Authorization issue

The=20 authorization problem here is to determine if the user creating the = sending=20 rule is authorized to send an event stream to the receiving=20 address.  = If anybody can send to the = receiving=20 address (e.g. email) then it's publicly addressable and the problem=20 disappears. =20 Many kinds of = addresses are=20 publicly addressable and use whitelisting together with asking = permission ("do=20 you wish to allow messages from this source in the = future").

B-3=20 Drawbacks:
   a) Only some event sources support RULE = systems.  We are building SIEVE for = email clients=20 and servers but it may be harder to generalize this beyond email = clients and=20 servers.  = Even sticking strictly the = proposed scope=20 of email server sources, we have to consider whether a client such as = a=20 calendar client (subscribing for IMIP messages) or a time-management = dashboard=20 (subscribes to "unread" counts but doesn't otherwise read email) are = going to=20 be able to implement SIEVE, authenticate to mail servers = etc.

   b) If sender rules are setup through Web interfaces, = users are=20 definitely not going to turn them on and off frequently.

   c) Failure feedback: how does the event source let the = user know=20 that some address keeps bouncing?

 





------=_NextPart_000_07F7_01C74481.1AED0780-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: