[Forces-protocol] RE: Meaning of PACKET *SUBSCRIBE operation type unclear

"Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com> Mon, 25 October 2004 23:54 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20130 for <forces-protocol-web-archive@ietf.org>; Mon, 25 Oct 2004 19:54:23 -0400 (EDT)
Received: from megatron.ietf.org ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEsy-0004mp-TD for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:08:25 -0400
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEOU-00080W-Ib; Mon, 25 Oct 2004 19:36:54 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMCEd-0003w1-J0 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:18:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11691 for <forces-protocol@ietf.org>; Mon, 25 Oct 2004 17:18:32 -0400 (EDT)
Received: from fmr06.intel.com ([] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCS9-0001Uk-5W for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:32:34 -0400
Received: from petasus.jf.intel.com (petasus.jf.intel.com []) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PLHer8032731; Mon, 25 Oct 2004 21:17:40 GMT
Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com []) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PLLdsG029826; Mon, 25 Oct 2004 21:21:42 GMT
Received: from orsmsx331.amr.corp.intel.com ([]) by orsmsxvs041.jf.intel.com (SAVSMTP with SMTP id M2004102514175904823 ; Mon, 25 Oct 2004 14:17:59 -0700
Received: from orsmsx408.amr.corp.intel.com ([]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 14:17:59 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Oct 2004 14:17:58 -0700
Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DD86@orsmsx408>
Thread-Topic: Meaning of PACKET *SUBSCRIBE operation type unclear
Thread-Index: AcS610FxLdBMIO0wQAeMOG0Y8hE+xgAACZ2Q
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
To: "Robert Haas" <rha@zurich.ibm.com>, "Jamal Hadi Salim" <hadi@znyx.com>
X-OriginalArrivalTime: 25 Oct 2004 21:17:59.0439 (UTC) FILETIME=[1A8D59F0:01C4BAD8]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: quoted-printable
Cc: avri@psg.com, ram.gopal@nokia.com, Ligang Dong <donglg@mail.hzic.edu.cn>, "Wang, Weiming" <wmwang@mail.hzic.edu.cn>, forces-protocol@ietf.org
Subject: [Forces-protocol] RE: Meaning of PACKET *SUBSCRIBE operation type unclear
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: quoted-printable


I am not so sure about this, what kind of attributes would the LFB have
to expose for this ?
What do others think about this ? Jamal, you had a similar
question...let us know what your experience has been in this regard.

In our experience, we had such messages which would specify filters,
e.g. Packet Subscribe for filters A, B, C, etc. But I am fine with doing
this a different way as well...what is important is that this
functionality needs to be supported by the protocol.


-----Original Message-----
From: Robert Haas [mailto:rha@zurich.ibm.com] 

My current thinking is that any LFB that generates PKT_REDIR messages 
will provide attributes that can be configured to decide which packets 
must be redirected or mirrored. A CONFIG msg to the appropriate 
attribute(s) should suffice, no ?


Forces-protocol mailing list